Weird problem ( 3 * 31.9 = 95.69999999999999)

[Dag Sunde]

What thing that is very confusing to me is the relation between W3C and
ECMA. Is ECMA the standard for Javascript? I see things like W3C
telling me that I should not use "<script language="javascript"> and
rather use <script type="text/javascript"> (which will be depracated
and replaced by <script type="application/javascript"> but ECMA tells
me the opposite, emphasizing on version numbers (<script
language="javascript1.2">) as being important for defining which
version of the language is supported.

Its a matter on who's responsible for what.

The <script> tag is an HTML tag and belong as such to W3C.
The 'content' of the script-tag (if its type-attribute is set to
"application/javascript") is written in JavaScript, and belongs
to ECMA's domain.

One thing people need to understand is that there wouldn't be any group
like this particular group if everyone read and understood the
javascript language. It is not simple, there are numerous books and
references and websites about it and it is still a language in the
works, with multiple versions, conflicting standards, etc. Asking a
question and not knowing the complete history & different
implementations about javascript is not a crime.

This is very true. I wouldn't put too much weight on the at times
harsh replies newbies get. Some of those replies are actually well
meant. Others are kind of a "Power Show", and can safely be ignored.

Snip things that is out of context, and reply at the bottom of the post,
Or inline if it falls natural in the context.
Be polite, even if others aren't.
Mark flippant comments with some kind of smiley, so people can see the
"mood".

These simple guidelines work for me, and I have not been flamed yet... ;-)

 

[Thomas 'PointedEars' Lahn]

ECMAScript is the standard JavaScript 1.5+ and JScript are based on. ECMA
(European Computer Manufacturers Association) is the standardization body
that published that standard.

No, they refer to the respective Internet Draft by Björn Höhrmann which
has been approved as Informational RFC (Request for Comments) by the IETF
(Internet Engineering Task Force), another standardization body.

The former will not be deprecated by the latter but is registered and
marked in the standards tree as _obsolete_ now (since June 2005).

I would like to see proof for that statement.

Its a matter on who's responsible for what.

The <script> tag is an HTML tag and belong as such to W3C.
The 'content' of the script-tag (if its type-attribute is set to
"application/javascript") is written in JavaScript, and belongs
to ECMA's domain.

That is not entirely true.

1. The `script' _element_ (which consists of its start tag, content
and end tag) is specified by the W3C (HTML and XHTML specifications).

2. The content (no need for quotes) of the `script' element, if its
`type' attribute is set to `application/javascript', is _JavaScript_
code and as such belongs to the domain of the Mozilla Organization,
since Netscape (after the AOL/TW takeover) no longer takes care
on the language. (See for example JavaScript 1.6 implemented in
Mozilla/5.0 since release version 1.8.)

The second statement above would have been correct if it referred
to the MIME type `application/ecmascript'.


PointedEars

 

[Richard Cornford]

One of urban legends originally raised from the bad math /
CS skills of some ECMA time-share paper wasters
(aka tech-writers).

Windows / Mac / Linux and Co are 32-bit systems - 64 bit
systems are still rather new bists on the market.

LOL. Criticising the CS skills of others and then posting that
irrelevance in the following sentence?

If the interpreter spots a new number, it will first try reading
the number as an integer. If that's possible, then it stores the
number as a 31 bit integer, not as a 64 bit IEEE 754. (Yes,
that's 31 bits, not 32 bits.) If the number cant be read as an
integer or it won't fit in 31 bits, then it is stored in 64 bit
IEEE 754. Similar logic applies to all calculations.

You have previously made it clear that you are a spectacularly bad
programmer. That you think this is even likely reinforces that
impression. You certainly have no evidence (empirical or in
documentation) that will support this nonsense.

Richard.

 

[VK]

You have previously made it clear that you are a spectacularly bad
programmer. That you think this is even likely reinforces that
impression. You certainly have no evidence (empirical or in
documentation) that will support this nonsense.

"Three Number Formats: JavaScript Number Implementation"
<http://www.devx.com/webdev/Article/17215/0/page/3>

"Four Values: Warning Numbers You Need to Know"
<http://www.devx.com/webdev/Article/17215/0/page/4>

Don't ask me why should you take the author as an authority. You should
not! But both articles give you enough of data to conduct your own
experiments to prove it or to dismiss it. I did experiment and I got a
prove, but my testcases are not reliable because they are mine, are
they? So why would you not make your own then? Besides it would show
what kind of programmer *you* are.

Oh, sorry... You already stated several times that empiric results are
not reliable in any shell perform form.
Keep reading then ECMA (Book Of Definitions, Chapter 4.3.20) and simply
don't think about facts.

As Dag Sunde suggests - a nice smily at the end:

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Mon, 14
Nov 2005 22:41:46, seen in Richard Cornford

"Javascript only has one number type and that is a double-precision
64-bit format IEEE 754 floating point number. That type of number is
capable of representing 18437736874454810627

ISTM better to indicate how that is arrived at. For example, it's
clearly 1 + 2 * (Z+1) where the first 1 is for a large number of
distinct but indistinguishable NaNs, the second 1 is for the infinities,
the 2 is for the sign bit, and Z is the number of non-negative finite
numbers, including a zero.

distinct values including
positive and negative infinity and the special numeric value NaN (Not a
Number). The representable range is +/-1.7976931348623157×10^308 (with
numbers as small as +/-5×10^-324). The range of precise integer values
is +/-9007199254740992 (+/-2^53).

Well the range is that, but the count is actually that + 1, since there
are two distinct zeroes which are equal for only most purposes.

ISTM better to put it as "all integer values in 0 to 9007199254740992
(2^53), with either sign, are represented exactly". Outside that range,
only some are.

That leaves 18419722475945328643
values to represent non-integers and integers outside of that range, and
obviously there are considerably more numbers in the IEEE 754 range than
can be represented by the available distinct values.

ISTM that there are 2^52-1 distinct but indistinguishable NaNs of each
sign, and two Infinities; and 2 * 2^11-1 * 2^52 other Numbers, all
distinguishably different though +0 & -0 are less different than any
other pair.


ISTM worth observing, nearby, that the only decimal fractions which are
represented exactly are the multiples of 1/2, 1/4, 1/8, 1/16, ... down
to a limit depending on the number of bits needed for the integer part;
for example, the only exact numbers of the form ###.## ate ###.00,
###.25. ###/50. & ###.75 .

 

[Dag Sunde]

it looks correct to me.

in binary. 1/5 is like 1/3
(0.33333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333...)
in binary you can't 1/5 with a binary point and a finite number of digits.

as a result numbers like that don't work perfectly in computerso
just lik many calculators will give 0.99999999 for 1/3*3 ...

Bad example... :-D

1/5 = 0.2, which is easily expressable as a power of 2...

 

[Lasse Reichstein Nielsen]

I thought it was two to the power of fifty three (9007199254740992), but
what is a bit here or there?

It is. I was remembering that 53 bits can only represent up to 2^53-1,
but 64 bit floats (with their 53 bit mantissa) can actually represent
up to 2^53. I then overcompensated

....

As a result some numeric values are represented as approximations. For
example, the largest integer value that can be entered in source code
without its IEEE 754 representation being returned in exponential format
when converted to a string is 999999999999999934469,

The highest I can get without getting 1e+21 is 999999999999999934463
(Opera 8.5). Generally, this text throws around a lot of, and perhaps
too many, long numbers. It feels mostly like "drama digits"

/L

 

[Lasse Reichstein Nielsen]

One of urban legends originally raised from the bad math / CS skills of
some ECMA time-share paper wasters (aka tech-writers).

That depends on what you mean by "Javascript". It is not ECMAScript,
because that's a specification of a language, not an implementation.
The specification only specifies one number type, the 64 bit IEEE 754
floating point number.

If the interpreter spots a new number,

You are saying *the* interpreter. There are lots of interpreters for
languages called "Javascript" and compatible with the ECMAScript
specification. Some of these implementations might do what you say.
Others surely don't (or I'll write one that doesn't .

it will first try reading the number as an integer. If that's
possible, then it stores the number as a 31 bit integer, not as a 64
bit IEEE 754.

That could be one optimization that an ECMAScript compatible
implementation could do.

/L

 

[Eric Kenneth Bustad]

Bad example... :-D

1/5 = 0.2, which is easily expressable as a power of 2...

No it isn't.

0.2 decimal = 0.00110011001100110011001100110011... binary.

See http://www.geocities.com/oosterwal/computer/dec2bin.html

 

[Thomas 'PointedEars' Lahn]

Bad example... :-D

IMHO the example was well chosen.

1/5 = 0.2, which is easily expressable as a power of 2...

It is not, see Eric's reply. You have confused

2*10^-1 = 2/10 = 1/5 = 0.2 = 2^-3 + 2^-4 + 2^-7 + 2^-8 + ...

with

2^-2 = 1/2^2 = 1/4 = 0.25


PointedEars

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Mon, 14 Nov 2005 21:59:21, seen in

One thing people need to understand is that there wouldn't be any group
like this particular group if everyone read and understood the
javascript language.

Untrue, even if we take that as including all varieties of the language
and of the DOM.

There is still the matter of producing algorithms - for example, if you
were writing a site for a hotelier, would you know how to determine the
date of Easter, the start and end of Summer Time, and the local time at
the hotel in code executing in a differently-located browser?

 

[Richard Cornford]

"Three Number Formats: JavaScript Number Implementation"
<http://www.devx.com/webdev/Article/17215/0/page/3>

You realise that if you search the Internet you can always find someone
claiming that almost any proposition is true. The ability to refer to
such an article doesn't make the proposition true.

This page asserts that "If the interpreter spots a new number, it will
first try reading the number as an integer. If that's possible, then it
stores the number as a 31 bit integer, not as a 64 bit IEEE 754", but
presents precisely nothing that differs from what would be expected if
all numbers were stored as IEEE 754 double precision floating point
numbers. Consequentially it makes an unsubstantiated claim and does
nothing else.

"Four Values: Warning Numbers You Need to Know"
<http://www.devx.com/webdev/Article/17215/0/page/4>

And here we find a page telling us how javascript stores RGB colors,
even though the language has no notation of what an RGB color is. So we
have a work by an author who doesn't understand what javascript is.

Don't ask me why should you take the author as an authority.

Because you never explain anything when asked?

You should not!

No I shouldn't.

But both articles give you enough of data to conduct
your own experiments to prove it or to dismiss it.

No they don't. The claim that javascript stores some numbers as an
integer type cannot be verified or dismissed based on any 'data' in the
article. The 'data' provided corresponds precisely with the results that
would be expected if javascript exclusively uses an IEE 754 double
precision floating point value for number storage.

I did experiment and I got a prove,

It is unlikely that whatever you perceive to be 'a prove' is anything of
the sort. If it were you would not be wasting my time referring to the
pages above, instead you could just post your 'prove' and make a real
point, Or, more likely, give someone the opportunity to explain why your
interpretation is incorrect.

but my testcases are not reliable because they are mine,

You have a long history of misconceiving even the simplest things so you
shouldn't expect anyone sane to take your word on anything.

are they?

Post them and find out.

So why would you not make your own then?

My own what? When you are referring me to a page that demonstrates
javascript behaving as if its only numeric type is an IEEE 754 double
precision floating point value in an effort to convince me that
javascript uses integer types for number storage there is not much point
in my posting code that demonstrates javascript behaving as if its only
numeric type was a double precision float.

Let's be clear about this; a demonstration that javascript uses an
integer type for numeric storage consists of code that exhibits
behaviour, or produces and outcome, that would be expected if it did use
an integer type for number storage, and would be impossible if it
exclusively used a double precision floating point.

Show that and you have made your point, I won't be holding my breath

Besides it would
show what kind of programmer *you* are.

Oh, sorry... You already stated several times that empiric
results are not reliable in any shell perform form.

I said nothing of the sort. Not least because that is so incoherent that
I have no idea what it is supposed to mean. I have pointed out that you
cannot draw valid conclusions about one thing by measuring another, but
you were unimpressed with that notion.

Keep reading then ECMA (Book Of Definitions, Chapter
4.3.20) and simply don't think about facts.

You never present any facts. You seem to think that making bizarre
assertions and then following them with code demonstrating javascript
behaving exactly as it should represent facts of some sort, but as you
never explain what you are talking about it is not even possible to work
out what these supposed 'facts' are even related to.

As Dag Sunde suggests - a nice smily at the end:

Hmm... I suppose one explanation for you habit of posting fictional
assertions to a technical newsgroup would be as a strange practical
joke. But there won't be many finding it funny.

Richard.

 

[Richard Cornford]

Richard Cornford writes:

The highest I can get without getting 1e+21 is 999999999999999934463

I recall testing the values in IE and Mozilla. I was expecting the
results to be the raw output from the FPU in all cases, so should not
depend upon the browser, but rather the hardware.

(Opera 8.5). Generally, this text throws around a lot of,
and perhaps too many, long numbers. It feels mostly like
"drama digits"

You are probably right. I am certainly not satisfied with the text as it
is, which is probably why I am not finding it easy to carry on with it.
One the other hand some of the numbers are important, for example,
people should understand that the integer range is big but not as big as
some, and why some numbers have to be approximated.

Richard.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Mon, 14
Nov 2005 08:27:14, seen in Dag Sunde

Remember that there is a finite number of bits set aside
to store the fractional part of a calculation.

But that is 52 bits, and applies after the integer part is normalised
to 1; there's one sign bit, and 11 biased-exponent bits. Javascript
uses IEEE Doubles for numbers.

If you had 1 byte (8 bits) to store a floating point number
and you set aside 4 bits to hold the integer part and sign,
you'll have 4 bits left for the fraction:

That's not floating point, it's fixed point.

If we store 3.15, we get 100% accuracy

S | I I I . F F F F
0 | 0 1 1 . 1 1 1 1

Of a peculiar form, never used in practice.

I suggest that you look up hoe IEEE Doubles are formatted internally;
you can find it by way of one of the links in the newsgroup FAQ.

 

[Dag Sunde]

JRS: In article <[email protected]>, dated Mon, 14
Nov 2005 08:27:14, seen in Dag Sunde


But that is 52 bits, and applies after the integer part is normalised
to 1; there's one sign bit, and 11 biased-exponent bits. Javascript
uses IEEE Doubles for numbers.


That's not floating point, it's fixed point.


Of a peculiar form, never used in practice.

I suggest that you look up hoe IEEE Doubles are formatted internally;
you can find it by way of one of the links in the newsgroup FAQ.

It was *not* an attempt to describe IEEE Doubles, but an oversimplification
of rounding with a finite number of bits...

Guess I should have been more explicit...

:-O

 

[John W. Kennedy]

What thing that is very confusing to me is the relation between W3C and
ECMA. Is ECMA the standard for Javascript? I see things like W3C
telling me that I should not use "<script language="javascript"> and
rather use <script type="text/javascript"> (which will be depracated
and replaced by <script type="application/javascript"> but ECMA tells
me the opposite, emphasizing on version numbers (<script
language="javascript1.2">) as being important for defining which
version of the language is supported.

That question is not a JavaScript/ECMAScript question, but an (X)HTML
question, so W3C trumps ECMA. ECMAScript is the standard for the core
JavaScript language, which W3C does not attempt to define (although it
does define the Document Object Model (DOM) that JavaScript uses).

The SCRIPT tag is part of the HTML and XHTML languages, which W3C
defines and ECMA does not.

--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"