Just an informational comment on this (I'm not involved enough to expect a "vote", but I can probably speak for a segment of the community): In astronomy we mainly use float32 (as well as int16). That's usually precise enough and we work with quite large images (eg. 100Mb/file times N), so the additional storage requirements of float64 would be significant. From my viewpoint, it's good for any processing step to preserve the data type of the input unless there's a specification to the contrary. Maybe one can cast the output back to 32 though, as long as there wasn't a division by very small values (that does happen sometimes). Cheers, James. On 06/11/10 22:14, Chris Colbert wrote:
i think we should definitely add uint8 support for algorithms.
I think float64, int16, and uint8 versions of each algorithm would be a good compromise.
2010/11/6 St�fan van der Walt <stefan@sun.ac.za <mailto:stefan@sun.ac.za>>
On Fri, Nov 5, 2010 at 3:29 PM, Chris Colbert <sccolbert@gmail.com <mailto:sccolbert@gmail.com>> wrote: > Did we decided on a standard for which dtypes we will support?
IIRC, we said we'd write utility functions to convert from whatever input is received to either float64 or int16 types and go from there. The output type is whatever is most convenient for the algorithm, and should be well documented.
Can you recall the different approaches discussed at the sprint?
Cheers St�fan