Disagreement in size of "float" between blaze and numpy about blaze HOT 6 CLOSED

+1 to your first option. I'm inclined to exclude "float" and "float_" from the datashape grammar and from the blaze namespace. People coming from the C/C++ world will likely expect it to be 32-bit, and people coming from Python will likely expect it to match Python's float, 64-bit.

One idea would be to construct dshape("float64") when people say dshape(float), and dshape('float32") when people say dshape(np.float_), to match the sizes of the input type. This raises the question of whether blaze should allow numpy or python types where it is expecting a measure dshape object?

from blaze.

I just checked the documentation of Blaze, and it says that "float" should be "float64" (so, the second option). But I'm also +1 for the first option and forcing people to be explicit about it.

Also, I don't think there is a difference between Python float and np.float_. On my system:

>>> print np.float_
<type 'numpy.float64'>

from blaze.

It is a bit confusing in numpy, all of the following lead to float64:

In [2]: np.float_
Out[2]: numpy.float64

In [3]: np.double
Out[3]: numpy.float64

In [4]: np.float
Out[4]: float

from blaze.

In my opinion, in blaze types without an explicit bit width should only exist as aliases to ones with explicit bit width. Otherwise it has implications when persistence is taken into account. In fact, float is not that bad, as it maps always in the same bit width. But 'int' is a different issue.

By alias I mean something that gets accepted as input but translated to a real dtype.
IMO: this does not make sense in current blaze:

In [10]: blz.dshape('float')
Out[10]: dshape("float")

In [11]: blz.dshape('float32')
Out[11]: dshape("float32")

In [12]: blz.dshape('float64')
Out[12]: dshape("float64")

In [13]: blz.dshape('float') == blz.dshape('float32')
Out[13]: False

In [14]: blz.dshape('float') == blz.dshape('float64')
Out[14]: False

It should either:

In [10]: blz.dshape('float')
Out[10]: dshape("float32")

or

In [10]: blz.dshape('float')
Out[10]: dshape("float64")

Same with 'int':

In [15]: blz.dshape('int')
Out[15]: dshape("int")

In [16]: blz.dshape('int32')
Out[16]: dshape("int32")

In [17]: blz.dshape('int64')
Out[17]: dshape("int64")

In [18]: blz.dshape('int') == blz.dshape('int32')
Out[18]: False

In [19]: blz.dshape('int') == blz.dshape('int64')
Out[19]: False

Either that or drop the unsized ones, as commented.

from blaze.

In my opinion, in blaze types without an explicit bit width should only exist as aliases to ones with explicit bit width.

This was the original model, i.e. int was aliased to int32. This changed at some point for reasons I don't recall. The current model is that these are all distinct unit types with meaning unto themselves, which I think doesn't reflect the semantics that any of us want:

int_       = CType('int')
long_      = CType('long')
bool_      = CType('bool')
float_     = CType('float')
double     = CType('double')
short      = CType('short')
char       = CType('char')

Coming from a C/LLVM perspective I'm for the notion that int should be an alias for int32 irregardless of platform integer. The same for the floating point aliases:

half    16-bit floating point value
float   32-bit floating point value
double  64-bit floating point value

from blaze.

This appears to be resolved.

from blaze.