On Tue, Apr 28, 2015 at 7:00 AM, Benjamin Root ben.r...@ou.edu wrote:
I have a need to have a numpy array of 17 byte (more specifically, at
least 147 bits) values that I would be doing some bit twiddling on. I have
found that doing a dtype of i17 yields a dtype of int32, which is
completely
I have a need to have a numpy array of 17 byte (more specifically, at least
147 bits) values that I would be doing some bit twiddling on. I have found
that doing a dtype of i17 yields a dtype of int32, which is completely
not what I intended. Doing 'u17' gets an data type not understood. I have
Yeah, I am not seeing any way around it at the moment. I guess I will have
to use the bitarray package for now. I was hoping for some fast per-element
processing, but at the moment, I guess I will have to sacrifice that just
to have something that worked correctly.
Ben Root
On Tue, Apr 28, 2015
On Mon, 27 Apr 2015 19:35:51 -0400
Neil Girdhar mistersh...@gmail.com wrote:
Also, FYI: http://numba.pydata.org/numba-doc/0.6/doc/modules/transforms.html
It appears that numba does get the ast similar to pyautodiff and only get
the ast from source code as a fallback?
That documentation is
2015-04-28 4:59 GMT+02:00 Neil Girdhar mistersh...@gmail.com:
I don't think I'm asking for so much. Somewhere inside numexpr it builds
an AST of its own, which it converts into the optimized code. It would be
more useful to me if that AST were in the same format as the one returned
by
