Re: [Numpy-discussion] convertcode.py and float defaults

[Tim H. <tim...@co...>]

Sasha wrote:
> 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 
types.

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 
heads.

-tim

> 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 <ai...@am...> 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.
>>
>> fwiw,
>> 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
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Numpy-discussion mailing list
>> Num...@li...
>> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>
>>     
>
> 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
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>