Juha Nieminen <nospam@thanks.invalid>: Oct 31 08:19AM
> Does it say anywhere that a division by zero /is/ allowed
> (is not undefined behavior) in floating-point divisions?
It's UB. In some systems you might get the IEEE floating point value
of "infinity". In other systems you will get a system signal (which
will abort your program unless you catch it with a system-specific
method). Even in the former case the compiler may optimize the
code in such a manner that it does something else than give you inf
as the result.
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
|
mark <mark@invalid.invalid>: Oct 31 10:25AM +0100
On 2016-10-30 00:46, Stefan Ram wrote:
> course, evaluating to "Inf" is subsumed by UB, but when the
> programmer has no guarantee for that result, it is not worth
> that much.
C++14 standard:
<<<
static constexpr bool is_iec559;
True if and only if the type adheres to IEC 559 standard.
IEC559 standard:
<<<
7.3 Division by zero
The divideByZero exception shall be signaled if and only if an exact
infinite result is defined for an operation on finite operands. The
default result of divideByZero shall be an ∞ correctly signed according
to the operation:
...
So I don't see how anyone could argue that the behavior is undefined,
since that would directly contradict IEC 559 adherence.
|
David Brown <david.brown@hesbynett.no>: Oct 31 10:44AM +0100
On 30/10/16 21:40, Alf P. Steinbach wrote:
>>> Nonsense.
>> No, it is not nonsense - it is perfectly reasonable mathematics.
> Is it? What's it use then?
You can look up projective planes, projectively extended real lines,
etc., on Wikipedia. The most useful variation, I believe, is the
Reimann sphere which is the complex numbers with an infinity added.
Imagine taking the complex plane as a sheet of rubber and wrapping it
around a sphere, stretching and squashing as necessary (I don't know
your mathematical background, but you will probably have heard of
topology being described as "rubber sheet geometry"). You can make it
all fit as neatly as you want, but there is still a tiny hole left. The
Reimann sphere has that hole filled in with "infinity". As well as
being useful in mathematics, it turns out to be helpful in quantum
physics, I believe.
Of course, once you start adding a single infinity and the result of
division by zero to be that infinity, you no longer have a field and
lose some mathematical properties while gaining others. And in the
Reimann sphere (or the projectively extended real line, which is a sort
of circular version) then 0/0 and inf/inf are still undefined.
It can also be useful to use vectors of the form (x, y, z, u) in 3
dimensional geometry, where your points are (x/u, y/u, z/u) for any
non-zero u. Zero u represents directions, but not points.
So there are many situations where you might want infinities, or
divisions by zero (the two are not the same - hyperreals have
infinities, but no division by zero). But division by zero does not
make sense within the mathematics directly supported by C and C++ -
integer arithmetic, modulo arithmetic, and floating point approximations
to reals and complex numbers.
|
David Brown <david.brown@hesbynett.no>: Oct 31 10:48AM +0100
On 30/10/16 21:36, Mr Flibble wrote:
>> real numbers.
> But in mathematics division by zero is undefined so you are talking
> bollocks.
Ah, the old "proof by repeated assertion" - re-enforced by gratuitously
colourful language. (I have nothing against a bit of swearing where
appropriate - but it does not help when you are wrong.)
Mathematics is more than the arithmetic you learned at school - and more
than the arithmetic supported directly by C++. There are useful
mathematical structures in which division by zero /is/ defined (though
usually excluding 0/0). You might not be familiar with them - most
people are not - but they still exist.
|
David Brown <david.brown@hesbynett.no>: Oct 31 11:09AM +0100
On 30/10/16 22:04, Rick C. Hodgin wrote:
> parts, would be able to apply something like a cask to indicate that in
> a particular portion, this should be the result should it encounter a
> division by zero condition.
It is very rare that there is any sensible answer for the result, except
an error indicator. If you have an algorithm that may end up doing
division by zero, then spotting that error and trapping it in some way
could be a good idea. Whether you call that a NaN, a trap, an exception
or a cask is just details. And if it helps the software developer write
better code, or spot their mistakes faster, great.
However, I would say that if an algorithm can try to execute a division
by zero, the algorithm is broken. At best, it is going to be wildly
unstable somewhere - your tools may trap division by zero, but what
about division by 0.00000000000000000000000000000001 that is likely to
be just as wrong?
>> undefined in the language.
> Yes, because that's the way it is today. I'm suggesting it shouldn't be
> like that, and with some redesign, wouldn't need to be like that.
The mathematics of integers, reals and complex numbers don't change with
the times. If you want to include some support for division by zero
(other than tracking errors), you are no longer trying to approximate
real number arithmetic with your floating point.
> IEEE 754 also defines signaling and non-signaling forms, so it's at least
> incorporated into fp that the possibility of legitimate recovery exists,
> though it will trap to an OS-level handler.
No, NaNs are not there for recovery. They exist in IEEE to help track
errors and find bugs (such as dropping to a debugger when a signalling
NaN is generated), and to allow code to know that an incorrect
calculation has occurred. They are not of any use in trying to correct
the calculation or generate a correct output given incorrect input or an
incorrect algorithm.
> special cases without the extra overhead of trapping to the OS, noting
> the trap, redirecting to an app handler, returning to the OS, then
> finally returning back to the original instruction stream.
That's fine - I have nothing against such an idea. C++ supports it
manually:
double safediv(double x, double y) {
if (y == 0) throw std::overflow_error("Division by zero");
return x / y;
}
For your language, you would use casks, and you can make it automatic if
you like (as Java does). It adds a small run-time overhead to do the
checking, but it is your decision whether you want the feature or not.
>>> address it.
>> Lots of hardware has no efficient way of making such traps.
> That's true today. I'm talking about looking to the future.
I look to the future, and for every processor made that has efficient
traps on division by zero, there will be thousands made that don't have
such traps. There even will be thousands made that don't even have
instructions for division. And there is no reason why that should ever
change.
It is, of course, fine for you to say that your language will require
such hardware support in its target processors. That won't fly for C or
C++, but it's fine for /your/ language to make such choices.
>>> design, and support for both into my CAlive compiler.
>> In virtually every case, a division by 0 is a bug in the code.
> That's true today. :-) I'm talking about looking to the future. :-)
Again, basic mathematics won't change in the future. Unless you are
doing maths with structures (such as the Reimann sphere) that support
division by 0 in a consistent and sensible way, then dividing by zero is
usually a bug in the code. It might turn up due to incorrect input
(garbage in, garbage out) - an error in whatever is feeding the
algorithm, rather than in the algorithm itself. And NaNs can be a
convenient way of spotting this without having to explicitly check for
division by 0 in the code.
> within the context of a larger known formula, which must be broken out
> to into discrete operations, it can make sense, and in many cases it
> does" (or words to that effect).
No, I don't have to say that.
|
Real Troll <real.troll@trolls.com>: Oct 31 08:59AM -0400
On 29/10/2016 22:59, Stefan Ram wrote:
> undefined.«, C++ 2016, 5.6p4.
> Does it say anywhere that a division by zero /is/ allowed
> (is not undefined behavior) in floating-point divisions?
A number is a number whether an integer or a decimal number. Therefore,
division by zero is not defined and one should introduce error checking
to avoid this problem.
|
leigh.v.johnston@googlemail.com: Oct 31 06:08AM -0700
You are simply wrong. Division by zero is undefined in mathematics.
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 31 06:28AM -0700
> You are simply wrong. Division by zero is undefined in mathematics.
You are stuck on one point, Leigh, and can't break past it. That doesn't
change the fact that there's more to the explanation of division by zero
than that one position.
If you pursue the truth, you'll come to realize that there's more than
you previously thought (about a great many things ... including faith in
Jesus Christ).
Best regards,
Rick C. Hodgin
|
David Brown <david.brown@hesbynett.no>: Oct 31 02:37PM +0100
> You are simply wrong. Division by zero is undefined in mathematics.
Please update Wikipedia, based on your new-found expertise in
mathematics. To get started, edit this page:
<https://en.wikipedia.org/wiki/Riemann_sphere#Arithmetic_operations>
Then move on to
<https://en.wikipedia.org/wiki/Projectively_extended_real_line>
<https://en.wikipedia.org/wiki/Wheel_theory> should be deleted altogether.
Those of us who know a little more mathematics, will continue to say
that division by zero is undefined for integers, real numbers, and any
other fields, as well as computer-based approximations to those fields -
but that division by zero /is/ defined for certain other mathematical
structures.
It is fine to say that you are never going to need these structures.
/I/ am highly unlikely to ever need them, despite knowing about them.
And most people will never know of or care about their existence. But
repeating your ignorance does not make you look any smarter.
|
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 31 05:35PM
On 31/10/2016 13:37, David Brown wrote:
> /I/ am highly unlikely to ever need them, despite knowing about them.
> And most people will never know of or care about their existence. But
> repeating your ignorance does not make you look any smarter.
Those three "mathematical structures" are gibberish; yes the articles
should be deleted. Again: division by zero is undefined in kosher
mathematics.
/Flibble
|
Gareth Owen <gwowen@gmail.com>: Oct 31 05:56PM
> But in mathematics division by zero is undefined so you are talking
> bollocks.
Depends which field you're in. Real or complex numbers?
Yeah definitely undefined.
But mathematicians - devious bastards that we are - have created domains
in which there is a zero element with defined division.
The fact you don't know enough advanced mathematics to appreciate that
truth of that statement a shame; that you assert your ignorance in
denying is embarrassing.
|
Gareth Owen <gwowen@gmail.com>: Oct 31 05:57PM
> Those three "mathematical structures" are gibberish; yes the articles
> should be deleted. Again: division by zero is undefined in kosher
> mathematics.
Wow. That's ... Stucklesque.
|
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 31 05:59PM
On 31/10/2016 17:56, Gareth Owen wrote:
> The fact you don't know enough advanced mathematics to appreciate that
> truth of that statement a shame; that you assert your ignorance in
> denying is embarrassing.
Nope. Anyone can make up any old bollocks in any field as is the case
here. Division is undefined, end of.
/Flibble
|
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 31 06:02PM
On 31/10/2016 17:57, Gareth Owen wrote:
>> should be deleted. Again: division by zero is undefined in kosher
>> mathematics.
> Wow. That's ... Stucklesque.
And whilst we are on this subject: there is no such thing as negative
zero in mathematics. IEEE floating point is wrong in including support
for negative zero.
/Flibble
|
Gareth Owen <gwowen@gmail.com>: Oct 31 06:11PM
> And whilst we are on this subject: there is no such thing as negative
> zero in mathematics
This is true (to the best of my knowledge). Stopped clocks, and all that.
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 31 11:22AM -0700
On Monday, October 31, 2016 at 1:56:43 PM UTC-4, gwowen wrote:
> Yeah definitely undefined.
> But mathematicians - devious bastards that we are - have created domains
> in which there is a zero element with defined division.
It's worse than that:
1 + 2 + 3 + 4 ... = -1/12
https://www.youtube.com/watch?v=w-I6XTVZXww
> The fact you don't know enough advanced mathematics to appreciate that
> truth of that statement a shame; that you assert your ignorance in
> denying is embarrassing.
All truly advanced math people are obvious lunatics. It's so easy to
see from the nonsensical stuff they come up with. So, it's not fair
to judge Leigh on standards where they think an infinite sum of ever-
increasing positive integers is actually -1/12.
:-)
Best regards
Rick C. Hodgin
|
Melzzzzz <Melzzzzz@zzzzz.com>: Oct 31 06:25PM
> All truly advanced math people are obvious lunatics.
Bullshit. Math is rational science. You can't get more rational then in
math...
--
press any key to continue or any other to quit
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 31 11:28AM -0700
On Monday, October 31, 2016 at 2:26:05 PM UTC-4, Melzzzzz wrote:
> > All truly advanced math people are obvious lunatics.
> ... Math is rational science. You can't get more rational then in
> math...
Psssst. Hey... come over here, Melzzzzz. I'll let you in on a little
secret... I was kidding.
:-)
Best regards,
Rick C. Hodgin
|
Melzzzzz <Melzzzzz@zzzzz.com>: Oct 31 06:49PM
> Psssst. Hey... come over here, Melzzzzz. I'll let you in on a little
> secret... I was kidding.
>:-)
Oh!
--
press any key to continue or any other to quit
|
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 31 07:49PM +0100
On 31.10.2016 10:44, David Brown wrote:
> make sense within the mathematics directly supported by C and C++ -
> integer arithmetic, modulo arithmetic, and floating point approximations
> to reals and complex numbers.
Uhm, none of the above seems at all useful to me.
I once (1986) defined a kind of division by zero that was useful for
Dempster-Shafer evidence combination formulas. Essentially it treats A*B
as a multiset {A, B}, and then A/B is practically defined for B=0 by
allowing a negative number of a factor in a set. It all reduces to
simple operations on pairs for the cases of practical interest.
This allowed simple general code (it was in Modula-2) without
special-casing all over the place.
But there is no infinity in such a scheme, and I'd better mention, in
order to not give people wrong ideas, that apparently it can't
reasonably support addition or subtraction of pairs other than those
that have the same count of 0. So it's a scheme that is practical for
certain programming tasks, but as far as I can see not for mathematics.
Unless mathematicians can enjoy the elegance of the code.
The infinity of the Riemann sphere and of the whatever-projected real
line, seems to be nothing but a device to allow vertical lines to be
expressed as y = ax + b, with a as infinity. That "explains" why
-infinity = +ininity in such scheme: the vertical line can be viewed as
going up, or down, at will. But it's utter nonsense: it's a kludge, at a
high cost, to support a single case, for which there is no need.
So, I think Leigh is entirely right about the x/0 that yields infinity.
It's just idiocy. :)
Cheers!,
- Alf
|
