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 1 of 3  [1] 2 3  Next page →

#25738 — IE and IEE 754

In most browsers:

   0.57 + 8.36 + 3.36 + 0.19 = 12.479999999999999

in IE it returns:

   12.479999999999998

Is IE wrong, or is the above difference allowable within IEEE 754?


-- 
Rob

[toc] | [next] | [standalone]

#25739 — Re: IE and IEEE 754

On Wed, 27 Aug 2014 22:44:35 +1000, RobG <rgqld@iinet.net.au> wrote:

>In most browsers:
>
>   0.57 + 8.36 + 3.36 + 0.19 = 12.479999999999999
>
>in IE it returns:
>
>   12.479999999999998
>
>Is IE wrong, or is the above difference allowable within IEEE 754?

It's possible both are right. According to Wikipedia :
"The standard requires operations to convert between basic formats and
external character sequence formats.[12] Conversions to and from a
decimal character format are required for all formats. Conversion to
an external character sequence must be such that conversion back using
round to even will recover the original number."

  John

PS I've corrected the typo in the Subject. The late lamented IEE is no
more, alas.

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

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

RobG wrote:

> In most browsers:
> 
>    0.57 + 8.36 + 3.36 + 0.19 = 12.479999999999999
> 
> in IE it returns:
> 
>    12.479999999999998

Probably neither is true.
 
> Is IE wrong, or is the above difference allowable within IEEE 754?

Mu.  You need to keep in mind that in this way you are only seeing string 
representations of Number values, specified in
<http://ecma-international.org/ecma-262/5.1/#sec-9.8.1>.  (Is there even 
another way?)

If I understand it correctly, there is enough room in the algorithm and 
implementation notes for this to be implementation-dependent.  Even if it 
were not, or implementors would not defer to any allowances, the wording of 
the algorithm is so complicated, even for Ecma standards (pun intended), 
that I would not be surprised if, because of that, different implementors 
would arrive at different implementations of it.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#25742

RobG <rgqld@iinet.net.au> wrote on 27 aug 2014 in comp.lang.javascript:

> In most browsers:
>    0.57 + 8.36 + 3.36 + 0.19 = 12.479999999999999
> in IE it returns:
>    12.479999999999998
> Is IE wrong, or is the above difference allowable within IEEE 754?

Both are and must be wrong in the sense that the binary converions
of floting point fractional decimal values NEVER can be right.

So why use a standard that defines how wrong they must be?

Just remember every time,
that you should not compare such values without prior rounding.

If you are a sticker for correctness and these are monitary values,
like $ or €, use integer cent values in variables, and write decimals with 
string manupulation.

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

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

#25744

Evertjan. wrote:

> RobG <rgqld@iinet.net.au> wrote on 27 aug 2014 in comp.lang.javascript:
> 
>> In most browsers:
>>    0.57 + 8.36 + 3.36 + 0.19 = 12.479999999999999
>> in IE it returns:
>>    12.479999999999998
>> Is IE wrong, or is the above difference allowable within IEEE 754?
> 
> Both are and must be wrong in the sense that the binary converions
> of floting point fractional decimal values NEVER can be right.

Wrong.  Consider e.g. 0 or 2.

> So why use a standard that defines how wrong they must be?

To be able to quantify the inaccuracy.

> Just remember every time,
> that you should not compare such values without prior rounding.

AFAIK it is common to compare for equality with

    Math.abs(a - b) < epsilon

See also Number.EPSILON[1].

> If you are a sticker for correctness and these are monitary values,
> like $ or €, use integer cent values in variables, and write decimals with 
> string manupulation.

Are you suggesting that storing $123.45 as 12345 is better than storing
it as 123.45?  As ECMAScript implementations typically have no integer
type, there is no difference regarding the precision of further
calculations.

[1]
<http://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.epsilon>

-- 
Christoph M. Becker

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

#25745

"Christoph M. Becker" <cmbecker69@arcor.de> wrote on 27 aug 2014 in
comp.lang.javascript: 

>> Both are and must be wrong in the sense that the binary converions
>> of floting point fractional decimal values NEVER can be right.
> 
> Wrong.  Consider e.g. 0 or 2.

No 0 and 2 are integers.

>> So why use a standard that defines how wrong they must be?
> 
> To be able to quantify the inaccuracy.

There is no need for that.

>> Just remember every time,
>> that you should not compare such values without prior rounding.
> 
> AFAIK it is common to compare for equality with
> 
>     Math.abs(a - b) < epsilon

What has "common" to do with it?

It is a way, 
but a and b stay unrounded, 
and if reused and reused 
you might find yourself in trouble
with the wrong value of epsilon. 

> See also Number.EPSILON[1].

I don't see that.

> 
>> If you are a sticker for correctness and these are monitary values,
>> like $ or  , use integer cent values in variables, and write decimals
>> with string manupulation.
> 
> Are you suggesting that storing $123.45 as 12345 is better than storing
> it as 123.45?  

I am not 'suggesting' anything, 
I am not saying 'better',
just read my words.

But indeed, it is safer to manipulate integers.

> As ECMAScript implementations typically have no integer
> type, there is no difference regarding the precision of further
> calculations.

I wes not talking about the integer type, 
I was not talking about Javascript [ECMA if you like],
but about integers.

There is a rather a big difference 
'regarding the precision of further calculations.'
that difference is called safety of exactness.

Integers in binary storage are exact 
and so are simple arithmetic with those numbers, except for division, 
as long as the precision stays within practical limits.

input '23.45' string, store as a = 2345
input '23.4' string, store as b = 2340
do c = a - b
c contains 5
convert c to string d 0.05
write d

Compare this to:

document.write(23.45-23.4); // 0.05000000000000071

You are quite in your right 
not to call the first method "better",
but in monetary calculus, I would disagree.

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

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

#25747

Evertjan. wrote:

> "Christoph M. Becker" <cmbecker69@arcor.de> wrote on 27 aug 2014 in
> comp.lang.javascript: 
> 
> I wes not talking about the integer type, 
> I was not talking about Javascript [ECMA if you like],
> but about integers.

Well, then you're off topic.

> Compare this to:
> 
> document.write(23.45-23.4); // 0.05000000000000071
> 
> You are quite in your right 
> not to call the first method "better",
> but in monetary calculus, I would disagree.

Well, then try to calculate the German VAT with "integers":

  2345 * 1.19 -> 2790.5499999999997

Ah, we have to round the result:

  (2345 * 1.19).toFixed(0) -> 2791

Or:

  (23.45 * 1.19).toFixed(2) -> 27.91

Hm, same result (but see <http://www.jibbering.com/faq/#formatNumber>
for very old browsers).

Anyway, you can't do arbitrary monetary calculations reliably with IEEE
754 doubles.  However, that is the only number type that is guaranteed
to be supported by conforming ECMAScript implementations.

-- 
Christoph M. Becker

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

#25761

On Thu, 28 Aug 2014 00:47:16 +0200, "Christoph M. Becker"
<cmbecker69@arcor.de> wrote:

>Evertjan. wrote:
>
>> "Christoph M. Becker" <cmbecker69@arcor.de> wrote on 27 aug 2014 in
>> comp.lang.javascript: 
>> 
>> I wes not talking about the integer type, 
>> I was not talking about Javascript [ECMA if you like],
>> but about integers.
>
>Well, then you're off topic.
>
>> Compare this to:
>> 
>> document.write(23.45-23.4); // 0.05000000000000071
>> 
>> You are quite in your right 
>> not to call the first method "better",
>> but in monetary calculus, I would disagree.
>
>Well, then try to calculate the German VAT with "integers":
>
>  2345 * 1.19 -> 2790.5499999999997
          ^^^^
     This is not an integer.

[snip]

>Anyway, you can't do arbitrary monetary calculations reliably with IEEE
>754 doubles.  However, that is the only number type that is guaranteed
>to be supported by conforming ECMAScript implementations.

     Not arbitrary ones, but if you stick with integers of up to 15
digits, it can work just fine.

Sincerely,

Gene Wirchenko

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

#25763

Gene Wirchenko wrote:

> On Thu, 28 Aug 2014 00:47:16 +0200, "Christoph M. Becker"
> <cmbecker69@arcor.de> wrote:
> 
>> Evertjan. wrote:
>>
>>> Compare this to:
>>>
>>> document.write(23.45-23.4); // 0.05000000000000071
>>>
>>> You are quite in your right 
>>> not to call the first method "better",
>>> but in monetary calculus, I would disagree.
>>
>> Well, then try to calculate the German VAT with "integers":
>>
>>  2345 * 1.19 -> 2790.5499999999997
>           ^^^^
>      This is not an integer.

No, of course not.  I just wanted to show that storing dollars as cents
doesn't solve all problems regarding monetary calculations.  Of course,
one could use the following instead:

  2345 * 119 / 100

But you may see the potential problems with this approach.

>> Anyway, you can't do arbitrary monetary calculations reliably with IEEE
>> 754 doubles.  However, that is the only number type that is guaranteed
>> to be supported by conforming ECMAScript implementations.
> 
>      Not arbitrary ones, but if you stick with integers of up to 15
> digits, it can work just fine.

If one cares about all the gory details and avoids the pitfalls.  IMHO
one is better off to use a bigint library when there is really the need
for exact integer calculations.

-- 
Christoph M. Becker

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

#25764

"Christoph M. Becker" <cmbecker69@arcor.de> wrote on 28 aug 2014 in 
comp.lang.javascript:

>>> Well, then try to calculate the German VAT with "integers":
>>>
>>>  2345 * 1.19 -> 2790.5499999999997
>>           ^^^^
>>      This is not an integer.
> 
> No, of course not.  I just wanted to show that storing dollars as cents
> doesn't solve all problems regarding monetary calculations.  Of course,
> one could use the following instead:
> 
>   2345 * 119 / 100

No that would not help.
It seems your mathematic skills leave much to be desired.

> But you may see the potential problems with this approach.

You are mistaken again. 

The cents approach solves the problems 
of binary conversion inaccuracies, 
but you still have to be a good programmer.

Adding and substracting of cents will be exact.
Multiplying with an integer too.

Multiplying with a fraction or percentage
and division still needs rounding,
however in monitary calculus one expects 
rounding being neccessary anyway and [only]
NOT BECAUSE OF THE BINARY CONVERSION.

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

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

#25768

Evertjan. wrote:

> "Christoph M. Becker" <cmbecker69@arcor.de> wrote on 28 aug 2014 in 
> comp.lang.javascript:
> 
>>>> Well, then try to calculate the German VAT with "integers":
>>>>
>>>>  2345 * 1.19 -> 2790.5499999999997
>>>           ^^^^
>>>      This is not an integer.
>>
>> No, of course not.  I just wanted to show that storing dollars as cents
>> doesn't solve all problems regarding monetary calculations.  Of course,
>> one could use the following instead:
>>
>>   2345 * 119 / 100
> 
> No that would not help.
> It seems your mathematic skills leave much to be desired.

Of course, that would not help.  I did not suggest that as a solution,
but rather to reply to Gene's complaint that "this is not an integer".

> The cents approach solves the problems 
> of binary conversion inaccuracies, 
> but you still have to be a good programmer.

The "cents approach" is usually not exact enough.  Intermediate
calculations may well require more precision, and sometimes even "final"
results, for instance some stock quotations.

> Adding and substracting of cents will be exact.
> Multiplying with an integer too.

You should consider "overflow".  AISB:

| IMHO one is better off to use a bigint library when there is really
| the need for exact integer calculations.

-- 
Christoph M. Becker

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

#25771

"Christoph M. Becker" <cmbecker69@arcor.de> wrote on 29 aug 2014 in 
comp.lang.javascript:

>> The cents approach solves the problems 
>> of binary conversion inaccuracies, 
>> but you still have to be a good programmer.
> 
> The "cents approach" is usually not exact enough. 

Exact is exact, there is no such thing as "exact enough". 

> Intermediate
> calculations may well require more precision, and sometimes even "final"
> results, for instance some stock quotations.

The "cents approach" is perfectly exact, if you consider the exceptions, the 
first two I mentioned earlier:

1 division [apply rounding rules]
2 multiplication with non-integers [apply rounding rules]
3 precision overflow, more than 2^51 or 15 decimal digits, I believe.
  [officially 17 decimal digits, but there are problems at the top, I read.]
3 exponent overflow, 2^10, or 1024. 

In day to day accounting these last two will not be reached easily.

Money values absolutely smaller than +/- 9,999,999,999,999.99, or even 
equal, are within the precision range, I would call those "usual" amounts.

Repeated rounding needs additional rules, 
usually available in large sum banking and stock exchange. 

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

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

#25748

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

> Evertjan. wrote:
<snip>
>> If you are a sticker for correctness and these are monitary values,
>> like $ or [euro-sign], use integer cent values in variables, and
>> write decimals with string manupulation.
>
> Are you suggesting that storing $123.45 as 12345 is better than storing
> it as 123.45?  As ECMAScript implementations typically have no integer
> type, there is no difference regarding the precision of further
> calculations.

12345 can be represented exactly in binary floating point (given enough
bits, and we certainly have that) whereas 123.45 can't be.  Whether this
matters (and how much) depends on what calculations you go on to do, but
I would call that a difference in precision from the get go.

-- 
Ben.

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

#25750

Ben Bacarisse wrote:

> "Christoph M. Becker" <cmbecker69@arcor.de> writes:
> 
>> Evertjan. wrote:
> <snip>
>>> If you are a sticker for correctness and these are monitary values,
>>> like $ or [euro-sign], use integer cent values in variables, and
>>> write decimals with string manupulation.
>>
>> Are you suggesting that storing $123.45 as 12345 is better than storing
>> it as 123.45?  As ECMAScript implementations typically have no integer
>> type, there is no difference regarding the precision of further
>> calculations.
> 
> 12345 can be represented exactly in binary floating point (given enough
> bits, and we certainly have that) whereas 123.45 can't be.
<snip>

Thanks for pointing this out. :) After quite some reconsideration I have
to admit that I was wrong.  Of course, 123.45 can't be represented
exactly as *binary* floating point number, while 12345 can be.

However, it seems to me that multiplying 123.45 (0x405edccccccccccd)
with 100 doesn't solve the issue, i.e. the result is not necessarily
equal to 12345 (0x40c81c8000000000).

-- 
Christoph M. Becker

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

#25752

"Christoph M. Becker" <cmbecker69@arcor.de> wrote on 28 aug 2014 in 
comp.lang.javascript:

> However, it seems to me that multiplying 123.45 (0x405edccccccccccd)
> with 100 doesn't solve the issue, i.e. the result is not necessarily
> equal to 12345 (0x40c81c8000000000).

No, as I said, it is the string that is <input>-ted,
and that should be converted by string [regexed if you like] methods.   

a = 123.45; // expecting 2 decimals, extra code needed if otherwise
b = +a.split('.').join('');


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

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

#25755

Evertjan. wrote:

> "Christoph M. Becker" <cmbecker69@arcor.de> wrote:
>> However, it seems to me that multiplying 123.45 (0x405edccccccccccd)
>> with 100 doesn't solve the issue, i.e. the result is not necessarily
>> equal to 12345 (0x40c81c8000000000).
> 
> No, as I said, it is the string that is <input>-ted,
> and that should be converted by string [regexed if you like] methods.
> 
> a = 123.45; // expecting 2 decimals, extra code needed if otherwise
> b = +a.split('.').join('');

There is no Number.prototype.split() by default.  You mean 
String.prototype.split():

  var b = a.toString().split('.').join('');

or (in this case equivalent)

  var b = String(a).split('.').join('');

but this does not solve the problem because it is based on the very same 
string representation of the Number value.

It can only be solved if you have string input in the first place, like from 
an HTML form:

  /* BTW see jsx.array.destructure() for an emulation of
     JavaScript 1.7’s Array destructuring */
  var parts = input.value.split('.');
  var int_part = parts[0];
  var frac_part = parts[1];

  var value = int_part * 100 + (+frac_part);

  /* calculate with value */

  var result = … / 100;

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#25758

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote on 28 aug 2014 in 
comp.lang.javascript:

> Evertjan. wrote:
> 
>> "Christoph M. Becker" <cmbecker69@arcor.de> wrote:
>>> However, it seems to me that multiplying 123.45 (0x405edccccccccccd)
>>> with 100 doesn't solve the issue, i.e. the result is not necessarily
>>> equal to 12345 (0x40c81c8000000000).
>> 
>> No, as I said, it is the string that is <input>-ted,
>> and that should be converted by string [regexed if you like] methods.
>> 
>> a = 123.45; // expecting 2 decimals, extra code needed if otherwise
>> b = +a.split('.').join('');
> 
> There is no Number.prototype.split() by default.  You mean 
> String.prototype.split():

You are right.
I forgot the string specification I stipulates earlier, 
where a came from an <input>.

>> a = '123.45'; // expecting 2 decimals, extra code needed if otherwise
>> b = +a.split('.').join('');


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

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

#25756

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

> Ben Bacarisse wrote:
>
>> "Christoph M. Becker" <cmbecker69@arcor.de> writes:
>> 
>>> Evertjan. wrote:
>> <snip>
>>>> If you are a sticker for correctness and these are monitary values,
>>>> like $ or [euro-sign], use integer cent values in variables, and
>>>> write decimals with string manupulation.
>>>
>>> Are you suggesting that storing $123.45 as 12345 is better than storing
>>> it as 123.45?  As ECMAScript implementations typically have no integer
>>> type, there is no difference regarding the precision of further
>>> calculations.
>> 
>> 12345 can be represented exactly in binary floating point (given enough
>> bits, and we certainly have that) whereas 123.45 can't be.
> <snip>
>
> Thanks for pointing this out. :) After quite some reconsideration I have
> to admit that I was wrong.  Of course, 123.45 can't be represented
> exactly as *binary* floating point number, while 12345 can be.
>
> However, it seems to me that multiplying 123.45 (0x405edccccccccccd)
> with 100 doesn't solve the issue, i.e. the result is not necessarily
> equal to 12345 (0x40c81c8000000000).

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.

-- 
Ben.

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

#25762

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?

Sincerely,

Gene Wirchenko

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

#25767

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?

-- 
Ben.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web