ECMAScript Version 5 Approved

systembug writes "After 10 years of waiting and some infighting, ECMAScript version 5 is finally out, approved by 19 of the 21 members of the ECMA Technical Committee 39. JSON is in; Intel and IBM dissented. IBM is obviously in disagreement with the decision against IEEE 754r, a floating point format for correct, but slow representation of decimal numbers, despite pleas by Yahoo's Douglas Crockford." (About 754r, Crockford says "It was rejected by ES4 and by ES3.1 — it was one of the few things that we could agree on. We all agreed that the IBM proposal should not go in.")

Comments

use fixed point instead

[StripedCow]

instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.

and if you're afraid that you might mix up floating point and fixed point numbers, just define a special type for the fixed-point numbers, and define corresponding overloaded operators... oh wait

Re:use fixed point instead

[StripedCow]

Do you work for these guys?

No, but they can hire me... I'm already looking forward to the amount they'll put on my paycheck...

Re:use fixed point instead

[shutdown -p now]

instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.

There are several problems here.

First of all, quite obviously, having to do this manually is rather inefficient. I do not know if it's a big deal for JS (how much of JS code out there involves monetary calculations), but for languages which are mostly used for business applications, you really want something where you can write (a+b*c).

If you provide a premade type or library class for fixed point, then two decimal places after the point isn't enough - some currencies in the world subdivide into 10,000 subunits. So you need at least four.

Finally - and perhaps most importantly - while 4 places is enough to store any such value, it's not enough to do arithmetics on it, because you'll get relatively large rounding errors (basically you may start missing local cents after two operations already).

All in all, decimal floating-point arithmetics just makes more sense. It's also more generally useful than fixed-point (it's not just money where you want decimal).

Re:use fixed point instead

[DragonWriter]

You would always use the smallest subdivision of a currency as the unit for calculations. For the US dollar you store everything as cents

Except that there are all kinds of areas where units smaller than cents are required when working with US currency. If you don't believe me, try finding a gas station whose prices aren't specified in mils. The smallest subdivision for which coins are minted -- or which normal bank transactions can be conducted in -- is not necessarily the smallest unit that needs to be stored or used in calculations.

I can guess why IBM was pushing for IEEE 754r

[tjwhaynes]

The debate over floating point numbers in ECMAScript is interesting. IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99+% of desktop users are running. Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware. This is an area where IBM already has a hardware implementation of IEEE 754r - its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation. I suspect that IBM will continue to push for IEEE 754r in ECMAScript, I wonder whether Intel is considering adding IEEE 754r support to its processors in the future.

Disclaimer: I have no contact with the IBM ECMAScript folks.

Cheers,
Toby Haynes

Re:I can guess why IBM was pushing for IEEE 754r

[teg]

IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99+% of desktop users are running. Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware. This is an area where IBM already has a hardware implementation of IEEE 754r - its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation.

ECMAScript is client side, so I don't think that was the issue. Z-series is server only, and POWER6 is almost all servers - and for POWER workstations, the ability to run javascript a little bit faster has almost zero value. The more likely explanation is that IBM has its roots in business, and puts more importance into correct decimal handling than companies with their roots in other areas where this didn't matter much.

Re:I can guess why IBM was pushing for IEEE 754r

[H0p313ss]

There's also the mobile realm, where I don't think IBM has even stepped foot in.

The IBM JVM is used in mobiles. Lenovo (part owned by IBM) has/had a cellphone division.

Re:I can guess why IBM was pushing for IEEE 754r

[csnydermvpsoft]

Why do processors need decimal number support? 10 is just an arbitrary number humans picked because they happen to have 10 fingers. There's no connection between that and computers.

I don't know about you, but I'd prefer that computers adapt to the way I think rather than vice-versa.

Re:I can guess why IBM was pushing for IEEE 754r

[tjwhaynes]

Why do processors need decimal number support? 10 is just an arbitrary number humans picked because they happen to have 10 fingers. There's no connection between that and computers.

Clearly you've never dealt with an irate customer who has spent $$$ on your software product, has created a table using "REAL" (4-byte floating point) types and then wonders why the sums are screwing up. IEEE754 can't accurately represent most fractions in the way that humans do and this means that computers using IEEE 754 floating point give different answers to a human sitting down with pen and pencil and doing the same sums. As humans are often the consumer of the information that the computer spits out, making computers produce the correct results is important.

There are plenty of infinite precision computing libraries out there for software developers to use. However, they are all a lot slower than the 4, 8 or 10 byte floating point IEEE 754 calculations which are supported directly by the hardware. Implementing the IEEE 754r calculations directly on the CPU means that you can get close to the same performance levels. I'm guessing that at best, 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754, purely because of the data width.

Cheers,
Toby Haynes

Re:I can guess why IBM was pushing for IEEE 754r

[TrancePhreak]

It doesn't seem like any of the ARM based procs support IEEE 754r.

Re:I can guess why IBM was pushing for IEEE 754r

[systembug]

(...) I'm guessing that at best, 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754, purely because of the data width.

According to Douglas Crockford "...it's literally hundreds of times slower than the current format.".

Re:I can guess why IBM was pushing for IEEE 754r

[tjwhaynes]

(...) I'm guessing that at best, 128 bit IEEE 754r performs about half the speed of 64bit IEEE 754, purely because of the data width.

According to Douglas Crockford "...it's literally hundreds of times slower than the current format.".

I don't doubt that the software implementations are "hundreds of times slower". I've had my hands deep into several implementations of decimal arithmetic and none of them are even remotely close to IEEE 754 in hardware. IEEE 754r is better than some of the predecessors because a software implementation can map the internal representation to integer maths. However, IEEE 754r does exist in hardware and I was guessing that the hardware IEEE 754r is still half the speed of hardware IEEE 754.

One other thing that IEEE 754 has going for it is the emerging GPU-as-co-processor field. The latest GPUs can do full 64bit IEEE 754 in the stream processors, making massive parallel floating point processing incredibly speedy.

Cheers,
Toby Haynes

Re:I can guess why IBM was pushing for IEEE 754r

[roemcke]

So 754 vs 754r boils down do this: When doing arithmetic using 754, then 0.1+ 0.2 != 0.3 (as any half decent programmer should know). IBM want to fix it with a new floating point format that can do exact calculations (under certain circumstances) with decimal numbers.

Personally a see two problems with this:

First, it won't fix the stupid programmer bug. 754r can't guarantee exactness in every situation. For instance, (large_num+small_num)+small_num == large_num != large_num+(small_num + small_num).

Second, ECMAScript is supposed to run on different architectures. It should not depend on specific number-representaions, not for integers and certainly not for floating points.

In my opinion, the right thing to do is to look at Scheme. Scheme has two numeric types, exact and inexact, and leaves it to the implementation to choose what internal representation to use (normally integer or some rational number for exact numbers, and floating point for inexact). If a function can can make an exact calculation with exact numbers as input, it returns an exact number, otherwise it returns an inexact number.
The important here is that when the programmer needs exact calculations (for instance monetary calculation with fractional parts), he specifically chooses exact numbers and leaves it to the language-implementation to figure it out how to represent the numbers in memory.

There is only one minor problem with the scheme-way, it doesn't discourage the use of inexact numbers when it is obvious that the programmer is a moron. An improvement for both ECMAScript and Scheme, could be to throw an exception whenever the programmer compares two inexact or floating point numbers for equality.

Re:I can guess why IBM was pushing for IEEE 754r

[BZ]

> ECMAScript is client side,

You may be interested in http://en.wikipedia.org/wiki/Server-side_JavaScript

I agree that user-visible ECMAScript is client-side, but user-visible _everything_ is client-side, really.

Re:I can guess why IBM was pushing for IEEE 754r

[Junior J. Junior III]

Why do processors need decimal number support? 10 is just an arbitrary number humans picked because they happen to have 10 fingers. There's no connection between that and computers.

Yes there is; the human. Humans use base-10 quite a bit, and they use computers quite a bit. It therefore makes a great deal of sense for humans to want to be able to use base-10 when they are using computers. In fact, it's not at all surprising.

Re:I can guess why IBM was pushing for IEEE 754r

[Gospodin]

First, it won't fix the stupid programmer bug. 754r can't guarantee exactness in every situation. For instance, (large_num+small_num)+small_num == large_num != large_num+(small_num + small_num).

Actually, 754r handles situations like these via exception flags. If large_num + small_num == large_num, then the "inexact" and "rounded" flags will be raised (possibly others, too; I haven't looked at this in a while), which the programmer can use to take some alternate logic. It's certainly true that stupid programmers can use these tools incorrectly (or not use them), but isn't that true of any system? Sufficiently stupid programmers can defeat any countermeasures.

Re:JSON is in!?

[maxume]

Implementations are expected to provide a safe(r) parser than eval.

Financial Calculations

[pavon]

When you have strict regulatory rules about how rounding must be done, and your numerical system can't even represent 0.2 exactly, then it is most certainly a concern. There are other solutions, such as using base-10 fixed point calculations rather than floating point, but having decimal floating point is certainly more convenient, and having a hardware implementation is much more efficient.

Re:Financial Calculations

[iluvcapra]

If you know someone that is using IEEE floats or doubles to represent dollars internally, reach out to them and get them help, and let them know that just counting the pennies and occasionally inserting a decimal for the humans is much, much safer! ;)

Re:Financial Calculations

[Bigjeff5]

Why not? There is nothing intrinsicly differen't about the way Javascript is executed on a machine than, say C. They both eventually make it to machine language for execution, and any errors are going to be in the compiler (whether JIT or compiled in advance). Limitations in the language and the fact that it is interpreted means there are a lot of things you can do in C that you cannot do in Javascript, but none of that applies to raw calculations. C is just as susceptible to the floating point problem as Javascript, and the methods to avoid that pitfall are identical in Javascript and C. .1 + .2 != .3 in both, the dangers are the same.

The real question you should be asking is, who in their right mind would let a programmer who does not understand the pitfalls of floating point calculations write code for financial calculations that need to be relied on?

point in video where Crockford talks about this

[Anonymous Coward]

13:51 into the video is where you want to skip to if you want to hear just this argument. I just don't have the time for the whole 55:42 video. Nice non-youtube player though.

Re:JSON is in!?

[amicusNYCL]

Is that how JSON took hold? By being easy to parse using eval?

No, it took hold because it's Javascript's native object notation. And, as you can imagine, if you have a string of code you use eval to convert it. There are several JSON parsers which do some validation before using eval to ensure that it contains only an object definition and no statements. It would be nice if that validation was standardized and built-in.

they could have just used XML instead

Developers have a choice between XML and JSON (XML is already well supported), but many developers choose JSON instead of XML. Among other things, a JSON structure is typically smaller than a comparable XML structure, and when it's decoded you don't need to use anything special to use it.

instead of inventing a new serialized object format.

They didn't really invent this so much as realize that the native object format can easily be used to transfer arrays and objects between languages. It's very easy to create an associative array in PHP, encode it and send it to Javascript, and end up with virtually the exact same data structure in Javascript. Working with an associative array in PHP (or Javascript) is obviously a lot easier than working with an XML structure. Virtually any language you would use on a server has support for associative arrays or generic objects, so it makes a lot of sense to pass those structures around in a way where you lose no meaning and each language natively supports it.

Re:Will this allow us a FOSS alternative to Flash?

[snaz555]

Until we get a slick gui editor for javascript+svg animation, no.

In other words, we need GNU Ecmas.

Re:Context

[revlayle]

formal name of JavaScript - now turn in your geek card

Re:Floating point numbers and decimals

[mdmkolbe]

This is an area where ECMAscript pays the price for not being a strongly typed language.

I think you mean "statically typed" not "strongly typed".

Statically typed Catches type errors at compile time. Dynamically typed Catches type errros at run time. Strongly typed Always catches type errors. Weakly typed Doesn't always catch type errors.

Sorry, as a programming languages researcher this is a pet peeve of mine. Carry on.

Re:Floating point numbers and decimals

[mdmkolbe]

Catches type errros at run time.

And no, I don't know what the name is for a language that catches spelling errors.

Re:Calculations in cents

[Yvan256]

Even easier would be to base all the system on cents. After that it's extremely easy to convert that cents value into a dollar/cents string.

Yes, in Javascript

[pavon]

There is nothing stupid about using javascript for financial calculations. More and more applications are moving to the web, and the more you can put in the client, the more responsive the application will be. Imagine a budgeting app like Quicken on the web, or a simple loan/savings calculator whose parameters can be dynamically adjusted, and a table/graph changes in response. While critical calculations (when actually posting a payment for example) should be (re)done on the server, it would not be good if your "quick-look" rounded differently then the final result.

And no, people should not be using floating point for currency, ever, and fixed-point calcualtions aren't hard. But there is more to it that "just put everything in cents"; for example, you often have to deal with rates that are given as fractions of a cent. A decimal type would make this more convenient.

Finally, I don't know if IBM's proposal is a good one. I haven't looked at it; I was just talking in generalities.

Floating point representation

[XNormal]

The floating point representation issue could be resolved the same way it is handled in Python 3.1 by using the shortest decimal representation that is rounded to the exact same binary floating fraction.

With this solution 1.1 + 2.2 will show as 3.3 (it doesn't now) but it will not test as equal to 3.3. It's not as complete a solution as using IEEE 754r but it handles the most commonly reported problem - the display of floating point numbers.

See What's New In Python 3.1 and search for "shortest".

Re:Floating point representation

[YA_Python_dev]

Wrong. 1.1 + 2.2 in Python 3.1 shows as 3.3000000000000003, just like any other Python version.

The change is for e.g. "1.1 + 1.1" which shows 2.2 (instead of 2.2000000000000002 in old Pythons). And of course "1.1 + 1.1 == 2.2" is always True, in any Python version. If and only if two floats have the same repr(), they will be equal (except NaNs), again this is true for any Python version.

Still no O(1) data structure

[Tailhook]

Back when ECMAScript 4 was still alive there was a proposed Vector class that had the potential to provide O(1) access. This is very useful for many performance sensitive algorithms including coding, compression, encryption, imaging, signal processing and others. The proposal was bound up with Adobe's parameterized types (as in Vector<T>) and it all died together when ECMAScript 4 was tossed out. Parameterized types are NOT necessary to provide dense arrays with O(1) access. Today Javascript has no guaranteed O(1) mechanism, and version 5 fails to deal with this.

Folks involved with this need to consult with people that do more than manipulate the DOM. Formalizing JSON is great and all but I hadn't noticed any hesitation to use it without a standard... ActionScript has dense arrays for a reason and javascript should as well.

Re:Any other notable changes?

[Bill, Shooter of Bul]

Read the article, it provides some explanation of why things are the way they are.

Plus, what exactly are your other options? Doing the entire page in flash or active X?

Also, sort of makes perl 6's development look a lot better, doesn't it?

Re:Any other notable changes?

[TheCycoONE]

There are several other things, the most significant of which in my opinion is property descriptors:

eg. For any property (value/function) of an object you can specify whether it is: writable, enumerable, or configurable; allowing for read only properties, properties which do not pollute a for(val in obj) call, and properties which cannot be messed with by other programmers.

See: http://ejohn.org/blog/ecmascript-5-objects-and-properties/ for a better description.