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)
> "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)
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)
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)
> 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)
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)
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.
