Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #25738 > unrolled thread

IE and IEE 754

Back to article view | Back to comp.lang.javascript

Contents

  IE and IEE 754 RobG <rgqld@iinet.net.au> - 2014-08-27 22:44 +1000
    Re: IE and IEEE 754 John Harris <niam@jghnorth.org.uk.invalid> - 2014-08-27 15:23 +0100
    IE and IEEE 754 (was: IE and IEE 754) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-08-27 20:59 +0200
    Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-27 22:04 +0200
      Re: IE and IEE 754 "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-08-27 22:35 +0200
        Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-28 00:07 +0200
          Re: IE and IEE 754 "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-08-28 00:47 +0200
            Re: IE and IEE 754 Gene Wirchenko <genew@telus.net> - 2014-08-28 10:13 -0700
              Re: IE and IEE 754 "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-08-28 22:15 +0200
                Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-28 23:24 +0200
                  Re: IE and IEE 754 "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-08-29 01:16 +0200
                    Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-29 09:32 +0200
        Re: IE and IEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-27 23:59 +0100
          Re: IE and IEE 754 "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-08-28 02:55 +0200
            Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-28 09:50 +0200
              Re: IE and IEE 754 Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-08-28 12:21 +0200
                Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-28 13:42 +0200
            Re: IE and IEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-28 11:27 +0100
              Re: IE and IEE 754 Gene Wirchenko <genew@telus.net> - 2014-08-28 10:16 -0700
                Re: IE and IEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-29 00:04 +0100
                  Re: IE and IEE 754 Gene Wirchenko <genew@telus.net> - 2014-08-29 11:15 -0700
                    IEEE 754 (was: IE and IEE 754) "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-08-29 21:30 +0200
                      Re: IEEE 754 (was: IE and IEE 754) Gene Wirchenko <genew@telus.net> - 2014-09-02 11:22 -0700
                    Re: IE and IEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-29 20:42 +0100
                      IEEE 754 (was: IE and IEE 754) "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-08-29 23:29 +0200
                        Re: IEEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-29 23:27 +0100
                  Re: IE and IEE 754 Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-08-30 20:32 +0100
                    Re: IE and IEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-31 01:04 +0100
                      IE and IEEE 754 Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-09-01 23:05 +0100
      Re: IE and IEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-28 00:05 +0100
        Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-28 08:56 +0200
          Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-28 09:51 +0200
            Re: IE and IEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-28 11:16 +0100
              Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-28 13:34 +0200
                Re: IE and IEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-28 23:41 +0100
                  Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-29 09:09 +0200
                    Re: IE and IEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-29 12:39 +0100
                      Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-29 16:55 +0200
                        Re: IE and IEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-29 18:28 +0100
                          Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-30 00:37 +0200
                            Re: IE and IEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-29 23:53 +0100
                              Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-30 01:08 +0200
                                Re: IE and IEE 754 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-08-30 00:40 +0100
                                  Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-30 09:32 +0200
                        Re: IE and IEE 754 Gene Wirchenko <genew@telus.net> - 2014-08-29 11:22 -0700
                          Re: IE and IEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-30 00:14 +0200
    IE and IEEE 754 (was: IE and IEE 754) "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-08-27 22:08 +0200
      Re: IE and IEEE 754 RobG <rgqld@iinet.net.au> - 2014-08-28 22:50 +1000
      Re: IE and IEEE 754 RobG <rgqld@iinet.net.au> - 2014-08-28 22:55 +1000
      Re: IE and IEEE 754 (was: IE and IEE 754) Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-08-28 21:50 +0100
        Re: IE and IEEE 754 (was: IE and IEE 754) "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-29 09:43 +0200
          Re: IE and IEEE 754 (was: IE and IEE 754) Denis McMahon <denismfmcmahon@gmail.com> - 2014-08-29 08:42 +0000
          Re: IE and IEEE 754 Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-08-30 16:24 +0200
            Re: IE and IEEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-30 17:08 +0200
              Re: IE and IEEE 754 Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-08-30 18:12 +0200
                Re: IE and IEEE 754 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-08-30 18:32 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#25777

On Fri, 29 Aug 2014 00:04:48 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>Gene Wirchenko <genew@telus.net> writes:
>
>> On Thu, 28 Aug 2014 11:27:30 +0100, Ben Bacarisse
>> <ben.usenet@bsb.me.uk> wrote:
>>
>> [snip]
>>
>>>I think it must.  The ECMAScript specification imports IEEE 754's strict
>>>rounding and representation rules.  The IEEE FP value closest to 123.45,
>>>when multiplies by 100 must yield 12345 according to those rules.
>>
>>      Why?  What if the value that you have (and want) happens to be
>> the value closest to 123.45?  When you multiply that value by 100,
>> wouldn't you want 100 times the value instead of 12345?
>
>Yes, but you won't get it.  You'll get the nearest floating point
>number, which is 12345.  Am I missing your point?

     Yes.  The value closest to 123.45 can be represented exactly.  So
can 100 times that value.  That value is not 12345.  That 100 times
value would be what is wanted, not 12345.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#25781 — IEEE 754 (was: IE and IEE 754)

Gene Wirchenko wrote:

> On Fri, 29 Aug 2014 00:04:48 +0100, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
> 
>> Gene Wirchenko <genew@telus.net> writes:
>>
>>> On Thu, 28 Aug 2014 11:27:30 +0100, Ben Bacarisse
>>> <ben.usenet@bsb.me.uk> wrote:
>>>
>>>> I think it must.  The ECMAScript specification imports IEEE 754's strict
>>>> rounding and representation rules.  The IEEE FP value closest to 123.45,
>>>> when multiplies by 100 must yield 12345 according to those rules.
>>>
>>>      Why?  What if the value that you have (and want) happens to be
>>> the value closest to 123.45?  When you multiply that value by 100,
>>> wouldn't you want 100 times the value instead of 12345?
>>
>> Yes, but you won't get it.  You'll get the nearest floating point
>> number, which is 12345.  Am I missing your point?
> 
>      Yes.  The value closest to 123.45 can be represented exactly.  So
> can 100 times that value.  

If I am not mistaken, this conclusion is not correct.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#25802 — Re: IEEE 754 (was: IE and IEE 754)

On Fri, 29 Aug 2014 21:30:05 +0200, "Christoph M. Becker"
<cmbecker69@arcor.de> wrote:

>Gene Wirchenko wrote:

[snip]

>>      Yes.  The value closest to 123.45 can be represented exactly.  So
>> can 100 times that value.  
>
>If I am not mistaken, this conclusion is not correct.

     Yes, it is wrong.  Too much dealing with integers in
floating-point on my part led to me making the error.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#25782

Gene Wirchenko <genew@telus.net> writes:

> On Fri, 29 Aug 2014 00:04:48 +0100, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>Gene Wirchenko <genew@telus.net> writes:
>>
>>> On Thu, 28 Aug 2014 11:27:30 +0100, Ben Bacarisse
>>> <ben.usenet@bsb.me.uk> wrote:
>>>
>>> [snip]
>>>
>>>>I think it must.  The ECMAScript specification imports IEEE 754's strict
>>>>rounding and representation rules.  The IEEE FP value closest to 123.45,
>>>>when multiplies by 100 must yield 12345 according to those rules.
>>>
>>>      Why?  What if the value that you have (and want) happens to be
>>> the value closest to 123.45?  When you multiply that value by 100,
>>> wouldn't you want 100 times the value instead of 12345?
>>
>>Yes, but you won't get it.  You'll get the nearest floating point
>>number, which is 12345.  Am I missing your point?
>
>      Yes.  The value closest to 123.45 can be represented exactly.

Sure.  To be specific, for IEEE 754 double, it's 7B.733333333334 in hex.
Using enough decimal digits to see what happening, that's about

  123.45000000000000284217...

> So can 100 times that value.

That's an odd idea.  Why do you think it might be?

> That value is not 12345.

Yup, it's

  12345.000000000000284217...

> That 100 times value would be what is wanted, not 12345.

It's what you want, but, as I said, what you'll get is the nearest
representable floating point number.  The three candidates are centred
on 12345:

  12344.999999999998181011...
  12345.000000000000000000...
  12345.000000000001818989...

and 12345.0 is the closest.  (Assuming I have not made some blunder with
the arithmetic -- please check it.)

I'm still not sure I've got your point, but you've said what appears to
be the same thing twice now, so I don't know what else to say.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#25783 — IEEE 754 (was: IE and IEE 754)

Ben Bacarisse wrote:

> Gene Wirchenko <genew@telus.net> writes:
> 
>>      Yes.  The value closest to 123.45 can be represented exactly.
> 
> Sure.  To be specific, for IEEE 754 double, it's 7B.733333333334 in hex.
> Using enough decimal digits to see what happening, that's about
> 
>   123.45000000000000284217...

According to John's fine IEEE 754 double format calculator[1] that is
correct.  The hexadecimal representation is 405edccccccccccd, by the way.

>> So can 100 times that value.
> 
> That's an odd idea.  Why do you think it might be?
> 
>> That value is not 12345.
> 
> Yup, it's
> 
>   12345.000000000000284217...
> 
>> That 100 times value would be what is wanted, not 12345.
> 
> It's what you want, but, as I said, what you'll get is the nearest
> representable floating point number.  The three candidates are centred
> on 12345:
> 
>   12344.999999999998181011...

Correct.  Hexadecimal representation: 40c81c7fffffffff

>   12345.000000000000000000...

Correct.  Hexadecimal representation: 40c81c8000000000

>   12345.000000000001818989...

Correct.  Hexadecimal representation: 40c81c8000000001

> and 12345.0 is the closest.

[1] <http://www.merlyn.demon.co.uk/js-exact.htm#DW4>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#25785 — Re: IEEE 754

"Christoph M. Becker" <cmbecker69@arcor.de> writes:

> Ben Bacarisse wrote:
>
>> Gene Wirchenko <genew@telus.net> writes:
>> 
>>>      Yes.  The value closest to 123.45 can be represented exactly.
>> 
>> Sure.  To be specific, for IEEE 754 double, it's 7B.733333333334 in hex.
>> Using enough decimal digits to see what happening, that's about
>> 
>>   123.45000000000000284217...
>
> According to John's fine IEEE 754 double format calculator[1] that is
> correct.  The hexadecimal representation is 405edccccccccccd, by the
> way.

Sure, but that's the bit representation of the double.  If I've got it
right, 7B.733333333334 is the number in plain base 16 which might be
helpful in calculators that can do hex.

However, I can see that it might have helped to show the bit
representation of these:

>>  The three candidates are centred
>> on 12345:
>> 
>>   12344.999999999998181011...
>
> Correct.  Hexadecimal representation: 40c81c7fffffffff
>
>>   12345.000000000000000000...
>
> Correct.  Hexadecimal representation: 40c81c8000000000
>
>>   12345.000000000001818989...
>
> Correct.  Hexadecimal representation: 40c81c8000000001
>
>> and 12345.0 is the closest.

...as it might have made what's going on clearer.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#25795

In comp.lang.javascript message <871ts0md0v.fsf@bsb.me.uk>, Fri, 29 Aug
2014 00:04:48, Ben Bacarisse <ben.usenet@bsb.me.uk> posted:

>Gene Wirchenko <genew@telus.net> writes:
>
>> On Thu, 28 Aug 2014 11:27:30 +0100, Ben Bacarisse
>> <ben.usenet@bsb.me.uk> wrote:
>>
>> [snip]
>>
>>>I think it must.  The ECMAScript specification imports IEEE 754's strict
>>>rounding and representation rules.  The IEEE FP value closest to 123.45,
>>>when multiplies by 100 must yield 12345 according to those rules.
>>
>>      Why?  What if the value that you have (and want) happens to be
>> the value closest to 123.45?  When you multiply that value by 100,
>> wouldn't you want 100 times the value instead of 12345?
>
>Yes, but you won't get it.  You'll get the nearest floating point
>number, which is 12345.  Am I missing your point?

With FF31, or IE8, or Opera 12.17, or Chrome 36.0, in WinXP sp3, FWIW,
try

        S = ""
        for (J=1 ; J<111 ; J+=2) S += "\n" + J + "\t" +(1/J)*J
        alert(S)

And, in FF31 and Chrome 37.0,
        (123.45/100)*100 - 123.45    ->    -1.4210854715202004e-14

Two nominally-inverse arithmetic operations on IEEE Doubles do not
always yield the exact input.

-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
   Web  <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)

[toc] | [prev] | [next] | [standalone]

#25796

Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> writes:

> In comp.lang.javascript message <871ts0md0v.fsf@bsb.me.uk>, Fri, 29 Aug
> 2014 00:04:48, Ben Bacarisse <ben.usenet@bsb.me.uk> posted:
>
>>Gene Wirchenko <genew@telus.net> writes:
>>
>>> On Thu, 28 Aug 2014 11:27:30 +0100, Ben Bacarisse
>>> <ben.usenet@bsb.me.uk> wrote:
>>>
>>> [snip]
>>>
>>>>I think it must.  The ECMAScript specification imports IEEE 754's strict
>>>>rounding and representation rules.  The IEEE FP value closest to 123.45,
>>>>when multiplies by 100 must yield 12345 according to those rules.
>>>
>>>      Why?  What if the value that you have (and want) happens to be
>>> the value closest to 123.45?  When you multiply that value by 100,
>>> wouldn't you want 100 times the value instead of 12345?
>>
>>Yes, but you won't get it.  You'll get the nearest floating point
>>number, which is 12345.  Am I missing your point?
>
> With FF31, or IE8, or Opera 12.17, or Chrome 36.0, in WinXP sp3, FWIW,
> try
>
>         S = ""
>         for (J=1 ; J<111 ; J+=2) S += "\n" + J + "\t" +(1/J)*J
>         alert(S)
>
> And, in FF31 and Chrome 37.0,
>         (123.45/100)*100 - 123.45    ->    -1.4210854715202004e-14
>
> Two nominally-inverse arithmetic operations on IEEE Doubles do not
> always yield the exact input.

Of course not (I hope I never suggested otherwise).  I am happy to see
that the result you report is the one expected from IEEE 745's rules, so
I am not surprised that it's what you get in a wide range of browsers.
(In fact those that did not give this result are the ones I'd won't to
know about.)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#25798 — IE and IEEE 754

In comp.lang.javascript message <8761h9le2k.fsf@bsb.me.uk>, Sun, 31 Aug
2014 01:04:19, Ben Bacarisse <ben.usenet@bsb.me.uk> posted:

>Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> writes:
>
>> In comp.lang.javascript message <871ts0md0v.fsf@bsb.me.uk>, Fri, 29 Aug
>> 2014 00:04:48, Ben Bacarisse <ben.usenet@bsb.me.uk> posted:
>>
>>>Gene Wirchenko <genew@telus.net> writes:
>>>
>>>> On Thu, 28 Aug 2014 11:27:30 +0100, Ben Bacarisse
>>>> <ben.usenet@bsb.me.uk> wrote:
>>>>
>>>> [snip]
>>>>
>>>>>I think it must.  The ECMAScript specification imports IEEE 754's strict
>>>>>rounding and representation rules.  The IEEE FP value closest to 123.45,
>>>>>when multiplies by 100 must yield 12345 according to those rules.
>>>>
>>>>      Why?  What if the value that you have (and want) happens to be
>>>> the value closest to 123.45?  When you multiply that value by 100,
>>>> wouldn't you want 100 times the value instead of 12345?
>>>
>>>Yes, but you won't get it.  You'll get the nearest floating point
>>>number, which is 12345.  Am I missing your point?
>>
>> With FF31, or IE8, or Opera 12.17, or Chrome 36.0, in WinXP sp3, FWIW,
>> try
>>
>>         S = ""
>>         for (J=1 ; J<111 ; J+=2) S += "\n" + J + "\t" +(1/J)*J
>>         alert(S)
>>
>> And, in FF31 and Chrome 37.0,
>>         (123.45/100)*100 - 123.45    ->    -1.4210854715202004e-14
>>
>> Two nominally-inverse arithmetic operations on IEEE Doubles do not
>> always yield the exact input.
>
>Of course not (I hope I never suggested otherwise).  I am happy to see
>that the result you report is the one expected from IEEE 745's rules, so
>I am not surprised that it's what you get in a wide range of browsers.
>(In fact those that did not give this result are the ones I'd won't to
>know about.)

My aim was to reinforce what you said, not to argue with it.  BTW, the
36.0 & 37.0 do not show a typo; I was "upgrading" while writing.


AIUI, all ordinary numerical operations in IEEE 754 will give the exact
result when the exact result can be expressed exactly in an IEEE Double;
and for that it is necessary that the exact result is within range and
has no more than 54 significant bits in the binary mantissa.  I don't
recall whether that holds for expressions involving exp, log, or trig-
type functions.

Of course, one can achieve an arbitrary degree of accuracy in ECMA-
262-3, Mar 2000, JavaScript : one just needs to abandon the idea of
storing a high-accuracy variable in a single IEEE Double.

-- 
 (c) John Stockton, nr London, UK.  For Mail, see Home Page.  Turnpike, WinXP.
 Web  <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
 Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
 DOS/Win/UNIX now 2.0.6;  see my <http://www.merlyn.demon.co.uk/pc-links.htm>.

[toc] | [prev] | [next] | [standalone]

#25749

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
<snip>
> Both are and must be wrong in the sense that the binary converions
> of floting point fractional decimal values NEVER can be right.

What about 0.5 or 0.25?  Why can't these ever be right?  Did you mean
that *all* decimal fractions can't be correctly converted?  That's
certainly the case.  The way you worded it sounds like none of them can
be.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#25751

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 28 aug 2014 in 
comp.lang.javascript:

> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
> <snip>
>> Both are and must be wrong in the sense that the binary converions
>> of floting point fractional decimal values NEVER can be right.
> 
> What about 0.5 or 0.25?  Why can't these ever be right?  Did you mean
> that *all* decimal fractions can't be correctly converted?  That's
> certainly the case.  The way you worded it sounds like none of them can
> be.

No, keep it the they cannot be trusted to be exact.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#25753

"Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote on 28 aug 2014 in 
comp.lang.javascript:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 28 aug 2014 in 
> comp.lang.javascript:
> 
>> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
>> <snip>
>>> Both are and must be wrong in the sense that the binary converions
>>> of floting point fractional decimal values NEVER can be right.
>> 
>> What about 0.5 or 0.25?  Why can't these ever be right?  Did you mean
>> that *all* decimal fractions can't be correctly converted?  That's
>> certainly the case.  The way you worded it sounds like none of them can
>> be.
> 
> No, keep it the they cannot be trusted to be exact.
> 

No, keep it THAT they cannot be trusted to be exact.



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#25754

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:

> "Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote on 28 aug 2014 in 
> comp.lang.javascript:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 28 aug 2014 in 
>> comp.lang.javascript:
>> 
>>> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
>>> <snip>
>>>> Both are and must be wrong in the sense that the binary converions
>>>> of floting point fractional decimal values NEVER can be right.
>>> 
>>> What about 0.5 or 0.25?  Why can't these ever be right?  Did you mean
>>> that *all* decimal fractions can't be correctly converted?  That's
>>> certainly the case.  The way you worded it sounds like none of them can
>>> be.
>> 
>> No, keep it the they cannot be trusted to be exact.
>
> No, keep it THAT they cannot be trusted to be exact.

You mean "yes, but..." surely?  You did not say that that they cannot be
*trusted* to be exact, you said that they can't ever be exact.

But there's another point about your modified statement.  We are talking
here about ECMAScript, and that imposes IEEE 754's strict rounding and
representation rules.  This means that, from the point of view of the
language specification, you absolutely can rely on 0.5 (as a numeric
literal) being converted to the right, exact, binary floating-point
value.  You can also rely on the expression 1/2 yielding this same
value.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#25757

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 28 aug 2014 in 
comp.lang.javascript:
> You mean "yes, but..." surely?  You did not say that that they cannot be
> *trusted* to be exact, you said that they can't ever be exact.

Wow, are you still in kindergarten?

> But there's another point about your modified statement.  We are talking
> here about ECMAScript, 

So now you take on the "we", you do not define the constraints of this 
thread. Did you question all members of this NG?

I pointed out that the standard, even wgen implemented correctly, is not 
important in this case, as long as you know the ins and outs of binary 
conversion, and take proper care.

> and that imposes IEEE 754's strict rounding and
> representation rules. 

However, for proper programming, 
they are of minor importance, as I pointed out.

> This means that, from the point of view of the
> language specification, you absolutely can rely on 0.5 (as a numeric
> literal) being converted to the right, exact, binary floating-point
> value. 

Even if this were true in the practical implementations of Javascript, it 
still wouldn't mean a thing, as there decimal values that perhaps give the 
same repeated results, that will fail terribly when being used in compound 
arythmetic.

> You can also rely on the expression 1/2 yielding this same
> value.

Perhaps, Ben, you have never tried proper programming, as the above 
reliance, even when true crossbrowserwise and in practice, does not help 
with other and computed values.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#25765

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 28 aug 2014 in 
> comp.lang.javascript:
>> You mean "yes, but..." surely?  You did not say that that they cannot be
>> *trusted* to be exact, you said that they can't ever be exact.
>
> Wow, are you still in kindergarten?

I'd like to try to unravel this.  I don't think I am wrong to say that
0.5 can be converted to a binary floating point value exactly, and I
don't think you disagree on that point, but can you see that what you
wrote:

  "... the binary converions of floting point fractional decimal values
  NEVER can be right"

does seem to suggest otherwise?  I even suggested that there was a
communication problem:

  "What about 0.5 or 0.25?  Why can't these ever be right?  Did you mean
  that *all* decimal fractions can't be correctly converted?  That's
  certainly the case.  The way you worded it sounds like none of them
  can be."

But that was not, it seems, what you wanted to say.

When you rejected my examples of 0.5 and 0.25 you said the conversion
could not be trusted to be exact (correct me, if I've misunderstood that
as well).  That sounded exactly like a "yes they can be exact, but they
can't be trusted to be exact".  If you weren't saying "yes, but" what
were you saying?  "No, they can't be exact and in addition they can be
trusted to be exact"?  That doesn't sound right.

If you think my pointing this out was childish, or the way in which I
did so was childish, then I am genuinely sorry about that.  I certainly
don't want to appear childish, but I am now a little lost about what it
is you are saying.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#25769

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 29 aug 2014 in 
comp.lang.javascript:

> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
> 
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 28 aug 2014 in 
>> comp.lang.javascript:
>>> You mean "yes, but..." surely?  You did not say that that they cannot be
>>> *trusted* to be exact, you said that they can't ever be exact.
>>
>> Wow, are you still in kindergarten?
> 
> I'd like to try to unravel this.  I don't think I am wrong to say that
> 0.5 can be converted to a binary floating point value exactly, and I
> don't think you disagree on that point, but can you see that what you
> wrote:
> 
>   "... the binary converions of floting point fractional decimal values
>   NEVER can be right"
> 
> does seem to suggest otherwise?  I even suggested that there was a
> communication problem:
> 
>   "What about 0.5 or 0.25?  Why can't these ever be right?  Did you mean
>   that *all* decimal fractions can't be correctly converted?  That's
>   certainly the case.  The way you worded it sounds like none of them
>   can be."
> 
> But that was not, it seems, what you wanted to say.
> 
> When you rejected my examples of 0.5 and 0.25 you said the conversion
> could not be trusted to be exact (correct me, if I've misunderstood that
> as well).  That sounded exactly like a "yes they can be exact, but they
> can't be trusted to be exact". 

"Fixed point decimal <input> strings" can incidentally be exact, like 
'27.00', but the whole idea is the you as a programmer, when allowing for 
fractional input strings[!], don't know beforehand what number will be 
inputted, and an incidental input of '0.50' cannot be taken as exact, 
because you would have to make an array of exact decimal values, and still 
have the rest of the possibilities delt with as non-exact.

Therefore your example of 0.5 is childish, as it does not seriously address 
the problem of binary conversion in programmes.

> If you weren't saying "yes, but" what
> were you saying?  "No, they can't be exact and in addition they can be
> trusted to be exact"?  That doesn't sound right.

Indeed so, I cannot controll the way it sounds to you.

However, when programming money variables, better take it that these "fixed 
point decimal input strings" are NOT exact when stored and retrieved using 
binary conversion, like sailing the 7 seas without any navigational 
instrument does not get you from Amsterdam to New York, even if incidentally 
you might.
 
> If you think my pointing this out was childish, or the way in which I
> did so was childish, then I am genuinely sorry about that.  I certainly
> don't want to appear childish, but I am now a little lost about what it
> is you are saying.

Okay. I hope I am claring things up now.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#25774

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 29 aug 2014 in 
> comp.lang.javascript:
>
>> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
>> 
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 28 aug 2014 in 
>>> comp.lang.javascript:
>>>> You mean "yes, but..." surely?  You did not say that that they cannot be
>>>> *trusted* to be exact, you said that they can't ever be exact.
>>>
>>> Wow, are you still in kindergarten?
>> 
>> I'd like to try to unravel this.  I don't think I am wrong to say that
>> 0.5 can be converted to a binary floating point value exactly, and I
>> don't think you disagree on that point, but can you see that what you
>> wrote:
>> 
>>   "... the binary converions of floting point fractional decimal values
>>   NEVER can be right"
>> 
>> does seem to suggest otherwise?  I even suggested that there was a
>> communication problem:
>> 
>>   "What about 0.5 or 0.25?  Why can't these ever be right?  Did you mean
>>   that *all* decimal fractions can't be correctly converted?  That's
>>   certainly the case.  The way you worded it sounds like none of them
>>   can be."
>> 
>> But that was not, it seems, what you wanted to say.
>> 
>> When you rejected my examples of 0.5 and 0.25 you said the conversion
>> could not be trusted to be exact (correct me, if I've misunderstood that
>> as well).  That sounded exactly like a "yes they can be exact, but they
>> can't be trusted to be exact". 
>
> "Fixed point decimal <input> strings" can incidentally be exact, like 
> '27.00', but the whole idea is the you as a programmer, when allowing for 
> fractional input strings[!], don't know beforehand what number will be 
> inputted, and an incidental input of '0.50' cannot be taken as exact, 
> because you would have to make an array of exact decimal values, and still 
> have the rest of the possibilities delt with as non-exact.
>
> Therefore your example of 0.5 is childish, as it does not seriously address 
> the problem of binary conversion in programmes.

But it's unfair of you to make that accusation when I never intended it
to be anything other than a counter example to what looked like a simple
statement of fact.  I'm sorry you thought I was offering an example that
addressed the general problem of decimal to binary floating point
conversion, but I can't see how you could think I was, especially as I
explicitly suggested that maybe your remark had come over as being more
general than you had intended.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#25775

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 29 aug 2014 in 
comp.lang.javascript:

> But it's unfair of you to make that accusation when I never intended it
> to be anything other than a counter example to what looked like a simple
> statement of fact.  I'm sorry you thought I was offering an example that
> addressed the general problem of decimal to binary floating point
> conversion, but I can't see how you could think I was, especially as I
> explicitly suggested that maybe your remark had come over as being more
> general than you had intended.

Perhaps you think discussion is a contest who wins and who loses.

My idea of discussion is getting to the best solution available,
better than one can achieve on his own by listening to and weighing 
eachother's arguments.

So I try not to make comments felt as "accusations" and be "unfair".

However, as you kept by the statement that binary conversion of fractions 
can be exact, while such seldom instances do not help in programming,
and one should be prepared to treat all inputted decimal fraction strings as 
leading to inexact results if not properly handled, yes, I thought that your 
arguments were discussion for the above contest and not discussion for 
programming results. 

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#25776

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
<snip>
> So I try not to make comments felt as "accusations" and be "unfair".

I took your calling my remarks childish as an accusation, and an unfair
one at that.  If you had simply acknowledged that your remark at the
very least *looked* wrong, and then explained that you meant something
far less dogmatic, none of this would have happened.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#25786

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 29 aug 2014 in 
comp.lang.javascript:

> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
> <snip>
>> So I try not to make comments felt as "accusations" and be "unfair".
> 
> I took your calling my remarks childish as an accusation, and an unfair
> one at that.  If you had simply acknowledged that your remark at the
> very least *looked* wrong, and then explained that you meant something
> far less dogmatic, none of this would have happened.

None of what? Did something happen?

Seems you are still in fighting mode, how amusing.

Methinks my remarks were to the point,
I am not concerned how things looked to you.

It seems you are not grasping what discussion is all about.

Discussion is for joy and for widening our vieuws,
for learning from eachother, not for feeling offended,
not for trying to score points. Defending you views is 
a good part of the game.

Blaming someone else for being offended is childish in itself,
as being offended is a personal thing and consequently there is 
no right not to be offended.

hen again I don't blame you for being offended, 
you should only blame yourself.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web