> IMHO GHC's documentation should clearly warn that programmers should
> not depend on even basic stability and exactness of floating point
> computations, and only stability is provided by -fstrictfp.
GHC is no different from any other compiler for any other language in
this respect. Floating
Tue, 18 Jul 2000 12:19:32 +0100, Keith Wansbrough <[EMAIL PROTECTED]>
pisze:
> > IMHO GHC's documentation should clearly warn that programmers should
> > not depend on even basic stability and exactness of floating point
> > computations, and only stability is provided by -fstrictfp.
>
> GHC is
Keith Wansbrough wrote:
> GHC is no different from any other compiler for any other language in
> this respect. Floating-point values are *not* the mathematical `real
> numbers', and should not be treated as such. This is second-year CS
> course material.
No, but they ARE, assuming IEEE arithmet
> No, but they ARE, assuming IEEE arithmetic,
which is what the Report says, isn't it.
> discrete mathematical objects with an arithmetic as well
> defined as that on the integers. To do constant folding
> according to different rules is, IMHO, outrageous.
yes
> Surely this is obvious to Has
In article [EMAIL PROTECTED]>,
George Russell <[EMAIL PROTECTED]> wrote:
>No, but they ARE, assuming IEEE arithmetic, discrete mathematical
>objects with an arithmetic as well defined as that on the integers.
>To do constant folding according to different rules is, IMHO,
>outrageous. One should
"Wilhelm B. Kloke" wrote:
> IMHO you are not right in this. See W. Kahan on the ridiculous Java
> restriction in FP reproducibility.
We are getting into deep waters here but I think I _am_ right in this case.
Kahan's point (I presume you are referring to his excellent (online)
paper "How JAVA's Fl
Hmmm, I've never thought that two simple additions would lead to such
a riot... :-)
First of all: Even after re-reading the report I can't see that IEEE
arithmetic is *required* by it. The representation of floating point
values is explicitly stated as "implementation-defined", only the range
an
On 18-Jul-2000, Keith Wansbrough <[EMAIL PROTECTED]> wrote:
> > IMHO GHC's documentation should clearly warn that programmers should
> > not depend on even basic stability and exactness of floating point
> > computations, and only stability is provided by -fstrictfp.
>
> GHC is no different from
On 18-Jul-2000, Sven Panne <[EMAIL PROTECTED]> wrote:
>
> Nevertheless, there seems to be some consensus that optimization should
> not change the outcome of a computation. Note that GCC's -O flag *does*
> change it, at least if -ffloat-store is not given in addition. The newly
> introduced GHC o
Fergus Henderson <[EMAIL PROTECTED]> writes:
> Yes, but for any given Haskell program execution, the sum of any two
> floating-point values should be the same every time you compute it.
> In general it need not be the same as the sum of the equivalent real
> numbers, because floating point number
> Keith Wansbrough wrote:
> > GHC is no different from any other compiler for any other language in
> > this respect. Floating-point values are *not* the mathematical `real
> > numbers', and should not be treated as such. This is second-year CS
> > course material.
> One should not have to ad
I think many of the issues were discussed with great clarity on slashdot.
If we get the relevant critical mass of functional programmers, you will
definitely be hearing from us. Off the top of my head here are some
Haskell specific things that we need:
* HSP pages (like ASP or JSP or PHP)
* in me
12 matches
Mail list logo
