01.05.2012 11:14, David Froger kirjoitti:
> Excerpts from Travis Oliphant's message of mar. mai 01 01:39:26 +0200 2012:
> > If you have particular reasons why we should choose a particular CI service,
> > please speak up and let your voice be heard. There is still time to
make
> > a difference in
01.05.2012 08:52, Travis Oliphant kirjoitti:
[clip]
>> 3. No attachments for issues (screenshots, supporting documents, etc.).
>> Having API access to data won't help you here.
>
> Using gists and references to gists can overcome this. Also using an
> attachment service like http://uploading.co
12.04.2012 18:43, Ralf Gommers kirjoitti:
[clip]
> My current list of preferences is:
>
> 1. Redmine (if admin overhead is not unreasonable)
> 2. Trac with performance issues solved
> 3. Github
> 4. YouTrack
> 5. Trac with current performance
Redmine seems pretty nice, apparently has all the feat
Hi,
18.04.2012 19:57, Alan G Isaac kirjoitti:
> http://docs.scipy.org/doc/numpy/reference/routines.matlib.html#module-numpy.matlib
> promises a list of functions that does not appear (at the moment, anyway).
This doesn't seem to be due to a technical reason, but rather than
because nobody has wri
10.04.2012 06:52, Travis Oliphant kirjoitti:
[clip]
> 4) I'm still not sure about whether the IGNORED
> concept is necessary or not. I really like the separation
> that was emphasized between implementation (masks versus
> bit-patterns) and operations (propagating versus non-propagating).
> P
06.04.2012 00:57, Whitcomb, Mr. Tim kirjoitti:
[clip]
> Did something go wrong with a build?
Seems so. As a workaround, you can read the documentation of the
released versions.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discuss
Hi,
02.04.2012 22:47, Travis Oliphant kirjoitti:
> The plan is use a different issue tracker.
> We are trying out YouTrack right now and hope to
> export the Trac database into YouTrack.
Certainly, I'm aware :)
However, was the plan to also migrate the Scipy Trac? I understood the
answer to t
31.03.2012 18:19, Pauli Virtanen kirjoitti:
> I moved projects.scipy.org Tracs to run on mod_python (instead of CGI),
> in order to try to combat the present performance issues. Let's see if
> this helps with the "database is locked" problem.
>
> Please drop m
Hi,
I moved projects.scipy.org Tracs to run on mod_python (instead of CGI),
in order to try to combat the present performance issues. Let's see if
this helps with the "database is locked" problem.
Please drop me a message if something stops working.
Pauli
___
14.03.2012 14:28, Pierre GM kirjoitti:
[clip]
> Alas, the RuntimeError doesn't look like it's passed back to the interpreter,
> which still crashes. (Adding a Py_Exit(-1) at the end of pyraise_runtime at
> least let the interpreter do some extra cleaning after the fortran code
> stopped,
> but sti
reason is probably that Numpy uses PyObjects internally heavily,
which accumulates the cost of passing objects through the emulation layer.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
S')]
Typo: "argtpes" -> "argtypes"
Probably not Windows-specific :)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
10.03.2012 23:19, Sturla Molden kirjoitti:
[clip]
> If the intention is to avoid Fortran dependency in NumPy, I am not sure
> why this is better than a dependency on CBLAS and LAPACKE.
The CBLAS parts aren't compiled if the library is not available --- in
that case Numpy just falls back to a total
09.03.2012 21:05, Sameer Grover kirjoitti:
> subroutine union ()
>write(*,*)'Hello from Fortran90!!!'
> end subroutine union
>
> f2py is unable to wrap this function. Changing the name of the
> subroutine from 'union' to something else works. I understand that
> problems like these have been r
bug symbols on, set
breakpoints to relevant routines in your class and inside Numpy, and
then step through the execution with (c)gdb.
Automatic memory leak detection tools maybe don't help so much here, as
the problem is likely in wrong reference counting.
.c:array_alloc should
respect the size specified by the subtype.
A workaround is probably to specify a suitable tp_alloc routine yourself:
PyType_GenericAlloc,/* tp_alloc */
unitArray_new, /* tp_new */
_PyObject_Del /* tp_free *
re's no lock-in.
Keeping the conversion script in the public sounds good. We could
perhaps also consider applying hosting for the Scipy tracker, too.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/ma
Hi,
27.02.2012 20:43, Alan G Isaac kirjoitti:
> On 2/27/2012 2:28 PM, Pauli Virtanen wrote:
>> ISO specifies comma to be used in international standards
>> (ISO/IEC Directives, part 2 / 6.6.8.1):
>>
>> http://isotc.iso.org/livelink/livelink?func=ll&objId=10562502&a
27.02.2012 19:07, Alan G Isaac kirjoitti:
> On 2/27/2012 1:00 PM, Paulo Jabardo wrote:
>> First of all '.' isn't international notation
>
> That is in fact a standard designation.
> http://en.wikipedia.org/wiki/Decimal_mark#Influence_of_calculators_and_computers
ISO specifies comma to be used in
increasing the number of APIs for text file loading.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
nd also no, in the sense that Numpy and Scipy don't use VML.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ost of the work in Numpy implementation is not actually in numerics,
but in figuring out the correct operation to dispatch the computations
to. So, this is one reason why Fortran is not considered.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
19.02.2012 05:38, Travis Oliphant kirjoitti:
[clip]
>>> Sure. This list actually deserves a long writeup about that.
>>> First, there wasn't a "Cython-refactor" of NumPy. There was a
>>> Cython-refactor of SciPy. I'm not sure of it's current status.
>>> I'm still very supportive of that so
it is not that much fun.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
16.02.2012 23:39, Travis Oliphant kirjoitti:
[clip]
> * NumPy 1.8 to come out in July which will have as many ABI-compatible
> feature enhancements as we can add while improving test coverage and code
> cleanup. I will post to this list more details of what we plan to address
> with
Hi,
16.02.2012 18:00, Nathaniel Smith kirjoitti:
[clip]
> I agree, but the behavior is still surprising -- people reasonably
> expect something like svd to be deterministic. So there's probably a
> doc bug for alerting people that their reasonable expectation is, in
> fact, wrong :-).
The problem
16.02.2012 14:54, josef.p...@gmail.com kirjoitti:
[clip]
> If I interpret you correctly, this should be a svd ticket, or an svd
> ticket as "duplicate" ?
I think it should be a multivariate normal ticket.
"Fixing" SVD is in my opinion not sensible: its only guarantee is that A
= U S V^H down to n
16.02.2012 14:14, josef.p...@gmail.com kirjoitti:
[clip]
> We had other cases of several patterns in quasi-deterministic linalg
> before, but as far as I remember only in the final digits of
> precision, where it didn't matter much except for reducing test
> precision in my cases.
>
> In the rando
ta alignment, which can affect rounding error.
See http://www.nccs.nasa.gov/images/FloatingPoint_consistency.pdf
That would explain why the pattern you see is quasi-deterministic. The
other explanation would be using uninitialized memory at some point, but
that seems quite unlike
Hi,
15.02.2012 14:59, Ognen Duzlevski kirjoitti:
[clip]
> Alright, it will happen sometime today and I will post a message announcing
> so.
> Ognen
Great! Once you have changed the records, we can adjust [1] the
numpy.github.com page [1] to deal with the new virtual host name.
Thanks,
Pauli
[1
t of 3: 4.07 us per loop
I think the linear growth here is expected, as
i = arange(n)
a[i].shape == i.shape
It's probably possible to cut the overhead, though.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ence/c-api.array.html#import_array
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
11.02.2012 22:02, Jason Grout kirjoitti:
[clip]
> Are there any good github trac plugins? For example:
>
> http://davglass.lighthouseapp.com/projects/21212/home
>
> http://trac-hacks.org/wiki/GitPlugin (git, not github, but still maybe
> useful)
The Numpy & Scipy Trac is currently running on t
11.02.2012 20:44, Travis Oliphant kirjoitti:
> How to people feel about moving the issue tracking for NumPy to Github?
>It looks like they have improved their issue tracking quite a bit and
> the workflow and integration with commits looks quite good from what I
> can see.
The lack of attachm
owever, have the heuristics in place for elementwise operations.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
08.02.2012 11:22, Scott Sinclair kirjoitti:
[clip]
> I see that you've added the CNAME file. Now numpy.github.com is being
> redirected to numpy.scipy.org (the old site).
>
> As I understand it, whoever controls the scipy.org DNS settings needs
> point numpy.scipy.org at numpy.github.com so t
Hi,
06.02.2012 20:41, Ralf Gommers kirjoitti:
[clip]
> I've created https://github.com/scipy/scipy.github.com and gave you
> permissions on that. So with that for the built html and
> https://github.com/scipy/scipy.org-new for the sources, that should do it.
>
> On the numpy org I don't have the
ehavior is not a bug, but a documented feature that has
been around probably already since Numeric.
However, adding a new function could be possible.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/ma
19.01.2012 18:21, Travis Oliphant kirjoitti:
> I think the problem here is one of delegation and information.
>
> I'm not even sure how the web-pages get updated at this point.
> Does anyone on this list know? I think it would be a great idea
> to move to github pages for the NumPy project at lea
> The problem is I don't really know what is supposed to happen if the new
> buffer protocol is supported by some class named say Foo. Could I then
> do
>
> x=Foo([1,2,3])
>
> numpy.array([2,2,2])+x
>
> and such operations?
Yes. You can try it out with Pyt
.org/c-api/objbuffer.html .
[clip]
Since Numpy version 1.5, the new buffer protocol is supported.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
If Numpy indeed is linked against MKL (check the build log), then one
possible reason could be different threading options passed to MKL.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--- it does not make sense to explain
basic Numpy concepts in every docstring, especially `axis` and `shape`
are very common.
However, an example with the axis keyword could be useful.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy
01.12.2011 03:31, josef.p...@gmail.com kirjoitti:
[clip]
> I thought np.dot is Lapack based and favors fortran order, but if the
> second array is fortran ordered, then dot takes twice as long.
It uses C-LAPACK, and will make copies if the arrays are not in C-order.
--
Pauli Vi
y`.
Workarounds: copy-paste the glossary list from `glossary.py` to
`doc/source/glossary.txt` in place of `automodule:: numpy.doc.glossary`
If that doesn't help, then something in the formatting of the glossary
list that makes Sphinx to choke (and it's certainly t
23.11.2011 15:01, Fabrice Silva kirjoitti:
> Hi folks,
> how should I specify a PEP3118 buffer format that could be understand by
> numpy as the following dtype:
>
> dtype = [('t11', '|f8'), ('t22', '|f8'), ('t33', '|f8'),
> ('t23', '|f8'), ('t13', '|f8'), ('t12', '|f8')]
>
> so that I c
expected behavior on assignment, while retaining commutativity, and they
would also behave as expected in reductions. It's a somewhat different
concept from np.ma, but I'm wondering if there would be real-world uses
for tagging values with "this number is not really here, act as
de.
It seems that having `a += b` have `a[j]` unchanged if it's ignored, and
having ignored values propagate creates the problem.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
roperties of arrays with ignored values?
Is there a real-word need to have (a) be true?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
least for me it was not clear before this formulation that
there was a reason why binary ops in np.ma were not commutative! Now I
kind of see that there is an asymmetry in assignment into masked arrays,
and there is a conflict with commuting operations and with "what you'd
expect ignored
04.11.2011 23:29, Pauli Virtanen kirjoitti:
[clip]
> As the definition concerns only what happens on assignment, it does not
> have problems with commutativity.
This is of course then not really true in a wider sense, as an example
from "T J" shows:
a = 1
a += IGNORE(3)
# ->
readability:
Well, np.ma implements "d" semantics, but because of the way binary ops
are noncommutative, in-place binary ops behave as if they were not mutating.
Assignments do actually change the masked data:
>>> a[:] = b
which changes also masked values in `a`. That may b
followed by assignment
>>> x[:] = x + y
as far as the missing values are concerned.
> However, doesn't this have the issue that Nathaniel brought up earlier:
> commutativity
>
> unignore(x + y) != unignore(y + x)
As the definition concerns only what
= 99)
>>> x.data
array([5, 2, 3])
Let's call this (since I botched and already reserved the letter "n" :)
(m) mark-ignored
a := SPECIAL_1
# -> a == SPECIAL_a ; the payload of the RHS is neglected,
# the assigned value has the original LHS
#
04.11.2011 19:59, Pauli Virtanen kirjoitti:
[clip]
> This makes inline binary ops
> behave like Nn. Reductions are N. (Assignment: dC, reductions: N, binary
> ops: PX, unary ops: PC, inline binary ops: Nn).
Sorry, inline binary ops are also PdX, not Nn.
--
Pauli
04.11.2011 17:31, Gary Strangman kirjoitti:
[clip]
> The question does still remain what to do when performing operations like
> those above in IGNORE cases. Perform the operation "underneath"? Or not?
I have a feeling that if you don't start by mathematically defining the
scalar operations first
31.10.2011 09:44, mark florisson kirjoitti:
[clip]
> Ah, that's too bad. Is it anywhere near ready, or was it abandoned for
> ironclad? Could you point me to the code?
It's quite ready and working, and as far as I understand, Enthought is
shipping it. I haven't used it, though.
The code is here:
f that involved ripping
the innards of Numpy out to a more reusable C library. It's been in a
merge-limbo for some time now, however.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
26.10.2011 10:07, Nathaniel Smith kirjoitti:
> On Tue, Oct 25, 2011 at 4:49 PM, Matthew Brett
> wrote:
>> I guess from your answer that such a warning would be complicated to
>> implement, and if that's the case, I can imagine it would be low
>> priority.
>
> I assume the problem is more that it
ime datatypes is not implemented.
There's a faster code path that is triggered for small selection arrays,
and that does not require argsort, and that's why the error occurs in
only some of the cases.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
, or in the "cast to doubles
before formatting" one. In the latter case, one would have to maintain a
list of broken C libraries (ugh).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
* of long doubles that's
broken. Note how the value cast as double prints the correct result,
whereas the %Lg format code gives something wrong.
Can you try to check this by doing something like:
- do some set of calculations using np.longdouble in N
25.10.2011 06:59, Matthew Brett kirjoitti:
> res = np.longdouble(2)**64
> res-1
> 36893488147419103231.0
Can you check if long double works properly (not a given) in C on that
platform:
long double x;
x = powl(2, 64);
x -= 1;
printf("%g %Lg\n", (double)x, x);
or,
d results (or explicitly creates masked arrays), but
as far as I understand that's about the same situation as with np.ma.
.. [1] http://docs.scipy.org/doc/numpy/reference/arrays.maskna.html
--
Pauli Virtanen
___
NumPy-Discussion mailing lis
> somewhere else? Or something else I'm not thinking of? Please help me
> understand.
No, master is supposed to be the integration branch with only finished
stuff in it.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
17.10.2011 15:48, josef.p...@gmail.com kirjoitti:
> On Mon, Oct 17, 2011 at 6:17 AM, Pauli Virtanen wrote:
[clip]
>>> What am I missing? How to do this?
>>
>> np.rec.fromarrays(arr.T, dtype=dt)
>
> y.astype(float16).view(dt)
I think this will give surprises if
13.10.2011 12:59, Alex van der Spek kirjoitti:
> gives me a confusing result. I only asked to name the columns and change
> their
> types to half precision floats.
Structured arrays shouldn't be thought as an array with named columns,
as they are somewhat different.
> What am I missing? How to
sk] = b[mask]
> TypeError: array cannot be safely cast to required type
Seems to be fixed in Git master
>>> import numpy as np
>>> a = np.arange(10)
>>> b = np.ones(10, dtype=np.uint8)
>>> mask = a < 5
>>> b[mask] = b[mask]
>>> b[mask]
guration --- the one with the letter 'i' in it on the upper right
corner of the page.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
pe is known in
> advance, but this is not very efficient as all the lattice points inside
> the bounding box are checked.
The only way to vectorize this I see is to do write the floodfill
algorithm on rectangular supercells, so that the constant costs are
amortized. Sounds
eformulate the problem so that it can be vectorized. Without knowing
more about the actual algorithm you are trying to implement, it's not
easy to give more detailed help.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
10.10.2011 23:02, Jesper Larsen kirjoitti:
> Hi numpy-users
>
> I have a 2d array of shape (ny, nx). I want to broadcast (copy) this
> array to a target array of shape (nt, nz, ny, nz) or (nt, ny, nx) so
> that the 2d array is repeated for each t and z index (corresponding to
> nt and nz). I am not
# ye mighty FORTRAN, we beseech thee
for j, word in enumerate(words):
i = np.arange(len(word))
canvas[i+j, 2*i] = list(word)
canvas[:,-1] = '\n'
return canvas.tostring().rstrip()
--
Pauli Virtanen
___
NumPy-Disc
mpy is kept intentionally bare-bones.
There is one question, though: your qrupdate code is licensed under the
GPL. To include it in Scipy, we need to have it distributable under a
BSD-compatible license. Would you be willing to relicense it?
--
Pauli Virtanen
___
be a string or open file
> **
Yes, this is a known shortcoming of .tofile().
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, 23 Sep 2011 11:57:15 -0600, Charles R Harris wrote:
[clip]
> We're falling behind. The real world is impacting hard at the moment.
> Matthew's suggestion is a good one.
Should we stop recommending using Trac for contributions, and just
say "use git"? (I think we recommend it somewhere.)
I
Hi,
Thu, 22 Sep 2011 13:09:51 +0200, Marijn Verkerk wrote:
[clip]
> ImportError: libptf77blas.so.3: cannot open shared object file: No such
> file or directory
>
> In the __config.py file the folder where libptf77 should be is present.
>
> Any suggestions?
You need to make the dynamic linker ab
Thu, 22 Sep 2011 08:12:12 +0200, Han Genuit wrote:
[clip]
> I also noticed that it does strange things when using a list:
>
c[[True, False, True]]
> array([[3, 4, 5],
>[0, 1, 2],
>[3, 4, 5]])
It casts the list with booleans to an integer array. Probably shouldn't
work like t
Sun, 11 Sep 2011 03:03:26 -0500, Pengkui Luo wrote:
[clip]
> However, converting a large sparse matrix to dense would easily eat up
> the memory. Is there a way for np.sign (as well as other ufunc) to take
> a sparse matrix as parameter, and return a sparse matrix?
For CSR, CSC, and DIA you can do
Wed, 07 Sep 2011 12:52:44 -0700, Chris.Barker wrote:
[clip]
> In [9]: temp['x'] = 3
>
> In [10]: temp['y'] = 4
>
> In [11]: temp['z'] = 5
[clip]
> maybe it wouldn't be any faster, but with re-using temp, and one less
> list-tuple conversion, and fewer python type to numpy type conversions,
> mayb
certain matrix
is singular in exact arithmetic, for a computer it may still be
invertible (by a given algorithm). This type of things are not
unusual in floating-point computations.
The matrix condition number (`np.linalg.cond`) is a better measure
of whether a matrix is invertible or not.
Hey,
Sat, 27 Aug 2011 12:28:14 +0200, David Cournapeau wrote:
> I am finally at a stage where bento can do most of what numscons could
> do. I would rather avoid having 3 different set of build scripts
> (distutils+bento+numscons) to maintain in the long term, so I would
> favor removing numscons
consider heavy-weighedness is distribution:
does your target audience have these libraries already installed
(they are pre-installed in several Python-for-science distributions),
and how difficult would it be for you to ship them with your stuff,
or to require the users to install them.
--
Pa
specified number of lines instead of a number of bytes?
First use standard Python I/O functions to determine the number of
bytes to skip at the beginning and the number of data items. Then pass
in `offset` and `shape` parameters to numpy.memmap.
-
Fri, 19 Aug 2011 12:48:29 +0200, Ralf Gommers wrote:
[clip]
> Hi Ognen,
>
> Could you please disable http access to numpy and scipy svn?
Turns out also I had enough permissions to disable this. Now:
$ svn co http://svn.scipy.org/svn/numpy/trunk numpy
svn: Repository moved permanently to 'http://
Sat, 13 Aug 2011 22:00:33 -0400, josef.pktd wrote:
[clip]
> Does Trac require svn access to dig out old information? for example
> links to old changesets, annotate/blame, ... ?
It does not require HTTP access to SVN, as it looks directly at the
SVN repo on the local disk.
It also probably doesn'
Sat, 13 Aug 2011 18:14:11 +0200, Ralf Gommers wrote:
[clip]
> We should check if there's still any code in SVN branches that is
> useful.
> If so the people who are interested in it should move it somewhere else.
> Anyone?
All the SVN branches are available in Git, though some are hidden. Do
the warnings
module,
warnings.simplefilter("ignore", RuntimeWarning)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Fri, 29 Jul 2011 10:52:12 +0200, Yoshi Rokuko wrote:
[clip]
A, B = mod.meth(C, prob=.95)
>
> is ith possible to return two arrays?
The way to do this in Python is to build a tuple with
Py_BuildValue("OO", A, B) and return that.
___
NumPy-Discussi
hing obvious?
Cython doesn't vectorize the slice operations such as
b[:,j-g]
but falls back to Numpy on them. You'll need to convert the slice
notation to a loop to get speed gains.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumP
Wed, 20 Jul 2011 11:31:41 +, Pauli Virtanen wrote:
[clip]
> There is a sharp order-of-magnitude change of speed in malloc+memset of
> an array, which is not present in memset itself. (This is then also
> reflected in the Numpy performance -- floating point operations probably
> don
Wed, 20 Jul 2011 09:04:09 +, Pauli Virtanen wrote:
> Wed, 20 Jul 2011 08:49:21 +0200, Carlos Becker wrote:
>> Those are very interesting examples. I think that pre-allocation is
>> very important, and something similar happens in Matlab if no
>> pre-allocation is done:
Wed, 20 Jul 2011 09:04:09 +, Pauli Virtanen wrote:
> Wed, 20 Jul 2011 08:49:21 +0200, Carlos Becker wrote:
>> Those are very interesting examples. I think that pre-allocation is
>> very important, and something similar happens in Matlab if no
>> pre-allocation is done:
location, how come I get the same speed
as an equivalent C implementation, which *does* pre-allocation, using
exactly the same benchmark codes as you have posted?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail
Tue, 19 Jul 2011 21:55:28 +0200, Ralf Gommers wrote:
> On Sun, Jul 17, 2011 at 11:48 PM, Darren Dale
> wrote:
>> In numpy.distutils.system info:
>>
>>default_x11_lib_dirs = libpaths(['/usr/X11R6/lib','/usr/X11/lib',
>> '/usr/lib'], platform_bits)
>>defau
ng on -- on my machine, the Numpy operation
runs exactly at the same speed as C, so this issue must have
a platform-dependent explanation.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, 19 Jul 2011 17:49:14 +0200, Carlos Becker wrote:
> I made more tests with the same operation, restricting Matlab to use a
> single processing unit. I got:
>
> - Matlab: 0.0063 sec avg
> - Numpy: 0.026 sec avg
> - Numpy with weave.blitz: 0.0041
To check if it's an issue with building witho
Tue, 19 Jul 2011 11:05:18 +0200, Carlos Becker wrote:
> Hi, I started with numpy a few days ago. I was timing some array
> operations and found that numpy takes 3 or 4 times longer than Matlab on
> a simple array-minus-scalar operation.
> This looks as if there is a lack of vectorization, even thou
Sat, 16 Jul 2011 12:42:36 +0200, Stefan Krah wrote:
> x = ndarray(buffer=bytearray([1,2,3,4,5,6,7,8,9,10]),
> shape=[10], strides=[-1], dtype="B", offset=9)
[clip]
> I do not understand the PyBUF_SIMPLE result. According to the C-API docs
> a consumer would be allowed to access buf[9],
Hi,
Fri, 01 Jul 2011 16:45:47 +0200, Marc Labadens wrote:
> I am trying to interface some python code using numpy array with some C
> code.
You can read:
http://docs.scipy.org/doc/numpy/user/c-info.how-to-extend.html#writing-an-extension-module
However, using Cython often saves you from writing
201 - 300 of 1087 matches
Mail list logo
