parseInt(’08′, 10) – changes to base 10

I don’t think you understand what I’m telling you …

Maybe because what followed never appeared anywhere in your previous comment? Anyhow, you’re right: 0.1 + 0.2 == 0.3 returns false in those languages. I’m surprised, given the different results of 0.1 + 0.2 in those languages versus ECMAScript and Java.

This is not some JavaScript weirdness, it’s a well-known consequence of the impossibility to express either of these numbers exactly as a floating point number.

I’m well aware. It can, however, be solved.

As far as your continued suggestion to read more, I’m familiar with the issues involved on a general level, and never claimed it was “JavaScript weirdness”. I was mislead in practice by the inconsistencies of results in those languages versus in ECMAScript.

All in all, none of these WTFJS examples are really surprising for anyone who’s been working with the language for a while. Personally, I think giving null the type “object” was not a wise design decision, but I can live with that.

Agreed, agreed.

If you want some serious WTFs, look at IE’s treatment of host objects.

But here I think we’re looking at WTFDOM, not WTFJS. I don’t know the ins and outs of this bug, but it seems to me that the internal DOM is lying to the JScript engine.

Anyway, thanks for correcting my error. I hope you’ll understand why I was mislead, and accept that my misunderstanding of specific behavior doesn’t betray a misunderstanding of how floating point numbers work generally.

The thing that I “got” when I started in Java (and this was 8 years ago) was.. the vast majority of young developers, have little knowledge of these ever present inaccuracies. There are in fact, many of them. It’s not necessarily a bad thing though. Young developers expect there tools to work. I cant blame them at all, it frees up a few time slices for other processes. Thats why VMs like Java and .Net are so popular (disclaimer I have never used nor do I know much about .Net). I started getting serious about a year ago, and I’m somewhat dismayed at the state of the language myself.

P.S.
bit shifting in JS.. wtf is that good for? :)

Perl, PHP, Python, and Ruby all show the same rounding errors, but not necessarily for simple operations like 0.1 + 0.2

I don’t think that’s an accurate statement. The question isn’t simplicity or complexity of operations, but degree of precision. Precision of floating point numbers in Perl, PHP, Python and Ruby is greater than that in ECMAScript and Java. I didn’t attempt to claim that numbers in those language have infinite precision, I hope that’s clear now.

JavaScript doesn’t have a “decimal” type. There was an effort by IBM to get it into ECMAScript 5, but it was voted down by the committee.

Yes, this is true. This is because IBM was steadfast in the particular standard they insisted on using. Both sides were in error, in my opinion.

I’m not sure if this point was intended as a rebuttal or correction, so if it was I don’t know how to address it.

bc is a different case; it’s a calculator, and has its own oddities. Try calling it (without the -l option), and it will tell you that 3/2 makes 1.

This isn’t a rounding error, it’s a rounding default that is not what one might intuit. It simply rounds to an integer (down for 0-5) by default.

I don’t have AppleScript available for testing.

AppleScript doesn’t support the operations in question, so it is untestable. It seems the precision is equal to that of Perl, PHP, Python and Ruby, as 1234567.1229999999 and 1234567.123 both output 1.234567123E+6.

If you need more information about this, search for “IEEE-754?.

Again, I’m not sure if this is meant as a rebuttal or correction of something, so I’m not sure how to address it. Nothing I’ve said here is inaccurate and I think I’ve adequately addressed the question of precision as it differs from ECMAScript to certain of other languages.

$ perl -e ‘printf(“%.10f\n”, 1234567.123)’
1234567.1229999999
$ php -r ‘printf(“%.10f\n”, 1234567.123);’
1234567.1229999999
$ ruby -e ‘printf(“%.10f\n”, 1234567.123);’
1234567.1229999999
$ python -c ‘print “%.10f” % 1234567.123′
1234567.1229999999

JavaScript doesn’t have a “decimal” type. There was an effort by IBM to get it into ECMAScript 5, but it was voted down by the committee.

bc is a different case; it’s a calculator, and has its own oddities. Try calling it (without the -l option), and it will tell you that 3/2 makes 1. I don’t have AppleScript available for testing.

If you need more information about this, search for “IEEE-754″.

You said that any programmer in any language should expect 0.1 + 0.2 === 0.3 // false.

You are incorrect. This isn’t a matter of opinion, I provided half a dozen examples where a programmer would not and should not expect that. The differences, then, between double and float, are moot. Look again at your first comment. It had nothing to do with double or float, just whether or not 0.1 + 0.2 === 0.3. All the “WTF” was pointing out was that ECMAScript’s floating-point precision is not sufficient for that mathematical equation to behave as expected from a mathematical standpoint. This is true in other languages (Java being the example you provided), but not true in other languages as well (perl, php, python, ruby, AppleScript and bc being the examples I provided). It’s without a doubt language-specific, because some (but not all) languages have this problem.

Let me clarify what I am and am not saying. First, what I’m not saying:

1. ECMAScript is unique in floating point imprecision.
2. Imprecise floating point operations are unavailable in other languages.

What I am saying:

1. 0.1 + 0.2 != 0.3 is not (as you claimed) the case in “any programming language”, and I demonstrated that.
2. It then doesn’t follow that this is something any programmer should expect, negating the importance of pointing out the oddity in ECMAScript for those who expect 0.1 + 0.2 == 0.3.

Therefore, 0.1 + 0.2 != 0.3 does not belong to “WTFANYPROGRAMMINGLANGUAGE”, as in quite a lot of programming languages that is not the case.

System.out.println(a+b==c); // false
System.out.println(a+b); // 0.30000000000000004

perl -e ‘print .1 + .2 . “\n”;’
0.3

php -r ‘print .1 + .2 . “\n”;’
0.3

python -
>>> print .1 + .2
0.3

ruby -e ‘print 0.1 + 0.2; print “\n”;’
0.3

AppleScript:
.1 + .2
0.3

bc
.1 + .2
.3

I don’t really have time to go any further, but the only other language I could find where .1 + .2 != .3 is ActionScript, another ECMA variant.

(typeof obj == ‘number’ and isNaN(obj)) will let you know if the value is NaN, which would be nicer to simply be able to compare == NaN or === NaN like you can for an empty string, but not Undefined either. The other thing that’s nice and painful at the same time, is that null, ”, false and 0 all have equality, so you need to test for explicit equality if 0 is valid but say false isn’t etc.

Anyone who would expect typeof null returning “object” to mean that null === Object needs to take a step back and thing about it. This is true for everything that returns “object”, null is no exception.

And to ywg,

“Theses do not belong to WTFJS, but to WTFANYPROGRAMINGLANGUAGE”

Even the nightmare that is ECMA’s float standard choice, really? I don’t use any other language that treats 0.1 that way. I’m sure plenty do, but it’s definitely not a given and it can definitely lead to unexpected errors.

it is a numeric representation of something that is not a number. The value expressed by NaN has the type “number” because it is produced by numeric expressions (such as 1/0), and all numeric expressions have to provide numeric values.

In some ways it is the equivalent of null, in the sense that null is the representation of an object reference that does not exist, while NaN is the representation of a numeric value that does not exist.