Thanks for the explanation.
Chris Barker - NOAA Federal noaa.gov> writes:
> There has been a lot of discussion about casting on this list in the
> last couple months -- I suggest you peruse that discussion and see
> what conclusions it has lead to.
I'll look at it. My message to the ml followe
Hi,
I have noticed that numpy introduces some unexpected type casts, that are
in some cases problematic.
A very weird cast is
int + uint64 -> float
for instance, consider the following snippet:
import numpy as np
a=np.uint64(1)
a+1
-> 2.0
this cast is quite different from what other program
Partially fixed.
I was messing the row, column order. For some reason this was working in some
case. Now I've fixed it and it *always* works.
However, it is still slower than the cblas
cblas -> 0.69 sec
scipy blas -> 0.74 sec
Any clue why?
___
Num
... and it is not deterministic too...
About 1 time over 6 the code calling the scipy blas gives a completely wrong
result. How can this be?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discus
Hi,
following the excellent advice of V. Armando Sole, I have finally succeeded in
calling the blas routines shipped with scipy from cython.
I am doing this to avoid shipping an extra blas library for some project of
mine that uses scipy but has some things coded in cython for extra speed.
So fa
>
> from scipy.linalg.blas import fblas
> dgemm = fblas.dgemm._cpointer
> sgemm = fblas.sgemm._cpointer
>
OK, but this gives me a PyCObject. How do I make it a function pointer of the
correct type in cython?
Thanks again
Sergio
___
NumPy-Discussion
Hi,
I have a project that includes a cython script which in turn does some direct
access to a couple of cblas functions. This is necessary, since some matrix
multiplications need to be done inside a tight loop that gets called thousands
of times. Speedup wrt calling scipy.linalg.blas.cblas routine
