Fog Creek Software
Discussion Board




cool production code

Do you ever find code that is alive and well in a production environment and wonder how things like this even exist???

Private Function GetCellLetter(column As Integer) As String
' This function will return the spreadsheet column for a give numeric column
' 1 = A, 2 = B, 12 = L
' This function is only good til Z
Dim l              As Integer
Dim ColStr          As String

    ColStr = Trim$(Str$(column))
   
    l = Asc(Right(ColStr, 1)) + 16
    If Len(ColStr) > 1 Then l = l + 10
   
    GetCellLetter = Chr$(l)
   
End Function


...

"the wonder is not how the bear dances, but that it does at all." - Alan Cooper

Anon
Tuesday, May 07, 2002

That code looks like something I would have written just after I came off the mainframes in 1992.

It is amazing how much clunky and questionable code exists in production systems.

I'm working on a UNIX GUI telecom application that has been around for nearly 10 years...some pretty gruesome but functional code running there.

Brad Clarke
Tuesday, May 07, 2002

I once came across some code in a financial application for checking if a value was zero, which appears not to work all of the time. Someone says to me not to use it very often because it was very slow and not very trustworthy. How slow and untrustworthy could it possibly be, I wondered...

It sprintf'd the double[1] into a big buffer and ambled along the result looking for non-'0' digits. {Of course this doesn't work, because in double math, two minus two doesn't necessarily come out as EXACTLY zero.}

I then had one of the surreal conversations I keep having with people: "Why not just check it's between minus sigma and plus sigma where you pick sigma suitably small?"

"But how small would we pick?"

"Well, sensibly speaking, how many of the customers do their accounts to the tenth of a penny?"

"None."

"There you go then."

"But... but we can't go changing code that works."

"It DOESN'T work!! We have bug reports from customers about it.."

"It's deployed, it must work!"

<blink>


The reciprocity project talks about this bizarre ability of some people to dismiss the world in front of them and drift off into a fantasy world that doesn't contain logical contradictions.

Why must I work with each and every one of them?



[1] Yes. They were using doubles in a financial application. I reamed them out about that as well, but they kept on doing it, customers kept on finding bugs in their accounts...

Katie Lucas
Wednesday, May 08, 2002

> [1] Yes. They were using doubles in a
> financial application. I reamed them out
> about that as well, but they kept on
> doing it, customers kept on finding bugs
> in their accounts...

There's really nothing wrong with using "double" variables in a financial application - you just need to know how to use them properly.

And that's the fundamental problem - most programmers get by using so little math in their everyday work that they forget everything they learned in their basic math, science, and engineering classes about how to round numbers, the concept of "significant digits", etc.

Having said that, those languages and environments where a "managed precision" type is available probably suffer less from the "3/5*5 = 2.9999999999" problems.

I wonder why that kind of numeric support isn't built into more programming environments?

-Mark

Mark Bessey
Wednesday, May 08, 2002

Oh there's considerable wrong in using floating point when handling currency as a transactional value (as opposed to currency being the transaction itself).

Fractional carries and rounding is an evil, all the more so when you add VAT calculations which have specific and legal constraints on rounding, or in their case truncating.

Simon Lucy
Thursday, May 09, 2002

In Java, you can use the BigDecimal class, or the opensource IBM improvement soon-to-be available in JDK 1.5; and Sun has partnerered with companies offering well-featured financial classes.  C# has the primitive decimal type, and there is probably a wrapper convenience class.  Python has the decimal type in the works, wrapping the GNU multi-precision library.

For short, quick explanations:
[ http://www-106.ibm.com/developerworks/library/mathlibs/ ]
[ http://www2.hursley.ibm.com/decimal/decifaq.html#swsupport ]

For a big, long explanation, Google search on "What Every Computer Scientist Should Know About Floating Point Arithmetic".  Of course, you won't read this (I didn't), but it's cheaper than TAOCP v2, which no one reads either... but everyone has a Copy.

Sammy
Thursday, May 09, 2002

Simon, I'm with Mark on this one. You can deal properly with fractions and various rounding/truncating rules safely in floating point. The key is to maintain the smallest unit you deal with to the left of the decimal. For example, if you need exact cents, rounded to nearest (with half cent rounded up), and you want to compute (say) 7 percent, you keep amounts in cents and use
y=trunc((7*x+50)/100).
Try it for x=149, 150, and 151 to see how it works for $1.49, $1.50, $1.51.
$1.50 x .07 = $.105 rounds to $.11, as it should. More complicated regimes for rounding can also be implemented correctly as well. Proper scaling is the key.

Ray Gardner
Thursday, May 09, 2002

*  Recent Topics

*  Fog Creek Home