RFR: IO cleanup

[James Turner]

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 at sun.ac.za <mailto:stefan at sun.ac.za>>
>
>     On Fri, Nov 5, 2010 at 3:29 PM, Chris Colbert <sccolbert at gmail.com
>     <mailto:sccolbert at 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