Re: Indeterminate math
On Tue, Oct 15, 2002 at 04:07:51PM -0700, [EMAIL PROTECTED] wrote: [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 [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One This is my sig file. Is it not nify? Worship the sig file. http://www.sluggy.com
Re: Indeterminate math
Sounds like a good place for fail, as described in Exegesis 4, so that it could be taken as undef or an exception depending on pragmata. 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. 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 [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Don't worry, baby, my wrath can be pretty groovy. http://www.goats.com/archive/980804.html -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ Who are you and what have you done with reality? --Jamin Gray
Re: Indeterminate math
[EMAIL PROTECTED] wrote: From: Michael G Schwern [EMAIL PROTECTED] 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 22 Mob: 07798 528923 Fax: 01954 206360 Web: www.invisible.uk.net
Re: Lukasiewiczian logic (was Indeterminate math)
On Mon, Oct 14, 2002 at 06:27:48PM -0700, David Whipp wrote: 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. Looks like the X value of the 4 (or 9) state logics that ASIC designers use. I suspect that it would be possible to implement this with properties and overloading. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-11/msg00124.html -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Indeterminate math
In a message dated Tue, 15 Oct 2002, Angel Faus writes: 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
Re: Indeterminate math
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
Re: Indeterminate math
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
Prototype-Based Inheritance (was Re: Indeterminate math)
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
Re: Prototype-Based Inheritance (was Re: Indeterminate math)
Would it make sense for the syntax to be more like
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).
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
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
All I want is a warm bed, a kind word, and unlimited power.
Re: Indeterminate math
On Wed, Oct 16, 2002 at 02:54:37AM +1000, Ken Williams wrote: 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. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Indeterminate math
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
Re: Indeterminate math
In a message dated Tue, 15 Oct 2002, Jonathan Scott Duff writes: 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
Re: Indeterminate math
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.
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 [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Here's hoping you don't harbor a death wish!
Re: Indeterminate math
In a message dated Tue, 15 Oct 2002, Michael G Schwern writes:
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
Re: Indeterminate math
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).
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
Re: Indeterminate math
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 | |[EMAIL PROTECTED]| |You're just another X --Filter| +-+
Indeterminate math
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. 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 [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Don't worry, baby, my wrath can be pretty groovy. http://www.goats.com/archive/980804.html
Re: Indeterminate math
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?] Cheers, Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ Any wire cut to length will be too short
RE: Indeterminate math
From: Michael G Schwern [EMAIL PROTECTED] 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/ .
Re: Indeterminate math
At 10:38 PM +0100 10/14/02, Leon Brocard wrote: 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 [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Indeterminate math
On Mon, Oct 14, 2002 at 05:45:23PM -0400, [EMAIL PROTECTED] wrote: 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 [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] 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
Re: Indeterminate math
On Mon, Oct 14, 2002 at 07:06:57PM -0400, Michael G Schwern wrote: 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:[EMAIL PROTECTED] icq:4321282
Re: Indeterminate math
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. 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/0NaN 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 | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Indeterminate math
On 2002-10-14 at 19:48:23, Mark J. Reed wrote: 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. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Indeterminate math
On Mon, Oct 14, 2002 at 07:48:23PM -0400, Mark J. Reed wrote: 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 [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Indeterminate math
From: Mark J. Reed [EMAIL PROTECTED] Summary of values: 1/0 +Inf -1/0 -Inf 0/0 NaN Inf/0NaN Inf/Inf 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. -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: Indeterminate math
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. 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. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Indeterminate math
On Monday 14 October 2002 20:20, [EMAIL PROTECTED] wrote: 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.
Re: Indeterminate math
On Mon, Oct 14, 2002 at 08:25:43PM -0400, Mark J. Reed wrote: 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 [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I'm a man, but I can change... if I have to. -- Red Green
Lukasiewiczian logic (was Indeterminate math)
From: Andrew Rodland [EMAIL PROTECTED] After much fighting with google to find the right spelling, Sorry bout that. Your searching was probably as difficult as my attempts to pronounce it. 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? Yup. It would be cool to be able to overload , ||, and ! to implement Lukasiewiczian logic within a given scope. I'm no expert, but I wrote a short essay explaining Lukasiewiczian logic. See http://ars.userfriendly.org/cartoons/read.cgi?id=20020904tid=389032 Trivia: Jan Lukasiewicz is the Polish in Reverse Polish Notation. Trivia 2: my mom, Carole O'Sullivan nee Lucas, says Lukasiewicz is probably my second cousin fifteen times removed, or something like that. It's probably my best credentials in the math world. -Miko mail2web - Check your email from the web at http://mail2web.com/ .
RE: Indeterminate math
Mark J. Reed wrote:
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.
RE: Lukasiewiczian logic (was Indeterminate math)
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. Looks like the X value of the 4 (or 9) state logics that ASIC designers use. I use Perl to do ASIC testbenches and stuff: so I'll probably be constructing something similar (and hopefully I'll have some nice bitwise and/or operators available: I use bitwise and | frequently; though I can accept that the majority of Perl users don't). Maybe I'll implement Verilog as a Parrot language. Dave.
Re: Indeterminate math
On 2002-10-14 at 20:49:52, Michael G Schwern wrote: 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? ;) Heh, indeed. :) But seriously, you could do worse. JavaScript receives 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. :) -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
