Converting bool to float

[Tim Hochberg]

Travis Oliphant wrote:
> Robert Kern wrote:
>
>   
>> Tim Hochberg wrote:
>>  
>>
>>     
>>> 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.
>>>    
>>>
>>>       
>> Well, they *are* 64-bit floating point numbers. You simply can't get around 
>> that. That's why we now have all of the scalar types: you can get any precision 
>> scalars that you want as long as you are explicit about it (and explicit is 
>> better than implicit). The spacesaver flag was the only solution before the 
>> various scalar types existed. I'd like to suggest that the discussion already 
>> occurred some time ago and has concluded in favor of the scalar types. 
>> Downcasting should be explicit.
>>
>> However, whether or not float32 arrays operated with Python float scalars give 
>> float32 or float64 arrays is tangential to my question. Does anyone actually 
>> think that a Python float operated with a boolean array should give a float32 
>> result? Must we *up*cast a boolean array to float64 to preserve the precision of 
>> the scalar?
>>
>>  
>>
>>     
> The first basic rule is that scalars don't control the precision of the 
> output when doing mixed-type calculations *except* when they are of a 
> fundamentally different kind. 
>
> Then (if a different kind of scalar is used), the rule is that the 
> arrays will be upcast to the "lowest" precision in the group to preserve 
> overall precision.   So, when a bool is combined with a "float" kind of 
> scalar, the result is float32 because that preserves precision of the 
> bool.  Remember it is array precision that takes precedence over scalars 
> in mixed type array-scalar operations.
>
> This is the rule.  I agree that this rule is probably flawed in certain 
> circumstances.
>   
I think any rule will be flawed in certain circumstances. This 
particular rule has the advantage of being relatively straightforward 
and the circumstances that I can think of where it could cause problems 
are relatively limited and relatively easy to address. The obvious 
"fixes" to this rule that I  have I've thought of all have problems that 
are as bad or worse as the current rule and have the added disadvantage 
of being more complicated.

At the very least, any replacement rule should get some serious 
discussion here before being implemented. We should particularly solicit 
the input of numarray users since that package had more infrastructure 
in place to support the use of lower precision arrays.

> So, what should be done about it at this point?  Do you think a change 
> is acceptable for 1.0.1 or does it need to wait a year until 1.1?
>   
Unless someone can come up with a convincingly better solution, I say 
leave things as is indefinitely.

-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