Re: [Numpy-discussion] Back to numexpr

[Ivan V. i B. <iv...@ca...>]

En/na Tim Hochberg ha escrit::

> Francesc Altet wrote:
> [...]
>>Uh, I'm afraid that yes. In PyTables, int64, while being a bit bizarre =
for=20
>>some users (specially in 32-bit platforms), is a type with the same rig=
hts=20
>>than the others and we would like to give support for it in numexpr. In=
 fact,=20
>>Ivan Vilata already has implemented this suport in our local copy of nu=
mexpr,=20
>>so perhaps (I say perhaps because we are in the middle of a big project=
 now=20
>>and are a bit scarce of time resources) we can provide the patch agains=
t the=20
>>latest version of David for your consideration. With this we can solve =
the=20
>>problem with int64 support in 32-bit platforms (although addmittedly, t=
he VM=20
>>gets a bit more complicated, I really think that this is worth the effo=
rt)
>=20
> In addition to complexity, I worry that we'll overflow the code cache a=
t=20
> some point and slow everything down. To be honest I have no idea at wha=
t=20
> point that is likely to happen, but I know they worry about it with the=
=20
> Python interpreter mainloop. Also, it becomes much, much slower to=20
> compile past a certain number of case statements under VC7, not sure=20
> why. That's mostly my problem though.
> [...]

Hi!  For your information, the addition of separate, predictably-sized
int (int32) and long (int64) types to numexpr was roughly as complicated
as the addition of boolean types, so maybe the increase of complexity
isn't that important (but I recognise I don't know the effect on the
final size of the VM).

As soon as I have time (and a SVN version of numexpr which passes the
tests ;) ) I will try to merge back the changes and send a patch to the
list.  Thanks for your patience! :)

::

	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
	       C=C3=A1rabos Coop. V.  V  V   Enjoy Data
	                          ""