On Wed, 2003-01-29 at 05:02, Nicholas Clark wrote:
> Warning bells are ringing in my head. Someone sent code to p6i about 1 or
> 2 years ago that could convert between various floating point formats.
> You may be re-inventing wheels here.
>
> I forget who, and I've not managed to find it on google.
> Also I can't work out how to search the list archive at develooper.com.
You might be thinking of me. I had written such code for work, and had
announced as much before actually checking to see if I could export such
work. Which I couldn't, and therefore didn't.
I had all my notes[1] for rewriting such code, but, {sigh}, when was the
last time I actually produced anything, and useful at that? :-(
It's these notes I'm perusing now just to pass on for someone else to
actually *do* something with. Of particular bafflement (as far as a
Parrot implementation is concerned) is how to code things for pack,
unpack, and packfile use[2]. Do you go for consistency, treating all
non-native floats as byte-streams, returning both a native float (of
some arbitrary size?) and the number of bytes used from the stream? Do
you make things as efficient as possible where possible, so you can do
things like inline byte-swapping between IEEE and EEEI? How do you
handle conversions that overflow native types? Leopold's patch elects
to handle overflows as Inf, rather than, say, punting to a BigFloat
implementation. What's most useful for Parrot?
Anyway, evaluate the patch based on what it does[3].
[1] IEEE and EEEI formats (single, double, double extended) equivalent
to C's float, double, and long double on the various supported
platforms; various floats on CRI-based Crays; and a subset of VAX
formats.
[2] An old packfile proposal for supported formats.
http:[EMAIL PROTECTED]/msg06918.html
[3] Or, how well it does what it should do. I don't think anyone's
really addressed how much work to commit to such a thing.
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
