Re: Math functions? (Particularly transcendental ones)
>Okay, I'm whipping together the "fancy math" section of the interpreter >assembley language. I've got: > ... >Can anyone think of things I've forgotten? It's been a while since I've >done numeric work. HP calculators sometimes define lnp1(x) = ln(1 + x) expm1(x) = exp(x) - 1 to deal accurately and quickly with the special case where x<<1. This may not be useful in an environment of pseudo-infinite precision, unless speed begins to matter alot. Maybe they could be called automagically when the compiler sees something like the RHS of the above as an optimization. -- -- Tim Conrow [EMAIL PROTECTED] |
RE: Math functions? (Particularly transcendental ones)
At 02:12 PM 9/10/2001 -0700, Hong Zhang wrote: > > Uri Guttman > > > we are planning automatic over/underflow to bigfloat. so there is no > > > need for traps. they could be provided at the time of the > > > conversion to big*. > > > > OK. But will Perl support signaling and non-signaling NANs? > >I don't think we should go for automatic overflow/underflow between >float and bigfloat. Not for N registers, no. Perl's standard scalar variable will do this, though. >The float exception (overflow, underflow, inexact, >divide zero, ...) is very difficult to handle. That's why we wrap it in a generic macro and leave it for the individual ports to handle. >Using Unix signal is >expensive and very platform-specific (lots of ucontext issues). Since >C language does not support floating-point signal, we may use some >assembly code to handle it, it will be porting nightmare. Not if we do it right to start. Yes, there may be snippets of assembly in solaris.c/vms.c/linux.c/whatever.c, but that's fine. We can use a boring test comparison as a generic replacement on platforms people don't want to use a specific one on. >Since most of floating-point assumes IEEE-semantics, taking automatic >float/bigfloat will change this assumption significantly. Most people I know that use floating point numbers don't have any idea that there are well-defined IEEE semantics, let alone what they are. Some folks are, and for them we'll make sure you can avoid leaving IEEE floats. Of course, that's as much an argument for automatically going straight to bigfloats rather than going to native floats, since if people generally have no idea what the errors inherent in IEEE floats are they probably ought not use them. That's something to take up with Larry, though. >It may a >lot of code and algorithm. I think it is safer just to provide a >BigDecimal class for developers to use, and keep the basic float >semantics (close to 64-bit IEEE-754 if possible). IEEE floats suck. (I've got an amazingly bad opinion of a lot of widely-accepted computer practice, don't I? :) They're an OK option for what they are, and the hardware speed support is nice, but let's face it, they're a compromise with adequate characteristics, and the design compromises are usually the wrong ones (with the single exception of speed) for what most people do with floats in perl. 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)
> Uri Guttman > > we are planning automatic over/underflow to bigfloat. so there is no > > need for traps. they could be provided at the time of the > > conversion to big*. > > OK. But will Perl support signaling and non-signaling NANs? I don't think we should go for automatic overflow/underflow between float and bigfloat. The float exception (overflow, underflow, inexact, divide zero, ...) is very difficult to handle. Using Unix signal is expensive and very platform-specific (lots of ucontext issues). Since C language does not support floating-point signal, we may use some assembly code to handle it, it will be porting nightmare. Since most of floating-point assumes IEEE-semantics, taking automatic float/bigfloat will change this assumption significantly. It may a lot of code and algorithm. I think it is safer just to provide a BigDecimal class for developers to use, and keep the basic float semantics (close to 64-bit IEEE-754 if possible). Hong
RE: Math functions? (Particularly transcendental ones)
Uri Guttman > we are planning automatic over/underflow to bigfloat. so there is no > need for traps. they could be provided at the time of the > conversion to big*. OK. But will Perl support signaling and non-signaling NANs?
Re: Math functions? (Particularly transcendental ones)
Dan Sugalski wrote: >Okay, I'm whipping together the "fancy math" section of the interpreter >assembly language. I've got: [...] > >Can anyone think of things I've forgotten? It's been a while since I've >done numeric work. I'm not a math weenie, but I would thing gamma(x) would be of use. Also perhaps a div2(n,m): given two ints, returns two ints, n/m and n%m. -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
RE: Math functions? (Particularly transcendental ones)
At 10:58 AM 9/10/2001 -0700, David Whipp wrote: >Dan Sugalski wrote: > > Okay, I'm whipping together the "fancy math" section of the > > interpreter assembly language. I've got: >[...] > > Can anyone think of things I've forgotten? It's been a while > > since I've done numeric work. > >I'm not sure where this belongs, but I'd really like to have >a usage model for some of the edges of arithmetic. For example, >it should be possible to enable/disable overflow and underflow >exceptions. Basically, Perl5 should be IEE754 compliant; and it >should support the (optional) traps. It would also nice to have >a saturation-on-overflow mode/type. I'd intended the basic math ops on floats and ints (the ones in I and N registers) to ignore over and underflow stuff, or potentially throw exceptions, though there's no exception code at the moment. For math ops on variables, I'd intended they catch the exceptions and handle upgrading as appropriate. (The assumption being that the compiler would generate the low-level int/float code and make sure things don't over/underflow. I'm thinking that was probably a naive thought... :) >If you have this type of stuff for floats; it'd be consistant to >have it for integers, too. Yep. For variable operations we'd need it certainly, to catch cases where we need to go to the bigint format. 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)
> "DW" == David Whipp <[EMAIL PROTECTED]> writes: DW> Dan Sugalski wrote: >> Okay, I'm whipping together the "fancy math" section of the >> interpreter assembly language. I've got: DW> [...] >> Can anyone think of things I've forgotten? It's been a while >> since I've done numeric work. DW> I'm not sure where this belongs, but I'd really like to have DW> a usage model for some of the edges of arithmetic. For example, DW> it should be possible to enable/disable overflow and underflow DW> exceptions. Basically, Perl5 should be IEE754 compliant; and it DW> should support the (optional) traps. It would also nice to have DW> a saturation-on-overflow mode/type. we are planning automatic over/underflow to bigfloat. so there is no need for traps. they could be provided at the time of the conversion to big*. DW> If you have this type of stuff for floats; it'd be consistant to DW> have it for integers, too. overflow to bigint is also planned. 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)
Dan Sugalski wrote: > Okay, I'm whipping together the "fancy math" section of the > interpreter assembly language. I've got: [...] > Can anyone think of things I've forgotten? It's been a while > since I've done numeric work. I'm not sure where this belongs, but I'd really like to have a usage model for some of the edges of arithmetic. For example, it should be possible to enable/disable overflow and underflow exceptions. Basically, Perl5 should be IEE754 compliant; and it should support the (optional) traps. It would also nice to have a saturation-on-overflow mode/type. If you have this type of stuff for floats; it'd be consistant to have it for integers, too. Dave.
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)
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)
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 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)
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)
> "JH" == Jeremy Howard <[EMAIL PROTECTED]> writes: JH> 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. >> JH> We only really need ln(). Then [log(y) base x] is simply [ln(y)/ln(x)]. JH> There's no need to have separate functions for different bases. then there is no need for tan, or secant, or many others. it is useful to have some functions map directly to math lib calls. it usually is faster (fewer ops to call) and sometimes more accurate. we have pow and dan said will will probably have exp too. same thing. having these extra ops costs almost nothing and will simplify code generation and support of multiple language frontends. keep in mind parrot's goal is beyond just supporting perl5 functions. there is no reason why we can't support most common math functions in their most useful forms and not be minimal and have only 1 ln function. we can have ln, log2, log10 and log (any base) all at the same time. 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)
> "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. 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)
--- Dan Sugalski <[EMAIL PROTECTED]> 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. ln, asinh, acosh, atanh2? -- BKS __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
Re: Math functions? (Particularly transcendental ones)
On Saturday 08 September 2001 04:14 pm, Brian Wheeler wrote: > While not math, per se, there are bitops (and, or, not, xor, eqv) and > shifts (though they can be simulated by "mul tx,ty,(2^bits)" and "div > tx,ty,(2^bits)") There will be bitops. > > I doubt rolls would be useful :) Vuja de. > > Are there going to be string ops as well, or would add and mul work on > string registers? Yes. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Math functions? (Particularly transcendental ones)
On Sat, 2001-09-08 at 11:00, 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. > > Dan > While not math, per se, there are bitops (and, or, not, xor, eqv) and shifts (though they can be simulated by "mul tx,ty,(2^bits)" and "div tx,ty,(2^bits)") I doubt rolls would be useful :) Are there going to be string ops as well, or would add and mul work on string registers? Brian
Re: Math functions? (Particularly transcendental ones)
On Sat, Sep 08, 2001 at 02:55:36PM -0400, Uri Guttman wrote:
> zap is an ibm 360/370/390 assembler op code and i bet they
> trademarked/patented/whatevered its name. :)
>
> Zero and Add Packed.
>
> gawd, i can't believe i remembered that. i don't recall exactly what it
> does but i think it was decimal math (packed decimal).
>From The Free On-line Dictionary of Computing (06 Jun 01) [foldoc]:
Zero and Add Packed
(ZAP) An {IBM 360}/370 {assembly language}
instruction used when performing {packed arithmatic} to
initialise an {accumulator}.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Ooops, fatal mutation in the test script.
Re: Math functions? (Particularly transcendental ones)
> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes: MGS> On Sat, Sep 08, 2001 at 12:00:24PM -0400, Dan Sugalski wrote: >> pow: Raise x to the y power MGS> You forgot biff, zap and womp! zap is an ibm 360/370/390 assembler op code and i bet they trademarked/patented/whatevered its name. :) Zero and Add Packed. gawd, i can't believe i remembered that. i don't recall exactly what it does but i think it was decimal math (packed decimal). 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:
>> 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
Re: Math functions? (Particularly transcendental ones)
On Sat, Sep 08, 2001 at 12:00:24PM -0400, Dan Sugalski wrote: > pow : Raise x to the y power You forgot biff, zap and womp! -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One stretch your colon out, put some effort into it, and shit through that paste. -- japhy
Re: Math functions? (Particularly transcendental ones)
At 01:38 PM 9/8/2001 -0400, Bryan C. Warnock wrote:
>On Saturday 08 September 2001 12:00 pm, 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.
> >
>
>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.
Fair enough. Those are all going into the transcendental section, I think.
(Though my very vague memories of trig makes me think 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
Basic. No polynomial expansions under the hood means basic. :) I added mod,
I forgot the rest.
>The question arises what do you do as its opcode, and what languages
>features can be a series of opcodes.
Well, it looks like perl's angling to make things easier for the math
folks, so it makes sense to have these as single opcodes. (If anyone can
think of things that'd help out the bioperl people, let me know--we can add
a set of "bioperl ops" )
I'm beginning to think that Uri's right, and the transcendental bits should
be in a separate module. No need to yank in the math libraries ('specially
the system math libraries) if you're just doing text processing.
Of course, that means I need to define the ops to load in op modules...
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 Saturday 08 September 2001 12:00 pm, 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. > 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. 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 The question arises what do you do as its opcode, and what languages features can be a series of opcodes. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Math functions? (Particularly transcendental ones)
At 12:29 PM 9/8/2001 -0400, Buddha Buck wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > > > Okay, I'm whipping together the "fancy math" section of the interpreter > > assembly language. I've got: > > > > > Can anyone think of things I've forgotten? It's been a while since I've > > done numeric work. > >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. 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 12:12 PM 9/8/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> DS> Can anyone think of things I've forgotten? It's been a while since
> I've
> DS> done numeric work.
>
>i am not being picky, but there is secant, and arc hyperbolics too. you
>can derive secant from the others (gack, i forget how!) but then tan is
>just sin/cos and that is usually supplied anyway. some langs have exp
>which is just pow( e, power ).
Secant in it's variations, along with the arc hyperbolics are now in. As is
exp.
>what about providing e and pi as builtin functions with controllable
>precision. they would return a float or a bigfloat depending on the
>precision requested. with no args they would return a float with maximal
>precision for that size.
Good idea. We'll do that.
>how complete do you want this? why make it built in and not a math
>module with its own op codes?
They strike me as a reasonable set of things to have. They don't, I
suppose, have to be part of the base opcode set.
>and i would think math is low priority right now and would rather see
>you spend your valuable time on more generic and critical parrot
>stuff. this information comes from an echelon profile of your keyboard
>input. :)
Ah, I'm not actually going to write these, just get them in the
documentation. Not that writing them is tough--for example, the entire
opcode function to take the tangent of an NV constant is:
AUTO_OP tan_n_nc {
NUM_REG(P1) = tan(P2);
}
which, as you would probably admit, isn't that tough. :) (There's actually
more text in the support files than in the actual source module)
Besides, this stuff's quick and satisfying to whip out while I'm debugging
annoying memory allocation problems. It's nice to have simple things to do
that will work first time...
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: > Okay, I'm whipping together the "fancy math" section of the interpreter > assembly language. I've got: > Can anyone think of things I've forgotten? It's been a while since I've > done numeric work. Uri mentioned exp(x) = e^x, but I think if you are going to include log2, log10, log, etc, you should also include ln.
Re: Math functions? (Particularly transcendental ones)
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> Okay, I'm whipping together the "fancy math" section of the interpreter DS> assembly language. I've got: DS> sin, cos, tan : Plain ones DS> asin, acos, atan : arc-whatevers DS> shinh, cosh, tanh : Hyperbolic whatevers DS> log2, log10, log : Base 2, base 10, and explicit base logarithms DS> pow : Raise x to the y power DS> Can anyone think of things I've forgotten? It's been a while since I've DS> done numeric work. i am not being picky, but there is secant, and arc hyperbolics too. you can derive secant from the others (gack, i forget how!) but then tan is just sin/cos and that is usually supplied anyway. some langs have exp which is just pow( e, power ). what about providing e and pi as builtin functions with controllable precision. they would return a float or a bigfloat depending on the precision requested. with no args they would return a float with maximal precision for that size. how complete do you want this? why make it built in and not a math module with its own op codes? and i would think math is low priority right now and would rather see you spend your valuable time on more generic and critical parrot stuff. this information comes from an echelon profile of your keyboard input. :) 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
Math functions? (Particularly transcendental ones)
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. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
