Weird problem ( 3 * 31.9 = 95.69999999999999)
baong
i have use this line to time in many my web base appl.
but now i found a weird problem
the javascript line is the same
but i use the calculation 2 time
@ the first time, it is ok, 3 * 31.9 = 95.7
@ the second time, 3 * 31.9 = 95.69999999999999
this is the list number which calculation is NOT correct
6 * 31.9 = 191.39999999999998
7
9
12
14
18
23
24
28
29
This is the line, i use to calculation
Qu = document.form1[it].value ;
Har = document.form1[it+1].value ;
Jum = Qu * Har ;
Thank u b4
Budi
matty
have 95.69999999999 all the time.
You are mixing floating point and integer, so floating point takes
precedence (you should do 3.0 * 31.9 to be syntaxically correct). So
all results that look like .999999 are actually the correct results as
well as the 95.7, it depends on your computer and the browser doing the
calculation. If you want rounding, you should use the Math.round()
function. Check http://www.javascriptkit.com/javatutors/round.shtml for
info on how to round numbers with the decimals you want !
kicken
> dear all
> i have use this line to time in many my web base appl.
> but now i found a weird problem
> the javascript line is the same
> but i use the calculation 2 time
> @ the first time, it is ok, 3 * 31.9 = 95.7
> @ the second time, 3 * 31.9 = 95.69999999999999
> this is the list number which calculation is NOT correct
> 6 * 31.9 = 191.39999999999998
Floating-point mathmatics isn't perfect in computers due to storage
limits (you can only have 1 bit, not .5 bits and such). There's a nice
long technically correct reason why this happens, but I forget where I
read it at, and don't remember all the details. Basically, just round
the result with Math.round() and be done with it.
Randy Webb
Please quote what you are replying to.
If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the
article headers.
Or, just read this groups FAQ, specifically section 4.7
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Randy Webb
Don't do math calculations with decimals and you don't have a problem to
start with.
baong
i think i will do math.round
but i still wondering why NOT every number
but only 3,6,7,9,12,14,18,23,24,28,29
any way thank you again
Budi
Dag Sunde
news:1131953648.9...@g44g2000cwa.googlegroups.com...
> thank you very much u all
>
> i think i will do math.round
> but i still wondering why NOT every number
> but only 3,6,7,9,12,14,18,23,24,28,29
>
Incidentally, those numbers leads to a fraction that
can't be represented as exact x^2.
Remember that there is a finite number of bits set aside
to store the fractional part of a calculation.
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:
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
but if we want to store 3.16, we have to round it, since
we can't store the value 16 in 4 bits. We have to round it
down to .15, or up to .2
0011.1111 or 0011.0010
--
Dag.
Randy Webb
Please quote what you are replying to.
If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the
article headers.
> thank you very much u all
>
> i think i will do math.round
You are better off not using decimals in multiplication/division
operations in javascript, then you don't have any problems at all.
Remove the decimal, do your multiplication/division, then add the
decimal back using String operations.
> but i still wondering why NOT every number
> but only 3,6,7,9,12,14,18,23,24,28,29
For the same reason the question in the FAQ gives the results it does.
Did you read it?
Robert
>
> If you want to post a followup via groups.google.com, don't use the
> "Reply" link at the bottom of the article. Click on "show options" at
> the top of the article, then click on the "Reply" at the bottom of the
> article headers.
Do you have some button that automatically inserts this text for you :p
Lasse Reichstein Nielsen
> You are mixing floating point and integer, so floating point takes
> precedence (you should do 3.0 * 31.9 to be syntaxically correct).
That must be an idea from another language.
In Javascript, all numbers are floating point numbers (more preciely
64 bit floating point numbers as defined in IEEE-754, the kind typically
implemented by the CPU as well). There is no difference between "3" and
"3.0" as a number literal.
The 64 bit floats can represent all integers up to 2^54 precisely, and
do exact integer arithmetic with them.
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
matty
See, I clicked on "show options" so I won't get slapped :)
So thanks Lasse, I learned something, I didn't know that all numbers
were floating point. I wouldn't have known if the poster had read the
FAQ and didn't post here :)
Thomas 'PointedEars' Lahn
> So thanks Lasse, I learned something, I didn't know that all numbers
> were floating point. I wouldn't have known if the poster had read the
> FAQ and didn't post here :)
Well, you could have read the respective FAQ section before posting as
well ...
PointedEars
Richard Cornford
> Lasse Reichstein Nielsen wrote:
>> "matty" <unlimi...@gmail.com> writes:
>> > You are mixing floating point and integer, so floating point
>> > takes precedence (you should do 3.0 * 31.9 to be syntaxically
>> > correct).
>>
>> That must be an idea from another language.
>> 64 bit floating point numbers as defined in IEEE-754, ... .
>> There is no difference between "3" and "3.0" as a
>> number literal.
>>
>> The 64 bit floats can represent all integers up to
>> 2^54 precisely, and
I thought it was two to the power of fifty three (9007199254740992), but
what is a bit here or there? (and maybe you mean the sign bit to be bit
54.) I have been working on this for the FAQ notes, but I have only got
as far as:-
"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 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). 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.
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, but its IEEE 754
representation is approximated as 999999999999999900000. Most
non-integer numbers are also represented as the closest approximation
possible."
>> do exact integer arithmetic with them.
>>
>> /L
>> --
>> Lasse Reichstein Nielsen - l...@hotpop.com
>> DHTML Death Colors:
>> <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
>> 'Faith without judgement merely degrades the spirit divine.'
>
> See, I clicked on "show options" so I won't get slapped :)
You might think that but ... you have failed to trim the material you
quoted down to just that part of it that is sufficient to provide
context for your response, as is required by Usenet convention. You have
also quoted a 'signature' which is always incorrect.
> So thanks Lasse, I learned something, I didn't know that all
> numbers were floating point. I wouldn't have known if the
> poster had read the FAQ and didn't post here :)
And it doesn't occurred to you that you would not have needed to wait
until someone asked the question if you have read the FAQ yourself.
Still there seem to be plenty of people who regard the risk of learning
something from it as grounds for not reading the FAQ. Are you one of
them?
Richard.
Randy Webb
It's automatically added for me, I just move it where I want it or
remove it all together when I don't want it :)
matty
number type and that is a double-precision
FAQ. I search for "64" and it was not there and not in the
http://www.jibbering.com/faq/faq_notes/type_convert.html link either
(which I did read).
"you have failed to trim the material you quoted down to just that part
of it that is sufficient to provide context for your response, as is
required by Usenet convention. You have also quoted a 'signature' which
is always incorrect."
I don't understand. I think that even if newbies make mistakes in the
way they post or reply, they should be rewarded for trying to help, and
given references on how to properly respond rather than getting
arrogant replies that just discourage people from being more active.
Also, I googled "usenet convention" and nothing really clear came up.
If this is refering to the Netiquette of 1998, be aware that we are in
2005 and that new tools, new ways of discussions have made the
newsgroups more accessible and more "affordable" for most of us. I will
try my best to figure that out and will accept all comments and help as
long as they don't violate the "convention" :)
Dr John Stockton
19:01:43, seen in news:comp.lang.javascript, Lasse Reichstein Nielsen
<l...@hotpop.com> posted :
>In Javascript, all numbers are floating point numbers (more preciely
>64 bit floating point numbers as defined in IEEE-754, the kind typically
>implemented by the CPU as well). There is no difference between "3" and
>"3.0" as a number literal.
>
>The 64 bit floats can represent all integers up to 2^54 precisely, and
>do exact integer arithmetic with them.
But Math.pow(2, 54) - 1 is even, as is Math.pow(2, 53) + 1 ;
you mean up to (and including) 2^53 (and down to include -2^53).
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Richard Cornford
> I read the FAQ. And there was no mention of "Javascript
> only has one number type and that is a double-precision
> 64-bit format IEEE 754 floating point number." as of 2
> days ago in the FAQ. I search for "64" and it was not
> there and not in the
> http://www.jibbering.com/faq/faq_notes/type_convert.html
> link either (which I did read).
The rate at which it is possible to create accurate additional
explanation/detail for the FAQ is related to the number of (suitably
qualified) people willing to do it, and the amount of time they have
available for the task. the task is much nearer its beginning than its
end.
> "you have failed to trim the material you quoted down to
> just that part of it that is sufficient to provide context
> for your response, as is required by Usenet convention. You
> have also quoted a 'signature' which is always incorrect."
And this time you have failed to provide a context for your first
response, failed to attribute they quote you have made and failed to use
a conventional quote indicator.
> I don't understand.
What don't you understand? That quoting material that is not pertinent
to the responses is undesirable? That signatures are almost always
irrelevant to a response? Or what a signature is?
> I think that even if newbies make mistakes in the
> way they post or reply,
They do, and those mistakes can have serious consequences for the
outcome of their interactions with the group. Generally everyone gets an
opportunity to demonstrate a willingness to conform with the
conventions.
> they should be rewarded for trying to help,
And discouraged from doing harm. Which is what anyone who fails to
follow the post formatting conventions is doing, particularly in
encouraging newcomers to do likewise.
> and given references on how to properly respond
And where would you expect to find that information? Maybe in (and/or
referenced from) some sort of resource publicly available on the
Internet, posted to the group at frequent interval and to which posters
are regularly referred?
> rather than getting arrogant replies that just
> discourage people from being more active.
It is difficult to accurately attribute motivation, attitude or emotion
from the contents of plain text messages. If you re-read the posts that
you believe to be arrogant can you really be certain that they are not
intended as friendly advice, hints in the right direction and justified
warnings (albeit often terse)?
> Also, I googled "usenet convention" and nothing really clear came up.
Why didn't you just read the FAQ when you had it avalable?
> If this is refering to the Netiquette of 1998, be aware that
> we are in 2005 and that new tools, new ways of discussions
> have made the newsgroups more accessible and more "affordable"
> for most of us.
The Usenet posting conventions evolved in response to diversity in
methods of access. Having even more diversity is, if anything grounds
for more strict adherence to the established conventions. The last thing
that should be allowed to happen to Usenet is to have it fragment into
sub groups using different types of newsreader software.
> I will try my best to figure that out and will accept all
> comments and help as long as they don't violate the "convention" :)
You don't need to work it out, the details are available in, and
through, the FAQ (that is one of the points of its existence).
Richard.
VK
Richard Cornford wrote:
> "Javascript only has one number type and that is a double-precision
> 64-bit format IEEE 754 floating point number.
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.
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.
RobG
> I read the FAQ. And there was no mention of "Javascript only has one
> number type and that is a double-precision
> 64-bit format IEEE 754 floating point number."
It's in the ECMAScript Language Specification - section 4.3.20:
"Number Type
"The type Number is a set of values representing numbers. In
ECMAScript, the set of values represents double-precision 64-bit
format IEEE 754 values including the special "Not-a-Number" (NaN)
values, positive infinity, and negative infinity."
Not to be confused with Number Object, of course...
[...]
> Also, I googled "usenet convention" and nothing really clear came up.
> If this is refering to the Netiquette of 1998, be aware that we are in
> 2005 and that new tools, new ways of discussions have made the
> newsgroups more accessible and more "affordable" for most of us.
Usenet started in 1979, not everything is 'soooo five minutes ago...'.
It has a long history and well established conventions that are
intended to encourage positive and useful participation.
> I will
> try my best to figure that out and will accept all comments and help as
> long as they don't violate the "convention" :)
See ya round! :-)
--
Rob
rf
> Richard Cornford wrote:
>> "Javascript only has one number type and that is a double-precision
>> 64-bit format IEEE 754 floating point number.
>
> 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.
64 bit floating point has been around for decades.
> 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.
Please provide a referance where these assertions may be verified.
Here is a reference which I believe refutes what you claim:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/js56jscondatatype.asp
Scroll down a bit to the heading "Number data type", wherein it says
<quote>
Internally, JScript represent[sic] all numbers as floating-point values
</quote>
I take this source as being authoritative, since they are the blokes who
wrote JScript, IE's implementation.
--
Cheers, Richard.
If you are reading this using google groups then also read this:
http://www.safalra.com/special/googlegroupsreply/ if you have not done so
already. If you reply to this post without correct quoting and attribution,
as per the above, I, and others, may just totally ignore you.
matty
RobG wrote:
> matty wrote:
> > I read the FAQ. And there was no mention of "Javascript only has one
> > number type and that is a double-precision
> > 64-bit format IEEE 754 floating point number."
>
> It's in the ECMAScript Language Specification - section 4.3.20:
>
> "Number Type
> "The type Number is a set of values representing numbers. In
> ECMAScript, the set of values represents double-precision 64-bit
> format IEEE 754 values including the special "Not-a-Number" (NaN)
> values, positive infinity, and negative infinity."
>
and ECMA so I wouldn't post stupid replies when trying to help.
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.
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.
Dag Sunde
news:1132034361....@o13g2000cwo.googlegroups.com...
>
> RobG wrote:
>> matty wrote:
>> > I read the FAQ. And there was no mention of "Javascript only has one
>> > number type and that is a double-precision
>> > 64-bit format IEEE 754 floating point number."
>>
>> It's in the ECMAScript Language Specification - section 4.3.20:
>>
> 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... ;-)
--
Dag.
Thomas 'PointedEars' Lahn
> "matty" <unlimi...@gmail.com> wrote [...]
>> RobG wrote:
>>> matty wrote:
>>> > I read the FAQ. And there was no mention of "Javascript only has one
>>> > number type and that is a double-precision
>>> > 64-bit format IEEE 754 floating point number."
>>>
>>> It's in the ECMAScript Language Specification - section 4.3.20:
>>>
> <snipped/>
>> What thing that is very confusing to me is the relation between W3C and
>> ECMA. Is ECMA the standard for Javascript?
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.
>> I see things like W3C telling me that I should not use "<script
>> language="javascript"> and rather use <script type="text/javascript">
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.
>> (which will be depracated and replaced by <script
>> type="application/javascript">
The former will not be deprecated by the latter but is registered and
marked in the standards tree as _obsolete_ now (since June 2005).
>> 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.
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
> Richard Cornford wrote:
>> "Javascript only has one number type and that is a
>> double-precision 64-bit format IEEE 754 floating point
>> number.
>
> 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
Richard Cornford wrote:
> 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:
:-)
Jasen Betts
> dear all
> i have use this line to time in many my web base appl.
> but now i found a weird problem
> the javascript line is the same
> but i use the calculation 2 time
> @ the first time, it is ok, 3 * 31.9 = 95.7
> @ the second time, 3 * 31.9 = 95.69999999999999
> this is the list number which calculation is NOT correct
> 6 * 31.9 = 191.39999999999998
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 ...
either pick how many digits you want and round to that number of digits
before displaying the result. or do your calculations in "cents" instead of
"dollars"
--
Bye.
Jasen
Dag Sunde
news:slrndnj46e...@clunker.homenet...
> On 2005-11-14, baong <bao...@gmail.com> wrote:
>> dear all
>> i have use this line to time in many my web base appl.
>> but now i found a weird problem
>> the javascript line is the same
>> but i use the calculation 2 time
>> @ the first time, it is ok, 3 * 31.9 = 95.7
>> @ the second time, 3 * 31.9 = 95.69999999999999
>> this is the list number which calculation is NOT correct
>> 6 * 31.9 = 191.39999999999998
>
> 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...
--
Dag.
Lasse Reichstein Nielsen
> matty wrote:
>> Lasse Reichstein Nielsen wrote:
>>> The 64 bit floats can represent all integers up to
>>> 2^54 precisely, and
>
> 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" :)
Dr John Stockton
Nov 2005 22:41:46, seen in news:comp.lang.javascript, Richard Cornford
<Ric...@litotes.demon.co.uk> posted :
>"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 .
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Lasse Reichstein Nielsen
> Richard Cornford wrote:
>> "Javascript only has one number type and that is a double-precision
>> 64-bit format IEEE 754 floating point number.
>
> 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.
Eric Kenneth Bustad
No it isn't.
0.2 decimal = 0.00110011001100110011001100110011... binary.
See http://www.geocities.com/oosterwal/computer/dec2bin.html
--
= Eric Bustad, Norwegian bachelor programmer
Thomas 'PointedEars' Lahn
> "Jasen Betts" <ja...@clunker.homenet> wrote [...]
>> 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
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 :)
Richard Cornford
> Richard Cornford wrote:
>> 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>
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:
<snip>
>> ..., 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
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
dated Mon, 14 Nov 2005 21:59:21, seen in news:comp.lang.javascript,
matty <unlimi...@gmail.com> posted :
>
>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?
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Jasen Betts
> "baong" <bao...@gmail.com> wrote in message
> news:1131953648.9...@g44g2000cwa.googlegroups.com...
>> thank you very much u all
>>
>> i think i will do math.round
>> but i still wondering why NOT every number
>> but only 3,6,7,9,12,14,18,23,24,28,29
>>
>
> Incidentally, those numbers leads to a fraction that
> can't be represented as exact x^2.
>
> Remember that there is a finite number of bits set aside
> to store the fractional part of a calculation.
>
> 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:
>
> 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
???
if I was feeling mean I'd ask you hoe to store 3.015
that 0011.1111 is 3+(15/16)
which is 3.9375
3.15 is 0011.0010011001100110011...
3.2 is 0011.0011001100110011001...
> but if we want to store 3.16, we have to round it, since
> we can't store the value 16 in 4 bits. We have to round it
> down to .15, or up to .2
>
> 0011.1111 or 0011.0010
>
3.16 is 0011.0010100011110101110000101000111101011100...
and 3.015 is 11.000000110'1010011111101111100111011011001000101101
000011100101011000000100000110001001001101110100101111'
with the bit between the quotes repeating infinitely :)
Bye.
Jasen
Dr John Stockton
Nov 2005 08:27:14, seen in news:comp.lang.javascript, Dag Sunde
<m...@dagsunde.com> posted :
>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
news:TT8IYpBh...@merlyn.demon.co.uk...
> JRS: In article <CTXdf.7785$qE.17...@juliett.dax.net>, dated Mon, 14
> Nov 2005 08:27:14, seen in news:comp.lang.javascript, Dag Sunde
> <m...@dagsunde.com> posted :
>
>>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.
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
--
Dag.
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"