Re: fractions and floating point

On Thu, 14 Jul 2005 11:32:22 +0200, Steffen wrote:

> Hi,
>
> is it possible to have two fractions, which (mathematically) have the
> order a/b < c/d (a,b,c,d integers), but when (correctly) converted into
> floating point representation just have the opposite order?

They don't have to be integers, but we'll need to assume that we are
talking about values that are exactly representable in the floating point
type (i.e. there is no approximation step before the division takes
place). This isn't the case for all integers in the range of representable
values of a floating point type.

> The idea is that the two fractions are almost identical and that the
> error introduced by going to floating point representation is bigger
> than the exact difference, but different for the two fractions such that
> it somehow turns them around.

The property you want isn't guaranteed by C, but it may well be guaranteed
by IEEE 754 floating point arithmetic. It does follow when inexact
results are always rounded to the nearest representable floating point
value ***when using a consistent precision***. However C allows
intermediate results to be evaluated at a higher precision than the
underlying type represents, and this doesn't have to be consistent. So a/b
could in theory be evaluated at a different precision to c/d, and the
differing rounding that results could cause the ordering to be broken.

> I tried some numbers, but so far it always was ok.
>
> I know that this depends on the way floating points are represented, so
> the more precise question would be: is there a standard that would
> ensure that this never happens? Does somebody have a concrete example
> for a specific platform?

The trouble is that this is VERY dependent on the architecture and the
specific code that the compiler generates. For example on x86 systems
FPU registers are 80 bits (although this is settable) and float and double
values tend to be calcuated and held at a higher precision in registers
than when they are stored in memory. So if the compiler decides to store
one intermediate result in memory but not the other the problem can occur.

Lawrence
.

Relevant Pages

  • Re: Type Question
    ... this is true of all programming languages that use floating point ... Common Lisp comes pretty close to providing that as ... Change the floating point representation. ... computationally efficient binary representation, the fractions should be ...
    (comp.lang.lisp)
  • Re: How do you keep track of what all the numbers mean?
    ... that if you develop a floating point representation of a system, ... but I would suspect that scaling constants is a main part of it. ... There will be an assumed scaling between the floating point ... will depend upon the input signal power. ...
    (comp.dsp)
  • Re: Rounding of the double
    ... John von Neumann suggested that only fixed-point integers should be used because floating ... If you choose your representation as double, then you have to live with the consequences. ... you can never get precision in any computation on a computer than involves ... MVP Tips:http://www.flounder.com/mvp_tips.htm- Hide quoted text - ...
    (microsoft.public.vc.mfc)
  • Re: fractions and floating point
    ... > floating point representation just have the opposite order? ... > The idea is that the two fractions are almost identical and that the error ... > introduced by going to floating point representation is bigger than the ...
    (comp.lang.c)
  • fractions and floating point
    ... is it possible to have two fractions, which have the order a/b < c/d, but when converted into floating point representation just have the opposite order? ... The idea is that the two fractions are almost identical and that the error introduced by going to floating point representation is bigger than the exact difference, but different for the two fractions such that it somehow turns them around. ...
    (comp.lang.c)