On 11/14/2002 1:58 PM, Angel Faus wrote:
=section ** Pseudo-Numbers
=section *** NaN
The value CNaN (Not a Number) may be returned by some
functions or operations to signal that the result of a
calculation (for example, division by zero) cannot be
represented by a numeric value.
...
=section
On 11/26/2002 8:02 AM, James Mastros wrote:
Guys, can we please not argue over just how arithmetic and such works
for NaN and Inf, and defer to IEEE specs (IEEE-754, AKA IEEE floating
point)? It'll save much argument, and that's how it'll almost
certianly be implemented anyway. Give
James Mastros wrote:
Guys, can we please not argue over just how arithmetic
and such works for NaN and Inf, and defer to IEEE specs
(IEEE-754, AKA IEEE floating point)? It'll save much
argument, and that's how it'll almost certianly be
implemented anyway.
NaN requires a pragma. As such,
On Tuesday, November 26, 2002, at 05:02 AM, James Mastros wrote:
Guys, can we please not argue over just how arithmetic and such works
for NaN and Inf, and defer to IEEE specs (IEEE-754, AKA IEEE floating
Yes and no. perl6-internals has been discussing this, so I think we
can pause and not
On Tuesday, November 26, 2002, at 07:21 AM, Garrett Goebel wrote:
NaN requires a pragma. As such, shouldn't documenting it be deferred
till later?
Yes, but not _too_ much later. If CNaN isn't the default behavior,
we have to document what _is_ the default behavior. :-) And if you
need a
On Tue, 2002-11-26 at 11:55, Michael Lazzaro wrote:
Does it overflow (via an exception?), silently truncate, or ?. (Parrot
may offer us both options.) We can choose to call the result platform
dependent, or define it explicitly. But let's wait and see what the
Parrot people think, since
On Thu, Nov 14, 2002 at 07:58:55PM +0100, Angel Faus wrote:
Hi all,
Hi Angel,
This is the numeric literals part, reformated to follow Michael's
outline.
My contribution is some copyediting and a few suggestions. Take what
you think is worthwhile.
On Fri, Nov 15, 2002 at 08:17:04PM -0700, Luke Palmer wrote:
: Presumably, Ci is a keyword and it would be an error to say sub i.
Depends on how the complex module decides to implement it. It could
make it a keyword, or it could just import a sub of some sort.
Whether you have to use the complex
Why would Ci be a keyword? Its not in perl5, and I don't
remember any discussion where non-real numbers would
be part of the core language.
My fault.
For some strange reason I had a false idea that this had been said
somewhere, and didn't check. Shame on me.
-angel
Jonathan Scott Duff writes:
Maybe I'm just wired wrong, but Inf is the same size as Inf (since
they are the same value) To me Inf is a textual representation of
a value that's larger than all other values. So ...
Inf == Inf # true
false , but all( (0..Inf) ^[==]
On Thu, Nov 14, 2002 at 07:58:55PM +0100, Angel Faus wrote:
The C1i and C-1i numbers can be also written
respectively, Ci and C-i, so the previous example
could be rewritten:
my $z = 2.3 + i;
OK. So, what does this print?
sub i {return 40}
my $z = 2.3 + i;
print z:$z\n;
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Fri, 15 Nov 2002 22:11:58 -0500
From: Frank Wojcik [EMAIL PROTECTED]
Content-Disposition: inline
X-Virus-Scanned: by AMaViS perl-11
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
On Thu, Nov 14, 2002 at 07:58:55PM
Frank Wojcik wrote:
On Thu, Nov 14, 2002 at 07:58:55PM +0100, Angel Faus wrote:
The C1i and C-1i numbers can be also written
respectively, Ci and C-i, so the previous example
could be rewritten:
my $z = 2.3 + i;
OK. So, what does this print?
sub i {return 40}
my $z = 2.3 + i;
print
Luke Palmer wrote:
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Fri, 15 Nov 2002 22:11:58 -0500
From: Frank Wojcik [EMAIL PROTECTED]
Content-Disposition: inline
X-Virus-Scanned: by AMaViS perl-11
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
On Thu, Nov 14, 2002 at
$N ** Inf NaN
I'd expect Inf
Er... doesn't it depend on whether Inf is odd or even, and
therefore indeterminate and therefore NaN ?
R.
On Thursday, November 14, 2002, at 11:58 AM, Jonathan Scott Duff wrote:
=section * Caveats when using BigNum/BigRats
All literal numbers are interepreted at compile-time,
before there is any information available about the type
of the variable that will store them.
Hmm. In your example,
On Thu, Nov 14, 2002 at 01:12:52PM -0700, Luke Palmer wrote:
From: Tanton Gibbs [EMAIL PROTECTED]
Date: Thu, 14 Nov 2002 15:00:57 -0500
Inf - Inf NaN
I'd expect 0.
I'd expect Inf
Which Inf is bigger? Inf, or Inf?
You can't know, so it's NaN.
Maybe I'm just
Date: Thu, 14 Nov 2002 16:23:00 -0600
From: Jonathan Scott Duff [EMAIL PROTECTED]
Which Inf is bigger? Inf, or Inf?
You can't know, so it's NaN.
Maybe I'm just wired wrong, but Inf is the same size as Inf (since
they are the same value) To me Inf is a textual representation of
a
On Thu, Nov 14, 2002 at 07:58:55PM +0100, Angel Faus wrote:
It works just like the standard scientific notation:
the left portion of the Ce is the coefficient, and the
right is the exponent, so a number of the form CC.CCCeEE
is actually intepreted as CC.CCC * 10**EE.
For example, the
Inf - Inf NaN
I'd expect 0.
I'd expect Inf
Inf * $N Inf
^^^
presumably you meant -Inf here
Why?
Tanton
From: Tanton Gibbs [EMAIL PROTECTED]
Date: Thu, 14 Nov 2002 15:00:57 -0500
Inf - Inf NaN
I'd expect 0.
I'd expect Inf
Which Inf is bigger? Inf, or Inf?
You can't know, so it's NaN.
Inf * $N Inf
^^^
presumably you meant -Inf here
Why?
21 matches
Mail list logo
