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

[swimboy]

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

Do you work for these guys?

Re:use fixed point instead

[antifoidulus]

Hah, if you hadn't made that mundane mistake in your little scheme it would have worked perfectly, but Lumberg is on to you, you are going to federal pound-me-in-the-ass prison!

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

[Anonymous Coward]

No, you have to define all these functions in advance and then there is no problem.

Re:use fixed point instead

[molecular]

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 let all hell break loose when someone forgets to multiply / divide by 100, like happened here: http://entertainment.slashdot.org/story/09/11/25/1448218/Moving-Decimal-Bug-Loses-Money

Re:use fixed point instead

[Anonymous Coward]

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).

It's mostly input and output routines that need to monkey with the decimal point. You can still write (a+b*c) when you are dealing with pennies or cents.

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.

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

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).

You could use some other fixed point arithmatic. One of the linked articles was talking about using "9E6" were the numbers are 64 bits scaled by 9 million. That sounds a bit strange, but gives you a fare number of places after the decimal point, and lets you store a lot of common fractions (1/3, 1/360, etc.) exactly.

Either that, or use floating point but make the unit the smallest subdivision of the currency in question. You lose a bit off the top end (so your national deficit can only go up to 10^306 dollars instead of 10^308 or whatever) but you can store exact representations for whole numbers of cents/pennies/milims.

Re:use fixed point instead

[Yaa 101]

uhm, make that times 10.000, one needs 4 decimal places for correct rounding etc.

Re:use fixed point instead

[DragonWriter]

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.

Of course, you still have to use floating point operations (or horrible, case-by-case workarounds) if you are doing anything other than addition and subtraction, and multiplication by integer values, even if the representation you use for the inputs and results is fixed-point, and you'll have to convert the results of the floating point operations to and from your fixed-point representation. When you don't have very specific rounding rules for the operations, this isn't problematic, but the more specific the rules you have, the more cumbersome this will be, particularly if the rules are based on base-10 representation (as the often are in real world uses) and the floating point representation is base-2.

If you have use a base-10 floating point system (representation and operations) with good support for rounding the ways you need to start with, you can express the operations you want performed on the numbers more directly in your code.

Re:use fixed point instead

[angel'o'sphere]

So, are you sure you really understand the difference between a floating point and a fixed point numbers?
Would you care to point out lets say 3 of the advantages of each and 3 of the disadvantages of each? Feel free to intermix math dis-/advantages with implementation dis-/advantages ...

Man oh man, if you ever had implemented a fixed point math lib you would know that it lacks dozens of features a floating point implementation gives you (for a trade off, ofc).

angel'o'sphere

Re:use fixed point instead

[DamonHD]

Not all currencies have two digits after the decimal point.

Rgds

Damon

Re:use fixed point instead

[Jeremy Erwin]

Some local governments in the United States still calculate certain tax liabilities in Mills.

Re:use fixed point instead

[Anonymous Coward]

In a recent project of mine, I needed very high levels of application-specific clock accuracy over long periods with thousands to millions of iterations. This was my first time developing a major project, and with that freedom came the thought "Why not use an integer representation?"

In both my application and with currency apps, you're going to have a level of inaccuracy regardless of whether it's floating point or integer-based. One of the key differences is that with integer-based representation the level of inaccuracy is much more immediately apparent -- with a quick formula, I was able to mathematically describe precisely the level of accuracy maintained over a precise amount of time. With floating-point, almost everyone simply does hand-waving. Even the more careful engineers will follow a set of guidelines to try to maintain accuracy, but I doubt many of them will mathematically prove the limitations of the accuracy of their floating-point algorithms which is relatively easy to do with integer-based values.

The question I would have is how well-defined are the range of values needed for representation? The more well-defined they are, the more inclined I'd be to argue for floating point. In this particular case, you'd have to ask what the largest currency value it is that they want to be able to represent. If they know the number, define the format such that excess digits go to the right of the decimal point and you'll be able to derive accuracy levels for various operations and combinations of operations. In my case, I had a well-defined range of clocks speeds that allowed me to maintain effective accuracy (i.e., output kept completely accurate) with running times over a year while most use cases would involve running the app for less than fifteen minutes.

Re:use fixed point instead

[Anonymous Coward]

Ack! I meant "The more well-defined they are, the more inclined I'd be to argue for integer-based."

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.

Re:use fixed point instead

[jipn4]

If you provide a premade type or library class for fixed point, then two decimal places after the point isn't enough

Just like decimal coded numbers, you need a variable decimal point position. And you can get that easily.

All in all, decimal floating-point arithmetics just makes more sense.

No, it is absolutely useless. You want a bigint library and a small, simple fixed point library built on top of that. "Decimal floating point" is totally useless.

(basically you may start missing local cents after two operations already).

Decimal representations don't ensure that your numbers add up correctly either.

Re:use fixed point instead

[badkarmadayaccount]

How about using rational fractions, preferentially hardware accelerated? FPUs are too big and slow anyways.

Re:use fixed point instead

[aevans]

Actually, while gas prices are advertised to the tenth of the cent, the numbers are rounded up during calculation. If you buy 10 gallons at $2.499/gallon, you'll have to pay $25

Re:use fixed point instead

[aled]

NEVER, NEVER EVER USE FLOATING POINT FOR CURRENCY.

See an example http://mystuffisallhere.com/blog/post/2009/06/09/And-thate28099s-whye280a6-you-done28099t-use-floating-point-for-currency-values.aspx

It happens in every language, there are intrinsic problems to use floating points for currency calculations.

If you want some math http://docs.sun.com/source/806-3568/ncg_goldberg.html

JSON is in!?

[Anonymous Coward]

JSON was *always* in Ecmascript. It's just object literal notation, a shorthand way of instantiating an object with properties.

Re:JSON is in!?

[maxume]

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

Re:JSON is in!?

[SharpFang]

A parser of superset of JSON was in Ecmascript. With no direct, simple or easy way to limit it to the JSON set. This is mostly OK (if dangerous) if Ecmascript is on the receiving end.

OTOH in order to generate/send JSON, things get more complicated. The usual communication is asymmetric: client->server: HTTP GET/POST, server->client: JSON. Now it would be possible to keep a symmetric connection. And accepting JSON as a standard will protect from a lot of script insertion vulnerabilities, when "JSON" could contain code appended after the closing brace.

Re:JSON is in!?

[SharpFang]

and possibly a creator (serialize object as JSON string) as well?

Re:JSON is in!?

[Sancho]

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

Man, that really stinks. If they'd bothered to care about security in the first place, they could have just used XML instead of inventing a new serialized object format.

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:JSON is in!?

[Sancho]

Interesting. Thanks for the explanation.

Re:JSON is in!?

[asdf7890]

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

It is also easy to not-bother-parsing - just send it down with wrapper code if you are calling a script or file that returns JS code (var somevar = <JSON_stuff>;).

Potentially as nasty as eval() for exactly the same reasons, so much sanity checking is still required if the JSON you send is coming (entirely or partially) the user or persistent storage like the DB.

It is a handy format for defining whole structures in their initial state in code - it can be much more concise, and easier to read afterwards, then a pile of code creating arrays/objects and setting values/properties.

Re:JSON is in!?

[maxume]

I don't think that was a primary reason (safe parsers are, and have been, widely available), I worded my comment in that way because I didn't want to argue about whether or not eval qualified as a json parser.

Re:JSON is in!?

[aztracker1]

see json.org... it's pretty good already. Though having an in-browser JSON.stringify and parse will probably operate better, and safer. I think that adding the toISOString to dates, and including that format in the parser would probably be a nice built-in add, but there are examples in the json.org parser/encoder already.

Re:JSON is in!?

[Anonymous Coward]

JSONP is also just about the only way to grab data from non-same origin sources, making it the standard for mashup type content.

Re:JSON is in!?

[SharpFang]

JSON is a pretty limited syntax so filtering off anything dangerous (by whitelisting legal structures) is quite easy before you launch eval() on it.

Re:JSON is in!?

[wiredlogic]

If only someone could figure out how to make a DTD for this newfangled XML that duplicates the capabilities of JSON and could be parsed with a built-in routine to achieve the same result without eval.

Re:JSON is in!?

[amicusNYCL]

XML is so much more of a pain to work with. When I'm processing a data structure I'm not interested in traversing through a bunch of child nodes in order to find what I'm looking for. It's much, much easier to refer to a specific property in an object than it is to traverse an XML structure looking for attributes or text nodes.

Like I said, developers are free to choose between XML and JSON. It's not just random chance or ignorance that so many people choose JSON over XML. People look at the pros and cons of each and decide that JSON is a better fit for their application. If I have an associative array in PHP that I want to return to a Javascript request, is it a better idea to choose one of the myriad PHP XML libraries, build my XML structure from the array, and output the markup, or just send my array to json_encode and be done with it?

Re:JSON is in!?

[Anonymous Coward]

...and if that didn't work, they could have used more of it!

Re:JSON is in!?

[badkarmadayaccount]

That's why XQuery and XSLT exist.

Re:JSON is in!?

[amicusNYCL]

What is why XQuery and XSLT exist? Those exist because developers are free to choose JSON?

Re:JSON is in!?

[badkarmadayaccount]

Because pure XML is a pain. They are supposed to make it easier. And seem a reasonable solution.

Re:JSON is in!?

[Hurricane78]

It would be nice if that validation was standardized and built-in.

That would be ass-backwards, and as bad as configuring your firewall to accept everything, except for some blocked ports.

The proper way is defined in the spec: It defines only what is allowed. Not what is not allowed.
And actually it’s quite simple too:

JSON is essentially only JS literals, and does not contain functions (which are not literals). That’s it. The result is pure data, and no logic.

With Haskell that would be harder, since Haskell does not know the difference between functions and data. (Functions are data to it.) ^^

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

[TrancePhreak]

There's also the mobile realm, where I don't think IBM has even stepped foot in. Not adopting IEEE 754r at this time seems like the right thing to do.

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

[Lord Lode]

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.

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

[Lord Lode]

I see it now! I wish I could mod this reply up.

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

[kantos]

Intel does in fact have some support for BCD (note this is not IEEE 754r) in their processors using the BCD opcode, this could potentially be used to implement IEEE 754r

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

[amicusNYCL]

I can understand why IBM dissented, but why did Intel? If they have hardware support for the existing spec why would they dissent? Is it over another issue?

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

[systembug]

One should not forget that this time, Intel processors are not the only ones to be considerered. With the rise of the iPhone, RIM, and others, javascript performance on ARM is a serious issue.

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

[dkf]

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

For a long time, they didn't support straight IEEE 754 either, and did all float handling in software. (Don't know if that's changed. At the time I was involved in circuit-level simulation of ARM CPUs, but that was ages ago.)

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

[LWATCDR]

Is IEE754r a superset of 754? If couldn't it be used on hardware that supports it as an option?
Also what does ARM support? Some Arm cores now have FPUs and that is an important architecture for Mobile and is going to be a big percentage of the systems running ECMAScript in the future.

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

[TrancePhreak]

Some of the Cortex ones support 754, but not 754r. It's optional component, however.

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

[mzs]

No x86 does 0-9 BCD only, 754r would need 0-999 BCD for any speed improvement compared to 11 adds with carry. Also I think that the BCD opcodes never got extended circa 80286 like the other ones did to allow other registers to be used.

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

[Anonymous Coward]

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.

Since IBM has hardware IEEE 754r support and Intel does not, IBM likely has patents on one or more critical parts of the hardware implementation. If Intel were to implement 754r on their chips, it will likely get them sued, regardless of whether or not their engineers even looked at the patents, since there may only be one reasonable way to solve the problem. So IBM wants to drive 754r to everyone's chips and make a bunch of money in licenses and/or lawsuits.

Pretty standard business practice in the chip business. Just look at the history between Intel and AMD.

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

[Yvan256]

Screw complicated BCD functions and opcodes... I just do a look-up table. Even with a microcontroller that only has 4KiB you can spare 100 bytes for a look-up table that you can write in seconds instead of wasting 40 bytes and hours of coding and testing and debugging. And don't tell me it's easy to do because not all microcontrollers have enough registers and opcodes to make BCD an easy task.

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

[Anonymous Coward]

Why do processors need decimal number support?

One reason really sticks out. Money.
Decimals give easy and *exact* support for currency units and their sub-units expressed in their normal x.yy form. Binary doesn't. 0.10 (for example) cannot be expressed exactly in that form in binary no matter how many decimal places you use.

Yes, you can store these amounts exactly in binary by (e.g.) multiplying by *decimal* 100. But this is not ideal since it introduces an extra step which which may be missed out and cause incorrect results with financial consequences (e.g. sum of different inputs processed through different code paths; one input is not multiplied by 100 and you end up with a plausible looking but incorrect value; and yes, this *should* be caught in testing but not all bugs are detected, and this bug *could not occur* using decimals).

Or you could use a well-tested decimal library (which is standard practice on platforms without native decimal support). Still less efficient and more error prone (wrong library version etc.) than native support.

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

[Randle_Revar]

also: http://arstechnica.com/web/news/2009/12/commonjs-effort-sets-javascript-on-path-for-world-domination.ars

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

[NNKK]

If it's implemented right, you shouldn't take much of a performance hit, but the FPU would be more complex, with a _lot_ more transistors.

The only real speed hit should be transferring the larger values to/from RAM, but if we're talking about e.g. x86-64 growing 754r support, then QPI and HyperTransport are so bloody fast I doubt you'd notice much for most applications using floating point.

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

[MightyMartian]

The last time I really dealt with currency issues was on a customized Accounts Receivable program I wrote. The language was VB6 and the database was MySQL, so we're dealing with two different arithmetic libraries, and for the first few weeks I thought my head was going to pop off, with the database giving one result for summing a loooong list of AR entries, but equivalent summing in the software being out. This became particularly awful when dealing with sales tax issues.

Finally, I did precisely as you say, I turned everything into long integers. It meant writing my own little set of arithmetic abstraction functions, so nothing was ever as easy "x+y=z". It did make debugging more difficult, but at the end of the day, things have to balance, and converting to decimal numbers for display/reporting purposes was the only solution that I could come up with that would reliably give me the same answer regardless of what platforms aspects of the software were running on.

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:I can guess why IBM was pushing for IEEE 754r

[DragonWriter]

Why do processors need decimal number support?

To most efficiently perform tasks that people want computers to do, which more frequently means performing correct math with numbers that have an exact base-10 representation than, say, doing the same with numbers that have an exact base-2 representation.

10 is just an arbitrary number humans picked because they happen to have 10 fingers. There's no connection between that and computers.

Well, unless you consider that the users of computers are generally humans, and that the uses of computers are in applications defined by humans to fit human needs, which very often involves consuming base-10 input and producting base-10 output, using either operations where conversion to a base-2 approximation of the given base-10 values for internal processing and back out may produce incorrect, or at least unnecessarily imprecise, results.

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

[DragonWriter]

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

Presumably, that's comparing execution speed in environments with hardware support of the old standard, but using software-only for the new standard.

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

[DragonWriter]

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.

Well, IBM isn't the only one (outside of the world of ECMAScript standards)--which is why IEEE754-2008 ("IEEE 754r") incorporates decimal floating point and other improvements to the old version of IEEE 754 that it has replaced as a standard.

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).

The problem for non-stupid programmers is (or one of them, at any rate) that using only binary floating point prevents simple expression of calculations with simple rounding rules, when those rules are defined in terms of base-10 numbers, which is often the case in important application domains.

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.

But, supporting only the old IEEE 754 standard also depends on specific number representations for floating points. It just depends on ones that are less convenient from an application perspective, though easier from an implementation perspective.

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

[Bigjeff5]

Plus the fact that binary math is completely useless for almost all humans.

It has different oddities that we aren't used to, and as such they seem crazy. Nobody cares that it eliminates other oddities, we are used to those and understand them.

So in order to be useful, ALL computers must convert ALL calculations that a human will see into Decimal. If you can do that sooner rather than later, all the better for matching up with what humans will expect (like the results of 2/3).

The decimal standard came about for this very reasons - binary calculated figures come out slightly different than decimal or fraction calculations, and it's disconcerting when you work out a fraction with a pen and paper and come out with a "correct" answer that is different than what the computer says. Since you verified it separately, obviously the computer is wrong.

Decimal calculations avoid that pitfall for the most part (a good FP programmer would have written his code to avoid it anyway), and the calculations come out to exactly the same as what a guy with a pen and paper will produce.

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

[roemcke]

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.

Will these be accessible from ECMAScript? And will most programmers use them correctly?

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.

Exactly, and that is why i think 754r is a stupid hack. Depending on it makes implementations more complicated without solving the problem it is set out to solve: Programmers that haven't done their homework.

Having two numeric datatypes, exact and inexact, won't totally solve "the stupid programmer bug" either, but it will make it much easier for most programmers to understand what is going on, and do the right thing. And it will have the added benefit of letting the language implementation choose the right approach for internal numeric representation for the CPU the interpreter is running on.

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

[Bigjeff5]

It's a common problem people run into (often without realising it), and the standard way to mitigate it is to always calculate the problem at at least two decimals greater precision than the figures you are working with. So if you are given 1 + 1 = X, you calculate at 1.00 + 1.00 = X. 0.05 becomes 0.0500, etc. You don't remove the precision until after all your calculations are finished, and this virtually eliminates the binary/decimal rounding errors that occur. I could see in some cases it still being an issue, but 99% of the time that will fix it.

This basically just performs the hurdles for accurate binary/decimal conversions for you so you don't have to worry about it. It's still going to be calculated in binary at the hardware level though, and it's the natural difference between binary and decimal that causes the problems, so it is still something to keep in the back of your mind.

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

[angel'o'sphere]

Do you know what the difference between a natural number, an integral number, a rational number a real number and an irrational number is?
E.g. the rational number 1/3 is not perfectly describeable as a base 10 real number (0.333333333_).
There are plenty (hm, I wonder if it are "finite" ;D) base ten real numbers that can't be expressed as base 2 real numbers, one example: 0.2. It yields an periodic irrational number in base 2.

In other words, not only 0.2 is not "describable" in base 2, nor you can't calculate 0.2 + 0.2 + 0.2 + 0.2 + 0.2 ... in Base 10 this yields 1.0 (of course), in base 2 it is slightly less than 1.0. (How do you want to handle this???)
See: http://www.digitconvert.com/
Unfortunately 101 (that is 5!) * 0.001100110011001100110011001100110011001100110011001101 (that is 0.2) is rounded up to 1.0 by the online calculator, well probably you now fail to see my point, but exactly this rounding problem is my point.

angel'o'sphere

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

[roemcke]

I am not saying that ECMAScript should choose the old IEEE 754 standard in favor of the new 754r. What I am saying, is that the ECMAScript standard should specify neither of them. It is up to the implementation to select a numeric representation that makes sense on the CPU it it is running on, just as most other programming languages are doing.

I am also fully aware of that in many applications it is important that 0.1+ 0.2 equals 0.3. That is why I used Scheme as an example of how it can be done right. By calling a datatype "inexact" in stead of float/double, it is quite obvious for most programmers that it should not be used for exact calculations. And the "exact" datatype is not limited to holding integer numbers, perfect for counting dollars and cents.

As long as a programmer is not parsing/serializing binary data, all he cares about is whether calculations are exact or inexact, not if they are using the 754 or 754r internal representation.

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

[spitzak]

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.

In C I need to turn these warnings off. In perhaps 99% of the cases where the test is something like "x == 1.0" what is being tested is not "did the calculation result in 1". Instead the test that is really being done is "was the earlier statement that read x = 1.0 executed".

Unfortunatly these warnings are unable to distinguish why the test is being done, and it makes programmers do some stupid things to turn off the warnings. Changing it to some approximatly_equal() function will actually break the logic, especially for a calculation that CANNOT result in 1.0 except by the direct assignment. This is NOT uncommon!

So stop proposing ideas without actually seeing how things are done in the real world.

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

[WillKemp]

I hope you're not a programmer then!

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

[Bigjeff5]

The problem for non-stupid programmers is (or one of them, at any rate) that using only binary floating point prevents simple expression of calculations with simple rounding rules, when those rules are defined in terms of base-10 numbers, which is often the case in important application domains.

But 754r doesn't solve that, it simply mitigates it like anybody who understands the floating point problem already does. It cannot actually solve the problem, because ALL calculations done on a computer are done in binarey - there is no way around it. That the conversion is made in the CPU (FPU more specifically) doesn't change the fact that a conversion must be made and the errors are carried over.

The problem that some people have with doing this is it hides the problem, instead of accentuates it. Now even fewer programmers, especially new programmers, are aware there is a problem. They will simply think "I'm not ever converting out of decimal, so these calculations will always be correct" instead of being aware of the fact that the processor is simply doing some binary>decimal error mitigation for you, and problems can and will still crop up.

It isn't even floating point any more, it's decimal, so they may even have a hard time researching a well documented problem when something does come up.

It's the difference between recognizing a problem as soon as it crops up (because you ran into another FP problem and learned FP's pitfalls) instead of waiting for hours, days, or weeks learning how to correct it.

You know the old saying: Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime. Well, 754r is giving programmers fish instead of teaching them to fish, and it'll bite them in the ass 10 times harder (though 1/10th as often) when you can't figure out the problem because you have no idea there IS one (other than the fact that this one, particular calculation or another is always verifiably wrong).

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

[DragonWriter]

I am not saying that ECMAScript should choose the old IEEE 754 standard in favor of the new 754r. What I am saying, is that the ECMAScript standard should specify neither of them.

I can understand that so far as the internal (within the interpreter) representation, but it certainly needs to specify the behavior of numeric data types, which is most of either the 1985 or the 2008 version of IEEE 754 specifies.

That is why I used Scheme as an example of how it can be done right. By calling a datatype "inexact" in stead of float/double, it is quite obvious for most programmers that it should not be used for exact calculations. And the "exact" datatype is not limited to holding integer numbers, perfect for counting dollars and cents.

While I agree with you that Scheme's numeric tower is a good basic approach to a numeric type system your description of Scheme's numeric system as having only two types, "exact" and "inexact", is incorrect. The Scheme specification (both R5RS and R6RS) specifies a nested tower of 5 types (number, complex, real, rational, and integer). Exactness is an attribute that a numeric value -- of any of the 5 types -- can have.

Further, that doesn't address the issue of behavior, only that of representation.

As long as a programmer is not parsing/serializing binary data, all he cares about is whether calculations are exact or inexact

Actually, there is a lot more that a programmer may care about, such as how data that has to be rounded to fit into the representation used is treated, and what control they have over how that is done. That's a behavior feature that is specified by a floating point spec, and its a point of difference between the different versions of IEEE 754 (since the 2008 version has an additional rounding mode.) They also care about what values can be represented exactly, since that affects the behavior of operations and whether the results are exact or inexact.

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

[Jeremy Erwin]

irrational numbers aren't periodic.

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

[DragonWriter]

But 754r doesn't solve that, it simply mitigates it like anybody who understands the floating point problem already does. It cannot actually solve the problem, because ALL calculations done on a computer are done in binarey - there is no way around it.

Uh, sure there is. Any calculation done on a binary digital computer, of course, has to consume inputs and produce results that can be represented in a binary format, to be sure, but that doesn't mean that they are "done in binary" in any meaningful sense.

That the conversion is made in the CPU (FPU more specifically) doesn't change the fact that a conversion must be made and the errors are carried over.

In order to support the decimal types and operations defined by IEEE 754-2008 (whether it is done in hardware, in software, or in a hybrid) a system cannot be converting into binary floating point representation, using binary floating point operations, and converting back into decimal floating point representation, and allowing conversion errors to propagate through that process, even under the hood -- it has to be producing the correct results as defined in the operations for each type, including those defined on decimal types.

This is also why decimal floating point software implementations are much, much slower than binary floating point hardware operations on systems which support the latter. If you could just convert the decimal operands to binary and use binary operations than convert the result back to the decimal representation, you would get a slowdown, but not the kind of "hundreds of times" slowdown you get when you have to implement the basic operations on the decimal representations in software.

The problem that some people have with doing this is it hides the problem, instead of accentuates it. Now even fewer programmers, especially new programmers, are aware there is a problem. They will simply think "I'm not ever converting out of decimal, so these calculations will always be correct" instead of being aware of the fact that the processor is simply doing some binary>decimal error mitigation for you, and problems can and will still crop up.

Decimalbinary conversion errors cannot, by definition, show up in a correct IEEE 754-2008 implementation when only decimal (or only binary, for that matter) values are involved in the operation.

There are, of course, sources of compounding error in floating point operations (particularly sequences of such operations) besides base conversion issues, which are well understood and which remain in IEEE 754-2008. (Some of them can be avoided in practice by having bigger floating point representations of the same base, which is another area of change in IEEE 754-2008.)

It isn't even floating point any more, it's decimal

Decimal or binary refer to bases, which are orthogonal to whether the representation is a floating point one. IEEE 754-2008 defines both binary and decimal floating point representations.

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

[roemcke]

In C I need to turn these warnings off. In perhaps 99% of the cases where the test is something like "x == 1.0" what is being tested is not "did the calculation result in 1". Instead the test that is really being done is "was the earlier statement that read x = 1.0 executed".

But what if the calculation did result in 1? Better to use a flag, or if you don't want to use a flag: x = -1.0 and test for x < 0.0 (assuming the calculation will always return positive numbers). Or even better: x=Nan, this has the nice effect that you can't use x in calculations unless it has been initialized.

Now, since Scheme (and ECMAScript) is dynamically typed, you are not restricted to use floating point numbers as magic markers in variables that normally hold floating point numbers. So doing what you proposed in those languages is both unnecessary and counter-intuitive.

Unfortunatly these warnings are unable to distinguish why the test is being done, and it makes programmers do some stupid things to turn off the warnings.

If you turn off warnings, at least you were warned when thing breaks. That is better than having things that break and a lot of programmers doesn't understand why.

Changing it to some approximatly_equal() function will actually break the logic, especially for a calculation that CANNOT result in 1.0 except by the direct assignment. This is NOT uncommon!

I agree, implementing an approximatly_equal() function is in many cases totally moronic, and mostly done when float/double is the wrong datatype to use.

Luckily, Scheme has a datatype called "exact" that can hold fractional values, can do arithmetic without rounding errors, and comparisons for equality do make sense. This can be used most places where float or double is wrongly used now, and is why I used Scheme as an example of how things can be done right.

So stop proposing ideas without actually seeing how things are done in the real world.

I have seen a lot of things done in the real world, both good and bad. That is why I propose ideas

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

[Anonymous Coward]

Do you know what the difference between a natural number, an integral number, a rational number a real number and an irrational number is? E.g. the rational number 1/3 is not perfectly describeable as a base 10 real number (0.333333333_). There are plenty (hm, I wonder if it are "finite" ;D) base ten real numbers that can't be expressed as base 2 real numbers, one example: 0.2. It yields an periodic irrational number in base 2.

You should learn the definition of an irrational number yourself. From the definition of a rational number, you get that real number is rational if and only if any radix representation of it is finite or periodic. Whether a number is rational or irrational does not depend on the radix representation at all. You're essentially saying that that 0.2 is rational and irrational, which is nonsense.

Of course, the point you were trying to make is correct (in one base, the radix representation of some rational number is finite, in others it's infinitely periodic), but 0.2 is most definitely not irrational.

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

[WraithKenny]

I've often wished the opposite, that more people learn to "do maths and logics"

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

[spitzak]

I did not describe the problem all that well.

In the cases I mostly run into, the test is to update a GUI to match buttons the user pushed. The value 1.0 is actually mathematically correct and works when used, so replacing it with some other value or a non-numeric would break the code. What is wanted is a reliable test that says "the user pushed the 'set to 1.0' button and we should highlight it". Things like that. I can assure you that if you use approximately-equal or try to track this value in a parallel variable things break and become unreliable.

What I would like to see is the compiler produce a warning only if the value being compared to is not a constant that can be exactly represented. So "x == y" might produce a warning, and even "x == .1". But "x == 1.0" does not produce a warning. I don't like the fact that I have to turn off an otherwise useful warning because they don't understand how real software is written.

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

[roemcke]

I can understand that so far as the internal (within the interpreter) representation, but it certainly needs to specify the behavior of numeric data types, which is most of either the 1985 or the 2008 version of IEEE 754 specifies.

Agree, as long as the behavior doesn't force a specific implementation and it is a sane behavior.

While I agree with you that Scheme's numeric tower is a good basic approach to a numeric type system your description of Scheme's numeric system as having only two types, "exact" and "inexact", is incorrect. The Scheme specification (both R5RS and R6RS) specifies a nested tower of 5 types (number, complex, real, rational, and integer). Exactness is an attribute that a numeric value -- of any of the 5 types -- can have.

I am aware of that, but sometimes you have to simplify things to make them fit in a slashdot comment :-)

Further, that doesn't address the issue of behavior, only that of representation.

Huh? Exact/Inexact is all about behavior ??

Actually, there is a lot more that a programmer may care about, such as how data that has to be rounded to fit into the representation used is treated, and what control they have over how that is done. That's a behavior feature that is specified by a floating point spec, and its a point of difference between the different versions of IEEE 754 (since the 2008 version has an additional rounding mode.) They also care about what values can be represented exactly, since that affects the behavior of operations and whether the results are exact or inexact.

And that is why Scheme is a good specification. Very few programmers have read the IEE754(r) specifications and understand when and how numbers are rounded or are even aware that rounding is taking place.

On the other hand the Scheme specification is simple to understand, and will give you very few surprises. Any integer or rational number can be represented exactly, and by sticking to "exact" functions, the results will also be exact. No need to care about how rounding is done, because there is none. Rounding of exact numbers will only take place when explicitly told so, in a way chosen by the programmer. When working with inexact numbers, only an implementation-specific precision is guarantied.

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

[DragonWriter]

Exact/Inexact is all about behavior ??

No, exact or inexact is an attribute of a data value.

(Under what conditions an operation returns an exact or inexact value is part of its behavior, but far from the only important area of behavior a specification is likely to be concerned with.)

Very few programmers have read the IEE754(r) specifications and understand when and how numbers are rounded or are even aware that rounding is taking place.

I think most programmers -- whether or not they have read the IEEE 754-2008 spec -- are aware that rounding takes place with floating point numbers.

On the other hand the Scheme specification is simple to understand, and will give you very few surprises. Any integer or rational number can be represented exactly, and by sticking to "exact" functions, the results will also be exact. No need to care about how rounding is done, because there is none.

There are very few languages where rounding would be done on integers (or rationals, if the language supports them in the first place) with exact operations.

Of course, Scheme is less specific than IEEE 754 when it comes to the behavior of inexact operations, so an implementation is more likely to surprise even a diligent programmer who knows the spec for the language.

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

[roemcke]

I did not describe the problem all that well.

In the cases I mostly run into, the test is to update a GUI to match buttons the user pushed. The value 1.0 is actually mathematically correct and works when used, so replacing it with some other value or a non-numeric would break the code. What is wanted is a reliable test that says "the user pushed the 'set to 1.0' button and we should highlight it". Things like that. I can assure you that if you use approximately-equal or try to track this value in a parallel variable things break and become unreliable.

Then, in my opinion, you should define a compound variable "struct {x, highlight};" with a public interface that sets x and keeps track of the highlight flag. Using magic numbers in variables that normally hold scalar values is a documentation nightmare.

What I would like to see is the compiler produce a warning only if the value being compared to is not a constant that can be exactly represented. So "x == y" might produce a warning, and even "x == .1". But "x == 1.0" does not produce a warning.

But how can the compiler know that you are not comparing 1.0 to something that you think is exactly 1.0 but is only almost 1.0?

In Scheme you would be able to do this, it is still ugly code though:

(set! x 0.9) ; Not magic number, a float
(set! x 1) ; Magic number, not a float

(and (exact x) ; Test for magic number
      (= x 1)) ; without doing comparisons between floats

I don't like the fact that I have to turn off an otherwise useful warning because they don't understand how real software is written.

It is my impression that most warnings are there because they do know how real software is written

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

[roemcke]

Exact/Inexact is all about behavior ??

No, exact or inexact is an attribute of a data value.

(Under what conditions an operation returns an exact or inexact value is part of its behavior, but far from the only important area of behavior a specification is likely to be concerned with.)

Yes, "exactly"

I think most programmers -- whether or not they have read the IEEE 754-2008 spec -- are aware that rounding takes place with floating point numbers.

A lot of them do, but far from everybody. I have seen a lot of abuse of floating point numbers. People using floats as array indexes, monetary values or using the exponential function for bit-shifting (Ughh..)

There are very few languages where rounding would be done on integers (or rationals, if the language supports them in the first place) with exact operations.

Yes, and Scheme do support exact rationals. And if Scheme can do do it then i think ECMAScript should do it. It is in my opinion the best way to solve the 0.1+0.2 != 0.3 problem

Of course, Scheme is less specific than IEEE 754 when it comes to the behavior of inexact operations, so an implementation is more likely to surprise even a diligent programmer who knows the spec for the language.

Maybe, but when using inexact numbers and operations in Scheme, it is obvious to any programmers that there might be surprises. So by definition, any surprise is not a surprise. Luckily you have exact numbers and operations that can handle numbers with fractional parts, so inexacts aren't really needed for most programmers.

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

[roemcke]

Just some added comment...

Of course, Scheme is less specific than IEEE 754 when it comes to the behavior of inexact operations, so an implementation is more likely to surprise even a diligent programmer who knows the spec for the language.

That is the whole point.. By being less specific than IEEE 754 on the behavior of inexact operations, Scheme can run efficiently on CPUs with a different floating point implementation.

I am sure the IEEE 754 is a fine standard, I have only read part of it and it was a long time ago so I don't remember much, but those thing I do remember were mostly good.
Implementors of compilers and interpreters need to know how inexact operations behave on the CPU. So if IEEE 754 define every detail of those operations, and CPU manufacturers implement IEEE754, then that is a good thing.

On the other hand, most users of high level langages, like Scheme and ECMAScript, doesn't care if the behaviors of inexact operations are predictable according to a specification they have never read. They want the operations to be exact in a predictable manner, for any number they might type on the keyboard, just like Scheme does, and ECMAScript currently doesn't

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

[spitzak]

I'm still failing to describe the problem.

What I want to test is "will hitting the set to 1.0 button do something". This can ONLY be done by checking if the value is equal to the value that the 1.0 button will set it to.

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

[roemcke]

All I understand is that you want x=1.0 to mean two things: "the value is 1.0" and "The button has been pressed". In c you can not this without comparing two floating point numbers with each other.

In a dynamically typed language you can do it the way you want with this pseudo-code (in case you didn't understand my scheme example):

void push_button()
{
    x = 1; // x is now an integer
}

bool test_for_buttonpress()
{
    if (! is_integer(x))
        return false;
    if ( x == 1)
        return true;
    else
        return false;
}

The x==1 in the above example never compares two floating point values with each other, even if x is sometimes set to a floating point value.

That is why i don't think the equality operator for floats is necessary in a dynamically typed language.

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

[DragonWriter]

Yes, and Scheme do support exact rationals. And if Scheme can do do it then i think ECMAScript should do it. It is in my opinion the best way to solve the 0.1+0.2 != 0.3 problem

On this much, we agree. Particularly if constants are exact by default and conversion down the numeric tower is automatic.

Maybe, but when using inexact numbers and operations in Scheme, it is obvious to any programmers that there might be surprises.

Making it obvious where surprises can occur is better than obscuring it; having well-defined behavior that assures that applications will run consistently on compliant implementations, OTOH, is better yet. And consistency is, I would say, more important for ECMAScript than Scheme, given that how much of the use of ECMAScript centers around the ability to use it as a CPU/OS agnostic client-side scripting language for web-based client-server applications.

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

[spitzak]

I see your point. I was only arguing for a static typed language such as C++. In my experience, attempts to duplicate dyanmic typing (such as replacing the float with a structure having the float and a flag) cause bugs because there is no low-level code insuring the two values match each other. When this goes wrong it can be really hard to debug because other code and the programmer themselves may assume it is impossible.

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

[Gospodin]

Will these be accessible from ECMAScript? And will most programmers use them correctly?

If it's an implementation of 754r, then the answer to the first question is yes. As to the second, obviously I can't say.

Exactly, and that is why i think 754r is a stupid hack. Depending on it makes implementations more complicated without solving the problem it is set out to solve: Programmers that haven't done their homework.

With all due respect, 754r is not a stupid hack. It's a well-thought-out way to handle an exact datatype. From your other comment you seem to think having an exact datatype is useful, but perhaps you haven't thought through all the implications of that. (For example: take the exact number "1" and divide it by the exact number "3". What's the result? In 754r, it will be "1.33333" with some number of 3s, and will be flagged as being "rounded" and "inexact". So at least the programmer knows the number is no longer exact. Arbitrary-precision computations don't solve this problem.) 754r may not be perfect, but at least it's an effort to work through all the implications.

That said, including 754r in ECMAScript probably is stupid. It's pretty complicated, and wouldn't see all that much use. If it's really needed, code it up as an add-on library. (And provide ECMAScript with an easier way to handle... add-on libraries. Which I understand they're working on.)

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

[Hurricane78]

The thing is: I worked in that business since 2000, and I have yet to see someone actually use JS on the server side. We just use Java, PHP, and maybe some CGIs.

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

[aled]

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

This remembers me of this joke:

-Quick, answer this: 2+2?
-3
-This is wrong!
-What did you want? Quickness or precision?

The thing is a fast result with the wrong answer may not be what the user wants. Think of money transactions and floating point operations **SHUDDERS**

Will this allow us a FOSS alternative to Flash?

[AP31R0N]

Will this allow us a FOSS (competitive) alternative to Flash?

Because that would be sweet.

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

[nyctopterus]

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

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

[Anonymous Coward]

The real problem is that SVG animation is still way too slow.

The current SVG implementations all took the approach of "get something done now, optimize later" and we're still paying for it. Same thing happened with Ruby, they put off optimizing because they "could do that later"... Yeah, guess what, it's a decade later and the performance still sucks ass.

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:Will this allow us a FOSS alternative to Flash?

[Anonymous Coward]

"In other words, we need GNU Ecmas."

Not to be confused with GNU Xmas.

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

[AP31R0N]

Could someone 'splain why i was modded down? It's a legit question and not even snarky in its wording.

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

[Anonymous Coward]

When you have strict regulatory rules about how rounding must be done, and your numerical system can't even represent 0.2 exactly, then ...

.. don't use javascript.

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

[Anonymous Coward]

It's still phenomenally stupid to make JAVASCRIPT of all languages use a slower and less precise (!) number format because somebody may want to do financial calculations and doesn't understand floating point math enough to use fixed point math for that purpose.

Re:Financial Calculations

[MunkieLife]

Who in their right mind would use javascript for financial calculations that need to be relied on?

Re:Financial Calculations

[MunkieLife]

Doesn't everyone know not to use floating point numbers for financial calculations? Or at least understand the limitations or faults associated with them...

Re:Financial Calculations

[DragonWriter]

Doesn't everyone know not to use floating point numbers for financial calculations? Or at least understand the limitations or faults associated with them...

Financial calculations that involve more than addition, subtraction, and multiplication by integer values -- which there are a lot of -- require the use something other than integer math. But, yeah, most people understand the pitfalls, which is why the newer standard exists to address them.

Re:Financial Calculations

[DragonWriter]

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! ;)

Using IEEE decimal floating point is also safer, and involves less conversion and better control of rounding when you have to do operations that can't be done with pure integer math. Like, you know, anything involving percentages.

Financial calculations involve more than just tracking deposits and withdrawals of amounts given in dollars-and-cents or the equivalent.

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?

Re:Financial Calculations

[ToasterMonkey]

Who in their right mind would use javascript for financial calculations that need to be relied on?

Nobody will, now. Is this a good or bad artificial limitation? What's the latest groupthink on this, I'm out of sync with the collective.

Re:Financial Calculations

[Hurricane78]

Tell that to Verizon. ^^

Re:Financial Calculations

[iluvcapra]

If you're doing percentages and ratios, and you do genuinely care about the rounding, you'd be much safer doing it with modular arithmetic than with floats.

Re:Financial Calculations

[aled]

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?

almost everyone given that few understand or care about those... until they bite them

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.

Floating point numbers and decimals

[bradley13]

Floating point numbers are a mess if you want to deal with currencies - rounding errors are guaranteed.

That said, look at IBM's 754r standard: unpacking a 128-bit number in chunks of 10-bits? That's got to be the ugliest thing I've seen in a long, long time. A triple-bagger. Implementing that in software will be painfully slow - implementing it in hardware will be a gigantic kludge of dedicated circuitry.

This is an area where ECMAscript pays the price for not being a strongly typed language. The only solution in the ECMAscript framework is to use a decimal library. Awkward, but that's life.

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

[aztracker1]

I fail to see how being loosely typed means that support for higher precision numbers is any uglier than in a strongly typed language. Simply adding a new up for a Decimal type that gave a stronger precision number internally, or had an extra notation for a strong number's initialization could work. IIRC, Python has a pretty decent numerics.

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:Floating point numbers and decimals

[Anonymous Coward]

Because you get a mixture of demical and binary numbers without any clarity.

Re:Floating point numbers and decimals

[DragonWriter]

I fail to see how being loosely typed means that support for higher precision numbers is any uglier than in a strongly typed language.

In fact, I think Scheme demonstrates pretty effectively that being dynamically typed (which, not loose typing, is what JavaScript is) is entirely compatible with having an extraordinarily elegant system of numeric representation which seamless scales from exact integer representation through exact rational representation through to inexact representations.

Re:Floating point numbers and decimals

[Anonymous Coward]

"Pedantic."

Re:Floating point numbers and decimals

[Anonymous Coward]

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

Any???

Re:Floating point numbers and decimals

[DamonHD]

Goedel-script, but it's never gonna get finished, well not consistently and completely...

Rgds

Damon

Re:Floating point numbers and decimals

[Anonymous Coward]

I read that as 'eros' and thought about Floats getting frisky with Doubles.

Re:Floating point numbers and decimals

[Anonymous Coward]

Every chunk of 10 bits corresponds to 3 decimal digits, that's actually quite optimal. Using 1000 out of 1024 possibilities, it's a very dense representation and hardware implementations (Power) are reasonably fast. And with 34 decimal digits of precision (in the 128 bit format), you can represent US public debt down to the cent with room to spare.

Don't forget that financial computations do not need as many operations as image processing, you don't need to compute several of them for every pixel on the display, and decimal representation gives you the right precision and saves a lot on decimalbinary conversion for display (libc's routines to convert between ASCII and IEEE-754 binary FP are over 1000 lines long, and calls external functions for multi-precision arithmetic.
In financial computations, you typically have to display every step, so the conversion routines to human readable form are often the dominant computation cost. Converting from IEEE-754r to a string is trivial, and ends up saving CPU time and power.

Re:Floating point numbers and decimals

[steveha]

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

I feel your pain. I'm a Python fan and I'm always quick to remind people that Python is in fact strongly typed, but not statically.

However, in this case, I wonder why you picked the nit, because Javascript is in fact weakly typed.

"1234" * 1 is a legal expression, which evaluates to 1234. That's pretty weak if you ask me.

steveha

Re:Floating point numbers and decimals

[mdmkolbe]

However, in this case, I wonder why you picked the nit, because Javascript is in fact weakly typed.

Meh, I would say that it just has automatic coercion. Soundness is still preserved.

Unfortunately on the strongly vs. weakly typed scale there are several different stopping points so one man's strong is another man's weak (e.g. to a Haskell or ML programmer, both Python's and Perl's type systems are fairly weak). It also doesn't help that strong vs. weak is use to refer both to the level of sophistication and to whether it is possible to violate soundness.

Re:Floating point numbers and decimals

[SolitaryMan]

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

Freud?

Context

[Anonymous Coward]

What the fuck is ECMAScript?

Re:Context

[revlayle]

formal name of JavaScript - now turn in your geek card

Re:Context

[rubycodez]

not quite, the various javascript,Ejscript,ActionScript are dialects of it, which means it has significant variations from the standard.

does anthing use the real ECMAScript.

also, geek card not required, language is a pathetic throwback to 1980s c++ type language.

Re:Context

[Anonymous Coward]

'tis based on scheme, is it not?

Re:Context

[badkarmadayaccount]

Now turn in yours. JS takes concepts from Self and Lisp, not C++.

Re:Context

[rubycodez]

no, it doesn't take any *useful* concepts from either of those languages. It's merely a weakly typed semi-OO (all objects are associative array, ew) langauge with a truly crappy implementation of closures as inner functions.

Re:Context

[badkarmadayaccount]

Oh, and what is your idea for an object implementation? And do you have a better idea for closures?

Calculations in cents

[tepples]

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.

The numerical system in use at my employer includes a fixed-point representation of money. All money values are assumed to be fractions with a denominator of exactly 100.

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.

Re:Calculations in cents

[spud603]

umm... nevermind.

Re:Calculations in cents

[Anonymous Coward]

WHOOSH

Re:Calculations in cents

[mpilsbury]

How would this work if you needed to localise your application to handle some of the Middle Eastern currencies that use 1000 sub-units instead of 100?

Re:Calculations in cents

[Bigjeff5]

Assume all values are fractions with a denominator of 1000?

Any other notable changes?

[Anonymous Coward]

Folks it took 10 years and the only thing people talk about is JSON!
No namespaces, no concurrency, nothing?
Isn't it too little for 10 years?

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.

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.

Re:Floating point representation

[jackjansen]

Python's new way of representing floating point numbers is only a partial solution. The bigger problem is accumulation of errors. To see this: add 10 copies of the number "1.1". Now subtract 11. The result will be tiny, but non-zero (-1.8e-15, on my machine). This is a much more serious problem than the 10.99999999999999998 representation problem.

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:Still no O(1) data structure

[olau]

Why not just make the interpreter a bit smarter? I think Firefox's array implementation will use a continuous array unless you try to use it in an associative fashion.

Also when you're talking about pixels, you need to know the type of each element so you can put the elements themselves (and not pointers to them) next to each other in the array to get anywhere near compiled C code speed. How can you do that without either a smarter interpreter or some kind of type system where you specify it explicit? If you're going to make the interpreter smarter, you might as well try to reuse the existing array syntax. :)

By the way, strictly speaking the built-in array is actually O(1) amortized as far as I know and a continuous array is also only O(1) amortized if you want to be able to add elements dynamically. But sure, hash lookup is slower than indexing.

Re:Still no O(1) data structure

[Anonymous Coward]

While it's not guaranteed by the spec, I highly doubt you'll find any modern implementation for which Array objects
with dense indices do not use an array backing store.

Re:Still no O(1) data structure

[TheCycoONE]

Even JScript (in IE8) is smart enough to internally choose between a data structure optimized for dense or sparse data. See: http://blogs.msdn.com/jscript/archive/2008/03/25/performance-optimization-of-arrays-part-i.aspx

Re:Still no O(1) data structure

[KnownIssues]

When I read this, I wondered, "what does this have to do with floating point math?", and then I realized ECMAScript was the original topic.

You can't do it server side in PHP either

[bigtrike]

PHP doesn't have a built in fixed point type either, yet many programmers use it for financial calculations and simply round to 2 decimal places when it's time to display. Sure, you can use the bcmath extension (about as easily as writing your own fixed point math code in javascript), but very few people do.