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
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
[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,
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
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
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, 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
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
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
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
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
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
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
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
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
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
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,
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
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
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/
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
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
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:
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
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.
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
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 in Perl
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
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
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
30 matches
Mail list logo
