Indeterminate math
Michael G Schwern
produce a divide by zero error in Perl 6, or if it would return a value
representing an indeterminate result (undef?) It would make more sense for
Perl, upon being given a simple bit of impossible math, to return undef
(like other functions do on failure) than to generate an error. The error
seems a throwback to earlier days of hardwired calculators.
If nothing else it would make guarding against indeterminate math easier.
Rather than the user having to trap an error, or do possibly complicated
work to see if any of the denominators might be zero, you can just see if
the result is undef.
[1] I apologize for forgetting who.
[2] Discussion of divide by zero and why it's not infinity [3]
http://mathforum.org/dr.math/faq/faq.divideby0.html
[3] I was always taught it's infinity.
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
Don't worry, baby, my wrath can be pretty groovy.
http://www.goats.com/archive/980804.html
mosul...@crtinc.com
> This came up at YAPC::Europe. Someone [1] wanted to know if 1/0
> would produce a divide by zero error in Perl 6, or if it would
> return a value representing an indeterminate result (undef?)
> It would make more sense for Perl, upon being given a simple bit
> of impossible math, to return undef (like other functions do on
> failure) than to generate an error. The error seems a throwback
> to earlier days of hardwired calculators.
The problem with returning undef is that undef numifies to zero. It would
make more sense if either 1/0 returned NaN, if Perl6 has NaN, or throw an
error, which Larry has indicated will be a concept in Perl6.
There once was a man from NaNtucket
Who kept all his bits in a bucket
He said "I'm a hero!
I divided by zero!
and the bits in the bucket, they tuckit!"
-Miko
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
Jonathan Scott Duff
> This came up at YAPC::Europe. Someone [1] wanted to know if 1/0 would
> produce a divide by zero error in Perl 6, or if it would return a value
> representing an indeterminate result (undef?) It would make more sense for
> Perl, upon being given a simple bit of impossible math, to return undef
> (like other functions do on failure) than to generate an error. The error
> seems a throwback to earlier days of hardwired calculators.
I thought that under the new world order it would generate an exception
rather than an error.
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
Leon Brocard
> Someone [1] wanted to know if 1/0 would produce a divide by zero
> error in Perl 6, or if it would return a value representing an
> indeterminate result (undef?)
This is probably the mathematician in me escaping, but I also remember
a discussion at Y::E about number systems. What if you didn't want
Perl to use the "normal" number system, but instead only have, say,
positive integers, or integers modulo prime P. This is possible with
Perl 5, but with lots of scary overloading. Will it be any different
in Perl 6? [Or are we not quite there yet?]
Cheers, Leon
--
Leon Brocard.............................http://www.astray.com/
scribot.................................http://www.scribot.com/
.... Any wire cut to length will be too short
Michael G Schwern
> The problem with returning undef is that undef numifies to zero.
Yes, but it does produce a warning.
> It would make more sense if either 1/0 returned NaN, if Perl6 has NaN, or
> throw an error, which Larry has indicated will be a concept in Perl6.
What happens when NaN is used in an expression? Is NaN + 0 == NaN?
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
11. Every old idea will be proposed again with a different name and
a different presentation, regardless of whether it works.
-- RFC 1925
Dan Sugalski
>Michael G Schwern sent the following bits through the ether:
>
>> Someone [1] wanted to know if 1/0 would produce a divide by zero
>> error in Perl 6, or if it would return a value representing an
>> indeterminate result (undef?)
>
>This is probably the mathematician in me escaping, but I also remember
>a discussion at Y::E about number systems. What if you didn't want
>Perl to use the "normal" number system, but instead only have, say,
>positive integers, or integers modulo prime P. This is possible with
>Perl 5, but with lots of scary overloading. Will it be any different
>in Perl 6? [Or are we not quite there yet?]
I expect the overloading will be just as pervasive, though perhaps
not as scary as in perl 5. (I suppose you could just go override the
vtable methods for all the core data types... :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
David Hand
> What happens when NaN is used in an expression? Is NaN + 0 == NaN?
Actually, NaN is never equal to anything at all, even NaN.
Many languages have an isNaN() function for that.
--
David "cogent" Hand
<http://davidhand.com/> <mailto:davi...@davidhand.com> <icq:4321282>
Mark J. Reed
dividing by 0 if the numerator is either infinite or also 0.
The reason most implementations throw an error on division by 0
is that they either don't have a representation for infinity
(not a problem in IEEE floating point) or the rest of the arithmetic
operations don't behave sensibly when handed an infinite value.
I would argue that Perl's arithmetic operations should behave sensibly
on infinite values and that 1/0 should therefore just return +Infinity.
No exception, no error, no undefined value.
Summary of values:
1/0 +Inf
-1/0 -Inf
0/0 NaN
Inf/0 NaN (Sign doesn't matter for these two;
Inf/Inf NaN +Inf and -Inf may be interchanged)
--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754
Mark J. Reed
> Actually, 1/0 is not NaN; it's +Infinity. You only get NaN out of
> dividing by 0 if the numerator is either infinite or also 0.
> The reason most implementations throw an error on division by 0
> is that they either don't have a representation for infinity
> (not a problem in IEEE floating point) or the rest of the arithmetic
> operations don't behave sensibly when handed an infinite value.
Well, let me backpedal a bit, here.
I realize the above is mathematically simplistic. The
real reason y = x/0 returns an error is because no matter what
value you assign to y, you aren't going to get x back via multiplying
y by 0. Certainly 0 times infinity is not going to give you back
your original numerator; the infinity value of x/0 is just a convention,
inspired by the fact that the *limit* of x/z as z approaches 0 is infinity.
So it's probably a good idea when doing $y = $x/$z to notice that
$z is 0 before later trying to get $x back by multiplying $y * $z.
I suspect the erroneousness of division by 0 should be pragmatically
controlled.
Michael G Schwern
> Actually, 1/0 is not NaN; it's +Infinity. You only get NaN out of
> dividing by 0 if the numerator is either infinite or also 0.
There are several verbal proofs why 1/0 is not +Infinity here:
http://mathforum.org/dr.math/faq/faq.divideby0.html
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.
-- Larry Wall in <1999111922...@kiev.wall.org>
Mark J. Reed
> There are several verbal proofs why 1/0 is not +Infinity here:
> http://mathforum.org/dr.math/faq/faq.divideby0.html
imply that 1/0 is positive infinity in "real world math".
However, returning Infinity when asked to divide a finite
number by 0 is conformant behavior according to the IEEE spec.
An implementation is *allowed* to indicate an error on division
by 0, but is not *required* to - returning infinity is legal.
It is also, as an example, the behavior required by the ECMAScript
specification.
In any case, my point was simply that 1/0 is not NaN. If you're going to
return a defined value as the result of 1/0, you should return +Infinity
instead. NaN is used for other purposes, such as square roots of negative
numbers when complex numbers are not available, or as the return value
of failed numeric coercions, or of operations where even as a limit the
result is indeterminate, such as 0/0.
mosul...@crtinc.com
> Summary of values:
>
> 1/0 +Inf
> -1/0 -Inf
> 0/0 NaN
> Inf/0 NaN
Are Inf and NaN going to be standard in Perl 6? As long as we're traveling
down that road, how about i (the square root of -1), or Lukasiwiscean Null?
(Sorry if I sound sarcastic, I'm actually honestly curious.)
My inner Larry Wall is right now saying that there needs to be a more
generalized solution to all this. OK, here's one. By default, anything/0
throws an exception. However, you can load modules to handle those
exceptions, substituting Inf, NaN, or whatever as the evaluation of the
expression.
Larry Wall
: From: Mark J. Reed mark...@turner.com
: > Summary of values:
: >
: > 1/0 +Inf
: > -1/0 -Inf
: > 0/0 NaN
: > Inf/0 NaN
: > Inf/Inf NaN
:
: Are Inf and NaN going to be standard in Perl 6?
I don't know if they're "standard", but it has to be drop-dead easy to add them.
: As long as we're traveling
: down that road, how about i (the square root of -1), or Lukasiwiscean Null?
: (Sorry if I sound sarcastic, I'm actually honestly curious.)
Obviously complex arithmetic is important to a sizable set of people, and
they want it to be fast.
: My inner Larry Wall is right now saying that there needs to be a more
: generalized solution to all this. OK, here's one. By default, anything/0
: throws an exception. However, you can load modules to handle those
: exceptions, substituting Inf, NaN, or whatever as the evaluation of the
: expression.
You can control how things compile in a lexical scope via pragma,
and you can control how division is implemented for a class via
overloading. That's probably enough control to get wherever you want
without implicitly throwing and catching exceptions.
Larry
Andrew Rodland
> Are Inf and NaN going to be standard in Perl 6? As long as we're traveling
> down that road, how about i (the square root of -1), or Lukasiwiscean Null?
> (Sorry if I sound sarcastic, I'm actually honestly curious.)
>
After much fighting with google to find the right spelling, it looks like
"Lukasiewiczian NULL" is just the nifty NULL that SQL has, and the nifty ways
that it affects logical and aggregate operations. Actually, something I
wouldn't mind seeing in other languages -- I can't say if perl is one of
those, but if it can be provided by expansion, that would be neato.
Miko, did I get the right thing out of that?
--hobbs
P.S. Delurk.
Michael G Schwern
> On 2002-10-14 at 20:15:33, Michael G Schwern wrote:
> > There are several verbal proofs why 1/0 is not +Infinity here:
> > http://mathforum.org/dr.math/faq/faq.divideby0.html
>
> Yeah, that would be why I sent my followup. I did not mean to
> imply that 1/0 is positive infinity in "real world math".
Sorry, I was a little too fast on the reply gun.
> However, returning Infinity when asked to divide a finite
> number by 0 is conformant behavior according to the IEEE spec.
> An implementation is *allowed* to indicate an error on division
> by 0, but is not *required* to - returning infinity is legal.
<snip>
> It is also, as an example, the behavior required by the ECMAScript
> specification.
Heh. "Because Javascript does it" is supposed to be an argument for? ;)
> In any case, my point was simply that 1/0 is not NaN. If you're going to
> return a defined value as the result of 1/0, you should return +Infinity
> instead.
Mathematically, 1/0 is not +Infinity. It's undefined/indeterminate in the
set of rational numbers. The IEEE may say otherwise.
So here's a big question. Should Perl's core maths conform to IEEE or
mathematics? (Not something I expect an answer to.)
> NaN is used for other purposes, such as square roots of negative
> numbers when complex numbers are not available, or as the return value
> of failed numeric coercions, or of operations where even as a limit the
> result is indeterminate, such as 0/0.
So NaN means "this equation might have an answer, just not in your current
set of numbers" and it means "a coercion failed" and it means "the limit is
indeterminate"? A lot of meanings. But it doesn't mean 1/0?
This gets into questions of how Perl's math systems are extended/overridden.
Something better suited to guys like Tels I guess. While I'd personally
like built-in support for automatic bignum conversion, I suppose the best
answer I could expect right now would be "Perl 6's support for additional
maths will be greater than or equal to Perl 5".
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
I'm a man, but I can change... if I have to.
-- Red Green
David Whipp
> I realize the above is mathematically simplistic. The
> real reason y = x/0 returns an error is because no matter what
> value you assign to y, you aren't going to get x back via multiplying
> y by 0.
Well, that may be true in math; but there's no reason why it has to be
true in Perl6 (using the Math::Perverse module?)
Imagine
> $b = 7 / 0
.... $b = undef but DivZero(7) but Overload('*' => sub ($rhs) { $rhs==0 ? 7 :
.... })
> print $b * 0
.... "7"
> print $b * 2 * 0
.... "14"
I.e. you can use a runtime property to remember the value that was
divided by zero. I'm not sure what the correct syntax is to make that
really clean: hopefully the DivZero property could do the Overload.
Dave.
Mark J. Reed
> > It is also, as an example, the behavior required by the ECMAScript
> > specification.
>
> Heh. "Because Javascript does it" is supposed to be an argument for? ;)
a lot of (IMHO) undeserved criticism. The name is a blatant marketing
ploy, and abuses abound in web pages, but there's really not much wrong
with the core language, and there are even a couple things I wouldn't
mind seeing Perl6 borrow from it.
I'm going to continue my train of thought as it wanders directly off
the rails of Perl6, so feel free to stop reading this now. :)
JavaScript is a fine object-oriented scripting language with
prototype-based inheritance. (I think that term is a misnomer, btw -
if you create an object using a prototype, then change the prototype,
that later change is visible through the earlier-created object.
That doesn't sound like the behavior of what we normally mean by
the word "prototype" in English. But it's the standard term.)
Since it is prototype-based, the syntax for defining (or faking)
classes, and subclasses thereof, is a little clunky; and it has no
data hiding - everything is effectively a public associative array,
But both of those things could be said about Perl5, as well, although
Perl5's syntax is less clunky.
On the single axis of O-O purity - which I am by no means advocating as
a general measure of language utility - JavaScript ranks somewhere above
Python (which is itself above Perl5) and below Ruby.
It has the usual stuff - inheritance (albeit prototype-based);
automatic type coercion among strings and numbers and Objects; regular
expressions (syntax stolen from Perl5, of course); dynamic arrays
(with a variety of manipulation methods that were also stolen from
Perl5: splice, slice, shift, unshift, push, pop); and associative
arrays (every object is one, really). It also has some a couple
nice features regarding functions:
They have prototypes, but they're not enforced by the
language. A function definition may specify a set of named
parameters, but any function may be called with fewer (in
which case the unspecified ones have the undefined value),
or more (which may be accessed via an array analogous to @_).
An anonymous function/closure may call itself recursively
despite not having a name by which to do so. This in particular
is something I would like to see in Perl6.
There are some oddly confusing things. We were talking about what
to return for "failure" in the context of 1/0. Well, as I said,
JavaScript actually returns +Inf for 1/0, but for other cases it
has *three* different nil values:
1. undefined (like Perl undef; true of variables that have
been declared but not yet assigned any
other value)
2. null (for use when an Object reference is expected)
3. NaN (for use when a number is expected)
Additionally, an attempt to access a variable that hasn't even been
declared yet throws an exception, so that could be considered a fourth
case, although it pertains to variables rather than their values.
The biggest problem with JavaScript is the fact that the environment
in which it runs - the interface to the outside world - is not defined
by the language spec. You can't even write "Hello, world!"
without specifying more information. (Running in a web browser?
Use document.write(). Running under the Windows Script Host?
Use WScript.stdOut.writeLine(). Running under the Mozilla project's
rhino interpreter? Use print().)
Anyway, I don't think JavaScript is going to make any inroads in the
sysadmin scripting language "market". For Windows administrators, it has
some advantages: it's already there on modern versions of the OS, and
it's a huge improvement over the previous scripting language for which
that was true, namely DOS batch files. But Windows administrators who
were brought up in the Windows world will probably use VBScript instead of
JScript to access the WSH, and those who were brought up in the UNIX
world will just download ActiveState Perl. :)
Anyway, I'll shut up now. Just don't knock it 'til you've really tried it.
:)
Adam D. Lopresto
could be taken as undef or an exception depending on pragmata.
--
Adam Lopresto (ad...@cec.wustl.edu)
http://cec.wustl.edu/~adam/
Who are you and what have you done with reality?
--Jamin Gray
Richard Nuttall
>From: Michael G Schwern sch...@pobox.com
>
>
>>This came up at YAPC::Europe. Someone [1] wanted to know if 1/0
>>would produce a divide by zero error in Perl 6, or if it would
>>return a value representing an indeterminate result (undef?)
>>It would make more sense for Perl, upon being given a simple bit
>>of impossible math, to return undef (like other functions do on
>>failure) than to generate an error. The error seems a throwback
>>to earlier days of hardwired calculators.
>>
>>
>
>The problem with returning undef is that undef numifies to zero.
>
Why can't it return "undef but +Inf", or "undef but NaN" for 0/0,
which would then cause a warning/error/nothing, as required by pragma,
following the "0 but true" that has been discussed previously.
Normal numification would presumably propogate the "undef but +Inf" value.
R.
--
Richard Nuttall
Invisible Networks
DDI: 01954 206361
Tel: 01954 200002
Mob: 07798 528923
Fax: 01954 206360
Web: www.invisible.uk.net
Angel Faus
> Mathematically, 1/0 is not +Infinity. It's undefined/indeterminate
> in the set of rational numbers. The IEEE may say otherwise.
Mathematically, 1/0 is whatever you define it to be.
And it is perfectly correct to assume that operations happen in the
extended real line, and thus that 1/0 is exactly +Inf.
And probably more convenient.
The only remote problem is that the extended real line isn't a proper
field. But, who cares...
-angel
Trey Harris
>
> > Mathematically, 1/0 is not +Infinity. It's undefined/indeterminate
> > in the set of rational numbers. The IEEE may say otherwise.
>
> Mathematically, 1/0 is whatever you define it to be.
Well, sure. That's as axiomatic as saying, "mathematically, the number
one is whatever you define it to be." But a mathematical system that has
a definition which is inconsistent with the rest of the system is a flawed
one. If you let 1/0 be *anything*, then ordinary algebraic logic falls
apart. Those silly proofs where it is "proven" that 1 = 2, 1 + 1 = 1,
etc., all depend on division by zero being possible (regardless of what
its value is). You have to keep division by zero illegal to avoid these
absurd results. Hence, to my mind at least, exception-throwing or NaN is
a better solution than infinity.
But will it really matter one way or the other? Probably not, so we
should stop quibbling. Perhaps if someone could demonstrate a real-world
need for either NaN or infinity in this case, or else a case for why
exception-throwing should *not* go away, we'd be able to bring the
discussion somewhere more fruitful.
For my part: division by zero is so often a programmer error, and so
rarely a useful thing to do, that it seems to me that exception-throwing
should remain the behavior in Perl 6.
Trey
Angel Faus
> > Mathematically, 1/0 is whatever you define it to be.
>
> Well, sure. That's as axiomatic as saying, "mathematically, the
> number one is whatever you define it to be." But a mathematical
> system that has a definition which is inconsistent with the rest of
> the system is a flawed one. If you let 1/0 be *anything*, then
> ordinary algebraic logic falls apart. Those silly proofs where it
> is "proven" that 1 = 2, 1 + 1 = 1, etc., all depend on division by
> zero being possible (regardless of what its value is). You have to
> keep division by zero illegal to avoid these absurd results.
> Hence, to my mind at least, exception-throwing or NaN is a better
> solution than infinity.
>
My point was that there is no stone-carved mandate of the ancient
mathematicians saying whether the value of 1 / 0 is defined or not. I
did not intend to say that you could assign it any value.
It is general practice among mathematicians to say that is undefined,
but it is also general practice among other respectable ocupations to
say it is "something like infinite", and both approaches can be
formalized.
But of course, as you said, this is largelly irrelevant to the actual
discussion.
My personal opinion is that a language that lets you add "apples" +
"oranges" and get 0, shouldn't be too picky about 1 / 0 not being a
"proper" number.
-angel
Ken Williams
On Tuesday, October 15, 2002, at 07:05 AM, Michael G Schwern wrote:
> This came up at YAPC::Europe. Someone [1] wanted to know if 1/0 would
> produce a divide by zero error in Perl 6, or if it would return a value
> representing an indeterminate result (undef?) It would make more sense
> for
> Perl, upon being given a simple bit of impossible math, to return undef
> (like other functions do on failure) than to generate an error. The
> error
> seems a throwback to earlier days of hardwired calculators.
Well, if you're an exceptions guy like me, you'd *much* rather have it
produce an error than a zero, which I assume undef would still evaluate
to.
NaN is another option, following some standard or other.
> [2] Discussion of divide by zero and why it's not infinity [3]
> http://mathforum.org/dr.math/faq/faq.divideby0.html
>
> [3] I was always taught it's infinity.
Positive or negative infinity? (it's a trap!)
-Ken
Michael Lazzaro
On Monday, October 14, 2002, at 07:54 PM, Mark J. Reed wrote:
> Heh, indeed. :) But seriously, you could do worse. JavaScript
> receives
> a lot of (IMHO) undeserved criticism. The name is a blatant marketing
No, I've had to use it off-and-on for the past year... it deserves it.
:-) But enough of that.
I agree, prototype based inheritance is really useful sometimes.
(Those of you not subjected to JS may be more familiar with
Class::Classless, a quite nice perl5 implementation.)
I'd definitely like to see builtin support for instance based
inheritance. I've found many, many uses for Class::Classless, and have
made halfbreed variations of it for several special-case situations.
IMO the best situation would be to have both worlds collide; not
strictly class-based, not strictly proto-based, but a mix-and-match of
each in accordance to the particular problem you're trying to solve.
An interesting way to do this could simply be to allow object
instances, as well as normal classes, in the inheritance tree; you
could then mix a prototype-based object with, for example, several
class-based mixin behaviors, etc.
Something like:
my $obj = Something.new; # (1) obj based on a class
class MyClass is $obj {...} # (2) a class based on an obj!
my $obj2 = MyClass.new; # (3) obj based on a class based on
an obj
my $obj3 isa $obj; # (4) an obj based on another obj
my $obj4 isa $obj isa MyClass; # (5) obj + mixin (but what syntax???)
Note that (2) would have interesting implications if you changed $obj
runtime, but would be very uncommon. (4,5) could be quite common, tho.
And (4,5) need to use a word other than 'is', which means that
currently none of these syntaxes look anything alike. :-P
Mixing OO frameworks is quite useful in some real-world situations.
Sometimes it's more efficient to change your OO implementation than to
try to translate your problem to fit the one you're given.
MikeL
Jonathan Scott Duff
>
> On Tuesday, October 15, 2002, at 07:05 AM, Michael G Schwern wrote:
> > This came up at YAPC::Europe. Someone [1] wanted to know if 1/0 would
> > produce a divide by zero error in Perl 6, or if it would return a value
> > representing an indeterminate result (undef?) It would make more sense
> > for
> > Perl, upon being given a simple bit of impossible math, to return undef
> > (like other functions do on failure) than to generate an error. The
> > error
> > seems a throwback to earlier days of hardwired calculators.
>
> Well, if you're an exceptions guy like me, you'd *much* rather have it
> produce an error than a zero, which I assume undef would still evaluate
> to.
People have used the terms "error" and "exception" interchangably in
this disucssion. To me, an "error" is something that stops program
execution while an "exception" may or may not stop execution depending
on what the user decides to do about exceptions.
1/0 could throw an exception, yet continue execution. Somewhere I
expect we should be able to define a policy for what to do in these
situations.
use Policy DivideByZero => Nan;
use Policy DivideByZero => Inf;
use Policy DivideByZero => DivideByZeroException;
I'm sure someone else can pick a better syntax than I.
Adam D. Lopresto
my $obj3 = $obj.new;
Of course, that would kill my ".= new" idea for instantiation (since it would
call an instance-based new instead of class-based), but I'm getting less fond
of that syntax anyway (though I think .= should definitely be supported in the
language, and $a .= foo; should DTRT, ie, $a = $a.foo).
--
Adam Lopresto (ad...@cec.wustl.edu)
http://cec.wustl.edu/~adam/
All I want is a warm bed, a kind word, and unlimited power.
Ken Williams
On Wednesday, October 16, 2002, at 04:44 AM, Jonathan Scott Duff wrote:
> People have used the terms "error" and "exception" interchangably in
> this disucssion. To me, an "error" is something that stops program
> execution while an "exception" may or may not stop execution depending
> on what the user decides to do about exceptions.
Agreed. I've meant "exception" in my comments, in the trappable sense
of the term. I don't see much need for a true untrappable error - one
man's error is another man's case.
> 1/0 could throw an exception, yet continue execution. Somewhere I
> expect we should be able to define a policy for what to do in these
> situations.
>
> use Policy DivideByZero => Nan;
> use Policy DivideByZero => Inf;
> use Policy DivideByZero => DivideByZeroException;
>
> I'm sure someone else can pick a better syntax than I.
I don't think there are going to be many real situations when people
would want Inf or Undef (99% of the rare cases where people think they
might want it, they're probably wrong ;-), but NaN or Exception could
indeed be common needs.
-Ken
Trey Harris
> People have used the terms "error" and "exception" interchangably in
> this disucssion. To me, an "error" is something that stops program
> execution while an "exception" may or may not stop execution depending
> on what the user decides to do about exceptions.
I'm not familiar with that dichotomy. In the OO languages I'm familiar
with, errors fall into two basic classes, compile time and run time.
Compile time errors are 'fatal', in the sense that they will prevent the
program from ever beginning execution. Runtime errors throw exceptions,
which may be caught, and if not caught at the top level of execution, will
cause the program to abort (or do whatever else it is supposed to do by
default when an error propagates that far). Java (and at least one of the
Eiffel runtimes I've used) makes a further division in the runtime
category between "exceptions", which must be handled or declared, and
"errors", which are conditions like "out of memory" which are so baroque
or whose potential for ocurring is so pervasive as to make required
handling a ridiculous burden on the programmer.
But you still *may* attempt to handle these errors, if you wish--they are
still exceptions. For instance, running on a system in which programs can
give previously allocated memory back to the operating system, a program
might attempt to use a fast but memory-intensive algorithm, but, upon
catching the OutOfMemoryError exception, return the memory to the OS and
fall back to a slower but less greedy algorithm.
Perl obscures things a bit by its free movement between compile- and
runtimes, in some sense collapsing the two types of errors into one, or
rather making it possible for either to manifest in the guise of the
other. For example, a string eval could cause the ordinarily compile-time
syntax error, which would generate a runtime exception, or a BEGIN block
might try to perform a division by zero, in which case the ordinarily
runtime DivByZero exception would be thrown at compile time (and probably
cause the program to "never begin execution" in the sense we ordinarily
think about it). So the compile-time vs. runtime error distinction goes
away, so far as the programmer is concerned.
Since I assume that Perl will not require that subroutines declare the
exceptions they might throw (but I guess we'll find out in the next Apo!),
the dichotomy Java sets up goes away, too. So, I think it is completely
reasonable to use "error" and "exception" as interchangeable terms. If
there is a difference, it may be merely in point of view. Errors
"happen," while exceptions are "thrown" and "caught."
> 1/0 could throw an exception, yet continue execution. Somewhere I
> expect we should be able to define a policy for what to do in these
> situations.
>
> use Policy DivideByZero => Nan;
> use Policy DivideByZero => Inf;
> use Policy DivideByZero => DivideByZeroException;
>
> I'm sure someone else can pick a better syntax than I.
I think miko just suggested one, though I'm still digesting it.
Trey
Trey Harris
> On Tue, Oct 15, 2002 at 01:44:50PM -0500, Jonathan Scott Duff wrote:
> > People have used the terms "error" and "exception" interchangably in
> > this disucssion. To me, an "error" is something that stops program
> > execution while an "exception" may or may not stop execution depending
> > on what the user decides to do about exceptions.
>
> Unless I've missed my mark, Perl errors have always been trappable [1]. Does
> that make them exceptions? We've been calling them errors for years now.
The Perl trainers I've seen have been calling Perl errors "exceptions" for
years now, mostly, I think, to shut up the Javaphiles who think that
they're the only ones that have such a wondrous and unprecedented thing
(at least, that's why I always did it ;-)
> Put another way, is there a significant difference between:
>
> eval {
> $foo = 1/0;
> print "Bar";
> }
> if( $@ =~ /^Illegal division by zero/ ) {
> ... oops ...
> }
>
> and
>
> try {
> $foo = 1/0;
> print "Bar";
> }
> catch {
> when /^Illegal division by zero/ {
> ... oops ...
> }
> }
None that I can see.
Trey
Michael G Schwern
> this disucssion. To me, an "error" is something that stops program
> execution while an "exception" may or may not stop execution depending
> on what the user decides to do about exceptions.
Unless I've missed my mark, Perl errors have always been trappable [1]. Does
that make them exceptions? We've been calling them errors for years now.
Put another way, is there a significant difference between:
eval {
$foo = 1/0;
print "Bar";
}
if( $@ =~ /^Illegal division by zero/ ) {
... oops ...
}
and
try {
$foo = 1/0;
print "Bar";
}
catch {
when /^Illegal division by zero/ {
... oops ...
}
}
(putting aside that exception handlers stack).
Whatever you call it, exception or error, it will halt the program if left
unhandled.
[1] Less the few odd really hard core "the interpreter is having a bad trip"
sort of errors.
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
Here's hoping you don't harbor a death wish!
jy...@gryphon.csc.calpoly.edu
long time reader, first time writer...
On Tue, Oct 15, 2002 at 10:06:37PM +0200, Angel Faus wrote:
> >
> > > Mathematically, 1/0 is whatever you define it to be.
> >
> > Well, sure. That's as axiomatic as saying, "mathematically, the
> > number one is whatever you define it to be." But a mathematical
> > system that has a definition which is inconsistent with the rest of
> > the system is a flawed one. If you let 1/0 be *anything*, then
> > ordinary algebraic logic falls apart. Those silly proofs where it
> > is "proven" that 1 = 2, 1 + 1 = 1, etc., all depend on division by
> > zero being possible (regardless of what its value is). You have to
> > keep division by zero illegal to avoid these absurd results.
> > Hence, to my mind at least, exception-throwing or NaN is a better
> > solution than infinity.
> >
>
> My point was that there is no stone-carved mandate of the ancient
> mathematicians saying whether the value of 1 / 0 is defined or not. I
> did not intend to say that you could assign it any value.
Well, yes and no. The original progenitor of the number zero did say
that he thought 0 / 0 should be 0, so mathematicians haven't always gotten
it right. But it can be proven that 1 / 0 should be undefined, and once
it's been proven, it doesn't need to be gone over again -- effectively
setting it in stone.
So for instance, 1 / 0 is not defined because the division algorithm
explicitly fails to work correctly for it[1]. If you can't use the division
algorithm how do you expect to divide? It cannot be done.
1 / 0 can only be construed as +Inf if we're discussing limits of functions
such that the denominator approaches 0 (from the positive side). It does
not appear that we are discussing such things, but the actual integers
1 and 0. Even in the case of limits i am want to be careful, for infinity
is not technically a number, but a convenient concept used to describe
certain behaviors...
> It is general practice among mathematicians to say that is undefined,
> but it is also general practice among other respectable ocupations to
> say it is "something like infinite", and both approaches can be
> formalized.
No offense, but i would love to see someone's formalization that the
integer division 1 / 0 is equivalent to infinity. Mostly because i
would attempt to rip it asunder :)
(i might fail, but i would try...)
> My personal opinion is that a language that lets you add "apples" +
> "oranges" and get 0, shouldn't be too picky about 1 / 0 not being a
> "proper" number.
i more have to agree with tilly on this one[2]. Essentially, if i ever
divide by zero, it's probably an unmistakable error on my part. And
it should raise a trappable error so that if i'm expecting it i can
shuffle it under the rug, and if i'm not i'll be notified that something
went 'splody.
jynx
[1]: This comes from a recent discussion on perlmonks where i attempted
to formally iron things out for people, since i have yet to see anywhere
thus far on the web where it was actually formalized.
(formalization being markedly different from rationalization)
http://www.perlmonks.org/index.pl?node_id=203698
[2]: Tilly's opinion can be found at the following:
http://www.perlmonks.org/index.pl?node_id=98996
+-------------------------------------+
|jynx d mouse |
|jy...@dead.org |
|"You're just another X" --Filter|
+-------------------------------------+
Luke Palmer
>
> eval {
> $foo = 1/0;
> print "Bar";
> }
> if( $@ =~ /^Illegal division by zero/ ) {
> ... oops ...
> }
>
> and
>
> try {
> $foo = 1/0;
> print "Bar";
> }
> catch {
> when /^Illegal division by zero/ {
> ... oops ...
> }
> }
>
> (putting aside that exception handlers stack).
>
Yeah. The latter is not valid syntax in any version of Perl. :)
try {
$foo = 1/0;
print "Bar\n";
CATCH {
when /division by [zero|0]/ {
... ooops ...
}
}
}
Luke
Michael G Schwern
> [1]: This comes from a recent discussion on perlmonks where i attempted
> to formally iron things out for people, since i have yet to see anywhere
> thus far on the web where it was actually formalized.
> (formalization being markedly different from rationalization)
> http://www.perlmonks.org/index.pl?node_id=203698
Here's two simple proofs by contradiction.
Let 1/0 == +Infinity
Then 1 == +Infinity * 0
Since anything times 0 == 0
1 == 0
Contradiction.
Here's another way to look at it.
0 * 1/0 == ?
On the one hand, anything times 0 == 0. So it's 0.
On the other hand, a * b/a == b. So it's 1.
Contradiction.
I don't know exactly what you're looking for in terms of formal proofs,
but the above math will hold just fine.
For more a more complete analysis of what happens when you try to
introduce infinity into the real number system, see:
http://mathforum.org/library/drmath/view/55764.html
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
This is my sig file. Is it not nify? Worship the sig file.
http://www.sluggy.com
David W. Cantrell
> Actually, 1/0 is not NaN; it's +Infinity.
Correct for standard floating-point arithmetic (with the denominator
assumed to be +0.0).
> You only get NaN out of
> dividing by 0 if the numerator is either infinite or also 0.
Not quite.
x/0 yields NaN if and only if x is NaN or 0.
If x is infinite, the result must be an appropriately signed infinity.
> The reason most implementations throw an error on division by 0
> is that they either don't have a representation for infinity
> (not a problem in IEEE floating point) or the rest of the arithmetic
> operations don't behave sensibly when handed an infinite value.
> I would argue that Perl's arithmetic operations should behave sensibly
> on infinite values and that 1/0 should therefore just return +Infinity.
> No exception, no error, no undefined value.
>
> Summary of values:
>
> 1/0 +Inf
> -1/0 -Inf
> 0/0 NaN
> Inf/0 NaN
No. Rather, as noted above, +Infinity/+0.0 must yield +Infinity.
> (Sign doesn't matter for these two;
> Inf/Inf NaN +Inf and -Inf may be interchanged)
David
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service
David W. Cantrell
> Here's two simple proofs by contradiction.
But neither of them is valid, as explained below.
> Let 1/0 == +Infinity
That can be done (e.g., as in floating-point arithmetic, where the
denominator would be assumed to be +0.0). However, as far
as pure mathematics is concerned, if 1/0 is defined, it would
most often be in the context of the projective extension of the
real or complex numbers, in which case 1/0 would be _unsigned_
infinity, not positive infinity. (Readers might look at my MathWorld
article about the projective extension of the reals at
<http://mathworld.wolfram.com/ExtendedRealNumberProjective.html>.)
Anyway, let's assume, as you say, that we do have a system in which
it makes sense to say 1/0 = +Infinity. For this discussion, let's take that
system to be standard floating-point arithmetic. But you must beware that
whenever we go from one number system to another, some properties
will change. For example, the property sqrt(a*b) = sqrt(a)*sqrt(b) holds
if a and b are nonnegative reals. But if we venture into the complex
number system, this property no longer holds. And if one mistakenly
thinks that it continues to hold, then contradictions are easily obtained.
Of course, such contradictions, being based on fallacious reasoning,
should not convince us that the complex number system is inherently
flawed...
> Then 1 == +Infinity * 0
This does not follow from 1/0 = +Infinity. Perhaps you thought that by
multiplying by 0 on both sides, you would get 1 = +Infinity*0, but that
is incorrect. You would instead have gotten 1/0*0 = +Infinity*0, the right
side of which does _not_ simplify to 1 (since cancelling factors of 0
between numerator and denominator is not justifiable). Rather, each side
yields NaN (Not a Number).
> Since anything times 0 == 0
Incorrect. For example, +Infinity*0 is NaN, rather than 0.
> 1 == 0
> Contradiction.
No. There is no contradiction -- unless, of course, you do something
which is not allowable in the system.
> Here's another way to look at it.
>
> 0 * 1/0 == ?
NaN
> On the one hand, anything times 0 == 0. So it's 0.
No, the result is not necessarily 0. As noted above, +Infinity*0 isn't 0.
> On the other hand, a * b/a == b. So it's 1.
No, the result is not necessarily 1. As noted above, 0*1/0 isn't 1.
> Contradiction.
As noted above, there is no contradiction.
> I don't know exactly what you're looking for in terms of formal proofs,
> but the above math will hold just fine.
No.
> For more a more complete analysis of what happens when you try to
> introduce infinity into the real number system, see:
> http://mathforum.org/library/drmath/view/55764.html
I have great respect for The MathForum. However, their discussion of
division by zero could certainly be improved in some ways.
Regards,
David Cantrell
David W. Cantrell
> So for instance, 1 / 0 is not defined because the division algorithm
> explicitly fails to work correctly for it[1]. If you can't use the
> division algorithm how do you expect to divide? It cannot be done.
Yes, it can. See my article mentioned below.
> 1 / 0 can only be construed as +Inf if we're discussing limits of
> functions such that the denominator approaches 0 (from the positive
> side). It does not appear that we are discussing such things, but the
> actual integers 1 and 0. Even in the case of limits i am want to be
> careful, for infinity is not technically a number, but a convenient
> concept used to describe certain behaviors...
1/0 can be construed as +Inf in other contexts (in which, BTW, one could
well argue that it is a number).
> > It is general practice among mathematicians to say that is undefined,
Undefined in the real or complex number systems, certainly. But 1/0 is
defined in their projective extensions.
> > but it is also general practice among other respectable ocupations to
> > say it is "something like infinite", and both approaches can be
> > formalized.
> No offense, but i would love to see someone's formalization that the
> integer division 1 / 0 is equivalent to infinity. Mostly because i
> would attempt to rip it asunder :)
> (i might fail, but i would try...)
Hmm. Then you might enjoy my article "How I Divided by Zero, and Lived to
Tell About It!" at <http://mathforum.org/discuss/sci.math/m/338231/338231>.
Have fun attempting "to rip it asunder"!
David W. Cantrell
> sch...@pobox.com (Michael G Schwern) wrote:
> > Here's two simple proofs by contradiction.
>
> But neither of them is valid, as explained below.
>
> > Let 1/0 == +Infinity
>
> That can be done (e.g., as in floating-point arithmetic, where the
> denominator would be assumed to be +0.0). However, as far
> as pure mathematics is concerned, if 1/0 is defined, it would
> most often be in the context of the projective extension of the
> real or complex numbers, in which case 1/0 would be _unsigned_
> infinity, not positive infinity. (Readers might look at my MathWorld
> article about the projective extension of the reals at
> <http://mathworld.wolfram.com/ExtendedRealNumberProjective.html>.)
Oops! I have just found that the address for this article at MathWorld
has changed. The correct link is now
<http://mathworld.wolfram.com/ProjectivelyExtendedRealNumbers.html>.
Sorry if I had sent anyone "on a wild goose chase"!
--
David