In article <52h0lt$444@rap.SanDiegoCA.NCR.COM> swf@elsegundoca.ncr.com
(Stan Friesen) writes:

|> In article <51sc7a$9er@gap.cco.caltech.edu>, dacut@ugcs.caltech.edu (David A. Cuthbert) writes:
|> |>
|> |> One caveat with FP numbers that is often overlooked is that there are
|> |> many other numbers that cannot be expressed exactly other than the
|> |> obvious (irrationals,

|> Computers cannot really meaningfully represnt irrationals at all.
|> No matter *what* representation one uses, the end product will ultimately
|> be a rational number - albeit possibly with an enormous denominator.

The verb should be "do not normally", not "cannot".  Computers can
represent at least certain classes of irrational numbers (say roots of a
polynomial) exactly.  Generally, they do not because such
representations are large, awkward, and relatively slow.

|> |> repeating decimals):  repeating decimals in the
|> |> machine representation (usually radix-2).  So 1/5 (=0.00110011...[2])
|> |> also has problems being represented (though machine rounding will make
|> |> it appear correctly as 0.2).

|> Yep, is the sort of thing I had in mind. (I thinks 1/3 is a repeating "decimal"
|> in both decimal and radix-2 representations).

Correct, but there is nothing to prevent you from writing a Rational
class which represents its numbers as the quotient of two integers.

|> The net result, of course, is that numeric results using machine FP can be
|> unintuitive.  Tuning numerical extensive calculations so that the final result
|> does not lose too much precision is a trickly, and difficult process.
|> [UC Berkeley even has an entire course just on that one subject].

Agreed.  What you say above is generally true concerning normal use.
The exceptions (precise representation of irrationals or arbitrary
rationals) are just that: exceptions, and are only used in special
cases.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <51sc7a$9er@gap.cco.caltech.edu>, dacut@ugcs.caltech.edu (David A. Cuthbert) writes:
|>
|> One caveat with FP numbers that is often overlooked is that there are
|> many other numbers that cannot be expressed exactly other than the
|> obvious (irrationals,

Computers cannot really meaningfully represnt irrationals at all.
No matter *what* representation one uses, the end product will ultimately
be a rational number - albeit possibly with an enormous denominator.

|> repeating decimals):  repeating decimals in the
|> machine representation (usually radix-2).  So 1/5 (=0.00110011...[2])
|> also has problems being represented (though machine rounding will make
|> it appear correctly as 0.2).

Yep, is the sort of thing I had in mind. (I thinks 1/3 is a repeating "decimal"
in both decimal and radix-2 representations).

The net result, of course, is that numeric results using machine FP can be
unintuitive.  Tuning numerical extensive calculations so that the final result
does not lose too much precision is a trickly, and difficult process.
[UC Berkeley even has an entire course just on that one subject].

--
swf@elsegundoca.ncr.com  sarima@ix.netcom.com

The peace of God be with you.


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <51n4mc$hu3@rap.sandiegoca.ncr.com>,
Stan Friesen <swf@elsegundoca.ncr.com> wrote:
>On the other hand, with FP, there are an infinite number of rational values
>between the minumum and the maximum that *cannot* be represented by the
>machine representation. (Say, for instance, 1/3).

One caveat with FP numbers that is often overlooked is that there are
many other numbers that cannot be expressed exactly other than the
obvious (irrationals, repeating decimals):  repeating decimals in the
machine representation (usually radix-2).  So 1/5 (=0.00110011...[2])
also has problems being represented (though machine rounding will make
it appear correctly as 0.2).

For exact precision with rational numbers, the only way to handle such
a need is with a fraction class whose internal representation uses a
numerical type that possesses the is_exact property.  Fortunately,
such a need is infrequent.

--
David A. Cuthbert
dacut@ugcs.caltech.edu


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <515pj9$68n@krant.cs.ruu.nl>, geert@cs.ruu.nl (Geert-Jan Giezeman) writes:
|>
|> The numeric_limits class has a member is_exact. The DWP says that
|> this member is true if the type uses an exact representation. What is
|> meant by this?  A floating point number (not exact, according to
|> example 18.2.1.4) represents exactly one real number just as an int.
|>
It means that some mathematically legitimate values do not have exact
representations in the encoding method used.

Integers are exact on all machines I know of, since all mathematical integers
within the allowed range are represented directly and exactly.

On the other hand, with FP, there are an infinite number of rational values
between the minumum and the maximum that *cannot* be represented by the machine
representation. (Say, for instance, 1/3).

|> It may also mean that computation is exact, but this is not how it is
|> stated.  Also, what would this mean? +, - and * are exact for
|> integers (apart from overflow), but / is not, if we take the
|> mathematical meaning of /, where (a/b)*b == a in all cases.

For integers '/' is defined to mean floor[a/b], not a/b.

--
swf@elsegundoca.ncr.com  sarima@ix.netcom.com

The peace of God be with you.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

The numeric_limits class has a member is_exact. The DWP says that
this member is true if the type uses an exact representation. What is
meant by this?  A floating point number (not exact, according to
example 18.2.1.4) represents exactly one real number just as an int.

It may also mean that computation is exact, but this is not how it is
stated.  Also, what would this mean? +, - and * are exact for
integers (apart from overflow), but / is not, if we take the
mathematical meaning of /, where (a/b)*b == a in all cases. We can
make / exact if we alter the definition of /, but then we can also
call the * of floats exact if we specify how we are rounding.

Can anyone explain what is meant exactly?
Is the wording in the current draft still the same?

--
Geert-Jan Giezeman, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 2534096
Telefax:   +31 30 2513791   Email: geert@cs.ruu.nl


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

geert@cs.ruu.nl (Geert-Jan Giezeman) wrote:
> The numeric_limits class has a member is_exact. The DWP says that
> this member is true if the type uses an exact representation. What is
> meant by this?  A floating point number (not exact, according to
> example 18.2.1.4) represents exactly one real number just as an int.
>
> It may also mean that computation is exact, but this is not how it is
> stated.  Also, what would this mean? +, - and * are exact for
> integers (apart from overflow), but / is not, if we take the
> mathematical meaning of /, where (a/b)*b == a in all cases. We can
> make / exact if we alter the definition of /, but then we can also
> call the * of floats exact if we specify how we are rounding.
>
> Can anyone explain what is meant exactly?
> Is the wording in the current draft still the same?
>
> --
> Geert-Jan Giezeman, Dept of Computer Science, Utrecht University,
> Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
> Telephone: +31 30 2534096
> Telefax:   +31 30 2513791   Email: geert@cs.ruu.nl

is_exact is false for floats because a floating point number does not represent
exactly one number, it represents a range which covers an infinite number of
real world numbers. The magnitude of the range depends on the value of the float
(it can probably be expressed as a percentage).

The following program might help:

#include <iostream.h>
#include <iomanip.h>

int main()
{
    float   f = 16777216;

    unsigned long i;

    for (i = 0; i < 1000000; i++)
    {
        f += 1;
    }

    cout << setprecision(10) << f << endl;

    return (0);
}

The two machines I tried it on (HP 9000/700 and DEC Alphaserver 2100) output
16777216. If a bank added my millions (!) together in this way I would be a
little upset! 16777216 is the first number that it occurs at (on my machines)
because the floats have a 24-bit mantissa (2^24 == 16777216).

An integer representation is exact because an integer represents a point on the
continuum of real world numbers - with suitably sized integers, the above
program would produce the correct output.

Paul



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In comp.std.c++ you write:

>is_exact is false for floats because a floating point number does not represent
>exactly one number, it represents a range which covers an infinite number of
>real world numbers.

That's a nice way of putting it, but can I find this somewhere in the
standard?

What one could say is something like the following:

A number type is exact iff there is a one to one correspondence from the
mathematical type that is modelled (within the bounds stated by
is_bounded, min, max) to the computer type.

float and double model the (mathematical) reals.
short, int, long etc. model the (mathematical) integers.


>The following program might help:
>
>    float   f = 16777216;
>    unsigned long i;
>    for (i = 0; i < 1000000; i++)
>        f += 1;

This shows that the addition <computation> is not exact, not that the
<representation> is not exact.

>An integer representation is exact because an integer represents a point on the
>continuum of real world numbers - with suitably sized integers, the above
>program would produce the correct output.

If your bank adds your millions in that way, pay your debts in the following
way!

const int Days_in_a_year = 365;
void pay_debt(int debt)
{
  int daily_debt = debt/Days_in_a_year;
  for (int i=0; i<Days_in_a_year; i++)
     pay(daily_debt);
}

main()
{  pay_debt(364); }


--
Geert-Jan Giezeman, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 2534096
Telefax:   +31 30 2513791   Email: geert@cs.ruu.nl
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]