Tue, 12 Oct 2010 13:55:27 -0600, Vincent Davis wrote:
It's meant for easy inclusion in other projects (if they agree with the
worfklow it presents), here it is for example rendered with the urls
pointing to ipython repos:
Hope something like this gets converted/done for Numpy.
Sat, 16 Oct 2010 23:23:46 -0600, Charles R Harris wrote:
[clip]
And I just managed the same result on a push to maintenance/1.5.x :-/
But I know how it happened, I cherry picked from master for a backport
before updating the 1.5.x branch from github. In Retrospect I probably
should have reset
Mon, 18 Oct 2010 09:07:42 -0400, Ian Goodfellow wrote:
To do a standard installation, run
sudo python setup.py install
from inside the numpy directory
Preferably,
sudo python setup.py install --prefix=/usr/local
and then you don't mess up your package manager.
Pauli
Mon, 18 Oct 2010 12:20:00 +0300, Pearu Peterson wrote:
[clip]
I see that there are long discussions in numpy ml about the git usage
and mis usage. I wonder whether this has converged to something that
could be used as reference for git beginners like me.
I think there's agreement on what we
Tue, 19 Oct 2010 21:26:38 +1300, Alex Ter-Sarkissov wrote:
thanks, this didn't seem to work. I get a whole range of errors, most
importantly
SystemError: Cannot compiler 'Python.h'. Perhaps you need to install
python-dev|python-devel.
I think you should do sudo apt-get install python-dev
reduced to a single
boolean.
You can also initialize
dimensions = shape(self) + (-1,)
and let PyArray_Newshape do the size calculation for you.
I guess it's best to not initialize structures directly, if there is some
suspicion that obscure compilers don't like it.
--
Pauli Virtanen
Wed, 20 Oct 2010 19:21:15 +0200, Nils Wagner wrote:
test_duplicate_field_names_assign
(test_regression.TestRegression) ...
Works for me. This is exactly the crash that the test tests, so perhaps
you have an incomplete rebuild. I'd try rm -rf build and rebuild.
--
Pauli Virtanen
, but apparently not. So you're right
that the correct place to do the shape check is on the dtype level.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
(on subdtype): If a field whose dtype object has this attribute is
retrieved, then the extra dimensions implied by the shape are tacked on to
the end of the retrieved array.
IMO, it should be possible to change this with little prior notice.
A can of worms :)
--
Pauli Virtanen
a report. Be sure to include simple test case (like the one you
attached).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
, though.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
])
PyArray_OrderConverter interprets `None` as A. However, this problem is
already there with `reshape`, so this patch looks good to me -- fixing
OrderConverter is a separate job.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
() does return when it sees the first True, but this is not full
short-circuiting.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
context.
Note also that at least Python's struct module (mis-?)uses __index__()
for casting inputs to integers.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
miss).
That's why I said that __getattr__ would perhaps work better.
So do you want me to try out an implementation and supply a patch? If
so, where should I send the patch?
See here:
http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html
--
Pauli Virtanen
pe, 2010-10-29 kello 12:48 +0200, Francesc Alted kirjoitti:
A Friday 29 October 2010 12:18:20 Pauli Virtanen escrigué:
Fri, 29 Oct 2010 09:54:23 +0200, Francesc Alted wrote:
[clip]
My vote is +1 for deprecating ``array([scalar])`` as a scalar index
for NumPy 2.0.
I'd be -0
slots are consulted before falling back to tp_getattro. If tp_getattro is
consulted first, then implementing it will lead to a performance hit.
I'd probably be +0 on providing recarray-like functionality on ordinary
ndarrays, if it can be done without (significant) performance issues.
--
Pauli
want to chip in:
x = np.zeros((2, 3), dtype=[('a', 'f8', (4,))])
x.T['a'].shape
(4, 3, 2)
x.T.copy()['a'].shape
(3, 2, 4)
Fortran-order is special-cased. We might want to change this to work like
so:
x.T['a'].shape
(3, 2, 4)
which is more predictable.
--
Pauli Virtanen
Wed, 03 Nov 2010 12:39:08 +0100, Vincent Schut wrote:
[clip]
Btw, should I file a bug on this?
One can argue that mean() and sum() should use a numerically stabler
algorithm, so yes, a bug can be filed if there is not yet one already.
--
Pauli Virtanen
/doc/numpy/dev/gitwash/patching.html
(iii) File a bug ticket.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thu, 04 Nov 2010 13:33:48 +0100, Francesc Alted wrote:
[clip]
To solve this, just apply byteswap once more:
a = np.int32(300)
a.byteswap().byteswap()
300
and you are done.
Or directly specify big-endian byte order when reading
fromfile(fp, 'i4', 3)
to github?
That would require more work on the Trac-Git integration front:
http://github.com/pv/githubsimple-trac
It might be more cost-effective to just use links to the Github web
interface.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Mon, 08 Nov 2010 19:31:31 +0100, Pauli Virtanen wrote:
ma, 2010-11-08 kello 18:56 +0100, LittleBigBrain kirjoitti:
In my system '' is the native byte-order, but unless I change the
byte-order label to '=', it won't work in linalg sub-module, but in
others works OK. I am not sure whether
Mon, 08 Nov 2010 17:00:34 -0200, Renato Fabbri wrote:
[clip: offtopic]
Please post this on the scipy-user list instead, it's more suitable for
misc questions.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
, but my understanding
is that numpy.linalg.inv actually solves Ax = I instead of literally
calculating the inverse of A. It would be great if I can get some
intuition about this.
That's the same thing as computing the inverse matrix.
--
Pauli Virtanen
in lapack_lite.
numpy.linalg.pinv OTOH does use SVD, but that's probably more costly.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
in Numpy is the straightforward one, without SIMD etc.
For large datasets, scipy.signal.fftconvolve should be faster.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy
branch
onto the current Git history -- currently, it's still based on Git-SVN.
Re-grafting would make incremental merging and tracking easier. Luckily,
this is easy to do thanks to Git's data model (I have a script for it),
and I believe it could be useful to do it ASAP.
--
Pauli Virtanen
On Thu, 11 Nov 2010 21:08:55 +, Pauli Virtanen wrote:
[clip]
The first step I would like to see is to re-graft the teoliphant branch
onto the current Git history -- currently, it's still based on Git-SVN.
Re-grafting would make incremental merging and tracking easier. Luckily,
this is easy
development branches at all in
the main repository.
A repository like
github.com/numpy/numpy-refactor
might be a better solution, and also give visibility.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
already.
Only scipy.weave is left to do. Otherwise, the test suite passes on
Python 3.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
://github.com/numpy/numpy-refactor
I can re-sync/scrap it later on if needed, depending on what the
refactoring team wants to do with it.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo
On Fri, 12 Nov 2010 14:37:19 -0600, Jason McCampbell wrote:
Sure:
https://github.com/numpy/numpy-refactor
I can re-sync/scrap it later on if needed, depending on what the
refactoring team wants to do with it.
Ok, maybe to clarify:
- That repo is already created,
- It contains your
Tue, 16 Nov 2010 09:41:04 -0500, Darren Dale wrote:
[clip]
That loop takes 0.33 seconds to execute, which is a good start. I need
some help converting this example to return an actual numpy array. Could
anyone please offer a suggestion?
Easiest way is probably to use ndarray buffers and resize
indirect calls.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
invokes any Numpy code.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, 20 Nov 2010 20:57:07 +, Pauli Virtanen wrote:
[clip]
There are more unnecessary merge commits in the git history.
I did a forced push to clear those up.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
On Tue, 23 Nov 2010 23:24:25 +0200, Stéfan van der Walt wrote:
2010/11/23 Stéfan van der Walt ste...@sun.ac.za:
On Tue, Nov 23, 2010 at 9:28 AM, Nils Wagner
nwag...@iam.uni-stuttgart.de wrote:
/data/home/nwagner/local/lib/python2.5/site-packages/numpy/lib/npyio.py,
line 66, in
to the
repository.
+0, I see no problems with this approach.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
the data, which should not be needed.
So yes, rewriting the function would be useful. The main difficulty in
the rewrite seems to be appropriate mask handling, but slicing is a
faster way to do that.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
or function called init_numpy in Numpy. What symbol
did you actually mean?
If you meant import_array(), it is a macro, which on Python 3 contains
a return NULL; statement and Python 2 a return;.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy
, the native-aligned mode that was discussed there is compatible
with what dtype(..., align=True) produces: Numpy aligns structs as given
by the maximum alignment of its fields.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion
Fri, 03 Dec 2010 09:23:15 -0800, Mark Wiebe wrote:
[clip]
- refuse to export buffers containing half floats
I think this is the better option, code that needs to do this can create
an int16 view for the time being.
That's also easier to implement -- no changes are needed :)
Pauli
:
refactor--- new-refactor
//
/libndarray--x
/ \
start-- master- new-master
--
Pauli Virtanen
___
NumPy
puts it. The point is that numpy.distutils
should be able to locate this library file for building extension modules
that depend on it.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
handling the thruth value of NaN correctly.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Keith Goodman wrote:
np.float64 is fast, just hoping someone had a C-API inline version of
np.float64() that is faster.
You're looking for PyArrayScalar_New and _ASSIGN.
See
https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/arrayscalars.h
Undocumented (bad), but AFAIK
Numpy binaries?)
What do you get if you replace `numpy.dot` with
`numpy.core.multiarray.dot` (which does not use BLAS)?
There's another thread on a similar issue here:
http://permalink.gmane.org/gmane.comp.python.scientific.user/27444
--
Pauli Virtanen
easily
redistributable binary packages for OSX.
If you really want to run Python 3, just build it yourself from the
sources.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy
On Thu, 13 Jan 2011 19:25:47 +, Pauli Virtanen wrote:
[clip]
If you really want to run Python 3, just build it yourself from the
sources.
Of course, this should have been: ..., just build Numpy from the
sources.
___
NumPy-Discussion mailing list
involving Numpy.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thu, 27 Jan 2011 11:40:00 +0100, Mark Bakker wrote:
[clip]
Not for large complex values:
In [85]: tanh(1000+0j)
Out[85]: (nan+nan*j)
Yep, it's a bug. Care to file a ticket?
The implementation is just sinh/cosh, which overflows.
The fix is to provide an asymptotic expansion (sgn Re z),
Thu, 27 Jan 2011 20:46:22 -0700, Charles R Harris wrote:
Mark Wiebe has proposed making the master branch backward compatible
with 1.5. The argument for doing this is that 1) removing the new bits
for new releases is a chore as the refactor schedule slips and 2) the
new ABI isn't settled and
Fri, 28 Jan 2011 11:25:19 +0100, Mark Bakker wrote:
I'll file a ticket.
Incidentally, if tanh(z) is simply programmed as
(1.0 - exp(-2.0*z)) / (1.0 + exp(-2.0*z))
This will overflow as z - -\infty. The solution is probably to use a
different expression for Re(z) 0, and to check how other
Fri, 28 Jan 2011 12:57:18 +0100, Mark Bakker wrote:
Follow up:
The behavior is correct for real argument:
[clip]
So maybe we should look there for good logic,
In the real case you can do if (abs(z) cutoff) return sgn(z),
which is not the right thing to do for complex numbers.
Anyway,
` is indeed the correct result.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sun, 30 Jan 2011 18:35:56 +0100, Sturla Molden wrote:
Den 30.01.2011 17:04, skrev Charles R Harris:
The v.H is the old, incorrect, version of the documentation. The
current documentation is correct.
!!!
Was it just the documentation that was false, or did SVD return v.H
before?
The
Hi,
The master branch did not build today on Python 3. Please make sure that
your code works correctly also on Python 3, before pushing it.
***
I mostly fixed the stuff for now, mostly just the usual bytes vs unicode.
On Python 3, the tests however give two non-obvious failures -- I'm
On Tue, 01 Feb 2011 16:42:04 -0800, Mark Wiebe wrote:
[clip: problem 1]
This looks like it's a problem in new_iterator_pywrap.c, in
PySequenceMethods npyiter_as_sequence. I got this error when trying to
slice before implementing the slot sq_slice. I copied the definition
from
On Tue, 01 Feb 2011 16:42:04 -0800, Mark Wiebe wrote:
[clip]
Sorry about that, I had hoped to be able to use the build-bot to
test/diagnose the issues, but it's down and I didn't pursue it further.
Hmm, I see Github's SVN gateway is broken again. Perhaps it could be
possible to make it work
Tue, 08 Feb 2011 15:24:10 +, EMMEL Thomas wrote:
[clip]
n = 100 # for test otherwise ~30
a1 = reshape(zeros(3*n).astype(float), (n,3))
a2 = zeros(n).astype(int)
for indices, data in [...]:
#data = array((1.,2.,3.))
#indices = (1,5,60)
for index in indices:
Tue, 08 Feb 2011 11:35:12 -0700, Charles R Harris wrote:
Permission to close ticket for Mark Wiebe
I don't know who handles these permissions, I didn't see a way to do it
myself.
Granted. (You'd need a shell account to do these changes.)
--
Pauli Virtanen
://projects.scipy.org/numpy/ticket/1739
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thu, 10 Feb 2011 14:30:37 +0900, David wrote:
[clip]
Following recent release of waf 1.6 and its adoption by the samba
project, as well as my own work on integrating waf and bento, I have
spent some time to build numpy with it. Although this is experimental,
it should be possible for people to
within the ufunc
framework?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
cases for sizeof(item) strides. Think how to add them cleanly.
3. If it's in the outer iteration, try to think how to make it faster.
This will be a more messy problem to solve.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion
to a separate source
package? That wouldn't need to get into main, as it's of use only to
developers.
Or, using prebuilt HTML documentation supplied by upstream or pre-built
by Ubuntu devs?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion
Thu, 10 Feb 2011 20:49:28 +, Pauli Virtanen wrote:
[clip]
1. Check first if the bottleneck is in the inner reduction loop
(function DOUBLE_add in loops.c.src:712) or in the outer iteration
(function PyUFunc_ReductionOp in ufunc_object.c:2781).
2. If it's in the inner loop, some
/numpy-1.5.x/numpy-html.zip
as numpy-doc-1.5.1.zip (or .tar.gz) on sourceforge?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Fri, 11 Feb 2011 17:07:25 +0100, Pauli Virtanen wrote:
Fri, 11 Feb 2011 10:40:57 -0500, Barry Warsaw wrote: [clip]
Neither will be acceptable I think. Prebuilt by upstream won't fly for
Debian because they'd want the source and build process, and I don't
see a feasible way for them
and
matplotlib in universe.)
I don't see other solutions apart from creating a separate source package
from the contents of numpy/doc/*. However, I don't see very many reasons
why we (as the Numpy upstream) should make this split, and why the
Debian/Ubuntu packagers could not do it.
--
Pauli Virtanen
Fri, 11 Feb 2011 12:06:42 -0600, Bruce Southey wrote:
[clip: numpy/doc/*]
But that directory is still not sufficient for having the documentation
alone.
It is, given a build-time dependency on the main Numpy package.
Pauli
___
On Mon, 14 Feb 2011 17:21:07 -0500, Bryan Woods wrote:
[clip]
roughness = np.array(landcover.shape,dtype='f')
np.zeros(landcover.shape, dtype='f')
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
that off until Natty+1.
The Scipy releases in general are not fully backward API compatible
(until 1.0 is reached), and this applies also to 0.8.0 vs. 0.9.0. So I
guess the timing is pretty tight...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
bytes ?
Cache lines are typically much smaller, 16-512 bytes.
In this specific case, since the stride of the `i` loop is only
2*sizeof(float) = 16 bytes cache line size, threads running with
different `i` tend to write to the same cache lines.
--
Pauli Virtanen
On Mon, 21 Feb 2011 15:09:05 -0500, Skipper Seabold wrote:
[clip]
Should I file a ticket?
Yes.
[clip]
PS. Is there an incompatibility of numpy 1.5.1 and numpy 1.6.0 trunk for
packages that depend on numpy?
It should be binary compatible.
--
Pauli Virtanen
On Mon, 21 Feb 2011 16:03:43 -0500, Skipper Seabold wrote:
[clip]
I had to reinstall scipy, matplotlib, etc. when I changed from 1.6.0
back to 1.5.1.
Yes, it should be backward compatible (you should be able use binaries
compiled with 1.5.1 on 1.6.0), but not forward compatible (binaries
On Tue, 22 Feb 2011 16:44:56 -0500, Alan G Isaac wrote:
[clip]
I don't believe the matrix multiplication results. Maybe I misunderstand
them ...
t = timeit.Timer(np.dot(A,B),import numpy as
np;N=1500;A=np.random.random((N,N));B=np.random.random((N,N)))
print
?
Another possible reason is that Numpy was installed wrong (as the
numpy.__config__ module is apparently missing). Numpy needs to be
installed via python setup.py install, manually copying the numpy
directory is not enough.
--
Pauli Virtanen
___
NumPy
Thu, 24 Feb 2011 16:47:14 +, Pauli Virtanen wrote:
Another possible reason is that Numpy was installed wrong (as the
numpy.__config__ module is apparently missing). Numpy needs to be
installed via python setup.py install, manually copying the numpy
directory is not enough
that there are valid values in the interior of the domain
which plot properly.
I can't find anything in the numpy documentation that addresses this
type of missing value. Has anyone dealt with this before?
Here you go:
http://docs.scipy.org/doc/numpy/reference/maskedarray.html
--
Pauli
Mon, 28 Feb 2011 16:50:59 +0800, Ralf Gommers wrote:
On Mon, Feb 28, 2011 at 4:00 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
The other thing that needs to be done is some (more) documentation of
new features. Einsum and the new iterator seem to be well documented,
but not described
On Fri, 04 Mar 2011 22:58:14 -0600, Benjamin Root wrote:
I recently had to fix an example in matplotlib where there was a 1xN
array being assigned to a 1-D slice of a numpy array. It used to work,
but it now doesn't. I don't know if this was intended or not, though.
Probably not -- please
Mon, 07 Mar 2011 11:03:17 +0800, Ralf Gommers wrote:
[clip]
If anyone has new deprecations they want to put in for 1.6, discussing
them now would be good. I found one item in Trac, #1543. The proposal in
the ticket is to deprecate assert_almost_equal because it is quite badly
behaved. This
precision via decimals= which is somewhat
clumsy for numerical work.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
, this is quite useful for special functions,
whose range of values typically vary widely, but for which one still
wants to have accuracy which is as good as possible.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
Cython versions? If so, some of the existing code should not have this
problem.
However, the size of PyArray_Descr does not seem to have changed between
1.5.1 and the Git master. So I'm not sure why you see this error...
--
Pauli Virtanen
___
NumPy
were compiled
against Numpy 1.5? If so, the same errors should come up with Numpy
1.5.x.
In any case, it seems to me that since there have been no changes in the
dtype struct contents since 1.5, the Git master should behave exactly the
same as 1.5 in this respect.
--
Pauli Virtanen
looking into. I don't immediately see how it can
happen, and agree that it shouldn't (AFAIK, there are no changes in 1.6
that require additions to the structs).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
((5,5,5)).transpose(1,2,0)).strides
(200, 40, 8)
After:
np.sin(np.zeros((5,5,5)).transpose(1,2,0)).strides
(40, 8, 200)
This gets +1 from me; the drawbacks to this are mostly in code that
makes too much assumptions and makes no checks.
--
Pauli Virtanen
Tue, 08 Mar 2011 00:12:35 -0800, Robert Bradshaw wrote:
[clip]
Unfortunately, I don't think anyone's actively working on it right now.
It's probably a superficial fix for someone who knows NumPy and Cython
decently well, but I have no idea myself (not having looked that deeply
into it.) Does
Thu, 10 Mar 2011 15:23:59 +0800, Ralf Gommers wrote:
[clip]
x = np.array([1.5])
x.view(int)
array([4609434218613702656])
Yes, `view` is meant to do exactly that. Use `astype` if you want a type
cast.
Pauli
___
NumPy-Discussion mailing
On Fri, 11 Mar 2011 11:47:58 -0700, Charles R Harris wrote:
[clip]
What about views? Wouldn't it be easier to write another object wrapping
an ndarray?
I think the buffer interfaces and all other various ways Numpy provides
exports for arrays make keeping tabs on modification impossible to do
Tue, 15 Mar 2011 10:06:09 -0700, Matthew Brett wrote:
Sorry to ask, and I ask partly because I'm in the middle of a py3k port,
but is this the right fix to this problem? I was confused by the
presence of the old PyString_AsString function.
It's not a correct fix. The original code seems also
Tue, 15 Mar 2011 10:23:35 -0700, Matthew Brett wrote:
[clip]
OK - I realize I'm being very lazy here but, do you mean:
PyErr_Format(PyExc_ValueError,
field named %s not found.,
PyString_AsString(PyObject_Repr(index)));
The
,
so it's not clear if this can be fixed in the 1.x series.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, 23 Mar 2011 14:17:20 -0500, Bruce Southey wrote:
I can not figure out what is different between git and this version :-(
All the paths appear to be the same.
Further it continues onwards when I do: $python3.1 -m pdb setup.py build
I added these lines to the start of
201 - 300 of 995 matches
Mail list logo
