On Monday 19 January 2009 14:13:22 Bob Rogers wrote: > On Monday 19 January 2009 13:41:21 Bob Rogers wrote: > > Math ops: > > - ceil/floor > > - transcendental ops > > - gcd/lcm/fact > > > > What are you suggesting as replacements? Or (with the probable > > exception of fact) must every language reinvent these wheels? > > I had in mind the idea that they could become members of a PBC library.
> Do you think that would be fast enough? The usual way for dynamic > languages to get fast compiled numeric code is to bind variables to > hardware types at compile time, and then inline numeric operations in > order to use that information. That seems to require op_i_i_i and > op_n_n_n versions of these ops, which are not language-dependent. I don't see how Parrot can be fast enough in general without JIT. With JIT, if these ops are implemented in terms of other ops, there's no speed penalty. > And possibly of other ops as well. Speed should certainly not be an > issue for Parrot 1.0, so I can see not wanting to add new numeric ops, > but I don't see the point of removing ops we already have only to decide > we need them later. That's a fair point, though it can be difficult to remove ops later. -- c
