Follow Slashdot stories on Twitter


Forgot your password?
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Programming IBM Mozilla The Internet Technology

ECMAScript Version 5 Approved 158

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.")
This discussion has been archived. No new comments can be posted.

ECMAScript Version 5 Approved

Comments Filter:
  • by tjwhaynes ( 114792 ) on Tuesday December 08, 2009 @11:31AM (#30365704)

    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.

    Toby Haynes

  • by TrancePhreak ( 576593 ) on Tuesday December 08, 2009 @11:40AM (#30365858)
    It doesn't seem like any of the ARM based procs support IEEE 754r.
  • by systembug ( 172239 ) on Tuesday December 08, 2009 @11:45AM (#30365928) Homepage

    (...) 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 "'s literally hundreds of times slower than the current format.".

  • by Anonymous Coward on Tuesday December 08, 2009 @11:52AM (#30366022)
    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.
  • by tjwhaynes ( 114792 ) on Tuesday December 08, 2009 @12:04PM (#30366200)

    (...) 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 "'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.

    Toby Haynes

  • Re:JSON is in!? (Score:5, Informative)

    by amicusNYCL ( 1538833 ) on Tuesday December 08, 2009 @12:11PM (#30366318)

    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.

  • by mdmkolbe ( 944892 ) on Tuesday December 08, 2009 @12:32PM (#30366648)

    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.

  • by BZ ( 40346 ) on Tuesday December 08, 2009 @12:43PM (#30366770)

    > ECMAScript is client side,

    You may be interested in []

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

  • by Gospodin ( 547743 ) on Tuesday December 08, 2009 @02:28PM (#30368174)

    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.

  • by Anonymous Coward on Tuesday December 08, 2009 @06:07PM (#30371106)

    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.

  • by DragonWriter ( 970822 ) on Tuesday December 08, 2009 @06:32PM (#30371414)

    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.

This restaurant was advertising breakfast any time. So I ordered french toast in the renaissance. - Steven Wright, comedian