Re: Numeric literals, take 1
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 *** Inf The terms CInf and C-Inf represent positive and negative infinity; you may sometimes use these to create infinite lists. For the CInf values, perl will operate them following the standard conventions. For example: 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 examples and references, but don't define nonstandard standard perl6 semantics when a good standard exists. (I'm looking for a good reference on the IEEE semantics right now, but I'm not having much luck for some reason.) (We need a few additional rules, actualy: NaN is false, and -Inf and +Inf are both true. If either are forced into an int, and error occours (? on that last point.) This whole paragraph might properly be pushed off to the discussion of Num in Bool context later.) -=- James Mastros
Re: Numeric literals, take 1
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 examples and references, but don't define nonstandard standard perl6 semantics when a good standard exists. (I'm looking for a good reference on the IEEE semantics right now, but I'm not having much luck for some reason.) (Yes, I'm replying to myself.) The best reference I can find right now is http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html. If anybody has a better one, I'd /love/ to see it. (IEEE-754 itself is non-free.) (here -N is a negitive number, +N is a negive number, and N is any number (but not NaN or Inf).) N / Inf = 0 Inf / Inf = NaN # Multipication between infintes follows normal sign rules, and is infinite in result. Inf * Inf = Inf -N/0 = -Inf 0/0 = NaN +N/0 = +Inf Inf - Inf = NaN Inf * 0 = NaN All arithmetic ops with any arg NaN results in NaN. NaN==NaN is NaN, which is false. NaN!=NaN is also NaN, which is false. -=- James Mastros
RE: Numeric literals, take 1 [x-bayes][x-adr]
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, shouldn't documenting it be deferred till later? And then, you might want to take a look at: o IEEE 754 Support in C99 document http://grouper.ieee.org/groups/754/meeting-materials/2001-07-18-c99.pdf o IEEE 754 web page http://grouper.ieee.org/groups/754/ Give examples and references: In chronological order: Damian Conway: Perl NaN's will not be IEEE 754 compliant. Damian: NaN is dead. [...] Except perhaps under a Cuse IEEE pragma of some kind, in which case it would be a proper IEEE Norweigian Blue NaN. Larry: : IIRC, native data types, which are all lowercase (e.g., : int, bit, long, etc.) cannot be undef. However, their : class equivalents (e.g., Int, Bit, Long, etc) can be undef. That is correct. It probably throws an exception if you try to assign an undefined value to a lowercase type. (Though an IEEE num might well set itself to NaN instead.) So there you have it. NaN is outside the core... or at least a pragma away... Or pickup a thread: http://www.mail-archive.com/perl6-language@perl.org/msg08521.html http://www.mail-archive.com/perl6-language@perl.org/msg08359.html http://groups.google.com/groups?hl=enlr=ie=UTF-8threadm=Pine.LNX.4.44.021 0311948500.18773-10%40london.wall.orgrnum=1prev=/groups%3Fnum%3D20%26h l%3Den%26lr%3D%26ie%3DISO-8859-1%26q%3D%2B%2522IEEE%2522%2Bgroup%253Aperl.pe rl6.language%2Bauthor%253ALarry%2Bauthor%253AWall -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Numeric literals, take 1
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 worry about it quite yet. Floats will almost certainly be IEEE, but in addition to floating point (num, aka C double), most of the same issues exist for sized integers, both signed and unsigned. Worse, the behaviors are platform-dependent. For example, what happens when you add two 8-bit numbers, and the result is no longer an 8-bit number, e.g. 'overflow'? (We may indeed have access to a type called 'int8', since Parrot will likely have it.) my int8 $i = 254; my int8 $j = 254; $i += $j; # ??? 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 they're closer to the action. MikeL
Re: Numeric literals, take 1
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 pragma to enable CNaN, which in turn makes fundamental changes in how many Perl6 numeric types behave, we ought to document _both_ behaviors in the Numerics section. Even if it's a standard pragma, it still may be a basic feature of Perl6 that needs documenting, and we should associate it with the other numeric behaviors. (We can't quite go in Camel-book order, w.r.t. pragma and other toggles.) But it's true, perl6-internals is talking about these issues right now. So if we wait a bit, we can have a much more informed discussion. MikeL
Re: Numeric literals, take 1
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 they're closer to the action. It might help the Parrot people if they knew what their target languages wanted. (Not that they can guarantee delivery of said requests, of course. :-) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Numeric literals, take 1
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. - =section * Numeric Literals =section ** Integer and Decimal literals There are many ways to specify literal numeric values in perl, but they default to base 10 for input and output. s/perl/Perl/ (Aren't we still using the capitalization to distinguish between the interpreter and the language?) Perl allows you to use the standard scientific notation s/the// It works just like the standard scientific notation: Delete this phrase; you've already said that this IS standard SN. the left portion of the Ce is the coefficient, and the s/the/The/ right is the exponent, so a number of the form CC.CCCeEE is actually intepreted as CC.CCC * 10**EE. I would suggest using XX for the exponent, so as to have less confusion with the 'e'-as-exponent-marker. Also, add a sentence stating that the exponent marker may be in either case. Then you get: ...right is the exponent, so a number of the form CC.CCCeXX is actually intepreted as CC.CCC * 10**XX. You may use either upper- or lowercase 'e' as the exponent marker, so, for example, 3.6e3 is the same as 3.6E3. For example, the literal C7.828e6 is interpreted as C7823000. 7828000, as was already pointed out You can use negative numbers in the exponent side, allowing you to write very small numbers. You may write very small numbers by using negative exponents. =section ** Radix Notation For integer numbers, you can represent the literal value in any other base, using the Cradix: syntax. s/other// a need to represent digits that are greater than 9. You can do this in two ways: Make the above be one paragraph; you haven't started a new thought yet. Alphabetic characters: Following the standard convention, perl will interpret the A letter as the digit 10, the B letter as digit 11, and so on. s/perl/Perl/ ...will interpret the letter A...the letter B as the digit ^^^ Separating by dots: You can also write each digit in its decimal representation, and separate digits using the C. character. Although separating by dots is perfectly correct and fluid, I would suggest using the term dotted notation, just so people start getting used to it. my $m = 256:255.255.255.0;# 256-base # base 256 For example, the integer 30 can be written in hexadecimal base in two equivalent ways: Either say: ...in hexadecimal... or ...in base 16..., but don't mix them. Also note that a compile-time error will be generated if you specify a digit that is larger than your radix can support. For instance, my $x = 3:23; # error Very small nit: the problem here is the digit 3, but on first glance it looks like you are saying that the digit in question is 23. Extend the comment to explain: my $x = 3:23; # error; can't use digit '3' in base 3 Beware that when writing negative integers, the negative character C- should be at the leftest point of the expression: When writing negative integers, be aware that the minus sign (C-) must always be the leftmost character in the literal, which means it will come to the left of the radix when using radix notation. my $z = -256:234.254; # negative number my $e = 256:-234.254; # error Keep in mind that once the number has been read by perl Perl it becomes just a magnitude. That is it loses all trace of s/That is it/That is, it/ the way it was originally represented and is just a number. Perl will use decimal base when printing all the numbers, no matter what base did you use to type them. Either say base 10 or decimal notation, not decimal base. I would suggest: Perl always uses decimal for printing numbers, regardless of what base you used to enter them. =section ** Underscore character as a seprator Perl allows the underscore character, C_, to be placed as s/placed/used/ a separator between the digits of any literal number. You can use this to break up long numbers into more readable forms. ...to break up a long number into a more readable form. There aren't any rules to it; you can use it however you like: The only rule is that you may only use underscore between digits, not between any other characters that is allowed to appear in a number. 123_456_000.000 (floating point) 2:0110_1000 (binary) 16:FF_88_EE (hexidecimal) 1312512.25(decimal number) 1_312_512.25 (the same) 1_312_512_.25 (error) 1_312_512._25 (error) 1.375_e56 (error) 1.375e_56 (error) _2_3_45___6 (error) [delete intermediate comment, collapse examples together, add
Re: Numeric literals, take 1
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 module explicitly is a different question. I'd say if you use the bareword i it's pretty clear what's wanted. Use of i as a postfix operator is also pretty indicative... : I don't recall complex numbers ever being considered as a builtin : type; i.e. non-module. Could someone point me to where this was : discussed? This whole issue of what's builtin and what isn't is really kinda bogus. A built-in is something that is either pre-imported or auto-imported. That's all. To the first approximation, the only function that *has* to be built-in to Perl is sub (that is, lambda). Almost everything else is negotiable. : (Just, I don't see a general enough usage for them as to make them : builtin...) I don't think Perl 6 documentation should use the word builtin. At best we can go for a hierarchy of standard levels, where each level assumes the availability of a certain set of function names. But even then, different levels might have the same name an implement them differently. A level 0 Perl might implement basic functionality like Cif only as a subroutine. Looking at it another way, we can have varying levels of guaranteed functionality from femtoperl picoperl nanoperl microperl milleperl perl kiloperl megaperl gigaperl teraperl petaperl Calling something builtin has little meaning unless you answer the question: Built into what? Larry
RE: Numeric literals, take 1
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
Re: Numeric literals, take 1
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) ^[==] (0..Inf) ) # true , maybe
Inf != Inf # false
false
Inf Inf # false
false
Inf Inf # false
false
Inf - Inf == 0 # true
Inf - Inf = NaN because it may be +Inf or -Inf
Inf + Inf == Inf# true
true , but maybe for consistency with previous it have to be false .
so may be , actually, everything above have to be undef .
In any case , I think that if expression contains more then *single*
Inf , in *general* case it have to be carefully analyzed , and
mathematically it can give practically anything , depending on the
degree of infinity of that particular Inf , and since we are not
(???) going to built in symbolic analysis of limits , it have to be
out altogether.
so , possibly , all previous examples have to give Undef , because *we
dont know* how exactly the limit was taken .
examples
in all examples here n-Inf
Inf Inf
? (n) (n*n)
? (n*n) (n*n/10)
? (n)== (n/3)
? (n)-(n)
? (n/10) -(n/5)
? (n/2) -(n/3)
and once one consider more complex operations like * , ** , or their
combinations that gets *very* complicated . Every math course contains
*the whole chapter* exlussively on the subject of taking limits
it seems that Inf have well defined meaning in something like
1..Inf because that defines what elements are present in the list. so
we can compare , e.g. two such lists.
It comes to my mind now :
I think the rule have to be :
Inf is a literal value that *we write in perl source* but it cannot be
a result of intermediate expressions ( or any expressions ) when perl
is calculating. In particular perl cannot know what to do if it
encounter more then single Inf in *any* expression . just for
consistency. But may be I am wrong .
arcadi.
But, I'm willing to be educated on the subject. I don't ever use
infinities in code now and I don't think I'm likely to (except perhaps
in lazy list generation).
The only infinities of varying sizes that I know of are the alephs,
and they don't apply here.
It's actually
{ 0 , $P 1
$P ** Inf { 1 , $P == 1
{ Inf, $P 1
But perhaps we could forgo documenting any of the power cases and
leave it to common sense.
We can't leave *anything* to common sense because one person's common
sense may be different from another's. (i.e., there's no such thing
as common sense :)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Numeric literals, take 1
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;
Re: Numeric literals, take 1
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 +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;
Presumably, Ci is a keyword and it would be an error to say sub i.
I don't recall complex numbers ever being considered as a builtin
type; i.e. non-module. Could someone point me to where this was
discussed?
(Just, I don't see a general enough usage for them as to make them
builtin...)
Luke
Re: Numeric literals, take 1
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 z:$z\n;
Thats an easy one; it will print:
z::42.3
You can only expect so much out of the parser; moving from interpolating
simple scalars and arrays to interpolating full hashes and subs is already
a huge step. Knowing to interpolate full expressions would be more
harmful than helpful.
Re: Numeric literals, take 1
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 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;
Presumably, Ci is a keyword and it would be an error to say sub i.
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.
Re: Numeric literals, take 1
$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.
Re: Numeric literals, take 1
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, my BigInt $i = 777_666_555_444_333_222_111; perl has already read the text BigInt by the time it's gotten to the number, so it has some idea of what type of thing the numeric literal should be. Besides, what I think should happen is that perl should auto-adjust the type as it reads so that these are equivalent: my BigInt $i = 777_666_555_444_333_222_111; my $i = 777_666_555_444_333_222_111; In previous postings, Larry has said he hopes that there will be no BigInt and BigNum types: there will simply be Int and Num, which will know to represent themselves in Big* form when necessary. MikeL
Re: Numeric literals, take 1
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 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
Inf != Inf # false
Inf Inf # false
Inf Inf # false
Inf - Inf == 0 # true
Inf + Inf == Inf# true
But, I'm willing to be educated on the subject. I don't ever use
infinities in code now and I don't think I'm likely to (except perhaps
in lazy list generation).
The only infinities of varying sizes that I know of are the alephs,
and they don't apply here.
It's actually
{ 0 , $P 1
$P ** Inf { 1 , $P == 1
{ Inf, $P 1
But perhaps we could forgo documenting any of the power cases and
leave it to common sense.
We can't leave *anything* to common sense because one person's common
sense may be different from another's. (i.e., there's no such thing
as common sense :)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Numeric literals, take 1
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 value that's larger than all other values. So ... Inf == Inf # true Inf != Inf # false Inf Inf # false Inf Inf # false Inf - Inf == 0 # true Inf + Inf == Inf# true But, I'm willing to be educated on the subject. I don't ever use infinities in code now and I don't think I'm likely to (except perhaps in lazy list generation). Look at this. I think it's a pretty good (and interesting) explanation: http://askdrmath.com/library/drmath/view/53370.html The only infinities of varying sizes that I know of are the alephs, and they don't apply here. Actually they do. Consider a set with cardinality ℵ₀ (Aleph-null). What's the cardinality if you add one more number to that set? Still ℵ₀, right? Obviously the difference between their cardinal numbers is 1, but they're called the same thing. So you can't really subtract them with any _single_ meaning. Someone correct my if I've got my set theory messed up. Luke
Re: Numeric literals, take 1
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 literal C7.828e6 is interpreted as C7823000. That must be some new math there where 7.828 * 10**6 is 7823000 :-) I'd write out the steps: 7.828e6 - 7.828 * 10**6 - 7.828 * 100 - 7828000 =section ** Underscore character as a seprator Perl allows the underscore character, C_, to be placed as a separator between the digits of any literal number. You can use this to break up long numbers into more readable forms. There aren't any rules to it; you can use it however you like: The rule is that the underscore must appear between digits, so there is at least one rule. :-) Operation Result ---- Inf + $X Inf Inf + Inf Inf Inf - $X Inf Inf - Inf NaN I'd expect 0. Inf * $N Inf ^^^ presumably you meant -Inf here Inf * 0 NaN I'd expect 0 $N ** Inf NaN I'd expect Inf =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, my BigInt $i = 777_666_555_444_333_222_111; perl has already read the text BigInt by the time it's gotten to the number, so it has some idea of what type of thing the numeric literal should be. Besides, what I think should happen is that perl should auto-adjust the type as it reads so that these are equivalent: my BigInt $i = 777_666_555_444_333_222_111; my $i = 777_666_555_444_333_222_111; That's dwimmery-do! -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Numeric literals, take 1
Inf - Inf NaN I'd expect 0. I'd expect Inf Inf * $N Inf ^^^ presumably you meant -Inf here Why? Tanton
Re: Numeric literals, take 1
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?
$N represents a negative number.
Another thing, I remember you said:
$P ** Inf Inf
Which is not true.
It's actually
{ 0 , $P 1
$P ** Inf { 1 , $P == 1
{ Inf, $P 1
But perhaps we could forgo documenting any of the power cases and
leave it to common sense. OTOH, we could document every last detail.
I think the latter would be more suited to the goal of the project.
Luke
