[Numpy-discussion] CASTABLE flag

[Zachary Pincus]

Hello all,

In order to help make things regarding this casting issue more  
explicit, let me present the following table of potential "down-casts".

(Also, for the record, nobody is proposing automatic up-casting of  
any kind. The proposals on the table focus on preventing some or all  
implicit down-casting.)

(1) complex -> anything else:
Data is lost wholesale.

(2) large float -> smaller float (also large complex -> smaller  
complex):
Precision is lost.

(3) float -> integer:
Precision is lost, to a much greater degree than (2).

(4) large integer -> smaller integer (also signed/unsigned conversions):
Data gets lost/mangled/wrapped around.

The original requests for exceptions to be raised focused on case  
(1), where it is most clear that loss-of-data is happening in a way  
that is unlikely to be intentional.

Robert Kern suggested that exceptions might be raised for cases (1)  
and (3), which are cross-kind casts, but not for within-kind  
conversions like (2) and (4). However, I personally don't think that  
down-converting from float to int is any more or less fraught than  
converting from int32 to int8: if you need a warning/exception in one  
case, you'd need it in the rest. Moreover, there's the principle of  
least surprise, which would suggest that complex rules for when  
exceptions get raised based on the kind of conversion being made is  
just asking for trouble.

So, as a poll, if you are in favor of exceptions instead of automatic  
down-conversion, where do you draw the line? What causes an error?  
Robert seemed to be in favor of (1) and (3). Anne seemed to think  
that only (1) was problematic enough to worry about. I am personally  
cool toward the exceptions, but I think that case (4) is just as  
"bad" as case (3) in terms of data-loss, though I agree that case (1)  
seems the worst (and I don't really find any of them particularly  
bad, though case (1) is something of an oddity for newcomers, I agree.)

Finally, if people really want these sort of warnings, I would  
suggest that they be rolled into the get/setoptions mechanism, so  
that there's a fine-grained mechanism for turning them to off/warn/ 
raise exception.

Zach