Thu, 07 Oct 2010 16:34:46 +0800, Ralf Gommers wrote:
[clip]
> A 1.5.1 release soon would be good. All the issues above are already
> committed, is there anything else that needs to go in? If not, I think
> an RC by the end of next week (10/17) and release by the end of the
> month should be possibl
Thu, 07 Oct 2010 07:09:37 -0600, Charles R Harris wrote:
[clip]
> No, I just wanted to include the Laguerre and Hermite polynomials and
> add a domain keyword to the linspace method of the polynomial template.
> But I don't think these are pressing needs.
It's a minor release, so I think we need t
#x27;d have to rewrite large parts of Numpy since
the separated storage of re/im conflicts with its memory model. I
believe this will simply not be done, since there seems to be little
need for such a feature.
--
Pauli Virtanen
___
NumPy-Di
to, 2010-10-07 kello 15:38 -0400, Andrew P. Mullhaupt kirjoitti:
[clip]
> On 10/7/2010 1:01 PM, Pauli Virtanen wrote:
> > to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti:
> > [clip]
> > But to implement this, you'd have to rewrite large parts of Num
Thu, 07 Oct 2010 18:02:43 -0400, Andrew P. Mullhaupt wrote:
> On 10/7/2010 3:45 PM, josef.p...@gmail.com wrote:
>> what's your namespace?from scipy import log
> log(int(-2))
>> (0.69314718055994529+3.1415926535897931j)
>
> This should explain:
> >>> R = ones(2)
> >>> R[0] = R[0] * 1j
> >>> R
>
7;t sound like something for 1.5.1. Can you think through the
> naming issue and open a ticket so we can start rationalizing this for
> 2.0? I'm thinking having pareto1 and lomax, or maybe pareto1 and
> pareto2, and deprecating plain old pareto may be the way to go.
The documentation b
Fri, 08 Oct 2010 13:28:01 -0400, josef.pktd wrote:
[clip]
> I think I clarified the doc string enough that user that read the
> docstring don't get confused anymore.
> http://docs.scipy.org/numpy/docs/numpy.random.mtrand.RandomState.pareto/
>
> At least the first part is explicit about it, the not
Mon, 11 Oct 2010 13:03:56 +0300, Ioan Ferencik wrote:
> I would like to aks where can I find more detaile dinfo on
> PyArg_ParseTuple function.
This is off-topic for this list.
See docs.python.org or ask on the Python lists:
http://python.org/community/lists/
__
Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote:
> Would any of you mind giving me commit rights on github? My handle is
> pierregm. Thanks a million in advance.
Granted.
Cheers,
Pauli
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http:
s it chooses to diff the result of
a merge against the "wrong" parent (but of course there is no way to know
which is the right one).
The problems with the commit, as far as I see:
- adds unrelated Eclipse .project and .pydev* files
- introduces a merge commit for a sm
r anyone up, but is this the
> best workflow now? Who would decide?
I think it is best to discuss this now, and make sure all core devs have
similar ideas on what is ideal.
One change at a time (i.e. "give 'em the little finger" approach).
--
Pauli Virtanen
___
git branch old_branch new_branch
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
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.
http:/
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 res
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-d
there is some
suspicion that obscure compilers don't like it.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Wed, 20 Oct 2010 17:46:06 +0900, David Cournapeau wrote:
[clip]
> This should have been fixed when I implemented the hashing protocol for
> dtypes. This is a bug in the hashing protocol implementation, most
> likely caused by "=" and "<" being considered different by the hashing
> function. I will
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
Thu, 21 Oct 2010 11:03:52 -0600, Charles R Harris wrote:
[clip]
> I think the important thing to settle here is just how dtype comparisons
> are supposed to work. The current implementation might well be intended
> and if so we need to know why it is so. I'd like Travis to weigh in
> here.
To me i
s being appended to both when extracting the field
> 'a'.
Nice catch!
It seems that `_void_compare` *must* handle broadcasting itself -- I
thought this was done by the caller, but apparently not. So you're right
that the correct place to do the shape check is on the dtype level
ome ways to create arrays in Fortran order so
that the flag does not get set.)
This seems to be somewhat of a mis-feature to me -- it makes predicting
code behavior difficult to anticipate.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
's Guide to Numpy
says (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.
ssues tab and
write 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
are
has a list of Python libraries. I don't know which of them would be
the best ones, though.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
> x.T.flatten()
array([0, 3, 6, 1, 4, 7, 2, 5, 8])
>>> x.T.flatten(order=None)
array([0, 1, 2, 3, 4, 5, 6, 7, 8])
PyArray_OrderConverter interprets `None` as "A". However, this problem is
already there with `reshape`, so this patch looks good to me -- fixing
OrderCon
temporary boolean array.
any() 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
in boolean
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
the result of
>>> the attribute hash table "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:/
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 sc
if it can be done without (significant) performance issues.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
thread where you might 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 lik
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 Virta
t yourself (b).
http://docs.scipy.org/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)
ins point the ReST plugin 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-
py
methods -- the '<' (or '>') is always normalized to '='. Numpy and
several other modules consequently assume this normalization.
Where do `a` and `b` come from?
--
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-modul
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
ating the inverse is not recommended, 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 th
7;s not included 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
e some. The implementation
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/lis
t's data model (I have a script for it),
and I believe it could be useful to do it ASAP.
--
Pauli Virtanen
#!/bin/bash
#
# Graft changesets $OLD_START..$OLD_BRANCH onto $NEW_START, into a branch
# $NEW_BRANCH
#
set -e
OLD_START=7e1e5da84fc110936035660974167cd33f9e4831 # last SVN commit in o
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. Luck
I'm not sure if we should put 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
e in the trunk
> 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
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.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
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 con
ing of long doubles
properly, which cannot be done via the %-syntax.
http://projects.scipy.org/numpy/ticket/1675
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
temsize should be
sizeof(float) and not sizeof(double). If your view really contains floats
in sizeof(double) bytes, the buffer format string probably should
indicate the padding.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@s
e the nan* functions to using Ufuncs.
Unless I'm missing something,
np.nanmax -> np.fmax.reduce
np.nanmin -> np.fmin.reduce
For `nansum`, we'd need to add an ufunc `nanadd`, and for
`nanargmax/min`, we'd need `argfmin/fmax'.
--
Pauli Virtanen
__
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 resi
any indirect calls.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
think this issue
invokes any Numpy code.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
There are more unnecessary merge commits in the git history.
Before you do "git push", check
git log --oneline --graph
git log --oneline --graph upstream/maintenance/1.5.x..
so that you don't push unnecessary stuff. (Also, don't use "git pull".)
$ git log --oneline
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
h
d be useful if someone spent time on profiling the call overhead
for integer indexing. From what I remember from that part of the code,
I'm fairly sure it can be optimized.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discus
On Tue, 23 Nov 2010 23:24:25 +0200, Stéfan van der Walt wrote:
> 2010/11/23 Stéfan van der Walt :
>> On Tue, Nov 23, 2010 at 9:28 AM, Nils Wagner
>> wrote:
>>> "/data/home/nwagner/local/lib/python2.5/site-packages/numpy/lib/npyio.py",
>>> line 66, in seek_gzip_factory
>>> g.name = f.name
>>> A
of keeping some control over what happens 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
terate over 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-Discuss
bug?
There is no symbol 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
__
e to have feedback from us
here.
AFAIK, 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
___
Num
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
nge(200)[newaxis,:,newaxis]
x[...,2] = np.arange(200)[newaxis,newaxis,:]
x[1,3,2]
# -> array([ 1., 3., 2.])
Depending on what you use this array for, it's possible that you can
avoid constructing it (and use broadcasting etc. instead).
--
Pau
tly as Python-specific
wrappers.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ge tracking
still works:
refactor--- new-refactor
//
/libndarray--x
/ \
start-- master----- new-master
--
Pauli Virtanen
_
he
> doc = inspect.getdoc(item)
> File "C:\cygwin\home\haase\Priithon_25_win\Python25\lib\inspect.py",
> line 313, in getdoc
> doc = object.__doc__
> NameError: Unknown C global variable
[clip]
That's more of an issue in the `wx` module in that it behaves
ython setup.py install" 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://mai
a loading routines however could in principle be changed to handle
duplicate title/field combinations. How did you save your data, with
numpy.save/numpy.savez or via pickling?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
0] = 0' 'x.all()'
10 loops, best of 3: 3.12 usec per loop
Could be easily generalized to all types, though, apart from maybe
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 publi
x?
Where did you obtain 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/274
disconnect. The fact just is that nobody has yet built 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-Discussio
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-Di
s not directly
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),
a
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 an
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
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,
in the imaginary part), in
which case `nan` 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
> befor
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 not
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 array_as_seq
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 d
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 ch
p.__version__
> '1.5.1'
Thanks. It's a bug in issubdtype,
http://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
more optimization, even within the ufunc
framework?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
timizations are possible, e.g.
specialized 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-Discus
plitting off the Numpy documentation 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
_
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
sourceforge permissions: would you mind
uploading
http://docs.scipy.org/doc/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
>
n "main" 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/Ub
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
___
NumPy-Discuss
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
http://mail.scipy.org/mailman/listinfo/nump
may
> have to push 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-D
> line is always a few mega 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 cach
501 - 600 of 1087 matches
Mail list logo
