in the version I
> have (EPD), these also seem to make copies (though recent version seem
> to be fixed by looking at the source.)
I don't see many relevant changes in scipy.lib recently, so I'm
not sure what change you mean by the above.
--
Pauli Virtanen
On 2009-06-24, Robert Kern wrote:
[clip]
> Yes. The HOWTO_BUILD_DOCS.txt is unfortunately out of date.
So it is.
Rewritten.
--
Pauli Virtanen
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/nu
n
> fid.read(bytes) as the default, which simply returns as many items as could be
> read before the EOF was reached, including zero. An additional strict
> interface
> could be added (by keyword) for those who want an exception raised whenever
> the
> requested read count cou
dition.
Also, an assert makes the program crash on C-level, which is
clearly undesirable in a Python program as it cannot be handled.
Raising an error here seems to be the proper thing to do.
--
Pauli Virtanen
___
Numpy-discussion mailing list
Numpy-
program runs.
In this case, what is most likely actually taking up memory is the OS
buffering the data in memory, before writing it to disk. Linux has at
least some system-wide parameters available that tune the aggressiveness
of data cachine. I suppose there may also be
cs[docname].deepcopy()
> KeyError: 'reference/generalized_ufuncs'
Do "make clean" first.
--
Pauli Virtanen
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
fallback when the C99 ones are not available.
> What do you mean by "packing" ?
C99 defines a complex type such that the real and imag parts are
packed as in an array:
double complex t;
real = ((double*)&t)[0];
imag = ((double*)&t)
ee/c99-complex-umath
This has some risks: the system-provided complex-valued functions
may be broken in different ways, or suffer from some subtle
flaws. This is likely more common than having broken real-valued
functions that have been around quite a while longer. (To give an
example: casinh(1
iling tests even if
buildbots are OK... After repeating this cycle a couple of times,
IIRC only some special cases of log survived :)
Of course, if you meant to merge the tests first to the new
implementations and that to trunk, this sounds better.
+1] = 0.5
A[j, j-1] = 0.5
A[-1,:] = -0.5*a[:-1]/a[-1]
A[-1,-2] += 0.5
and the zeros are
x = linalg.eig(A)[0]
See eg. http://dx.doi.org/10.1016/j.apnum.2005.09.007 for more.
--
Pauli Virtanen
___
Numpy-discussion mailing l
s can keep track of which features are supported in
which version.
--
Pauli Virtanen
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ither this
> list doesn't want me or there is some other problem.
> Anyway it seems impossible to reach the right people.
I don't think I am able to help you here. Forwarding this to the ML, so
the list admins know.
--
Pauli Virtanen
he old thread applies also here: instead of a
file random.py, you have a package named 'random' in the working
directory.
--
Pauli Virtanen
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
r also left it as an exercise for the reader to
implement the data file parser in Matlab. I doubt it can be easily done
in 20 lines :)
--
Pauli Virtanen
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/
Hi,
Ticket #1143 points out that Numpy's reduction operations are not
always cache friendly. I worked a bit on tuning them.
Just to tickle some interest, a "pathological" case before optimization:
In [1]: import numpy as np
In [2]: x = np.zeros((8, 256))
In [3]: %timeit x.sum(ax
, or whether it just walks the
array in virtual C-order copying the data. If so, then it
probably hits similar cache problems as the non-optimized
reduction operation.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
he ATNumPy route, or even have
tunable parameters chosen at build or compile time. (Unless, of
course, we want to bring a monster into the world -- think about
cross-breeding distutils with the ATLAS build system :)
--
Pauli Virtanen
___
NumPy
airy. Anyway, it seems there is some auditing to do
before this change can be safely considered.
Also, the speedups obtained were fairly modest, 20%. Are they
larger for more complicated expressions? (Ie. is there an
expression whose execution time
have
to go through the list of exported functions, and check that none of them
is problematic. (We know already that at least PyArray_Conjugate is.)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thu, 09 Jul 2009 09:54:26 +0200, Matthieu Brucher kirjoitti:
> 2009/7/9 Pauli Virtanen :
[clip]
>> I'm still kind of hoping that it's possible to make some minimal
>> assumptions about CPU caches in general, and have a rule that decides a
>> code path that
nge ufunc semantics at this point,
and I don't see ways in which one could distinguish between "temporary
arrays" and refcount-1 arrays used in extension modules.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.
t
PyUFunc_GenericFunction is there, and the args tuple probably
usually has new references of the contained objects.
[CPython itself creates a new tuple when doing
a = (np.zeros((4,)), np.zeros((5,)))
np.add(*a)
so that also in this case th
this correct? The .flat iterator always traverses the array in virtual
C-order, not in the order it's laid out in memory.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Wed, 08 Jul 2009 22:16:22 +, Pauli Virtanen kirjoitti:
[clip]
> On an older CPU (slower, smaller cache), the situation is slightly
> different:
>
> http://www.iki.fi/pav/tmp/athlon.png
> http://www.iki.fi/pav/tmp/athlon.txt
>
> On average, it's still an
t of type NotImplementedType. I would have expected it to raise a
> NotImplementedError exception.
>
> Can anybody cast some light on this issue ? Thanks a lot in advance
Seems like a bug. As I understand, NotImplemented is intended to be
returned only from __lt_
Wed, 15 Jul 2009 10:05:12 -0400, Neal Becker kirjoitti:
> Simple question. I want to save a complex vector as text in format
>
> real_0 imag_0\n
> real_1 imag_1\n
> ...
>
> I thought to use something like:
> np.savetxt ('gen_qpsk.txt', (mod_out.real, mod_out.imag), fmt='%g %g\n')
>
> I need a
[clip]
>
> Generally, scalars are never views. a[0] pulls out a record scalar.
> Assigning into that scalar does not affect the original memory.
> a['point'] creates an array that is a view and assigning to the [0]
> element of that array modifies the original memory.
But then, why does it alter the first element of the sub-array?
This seems like a bug...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 2009-07-16, David Cournapeau wrote:
> Hi Pauli,
>
> On Sat, Jul 4, 2009 at 9:59 PM, Pauli Virtanen wrote:
>> Hi,
>>
>> When you add new functions to Numpy, please include
>>
>> .. versionadded:: 1.4.0
>
> What is the best way to do this in the
cache coherency of the reduction operations. Also these would be
more efficient if the striding of the output array could be
chosen freely.
I wonder if it would be OK to make this change...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-D
On 2009-07-18, David Cournapeau wrote:
> On Fri, Jul 17, 2009 at 4:11 AM, Pauli Virtanen wrote:
[clip]
>> Yeah, currently there's no way to do that. I can probably add
>> numpy*function/cfunction/... etc. directives that allow this.
>>
>> An alternative is to us
On 2009-07-20, Keith Goodman wrote:
[clip]
> Oh, sorry, I misunderstood. Yes, a similar change was made to eye but
> not to identity.
Nasty, duplicated code there it seems...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Disc
Wed, 29 Jul 2009 10:20:19 -0400, Neal Becker kirjoitti:
[clip]
> Can 'view' switch byteorder? Doesn't seem to work:
[clip]
I think not: view only alters the dtype, ie., the interpretation of the
block of memory. It does not physically reorder the data in memory, which
is necessary for unpacking
custom implementations for functions
that are missing in it.
> Are they platform independent?
In practice, yes. There are some possible obscure corner cases
currently in complex-valued inf/nan handling, though.
--
Pauli Virtanen
___
NumPy-Disc
hits.
This is the old Numeric module documentation. It probably doesn't
describe all points of Numpy accurately. Of course, the URL is
misleading...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ly small and tasty...
The main issue is probably just choosing an appropriate float return
type, and personally I believe this should be same as numpy's default
float.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
d np.savez a list of ndarrays. It didn't complain, but when I
> loaded the data back, the list had been turned into an ndarray. Is this
> behaviour expected? It did surprise me. Below there is an example:
[clip]
It is expected. savez casts its input to arrays before savi
t.
I'd say that just go ahead and create one -- there's little harm
done even if it's a duplicate.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Wed, 09 Sep 2009 13:08:22 +0200, Ruben Salvador wrote:
> Perfect! Thank you very much :D
>
> It's not obvious, though...I think I should read more deeply into
> Python/NumPy...but for the use I'm giving to it...
>
> Anyway, I thought the pythonic way would be faster, but after trying
> with a siz
e
-pedantic -Werror
in your CFLAGS. Just
unset CFLAGS
or so before compilation. Yes, comma at the end of enum list is not
strictly valid C89, although it is valid C99 and already passes for most
compilers.
--
Pauli Virtanen
su, 2009-09-13 kello 01:47 +0300, Pauli Virtanen kirjoitti:
[clip]
> The error you get from the comma at the end of the enum must be because
> you have
>
> -pedantic -Werror
>
> in your CFLAGS. Just
>
> unset CFLAGS
>
> or so before compilation.
Mon, 14 Sep 2009 09:08:34 +0200, Mads Ipsen wrote:
[clip]
> Well, I don't know you consider this as a valid argument, but to me its
> a matter of removing a single comma, which will make the source less
> sensitive to compilers and compiler flags.
That's done.
; they are an improvement over the current svn version. Is that correct?
> I can help with that if necessary.
You have reviewer rights, so you can go and click the "OK to apply"
buttons, to flag those changes that are better than SVN.
Also, check that no unwanted or dan
always going to be a lot of work when we let the trunk and
> doc-editor get too far out of sync.
The work scales linearly with the size of the diff to SVN, so it's not
extremely bad. Of course, it's a bit of a work to go through hundreds of
potential docstrings in one sitting.
--
sy to fix
them, go ahead and tell them. Designing the UI and how it should work is
the first part of the work in making any improvements.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Fri, 18 Sep 2009 07:42:08 +, Pauli Virtanen wrote:
[clip]
> I doubt that -- not so much has been moved around. It's easy to see from
> "git log --stat -M -C" that only shape_base, getlimits, and machar have
> been moved around since 2007.
A complete listing obtained
olution.
Sounds good, manual resolution for all new and removed pages is
reasonably low-overhead, especially as there is no completely reliable
way to detect when a new page is moved, or just new.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
N
t-svn rewrites the commits you
dcommit to SVN.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
The closest base. If the documentation says the opposite, it's wrong.
That it's the closest base also causes crashes when the base chain
becomes longer than the stack limit.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Dis
creation. I don't know if anything in view creation requires
that the immediate base is alive afterwards, but that seems unlikely, so
I believe there's no reason not to make this change.
Some (bad) code might be broken if this was changed, for example
>>> y = x[::-1]
>>&g
you want to
use it, you'll have to modify to match your module.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
this, and I went
> to the rst file to view the code, but that's obviously not a fix for
> the rendering problem.
The `sphinx.ext.doctest` extension is not enabled, so the testcode::
etc. directives are not available. I'm not sure if i
Mon, 21 Sep 2009 18:49:47 -0700, Fernando Perez wrote:
> On Mon, Sep 21, 2009 at 11:32 AM, Pauli Virtanen wrote:
>> The `sphinx.ext.doctest` extension is not enabled, so the testcode::
>> etc. directives are not available. I'm not sure if it should be enabled
>> -- i
e), or
enabling Sphinx's doctest extension and its support for those.
What Fernando said about them being more clumsy to write and copy than
separate code directives is of course true. I wonder if there's a
technical fix that could be made in Sphinx, at least for HTML, to c
e is how to create one:
Please file a bug ticket in the Trac, thanks!
Here is a simpler way, although one more difficult to accidentally:
>>> a = numpy.frombuffer("A", dtype='S1')
>>> a.flags.writeable = True
>>> b = "A"
>>> a[0] =
s in the end possible to emit raw byte stream to
a pickle somehow, not going through strings. If not, then a copy can't
be avoided.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
to, 2009-09-24 kello 11:51 -0600, Charles R Harris kirjoitti:
> Would it be appropriate to add a class similar to poly but instead
> using chebyshev polynomials? That is, where we currently have
[clip]
Yes, I think. scipy.special.orthogonal would be the best place for this,
I think. Numpy would pr
to, 2009-09-24 kello 14:31 -0500, Robert Kern kirjoitti:
> On Thu, Sep 24, 2009 at 14:18, Pauli Virtanen wrote:
> > As a side note, should the cheby* versions of `polyval`, `polymul` etc.
> > just be dropped to reduce namespace clutter? You can do the same things
> > alre
to, 2009-09-24 kello 13:53 -0600, Charles R Harris kirjoitti:
[clip]
> I was thinking of storing the chebyshev internally as the values at
> the chebyschev points. This makes multiplication, differentiation and
> such quite easy (resample and multiply/divide appropriatately). Its
> equivalent to w
return self.attributes[key]
> KeyError: 'numbered'
No ideas. I think I've seen KeyErrors before, but not from inside
docutils.
My only guess would be to remove the build directory and try again. If
that does not help, I'd look into if there's some known issue with t
fixed
at some point...)
At the least, we should write a well-visible "differences to numarray"
document that explains all differences and known bugs.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http:
anspose has the
> same docstring as numpy.transpose. So it would be very helpful to first
> correct the numpy.array.transpose documentation.
numpy.numarray.transpose is numpy.transpose, so fixing this would involve
implementing the numarray-style transpo
in the case the main problem becomes a wontfix.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Tue, 29 Sep 2009 09:53:40 -0700, Christopher Barker wrote:
[clip]
> How can I identify -0.0?
signbit
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
retty big advantage. (I wonder if there is some way to
> do some of these as a generic 'mixin'?)
The usual approach is to use __getattr__, to forward many routines with
little extra work.
--
Pauli Virtanen
___
NumPy-Discussion m
e of the docstring is generated by Numpy and cannot be
modified.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
econd error may also indicate a bug in patch
generation.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
.. add 'sphinx.ext.autodoc', 'numpydoc' to extensions ...
$ cp /some/path/modulename.py modulename.py
$ vi index.rst
...
add
.. automodule:: modulename
:members:
...
$ make PYTHONPATH=$PWD html
Could be automated.
--
Pauli Virtanen
__
cked, I tried.
Maybe it's best just not to use Google Groups. IMO, gmane.org offers an
equivalent if not superior service.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
d not be too
> difficult to take advantage of this for avoiding unnecessary copies in
> this scenario.
I suppose this kind of check is easiest to do at compile-time, and
defining a -DFORCE_ALIGNED? This wouldn't cause performance penalties for
those architectures
Wed, 21 Oct 2009 16:48:22 +0900, Mathieu Blondel wrote:
[clip]
> My original idea was to write the code in C with Intel/Alvitec/Neon
> intrinsics and have this code binded to be able to call it from Python.
> So the SIMD code would be compiled already, ready to be called from
> Python. Like you sai
place the Numpy routines.
This type of project could probably also be started outside Numpy, and
just monkey-patch the Numpy routines on import.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
I guess the answer is "no".
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ll for my project.
Numpydoc hooks into sphinx.ext.autodoc's docstring mangling. So if you
just need to have docstrings formatted, you can use Sphinx's auto*::
directives.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scip
r my project.
Ah, you meant the stuff output by default to class docstrings. Currently,
there's no way to turn this off, unfortunately. It seems there should be,
though...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Dis
Mon, 26 Oct 2009 08:15:51 -0400, Neal Becker wrote:
> This link:
>
> http://docs.scipy.org/doc/scipy/reference/generated/
scipy.stats.var.html#scipy.stats.var
>
> gives 500 internal server error
Now that's strange. It's a static
Mon, 26 Oct 2009 14:26:20 -0400, Michael Droettboom wrote:
> I know David Cournapeau has done some work on using gcov for coverage
> with Numpy.
>
> Unaware of this, (doh! -- I should have Googled first), I wrote a small
> C code-coverage tool built on top of valgrind's callgrind tool, so it
> bas
rt that can cause
problems is scipy.linalg.eig or numpy.linalg.eig, and, much less likely,
scipy.special.gamma. The former are thin wrappers around LAPACK
routines.)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mai
d if not,
substitute the C99 functions with our npy_math implementations.
This'd be great for scipy.special.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Fri, 30 Oct 2009 18:34:07 +0900, David Cournapeau wrote:
[clip]
> Actually, I am in the process of cleaning my numpy branches for review,
> and intend to push them into svn as fast as possible. Complex is pretty
> high on the list.
Great!
> The missing piece in complex support in npymath is mostl
pe, 2009-10-30 kello 18:57 +0900, David Cournapeau kirjoitti:
[clip: struct return values]
> Is this a problem in practice ? If two compilers differ in this,
> wouldn't they have incompatible ABI ?
Yep, it would be an incompatible ABI. I don't really know how common
this in practice -- but there w
s, please do it soon,
Can we get the complex functions to npy_math for 1.4.0: could be useful
for the next Scipy? This is pretty quick to do, I can just write up some
more tests one evening and commit.
--
Pauli Virtanen
___
NumPy-Discussion mailing lis
d on Windows were contaminated by \r\n line feeds".
I looked in the two files you attached on Numpy trac, and noticed that
they were different (sha1sum).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ft axis=-1 and axis=0 allowed, in addition to axis=None. These
seemed to be required by at least the masked arrays unit tests...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
= np.frompyfunc(lambda x: list(), 1, 1)
>>> a = np.empty((3, 4), dtype=np.object)
>>> filler(a, a);
array([[[], [], [], []],
[[], [], [], []],
[[], [], [], []]], dtype=object)
>>> a[0,3].append(9)
>>> a
array([[[], [], [], [9]],
[[
ma, 2009-11-09 kello 23:13 +, Neil Crighton kirjoitti:
> I've written some release notes (below) describing the changes to
> arraysetops.py. If someone with commit access could check that these sound ok
> and add them to the release notes file, that would be great.
Thanks, added!
Paul
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=
ython code from Matlab.
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
__
I think
everything was well, until 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
on integration meant for numerical computations I
would be surprised if CRT 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 Vi
ted on sphinx bug
> tracker 10 months ago by Pauli, is this indeed related ?
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
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
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
on Python3
Lähettäjä: David Cournapeau
Päivämäärä: 23.11.2009 08:19
On Mon, Nov 23, 2009 at 2:35 PM, Pauli Virtanen 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 for Py
Päivämäärä: 23.11.2009 08:08
On Sun, Nov 22, 2009 at 10:35 PM, Pauli Virtanen 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 &&a
ore.
I just 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
__
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 recompil
S')])
> >>> np.rec.fromarrays(Cols,dtype=d)
> recarray([('test', ''), ('\x00est', ''), ('\x00est', ''), ('\x00est',
> ''),
>('\x00est', ''), ('\x00est'
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
'a'
cease to hold.
dtype titles
If Bytes or Unicode, work similarly as field names.
dtype format strings, datetime tuple, and any other "protocol" strings
Bytes. User can pass in Unicode, but it's converted using
UTF8 codec.
801 - 900 of 1087 matches
Mail list logo
