On Jan 8, 2008 12:03 PM, Anne Archibald <[EMAIL PROTECTED]> wrote: > On 08/01/2008, Charles R Harris <[EMAIL PROTECTED]> wrote: > > > I'm starting to get interested in implementing float16 support ;) My > > tentative program goes something like this: > > > > 1) Add the operators to the scalar type. This will give sorting, basic > > printing, addition, etc. > > 2) Add conversions to other types. This will allow promotion of data to > > currently supported types. > > 3) Unoptimized BLAS or ATLAS additions for the type. This would give > array > > operations. > > 4) Figure out what the precedence relations are. > > > > Can you add some details to this roadmap? It also strikes me that this > > exercise can be repeated for quad precision floats, so might be a good > > preparation for future IEEE types like the proposed decimal floating > types. > > Note that we are going to need some way to distinguish quads and > extended > > precision types on 64bit platforms, as both will both register as > float128 > > in the current notation. Decimal floats can be added with the notation > > decimal64, etc. > > How were you planning to implement the basic mathematics (addition, > multiplication, trig, what have you)? Were you planning to code all
Basic math isn't bad and I expect that there are already emulations out there. Comparisons look easy for all the floating types. Type conversions are going to be a mess if we get into the decimal floats. And support for ufuncs is probably pointless for the type as is. I will probably look into using up/down conversions on an element by element basis if I do go that route. Logic operators shouldn't be a problem, avg and such already accumulate in greater precision, so there is probably a subset of the ufuncts that should go right over. > that from scratch or is there a 16-bit float math library? Or were you > planning to make this work only on machines with 16-bit math hardware? > Or ship it out to a graphics card? > > Without hardware support, people may be happier using 16-bit floats > only for on-disk storage... Well, at a minimum people will want to read, write, print, and promote them. That would at least let people work with the numbers, and since my understanding is that the main virtue of the format is compactness for storage and communication, a basic need will be filled right there. One potential problem I see is handling +/-inf and nans, tests for these should probably be built into the type. Chuck
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
