>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> 1/x is often handy, although maybe not enough to justify its own opcode.
>> (It is often used in other calculations, however, so perhaps one opcode
>> would be better than 3.)
>>
>> sqrt has traditionally been provided in languages, although it (and all
>> other roots) could simply be an power (inverse x).
>>
>> atan2 is also often traditionally provided in a language, since it
>> identifies the proper quadrant.
DS> Fair enough. Those are all going into the transcendental section,
DS> I think. (Though my very vague memories of trig makes me think
DS> they're not, strictly speaking, transcendental functions)
>> Others would include abs, floor, ceil, round, mod - don't know if
>> those are basic or "fancy" to you. I suspect you may have those
>> already....
DS> Basic. No polynomial expansions under the hood means basic. :) I
DS> added mod, I forgot the rest.
some of those are in POSIX now. will they be standard in the math lib?
will the math lib be autoloaded upon detection of any of its functions?
we don't want to have to say use math; all the time.
>> The question arises what do you do as its opcode, and what
>> languages features can be a series of opcodes.
DS> Well, it looks like perl's angling to make things easier for the
DS> math folks, so it makes sense to have these as single opcodes. (If
DS> anyone can think of things that'd help out the bioperl people, let
DS> me know--we can add a set of "bioperl ops" )
since it will be a separate lib, expanding it will be easier and less of
an issue. we just have to define the official names and ops supported in
it. i am sure math types will want many more functions but those will
have to be in another module and loaded explicitly with a use command.
DS> I'm beginning to think that Uri's right, and the transcendental
DS> bits should be in a separate module. No need to yank in the math
DS> libraries ('specially the system math libraries) if you're just
DS> doing text processing.
i forgot about the c lib not being needed then. that is a good win too.
DS> Of course, that means I need to define the ops to load in op
DS> modules...
see, i said you weren't focusing on the more general stuff. but then
hacking the math stuff made you realize that. i think we have to keep a
shorter leash on you. :)
speaking of those loading ops, i don't recall any discussions about that
yet. we have covered some of the format for the op code tables, but the
actual loading and what ops do it and how they do it is still open
IMO. i am sure you can hack something up quickly but this will be a
critical area as we will be loading more modules than with perl5 it
seems.
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
