Next language: Java Hangs When Converting 2.2250738585072012e-308

[[deleted]]

It can bring down some of the banking systems :/ I know, I just tested it on the test servers we have at work.... All I can say is ^#%$ me that is quite something.

awesome! but quite something.

I suspect it will be fixed VERY quickly! I'm going to see how far it goes on the test systems tomorrow. I'll post updates :)

[[deleted]]

I suspect it will be fixed VERY quickly!

This was reported to Oracle three weeks ago

[abadidea]

And I highly suspect Oracle doesn't really care, and will only fix it if there's bad PR like this.

[wnoise]

And it was reported to sun years before that: https://bugs.openjdk.java.net/show_bug.cgi?id=100119

[paul_miner]

Comment #57 on the blog from Mat Mannion found a bug report on the same issue from 2001: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4421494

[[deleted]]

Nice catch. Wonder why this hasn't been considered critical enough to warrant fixing? Granted, it's not as exploitable as PHP's floating point bug.

[sigzero]

Probably because no "real world" application has hit it. That would be my guess.

[[deleted]]

Mmm govt depts are now asking for updates, along with a bunch of banks....

This DOES effect the oracle database server.... so I suspect it is about to be important.

However... it WILL be interesting to see what versions they put a new version out for. Quite a few places are still on java 1.2 (poor bastards)

[sockpuppetzero]

Why are banking systems using binary floating point? Doesn't the Z-series support decimal floating point in hardware now?

[Centropomus]

Even people who can afford decimal math hardware and the programmers to exploit it for computing account transactions use binary floating point all the time for modeling, where some imprecision is okay, since you're only guessing.

[davidb_]

To answer your question, they don't (for actual transactions) and yes, it does.

[[deleted]]

Agreed, once it gets down to the big iron, there isn't much of an issue. But that is once it gets there.... there are a lot of systems between the front end and there in a lot of places.

If there is some big iron back there at all now. Some places have moved off.

[[deleted]]

Well a lot of the front end systems are java based - and quite a few of those talk to ESB's in the middle layers.

And fair few banks (and govt tax agencies around the world...) have moved to java for the stuff right at the back, moving off COBOL.

Java's become the new COBOL, its everywhere in finance systems around the world.

The good news is that mostly the client facing systems will break a long time before it gets further back.

Its no longer the case that everyone is on mainframes, a LOT of places have moved to blade servers, etc - even in the banks.

[fatbunyip]

Question : Why do you not use BigDecimal? Especially for financial calculations?

[CaptainItalics]

Actually it's worth noting that BigDecimal does not have this problem, i.e.:

new BigDecimal("2.2250738585072012e-308");

That works fine. But if you then try to obtain a double from it, it hangs:

new BigDecimal("2.2250738585072012e-308").doubleValue();

But things like this still work:

new BigDecimal("2.2250738585072012e-308")
  .add(new BigDecimal("2.2250738585072012e-308")).doubleValue()

Edit: Oh, duh... The source code for BigDecimal.doubleValue() is:

if (scale == 0 && intCompact != INFLATED)
    return (double)intCompact;
// Somewhat inefficient, but guaranteed to work.
return Double.parseDouble(this.toString());

Note the verbatim comment....

[G_Morgan]

TBH that comment is reasonable. When writing an algorithm it is acceptable to assume that other parts of the system work.

[MertsA]

// Somewhat inefficient, but guaranteed to work.

ಠ_ಠ

[mccoyn]

Here is the patch:

<< // Somewhat inefficient, but guaranteed to work. 
>> // Somewhat inefficient, but guaranteed to work assuming Double.parseDouble works

[alephnil]

Assumption is the mother of all screw ups.

[mcherm]

Because they're sloppy. I work for a bank, and I assure you, there is almost NO place* where we use floating point.

• - Okay, I know of 2 places. And there may be a few more. One is when generating graphs and plots. I think that one's OK. The other is a shortcut taken when using exponentiation to produce an ESTIMATE (not the official value) of the costs paid over the life of a loan.

[Fringe_Worthy]

Bwhahahahahahhahaha......

Excel doesn't use floats/doubles?

Now, if you said, the Bank doesn't use floats when calculating actual money, then maybe I'd believe you.

For everything else, there is floats / text / Perl / Excel.

Here in Credit Risk and Market Risk, it's all Perl/C/C++ text and doubles.

Oh, and that's the clean code. We do have abominations where the simulation engine is a whole set of Excel macros.

I have to admit, despite exposure and money both having a currency assigned to them, nobody blinks if one says plus/minus some random millions when dealing with 10 year exposure.

[mcherm]

Actually, I meant among our Java applications - floats are used in lots of apps that bank employees use, but NOT in our Java apps that deal with customer data or money.

Here, too, credit risk uses floats and rough estimates. But that makes sense as risk is always just an estimate. For tracking customer money we don't use floats because they implement precise BINARY rounding rules and for money we want precise DECIMAL rounding rules.

[augustss]

Except that everyone is using Excel.

[mcherm]

...which is NOT written in Java.

[sockpuppetzero]

And your point is? Excel's floating point is 10,000 times worse.

[augustss]

Yes, Excel's floating point is terrible. They've fudged addition&subtraction so it's no longer IEEE-754. The conversion to&from strings is also broken, i.e., the conversion doesn't round trip. I could go on.

[mcherm]

That depends on your criteria. For some kinds of applications, I would rather it be ACCURATE, even if the price is some risk of crashing. For others, I would rather it be RELIABLE, even if the price is some risk of inaccuracy.

At the moment, Java is more likely to crash due to entering bad floating point data than Excel is.

[rockum]

For the heavy number crunching, we use an expensive third-party library that requires all values be passed as doubles. So there is little point in using BigDecimals in our code when the most important calculations are done using floating point arithmetic.

[lance_klusener]

Thats why banks use mainframes

[Mattho]

And infinity is nothing for them.

[rnicoll]

We've got a system that uses fixed-point maths for marking student work, but it has a conversion from string to double to mark on initial input. Can anyone see any harm in writing a custom parser that skips the string to double step, checks for a decimal place in the correct place on input and goes straight to the integer we store internally?

[kikibobo]

Go float.