This is compatible with IEEE-754. Section 7.2 says
7.2 Invalid operation
For operations producing results in floating-point format, the default
result of an operation that signals the
invalid operation exception shall be a quiet NaN that should provide
some diagnostic information (see 6.2)
Zitat von C Western :
My first reaction is that
SetExceptionMask([exDenormalized,exZeroDivide,exOverflow,exUnderflow,exPrecision])
would be required (I can't remember what the default is), but it
doesn't stop the error (x86_64/linux). I suspect a bug, though I am
slightly surprised it hasn'
Quoting James Richters :
SetExceptionMask(GetExceptionMask + [exInvalidOp]); Works!
Thank you for the help!
I'm curious why things like SQRT(-1) just produce NAN without
needing to change the exception mask and (+inf) - (+inf) does not
behave the same way. They both are invalid,
Zitat von Adriaan van Os :
Even with masked exceptions, runtime errors are produced in the Math
unit. That is not conformant to the standard.
Even with masked exInvalidOp? Can you give an example?
___
fpc-pascal maillist - fpc-pascal@lists.freepa
Zitat von James Richters :
For operations producing results in floating-point format, the
default result of an operation that
signals the invalid operation exception shall be a quiet NaN that
should provide some diagnostic
information (see 6.2).
If it shall be a quiet NaN doesn't that mea
Zitat von James Richters :
The fact that it raises the exception at all makes it a signaling
NaN not a quiet Nan, but they are supposed to be Quiet Nan which
never throw the exception according to the specification which
clearly states they are Quiet Nans, not Signaling Nans.
Suppressi
Zitat von Vojtěch Čihák :
will not give any warning even if correct result is 2.5.
It is simply absurd because it is not about shooting your own foot.
Compiler is not a crystal ball, it does what you tell him.
If you need floating point, use floating point types and floating
point division (
Zitat von Florian Klämpfl :
In pascal, the rule applies that *the resulting type of an operation
does not depend on the type a value is assigned too*. So: 1.0 fits
perfectly into a single, 3.0 as well, they are single constants (you
didn't tell the compiler otherwise). Nobody wants that unneces
Zitat von Florian Klämpfl :
So you want float constants being evaluated always with full
precision (which would be required for consistency) causing any
floating point expression containing a constant being evaluated with
full precision as well?
Yes, at least as default or selectable p
Zitat von Florian Klämpfl :
But actually, I just found out that we have something like this
already for years:
{$minfpconstprec 64}
OK, then two questions remain: Why does is occur/apply only for
(newer?) 3.1.1 versions?
And why is there no option to select the maximum precision for th
Zitat von Martok :
To make sure this works, one has to manually make the const
expression be of the
type required:
const
e: Extended = Extended(1.0) / 3.0;
I seem to remember that this was once documented somewhere for Delphi. Can't
seem to find it though, so maybe it was a 3rd-party book?
Zitat von Florian Klaempfl :
I am happy to implement this in delphi mode, but it requires some
documentation references how delphi evaluates such expressions
(which precision is used when and why) and how they are handled in
expressions.
These links may be of interest:
http://docwiki.e
This is one of the most useless collection of floating point myths I
have seen since a long time.
I don't know why you want to compare two floats, but you'd better
use currency type. Float is for calculus, but comparing
float1=float2 (or float1>float2) is rolling the dice. Obviously, the
m
13 matches
Mail list logo
