kuyper@wizard.net wrote:

>
> However, my main point wasn't about the accuracy of the division, but
> rather about the ability of ma and mb to be exactly representable. The
> original poster compared those values with LONG_MAX, which is not
> suffient to ensure exact representability as a double-precision number.
> If either ma or mb is not exactly representable, you can't count on a/b
> and ma/mb producing the same value, even if IEC 559 does apply.
>

Another shocking example for many people (myself included, when I first
came across it) is that m*(a+b) isn't necessarily equal to m*a+m*b, for
similar reasons.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

arn_2000@rediffmail.com wrote:
> let a, b be long integers
>
> suppose i do  doubl(a)/b and double(m*a)/(m*b)  (NOTE: the division is
> by an integer) .... am i guaranteed to get the same result .  (m*a &
> m*b < MAX_LONG)...  my experimentations showed YES atleast in GCC...
> but i've not found anything on the net saying so.
>
> if not : why not?
> if yes : why shud it?

There's no guarantees about that. However, in practice, if m is a power
of 2, you'll generally get the same result. If m*a and m*b can be
represented exactly as floating point numbers then you've got a pretty
good chance at exactly matching results. Note that LONG_MAX isn't the
relevant limit; if 'long' and 'double' are both 64-bit types, then
LONG_MAX will almost certainly not be exactly representable as a
double.

In general, when comparing floating point numbers you should always
include an appropriate fudge factor, to allow for the fact that
floating point operations are inexact.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

arn_2000@rediffmail.com wrote:

>
> let a, b be long integers
>
> suppose i do  doubl(a)/b and double(m*a)/(m*b)  (NOTE: the division is
> by an integer) .... am i guaranteed to get the same result .  (m*a &
> m*b < MAX_LONG)...  my experimentations showed YES atleast in GCC...
> but i've not found anything on the net saying so.
>

Not necessarily, for the same reason that it's not guaranteed for longs:
you might need more bits to represent the value of the product than are
available. If you've got enough bits it'll work the way you expect.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:

>     Most computers manufactured today are IEEE 794 floating
> point compliant for general floating point arithmetic.

Not to detract from what you said, but 794 is a typo for 754, right?
These days <g> the usual suspect is IEC 60559, which is mentioned in the
C++ standard and cited as authority in the C99 standard.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2005-07-14 18:57:25 -0400, hyrosen@mail.com (Hyman Rosen) said:

> Clark S. Cox III wrote:
>> No, you aren't guaranteed, because floating point math is inexact.
>
> Yes, you are guaranteed, except on unusual machines
> where doubles do not have enough mantissa bits to
> represent all long integers exactly, or on machines
> where floating division does not give you the result
> closest to the correct mathematical value.
>
> He's dividing integers.

He did not specify that m was an integer.

--
Clark S. Cox, III
clarkcox3@gmail.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:
> arn_2000@rediffmail.com wrote:
>
>>
>> let a, b be long integers
>>
>> suppose i do  doubl(a)/b and double(m*a)/(m*b)  (NOTE: the division is
>> by an integer) .... am i guaranteed to get the same result .  (m*a &
>> m*b < MAX_LONG)...  my experimentations showed YES atleast in GCC...
>> but i've not found anything on the net saying so.
>>
>
> Not necessarily, for the same reason that it's not guaranteed for longs:
> you might need more bits to represent the value of the product than are
> available. If you've got enough bits it'll work the way you expect.
>

Sorry, too terse. Ignore this.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Clark S. Cox III wrote:
> Hyman Rosen wrote:
>> He's dividing integers.

> He did not specify that m was an integer.

Yes he did. He specified that a, and b were long ints, and that m*b was
an integer.

--
Mark Williams

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:

Please keep followups related to standardisation, or take them to other
groups.


===================================== END OF MODERATOR'S COMMENT
ok i'm specifying m's an integer... there's no overflows for m*a &
m*b... neither am i asking for uniqueness (a/b & c/d may be different
but repre. wise same)

ok.. so are you guys saying that in most modern systems (which is what
I'm working with) you get the same result?? So does it have to do with
the compiler or the system in itself? What about GCC on Intel & clones??

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen wrote:
> Clark S. Cox III wrote:
> > No, you aren't guaranteed, because floating point math is inexact.
>
> Yes, you are guaranteed,

Would you please cite the text containing that guarantee? In the
context of comp.std.c++, the approapriate text should be found in the
C++ standard, or in other documents it incorporates by reference. I
don't know of any such guarantee in any of those texts.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net wrote:
> Would you please cite the text containing that guarantee? In the
> context of comp.std.c++, the approapriate text should be found in the
> C++ standard, or in other documents it incorporates by reference. I
> don't know of any such guarantee in any of those texts.

5.6/4 says
     The binary / operator yields the quotient ...
     of the first expression by the second.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen wrote:
> kuyper@wizard.net wrote:
> > Would you please cite the text containing that guarantee? In the
> > context of comp.std.c++, the approapriate text should be found in the
> > C++ standard, or in other documents it incorporates by reference. I
> > don't know of any such guarantee in any of those texts.
>
> 5.6/4 says
>      The binary / operator yields the quotient ...
>      of the first expression by the second.

So, on essentially every real implementation, 1.0/3.0 produces a
non-conforming result?

5.6/4 is not meant to be understood as requiring infinite accuracy.
That clause, and the corresponding ones for other arithmetic operators,
must be understood as allowing an unspecified degree of inaccuracy;
otherwise C++ wouldn't be implementable on any real platform.

if std::numeric_limits<double>::is_iec559 is true, then IEC 559 imposes
some accuracy requirements. However, those requirements aren't
sufficiently strict to provide the guarantee that the OP was asking
for.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kmarkw65@yahoo.com wrote:
> Clark S. Cox III wrote:
> > Hyman Rosen wrote:
> >> He's dividing integers.
>
> > He did not specify that m was an integer.
>
> Yes he did. He specified that a, and b were long ints, and that m*b was
> an integer.

b=2, m=1.5

Now if he had said that m*b had integral type, then your conclusion
would follow. But all he said is that it was an integer.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2005-07-14 10:09:55 +0100, arn_2000@rediffmail.com said:

> let a, b be long integers
>
> suppose i do  doubl(a)/b and double(m*a)/(m*b)  (NOTE: the division is
> by an integer) .... am i guaranteed to get the same result .  (m*a &
> m*b < MAX_LONG)...  my experimentations showed YES atleast in GCC...
> but i've not found anything on the net saying so.
>
> if not : why not?
> if yes : why shud it?

Isn't your code assuming that, for int x, int(double(x)) == x ?
This is not necessarily the case ...

#include <stdio.h>
#include <stdlib.h>

int main (int argc, const char * argv[]) {

    int i ;
    for (i = 0 ; i <= 2147483647 ; ++i) { // note: 2^31 -1
        float f = (float) i ;

        if (((int) f) != i) {
            printf("first loss of precision occurs at: %d, float value
was %g", i, f) ;
            exit(0) ;
        }
    }

    printf("Can't beleive this!") ;
    return 0;
}

[Session started at 2005-07-17 00:21:45 +0100.]
first loss of precision occurs at: 16777217, float value was 1.67772e+07
int2float has exited with status 0.

Obviously you'll get the corresponding behavior when
replacing int and float with long and double, but the
basic idea is the same ...
--
JFB

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

verec wrote:
> Isn't your code assuming that, for int x, int(double(x)) =3D=3D x ?
> This is not necessarily the case ...
>=20
> <snip brute force example for float type>
>=20
> Obviously you'll get the corresponding behavior when
> replacing int and float with long and double, but the
> basic idea is the same ...

=A74.9/2: An rvalue of an integer type or of an enumeration type can be
converted to an rvalue of a floating point type. The result is exact if
possible. [...] [Note: loss of precision occurs if the integral value
cannot be represented exactly as a value of the floating type. ]

This statement gives you certain guarantees if you know how floating
point is implemented on you platform. std::numeric_limits can help you
detect if and when loss of precision might occur, without brute force
trials. For example, as reported by Marc Schoolderman, if the expression:

numeric_limits<double>::digits >=3D numeric_limits<long>::digits
  && numeric_limits<double>::is_iec559 =3D=3D true

is true, than you can assume long(double(x)) =3D x for any long x.

For example, the expression is true on the i386 platform (32-bit for
longs, 43-bit mantissa for doubles) so any long is exactly representable
as a double on that platform. floats have only 24-bit mantissa so the
assumption is no longer valid: loss of precision may occur for integers
greater than 2^24=3D16,777,216.

Alberto

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net wrote:
> if std::numeric_limits<double>::is_iec559 is true, then IEC 559 imposes
> some accuracy requirements. However, those requirements aren't
> sufficiently strict to provide the guarantee that the OP was asking
> for.

Why not? As far as I know, the result is required to be the closest
representable number to the mathematically correct value. Do you
claim that is not the case, or do claim that even if it is, a/b
and ma/mb could then still give different answers (for a, b, m
integers and where a, b, ma and mb are exactly representable)?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen wrote:
> kuyper@wizard.net wrote:
> > if std::numeric_limits<double>::is_iec559 is true, then IEC 559 imposes
> > some accuracy requirements. However, those requirements aren't
> > sufficiently strict to provide the guarantee that the OP was asking
> > for.
>
> Why not? As far as I know, the result is required to be the closest
> representable number to the mathematically correct value. Do you
> claim that is not the case, or do claim that even if it is, a/b
> and ma/mb could then still give different answers (for a, b, m
> integers and where a, b, ma and mb are exactly representable)?

I own a copy of that standard, but I'm having trouble locating it. I
know that in a number of locations, the standard does NOT require that
the result of an operation be the closest representable number to the
mathematically correct value. It allows a certain amount of error,
because algorithms that produce always produce exactly the correct
result are sometimes excessively inefficient. I don't know whether
division is one of the operators for which it allows some uncertainty.

However, my main point wasn't about the accuracy of the division, but
rather about the ability of ma and mb to be exactly representable. The
original poster compared those values with LONG_MAX, which is not
suffient to ensure exact representability as a double-precision number.
If either ma or mb is not exactly representable, you can't count on a/b
and ma/mb producing the same value, even if IEC 559 does apply.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

let a, b be long integers

suppose i do  doubl(a)/b and double(m*a)/(m*b)  (NOTE: the division is
by an integer) .... am i guaranteed to get the same result .  (m*a &
m*b < MAX_LONG)...  my experimentations showed YES atleast in GCC...
but i've not found anything on the net saying so.

if not : why not?
if yes : why shud it?

arnold

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2005-07-14 05:09:55 -0400, arn_2000@rediffmail.com said:

>
>
> let a, b be long integers
>
> suppose i do  doubl(a)/b and double(m*a)/(m*b)  (NOTE: the division is
> by an integer) .... am i guaranteed to get the same result .  (m*a &
> m*b < MAX_LONG)...  my experimentations showed YES atleast in GCC...
> but i've not found anything on the net saying so.
>
> if not : why not?
> if yes : why shud it?

No, you aren't guaranteed, because floating point math is inexact.


--
Clark S. Cox, III
clarkcox3@gmail.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

arn_2000@rediffmail.com wrote:

> suppose i do  doubl(a)/b and double(m*a)/(m*b)  (NOTE: the division is
> by an integer) .... am i guaranteed to get the same result .  (m*a &
> m*b < MAX_LONG)...  my experimentations showed YES atleast in GCC...
> but i've not found anything on the net saying so.

Not portably. There is nothing in the standard that guarantees a double
can hold all the values representable by a long. And in fact, double
commonly has 53 significant bits, while "long" can have 63bits on a
64bit machine, in which case you lose precision.

However, C++ allows you to examine the significant bits in fundamental
types (and whether they obey IEEE754/IEC559 rules) by providing the
std::numeric_limits<> template in <limits>. Using it; I would say that

IF  numeric_limits<double>::digits >= numeric_limits<long>::digits
AND numeric_limits<double>::is_iec559 == true

Then, yes, you have your guarantee.

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Clark S. Cox III wrote:
> No, you aren't guaranteed, because floating point math is inexact.

Yes, you are guaranteed, except on unusual machines
where doubles do not have enough mantissa bits to
represent all long integers exactly, or on machines
where floating division does not give you the result
closest to the correct mathematical value.

He's dividing integers.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Clark S. Cox III wrote:
> On 2005-07-14 05:09:55 -0400, arn_2000@rediffmail.com said:
>
>>
>>
>> let a, b be long integers
>>
>> suppose i do  doubl(a)/b and double(m*a)/(m*b)  (NOTE: the division is
>> by an integer) .... am i guaranteed to get the same result .  (m*a &
>> m*b < MAX_LONG)...  my experimentations showed YES atleast in GCC...
>> but i've not found anything on the net saying so.
>>
>> if not : why not?
>> if yes : why shud it?
>
>
> No, you aren't guaranteed, because floating point math is inexact.

     Assuming, in the above, that m is an integer...

     Most computers manufactured today are IEEE 794 floating
point compliant for general floating point arithmetic.
Not all.  IBM and UNISYS legacy mainframes are not.
Some digital signal processing parts are not.  Some
game machines are not.  Some proprietary modes in
CPUs (AltiVec, etc.) are not.  But ordinary floating
point arithmetic on PC-type machines is IEEE 794
compliant.

     In IEEE 794 floating point, you are guaranteed that
if an integer value is exactly representable in floating
point, addition, subtraction, and multiplication
results that fit in the mantissa will be exact.
There are also some rounding guarantees.
(This matters.  In some older representations,
2.0 + 2.0 results in something like 3.9999999999297.
Business programming was done with decimal representations
for decades because of problems like that. IEEE 794 made
floating point acceptable for business work.)

     Division is more complicated.  You need to read
the IEEE 794 standard and Kahan's papers to understand
its limitations.

     C++ does not mandate data representations, so it
doesn't mandate IEEE 794 floating point compliance.

     Now and then there's some discussion as to whether
C and C++ should finally drop support for older architectures.
C and C++ will still run on non-byte architectures,
although much software will not port properly.
The 36-bit mainframes are almost, but not quite, dead.
You can still buy 36-bit Unisys ClearPath servers, and
even run C++ on them.  This is the world's oldest
computer architecture still in use, dating back to
the UNIVAC 1103A from 1956.  Next year, 50 years
of 36-bit UNIVACs.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]