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
First of all: Sorry, I duplicated the bug...
Things change when instead of a 'f' I write float:
sage: a=numpy.array([[1,2,3],[4,5,6],[7,8,9]],float)
sage: a
array([[ 1., 2., 3.],
[ 4., 5., 6.],
[ 7., 8., 9.]])
sage: matrix(a)
[1.0 2.0 3.0]
[4.0 5.0 6.0]
[7.0 8.0 9.0]
sage
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.
When I call matrix(a) and a is a numpy array, things do not work:
sage: import numpy
sage: a=numpy.array([[1,2,3],[4,5,6],[7,8,9]],'f')
sage: a
array([[ 1., 2., 3.],
[ 4., 5., 6.],
[ 7., 8., 9.]], dtype=float32)
sage: matrix(a)
[ 2.0047311 512.000122547 81
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]
[ 131072.0
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 relate
Dear Joel,
On Oct 9, 7:28 pm, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote:
> 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