BabyPerl 0.02
Okay, I've finished version 0.02 of babyperl. In addition to constants,
variables, operators, and functions, it now understands comments (in a
rudimentary way--watch out if a constant string contains #), if,
if/else, unless, unless/else, while, and do/while. I relented and put
in _ for concat. It also understands parenthesis-less function calls.
It has new and improved error messages, and a -v command with version
information. It also has improved internals, with a much more flexible
function table.
As before, it takes the name of the file you want to compile as its
input parameter and spits out assembly on STDOUT. All error messages
leave via STDERR; the debugging messages from babyperl 0.01 are now
turned off and can be reactivated by changing the 'use constant' line in
the source.
Most parser errors are of the form "Error (L###C###): ". The
first series of numbers is the line number, while the second series of
numbers is the (approximate) column number. For example, if you
commented out the curly brace on line 20 of the test file, you would get
the following message:
Error (L20C1): An if or unless statement was started, but was
incomplete
Followed by the catch-all:
Cannot continue after parsing errors
I've pasted a program below that shows much of what it can handle.
babyperl.pl is attached to this e-mail. It's over 600 lines, and very
messy. I will likely rewrite the whole thing Real Soon Now to make it
cleaner and more powerful.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
our int($one);
our int($two);
$one=1;
$two=2;
#This is a comment.
if($one) {
unless($two) {
print("The universe is"_"sane!\n");
}
else {
print "The universe isn't sane!\n";
}
}
else {
print("The universe isn't sane!\n");
}
if($one) {
print("The universe is still sane!\n");
unless($two) {
print("No it isn't!\n");
}
}
our int($i);
$i=10;
while($i) {
print("Looping...\n");
$i=$i-1;
}
$i=10;
do {
print("Looping again...\n");
$i=$i-1;
} while($i);
babyperl.pl
Description: Binary data
Re: HOF positional args (was Re: reduce via ^)
> > @a ^+= reduce {$^a+$^b} @b;
>
> What's this? Are positional args to HOFs now alphabetic rather than
> numeric?
No. I just chose to used named placeholders, since they're more easily
followed in this example.
> cf. http://dev.perl.org/rfc/23.html#Positional_placeholders
cf. http://dev.perl.org/rfc/23.html#Combining_placeholder_types
Damian
HOF positional args (was Re: reduce via ^)
Damian Conway wrote:
> @a ^+= reduce {$^a+$^b} @b;
What's this? Are positional args to HOFs now alphabetic rather than numeric?
cf. http://dev.perl.org/rfc/23.html#Positional_placeholders
Re: reduce via ^
> So, does that mean: > > $a = ($a) ^+ @b; > print $a; # prints: 3 > # $a = ($a,undef,undef) ^+ @b ... Yes. > My new confusion has to do with why does the hyperoperator expand $a to > ($a,$a,$a), but (1) to (1,undef,undef)? Oh, it's because hyper-ops > expand an arg if it is short on *dimensions* and not *elements*. Bingo. > (1) gets expanded to (1,undef,undef) by auto-vivification of list > elements, and not by action of the hyper-op, correct? Yes. Damian
Re: reduce via ^
According to Damian: > > Colin exemplifies: > >> $a = 1; >> @a = (1); >> @b = (1, 2, 3); >> @c = (4, 5, 6); >> >> $a = $a ^+ @b; >> @a = @a ^+ @b; >> >> print $a; # 7 > > No. It will (probably) print: 4. Because: > > >> print @a; # 7 or 2? > > Prints: 2 2 3. Because: >$a = ($a,$a,$a) ^+ @b; >$a = (1,1,1) ^+ (1,2,3); >$a = (2,3,4); >$a = 4; and > > print @a; >@a = @a ^+ @b; >@a = (1,undef,undef) ^+ (1,2,3);# or (1,0,0) ^+ (1,2,3) >@a = (2,2,3); prints 2 2 3 So, does that mean: $a = ($a) ^+ @b; print $a; # prints: 3 # $a = ($a,undef,undef) ^+ @b ... My new confusion has to do with why does the hyperoperator expand $a to ($a,$a,$a), but (1) to (1,undef,undef)? Oh, it's because hyper-ops expand an arg if it is short on *dimensions* and not *elements*. (1) gets expanded to (1,undef,undef) by auto-vivification of list elements, and not by action of the hyper-op, correct? Trying to get the hang of parallelisms, -C.
Re: reduce via ^
Colin exemplifies: > $a = 1; > @a = (1); > @b = (1, 2, 3); > @c = (4, 5, 6); > > $a = $a ^+ @b; > @a = @a ^+ @b; > > print $a; # 7 No. It will (probably) print: 4. Because: $a = $a ^+ @b; becomes: $a = ($a,$a,$a) ^+ @b; which is: $a = (1,1,1) ^+ (1,2,3); becomes: $a = (2,3,4); which is: $a = 4; > print @a; # 7 or 2? Prints: 2 2 3. Because: @a = @a ^+ @b; becomes: @a = (1,undef,undef) ^+ (1,2,3);# or (1,0,0) ^+ (1,2,3) which is: @a = (2,2,3); Damian
Re: reduce via ^
Aaron asked:
> I'm wondering about some other operators Will there be a ^?? operator?
I believe that there will be a hyperoperator for *every* operator.
> I might, for example, say:
>
>@a = @b ^?? 'yea' :: 'nay';
>
> Which I would expect to be the same as:
>
>@a = map {$_ ?? 'yea' :: 'nay'} @b;
Yes.
> Will unary operators have hyper-equivalents, as well? Will,
>
>@a = ^-@b;
>
> work?
Yes.
Damian.
Re: reduce via ^
> >> $a ^+= @list; # should sum the elements of @list
>
> Does this mean that
>
> @a ^+= @b;
>
> will add every value of @b to every value of @a?
No. The rule is that a hyperoperator replicates its lower-dimensional
operand up to the same number of dimensions as its higher-dimensional
operand, then applies the hyped operator element-by-element across the
two operands.
Since @a and @b are (presumably) of the same dimensionality:
@a ^+= @b;
means:
@a[0] += @b[0]
@a[1] += @b[2]
@a[2] += @b[2]
# etc.
To add every value of @b to every value of @a, you'll need either:
@a ^+= reduce {$^a+$^b} @b;
or:
@a = @(any(@a) + any(@y));
(depending on your definition of "every").
Damian
Re: reduce via ^
On Wed, Oct 10, 2001 at 03:41:18PM -0700, Colin Meyer wrote: > > Maybe this illustrates my confusion: > > $a = 1; > @a = (1); > @b = (1, 2, 3); > @c = (4, 5, 6); > > $a = $a ^+ @b; > @a = @a ^+ @b; > > print $a; # 7 > print @a; # 7 or 2? Or, after re-reading the apocolypse again, it seems: print @a; # 234 ? > > -C.
Re: reduce via ^
On Wed, Oct 10, 2001 at 04:34:14PM -0500, Jonathan Scott Duff wrote:
> On Wed, Oct 10, 2001 at 02:23:33PM -0700, Colin Meyer wrote:
> [ @a ^+= @b ]
> > What I'd expect is more like:
> >
> > foreach my $elem (@a) {
> > $elem ^+= @b;
> > }
>
> Hrm. Why would you expect that when you'd have written as you just
> did? Would you also expect
>
> @a = @b ^+ @c;
>
> to mean
>
> @a = (); for (@b) { push @a, $_ ^+ @c; }
Maybe this illustrates my confusion:
$a = 1;
@a = (1);
@b = (1, 2, 3);
@c = (4, 5, 6);
$a = $a ^+ @b;
@a = @a ^+ @b;
print $a; # 7
print @a; # 7 or 2?
-C.
Re: reduce via ^
On Wed, 10 Oct 2001 14:23:33 -0700, Colin Meyer wrote:
>> > Does this mean that
>> >
>> > @a ^+= @b;
>> >
>> > will add every value of @b to every value of @a?
>What I'd expect is more like:
>
> foreach my $elem (@a) {
> $elem ^+= @b;
> }
>
If you want that effect, apply "scalar" on the RHS.
--
Bart.
Re: reduce via ^
On Wed, Oct 10, 2001 at 02:23:33PM -0700, Colin Meyer wrote:
[ @a ^+= @b ]
> What I'd expect is more like:
>
> foreach my $elem (@a) {
> $elem ^+= @b;
> }
Hrm. Why would you expect that when you'd have written as you just
did? Would you also expect
@a = @b ^+ @c;
to mean
@a = (); for (@b) { push @a, $_ ^+ @c; }
?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: reduce via ^
On Wed, Oct 10, 2001 at 01:27:35PM -0700, Colin Meyer wrote:
> On Wed, Oct 10, 2001 at 09:42:58PM +1000, Damian Conway wrote:
> >
> > John observed:
> >
> >> I just read Apocalypse and Exegesis 3, and something stuck out at me
> >> because of its omission, namely using hyper operators for reduction.
> >>
> >> $a ^+= @list; # should sum the elements of @list
>
> Does this mean that
>
> @a ^+= @b;
>
> will add every value of @b to every value of @a?
Yes, that's correct.
Thinking about this, I'm realizing that there's something missing
in map I was trying to think of how this mapped to map's syntax,
and the problem is indexes. It would be very nice if there were some
temporary variable that could be accessed from map that contained
the index.
This is what I mean:
@a = map {$_ + $b[$map_index]} @a;
which is almost the same thing as the previous statement, except for the
behavior on a short @a.
I'm wondering about some other operators Will there be a ^?? operator?
I might, for example, say:
@a = @b ^?? 'yea' :: 'nay';
Which I would expect to be the same as:
@a = map {$_ ?? 'yea' :: 'nay'} @b;
Will unary operators have hyper-equivalents, as well? Will,
@a = ^-@b;
work?
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
"Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew." -Queen/_'39_
Re: reduce via ^
On Wed, Oct 10, 2001 at 04:04:18PM -0500, Jonathan Scott Duff wrote:
> On Wed, Oct 10, 2001 at 01:27:35PM -0700, Colin Meyer wrote:
> >
> > Does this mean that
> >
> > @a ^+= @b;
> >
> > will add every value of @b to every value of @a?
>
> That's what I'd expect it to do. Well ... that's assuming you really
> mean "each" where you said "every". i.e.,
>
> my $i = 0;
> while ($i < length(@a) && $i < length(@b)) {
>@a[$i] += @b[$i];
$i++;
> }
What I'd expect is more like:
foreach my $elem (@a) {
$elem ^+= @b;
}
Have fun,
-C.
Re: reduce via ^
On Wed, Oct 10, 2001 at 01:27:35PM -0700, Colin Meyer wrote:
> On Wed, Oct 10, 2001 at 09:42:58PM +1000, Damian Conway wrote:
> >
> > John observed:
> >
> >> I just read Apocalypse and Exegesis 3, and something stuck out at me
> >> because of its omission, namely using hyper operators for reduction.
> >>
> >> $a ^+= @list; # should sum the elements of @list
>
> Does this mean that
>
> @a ^+= @b;
>
> will add every value of @b to every value of @a?
That's what I'd expect it to do. Well ... that's assuming you really
mean "each" where you said "every". i.e.,
my $i = 0;
while ($i < length(@a) && $i < length(@b)) {
@a[$i] += @b[$i];
}
Just like I'd expect
@a = @b ^=~ @patterns;
to be roughly equivalent to:
my $i = 0; @a = ();
while ($i < length(@patterns) && $i < length(@b)) {
push @a, (@b[$i] =~ @patterns[$i]);
$i++;
}
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: More on operators
HellyerP <[EMAIL PROTECTED]> writes: > > :Alberto Manuel Brandao Simoes <[EMAIL PROTECTED]> writes: > > : > > :> If we are in the mood of changing operators, && can be /\ > > :> and || can be \/. At least, mathematicians will like it! > > : > > :You are, of course, joking. > > > Given Damian's sigma operator in E3, there is no need to resort to > the ascii approximations... Especially when *both* the characters used to make up these 'composite' operators have special meanings. Quite how you'd distinguish between /\ and the start of a pattern match is left as an exercise for the suitably insane reader. -- Piers
Re: reduce via ^
On Wed, Oct 10, 2001 at 09:42:58PM +1000, Damian Conway wrote: > > John observed: > >> I just read Apocalypse and Exegesis 3, and something stuck out at me >> because of its omission, namely using hyper operators for reduction. >> >> $a ^+= @list; # should sum the elements of @list Does this mean that @a ^+= @b; will add every value of @b to every value of @a? -C. > > Well, I suspect Larry didn't mention it because he didn't want to scare > people *too* much. I didn't mention it for a much simpler reason: > because, in the heat of trying to weld together a concise example to > explain of everything Larry had designed, this neat corollary of ^ > simply didn't occur to me. ;-) > > Damian
RE: NaN semantics
> > > 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 unless of course we use nano prefix (postfix?), then it would be > 0.00123i of course. ;) In which case "123foo" is 123e-15 (femto). If we are going to have all these postfixes, then we would probably want invalid ones to evaluate to NaN instead of truncating them. We can always have a standard fn/method that strips the invalid characters off the end if the string: my $string = "1.23Ki4b2XXX". my $a = +string; # NaN my $b = +$string.numeric_prefix; # 1230 + 16i my $c = +$string.real_prefix;# 1230 my $d = +$string.integer_prefix; # 1 or some such thing. Dave.
Re: NaN semantics
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 prefixes. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
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 be very nice. What do you think? > > > > - RaFaL Pocztarski, [EMAIL PROTECTED] > > First this thread tells me that "123foo" will be 123 in numeric > context. Now I find myself wondering what "123indigo" evaluates > to! I have a strange felling that I should just shut up, as my ideas only cause a lot of chaos... :) - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
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 > evaluate to 123i. At least that's the position I'm taking at the > moment ;-) 123i unless of course we use nano prefix (postfix?), then it would be 0.00123i of course. ;) - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
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 > metric suffix follow that, if both exist. You're right, I was assuming that the imaginary i must be in the very end of literal, and was even thinking about using j instead. :) OK, that seems to be the nicest solution. So we have: 5Gmeans 5 * 10**9, 5 giga 5Gi means 5 * 2**30, 5 gibi 5iG means 5 * 10**9 * i, 5i giga 5iGi means 5 * 2**30 * i, 5i gibi (I really like those binary prefixes names!) Very nice, unambiguous, compatible with SI standard, no need for any pragmas, I'm really impressed! - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
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 position I'm taking at the moment ;-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: prefix-postfix [was Re: NaN semantics]
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 prec(\&operator:-($)) ($num) {
return $num * 1000;
}
but yeah, that's the idea. And it would live in a module so that
users would have to do
use BinaryMetric; # or some such
to get it.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
prefix-postfix [was Re: NaN semantics]
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?; :")
my sub operator:var is postfix:(?) ($var) {
$num > 10 ?? 1 :: 0;
}
my sub operator:sub is prefix:(U) () {
uc @params
}
very oversimplified of course... It become funny :") isn't it...
=
iVAN
[EMAIL PROTECTED]
=
| 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 4*2**10, 10*2**30) would be very nice. What do you think?
| >
| > I like the idea ... this is one of the ways to suspend the calculations
to
| > the last moment...
| > But one probelm comes to my mind, what the k,G etc mean
| > 1000 or 1024
| > or k => 1000, K => 1024
| >
| > Or probably the best way will be to have a hook so that we can specify
what
| > is a Number and how it has to be calculated down to the real
number...!!!
|
| How about we let users define their own postfix operators such that
| they can make 10K, 10M, 10G mean whatever they want. Perhaps this is
| also where the postfix "?" and "!" from Ruby can come in.
|
| I'd still advocate supporting imaginary numbers in core somehow
| though. With a pragma would be best I think so that exceptions are
| thrown on sqrt(-1) unless they really want imaginaries.
RE: More on operators
> :Alberto Manuel Brandao Simoes <[EMAIL PROTECTED]> writes:
> :
> :>If we are in the mood of changing operators, && can be /\
> :> and || can be \/. At least, mathematicians will like it!
> :
> :You are, of course, joking.
> :
> :--
> :Piers
>
Given Damian's sigma operator in E3, there is no need to resort to
the ascii approximations...
Philip
Disclaimer
This communication together with any attachments transmitted with it ('this E-mail')
is intended only for the use of the addressee and may contain information which is
privileged and confidential. If the reader of this E-mail is not the intended
recipient or the employee or agent responsible for delivering it to the intended
recipient you are notified that any use of this E-mail is prohibited. Addressees
should check this E-mail for viruses. The Carphone Warehouse Group PLC makes no
representations as regards the absence of viruses in this E-mail. If you have received
this E-mail in error please notify our ISe Response Team immediately by telephone on +
44 (0)20 8896 5828 or via E-mail at [EMAIL PROTECTED] Please then immediately
destroy this E-mail and any copies of it.
Please feel free to visit our website: http://www.phonehouse.com
RE: NaN semantics
> 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? > > - RaFaL Pocztarski, [EMAIL PROTECTED] First this thread tells me that "123foo" will be 123 in numeric context. Now I find myself wondering what "123indigo" evaluates to! Dave.
Re: NaN semantics
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 really 60e9 bytes, and the 1K ohm > >resistors that are really 1000 ohms. (Well, give or take a bit for ambient > >temperature...) > >You optimist! The precision of such resistors is often no better than 5 >or 10%. That is more than 24 ohm. Hey, I never said *which* bit. Bit 5 would be about the right one. :-P Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: NaN semantics
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 vague as to make me > uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good case > for both, and that's never a good sign. I must say I'd like it too, and I don't care which one you choose, this would mostly be used by sysadmins to sort the output of du and the likes, so it really doesn't matter. Michel Rodriguez Perl & XML http://www.xmltwig.com
Re: NaN semantics
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; $M = $K * 1000; $G = $M * 1000; print "These files are $(20 * $k) each\n"; print "The disk has $(2 * $M) left of $(80 * $G)!\n"; It seems to me that these things should be in a module rather than as pragmas. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: NaN semantics
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 1000 ohms. (Well, give or take a bit for ambient >temperature...) You optimist! The precision of such resistors is often no better than 5 or 10%. That is more than 24 ohm. But anyway... I hope a kg is still 1000 grams, not 1024 grams? -- Bart.
Re: NaN semantics
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 imaginary numbers, but there actually is no ambiguity if the imaginary i must immediately follow the number, and the metric suffix follow that, if both exist. -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: NaN semantics
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 that, make sure it has to be enabled with a pragma. Having > >complex numbers showing up in the middle of bad code is a scary concept :) > > Yeah, but is the code actually *wrong* if it does a sqrt(-1)? (I know, > don't go there... :) I strongly recommend that if NaN exist, that it have IEEE semantics. I personally think the subset of people that understand NaN is larger than a few handfuls. And it has beneficial utility, so I recommend having it. And Apo2, regarding Infinities and NaNs (RFC 038) says: > This is likely to slow down numeric processing in some locations. Perhaps it could >be turned off when desirable. We need to be > careful not to invent something that is guaranteed to run slower than IEEE floating >point. We should also try to avoid defining a > type system that makes translation of numeric types to Java or C# types problematic. > > That being said, standard semantics are a good thing, and should be the default >behavior. > Note that just because NaN == NaN never produces a true value (numerical inequality), that that doesn't prevent other matching operators from considering NaN and NaN equivilant. Switch, for example, could have an option for choosing NaN as one case, and executing that case when the input datum is NaN. > > > 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 that's never a good sign. > > > >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 1000 ohms. (Well, give or take a bit for ambient > temperature...) The reminder of the "e" (scientific notation) syntax reminds me that the whole issue is really one of choosing a syntax to be unambiguous with regards to its semantics. Of course the metric system defines quite a few prefixes (http://physics.nist.gov/cuu/Units/prefixes.html), all of which would be handy to practitioners in various sciences. Micro would, of course, require Unicode support. We could probably omit "hecto", "deka", "deci" and maybe "centi" prefixes, due to infrequent usage. Note that the prefixes are _case sensitive_ and that 1000 is represented by "k", not "K"!!! (although it isn't one of the case ambiguous ones, so perhaps we could include the common "K" as well). So since the metric system truly is based on base 10, it seems only reasonable that that standard be conformed to, so I propose allowing the Symbols from the above web page as numerical suffixes with the definitions found therein. However, for convenience in programming with powers of 2, I propose allowing a further suffix of "2" to mean the 1024 instead of 1000 for each of the symbols that are powers of 1000. So we would have: 1k == 1000 1k2 == 1024 1M == 100 1M2 == 1048576 ... 1m == 1e-3 1m2 == (1/1k2) 1µ == 1e-6 1µ2 == (1/1M2) ... Perhaps we only need to support the positive powers with the binary suffix, as the computer industry hasn't dealt much in fractions of bytes :) Other syntax variations may be more acceptable than the suffix "2"--maybe a suffix "b" (for binary) resulting in 1024 == 1kb -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: NaN semantics
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 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. I would prefer to use k1024 by default (with warning. and maybe with use strict the default would not be allowed, i.e. user have to choose one to use it. but I would like the default 1024 to work with one-liners) - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
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 good case > > for both, and that's never a good sign. > > There's always the possibility of supporting SI's binary prefixes ;) I thought about it but it wouldn't work with imaginary numbers. :) - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
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 supporting them. Is 1K 1024 or 1000? I can make a good case > > for both, and that's never a good sign. > > There's always the possibility of supporting SI's binary prefixes ;) > > http://physics.nist.gov/cuu/Units/binary.html I'm not really fond of 1K meaning anything, but if it's deemed appropos, I vote for the binary meaning. Question on the NIST definitions though: What does 1eie1i mean? I *think* that that's 2^60 times ten to the 1i... correct? Do we have precidence in mind, here? Can I say 1iei? Does anyone *do* that? -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF "Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew." -Queen/_'39_
Re: NaN semantics
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 4*2**10, 10*2**30) would be very nice. What do you think? > > I like the idea ... this is one of the ways to suspend the calculations to > the last moment... > But one probelm comes to my mind, what the k,G etc mean > 1000 or 1024 > or k => 1000, K => 1024 > > Or probably the best way will be to have a hook so that we can specify what > is a Number and how it has to be calculated down to the real number...!!! How about we let users define their own postfix operators such that they can make 10K, 10M, 10G mean whatever they want. Perhaps this is also where the postfix "?" and "!" from Ruby can come in. I'd still advocate supporting imaginary numbers in core somehow though. With a pragma would be best I think so that exceptions are thrown on sqrt(-1) unless they really want imaginaries. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: NaN semantics
>> 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 that's never a good sign. There's always the possibility of supporting SI's binary prefixes ;) http://physics.nist.gov/cuu/Units/binary.html -- Trond Michelsen
Re: More on operators
On Wed, Oct 10, 2001 at 05:20:06PM +0100, Piers Cawley wrote: ( Alberto Manuel Brandao Simoes <[EMAIL PROTECTED]> writes: ( ( > If we are in the mood of changing operators, && can be /\ ( > and || can be \/. At least, mathematicians will like it! ( ( You are, of course, joking. No... I'm not joking. Of course changing && and || is not such a good idea because C programmers will kill us. On the other hand, these two operators can be usefull for something else... and, if they are used, I hope they mean 'and' and 'or' :) Alberto -- | Alberto Manuel Brandão Simões | | [EMAIL PROTECTED] | | http://numexp.sourceforge.net |
Re: NaN semantics
| 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 like the idea ... this is one of the ways to suspend the calculations to the last moment... But one probelm comes to my mind, what the k,G etc mean 1000 or 1024 or k => 1000, K => 1024 Or probably the best way will be to have a hook so that we can specify what is a Number and how it has to be calculated down to the real number...!!! = iVAN [EMAIL PROTECTED] =
Re: More on operators
Alberto Manuel Brandao Simoes <[EMAIL PROTECTED]> writes: > If we are in the mood of changing operators, && can be /\ > and || can be \/. At least, mathematicians will like it! You are, of course, joking. -- Piers
Re: NaN semantics
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 enabled with a pragma. Having >complex numbers showing up in the middle of bad code is a scary concept :) Yeah, but is the code actually *wrong* if it does a sqrt(-1)? (I know, don't go there... :) > > 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 that's never a good sign. > >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 1000 ohms. (Well, give or take a bit for ambient temperature...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: NaN semantics
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 > uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good case > for both, and that's never a good sign. I was thinking about powers of 1024, as powers of 1000 are of course easy to write in decimal system (4e9, 4_000_000_000, but 4_294_967_296 and 4*2**30). - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
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 showing up in the middle of bad code is a scary concept :) > 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 that's never a good sign. If people want base 10, let them use "e" syntax. 1e3 = 1000 1k = 1024 Sam.
More on operators
If we are in the mood of changing operators, && can be /\ and || can be \/. At least, mathematicians will like it! Cheers Albie -- | Alberto Manuel Brandão Simões | | [EMAIL PROTECTED] | | http://numexp.sourceforge.net |
Re: NaN semantics
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 different route. > >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. If we do them, yep. Currently no promises there. >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 that's never a good sign. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: NaN semantics
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 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? - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
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 that the two compared >> values are numerically equal. >> >> Then again, if you tell me that == operator doesn't mean "numerically >> equal", I will agree that NaN==NaN should be true even considering that >> 'cat'=='dog' will also be true. > > But 'cat'=='dog' *is* true. Numerically, they *are* equal. > They are equally not numbers. One should certainly get a warning > (and one will if warnings are enabled), but this > expression shouldn't return false. OK, now I see your point even better. The difference in our points is that I suggested that numerical comparison of NaNs shouldn't make sense. But yes, two NaNs are equally not numbers. Now the question is if being a NaN should be the special case of numerical meaning or the lack of any numerical meaning. I don't think that the one idea is more correct than another, maybe that's the matter of taste, however they are mutually exclusive, so one of them has to be chosen. I joined this thread, because I thought that assuming that NaN!=NaN idea is just ugly and thus not worth deeper discussion, was oversimplifying and the problem deserves a little more of controversy. However I wasn't suspecting that NaN semantics will grow to one of the most important threads here. > 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. Well, Laziness is very important to me, but here it won't be hurt much, as in fact $x==$y!=NaN wouldn't be used very often. Only when numerically comparing two unknown values, and I can't remember when I did it last time. Maybe when sorting but with sorting it doesn't matter if every NaN is equal or not. Hmmm, maybe NaN==NaN would make starship operator simpler..? Anyway, even with NaN==NaN 'text'!=0, unlike Perl 5, where 'text'==0, which could've been the main problem with == operator. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: EX3: Adverbs and print()
On 10/10/01 7:27 AM, Piers Cawley wrote:
> Bart Lateur <[EMAIL PROTECTED]> writes:
>> On Sat, 06 Oct 2001 22:20:49 -0400, John Siracusa wrote:
>>
>>> So, in the
operator, the filter is the adverb:
>>>
>>>$sum =
@costs : {$^_ < 1000};
>>
>> WTF is that operator? All I see is a black block. We're not in ASCII any
>> more, Toto...
>
> I'm guessing Sigma.
Yeah, that's what it was supposed to be. Maybe the parser should understand
ASCII art... ;)
---
\
/
---
(I'm sure Damian will make a module for it eventually... :)
-John
continuation .... ?
hi,
Any idea what the "continuation" will be ? Something similar like
while(){..}continue{..} construct, but more primitive/lower-level ?
{ my $val = 10 } -=> { print $val; $val = 11 } -=> { print $val }
prints 10 and 11 i.e. lexicals of BLOCK1 are preserved for BLOCK2 and BLOCK3
i.e until continuation ends..
{ my $val = 10 } -=> { print $val; somesub(); $val = 11 } -=> { print
$val }
somesub() still have access to $val .
Or it will do other things too, not only extending the lexical scope...
Just thoughts !!!
=
iVAN
[EMAIL PROTECTED]
=
Re: EX3: $a == $b != NaN
Bart asked: > So to what does "123foo" evaluate in numeric context? Now, it produces > 123. Which is probably useful... Yes. And I would expect that it will continue to do so. Perl is primarily about convenience, not consistency ;-) Damian
Re: reduce via ^
John observed: > I just read Apocalypse and Exegesis 3, and something stuck out at me > because of its omission, namely using hyper operators for reduction. > > $a ^+= @list; # should sum the elements of @list > > Larry says @a ^+ 1 will replicate the scalar value for all a's, and > Damian talks about doing summation with the reduce function without > mentioning this compact syntax. > > So am I overlooking some obvious reason why this won't work? No. I expect that this would indeed work. Note that it's not really a replacement for C since it *requires* the lvalue in order to work. But it is a nice idiom. Why didn't we mention it in A3/E3. Well, I suspect Larry didn't mention it because he didn't want to scare people *too* much. I didn't mention it for a much simpler reason: because, in the heat of trying to weld together a concise example to explain of everything Larry had designed, this neat corollary of ^ simply didn't occur to me. ;-) Damian
Re: EX3: Adverbs and print()
Bart Lateur <[EMAIL PROTECTED]> writes:
> On Sat, 06 Oct 2001 22:20:49 -0400, John Siracusa wrote:
>
> >So, in the
operator, the filter is the adverb:
> >
> >$sum =
@costs : {$^_ < 1000};
>
> WTF is that operator? All I see is a black block. We're not in ASCII any
> more, Toto...
I'm guessing Sigma.
Re: EX3: Adverbs and print()
On Sat, 06 Oct 2001 22:20:49 -0400, John Siracusa wrote:
>So, in the
operator, the filter is the adverb:
>
>$sum =
@costs : {$^_ < 1000};
WTF is that operator? All I see is a black block. We're not in ASCII any
more, Toto...
--
Bart.
Re: EX3: $a == $b != NaN
On Sun, 7 Oct 2001 12:27:17 +1000 (EST), Damian Conway wrote: >The step you're missing is that the non-numeric string "hello", >when evaluated in a numeric context, produces NaN. So: > > "hello" == 0 && 0 != NaN > >is: > > Nan == 0 && 0 != NaN > >which is false. So to what does "123foo" evaluate in numeric context? Now, it produces 123. Which is probably useful... if "123foo" produces Nan, which wouldn't really surprise me too much, we'll need additional tools to extract the number from a string. We can do it with a regex, but for the general case, it becomes a nasty beast of a regex, and I don't want to rewrite it from scratch every time I need it.A job for Regexp::Common? -- Bart.
Re: hyperoperators (was: Apocalypse)
Alberto Simoes wrote: :2) using ^ for mapping operators.. this only works with two lists. :The problem here is that we have a pair of lists, and want a :list of pairs. There can be other situations where we have :three lists, instead of a list of tripplets... I thought it was :better to have a 'evidence' or 'factorize' for lists in a way :((a,b,c),(1,2,3)) will become ((a,1),(b,2),(c,3)) and :((1,2,3),(4,5,6),(7,8,9)) will become ((1,4,7),(2,5,8),(3,6,9)). :This way, the ^ operator could be replaced with a simple map... :More generic, less operators confusion... better? maybe... I'm hoping we'll get the facility to add user-defined hyperoperators, in which case it will be easy to add other list-manipulation strategies in a generic manner. With a bit of luck, the commonest such hyperoperators will get to be in a standard class that everyone uses, rather than everyone going off to invent their own symbols. Hugo
reduce via ^
I just read Apocalypse and Exegesis 3, and something stuck out at me because of its omission, namely using hyper operators for reduction. $a ^+= @list; # should sum the elements of @list Larry says @a ^+ 1 will replicate the scalar value for all a's, and Damian talks about doing summation with the reduce function without mentioning this compact syntax. So am I overlooking some obvious reason why this won't work? ~ John Williams
RE: dor (was RE: General Feelings on Apoc 3 )
> Bart Lateur: > # On Thu, 4 Oct 2001 03:22:55 -0400, Michael G Schwern wrote: > # > # >Binary // > # > > # >The analogy to || is probably a bit too clever. My first reaction > # >was it's some sort of weird division operator. But it's > servicable. > # > # I think it's very cute. I think of it as a "skewed or", > which is, er, > # both what it both is, and what it looks like. > > If we have 'and', 'or' and 'xor', can we have 'dor' (defined > or) to be a low-precedence version of this? Should this be pronounced "duh" ? :-) R.
Re: General Feelings on Apoc 3
On Wed, 10 Oct 2001 15:42:29 +1000 (EST), Damian Conway wrote: >Brent asked: > > > If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a > > low-precedence version of this? > >I actually suggested exactly that to Larry a few weeks back. > >He likes the idea, but is having trouble finding an acceptable name for the >operator. I'm not convinced it's that useful... The precedence of "dor" would be lower than that of assignment. And it's precisely in assignment where the "//" operator will come in very handy. If you don't need to assign the value of the expression, you can just as wel use defined(): defined($x = foo()) or die "Got an undefined value!"; Plus there's the matter of the name... Do we really need low and high precedence equivalents of every boolean operator? Next, you'll want a low precedence "?:" (or "??::"). We have one already: if/else, but except in do blocks, you can't really use them for expressions. -- Bart.
