Nicholas Clark [EMAIL PROTECTED] wrote:
I had a think about this a few days ago. I can't see how to do fractions
in Roman Numerals.
integers and exponents in E notation should all be easy, shouldn't they?
No major problem for fractions. As for irrational numbers...
Mark.
David Nicol wrote:
RaFaL Pocztarski wrote:
Or maybe NaN evaluates to 'NaN' in string context and
+$x eq 'NaN' (or +$x eq NaN) could be used? NaN==NaN being false is in
fact very intuitive for me, as NaN is something without any numerical
meaning, so numerically compared to anything
RaFaL Pocztarski wrote:
I haven't got any contact with NaN before, but when Tim pointed that
NaN!=NaN is true in IEEE I thought that it does make sense. I see pros
and cons and it's not so ugly and non-intuitive as it can look. When
comparing $a and $b as numbers there is no need for
Damian Conway wrote:
But I assume that == means numerically equal (and here I could be
wrong). If what I assume is true however, then anything which doesn't
have any numerical meaning, numerically compared to anything (even to
itself) should not return the misleading result
Dan Sugalski wrote:
At 08:37 AM 10/9/2001 -0700, Brent Dax wrote:
For consistency, I'd prefer to use is: 3+(2 is i).
Well, the convention is suffixing an imaginary number with an i. I don't
think we'd be too well served to go a different route.
So the imaginary numbers would be standard
At 05:12 PM 10/10/2001 +0200, RaFaL Pocztarski wrote:
Dan Sugalski wrote:
At 08:37 AM 10/9/2001 -0700, Brent Dax wrote:
For consistency, I'd prefer to use is: 3+(2 is i).
Well, the convention is suffixing an imaginary number with an i. I don't
think we'd be too well served to go a
On Wed, 10 Oct 2001 11:32:02 -0400
Dan Sugalski [EMAIL PROTECTED] wrote:
Great idea, as well as sqrt(-1) returning 1i istead of raising the
exception.
If we do them, yep. Currently no promises there.
If you do that, make sure it has to be enabled with a pragma. Having
complex numbers
At 04:42 PM 10/10/2001 +0100, Sam Vilain wrote:
On Wed, 10 Oct 2001 11:32:02 -0400
Dan Sugalski [EMAIL PROTECTED] wrote:
Great idea, as well as sqrt(-1) returning 1i istead of raising the
exception.
If we do them, yep. Currently no promises there.
If you do that, make sure it has to be
BTW, I was thinking once that numeral literals like 4k or 10G
(meaning 4*2**10, 10*2**30) would be very nice. What do you think?
I think the meaning of the suffices are sufficiently vague as to make me
uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good case
for both, and
On Wed, Oct 10, 2001 at 05:21:02PM +0200, raptor wrote:
| So the imaginary numbers would be standard literals? Like
|
| $x=2+10i;
|
| Great idea, as well as sqrt(-1) returning 1i istead of raising the
| exception. BTW, I was thinking once that numeral literals like 4k or 10G
| (meaning
On Wed, Oct 10, 2001 at 06:20:31PM +0200, Trond Michelsen wrote:
BTW, I was thinking once that numeral literals like 4k or 10G
(meaning 4*2**10, 10*2**30) would be very nice. What do you think?
I think the meaning of the suffices are sufficiently vague as to make me
uncomfortable
Trond Michelsen wrote:
BTW, I was thinking once that numeral literals like 4k or 10G
(meaning 4*2**10, 10*2**30) would be very nice. What do you think?
I think the meaning of the suffices are sufficiently vague as to make me
uncomfortable supporting them. Is 1K 1024 or 1000? I can make a
Dan Sugalski wrote:
I'll leave that for Larry to decide. I'm just thinking of all the 60G hard
drives I see at Best Buy that are really 60e9 bytes, and the 1K ohm
resistors that are really 1000 ohms. (Well, give or take a bit for ambient
temperature...)
I prefer powers of 1024 because it
Dan Sugalski wrote:
At 04:42 PM 10/10/2001 +0100, Sam Vilain wrote:
On Wed, 10 Oct 2001 11:32:02 -0400
Dan Sugalski [EMAIL PROTECTED] wrote:
Great idea, as well as sqrt(-1) returning 1i istead of raising the
exception.
If we do them, yep. Currently no promises there.
If you do
Trond Michelsen wrote:
There's always the possibility of supporting SI's binary prefixes ;)
http://physics.nist.gov/cuu/Units/binary.html
An excellant idea. I was unaware of that standard, but was trying to head that
direction in my last posting.
Someone thought it wouldn't work with
On Wed, 10 Oct 2001 11:52:16 -0400, Dan Sugalski wrote:
If people want base 10, let them use e syntax.
1e3 = 1000
1k = 1024
I'll leave that for Larry to decide. I'm just thinking of all the 60G hard
drives I see at Best Buy that are really 60e9 bytes, and the 1K ohm
resistors that are really
On Wed, Oct 10, 2001 at 06:38:05PM +0200, RaFaL Pocztarski wrote:
I prefer powers of 1024 because it help a lot more than powers of 1000.
But if you think that the ambiguity is the only problem then use kbin; /
use kdec; or use k1000; / use k1024; pragmas could solve it.
$K = 2**10;
On Wed, 2001-10-10 at 17:32, Dan Sugalski wrote:
At 05:12 PM 10/10/2001 +0200, RaFaL Pocztarski wrote:
BTW, I was thinking once that numeral literals like 4k or 10G
(meaning 4*2**10, 10*2**30) would be very nice. What do you think?
I think the meaning of the suffices are sufficiently
At 07:01 PM 10/10/2001 +0200, Bart Lateur wrote:
On Wed, 10 Oct 2001 11:52:16 -0400, Dan Sugalski wrote:
If people want base 10, let them use e syntax.
1e3 = 1000
1k = 1024
I'll leave that for Larry to decide. I'm just thinking of all the 60G hard
drives I see at Best Buy that are
So the imaginary numbers would be standard literals? Like
$x=2+10i;
Great idea, as well as sqrt(-1) returning 1i istead of raising the
exception. BTW, I was thinking once that numeral literals
like 4k or 10G
(meaning 4*2**10, 10*2**30) would be very nice. What do you think?
-
U mean something like 'term' (or how this thing is called 'bareword' ? )
So I can say :
# $x = 10k;
my sub operator:number is postfix(k) ($num) {
return $num * 1000
}
# $x = 10K;
my sub operator:number is postfix(K) ($num) {
return $num * 1024
}
#u can say later print $x if $x?;
On Wed, Oct 10, 2001 at 06:28:42PM +0200, raptorVD wrote:
U mean something like 'term' (or how this thing is called 'bareword' ? )
So I can say :
# $x = 10k;
my sub operator:number is postfix(k) ($num) {
return $num * 1000
}
I think that would be
sub operator:K is postfix
On Wed, Oct 10, 2001 at 10:21:38AM -0700, David Whipp wrote:
First this thread tells me that 123foo will be 123 in numeric
context. Now I find myself wondering what 123indigo evaluates
to!
It would evaluate to 123. If use complex is in effect, it would
evaluate to 123i. At least that's the
Glenn Linderman wrote:
An excellant idea. I was unaware of that standard, but was trying to head that
direction in my last posting.
Someone thought it wouldn't work with imaginary numbers, but there actually is
no ambiguity if the imaginary i must immediately follow the number, and the
Buddha Buck wrote:
As someone else pointed out, the e notation is good for powers of
10. How about a corresponding b notation for binary
exponents? 4_294_967_296 == 4b30?
I really like that idea, it makes the floating point (scientific?)
notation symmetric and consistent with X/Xi SI
Jonathan Scott Duff wrote:
On Wed, Oct 10, 2001 at 10:21:38AM -0700, David Whipp wrote:
First this thread tells me that 123foo will be 123 in numeric
context. Now I find myself wondering what 123indigo evaluates
to!
It would evaluate to 123. If use complex is in effect, it would
First this thread tells me that 123foo will be 123 in numeric
context. Now I find myself wondering what 123indigo evaluates
to!
It would evaluate to 123. If use complex is in effect, it would
evaluate to 123i. At least that's the position I'm taking at the
moment ;-)
123i
Jonathan Scott Duff
# On Tue, Oct 09, 2001 at 10:17:26AM -0400, Dan Sugalski wrote:
# Depending on what Larry's planning, we may weld in support
# for imaginary
# numbers. While they're mind-warping, in some ways they're
# better than
# having a line labeled Beyond here be dragons or
Damian Conway wrote:
but I still have immense difficulty with the notion that:
$x == NaN
doesn't return true if $x contains NaN.
Anyone with a hardware background should have no difficulty with
this concept. All common HDLs have multi-valued logic systems,
including values like
Damian Conway wrote:
Sigh. I *do* see your point of view (Laziness), but I still have immense
difficulty with the notion that:
$x == NaN
doesn't return true if $x contains NaN.
I *like* the proposed Perl6 semantics; it's DWIMier. The problem is just the
name collision. Why not
A quarter-baked idea:
How about punting by using nan (all lowercase)
as a boolean logic not-a-number, leaving NaN
for someone to (later) create an IEEE style
tristate not-a-number.
Later:
$foo == NaN; # NaN literal is not same as nan literal
use NaN;
NaN(expr);
Dave observed:
but I still have immense difficulty with the notion that:
$x == NaN
doesn't return true if $x contains NaN.
Anyone with a hardware background should have no difficulty with
this concept.
Yep. You, me, and the (comparative) handful
Tim suggested:
I *like* the proposed Perl6 semantics; it's DWIMier. The problem is
just the name collision. Why not 'inval' (for invalid), or some
such (badval?). This would preserve NaN in its IEEE sense for the
numerical algorithm crew to use.
And thus we circle back towards
Tim suggested:
How about punting by using nan (all lowercase)
as a boolean logic not-a-number, leaving NaN
for someone to (later) create an IEEE style
tristate not-a-number.
Err, I think not. Having CNaN and Cnan that differ so markedly in
behaviour is probably a Recipe For
Damian == Damian Conway [EMAIL PROTECTED] writes:
Damian Sigh. I *do* see your point of view (Laziness), but I still have immense
Damian difficulty with the notion that:
Damian $x == NaN
Damian doesn't return true if $x contains NaN.
Just think of it as a quantum number that hasn't
Semantic confusion alert!
Aroogha! Aroogha! All crew to clarification stations!
EX3 (great document!)
Thank-you.
sez:
print Inflation rate: and $inflation = +
until $inflation != NaN;
This requires that CNaN != NaN
Damian Conway [EMAIL PROTECTED] writes:
His point was that the NaN IEEE came up with is defined to have
NaN != NaN, and that it might be confusing if Perl's behavior
wasn't consistent with that. Not that I think NaN != NaN is a
particularly good idea, but consistency with
Tim wrote:
Err. Are you *sure*? That's an Cuntil, not a Cwhile, you realize?
Yes. I had to use all my fingers and toes to keep everything straight,
but I think I did. :-) In the semantics you show (different from IEEE
semantics) NaN==NaN is true, so NaN!=NaN is false,
RaFaL asked:
So OK, tell me if I get it right, and how (and why) it will look in Perl
6. From Exegesis I see that NaN==NaN, but that's not stated in
Apocalypse (or I just missed it).
No, it's not stated there. But I hope that Perl 6 will follow the lead of
other high level
Let me make it clear: AFAIK Perl NaN's will not be IEEE 754
compliant. That was certainly my intention in suggesting them to
Larry. I share the view of a number of other language designers that
the non-self-identity of IEEE NaN is (to slightly misquote Tim)
ugly,
40 matches
Mail list logo
