Re: Indeterminate math

2002-10-18 Thread Michael G Schwern
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 mark

Re: Indeterminate math

2002-10-15 Thread jynx
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 mathe

Re: Indeterminate math

2002-10-15 Thread Luke Palmer
> 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 { >

Re: Indeterminate math

2002-10-15 Thread Trey Harris
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 whil

Re: Indeterminate math

2002-10-15 Thread Michael G Schwern
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 u

Re: Indeterminate math

2002-10-15 Thread Trey Harris
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

Re: Indeterminate math

2002-10-15 Thread 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

Re: Indeterminate math

2002-10-15 Thread Jonathan Scott Duff
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 > > represe

Re: Prototype-Based Inheritance (was Re: Indeterminate math)

2002-10-15 Thread Adam D. Lopresto
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 suppo

Prototype-Based Inheritance (was Re: Indeterminate math)

2002-10-15 Thread 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

Re: Indeterminate math

2002-10-15 Thread 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

Re: Indeterminate math

2002-10-15 Thread 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

Re: Indeterminate math

2002-10-15 Thread Trey Harris
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,

Re: Indeterminate math

2002-10-15 Thread 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 i

Re: Lukasiewiczian logic (was Indeterminate math)

2002-10-15 Thread Paul Johnson
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

Re: Indeterminate math

2002-10-15 Thread Richard Nuttall
[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 f

Re: Indeterminate math

2002-10-15 Thread Adam D. Lopresto
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

Re: Indeterminate math

2002-10-14 Thread Mark J. Reed
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

RE: Lukasiewiczian logic (was Indeterminate math)

2002-10-14 Thread David Whipp
> 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

RE: Indeterminate math

2002-10-14 Thread David Whipp
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 tr

Lukasiewiczian logic (was Indeterminate math)

2002-10-14 Thread [EMAIL PROTECTED]
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

Re: Indeterminate math

2002-10-14 Thread Michael G Schwern
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 no

Re: Indeterminate math

2002-10-14 Thread Larry Wall
On Mon, 14 Oct 2002, [EMAIL PROTECTED] wrote: : 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 i

Re: Indeterminate math

2002-10-14 Thread Andrew Rodland
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

Re: Indeterminate math

2002-10-14 Thread Mark J. Reed
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". How

Re: Indeterminate math

2002-10-14 Thread [EMAIL PROTECTED]
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 (

Re: Indeterminate math

2002-10-14 Thread Michael G Schwern
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.div

Re: Indeterminate math

2002-10-14 Thread Mark J. Reed
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

Re: Indeterminate math

2002-10-14 Thread 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 t

Re: Indeterminate math

2002-10-14 Thread David Hand
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

Re: Indeterminate math

2002-10-14 Thread Michael G Schwern
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

Re: Indeterminate math

2002-10-14 Thread Dan Sugalski
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 proba

RE: Indeterminate math

2002-10-14 Thread [EMAIL PROTECTED]
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 simpl

Re: Indeterminate math

2002-10-14 Thread Leon Brocard
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

Re: Indeterminate math

2002-10-14 Thread Jonathan Scott Duff
On Mon, Oct 14, 2002 at 05:05:14PM -0400, 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

Indeterminate math

2002-10-14 Thread Michael G Schwern
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