Infinity + Infinity (or NegInfinity - NegInfinity)
Skybuck Flying
I was just wondering what happens if "Infinity" is added to "Infinity" when
it comes to floating point numbers ?
And also what happens if "Negative Infinity" is added to "Negative
Infinity"... ?
In Delphi these are defined as follows (in the math.pas unit):
const
Infinity = 1.0 / 0.0;
NegInfinity = -1.0 / 0.0;
As far as I know this conforms to some kind of floating point standard.
I haven't tried to add these two numbers together yet, but I will soon try
it out.
I am just wondering from a theoretical point of view what should happen ?
Should it wrap back from infinity to infinity ?
Should it wrap back from negative infinity to negative infinity ?
Or will perhaps something weird happen ?
Bye,
Skybuck.
Robert Myers
> it out.
>
> I am just wondering from a theoretical point of view what should happen ?
>
> Should it wrap back from infinity to infinity ?
>
> Should it wrap back from negative infinity to negative infinity ?
>
> Or will perhaps something weird happen ?
>
but to add plus and minus infinity and get anything but "Who knows?,"
you have to be a quantum field theorist.
Robert.
James Kuyper
then IEC 60559 should apply. I don't have a copy of that standard, but
the C standard indicates that it's closely related to ANSI/IEEE 854,
which I do have. It specifies:
"The invalid operation exception is signaled if an operand is invalid
for the operation being performed. The floating point result delivered
when the exception occurs without a trap shall be a quiet NaN. The
invalid operations are as follows:
...
(2) Addition or subtraction: magnitude subtraction of infinities such as
(+∞) + (-∞)"
The symbols in those parentheses are supposed to be infinities, though
I've found it's hard to predict whether or not symbols will display
properly.
--
James Kuyper
William Elliot
> I was just wondering what happens if "Infinity" is added to "Infinity" when
> it comes to floating point numbers ?
>
> And also what happens if "Negative Infinity" is added to "Negative
> Infinity"... ?
There is an oo and -oo defined in the extended reals and within the
extended reals one may consider that oo + oo = oo and -oo + -oo = -oo.
> In Delphi these are defined as follows (in the math.pas unit):
>
know math. As far as computer baloney is concerned, infinity is
simply an over load error message.
> const
> Infinity = 1.0 / 0.0;
> NegInfinity = -1.0 / 0.0;
> As far as I know this conforms to some kind of floating point standard.
> I haven't tried to add these two numbers together yet, but I will soon try it
> out.
If you naively manipulate the symbols, 1/0 + -1/0 = (1 + -1)/0 = 0/0
you are again faced with an undefined indeterminate.
> I am just wondering from a theoretical point of view what should happen ?
>
> Should it wrap back from infinity to infinity ?
> Should it wrap back from negative infinity to negative infinity ?
> Or will perhaps something weird happen ?
>
Speaking of infinite, do you know that the infinity of integers
is smaller than the infinity of real numbers and the infinity
for real numbers is smaller than the infinity of the subsets of
real numbers and that there are more, ever larger infinities -
more infinities than any infinite number?
Conway has constructed a field of infinite numbers, containing all the
infinite numbers of set theory indicated above. He even constructs
sqr aleph_0. I would think in his theory that aleph_eta - aleph_eta = 0.
Here aleph_0 is the first infinite cardinal and aleph_eta is the
eta-th infinite cardinal of a transfinite sequence of all infinite
numbers over all of the ordinal numbers.
There is a forth type of infinite, the geometric infinity
of the point at infinity where in Euclidean space, parallel
lines meet. In fact there's even a line at finity of all
the points at infinity, one for each different slope m, where
all the parallel lines with slope m meet.
There are other types of infinity - the philosophical, the theological,
the science fiction and the computer hack infinities - each progressively
better than the other for infinite nonsense.
Jasen Betts
> Hello,
>
> I was just wondering what happens if "Infinity" is added to "Infinity" when
> it comes to floating point numbers ?
>
> And also what happens if "Negative Infinity" is added to "Negative
> Infinity"... ?
> In Delphi these are defined as follows (in the math.pas unit):
>
> const
> Infinity = 1.0 / 0.0;
> NegInfinity = -1.0 / 0.0;
and can rely on the floating point arithmetic to give the
representations it wants.
> As far as I know this conforms to some kind of floating point standard.
> I haven't tried to add these two numbers together yet, but I will soon try
> it out.
0.0/0.0 gives.
> Or will perhaps something weird happen ?
( 1.0 / 0.0 ) + ( -1.0 / 0.0 )
= ( 1.0 + -1.0 ) / 0.0
= 0.0 / 0.0
http://en.wikipedia.org/wiki/NaN
--
⚂⚃ 100% natural
--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---
Jasen Betts
> On Sat, 8 Oct 2011, Skybuck Flying wrote:
>
>> I was just wondering what happens if "Infinity" is added to "Infinity" when
>> it comes to floating point numbers ?
>>
>> And also what happens if "Negative Infinity" is added to "Negative
>> Infinity"... ?
>
> The infinity of analysis, oo, is not defined by floating point numbers.
with a few exceptions (+Inf, -Inf, NaN) floating point can only
represent a finite subset of the rational numbers)
Gordon Burditt
and IEEE 754 include such numbers as -1.0, 0.0, 1.0, and 1.5 .
If your point is that neither set has the other as a subset, point
granted, but "disjoint" isn't the right word here.
> with a few exceptions (+Inf, -Inf, NaN) floating point can only
> represent a finite subset of the rational numbers)
infinite number of bits to represent.
Skybuck Flying
I was mostly interested in +inf + +inf. (Positive infinity + Positive
infinity)
However perhaps that situation is now unlikely in my algorithm so my
interest in this special situation is dwindling/decreasing ;)
But maybe this situation might still pop-up and then my interest in it might
go back up ;) :)
So don't expect me to look to deeply into it for now ;) (If my interest in
it changes, I'll let you know, could be within a few days, otherwise years,
or maybe never...)
Bye,
Skybuck.
Kaba
> Hello,
>
> I was just wondering what happens if "Infinity" is added to "Infinity" when
> it comes to floating point numbers ?
>
> And also what happens if "Negative Infinity" is added to "Negative
> Infinity"... ?
>
> In Delphi these are defined as follows (in the math.pas unit):
>
> const
> Infinity = 1.0 / 0.0;
> NegInfinity = -1.0 / 0.0;
>
> As far as I know this conforms to some kind of floating point standard.
Here are some interesting properties of the IEEE floating point
standard, which is the underlying technology behind most home computers.
The behaviour of high-level programming languages tend to mirror it
closely. Let x be some positive, regular, floating point number. The
basic mathematical model is the affinely extended reals, but the
standard defines a bit more (see division by zero).
Zeros:
* There are two zeros, +0 and -0.
* -0 = -(+0)
* Floating point comparison is defined so that +0 = -0 is true.
Not-A-Number (NaN):
* Produced as an error value, for example with +0 / +0.
* Multiplying, adding, subtracting or dividing with a NaN produces a
NaN. The NaN is said to be propagated.
* All comparisons (<, >, =, !=, <=, >=) with a NaN yield false.
Infinities:
* There is infinity (oo) and minus infinity (-oo).
* -oo = -(oo)
* oo + oo = oo
* -oo + -oo = -oo
* oo + -oo = NaN
* +-x + oo = oo
* +-x + -oo = -oo
* Subtraction similarly...
Division by zero:
* +-x / +0 = +-oo
* +-x / -0 = -+oo
* +-0 / +-0 = NaN
Multiplication by infinities:
* +-x * oo = +-oo
* +-x * -oo = -+oo
* +0 * +-oo = +-0
* -0 * +-oo = -+0
Division by infinities:
* +-x / oo = +-0
* +-x / -oo = -+0
christian.bau
> Multiplication by infinities:
>
> * +-x * oo = +-oo
> * +-x * -oo = -+oo
> * +0 * +-oo = +-0
> * -0 * +-oo = -+0
The 0 times infinity case does not agree with IEEE754.
And note that not all comparisons with NaN yield "false": x != NaN and
NaN != x yields "true".
nm...@cam.ac.uk
>
>Here are some interesting properties of the IEEE floating point
>standard, which is the underlying technology behind most home computers.
>The behaviour of high-level programming languages tend to mirror it
>closely.
> Let x be some positive, regular, floating point number. The
>basic mathematical model is the affinely extended reals, but the
>standard defines a bit more (see division by zero).
respects where traditional floating-point isn't.
Regards,
Nick Maclaren.
Kaba
Kaba
> Kaba <ka...@nowhere.com> wrote:
> >
> >Here are some interesting properties of the IEEE floating point
> >standard, which is the underlying technology behind most home computers.
> >The behaviour of high-level programming languages tend to mirror it
> >closely.
>
> Oh, no, they don't! Not even if you had got it correct.
in and make a better statement, on where the behaviour agreees and where
it differs.
> > Let x be some positive, regular, floating point number. The
> >basic mathematical model is the affinely extended reals, but the
> >standard defines a bit more (see division by zero).
>
> Its signed zero handling is incompatible with that model in several
> respects where traditional floating-point isn't.
However, they negative and positive zero can not be differentiated by
their action, expect when dividing by zero. But dividing by zero is not
defined in the affinely extended reals. Thus, unless I am missing
something, the IEEE floating point is a fine model for the affinely
extended reals.
--
http://kaba.hilvi.org
nm...@cam.ac.uk
Kaba <ka...@nowhere.com> wrote:
>> >
>> >Here are some interesting properties of the IEEE floating point
>> >standard, which is the underlying technology behind most home computers.
>> >The behaviour of high-level programming languages tend to mirror it
>> >closely.
>>
>> Oh, no, they don't! Not even if you had got it correct.
>
>Simply asserting that isn't particularly helpful. Maybe you could step
>in and make a better statement, on where the behaviour agreees and where
>it differs.
The IEEE 754 model is incompatible with most language's arithmetic
models, so it isn't possible (even in theory) to answer that question
for the vast majority of languages. If you really want to know the
details, you will have to start by studying various language standards
and specifications - i.e. the definitions of the languages, not
someone's summary of them.
>> > Let x be some positive, regular, floating point number. The
>> >basic mathematical model is the affinely extended reals, but the
>> >standard defines a bit more (see division by zero).
>>
>> Its signed zero handling is incompatible with that model in several
>> respects where traditional floating-point isn't.
>
>I disagree. Mathematics has one zero, the IEEE floating point has two.
>However, they negative and positive zero can not be differentiated by
>their action, expect when dividing by zero. But dividing by zero is not
>defined in the affinely extended reals. Thus, unless I am missing
>something, the IEEE floating point is a fine model for the affinely
>extended reals.
You are. IEEE 754 also has a sign test function, and that means
that -(x-y) is distinguishable from y-x, whereas -(x-y) = y-x for
in that form of mathematics.
Regards,
Nick Maclaren.
James Kuyper
> In article <MPG.28fad914b...@news.cc.tut.fi>,
> Kaba <ka...@nowhere.com> wrote:
> models,
typical incompatibilities are. I doubt that the writers of that standard
intended it to be incompatible with those languages, and I doubt that
the designers of all of those languages went out of their way to be
incompatible with that standard, which suggests that any such
incompatibility is likely to be subtle. If so, reading the IEEE 754
standard and comparing it with the language standards is not likely to
be fruitful without at least a hint of what incompatibilities to look for.
...
>> However, they negative and positive zero can not be differentiated by
>> their action, expect when dividing by zero. But dividing by zero is not
>> defined in the affinely extended reals. Thus, unless I am missing
>> something, the IEEE floating point is a fine model for the affinely
>> extended reals.
>
> You are. IEEE 754 also has a sign test function, and that means
> that -(x-y) is distinguishable from y-x, whereas -(x-y) = y-x for
> in that form of mathematics.
semantics, is part of the definition of affinely extended reals.
--
James Kuyper
Robert Myers
Thank you for introducing me to the affinely extended reals.
I struggled vainly to come to grips with many odd objects in theoretical
physics, until I finally grasped that, for someone with a pedestrian
mind like mine, these discussions make sense only if you are willing to
dig into the implied limiting processes in detail.
Appealing to arbitrary standards is well past silly. If you can't
define the limiting processes you are assuming in pedestrian terms, you
are either a genius or you don't know what you are talking about.
Robert.
nm...@cam.ac.uk
>...
>> The IEEE 754 model is incompatible with most language's arithmetic
>> models,
>
>That claim would be more useful if you would at least hint at what the
>typical incompatibilities are. I doubt that the writers of that standard
>intended it to be incompatible with those languages, and I doubt that
>the designers of all of those languages went out of their way to be
>incompatible with that standard, which suggests that any such
>incompatibility is likely to be subtle. If so, reading the IEEE 754
>standard and comparing it with the language standards is not likely to
>be fruitful without at least a hint of what incompatibilities to look for.
any match between the basic concepts, what on earth is the point
in looking for detailed incompatibilities? I said that the MODELS
were incompatible and not that the DETAILS were.
The clearest standard in this respect is Fortran: look at 7.1.8.3
in Fortran 2003 "Once the interpretation has been established in
accordance with those rules, the processor may evaluate any
mathematically equivalent expression, provided that the integrity of
parentheses is not violated." But that is NOT the only relevant
specification of the model, even in Fortran.
Look, when I raised this on the IEEE 754R mailing list, and in
personal contact, I was told that the languages would simply have
to change their arithmetic model to fit. I told them "no chance"
but said that I would raise it in some ISO working groups - which,
of course, said "no chance". Why ON EARTH do you think that there
is no full support for IEEE 754 in any language whatsoever after
27 years?
And, no, I am NOT going to describe what C99 really specifies,
even though I could in all its gory detail (as I think you know).
Regards,
Nick Maclaren.
James Kuyper
> In article <j6qf8u$hji$1...@dont-email.me>,
> James Kuyper <james...@verizon.net> wrote:
>> ...
>>> The IEEE 754 model is incompatible with most language's arithmetic
>>> models,
>>
>> That claim would be more useful if you would at least hint at what the
>> typical incompatibilities are. I doubt that the writers of that standard
>> intended it to be incompatible with those languages, and I doubt that
>> the designers of all of those languages went out of their way to be
>> incompatible with that standard, which suggests that any such
>> incompatibility is likely to be subtle. If so, reading the IEEE 754
>> standard and comparing it with the language standards is not likely to
>> be fruitful without at least a hint of what incompatibilities to look for.
>
> Aargh! You have got the whole thing arsey-versey. If there isn't
> any match between the basic concepts, what on earth is the point
> in looking for detailed incompatibilities? I said that the MODELS
> were incompatible and not that the DETAILS were.
problematic features of the IEEE 754 standard shared by the IEEE 854?
I've got a copy of that standard, and am somewhat familiar with it (I
wouldn't claim to be an expert, by any means). I do consider myself a
fair expert on the C99 standard, and I haven't noticed any
incompatibilities of the very fundamental nature that you're implying.
Your citation from the Fortran standard didn't do anything to clarify
the issue for me.
I'm not saying you're wrong. As it stands, I have no idea what you're
talking about, so I can't judge whether or not you're right. If you have
any inclination to be less cryptic, please let me know.
--
James Kuyper
William Elliot
> Obviously, otherwise computer floating point would require an
> infinite number of bits to represent.
capacity. Math is better at it for it has a countable capacity.
It's only a desperate illusion that those who know programming,
know something about mathematics. On the contrary, it appears
knowing programming is a mathematical handicap.
ken...@cix.compulink.co.uk
> I was mostly interested in +inf + +inf. (Positive infinity + Positive
> infinity)
memory aleph0 plus aleph0 =aleph0. While infinity theory is important
in mathematics it is hardly applicable to computer arithmetic.
Ken Young
Kaba
> It's only a desperate illusion that those who know programming,
> know something about mathematics. On the contrary, it appears
> knowing programming is a mathematical handicap.
close to mathematical thinking. With the least amount of assumptions,
you wish to create data structures and algorithms capable of handling
the greatest amount of cases.
For example: you can create a concept named semigroup (corresponding to
the mathematical concept) by requiring that each type conforming to a
semigroup have a binary addition operator +, and that operation be
associative. If you can create an algorithm which only relies on that
operation, then that algorithm works for all types conforming to the
semigroup concept (and not just for integers, say).
--
http://kaba.hilvi.org
nm...@cam.ac.uk
James Kuyper <james...@verizon.net> wrote:
>
>Then please explain the incompatibility you see in the models. Are the
>problematic features of the IEEE 754 standard shared by the IEEE 854?
Yes.
>I've got a copy of that standard, and am somewhat familiar with it (I
>wouldn't claim to be an expert, by any means). I do consider myself a
>fair expert on the C99 standard, and I haven't noticed any
>incompatibilities of the very fundamental nature that you're implying.
>Your citation from the Fortran standard didn't do anything to clarify
>the issue for me.
>
>I'm not saying you're wrong. As it stands, I have no idea what you're
>talking about, so I can't judge whether or not you're right. If you have
>any inclination to be less cryptic, please let me know.
Sorry - things have been a little stressful.
IEEE 754 is based on a serial assembler model, where arithmetic
is a sequence of basic operations. And both aspects are critical.
Fortran is based on an evaluation of mathematical expressions,
and is not in terms of basic operations, nor even necessarily serial.
There just isn't any match between the models.
Most languages are like Fortran, though usually less explicit, and
with less implied freedom for the implementor. If I recall from
my time on WG2, Pascal is one such. Python definitely is. I can't
remember about Ada, but I vaguely recall it being, too. As are
most of the other hundreds of languages I have looked at in my time.
The original intent of WG14 was similar (I was involved - remember
the unary plus proposal?) and the standards was deliberately left
ambiguous (NOT my choice). Later revisionists claimed that C had
always specified the execution order implied by one reading of the
syntax, but that is completely false, and is contradicted by other
wording, anyway (try 6.5#3, for a start). As I said, I am NOT going
to go into the complete mess that is FLT_EVAL_METHOD, the pragmas,
Annex F and all that - I tried to get some sanity injected during
C99's standardisation, and failed, which is the main reason I voted
against it.
C++ is similar, but different. I raised this there and WG21 kicked
it into the long grass. As I understand it, the intent is that the
order is unconstrained, but serial execution is assumed.
For Java, see Kahan's paper. Its value semantics match; its flag
ones don't.
Regards,
Nick Maclaren.
Larry Hewitt
>> In article<MPG.28fad914b...@news.cc.tut.fi>,
>> Kaba<ka...@nowhere.com> wrote:
> ...
>> The IEEE 754 model is incompatible with most language's arithmetic
>> models,
>
> That claim would be more useful if you would at least hint at what the
> typical incompatibilities are. I doubt that the writers of that standard
> intended it to be incompatible with those languages, and I doubt that
> the designers of all of those languages went out of their way to be
> incompatible with that standard, which suggests that any such
> incompatibility is likely to be subtle. If so, reading the IEEE 754
> standard and comparing it with the language standards is not likely to
> be fruitful without at least a hint of what incompatibilities to look for.
>
IEEE 754 defines 5 exceptions, but how these are triggered and then
handled is up to the compiler.
Invalid operation (e.g., square root of a negative number)
Division by zero
Overflow (a result is too large to be represented correctly)
Underflow (a result is very small outside the normal range)
Inexact.
Divide by zero is a defined exception, so 1.0/0.0 will trigger an
exception. But how the compiler triggers that exception may vary.
inf + inf is an exception, but the compiler can trigger either an
inexact exception or an overflow exception.
Some compilers will allow exceptions to be ignored, resulting in
unpredictable results based on the random content of memory that may be
misinterpreted as a valid result.
Larry
Skybuck Flying
For integers this seems to be the case but for floating point it could be
different.
When one thinks about it: dividing a number by a very small number gives a
very big number.
So dividing a number by zero would lead to infinity, so in a way it makes
sense to define the result of divizion by zero for floating point numbers to
either
be negative infinity or positive infinity this would save the need to use
branches to catch zero cases and assign infinity.
Example:
Nasty situation:
if Delta <> 0 then
begin
Result := Number / Delta;
end else
begin
if Number < 0 then
begin
Result := NegativeInfinity;
end else
begin
Result := PositiveInfinity;
end;
end;
Nice situation:
Result := Number / Delta;
^ It would be nice if the processor would automatically fill result with the
appriorate infinity so the possibly expensive branches up there can be
avoided.
I have at least seen one programmer claim that current X86/X64 processors
can already do this ? I am not sure and have not tried yet, seems a bit
risky to leave these branches out.
It could also be as you say and it could be compiler specific.
I think Delphi probably has a compiler directive to make the "nice"
behaviour work, if it doesn't then it should get one ! ;)
Bye,
Skybuck :)
Larry Hewitt
> I am not so sure if dividing by zero leads to exceptions.
>
The IEE 754 defines divide by zero to be an exception. It does not
differentiate between integer and floating point.
Mathematically the result is undefined.
> For integers this seems to be the case but for floating point it could
> be different.
>
> When one thinks about it: dividing a number by a very small number gives
> a very big number.
Except when that "very small: number is zero, then the result is
undefined, by definition .
>
> So dividing a number by zero would lead to infinity, so in a way it
> makes sense to define the result of divizion by zero for floating point
> numbers to either
> be negative infinity or positive infinity this would save the need to
> use branches to catch zero cases and assign infinity.
>
No.
The result is undefined.
To be a defined result the inverse operation must generate the original
values and be unique.
so, if :
1.0/0.0 = inf, then inf * 0.0 = 1.0
and
2.0/0.0 = inf, then inf*0.0 = 2.0
That is why division by zero and calculations in the reals with inf are
undefined.
> Example:
>
> Nasty situation:
>
> if Delta <> 0 then
> begin
> Result := Number / Delta;
> end else
> begin
> if Number < 0 then
> begin
> Result := NegativeInfinity;
> end else
> begin
> Result := PositiveInfinity;
> end;
> end;
>
> Nice situation:
>
> Result := Number / Delta;
>
> ^ It would be nice if the processor would automatically fill result with
> the appriorate infinity so the possibly expensive branches up there can
> be avoided.
>
> I have at least seen one programmer claim that current X86/X64
> processors can already do this ? I am not sure and have not tried yet,
> seems a bit risky to leave these branches out.
>
> It could also be as you say and it could be compiler specific.
>
Hardware does not understand numbers, software as produced by a compiler
does. A number or a letter is no more than a series of bits in a
register to hardware that is described by the software.
I have used languages where, if you are careless, you can add the ascii
value of letters.
\Larry
Al Grant
> The original intent of WG14 was similar (I was involved - remember
> the unary plus proposal?) and the standards was deliberately left
> ambiguous (NOT my choice). Later revisionists claimed that C had
> always specified the execution order implied by one reading of the
> syntax, but that is completely false, and is contradicted by other
> wording, anyway (try 6.5#3, for a start).
So in what respect is that incompatible with IEEE 754? C specifies
not only that in (a+b)+c, a+b happens first, but that in a+b+c,
a+b happens first, so it's more prescriptive than Fortran.
It says things are otherwise unsequenced, but how can IEEE 754
require more than that? If IEEE 754 required a total order on all
floating-point operations in a program it would have been
unimplementable on any SIMD computer from ILLIAC IV onwards.
C _allows_ implementations that are incompatible with IEEE 754
(e.g. ones that use a different format, or flush denormals to zero)
but that's a long way from _being_ incompatible with IEEE 754.
nm...@cam.ac.uk
>
>> The original intent of WG14 was similar (I was involved - remember
>> the unary plus proposal?) and the standards was deliberately left
>> syntax, but that is completely false, and is contradicted by other
>> wording, anyway (try 6.5#3, for a start).
>
>So in what respect is that incompatible with IEEE 754? C specifies
>not only that in (a+b)+c, a+b happens first, but that in a+b+c,
>a+b happens first, so it's more prescriptive than Fortran.
ISO/ANSI C standards and their implementations!
There is no such statement in the C standard, and I can tell you
(from personal recollection) that requiring it was NOT WG14's intent
during the standardisation of C90. The BNF was intended to specify
ONLY the precedence of operators and NOT the evaluation order; that
was specified by the side-effect rules.
If you had looked up the section of the standard I pointed you to,
you would have seen both that the word used is "grouping", which
is clearly intended to distinguish it from execution order, and a
clear statement that the order of evaluation is unspecified. And
THAT was the intent of WG14 during the standardisation of C90.
I am fully aware that a lot of people are now claiming that the
BNF has always been meant to define the execution order, but that
flatly contradicts large chunks of other wording (especially the
side-effect rules). Whether it is now what compilers do, I don't
know (and don't much care, either).
Regards,
Nick Maclaren.
James Kuyper
...
> (from personal recollection) that requiring it was NOT WG14's intent
> during the standardisation of C90. The BNF was intended to specify
> ONLY the precedence of operators and NOT the evaluation order; that
> was specified by the side-effect rules.
>
> If you had looked up the section of the standard I pointed you to,
> you would have seen both that the word used is "grouping", which
> is clearly intended to distinguish it from execution order, and a
> clear statement that the order of evaluation is unspecified. And
> THAT was the intent of WG14 during the standardisation of C90.
>
> I am fully aware that a lot of people are now claiming that the
> BNF has always been meant to define the execution order, but that
> flatly contradicts large chunks of other wording (especially the
> side-effect rules). Whether it is now what compilers do, I don't
> know (and don't much care, either).
great, but it's not completely unconstrained.
While there are people who have misinterpreted the BNF as fully
specifying the execution order, I don't consider that to be a common
position among those most familiar with the standard. A more common
position, and IMO fully defensible, is that the BNF implies constraints
on the execution order. For instance, in ((a+b) + (c+d)), the a+b can be
executed before or after the (c+d), but both must be executed before the
final addition can be performed, because that addition requires the
results of those execution. The standard does not say anything
explicitly about that fact, because it doesn't need to - it's implicit
in what the standard does explicitly say about the dependency of the
final value on the values of the sub-expressions.
I've seen claims, (possibly from you?), that it's possible for a
conforming implementation to generate code for a+b+c which calculates
the result of a+b after (sic!) the result of that very calculation has
already been added to c. However, when I asked for details of how that
was supposed to work, I learned that the supposedly-conforming code
calculated a+b twice - once for adding to c, and the second time for the
sole purpose (as far as I could tell) of "proving" that it's permissible
to compute it afterward.
I'll concede that the as-if rule allows spurious extra computations to
be inserted at any time, so long as they don't affect the final result.
However, for an implementation that pre-#defines __STDC_IEC_559__, it
seems to me that the "final result" necessarily includes the values of
testable floating point environment flags; at least, if it occurs within
code that actual performs such tests.
You know this, but for the benefit of those who don't: C99 added
<fenv.h>, providing portable C support for such flags.
I remember a long discussion we had (partly off-line) in which you
claimed that C99's provision of such support, in that form, made the
situation worse than it would have been without it. You presented a very
real list of weaknesses in the specifications, primarily consisting of
things that are optional which, if I understood your arguments, could
only be considered useful if mandatory. It seems to me that if a feature
is optional, but I have a portable way of testing whether it's
supported, and a portable way of making use of it if it is supported,
that's unambiguously more useful than having nothing portably specified
about that feature - I never understood your claims to the contrary.
nm...@cam.ac.uk
>
>The freedom of C implementations to rearrange the order of evaluation is
>great, but it's not completely unconstrained.
>While there are people who have misinterpreted the BNF as fully
>specifying the execution order, I don't consider that to be a common
>position among those most familiar with the standard.
> A more common
>position, and IMO fully defensible, is that the BNF implies constraints
>on the execution order. For instance, in ((a+b) + (c+d)), the a+b can be
>executed before or after the (c+d), but both must be executed before the
>final addition can be performed, because that addition requires the
>results of those execution.
were lots of OTHER interpretations, which were ALSO defensible.
> The standard does not say anything
>explicitly about that fact, because it doesn't need to - it's implicit
>in what the standard does explicitly say about the dependency of the
>final value on the values of the sub-expressions.
about side-effect ordering, and there is nothing in the standard
that distinguishes the evaluation of an assignment operator from
the evaluation of any other operator!
I could respond to the rest of your points in detail, but I am
afraid that I don't have the time, so will select just one.
>However, for an implementation that pre-#defines __STDC_IEC_559__, it
>seems to me that the "final result" necessarily includes the values of
>testable floating point environment flags; at least, if it occurs within
>code that actual performs such tests.
unfortunately a lot of WG14 didn't, and so it was left up in the air.
>You know this, but for the benefit of those who don't: C99 added
><fenv.h>, providing portable C support for such flags.
Firstly, any ambiguous specification does NOT enable portability,
because the programmer assumes one thing and the implementor another.
In my experience, that is the cause of something like 85% of the
nasty bugs in C code written by experienced programmers!
Secondly, the problem is NOT solely optionality (as you claimed
that I showed) - it's serious ambiguity and even inconsistency.
Here is one example of the problem.
5.1.2.3 Program execution footnote 11:
... Floating-point operations implicitly set the status flags; ....
Implementations that support such floating-point state are required
to regard changes to it as side effects ....
6.5 Expressions para. 5:
If an exceptional condition occurs during the evaluation of an
expression (that is, if the result is not mathematically defined or
not in the range of representable values for its type), the behavior
is undefined.
7.6 Floating-point environment para. 1:
... A floating-point status flag is a system variable whose value
is set (but never cleared) when a floating-point exception is
raised, which occurs as a side effect of exceptional floating-point
arithmetic to provide auxiliary information. ...
Now, 6.5 states unequivocally that exceptional conditions lead to
undefined behaviour, which is assuredly sometimes the case. But
Annex F states they are not if __STDC_IEC_559__ is defined. Why
do you claim that the latter overrides the former, and not the
former the latter?
That would have been trivial to fix, but there are a zillion other
such inconsistencies, all of which give scope to implementors to
do something that the programmer doesn't expect, and where the
implementation can still claim to be conforming. That's NOT a
recipe for portability!
Regards,
Nick Maclaren.
James Kuyper
> In article <4E95BBEE...@verizon.net>,
> James Kuyper <james...@verizon.net> wrote:
>> on the execution order. For instance, in ((a+b) + (c+d)), the a+b can be
>> executed before or after the (c+d), but both must be executed before the
>> final addition can be performed, because that addition requires the
>> results of those execution.
>
> Well, yes, but I never said it wasn't! What I said was that there
> were lots of OTHER interpretations, which were ALSO defensible.
defensible. The relevant thing would be a defensible interpretation that
differs from the one I gave in ways that would be problematic. Every
problematic interpretation I could come up with was indefensible for
reasons directly connected to the fact that was problematic. Could you
give an example?
...
>> seems to me that the "final result" necessarily includes the values of
>> testable floating point environment flags; at least, if it occurs within
>> code that actual performs such tests.
>
> I can tell you that most of the proponents of that agree with you;
> unfortunately a lot of WG14 didn't, and so it was left up in the air.
assertion that there are people who believe in the validity of that
argument.
>> You know this, but for the benefit of those who don't: C99 added
>> <fenv.h>, providing portable C support for such flags.
>
> I know damn well it didn't!
do it. :-)
...
That's the main thing I remembered you arguing; I didn't mean to imply
that the arguments I remembered were the only ones you actually made -
my memory's not that good.
> ... - it's serious ambiguity and even inconsistency.
>
> 5.1.2.3 Program execution footnote 11:
>
> ... Floating-point operations implicitly set the status flags; ....
> Implementations that support such floating-point state are required
> to regard changes to it as side effects ....
>
> 6.5 Expressions para. 5:
>
> If an exceptional condition occurs during the evaluation of an
> expression (that is, if the result is not mathematically defined or
> not in the range of representable values for its type), the behavior
> is undefined.
>
> 7.6 Floating-point environment para. 1:
>
> ... A floating-point status flag is a system variable whose value
> is set (but never cleared) when a floating-point exception is
> raised, which occurs as a side effect of exceptional floating-point
> arithmetic to provide auxiliary information. ...
>
> Now, 6.5 states unequivocally that exceptional conditions lead to
> undefined behaviour, which is assuredly sometimes the case. But
> Annex F states they are not if __STDC_IEC_559__ is defined. Why
> do you claim that the latter overrides the former, and not the
> former the latter?
any conflicting specification covering more the general cases; the
standard would require a lot of complicated re-wording if that weren't
true. #ifdef __STDC_IEC_559__ is more specific than #ifndef.
> That would have been trivial to fix,
"An implementation that defines __STDC_IEC_559_ _ shall conform to the
specifications in this annex." (F1.1). Should they add the words "even
in circumstances where the rest of the standard says that the behavior
is undefined."? That would seem redundant with the simple word "shall"
to me. What does the "shall" mean in this context if it doesn't already
imply that?
4p1: "‘‘shall’’ is to be interpreted as a requirement on an
implementation or on a program;" This is clearly a requirement imposed
on the implementation.
3.4.3p1: undefined behavior
"behavior, ... for which this International Standard imposes no
requirements."
Annex F is a part of "this International Standard", is labeled as
normative, and imposes requirements for the behavior when an
implementation chooses to pre-#define __STDC_IEC_559__. That doesn't
seem to meet the standard's definition of "undefined behavior".
Keith Thompson
An _expression_ is a sequence of operators and operands that
specifies computation of a value, or that designates an object
or a function, or that generates side effects, or that performs
a combination thereof. The value computations of the operands
of an operator are sequenced before the value computation of
the result of the operator.
The phrase "sequenced before" is new; it's defined in 5.1.2.3.
If there's a sequence point after x and before y, then x is
"sequenced before" y. But the reverse is not necessarily true; x can
be sequenced before y even if there's no sequence point between them.
In the example "a + b + c", the grammar says that the first "+"
applies to "a" and "b", and the second applies to the result of the
first and to "c"; in other words, "a + b + c" means "(a + b) + c",
*not* "a + (b + c)".
The order of evaluation of the operands of a given operator is
unspecified, and I don't believe anyone here has suggested otherwise.
"a + b" could evaluate "a" and then "b", or "b" and then "a"; it could
even evaluate them in parallel as long as the result is as if they were
evaluated sequentially.
But an operator cannot be applied until after its operands have
been evaluated. This is implicit in C90 and C99, and explicit (see
above) in C201X. The result of "a + b" *must* be computed before
the result of "a + b + c" can be computed. There's no sequence
point between the two additions, but their order is constrained by
the simple fact that you can't perform an operation without first
evaluating the operands. (The lack of a sequence point means that
the "value computation" of "a" is sequenced before the computation of
"a + b", but any side effects of evaluating "a" are not.)
[...]
(Followups to comp.lang.c only.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
nm...@cam.ac.uk
>
>>> position, and IMO fully defensible, is that the BNF implies constraints
>>> on the execution order. For instance, in ((a+b) + (c+d)), the a+b can be
>>> executed before or after the (c+d), but both must be executed before the
>>> final addition can be performed, because that addition requires the
>>> results of those execution.
>>
>> Well, yes, but I never said it wasn't! What I said was that there
>> were lots of OTHER interpretations, which were ALSO defensible.
>
>I'm sure that there are alternative interpretations, many of them
>defensible. The relevant thing would be a defensible interpretation that
>differs from the one I gave in ways that would be problematic. Every
>problematic interpretation I could come up with was indefensible for
>reasons directly connected to the fact that was problematic. Could you
>give an example?
One is that the BNF defines the execution order, except where
explicitly varied.
The other is that the grouping defines only the operator precedence
and not how the expression is evaluated. AS I SAID, I was active
in WG14 at the time, and I understood that to be the nearest it
got to a consensus.
>>> You know this, but for the benefit of those who don't: C99 added
>>> <fenv.h>, providing portable C support for such flags.
>>
>> I know damn well it didn't!
>
>It might not have done it as well as you might have liked - but it did
>do it. :-)
but the experience of being in WG14, interaction with vendors and
actually running tests.
>Specifications for particular cases are routinely considered to override
>any conflicting specification covering more the general cases; the
>standard would require a lot of complicated re-wording if that weren't
>true. #ifdef __STDC_IEC_559__ is more specific than #ifndef.
mailing list - I don't have the time to try to remember specific
examples now. It IS the case for implicit undefined behaviour, but
this is EXPLICIT.
>> That would have been trivial to fix,
>
>What fix do you think would be needed?
>"An implementation that defines __STDC_IEC_559_ _ shall conform to the
>specifications in this annex." (F1.1). Should they add the words "even
>in circumstances where the rest of the standard says that the behavior
>is undefined."? That would seem redundant with the simple word "shall"
>to me. What does the "shall" mean in this context if it doesn't already
>imply that?
Does it apply when pragma FENV_ACCESS is not set and, if so, exactly
how? Yes, there is an 'obvious' best choice there.
What does it mean together with FP_CONTRACT or CX_LIMITED_RANGE on?
I can tell you that the BSI never got an answer out of WG14 on that
one!
Does it apply to the large amount of the C language and library NOT
mentioned in Annex F and, if so, exactly how?
Under what conditions does it apply if any function from an external
library is linked in? And, if you think there is a simple answer
to that, I recommend a year or two in an ISO standards committee.
Anyway, I don't have time for more.
Regards,
Nick Maclaren.
Robert Myers
>
> No, it didn't, BECAUSE IT'S NOT PORTABLE.
You scare me, Nick.
That's only fair, because, to the extent that you pay attention to
anything I say, I probably scare you.
What you are really saying is that, in a code where mysterious and
unreliable things are happening, you can't blindly transfer the code
from one ad hoc hardware and software standard to another. Listen
very carefully:
THAT'S A GOOD THING.
It may be the last thing standing between us and careerists who don't
have a clue "validating" their results by transferring a meaningless
calculation from one machine to another with no clue that something
totally crazy is going on.
The idea that the universe would be a safer place if only people would
listen to you doesn't even pass the laugh test.
Robert.
Andrew Reilly
> It may be the last thing standing between us and careerists who don't
> have a clue "validating" their results by transferring a meaningless
> calculation from one machine to another with no clue that something
> totally crazy is going on.
Nick does have a good point though, notwithstanding the last couple of
posts in which the authors asserted that C (at least) now *does* specify
a total order of operations within expressions (even ones that appear
ambiguous because of expectations of associativity). I didn't realize
that, and I'm still not sure that I believe them.
Nick's point (I believe) is that floating point arithmetic is fraught,
because it is fairly fundamentally unlike the mathematics that expression-
based languages appear to be offering. In maths and exact computer
arithmetic (eg integer), addition is associative and a bunch of other
nice rules for "simplification" apply. In floating point they don't,
because every floating point multiply (a * b), for example, is really
something like round(_g_current_FPU_rounding_mode, multiply(a,b)), and
every addition or subtraction is even more complicated, with a bunch of
normalizations thrown in for good measure. Round is, naturally, a lossy
operation. Throw in exceptions that can be raised in a bunch of ways and
you wind up with something that can only really be reasoned about as a
discrete sequence of assembly-language-like operations that both produce
results and mutate and depend on the "system state" in obscure and
platform-dependent ways. I haven't even mentioned an IEEE standard here:
it ought to be possible to define a stateless floating point method,
where rounding modes were explicit in the instructions and exceptions
were either defined away as in-band values or made of precice exceptions,
but I've never heard of it being done.
Clearly you can still have parallelism between independent operations,
but you can't manipulate floating point expressions that look like maths
as though they were maths, at least not without giving up being able to
reason about the answer.
Which I think just emphasises your point, too: people doing floating
point need to have a clue...
Cheers,
--
Andrew
nm...@cam.ac.uk
Andrew Reilly <areil...@bigpond.net.au> wrote:
>
>Nick's point (I believe) is that floating point arithmetic is fraught,
>because it is fairly fundamentally unlike the mathematics that expression-
Actually, no. It's tricky, but not THAT tricky. My real point is
that the C99 and other modern 'improvements' make it appear to the
naive as if it is more portable and reliable, but actually introduce
ten times as many portability and reliability problems as they solve.
Almost everyone who has actually tried it has discovered that, but
most people code for one system, run a couple of sets of well-behaved
data, and then claim that their program is portable and robust and
any failures must be the fault of the compiler!
>Clearly you can still have parallelism between independent operations,
>but you can't manipulate floating point expressions that look like maths
>as though they were maths, at least not without giving up being able to
>reason about the answer.
Yes, you can. Look at most of the classic numerical analysis books.
You have to do it rather differently, and very, very few modern
'computer scientists' would know how to start. Wilkinson and Reinsch
"The Algebraic Eigenvalue Problem" is one example of such reasoning
that I have used in the past.
>Which I think just emphasises your point, too: people doing floating
>point need to have a clue...
Oh, THERE, I am in 100% agreement. When I teach it, I tell people
that the key is to think floating-point, not mathematical real,
but that 50+ years of Fortran experience shows that it's not as
hard as all that. Inter alia, we used to write code that was both
reliable and portable across a range of arithmetics that most
people nowadays cannot imagine :-)
There ARE some books on how to write robust, portable floating-point
code, but all are very old-fashioned. And there were a large number
of experiments showing both that the exact details of the arithmetic
didn't matter much (though directed versus nearest rounding did),
and that relying on the the exact details led to the code being LESS
robust, rather than more.
Of courses, that's now all regarded as heresy ....
Regards,
Nick Maclaren.
Arivald
> wrote:
>> In article<MPG.28fa8e225...@news.cc.tut.fi>,
>> Kaba<ka...@nowhere.com> wrote:
>>>
>>> Here are some interesting properties of the IEEE floating point
>>> standard, which is the underlying technology behind most home computers.
>>> The behaviour of high-level programming languages tend to mirror it
>>> closely.
>>
>> Oh, no, they don't! Not even if you had got it correct.
>
> Simply asserting that isn't particularly helpful. Maybe you could step
> in and make a better statement, on where the behaviour agreees and where
> it differs.
>
>>> Let x be some positive, regular, floating point number. The
>>> basic mathematical model is the affinely extended reals, but the
>>> standard defines a bit more (see division by zero).
>>
>> Its signed zero handling is incompatible with that model in several
>> respects where traditional floating-point isn't.
>
> I disagree. Mathematics has one zero, the IEEE floating point has two.
Start thinking about IEEE floating point number as a probable number -
number You can't measure exactly, there is always some immeasurable error.
In this case -0 means: number so small so we can assume it is zero, but
we certain it is negative. +0 is same, but positive.
So You never can say it is zero, because You never can be certain it is.
You can only compare to zero up to some precision.
--
Arivald
Al Grant
> The freedom of C implementations to rearrange the order of evaluation is
> great, but it's not completely unconstrained.
> While there are people who have misinterpreted the BNF as fully
> specifying the execution order, I don't consider that to be a common
> position among those most familiar with the standard. A more common
> position, and IMO fully defensible, is that the BNF implies constraints
> on the execution order. For instance, in ((a+b) + (c+d)), the a+b can be
> executed before or after the (c+d), but both must be executed before the
> final addition can be performed
That was what I was saying, with the further provision that
a + b + (c + d) is equivalent to ((a+b) + (c+d)). I.e. in C,
parentheses are a lexical feature and don't act as a further
constraint on the parse. The compiler has no more leeway
to reassociate a+b+c than it does to reassociate (a+b)+c.
Al Grant
> Nick does have a good point though, notwithstanding the last couple of
> posts in which the authors asserted that C (at least) now *does* specify
> a total order of operations within expressions (even ones that appear
> ambiguous because of expectations of associativity). I didn't realize
> that, and I'm still not sure that I believe them.
The point is that there is no difference in C between a+b+c
and (a+b)+c. Any order implied by the latter is also implied
by the former. The point is that operator precedence in C
uniquely defines the "evaluation tree". I don't believe anyone
has asserted that there is a total order of all computations
within the tree, i.e. between the LHS and RHS of a binary
operator.
> Nick's point (I believe) is that floating point arithmetic is fraught
We all know it that floating-point arithmetic is not the same as
real arithmetic. Nick appears to be making an abstruse point,
about the relationship between ISO C and IEEE 754, without
being able to explain what that point is.
James Kuyper
...
> That was what I was saying, with the further provision that
> a + b + (c + d) is equivalent to ((a+b) + (c+d)). I.e. in C,
> parentheses are a lexical feature and don't act as a further
> constraint on the parse.
I'm not sure exactly what you mean by the statement that they "don't act
as a further constraint on the parse". To clarify, do you agree that
each of the following expressions is parsed into a different evaluation
tree?
a + b + c + d
a + (b + c) + d
a + b + (c + d)
a + (b + (c + d)
In particular, the conditions that make each of those expressions
produce an overflow may be quite different.
> ... The compiler has no more leeway
> to reassociate a+b+c than it does to reassociate (a+b)+c.
I'll agree with that
Skybuck Flying
To be a defined result the inverse operation must generate the original
values and be unique.
so, if :
1.0/0.0 = inf, then inf * 0.0 = 1.0
and
2.0/0.0 = inf, then inf*0.0 = 2.0
That is why division by zero and calculations in the reals with inf are
undefined.
"
Feels as if math has a little short coming here.
Here is an idea:
How about:
Infinity * 0.0 = Anything
Bye,
Skybuck.
Al Grant
> I'm not sure exactly what you mean by the statement that they "don't act
> as a further constraint on the parse". To clarify, do you agree that
> each of the following expressions is parsed into a different evaluation
> tree?
>
> a + b + c + d
> a + (b + c) + d
> a + b + (c + d)
> a + (b + (c + d)
Yes. Also, the third one is the only "balanced" tree where
two of the adds can happen at the same time.
> In particular, the conditions that make each of those expressions
> produce an overflow may be quite different.
And in floating-point the result may be numerically different...
Robert Myers
>
> Nick does have a good point though, notwithstanding the last couple of
> posts in which the authors asserted that C (at least) now *does* specify
> a total order of operations within expressions (even ones that appear
> ambiguous because of expectations of associativity). I didn't realize
> that, and I'm still not sure that I believe them.
>
> Nick's point (I believe) is that floating point arithmetic is fraught,
> because it is fairly fundamentally unlike the mathematics that expression-
> based languages appear to be offering.
<snip>
> I haven't even mentioned an IEEE standard here:
> it ought to be possible to define a stateless floating point method,
> where rounding modes were explicit in the instructions and exceptions
> were either defined away as in-band values or made of precice exceptions,
> but I've never heard of it being done.
>
<snip>
> Which I think just emphasises your point, too: people doing floating
> point need to have a clue...
>
You make some good points that are worth remembering.
I'm not sure, though, that a stateless and platform-independent
definition of floating point arithmetic is either necessary or
desirable or even possible within the bounds of practical utility.
If the floating point details that people spend so much time on here
make all that much difference, there is probably something flaky about
either the algorithm or the code or both. Given that at least some of
the people who spend so much time talking about this issue here
probably already understand the claim I just made, I don't understand
why this alchemist's pursuit of turning lead into gold continues.
Given the choice between hammering it into people that floating point
arithmetic is not for the naive or even necessarily replicable from
one situation to another, and inventing an arbitrary standard that
makes it at least make the same mistake every time, I'd prefer the
current chaos to artificial predictability.
I could and would and do make the same objection about the
correspondence to mathematics that you make for floating point
arithmetic to every code that purports to represent mathematics where
a differential operator appears in the calculation. I know how to
make that correspondence precise and completely unarbitrary, but I am
repeatedly told that doing so is simply too expensive.
I conclude, as I believe I have said before, that this continuing
discussion is an instance of Nazrudin's lost key: looking where there
is light. Given that many if not most codes that use floating point
arithmetic rely on absurd mathematics (repeatedly differentiating
derivatives that are piecewise continuous even only in theory), I just
can't understand all the fuss about the last bit (rounding), which
idealized properties floating point arithmetic does or does not
possess, or what arbitrary thing the hardware does when the algorithm
leads to a nonsensical or ambiguous result.
Robert.
Andrew Reilly
> If the floating point details that people spend so much time on here
> make all that much difference, there is probably something flaky about
> either the algorithm or the code or both.
because I often find myself having to hose down the desire to produce bit-
exact test-suites for inherently unstable (or at least somewhat
arbitrary) algorithms that just happen to behave in a particular way in
floating point with a particular version of a compiler, with a particular
set of command-line options. Believe me, it happens a lot.
Cheers,
--
Andrew
Terje Mathisen
arbitrary/random, and could even impact one or more extra low bits.
I.e. if your code doesn't produce effectively the same results under
such a regime, your algorithms are almost certainly broken.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
Jasen Betts
> I would in fact be much _more_ useful to have a mode where rounding was
> arbitrary/random, and could even impact one or more extra low bits.
--
⚂⚃ 100% natural
--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---
Phil Carmody
> On 2011-10-15, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> > I would in fact be much _more_ useful to have a mode where rounding was
> > arbitrary/random, and could even impact one or more extra low bits.
>
> Intel tried something like that in the 90s :^)
Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator
Terje Mathisen
> Jasen Betts<ja...@xnet.co.nz> writes:
>> On 2011-10-15, Terje Mathisen<"terje.mathisen at tmsw.no"> wrote:
>>> I would in fact be much _more_ useful to have a mode where rounding was
>>> arbitrary/random, and could even impact one or more extra low bits.
>>
>> Intel tried something like that in the 90s :^)
>
> Until Terje himself broke the feature!
I did write most of the sw workaround for the FDIV (and FPATAN) bug on
the Pentium.
Phil Carmody
> Phil Carmody wrote:
> > Jasen Betts<ja...@xnet.co.nz> writes:
> >> On 2011-10-15, Terje Mathisen<"terje.mathisen at tmsw.no"> wrote:
> >>> I would in fact be much _more_ useful to have a mode where rounding was
> >>> arbitrary/random, and could even impact one or more extra low bits.
> >>
> >> Intel tried something like that in the 90s :^)
> >
> > Until Terje himself broke the feature!
>
> Rather fixed it again:
>
> I did write most of the sw workaround for the FDIV (and FPATAN) bug on
> the Pentium.
feature, then your fix 'broke' it. (I was assuming FDIV was what was
being refered to.)
Terje Mathisen
> Terje Mathisen<"terje.mathisen at tmsw.no"> writes:
>> I did write most of the sw workaround for the FDIV (and FPATAN) bug on
>> the Pentium.
>
> That's what I was trying to imply. If we're pretending the bug was
> feature, then your fix 'broke' it. (I was assuming FDIV was what was
> being refered to.)
FDIV did provide one sample point that was relevant though: It showed
that pretty close to zero applications and their users noticed anything
wrong even though divisions would drop 0 to 45 bits when the divisor hit
one of those 5 in 1024 leading mantissa bit patterns.