Re: Numpydiscussion digest, Vol 1 #693  3 msgs
1. Add a type parameter to sum which defaults to widest type.
2. Add a type parameter to reductions (and fix output type handling). Default is sametype as it is now. No major changes to Ccode.
3. Add a WidestType(array) function:
Bool > Bool Int8,Int16,Int32,Int64 > Int64 UInt8, UInt16,UInt32,UInt64 > UInt64 (Int64 on win32) Float32, Float64 > Float64 Complex32, Complex64 > Complex64
This sounds like a good solution.
The only thing this really leaves out, is a higher performance implementation of sum/mean which Peter referred to a few times.
Is this really the case? It depends on how you plan to implement the output conversion. If you will do this by allocating a temporary converted copy of the complete input before the calculations then this potentially requires a lot of temporary storage. But it is certainly possible to come up with an implementation that avoids this. Have you given this some thought?
Peter, if you want to write a specialized module, we'd be happy to put it in the addons package.
I hope that the reduce methods can be made sufficiently efficient so that this will not be necessary. Cheers, Peter
Peter Verveer writes:
Todd Miller writes:
1. Add a type parameter to sum which defaults to widest type.
2. Add a type parameter to reductions (and fix output type handling). Default is sametype as it is now. No major changes to Ccode.
3. Add a WidestType(array) function:
Bool > Bool Int8,Int16,Int32,Int64 > Int64 UInt8, UInt16,UInt32,UInt64 > UInt64 (Int64 on win32) Float32, Float64 > Float64 Complex32, Complex64 > Complex64
This sounds like a good solution.
The only thing this really leaves out, is a higher performance implementation of sum/mean which Peter referred to a few times.
Is this really the case? It depends on how you plan to implement the output conversion. If you will do this by allocating a temporary converted copy of the complete input before the calculations then this potentially requires a lot of temporary storage. But it is certainly possible to come up with an implementation that avoids this. Have you given this some thought?
The way numarray ufuncs currently work is that for larger arrays, the conversion of types is only done in blocks. No temporary copy is made of the whole input array. So the temporary storage issue is not a problem.
participants (2)

Perry Greenfield

Peter Verveer