Fri, 13 Nov 2009 11:54:51 +0100, Robert Cimrman wrote:
I think this is a bug:
In [16]: np.allclose([1.0, 1.0], [1.1], rtol=0.1, atol=0.0)
Out[16]: True
It's broadcasting. I'm not sure it is a bug:
np.allclose([1.0, 1.0], [1.1, 1.1, 1.1], rtol=0.1, atol=0.0)
False
--
Pauli Virtanen
.
Out of curiosity, how are you handling the Matlab RTLD_GLOBAL issue. Last
time [1] I did something similar, I had to hack around it in an ugly way.
.. [1] http://www.iki.fi/pav/software/pythoncall/index.html
--
Pauli Virtanen
___
NumPy-Discussion
you tried to run import numpy in the
embedded process -- loading multiarray.so would fail because of missing
symbols.
But if it worked for you without the hack, then it must have been changed
in the Matlab versions since then (and Pythoncall needs updating...).
--
Pauli Virtanen
is really a problem. You essentially can pass
data to Matlab only via Matlab's own interface -- CRT stuff like
ownership of pointers to allocated memory, file handles etc. typically
do not cross this boundary.
--
Pauli Virtanen
___
NumPy-Discussion mailing
?
I think I fixed this in r7751.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
la, 2009-11-21 kello 20:00 -0500, David Warde-Farley kirjoitti:
Guido posted a link to this on Twitter, it might be of interest to
people interested in the NumPy Python 3 transition:
http://dmalcolm.livejournal.com/3935.html
It's doubtful this is a magic bullet (at least, not yet)
su, 2009-11-22 kello 19:28 +0100, René Dudfield kirjoitti:
[clip]
I've been working on this too... see the previous py3k thread for
details of my plan. See http://github.com/illume/numpy3k/tree/work
for my (not very much) progress.
I don't have time for about a week to do any more work on
http://github.com/pv/numpy-work/tree/py3k
$ mkdir -p $PWD/dist/lib/python3.1/site-packages
$ python3 setup.py install --prefix=$PWD/dist
$ cd $PWD/dist/lib/python3.1/site-packages python3
Python 3.1.1+ (r311:74480, Oct 11 2009, 20:22:16)
[GCC 4.4.1] on linux2
Type help, copyright, credits or
Lähettäjä: David Cournapeau courn...@gmail.com
Päivämäärä: 23.11.2009 08:19
On Mon, Nov 23, 2009 at 2:35 PM, Pauli Virtanen p...@iki.fi wrote:
It might be nice to have this merged in at some point after 1.4.0 (after
the most obvious glaring bugs have been fixed), so that we could perhaps
start aiming
charlesr.har...@gmail.com
Päivämäärä: 23.11.2009 08:08
On Sun, Nov 22, 2009 at 10:35 PM, Pauli Virtanen p...@iki.fi wrote:
http://github.com/pv/numpy-work/tree/py3k
$ mkdir -p $PWD/dist/lib/python3.1/site-packages
$ python3 setup.py install --prefix=$PWD/dist
$ cd $PWD/dist/lib/python3.1/site-packages
wanted to breeze through and arrive as fast as possible at
something that can be imported and works for simple things, so I didn't
stop at anything that would take longer. I'll take a look at the rest
later on.
--
Pauli Virtanen
___
NumPy-Discussion
Mon, 23 Nov 2009 08:58:47 +0100, Sturla Molden wrote:
Pauli Virtanen skrev:
XXX: 3K: numpy.random is disabled for now, uses PyString_* XXX: 3K:
numpy.ma is disabled for now -- some issues
I thought numpy.random uses Cython? Is it just a matter of recompiling
the pyx-file?
The Cython file
://projects.scipy.org/numpy/ -- small bugs
like this tend to get lost and forgotten in mailing list traffic.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ke, 2009-11-25 kello 19:23 +0100, qu...@gmx.at kirjoitti:
[clip]
Could someone please investigate why correlate and especially
fftconvolve are orders of magnitude slower?
Read http://projects.scipy.org/numpy/ticket/1260
___
NumPy-Discussion mailing
strings, datetime tuple, and any other protocol strings
Bytes. User can pass in Unicode, but it's converted using
UTF8 codec.
This will likely change repr() of various objects. Acceptable?
--
Pauli Virtanen
___
NumPy-Discussion
have to plot it yourself.
Indeed, the next two lines in the example use Matplotlib (ie. pylab) to
plot the histogram.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy
to, 2009-11-26 kello 17:37 -0700, Charles R Harris kirjoitti:
[clip]
I'm not clear on your recommendation here, is it that we should use
bytes, with unicode converted to UTF8?
The point is that I don't think we can just decide to use Unicode or
Bytes in all places where PyString was used
pe, 2009-11-27 kello 18:30 +0900, David Cournapeau kirjoitti:
Pauli Virtanen wrote:
By the way, should I commit this stuff (after factoring the commits to
logical chunks) to SVN?
I would prefer getting at least one py3 buildbot before doing anything
significant,
I can add it to mine:
http
pe, 2009-11-27 kello 11:17 +0100, Francesc Alted kirjoitti:
A Friday 27 November 2009 10:47:53 Pauli Virtanen escrigué:
1) For 'S' dtype, I believe we use Bytes for the raw data and the
interface.
Maybe we want to introduce a separate bytes dtype that's an alias
for 'S
pe, 2009-11-27 kello 13:23 +0100, René Dudfield kirjoitti:
[clip]
I imagine dtype 'S' and 'U' need more clarification. As it misses the
concept of encodings it seems? Currently, S appears to mean 8bit
characters no encoding, and U appears to mean 16bit characters no
encoding? Or are some
in making a bytes_ scalar type available for
Python2. In fact, it would be useful for making upgrading to Py3 easier.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
are not actually used anywhere else than in
the descriptor user interface, so from an implementation POV Unicode is
not any harder.
[clip]
Pauli Virtanen wrote:
'U'
is same as Python 3 unicode and probably in same internal representation
(need to check). Neither is associated with encoding info.
Isn't
that the Numpy array flags (which the macros check) are
not always up-to-date wrt. the stride information?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
pe, 2009-12-04 kello 11:19 +0100, Chris Colbert kirjoitti:
Why cant the divisor constant just be made an optional kwarg that
defaults to zero?
It already is an optional kwarg that defaults to zero.
Cheers,
--
Pauli Virtanen
___
NumPy-Discussion
concerns probably some code of his own.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
I'd like to commit my Py3 Numpy branch to SVN trunk soon:
http://github.com/pv/numpy-work/commits/py3k
For an overview, check the notes:
http://github.com/pv/numpy-work/blob/py3k/doc/Py3K.txt
None of the changes should affect behavior on Py2. The test status
currently is:
lapack_litemodule.c in the build?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
su, 2009-12-06 kello 12:54 +0900, David Cournapeau kirjoitti:
On Sun, Dec 6, 2009 at 9:41 AM, Pauli Virtanen p...@iki.fi wrote:
Hi,
I'd like to commit my Py3 Numpy branch to SVN trunk soon:
http://github.com/pv/numpy-work/commits/py3k
Awesome - I think we should merge
su, 2009-12-06 kello 15:11 +0100, Gael Varoquaux kirjoitti:
On Sun, Dec 06, 2009 at 04:07:16PM +0200, Pauli Virtanen wrote:
[clip]
I find it a bit strange that a '.x' release induces so much breakage,
and I am afraid that it won't be popular amongst our users.
Well, there's still a lot
only after most of Numpy works on Py3.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
py3k branch from SVN, cf. doc/Py3K.txt in Numpy's SVN.
3) Run python3 setup.py install --user in a dir containing Numpy's SVN
trunk
Of course, since many thing are not finished yet for Py3, it's probable
you run into problems when trying to run software using Numpy on Py3.
--
Pauli Virtanen
should be filed for this, I believe.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ma, 2009-12-07 kello 09:17 -0500, Michael Droettboom kirjoitti:
Also noticed that
http://docs.scipy.org/numpy/docs/numpy.core.defchararray.chararray/
[clip]
I suspect fixing this at the implementation level may be too
difficult/dangerous, but for documentation purposes, is there a way to
ma, 2009-12-07 kello 09:12 -0500, Michael Droettboom kirjoitti:
We need character arrays for the astro people. I assume these will be
byte arrays. Maybe Michael will weigh in here.
I can't find in the thread where removing byte arrays (meaning arrays of
fixed-length non-unicode strings)
ma, 2009-12-07 kello 09:50 -0500, Michael Droettboom kirjoitti:
Pauli Virtanen wrote:
[clip]
The character 'B' is already by unsigned bytes -- I wonder if it's easy
to support 'B123' and plain 'B' at the same time, or whether we have to
pick a different letter for byte strings. 'y' would
ma, 2009-12-07 kello 22:36 +0100, Nils Wagner kirjoitti:
numpy.__version__
'1.5.0.dev7980'
FAIL: test_buffer_hashlib (test_regression.TestRegression)
Thx, fixed. I forgot about defaulting to int64.
Pauli
___
NumPy-Discussion mailing
to Python's sys.stderr instead?
Also, some code that worked OK before would now start to spit out extra
warnings, which is not so nice.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
. Because of the datetime
branch merge, a new field was added to ArrayDescr -- and this breaks
previously compiled Cython modules.
I guess this should be mentioned in the release notes. We'll probably be
doing it again in 1.5.0...
--
Pauli Virtanen
ti, 2009-12-08 kello 12:12 -0500, Darren Dale kirjoitti:
On Tue, Dec 8, 2009 at 12:02 PM, Pauli Virtanen pav...@iki.fi wrote:
Sun, 06 Dec 2009 14:53:58 +0100, Gael Varoquaux wrote:
I have a lot of code that has stopped working with my latest SVN pull to
numpy.
* Some compiled code
for this purpose.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
as the support
for PEP 3118 will not arrive before Numpy 1.5.0, and I don't see any
reason why we would be removing support for the array interface.
Perhaps Py3 is a different ball game, but even there, there is no real
reason to remove the support, so I don't think we should do it.
--
Pauli Virtanen
-- not nice.)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
discussing this issue too :-) ).
Yes. We can even make it a PendingDeprecationWarning, when we become
convinced that this feature should go away in entirety.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org
(numpy.__file__))+/core/include'
which is simple to pop in e.g. in a Makefile.
I think this is a price worth paying for supporting multiple versions,
and is in any case required on non-Ubuntu platforms.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
to, 2009-12-10 kello 10:18 -0600, Robert Kern kirjoitti:
On Thu, Dec 10, 2009 at 04:24, Pauli Virtanen pav...@iki.fi wrote:
Thu, 10 Dec 2009 09:54:32 +0100, Dag Sverre Seljebotn wrote:
[clip]
At this point I want to remind us about Charles Harris' very workable
proposal: Raise a warning
:)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
://svn.scipy.org/svn/numpy/branches/1.4.x
Does it fail too on Python 2.7? There are very few code changes since
1.4.x on the path that the test exercises.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
raising any warnings.)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
macro for that reason.
Actually, we have already have a separate
NumpyOS_ascii_strtod
function that should be used instead of PyOS_ascii_strtod (which,
historically, has not satisfier our requirements). So I believe
PyOS_ascii_strtod is used in only a single location in Numpy.
--
Pauli
Wed, 16 Dec 2009 02:09:45 +, Chris wrote:
Building a current checkout of scipy on OSX 10.6 fails when trying to
compile scipy.special.lambertw, giving the message:
Warning: No configuration returned, assuming unavailable.
The full failure is here:
.
A dedicated function could be nice here.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
with appropriate GIL-acquiring wrappers
plus if (PyErr_Occurred()) PyErr_Clear();
Anyway, how malformed input is handled is currently not so well
specified anyway, so this part requires further fixes.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
ti, 2009-12-22 kello 14:32 -0700, Charles R Harris kirjoitti:
[clip]
Could you expand a bit on this? There are several places where
PyErr_Occurred are called and I am wondering if there is a problem. In
fact, I moved one such check and a segfault went away, which made me
suspicious...
I think
ti, 2009-12-22 kello 15:28 -0700, Charles R Harris kirjoitti: [clip]
But what about the GIL? That's what I'm curious about. Do we need to
hold the GIL to check and clear and error? If so, there are other
places where this will matter. I was under the impression that each
thread had it's own
consisting only of spaces must match at
least one whitespace.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
to, 2010-01-07 kello 17:21 -0800, Christopher Barker kirjoitti:
[clip]
if I have NumPyOS_ascii_ftolf right, it should return 0 if it doesn't
succesfully read a number. However, this looks like it sets the data in
*ip, even if the return value is zero.
It may also return EOF (== -1) when
-compatibility */ return
dtype-f-scanfunc(*fp, dptr, NULL, dtype);
}
This functions is IMHO where the fix should go; I believe it should do
something like
return (ret == 0 || ret == EOF) ? -1 : ret;
--
Pauli Virtanen
___
NumPy-Discussion
pe, 2010-01-08 kello 15:12 -0800, Christopher Barker kirjoitti:
1) optionally allow newlines to serve as a delimiter, so large tables
can be read.
I don't really like handling newlines specially. For instance, I could
have data like
1, 2, 3;
4, 5, 6;
7, 8, 9;
Allowing
ma, 2010-01-11 kello 16:11 -0800, Christopher Barker kirjoitti:
[clip]
If no conversion is performed, zero is returned and the value of nptr
is stored in the location referenced by endptr.
off do do some more testing, but I guess that means that those pointers
need to be checked after the
ti, 2010-01-12 kello 12:51 -0500, Pierre GM kirjoitti:
[clip]
a = numpy.ma.MaskedArray([[1,2,3],[4,5,6]])
numpy.ma.sum(a, 1)
Traceback (most recent call last):
File stdin, line 1, in module
File
/usr/lib64/python2.5/site-packages/numpy-1.4.0-py2.5-linux-x86_64.egg/n
pe, 2010-01-15 kello 19:19 +0100, Nils Wagner kirjoitti:
[clip: issue with ipython]
Any idea ?
Maybe people on the Ipython mailing list would know best?
http://mail.scipy.org/mailman/listinfo/ipython-user
http://mail.scipy.org/mailman/listinfo/ipython-dev
--
Pauli Virtanen
])
print np.dot(x, V[:,1])
}}}
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
, I don't see great value in the invalid value encountered
reports that are appear every time a nan is generated...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
#sphinx.builders.qthelp.QtHelpBuilder
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
)
fig2fig.savefig(y1-time.png)
fig3fig.savefig(x1-time.png)
to save the respective figures.
There is a separate mailing list for Matplotlib-specific questions:
http://sourceforge.net/mail/?group_id=80706
--
Pauli Virtanen
___
NumPy
don't believe it will require ABI breakage.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
to, 2010-02-04 kello 12:09 -0700, Charles R Harris kirjoitti:
Realistically, I don't think Py3k will be ready by April-May. Fall is
probably doable and maybe there will be some things for a SOC person
to work on this summer.
Well, we have many components of Py3 support in place in the SVN
to, 2010-02-04 kello 15:28 -0600, Jeffery Kline kirjoitti:
I am experiencing unexpected behavior with the tofile() function. I
try to write two files with but distinct names, but only one of the
files is written.
The following code illustrates. For me, it only writes the file 't.bin'.
in the structs, and keep appending new members only at the end? The
Cython issue will probably be mostly resolved by new Cython releases
before the Numpy 2.0 would be out.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
] * 200
In [5]: i = np.arange(0, 200, 5)
In [8]: %timeit b[0] += 1
100 loops, best of 3: 260 ns per loop
In [20]: %timeit a[i] += 1
10 loops, best of 3: 71.2 ms per loop
In [25]: 71.2e-3/len(i)
Out[25]: 1.7801e-07
ie., 178 ns per element
--
Pauli Virtanen
-- the above code expands to
tmp = a[to_swap]
a[to_swap] = b[to_swap]
b[to_swap] = tmp
It'll work provided `to_swap` is such that `tmp` is not a view on `a`...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion
su, 2010-02-07 kello 10:39 -0500, Alan G Isaac kirjoitti:
[clip]
I thought that if `to_swap` is a boolean array that `a[to_swap]`
will always own its own data. Can that fail?
Ok, I don't think it can fail, then. But it's a slightly dangerous idiom
nevertheless...
--
Pauli Virtanen
.
***
But, should we make these functions available under some less
internal-ish namespace? There's numpy.rec at the least -- it could be
made a real module to pull in things from core and lib.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy
ti, 2010-02-09 kello 23:28 -0700, Charles R Harris kirjoitti:
[clip]
I'm curious if np.long the same as long?
np.long is long
I'm not sure if this was always so, since ticket #99's test cases try to
check that np.long works properly.
Pauli
to, 2010-02-11 kello 16:38 -0600, Travis Oliphant kirjoitti:
[clip]
Pauli, David, and Stephan, how opposed are you to numbering the next
release as NumPy 2.0 with no experimental tag or the like. If you
three could also agree. I could see my way through to supporting a
NumPy 2.0 release.
On Thu, Feb 11, 2010 at 18:23, Charles R Harris
charlesr.har...@gmail.com wrote:
What about python version? Do we want to bump that up from 2.4?
Only if it were *really* necessary for the Python 3 port. Otherwise, I
would resist the urge.
I don't think it's necessary for that.
--
Pauli
on our unit test coverage.
Finally, try to write some PEP 3118 using code, and check how it works. (You
can use python = 2.6 for this if you get numpy from the py3k branch.)
--
Pauli Virtanen
- Alkuperäinen viesti -
IMHO 2.0 should support python3.
That would be a major step
To see all available branches, do
git branch -r
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
for
me, but maybe it didn't find Atlas on my system for some reason.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
, but at the moment, it isn't
(patches welcome).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
su, 2010-02-14 kello 11:51 -0700, Charles R Harris kirjoitti:
[clip]
There are more - grep -r ob_type numpy/* - how do you want to go about
fixing these things?
self-ob_type is fine if `self` is a plain PyObject* and not a subclass
pointer.
The issue in changing all of them to Py_TYPE is that
ma, 2010-02-15 kello 21:07 +0200, Stéfan van der Walt kirjoitti:
[clip]
After your latest changes, numpy builds on OSX, although importing is
still broken:
from . import multiarray
ImportError:
dlopen(/Users/stefan/lib/python3.1/site-packages/numpy/core/multiarray.so,
2): Symbol not
ma, 2010-02-15 kello 21:41 +0200, Stéfan van der Walt kirjoitti:
[clip]
On Python 3.1, the numpymemoryview_init is a stub function that does
nothing. I guess this is another single-file compilation issue -- the
new file should be included in multiarraymodule_onefile.c. Should be
fixed now.
ma, 2010-02-15 kello 21:58 +0200, Pauli Virtanen kirjoitti:
[clip]
Program received signal SIGABRT, Aborted.
0x7fff84e1efe6 in __kill ()
(gdb) bt
#0 0x7fff84e1efe6 in __kill ()
#1 0x7fff84ebfe32 in abort ()
#2 0x0001000cd715 in Py_FatalError ()
#3
ma, 2010-02-15 kello 15:51 -0700, Charles R Harris kirjoitti:
[clip]
A lot of the remaining failures are of this sort:
x: array([b'pi', b'pi', b'pi', b'four', b'five'],
dtype='|S8')
y: array(['pi', 'pi', 'pi', 'four', 'five'],
dtype='U4')
This looks fixable by
the latest version of 2to3 and try again.
Try the latest head of the py3k branch, this should be worked around
there so that also earlier 2to3 work.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org
Hi,
Please remind me what platform you are running on. Also, please update
and re-run the tests, and check the output from
import numpy as np
from numpy.core.multiarray import memorysimpleview as memoryview
dt = [('a', np.int8), ('b', np.int16),
('c', np.int32), ('d', np.int64),
Hi,
The test suite passes now on Pythons 2.4 - 3.1. Further testing is very
welcome -- also on Python 2.x. Please check that your favourite software
still builds and works with SVN trunk Numpy.
Currently, Scipy has some known failures because of
(i) removed new= keyword in numpy.histogram
(ii)
pretty much the same as the CObject API. (Why the
name change?) We can probably #define PyCapsule_* compatibility defines
in npy_3kcompat.h that use PyCObject on 2.x, and use the real thing on
3.x.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
su, 2010-02-21 kello 20:17 +0200, Pauli Virtanen kirjoitti:
[clip]
The Capsule API seems pretty much the same as the CObject API. (Why the
name change?) We can probably #define PyCapsule_* compatibility defines
in npy_3kcompat.h that use PyCObject on 2.x, and use the real thing on
3.x.
Btw, I
su, 2010-02-21 kello 20:45 +0100, Dag Sverre Seljebotn kirjoitti:
Pauli Virtanen wrote:
[clip]
Currently, Scipy has some known failures because of
(i) removed new= keyword in numpy.histogram
(ii) Cython supports only native size/alignment PEP 3118 buffers, and
Numpy arrays are most
ma, 2010-02-22 kello 13:25 -0700, Charles R Harris kirjoitti:
[clip]
It looks like context is the new name for desc, so
that PyCObject_FromVoidPtrAndDesc can be implemented
as two calls.
I think it is a bit tricky to implement
ma, 2010-02-22 kello 13:53 -0700, Charles R Harris kirjoitti:
[clip]
I'm actually using #ifdefs for the whole change, no macros in the
include files. It hasn't been a lot of work so far. The c_api is
currently exported as a PyCObject, we might want to give it a name
when it is a PyCapsule. The
ma, 2010-02-22 kello 14:01 -0700, Charles R Harris kirjoitti:
On Mon, Feb 22, 2010 at 1:58 PM, Robert Kern robert.k...@gmail.com
wrote:
[clip]
Why? PyCObjects don't serialize at all. They would never show up in
a pickle to begin with.
So what happens to them? I'm not that familiar with
I don't think the situation is that bad with f2py. I suppose it will be enough
to erect unicode vs. Bytes barrier where the file i/o is done, and let f2py
work internally with unicode. Doesn't sound so bad, but I'd have to take a
closer look.
--
Pauli Virtanen
- Alkuperäinen viesti
ke, 2010-02-24 kello 17:33 +0900, David Cournapeau kirjoitti:
On Wed, Feb 24, 2010 at 5:19 PM, Pauli Virtanen p...@iki.fi wrote:
I don't think the situation is that bad with f2py. I suppose it will
be enough to erect unicode vs. Bytes barrier where the file i/o is
done, and let f2py work
ke, 2010-02-24 kello 18:04 +0900, David Cournapeau kirjoitti:
[clip]
P.S: is it expected that numpy cannot be built in-place correctly under
py3k?
Yes, unfortunately. 2to3 cannot really be run in-place, and I did not
want to engage distutils in a fight how to read the sources from a
different
:
return x
vect_func = numpy.frompyfunc(myfunc, 1, 1)
vect_func(a)
Note that frompyfunc always makes the vectorized function return object
arrays, which may not be what is wanted. Instead, one can use
numpy.vectorize.
--
Pauli Virtanen
___
NumPy
version
Or, rather, the Scipy binary is not compatible with the Numpy you built,
because of a differing size of the PyArray_Descr structure.
Recompilation of Scipy would fix this, but if the aim is to produce a
binary-compatible release, then something is still wrong.
--
Pauli Virtanen
), the
value is not hardcoded, so it's a compile-time issue.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
401 - 500 of 995 matches
Mail list logo
