Mon, 23 Aug 2010 15:30:19 -0500, Travis Oliphant wrote:
> I'm curious as to the status of the Github migration and if there is
> anything I can do to help. I have a couple of weeks right now and I
> would love to see us make the transition of both NumPy and SciPy to GIT.
I think the more or less
ersion of Numpy. On Python versions >= 2.6 Numpy arrays expose the buffer
interface, and array(), asarray() and other functions accept new-style buffers
as input.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy
ch)\n x: array([ inf nanj])\n y: array((inf+infj))')
[clip]
> Pauli or Charles, can you please have a look at these? Looks like
> that's related to your recent work on nans/infs.
These errors probably come from the fact that the platform's C library
does not handle special n
Wed, 04 Aug 2010 23:34:15 +0800, Ralf Gommers wrote:
[clip]
> I haven't started using py3k yet so I'm still a bit fuzzy about bytes
> vs string. But it's easy to try in the interpreter:
>
import re
RE_VERSION = re.compile('(\d+\.\d+(\.\d+)*)')
In the Python 3.1 version I have, this lin
Mon, 02 Aug 2010 23:48:52 +0800, Ralf Gommers wrote:
> I'm trying to get building to work with Python 3.1 under Wine on OS X.
> The first thing you run into is a python distutils problem, which is
> fixed by replacing line 379 of cygwinccompiler.py with
> result = RE_VERSION.search(str(out_str
; 719 res = do_warn(message, category, stack_level);
> (gdb)
That was probably fixed in r8394 in trunk.
But to be sure, can you supply the whole stack trace (type "bt" in the
gdb prompt).
--
Pauli Virtanen
___
NumPy-Discussion m
> the commonly-used pieces of inspect (and hacks like this) into an
> internal utility module that is fast to import.
We actually have `numpy.compat._inspect` and
from numpy.compat import getargspec
that could be used here.
--
Pauli Virtanen
___
module should be used -- no need
to go mucking with in the code objects to just find the number of
arguments for a function.
Nobody has tested this part of the distutils code on Python 3, and indeed
it does not have any tests, so it's not a surprise that stuff like this
is left over :)
ce distribution?
It's supposed to be included in the source distribution --
tools/py3tool.py seems to be missing from the tarball.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
sk[box] |= (grid_x[box] - xx)**2 + (grid_y[box] - yy)**2 < rr**2
# same as: mask[i0:j0,i1:j1] |= (grid_x[i0:j0,i1:j1] ...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Fri, 30 Jul 2010 14:21:23 +0200, Guillaume Chérel wrote:
[clip]
> As for the details about my problem, I'm trying to compute the total
> surface of overlapping disks. I approximate the surface with a grid and
> count how many points of the grid fall into at least one disk.
HTH,
import numpy as np
ting-point-gui.de/
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ould I use? I already use the newest release
The above indeed shows that you are probably using 1.4.1, but the scipy
you import was compiled against either the SVN version of Numpy or 1.4.0.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discus
Thu, 29 Jul 2010 23:39:19 +0800, Ralf Gommers wrote:
> The execfile builtin has disappeared in python 3.x, so I'm trying to
> find another solution for the use of it in setupegg.py. So far I've
> tried
I'd do something like this in "setup.py":
...
+ if os.environ.get('USE_SETUPTOOLS'):
+ i
Thu, 29 Jul 2010 02:40:00 +0200, Sturla Molden wrote:
>> Mon, 26 Jul 2010 23:58:11 +0800, Ralf Gommers wrote:
>> Is the current algorithm in the trunk the ziggurat one, or the previous
>> one? IIRC, the problem was that the ziggurat broke reproducibility of
>> random numbers with a given seed.
>
>
Wed, 28 Jul 2010 18:43:30 -0400, Pierre GM wrote:
[clip]
> Mmh. I did create a PyMappingMethod structure called MyArray_as_mapping,
> and MyArray_as_mapping.mp_subscript points to the function that I want
> to use. However, I'd like the MyArray_as_mapping.length and
> MyArray.mp_ass_subscript to po
Thu, 29 Jul 2010 01:16:14 +0200, Sturla Molden wrote:
[clip]
>> Makes sense. But couldn't a ``dtype`` argument still be useful?
>
> np.ceil(some_array).astype(int)
That's one temporary more. The dtype= argument for all ufuncs wouldn't
probably hurt to
evious
one? IIRC, the problem was that the ziggurat broke reproducibility of
random numbers with a given seed.
So, was the ziggurat algorithm pulled out, or is it still there?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@sci
e arbitrary-size integers are
first-class citizens in the Python world. This sits less well with
Numpy: (i) Numpy tries to sit close to the hardware, and (ii) strictly
speaking, arbitrary-size integers cannot be a Numpy scalar type since
they by definition are not fixed
since adding a new field changes the size
of the array item.
> (or are recarrays pointers-of-pointers as opposed
> to contiguous memory?)
No.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Wed, 28 Jul 2010 12:17:27 +0900, David Cournapeau wrote:
[clip]
http://github.com/numpy/numpy_svn
>
> I put a new repostory (same location)
Compared this against git-svn produced repository. There are a number of
commits missing from the early history, apparently because numpy trunk
was mo
Wed, 28 Jul 2010 12:17:27 +0900, David Cournapeau wrote:
[clip]
http://github.com/numpy/numpy_svn
>
> I put a new repostory (same location)
Some more notes:
- 1.1.x branch is missing.
This is maybe because in SVN something ugly was done with this branch?
- Something is still funny with
Tue, 27 Jul 2010 10:50:51 -0700, Christopher Barker wrote:
> Pauli Virtanen wrote:
>> Tue, 27 Jul 2010 08:37:56 -0600, Jed Ludlow wrote:
>>> On Tue, Jul 27, 2010 at 2:38 AM, Pauli Virtanen wrote:
>>>> One low-hanging fruit to fix could be np.fromfile raising Memor
Tue, 27 Jul 2010 08:37:56 -0600, Jed Ludlow wrote:
> On Tue, Jul 27, 2010 at 2:38 AM, Pauli Virtanen wrote:
>>
>> One low-hanging fruit to fix could be np.fromfile raising MemoryError
>> when it encounters EOF, and other bugs in that part of the code.
>
> The EOF bug
Aug 15: rc 1
> Aug 22: rc 2
> Aug 29: release
Seems OK. I don't remember any big changes that would still be needed.
One low-hanging fruit to fix could be np.fromfile raising MemoryError
when it encounters EOF, and other bugs in that part of
Tue, 27 Jul 2010 00:26:51 +0800, Ralf Gommers wrote:
[clip]
> > > Also, Ralf has the Git ID in format "rgommers<...email...>", but I
> > > guess that's correct?
>
> My checkout failed so can't check this, but that looks a little odd. My
> .gitconfig is normal:
> user]
> name = rgommers
> em
Mon, 26 Jul 2010 13:57:36 +0900, David Cournapeau wrote:
> I have finally prepared and uploaded a test repository containing numpy
> code:
>
> http://github.com/numpy/numpy_svn
Some observations based on a quick look:
1)
$ git branch -r
origin/maintenance/1.1.x_5227
origin/maintenance/1.5.x
, line 1, in
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in
position 0: ordinal not in range(128)
You probably meant to use byte strings, though:
string = b"".join(chr(i).encode('latin1') for i in range(256))
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
wig/numpy.i)
for users in their own projects
I'm not sure what's the best place to put these in.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
for an operation that is otherwise a *left*
> fold is very odd, no matter how you slice it. That is what looks like
> special casing...
I think I see your point now.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
be extended to other reduction
operations. Note that changing reduce behavior would require us to
special-case the above two operations.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
p even
> more, but I couldn't figure out how I'd handle the different attributes
> (or specifically, how to keep them together during a sort).
>
> What're my options?
One option could be to use structured arrays to store the data, instead
of Python objects.
--
Pauli
Thu, 22 Jul 2010 15:00:50 -0500, Johann Hibschman wrote:
[clip]
> Now, I'm on an older version (1.3.0), which might be the problem, but
> which is "correct" here, the code or the docs?
The documentation is incorrect.
--
Pauli Virtanen
nce it maps to either NPY_LONG or
whatever the C "int" type happens to be.
Maybe someone can correct me here, but AFAIK it goes like so.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
he above requires no copying of data, and should be relatively fast. If
you need overlapping windows, those can be emulated with strides:
http://mentat.za.net/numpy/scipy2009/stefanv_numpy_advanced.pdf
http://conference.scipy.org/scipy201
he overhead involved
in making Python function calls (PyArg_*) and interpreting the
bytecode.
So as the usual optimization mantra applies here: measure first :)
Of course, if you measure and show that the expectations 1-4) are
actually wrong, that's fine.
--
Pauli Virtanen
_
You should try using Numpy functions (these don't re-box the data) to do
this. http://docs.scipy.org/doc/numpy/reference/routines.set.html
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ke, 2010-07-21 kello 10:46 +0200, David Cournapeau kirjoitti:
[clip: assert nulps]
> I think we should go toward using those almost everywhere we need
> floating point comparison in testing,
I think we also need an assertion function that behaves like np.allclose
-- the ULPs are somewhat unintuiti
NIT_FUNC
> initexample(void)
> {
> (void) Py_InitModule("example", wrappers);
> }
You need to call import_array(); in the init function. Otherwise,
PyArray_Type probably won't be initialized. This can cause a crash.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Numeric.Complex32
'F'
There, the width of complex number was given by specifying the size of
one element, not the total size.
Numpy should probably raise a DeprecationWarning when someone tries to
use these old Numeric type codes.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ma, 2010-07-19 kello 15:10 +0300, Nadav Horesh kirjoitti:
> Till now I see that numpy2 plays well with PIL, Matplotlib, scipy and
> maybe some other packages. Should I expect that it might break?
If the other packages are compiled against Numpy 1.4.1 or earlier, then
yes, they are expected to bre
import numpy as np
np.array([0,0], dtype=np.complex256)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
> However, nans have been propagated by maximum and minimum since 1.4.0.
> There was a question, discussed on the list, as to what 'nan' complex to
> return in the propagation, but it was still a nan complex in your
> definition of such objects. The final choice was driven by using the
> first of
> What is the difference between these two versions? I usually check out
> the svn version (now 2.0) and it compiles well with python 2.6, 2.7 and
> 3.1.
Binary compatibility with previous versions.
Moreover, 2.0 will likely contain a refactored core.
_
Sun, 18 Jul 2010 15:57:47 -0600, Charles R Harris wrote:
> On Sun, Jul 18, 2010 at 3:36 PM, Pauli Virtanen wrote:
[clip]
>> I suggest the following, aping the way the real nan works:
>>
>> - (z, nan), (nan, z), (nan, nan), where z is any fp value, are all
>> equivale
], dtype=complex256)
>
> i ask for Complex128 and get complex256?
What platform? On Win-64 longdouble == double.
Of course, the byte-width names should still reflect the reality. Please
file a bug ticket...
--
Pauli Virtanen
___
NumPy-Di
now works (final tweaks in r8508, 8509).
Comments are welcome.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Preferences)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[shameless plug]
For those of you tired of waiting for 2to3 after "rm -rf build":
http://github.com/pv/lib2to3cache
and
cd numpy/
USE_2TO3CACHE=1 python3 setup.py build
--
Pauli Virtanen
___
NumPy-Discussion ma
Sun, 18 Jul 2010 21:13:43 +0800, Ralf Gommers wrote:
[clip]
> Builds fine on OS X 10.6 with both 2.7 and 3.1, and all tests pass. With
> one exception: in-place build for 3.1 is broken. Does anyone know is
> this is a distutils or numpy issue? The problem is that on import
> numpy.__config__ can no
Sat, 17 Jul 2010 16:06:40 -0600, Charles R Harris wrote:
> At the moment... Chuck
Worksforme at the moment.
Pauli
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
uired change is essentially replacing
svn checkout ...
svn update
by
git clone ...
git pull ...
in a shell script, and clearing up the checkout directories. I can take
care of this on the server machine, once the move to git has been made.
--
b) Support Python 3.1 and 2.7.
I expect it will be easy to track changes in the trunk, even if preparing
the release will still take some time.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/ma
release.
So I think we should just stick with PyCObject on 2.x, as we have done so
far. I'll just bump the version checks so that PyCapsule is used only on
3.x.
I'll commit this to Numpy SVN soon.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
'1.00e+00'
>>> float(np.complex64(1+2j))
1.0
This should raise an exception. I guess the culprit is at
scalarmathmodule.c.src:1023.
It should at least be changed to raise a ComplexWarning, which we now
anyway do in casting.
--
Pauli V
/* must be finite (normal or subnormal), or NaN */
> return (0);
> }
This function can generate overflows, for example for
x = 0.6 * np.finfo(np.float64).max
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Testing with arithmetic can raise overflows and underflows.
I think the correct isinf is to compare to NPY_INFINITY and -NPY_INFINITY.
Patch is attached to #1500
- Alkuperäinen viesti -
> On Thu, Jul 15, 2010 at 6:42 PM, John Hunter wrote:
>
> > On Thu, Jul 15, 2010 at 7:27 PM, Charles
&& isnan((x)-(x)))
I'll replace it by the obvious
((x) == NPY_INFINITY || (x) == -NPY_INFINITY)
which is true only for +-inf, and cannot raise any FPU exceptions.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@sc
ti, 2010-07-13 kello 10:06 -0700, Keith Goodman kirjoitti:
> No need to use where. You can just do a[np.isnan(a)] = 0. But you do
> have to watch out for 0d arrays, can't index into those.
You can, but the index must be appropriate:
>>> x = np.array(4)
>>> x[()] = 3
>>> x
array(3)
_
recommended by our PR department @ EuroScipy :)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
0.99.1.2, on Ubuntu.
So it seems your problem is localised on the older EPD-6.1-1.
The question is: do you need to support this older version of EPD at all?
The problem does not appear to be that matplotlib has stopped plotting
masked arrays properly, or that something crucial has
g
> loop), a[...,0] itself is changed during the loop, while in the former
> case, numpy makes a copy of a[...,0] ?
Correct.
> Is this intended?
Not really. It's a "feature" we're planning to get rid of eventually,
once a way to do it without sacrificing performance in &q
Fortran code, or uses stuff such as strings
for which Lua's default implementation may be efficient.
At least in the mandelbrot example some things differ. I wonder if Lua
there takes advantage of SIMD instructions because the author of the code
has manually changed the inmost loop
27;d', 'Zf', 'Zd', etc.)
> without calling Python code... Of course, complaints without patches
> should not be taken too seriously ;-)
We'll optimize once someone complains this makes their code slow ;)
--
Pauli Virtanen
___
- numpy/numarray/_capi.c
- numpy/lib/tests/test_io.py
- numpy/core/include/numpy/npy_math.h
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
cvxopt import matrix
N = 2000
X = [0]*N
Y = matrix(0.0, (N, N))
while True:
Y[:N, :1] = X
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Some search words you might want to try on Google:
http://www.google.com/search?q=subset%20sum%20dynamic%20programming
Generic advice only this time, sorry; I don't have pre-made code for
solving this at hand, but hopefully the above links give some pointers
for
Thu, 01 Jul 2010 06:17:50 -0300, Renato Fabbri wrote:
> i need to find which elements of an array sums up to an specific value
>
> any idea of how to do this?
Sounds like the knapsack problem
http://en.wikipedia.org/wiki/Knapsack_problem
___
NumPy-Dis
since it tries to unpickle, if it
doesn't see the .npy magic header.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ke, 2010-06-23 kello 12:46 +0200, Ruben Salvador kirjoitti:
[clip]
> how can I detect the EOF to stop reading
r = f.read(1)
if not r:
break # EOF
else:
f.seek(-1, 1)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discuss
,
speedups (at least with MKL) could come from using faster
implementations of sin/cos/exp etc. basic functions. Using SIMD to
maximum effect would then require an amount of cleverness in re-writing
the evaluation algorithms, which sounds like a major amount of work.
--
oblem is probably that the function is using PyArg_ParseTuple
instead of PyArg_ParseTupleAndKeywords
> Who do I contact about getting a trac account?
Go to http://projects.scipy.org/numpy/ and select "Register".
--
Pauli Virtanen
___
The only chance would be to search for docstrings that haven't
been edited after a certain date.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ranslated to numexpr bytecode that would make a Python
function call to obtain "iv(0, x)" for each block of data required,
assuming "iv" is a vectorized function. It's of course possible to
precompute the value of "iv(0, x)", but this is extra hassle and re
uld it be possible to add generic support for user-supplied ufuncs
into numexpr? This would maybe be more of a convenience feature than a
speed improvement, although perhaps some speed could be gained by
evaluating ufuncs per-block.
--
Pauli Virtanen
status to our Trac systems, primarily for tickets in this state.
Please make best use of it (or have your say if you think it's
not useful, in which case we can back it out).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scip
x27;t understand how this can be: the
float64 scalar type is not supposed to have a non-NULL in the nb_index
slot. Indeed, a np.float64.__index__ method does not exist, and the
following indeed does not work:
[1, 2, 3][np.float64(2.2)]
Strange.
--
Pauli Virtanen
___
tation needs clarification, as numpy.int is not
actually the platform-size integer, but the Python-size integer.
The platform-size integer corresponding to C "int" is IIRC numpy.intc,
which should result to the same sizes as NPY_INT.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
pe, 2010-06-18 kello 12:49 +0200, Berthold Hoellmann kirjoitti:
[clip]
> tst.inttestfunc(np.array((1,2),dtype=np.int))
> tst.inttestfunc(np.array((1,2),dtype=np.int8))
> tst.inttestfunc(np.array((1,2),dtype=np.int16))
> tst.inttestfunc(np.array((1,2),dtype=np.int32))
> tst.inttestfunc(np.array((1,2
.
Yes, I do not think any of us is expecting it to be simple. I don't
think we can aim for the optimal solution, since it is ill-defined, but
only for one that is "good enough in practice".
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
p itself can access the memory with a single stride.
This may cause some speed loss in some expressions. Perhaps there should
be a subtle bias towards C-order? But I'm not sure this is worth the
bother.
--
Pauli Virtanen
___
NumPy-Discussion
pe, 2010-06-11 kello 10:52 +0200, Hans Meine kirjoitti:
> On Friday 11 June 2010 10:38:28 Pauli Virtanen wrote:
[clip]
> > I think I there was some code ready to implement this shuffling. I'll try
> > to dig it out and implement the shuffling.
>
> That would be gre
That's a mirror of a mirror, the master SVN mirror is here:
http://projects.scipy.org/git/numpy/
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
be parseable by DecodeUTF16.
Conversion to real UCS-2 from UCS-4 would be a lossy procedure, since not
all code points can be represented with 2 bytes.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scip
his would be useful for temporary
arrays, although then one would have to be careful not ever to return
memory allocated by this back to the caller.
> have two C functions, the first determining the amount of allocation,
> the second doing the computation.
That sounds like a PITA, think
Sat, 12 Jun 2010 16:30:14 -0400, Alan Bromborsky wrote:
> If I have a single numpy array, for example with 3 indices T_{ijk} and I
> want to sum over two them in the sense of tensor contraction -
>
> T_{k} = \sum_{i=0}^{n-1} T_{iik}. Is there an easy way to do this with
> numpy?
HTH, (not really
shape of indices)
+ (dimensions after the index dimensions)
2) if the index dimensions are not all next to each other, then the shape
of the result array is
(broadcast shape of indices) + (non-index dimensions)
Might be a bit surprising, but at this po
that the outer iterator overhead is
small compared to the duration of the inner loop. This must then be
compared to the memory access overhead involved in the dtype** array.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
fore proceeding.
I'd say that we should simply do this, as nobody should depend on this
assumption.
I think I there was some code ready to implement this shuffling. I'll try
to dig it out and implement the shuffling.
--
Pauli Virtanen
___
Num
to implement specialized
loops for each operation, currently we do one function indirection per
iteration which probably costs something. But again, it may be that the
operations are already bounded by memory speed, and this would not
improve p
hich cannot
probably be shared between different openmp threads. So one would have to
do some extra work to parallelize these parts manually.
But probably if multithreading is desired, openmp sounds like the way to
go...
--
Pauli Virtanen
___
NumPy
have an older version of numpy installed somewhere
that overrides the new one. Check "import numpy; print numpy.__file__" to
see which one is imported.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
name, so it probably wouldn't break anyone's
code.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Fri, 04 Jun 2010 15:19:27 -0700, Dan Roberts wrote:
> Sorry to interrupt, but do you have a usable, up to date cloneable git
> repository somewhere? I noticed that you had a repository on github, but
> it's about a month out of date. I understand if what you're working on
> isn't ready to be clone
easiest combo to work with later?
I think the Github user name is not really needed here, as what goes into
the history is the Git ID: name + email address.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
real emails. Since email are "private", I don't want to just
> "scrape" them without asking permission first. I don't know how we
> should proceed here.
I don't think correcting the email addresses in the SVN history is very
use
r place).
The correct places where this stuff should be is
http://docs.scipy.org/
http://scipy.org/Additional_Documentation
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
3 changes did not require breaking ABI (on
Py2).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
bug. The function
should raise a ValueError instead.
NotImplemented is meant only for use as a placeholder singleton in
implementation of rich comparison operations etc., and we shouldn't
introduce any new meanings IMHO.
--
Pauli Virtanen
___
Wed, 26 May 2010 07:15:08 -0600, Charles R Harris wrote:
> On Wed, May 26, 2010 at 2:59 AM, Pauli Virtanen wrote:
>
>> Wed, 26 May 2010 06:57:27 +0900, David Cournapeau wrote: [clip:
>> doxygen]
>> > It is yet another format to use inside C sources (I don't think
501 - 600 of 1087 matches
Mail list logo
