This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Telford Tendys <telford@eng.uts.edu.au> writes: > On Mon, Feb 01, 1999 at 03:44:35AM -0330, Greg Harvey wrote: > > Maciej Stachowiak <mstachow@alum.mit.edu> writes: > > > > > > Oops, wasn't keeping a close eye on the standard. I don't see why > > > > these couldn't be moved to numbers.c, though (couldn't we just lose > > > > the $blah functions, and do the entire thing in c?). > > > > > > That would probably be a good idea in general, but numbers.c tries to be > > > clever about lifting the C double-taking versions of these functions > > > almost > > > directly so it might be more work than you expect (I imagine it would > > > not > > > be too hard to provide a "complex" version of each of these functions as > > > well which takes two doubles per argument (or maybe even use the > > > built-in > > > complex functions on C systems that support them). > > > > > > > Actually, I'm right now just taking the very easy, do exactly what the > > current versions do approach (complex numbers apparently being > > something that I've completely repressed ;). > > I don't see that complex number support is REQUIRED for RnRS, it's just that > RnRS specifies that if complex numbers ARE supported then they should be > supported in line with the standard. I would guess that about 10% of guile > users will be using complex numbers, maybe less. This is an excellent reason > to put them in a module. This is good (and not just because it's very easy to do, though that's a big part of the appeal for me ... just rename the $foo functions to foo (and have them accept SCM args, rather than doubles), and provide a complex module that defines the extended functionality versions). > I do feel that there should be at least a real valued sin, cos, etc available > in the core because a lot more people are going to use these for their real > valued applications. Also, the real valued functions are going to be faster > than the transcendental equivalents and, frankly, guile needs all the speed > it can get. This is true, though I don't particularly like the way they're done currently (with the tc7_cxr stuff... this seems to be cuteness for no particular gain, just moving the argument checks & conversion into eval, which is a place we should definately be trying to remove any extra code). > The dollar sign naming thing is just another symptom of a lack of a functional > module system. If we had separate namespaces then the core namespace would > define (sin X) as using real valued X while the complex module namespace > would define (sin X) as the transcendental. This would allow a logical system > of extensions and give users their choice of behaviour. Actually, we can do this now (if I'm not being completely stupid), and without even modifying much (just change the transcend-complex module to define the current sin, ... to $sin, and use the code that's already there). These seem to mostly be a holdover from SCM that hasn't really been looked at closely. > And before anyone asks, no, I don't believe that there should be a special > ``real-numbers'' module that people ask for so that they can get the > simplified functions -- that is just too topsy-turvy to contemplate. Yeah, that would be lame. -- Greg