Travis Oliphant wrote: > Robert Kern wrote: > > >> Travis Oliphant wrote: >> >> >> >> >>> It looks like 1.0-x is doing the right thing. >>> >>> The problem is 1.0*x for matrices is going to float64. For arrays it >>> returns float32 just like the 1.0-x >>> >>> >>> >> Why is this the right thing? Python floats are float64. >> >> >> > Yeah, why indeed. Must be something with the scalar coercion code...
This is one of those things that pops up every few years. I suspect that the best thing to do here is to treat 1.0, and all Python floats as having a kind (float), but no precision. Or, equivalently treat them as the smallest precision floating point value. The rationale behind this is that otherwise float32 array will be promoted whenever they are multiplied by Python floating point scalars. If Python floats are treated as Float64 for purposes of determining output precision then anyone using float32 arrays is going to have to wrap all of their literals in float32 to prevent inadvertent upcasting to float64. This was the origin of the (rather clunky) numarray spacesaver flag. It's no skin off my nose either way, since I pretty much never use float32, but I suspect that treating python floats equivalently to float64 scalars would be a mistake. At the very least it deserves a bit of discussion. -tim ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
