Dear Joel,
On Oct 9, 7:28 pm, Joel B. Mohler [EMAIL PROTECTED] wrote:
snip
Hmm, that's a pretty big improvement over the SAGE time above. I suspect that
we will have to work a lot harder than either of our optimizations have so
far.
After slightly improving my MeatAxe extension type for
I figured that x was being treated differently in some ways, because I
always had to re-variabilize (is that a word?) x in a related
context. I didn't realize that it was symbolic all the way through,
though that would definitely be very inefficient.
However, I really hate using lambda or
sage: import numpy
sage: numpy.array([[1,2,3],[4,5,6],[7,8,9]],'f')
array([[ 1., 2., 3.],
[ 4., 5., 6.],
[ 7., 8., 9.]], dtype=float32)
sage: a=numpy.array([[1,2,3],[4,5,6],[7,8,9]],'f')
sage: matrix(a)
[ 2.0047311 512.000122547 8192.0019722]
[
Hello,
Are you running a 64-bit machine?
I looked at the code, and the problem seems to come from the fact that
it is doing a naive check on the type of the numpy array; it is
currently assuming that your float32 array is a float64 array which is
why you are getting the strange results you are.
Hello,
I've attached a patch that fixes the issues that you've mentioned. To
apply it, run hg_sage.patch('/path/to/856.patch') from SAGE, exit
SAGE, and then run ./sage -br .
There still is some work to be done with numpy support -- for example,
getting the numpy integer types to play well with
