[Numpy-discussion] convertcode.py and float defaults
tim.hochberg at cox.net
Sat Jul 1 18:34:18 CDT 2006
> I don't see how that will simplify the transition. Convertcode will
> still need to detect use of the dtype argument (keyword or
> positional). Simple s/zeros/int.zeros/ will not work. I read Ed's
> suggestion as retaining current default in intzeros so that
> intzeros(n, float) is valid. On the other hand Tim's int.zeros would
> not take dtype argument because dtype is already bound as self.
It's just like a game of telephone! That was Robert's suggestion not
mine. What I said was:
Personally, given no other constraints, I would probably just get
rid of the defaults all together and make the user choose.
Since I've been dragged back into this again let me make a quick
comment. If we are choosing a floating point default, there are at least
two other choices that make as much sense as using float64. The first
possibility is to use the same thing that python uses, that is 'float'.
On my box and probably most current boxes that turns out to be float64
anyway, but choosing 'float' as the default rather than 'float64' will
change the way numpy is expected to behave as hardware and / or Python
evolves. The second choice is to use the longest floating point type
available on a given platform, that is, 'longfloat'. Again, on my box
that is the same as using float64, but on other boxes I suspect it gives
somewhat different results.
The advantage of using 'float64' as the default is that we can expect
programs to run consistently across platforms. The advantage of choosing
'float' is that interactions with Python proper may be less suprising
when python's float is not 'float64. The advantage of using 'longfloat'
is that it is the safest type to use when interacting with other unknown
I don't care much which gets chosen, but I think we should know which of
these we intend and why. Since there often the same thing at present I
have a suspicion that these three cases may be conflated in some people
> The bottom line: int.zeros will not work and intzeros(n, float) is
> ugly. I would not mind oldnumeric.zeros, but context aware convertcode
> is still worth the effort. Let's see how far I will get with that ...
> On 7/1/06, Alan G Isaac <aisaac at american.edu> wrote:
>> On Sat, 1 Jul 2006, Ed Schofield apparently wrote:
>>> couldn't we make the transition easier and more robust by
>>> writing compatibility interfaces for zeros, ones, empty,
>>> called e.g. intzeros, intones, intempty
>> I think Robert or Tim suggested int.zeros() etc.
>> Alan Isaac
>> 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
>> Numpy-discussion mailing list
>> Numpy-discussion at lists.sourceforge.net
> 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
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
More information about the Numpy-discussion