Re: Math functions? (Particularly transcendental ones)
Uri Guttman wrote: > > "BS" == Benjamin Stuhl <[EMAIL PROTECTED]> writes: > > >> Can anyone think of things I've forgotten? It's been a while since > >> I've done numeric work. > > BS> ln, asinh, acosh, atanh2? > > dan mentioned log (base anything) but i don't recall ln. and definitely > the arc hyberbolics are in after i pointed them out. dunno about atanh2. > We only really need ln(). Then [log(y) base x] is simply [ln(y)/ln(x)]. There's no need to have separate functions for different bases.
Re: Math functions? (Particularly transcendental ones)
On Sun, Sep 09, 2001 at 02:33:17PM +1000, Jeremy Howard wrote: > Uri Guttman wrote: > > > "BS" == Benjamin Stuhl <[EMAIL PROTECTED]> writes: > > > > >> Can anyone think of things I've forgotten? It's been a while since > > >> I've done numeric work. > > > > BS> ln, asinh, acosh, atanh2? > > > > dan mentioned log (base anything) but i don't recall ln. and definitely > > the arc hyberbolics are in after i pointed them out. dunno about atanh2. > > > We only really need ln(). Then [log(y) base x] is simply [ln(y)/ln(x)]. > There's no need to have separate functions for different bases. If we try to get away with just implementing ln(), we'll probably waste more time, space and effort answering FAQs about "How do I do log base X in Perl?" than we ever would just implementing log(y, base_x). Do ln(y) and log(y, base_x) and you pretty much cover everything. Besides, we have to have at least log(y) for backwards compatibility--and I don't think "because it's mathematically redundant" is a valid reason to bust compatibility for a tiny little function like log(). -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One The desired effect is what you get when you improve your interplanetary funksmanship.
Re: Math functions? (Particularly transcendental ones)
At 09:51 PM 9/8/2001 -0700, Dave Storrs wrote:
>On Sat, 8 Sep 2001, Uri Guttman wrote:
>
> > > "BW" == Brian Wheeler <[EMAIL PROTECTED]> writes:
> > BW> =item eqv tx, ty, tz *
> >
> > BW> Bitwise Equivalence all bits in y with z and store the result in
> > BW> register x.
> >
> > that is just !(y xor z). we can provide the op but perl as we know it
> > has no operator that will map to it. maybe another front end would want
> > it so let's have it. it is trivial to code up and won't take any space.
>
>
> I feel very uncomfortable about speaking up in opposition to a
>much more experienced person, but I'd like to register a vote against this
>idea.
I'm glad you did. I really don't want people to stifle dissent just because
of an air of authority and/or experience that might be perceived around
someone.
>The whole reason that we're building Perl6 in the first place is
>because there is a lot of nasty cruft in Perl5.
True, but the cruft isn't actually in the list of opcodes itself in perl 5.
Rather it's inside the functions for those opcodes. (Amongst other places)
A large list of opcodes isn't itself a big problem if they're organized in
a way that makes them straightforward to deal with. (Having a couple dozen
fancy math opcodes isn't a problem here--they can be lumped together
conceptually as "That big lump of opcodes from 150-187" if you don't need
to deal with 'em)
>We are working towards
>creating something clean and elegant; let's not start out by putting
>things in just because they are "trivial to code" when we don't have a use
>for them.
Well, we do have a use for them. The math folks are one of our new target
audiences, and I'd really like to roll as much of what PDL does as feasable
into the core. Also there's the possibility (albeit remote) that perl will
at some point handle deferred evaluation of expressions, in which case
having these handy (more to the point making perl aware of them) will make
reducing the expressions correctly later easier.
FWIW, clean and elegant is somewhere under "fast" on the big list 'o goals.
This:
@foo = tan @bar;
should be faster than:
foreach (0..$#bar) {
push @foo, sin $bar[$_]/cos $bar[$_];
}
by rather a lot. (Unless tan's cos/sin, in which case it's both faster and
more correct... :)
> In general, I would like to see the policy be "unless there is a
>clear and demonstrated need, we don't do it." Let's just make the engine
>easy enough to change that, as we discover things we didn't know we
>needed, we can go back and add them in later.
That policy is in effect in general, just not necessarily in the areas you
might think.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: Math functions? (Particularly transcendental ones)
At 07:43 PM 9/8/2001 -0700, Wizard wrote: >Questions regarding Bitwise operators: > > > =item rol tx, ty, tz * >... > > =item ror tx, ty, tz * > >Are these with or without carry? That's a good question. Now that we have a list of bitwise ops, we can decide how they work. What happens when you rotate/shift/bit-or a float? Or a bitint/bigfloat? Or a string? Important questions, and we can hammer something out now that we know what they are. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Math functions? (Particularly transcendental ones)
On 9/9/01 11:47 AM, Dan Sugalski wrote: >> http://www.allegedlyfunny.com/opcodes.html >> I think DWIM might be a bit much, but HCF (Halt, Catch Fire) might be >> fun :) > > Far too many of those are tempting... :) Hey, if the PPC can have EIEIO, I see no reason Parrot can't sneak a few fun ones in... :) -John
Re: Math functions? (Particularly transcendental ones)
At 03:51 PM 9/8/2001 -0700, Matthew Cline wrote: >On Saturday 08 September 2001 09:00 am, Dan Sugalski wrote: > > > Okay, I'm whipping together the "fancy math" section of the interpreter > > assembly language. I've got: > > > > sin, cos, tan : Plain ones > > asin, acos, atan : arc-whatevers > > shinh, cosh, tanh : Hyperbolic whatevers > > log2, log10, log : Base 2, base 10, and explicit base logarithms > > pow : Raise x to the y power > > > > Can anyone think of things I've forgotten? It's been a while since I've > > done numeric work. > > >Sorry for being clueless, but why are "fancy math" operators being included >in the opcodes, rather than being callable functions? * Some folks will use them, which is good. (Some will use them a lot) * Being an opcode makes things like this easier: @foo = tan @bar; # Take the tan of each element of bar and store in foo * Parrot's getting its first source release on monday, and I expect a goodly number of folks would like to try their hand at writing opcode functions, and these are straightforward. >Does each builtin >function have an opcode? Most of them will, yep. (I can't say all just because we're not done with the list yet) Many perl subs will also end up as opcode functions. Generally if we have a fixed list of inputs and outputs, there's no reason not to use an opcode instead of an actual perl sub. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Math functions? (Particularly transcendental ones)
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 07:43 PM 9/8/2001 -0700, Wizard wrote: > >Questions regarding Bitwise operators: > > > > > =item rol tx, ty, tz * > >... > > > =item ror tx, ty, tz * > > > >Are these with or without carry? > > That's a good question. Now that we have a list of bitwise ops, we can > decide how they work. What happens when you rotate/shift/bit-or a float? Or > a bitint/bigfloat? Or a string? Important questions, and we can hammer > something out now that we know what they are. I'd like to suggest that the shift- and roll/rotate- ops take a 4th parameter, that being the "word"-size in bits. For Bigints and arbitrary-length bit-vectors, the size of a "word" to rotate or shift could be infinite, probably isn't what is wanted. It would also make simpler such operations that might come up in some cryptographic routines, like "rotate the upper 64 bits left 3 bits", which would be encoded as (assuming "rotate_l dest, source, roll-amount, wordsize") rotate_l P1, P1, 64, 128 rotate_l P1, P1, 3, 64 rotate_r P1, P1, 64, 128 Just my 2 centums.
RE: Math functions? (Particularly transcendental ones)
Just curious, would it be practical to design-in a boolean-specific register/set of registers? There are many processors (PICC, 8051, etc.) which would likely be better able utilize their own optimizations if this were the case ( bitset, testbit, high, low, etc.). It could be done without the register(s), but implementation would be much more straight-forward. Just a thought, Grant M.
Re: Math functions? (Particularly transcendental ones)
> > BW> Roll y left z bits and store the result in x. > > BW> [what are the valid values for z?] > > > > isn't that rotate left? rotate should require z to be the word size or > > less. or we can define it to work modulo the word size. which reminds > > me, is there going to be a simple language way to get the word size > > (other than %Config)? > > Yep, rotate. I really need to wake up before I post email. Well, what > if a PMC or Numeric registers are passed to rol, rol, shr, shl? What > would be the size then? We could disallow them since they really don't > make sense...or do they? Is the VM going go have a fixed size register > set regardless of platform? If not, then the shift will behave > differently on each platform the bytecode is run...and that's bad, > especially if someone (cleverly) decides that a "SHL I0,I0,32" clears > the register. Previous discussions on bit operators on arbitrarily-sized integers: http://www.mail-archive.com/perl5-porters@perl.org/msg33402.html http://www.mail-archive.com/perl5-porters@perl.org/msg29166.html Executive summary: are you fixing the width of the number or not? -- Bryan C. Warnock [EMAIL PROTECTED]
RE: Math functions? (Particularly transcendental ones)
At 01:54 PM 9/9/2001 -0700, Wizard wrote: >Just curious, would it be practical to design-in a boolean-specific >register/set of registers? There are many processors (PICC, 8051, etc.) >which would likely be better able utilize their own optimizations if this >were the case ( bitset, testbit, high, low, etc.). It could be done without >the register(s), but implementation would be much more straight-forward. Could you go into more detail? I'm not sure what you're getting at here, but it sounds potentially interesting. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Math functions? (Particularly transcendental ones)
At 11:03 PM 9/8/2001 -0500, Brian Wheeler wrote: >On Sat, 2001-09-08 at 22:24, Uri Guttman wrote: > > > "BW" == Brian Wheeler <[EMAIL PROTECTED]> writes: >Looking at the opcodes as presented in the PDD, they're hauntingly like >the alpha codes (maybe Dan's favorite isn't the vax, but the alpha :) I made one abortive foray into Alpha assembly. (The RC5 core, FWIW) Finding details on the calling conventions and translating from Alpha NT format to Alpha VMS format put a quick halt to that. Too much trouble for another 500kk/sec. :) >If I hadn't let my hobbyist licenses expire on my vms/alpha machine, I'd >check it too... So go renew! It's easy... > > which reminds > > me, is there going to be a simple language way to get the word size > > (other than %Config)? There'll be some way to get info about the environment. I haven't gotten there yet, though. (A set of status opcodes, basically) > Well, what >if a PMC or Numeric registers are passed to rol, rol, shr, shl? What >would be the size then? We could disallow them since they really don't >make sense...or do they? Sure they do. Rotating bitvectors makes sense in some contexts, and rotating PMCs that hold integers certainly do. > Is the VM going go have a fixed size register >set regardless of platform? Number yes. Number of bits, no. > If not, then the shift will behave >differently on each platform the bytecode is run...and that's bad, >especially if someone (cleverly) decides that a "SHL I0,I0,32" clears >the register. "Oh, that's clever!" are the three most dangerous words in the english language. :) Clever like that will get you bitten, and deservedly so, since "clear I0" or "set I0, 0" is a darned sight more straightforward and faster. >Honestly I pulled the mneumonics from the x86 set, though the ROL/ROR >ops are the same as m68k. Grabbing mnemonics from other folks assembly set is a reasonable thing, and I'm OK with that. (There's no reason we can't have a short and long form, but I don't know that I want to go that far right now) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Math functions? (Particularly transcendental ones)
At 11:24 PM 9/8/2001 -0400, Uri Guttman wrote: > > "BW" == Brian Wheeler <[EMAIL PROTECTED]> writes: > > > BW> =item and tx, ty, tz * > > BW> Bitwise And all bits in y with z and store the result in register x. > BW> (x = y & z) > >just a minor thought on parrot assembler argument order. dan seems to >have picked the result register to be first. my experience with the >pdp-11 left me with the result on the right. i think the vax (dan's >favorite) followed dec's tradition and kept the result on the right. is >this ordering final? The VAX wasn't my favorite assembly. (Never did any, thinking about it) I was rather fond of both the 68K and the 6502. (Okay, so I was young and impressionable... :) Destination on the left makes parsing the assembly a bit easier. We've not gotten to the tricky bits yet, but those are coming. [odd bitops snipped. We'll deal with them later] >why the abbreviated op names? we don't want another creat(2) >controversy. :) i don't think we need to limit our op code names to any >length. old assemblers did so because of the odd speed up tricks. since >the parrot assembler will rarely be used directly and it will be written >in perl. shift_l is clearer. but then, i and many others learned short >assembler op names without trouble. we should have some consensus on op >name styles. underscores? longer names encouraged? etc. Names should be in all lower case, and short but not truncated. Try to avoid underscores, but shift_l and shift_r are OK. (I'll get to the underscore issues later) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Math functions? (Particularly transcendental ones)
At 10:19 PM 9/8/2001 -0500, Brian Wheeler wrote: >Out of curiosity, will there be a NOP instruction? I guess we really >wouldn't need one, since things like ADD I0,I0,0 is effectively a NOP >and the Dan has indicated he wanted to keep the bytecode read-only, so >there'd be no need for it after optimization (after the bytecode has >been fixed to the disk or in memory). Yeah, I can't think of a good reason for a noop. We might have one anyway, though, just in case one comes along anyway. >Here's a dumb question: will parrot allow bytecode which is stored in a >perl scalar to be executed? Yup, in a restricted sandbox too, if you want. That way we'll be able to serialize code to bytestreams, spit them across the 'net, and execute them on the other end. >http://www.allegedlyfunny.com/opcodes.html >I think DWIM might be a bit much, but HCF (Halt, Catch Fire) might be >fun :) Far too many of those are tempting... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Math functions? (Particularly transcendental ones)
Jeremy Howard: # Uri Guttman wrote: # > > "BS" == Benjamin Stuhl <[EMAIL PROTECTED]> writes: # > # > >> Can anyone think of things I've forgotten? It's been a # while since # > >> I've done numeric work. # > # > BS> ln, asinh, acosh, atanh2? # > # > dan mentioned log (base anything) but i don't recall ln. # and definitely # > the arc hyberbolics are in after i pointed them out. dunno # about atanh2. # > # We only really need ln(). Then [log(y) base x] is simply # [ln(y)/ln(x)]. # There's no need to have separate functions for different bases. "OISC: You've heard of RISC, Reduced Instruction Set Computers? Well, here is the concept taken to its logical extreme -- an emulator for a computer with just one (1) instruction (Subtract and Branch if Negative)! Sample programs in the OISC machine language are included. We now have available have a revised and expanded version of oisc called OIC. In the future, this may replace OISC." from http://www.tuxedo.org/~esr/retro/ :^) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
Re: Math functions? (Particularly transcendental ones)
On Sat, 08 Sep 2001 13:02:04 -0400, Dan Sugalski wrote: >>Uri mentioned exp(x) = e^x, but I think if you are going to include >>log2, log10, log, etc, you should also include ln. > >Added. Er... aren't ln and log synonyms? -- Bart.
Re: Math functions? (Particularly transcendental ones)
> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes: BL> On Sat, 08 Sep 2001 13:02:04 -0400, Dan Sugalski wrote: >>> Uri mentioned exp(x) = e^x, but I think if you are going to include >>> log2, log10, log, etc, you should also include ln. >> >> Added. BL> Er... aren't ln and log synonyms? we are using log as in log( base, num ) where you can specify the log base. ln is just log( e, num ). same for log2 and log10. those are just the most common bases for logs. no reason not to support all of them in parrot as they are trivial wrappers (and they save an argument per call). they can also be in the math module where again they will be simple wrappers. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
Re: Math functions? (Particularly transcendental ones)
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> At 01:54 PM 9/9/2001 -0700, Wizard wrote: >> Just curious, would it be practical to design-in a boolean-specific >> register/set of registers? There are many processors (PICC, 8051, etc.) >> which would likely be better able utilize their own optimizations if this >> were the case ( bitset, testbit, high, low, etc.). It could be done without >> the register(s), but implementation would be much more straight-forward. DS> Could you go into more detail? I'm not sure what you're getting at DS> here, but it sounds potentially interesting. i think this is conflating the VM registers and the cpu registers. parrot is in c and there is a fair amount of code between the boolean parrot op code and the single machine instruction that can do a boolean like that. in a c compiler that is a good idea, use the special cpu instructions. in fact parrot will use them only because the c compiler for the architecture you are on will generate those instructions. but having parrot op codes map to special instructions makes sense only if we are doing some form of machine instruction generation as with JIT or TIL. then that becomes an optimization that can be applied during that machine code generation. but at the stage we are at with parrot, it is not applicable. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
Re: Math functions? (Particularly transcendental ones)
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> Names should be in all lower case, and short but not truncated. Try to DS> avoid underscores, but shift_l and shift_r are OK. (I'll get to the DS> underscore issues later) two suggestions. first in the parrot asm PDD, codify that (maybe under a style section). and secondly, since we will be creating a bunch of ops now and in the near future, we can establish an op name style. shift_l is ok as is good old add. but what about subtract? pdp-11 used SUB which already has much meaning in the perl world. :) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
Re: Math functions? (Particularly transcendental ones)
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> That's a good question. Now that we have a list of bitwise ops, we DS> can decide how they work. What happens when you DS> rotate/shift/bit-or a float? Or a bitint/bigfloat? Or a string? DS> Important questions, and we can hammer something out now that we DS> know what they are. GACK!! i did that very thing when writing a PL/I any-to-any library. it really did any of 11 types to any of 11 types conversion, one of which was float to bit string. the problem is that is platform specific to an extreme. even if you have ieee floats, the byte ordering is subject to endian issues. i would not like to see perl ops that have so little care about portability. we should look into how other langs specify some of these wacky conversions and see what we can learn from that. actually pack supports float to bit conversion in some way. you can pack a float into a byte string. no specs on byte ordering or anything else are in the docs. also perl5 has minimal support for bit strings. the Bit::Vector library has many useful functions. we should design our bit string ops to support a similar set of operations (maybe not all of them). then that could be loaded too on demand like math when any of them are called/compiled in. along the way we will have to be very clear about our bit string definitions. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
Re: Math functions? (Particularly transcendental ones)
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Yeah, I can't think of a good reason for a noop. We might have one
DS> anyway, though, just in case one comes along anyway.
in a hardware cpu they were commonly used to fill an instruction slot to
keep a pipeline filled, or to follow a branch decision, or to pad a long
running op. in parrot, those timing issues don't exist. we have no
critical penalty with instruction ordering or branching. but then a NOP
would be as trivial as:
int NOP( int PC ) { return PC + 4 }
assuming 4 byte op codes.
>> Here's a dumb question: will parrot allow bytecode which is stored in a
>> perl scalar to be executed?
DS> Yup, in a restricted sandbox too, if you want. That way we'll be
DS> able to serialize code to bytestreams, spit them across the 'net,
DS> and execute them on the other end.
will the op code table need to be sent over if it is code from a module
which defines new op codes? what about different versions of perl6, will
they always use the same op code numbers? what about relocation and the
cleanup section of modules?
inquiring minds want to know,
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Search or Offer Perl Jobs -- http://jobs.perl.org
