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 a
On Tue, Apr 28, 2015 at 7:00 AM, Benjamin Root 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 not what I
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
2015-04-28 4:59 GMT+02:00 Neil Girdhar :
> 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 Python's ast module.
On Mon, 27 Apr 2015 19:35:51 -0400
Neil Girdhar 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 terribly obsolete (t