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.
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 $a==
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 anyt
> > > 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
> >
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
David Whipp 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 4*2**10, 10*2**30) would
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, i
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
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 tha
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 postfi
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?; :
> 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?
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 Be
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 sufficient
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, 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 th
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 ima
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 th
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
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 c
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
> > uncomfortabl
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
> | (m
>> 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
| 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?
I li
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 i
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 vague as to make me
> uncom
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 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
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 standa
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 r
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 C and C that differ so markedly in
behaviour is probably a Recipe For Disast
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 towa
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 (comparati
Nicholas wrote:
> I had a think about this a few days ago. I can't see how to do fractions
> in Roman Numerals.
Take a look at how Lingua::Romana::Perligata (and, incidentally, the
ancient Romans) did it.
Damianus
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);
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. Wh
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 li
At 08:37 AM 10/9/2001 -0700, Brent Dax wrote:
>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
># > ha
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 somet
At 09:33 AM 10/9/2001 -0500, Jonathan Scott Duff wrote:
>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 "B
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 something.
Neat. It'd be nice to h
At 05:29 AM 10/9/2001 -0500, [EMAIL PROTECTED] wrote:
>Piers Cawley [mailto:[EMAIL PROTECTED]] on 9 October 2001 09:02 wrote:
> > But there are going to be problems in some cases if we change the
> > behaviour of NaN to the perl semantics. There are cases where the IEEE
> > behaviour is *useful* d
> "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 t
On Tue, Oct 09, 2001 at 04:39:47PM +1000, 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 agree. The difficulty I have is that it is the compari
Piers Cawley [mailto:[EMAIL PROTECTED]] on 9 October 2001 09:02 wrote:
> But there are going to be problems in some cases if we change the
> behaviour of NaN to the perl semantics. There are cases where the IEEE
> behaviour is *useful* dammit.
Indeed, we certainly don't want sqrt(-1) == sqrt(-2)
Damian Conway <[EMAIL PROTECTED]> writes:
>
>> 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
>
>> itse
> 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 that the two compared
Dan Sugalski wrote:
> At 09:07 AM 10/8/2001 +1000, Damian Conway wrote:
> >I see your (and others') point here, but I view NaN as a *marker* indicating
> >a non-numeric result. Markers should always compare equal to themselves.
> >(Frankly, *everything* should compare equal to itself -- which is
At 09:07 AM 10/8/2001 +1000, Damian Conway wrote:
>I see your (and others') point here, but I view NaN as a *marker* indicating
>a non-numeric result. Markers should always compare equal to themselves.
>(Frankly, *everything* should compare equal to itself -- which is where
>IEEE 754 goes horribly
Damian Conway wrote:
> 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 th
> > 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)
> > "ug
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 langu
Tim wrote:
> > Err. Are you *sure*? That's an C, not a C, 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, whic
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 consist
> 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 other languages may be. If NaN != NaN, th
John Siracusa wrote:
> On 10/7/01 4:19 PM, RaFaL Pocztarski wrote:
> > I was very surprised when I saw the negative feedback on Slashdot
>
> Heh, did you just discover Slashdot recently? ;)
Well, maybe I was so excited about everything I read about Perl 6 that I
thought everyone will share my en
On 10/7/01 4:19 PM, RaFaL Pocztarski wrote:
> I was very surprised when I saw the negative feedback on Slashdot
Heh, did you just discover Slashdot recently? ;)
-John
Tim Conrow wrote:
> Damian Conway said:
>> > > print "Inflation rate: " and $inflation = +<>
>> > > until $inflation != NaN;
>> >
>> > This requires that C be false, causing the loop to
>> > continue until a valid numeric string is entered.
>
Damian Conway said:
> > > print "Inflation rate: " and $inflation = +<>
> > > until $inflation != NaN;
> >
> > This requires that C be false, causing the loop to
continue
> > until a valid numeric string is entered.
> Err. Are you *sure*? That's a
Damian Conway:
#> The example can be rewritten
#>
#>print "Inflation rate: " and $inflation = +<>
#> while $inflation != $inflation;
#
# Err. No it can't.
His point was that the NaN IEEE came up with is defined to have NaN !=
NaN, and that it m
> 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
61 matches
Mail list logo
