On 25-Jul-2000, Julian Assange <[EMAIL PROTECTED]> wrote:
> Fergus Henderson <[EMAIL PROTECTED]> writes:
>
> > Jon Fairbairn was talking about Haskell. MSVC is a C/C++ compiler,
> > not a Haskell compiler. For C and C++, there are many many areas of
> > undefined, unspecified, or implementation
Fergus Henderson <[EMAIL PROTECTED]> writes:
> Jon Fairbairn was talking about Haskell. MSVC is a C/C++ compiler,
> not a Haskell compiler. For C and C++, there are many many areas of
> undefined, unspecified, or implementation-defined behaviour. If a
> C or C++ program gives different behavio
Julian Assange wrote:
> Microsoft VCC once (still?) suffers from this problem. Whether
> it is because it accesses random, unassigned memory locations
> or because the optimiser has time thesholds, is unknown.
Optimisers for Intel can produce different results on floating point
because floating po
On 23-Jul-2000, Julian Assange <[EMAIL PROTECTED]> wrote:
> Jon Fairbairn <[EMAIL PROTECTED]> writes:
> > [George Russell wrote:]
> > > Surely this is obvious to Haskell programmers?
> > to me, anyway. If two runs (with different flags) of the
> > compiler produce programmes that give different r
Julian Assange <[EMAIL PROTECTED]> writes:
> complex-tecture pov-ray picture distributed to a 56 bit IEEE machine
> and a 64 bit one. The when the picture elements are stitched back
Is this really due to color differences of the order of 10^-17, or
rather due to different libc-inherited random n
Julian Assange wrote:
> [EMAIL PROTECTED] (Carl R. Witty) writes:
>
> > Fergus that this behavior is undesirable and should be avoided for
> > Haskell, unless a flag like "-funsafe-fast-math" is provided.
> >
> > double inverse(double val) {
> > if (val == 0) {
> > printf("Oops! divided by
[EMAIL PROTECTED] (Carl R. Witty) writes:
> Fergus that this behavior is undesirable and should be avoided for
> Haskell, unless a flag like "-funsafe-fast-math" is provided.
>
> double inverse(double val) {
> if (val == 0) {
> printf("Oops! divided by zero\n");
> abort();
> } else
Fergus Henderson <[EMAIL PROTECTED]> writes:
> but nevertheless, Haskell or any other language which aims to be
> referentially transparent, for any given program execution the sum
> should be the same each time in that program execution.
While that's theortically nice, I'm not sure that stateme
Jon Fairbairn <[EMAIL PROTECTED]> writes:
> to me, anyway. If two runs (with different flags) of the
> compiler produce programmes that give different results,
> then one of them isn't adhering to the standard, (and so
> should be noted as such).
Microsoft VCC once (still?) suffers from this pr
Tue, 18 Jul 2000 14:48:36 +0200 (MET DST), Wilhelm B. Kloke
<[EMAIL PROTECTED]> pisze:
> If you mind that this could be exploited to create side-effects,
> you have to wrap FP into a monad.
Not side effects but "unstable" values. IMHO it would be too pedantic,
although theoretically necessary.
Sven Panne wrote:
> (As an aside: I *hate* standards which are not freely
> available, I've never seen a real IEEE-754 document. A $4000 annual
> subscription price for a single person is ridiculous, and I would probably
> have slight problems persuade my company to buy the $40.000 enterprise
> su
> 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
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
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
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
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
"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
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
> 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
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
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
> 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
17 Jul 2000 18:24:54 GMT, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> pisze:
> >* If the -fstrictfp Option is given, *all* calculations (at
> > compile time and runtime) are done with the precision/range
> > of the type in question.
> Wouldn't it be simpler
[...]
I did not reali
Mon, 17 Jul 2000 19:27:05 +0200, Sven Panne <[EMAIL PROTECTED]>
pisze:
>* If the -fstrictfp Option is given, *all* calculations (at
> compile time and runtime) are done with the precision/range
> of the type in question.
>
>* If the option is not given, you can sometimes have
[ Redirected to Haskell list ]
Michael Marte wrote:
> When adding the three double numbers
> 0.7, 0.2, and 0.1, a ghc 4.07-compiled program (compilation flag -O)
> yields 0.. Whatever this string stands for, [...]
The closest thing the addition of those numbers can give you with
25 matches
Mail list logo
