notes are available at
https://sourceforge.net/projects/scipy/files/scipy/0.15.0/
Best regards,
Pauli Virtanen
==
SciPy 0.15.0 Release Notes
==
SciPy 0.15.0 is the culmination of 6 months of hard work. It contains
several new features, numerous bug
it is
available again in Scipy 0.15.1, using it is deprecated and it may be
removed again in a future Scipy release.
Source tarballs, binaries, and full release notes are available at
https://sourceforge.net/projects/scipy/files/scipy/0.15.1/
Best regards,
Pauli Virtanen
==
11.02.2015, 21:57, Alan G Isaac kirjoitti:
[clip]
> I think gains could be in lazy evaluation structures (e.g.,
> a KroneckerProduct object that never actually produces the product
> unless forced to.)
This sounds like an abstract linear operator interface. Several attempts
have been made to this
25.02.2015, 07:11, Nathaniel Smith kirjoitti:
> Not sure if this is a full GSoC but it would be good to get the benchmarks
> into the numpy repository, so we can start asking people who submit
> optimizations to submit new benchmarks as part of the PR (just like other
> changes require tests).
Thi
25.02.2015, 19:59, Pauli Virtanen kirjoitti:
> 25.02.2015, 07:11, Nathaniel Smith kirjoitti:
>> Not sure if this is a full GSoC but it would be good to get the benchmarks
>> into the numpy repository, so we can start asking people who submit
>> optimizations to submit new benc
Arnd Baecker web.de> writes:
[clip]
> Still I would have thought that this should be working out-of-the box,
> i.e. without the pickle.loads trick?
Pickle files should be considered incompatible between Python 2 and Python 3.
Python 3 interprets all bytes objects saved by Python 2 as str and att
06.03.2015, 20:00, Benjamin Root kirjoitti:
> A slightly different way to look at this is one of sharing data. If I am
> working on a system with 3.4 and I want to share data with others who may
> be using a mix of 2.7 and 3.3 systems, this problem makes npz format much
> less attractive.
pickle i
06.03.2015, 22:43, Eric Firing kirjoitti:
> On 2015/03/06 10:23 AM, Pauli Virtanen wrote:
>> 06.03.2015, 20:00, Benjamin Root kirjoitti:
>>> A slightly different way to look at this is one of sharing data. If I am
>>> working on a system with 3.4 and I want to share data
06.03.2015, 22:23, Pauli Virtanen kirjoitti:
> 06.03.2015, 20:00, Benjamin Root kirjoitti:
>> A slightly different way to look at this is one of sharing data. If I am
>> working on a system with 3.4 and I want to share data with others who may
>> be using a mix of 2.7 and 3.3
07.03.2015, 01:29, Julian Taylor kirjoitti:
> On 07.03.2015 00:20, Pauli Virtanen wrote:
>> 06.03.2015, 22:43, Eric Firing kirjoitti:
>>> On 2015/03/06 10:23 AM, Pauli Virtanen wrote:
>>>> 06.03.2015, 20:00, Benjamin Root kirjoitti:
>>>>> A slightly di
03.04.2015, 04:09, josef.p...@gmail.com kirjoitti:
[clip]
> I think numpy indexing is not too difficult and follows a consistent
> pattern, and I completely avoid mixing slices and index arrays with
> ndim > 2.
>
> I think it should be DOA, except as a discussion topic for numpy 3000.
If you chan
12.04.2015, 17:15, Peter Kerpedjiev kirjoitti:
[clip]
> numpy/random/mtrand/distributions.c:892:1: internal compiler error:
> Illegal instruction
An internal compiler error means your compiler (in this case, gcc) is
broken. The easiest solution is to use a newer version of the compiler,
assuming t
28.05.2015, 20:05, David Cournapeau kirjoitti:
[clip]
>> In any case I've always been surprised that NumPy is distributed
>> through SourceForge, which has been sketchy for years now. Could it
>> simply be hosted on PyPI?
>>
>
> They don't accept arbitrary binaries like SF does, and some of our
>
28.05.2015, 20:35, Sturla Molden kirjoitti:
> Pauli Virtanen wrote:
>
>> Is it possible to host them on github? I think there's an option to add
>> release notes and (apparently) to upload binaries if you go to the
>> "Releases" section --- there's
28.05.2015, 21:52, Julian Taylor kirjoitti:
> there is no guarantee that github will not do this stuff in future too,
> also PyPI or self hosting do not necessarily help as those resources can
> be compromised.
> The main thing that should be learned this and the many similar
> incidents in the pas
15.06.2015, 12:00, Nathaniel Smith kirjoitti:
[clip]
> http://homu.io/
One thing to consider is the disadvantage from security POV: this gives
full write access to the Numpy repository to that someone who is running
the bot. I don't see information on who this person (or these persons)
is and ho
13.07.2015, 19:44, Eric Martin kirjoitti:
> It seems to me that a potentially better route than "add code to Numpy to
> support BLAS library" for each library is to make Numpy easy to configure
> to compile with an arbitrary BLAS library (like what I've been doing).
Does this work:
export ATLAS=N
13.07.2015, 20:08, Nathaniel Smith kirjoitti:
[clip]
> Keep in mind that any solution needs to support weird systems too,
> including Windows. I'm not sure we can assume that all BLAS libraries are
> ABI compatible either. Debian/Ubuntu make sure that this is true for the
> ones they ship, but not
14.08.2015, 20:45, Allan Haldane kirjoitti:
[clip]
> Related to this, does anyone know how to debug numpy in gdb with proper
> symbols/source lines, like I can do with other C extensions? I've tried
> modifying numpy distutils to try to add the right compiler/linker flags,
> without success.
runte
15.08.2015, 01:44, Chris Barker kirjoitti:
[clip]
> numpy doesn't use namespace packages, so develop mode works there.
The develop mode is mainly useful with a virtualenv.
Otherwise, you install work-in-progress development version into your
~/.local which then breaks everything else. In addition
24.08.2015, 01:02, Chris Laumann kirjoitti:
[clip]
> Is there documentation about the limits and workarounds for py2/py3
> pickle/np.save/load compatibility? I haven't found anything except
> developer bug tracking discussions (eg. #4879 in github numpy).
Not sure if it's written down somewhere b
25.08.2015, 01:15, Chris Laumann kirjoitti:
> Would it be possible then (in relatively short order) to create
> a py2 -> py3 numpy pickle converter?
You probably need to modify the pickle stream directly, replacing
*STRING opcodes with *BYTES opcodes when it comes to objects that are
needed for c
26.08.2015, 14:14, Francesc Alted kirjoitti:
[clip]
> 2015-08-25 12:03 GMT+02:00 Nathaniel Smith :
>> Let's focus on evolving numpy as far as we can without major
>> break-the-world changes (no "numpy 2.0", at least in the foreseeable
>> future).
>>
>> And, as a target for that evolution, l
html
However, since it's piecewise, there's purposefully support only
for real-valued roots.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
py/commit/832baa20f0b5
so you may have better luck with the dev version.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
d take some
understanding of the downstream package, but this would at least ensure
we are aware of stuff breaking. Provided it's covered by downstream test
suite, of course.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion
31.01.2016, 14:41, Daπid kirjoitti:
> On 31 Jan 2016 13:08, "Pauli Virtanen" wrote:
>> For example, automated test rig that does the following:
>>
>> - run tests of a given downstream project version, against
>> previous numpy version, record output
&g
'm necessarily volunteering to maintain the setup, though, but
if it seems useful, move it under numpy org.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
added value this is compared to travis matrix, eg.
https://travis-ci.org/pv/testrig/
Of course, if the suggestion is that the results are generated on
somewhere else than on travis, then that's a different matter.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
05.02.2016, 19:55, Nathaniel Smith kirjoitti:
> On Feb 5, 2016 8:28 AM, "Chris Barker - NOAA Federal"
> wrote:
>>
>>> An extra ~2 hours of tests / 6-way parallelism is not that big a deal
>>> in the grand scheme of things (and I guess it's probably less than
>>> that if we can take advantage of ex
10.02.2016, 04:09, Charles R Harris kirjoitti:
> I'm pleased to announce the release of NumPy 1.11.0b3. This beta contains
[clip]
> Please test, hopefully this will be that last beta needed.
FWIW, https://travis-ci.org/pv/testrig/builds/108384173
___
N
23.02.2016, 03:47, Charles R Harris kirjoitti:
> I'm delighted to announce the release of Numpy 1.11.0rc1. Hopefully the
> issues discovered in 1.11.0b3 have been dealt with and this release can go
> on to become the official release. Source files and documentation can be
> found on Sourceforge
> <
ntation in the 2GB address space available? If dt==float64,
that requires 250MB contiguous.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Thu, 11 Feb 2016 00:02:52 +0100, Ralf Gommers kirjoitti:
[clip]
> OK first version:
> https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas I kept some
> of the ideas from last year, but removed all potential mentors as the
> same people may not be available this year - please re-add yourselv
dify the build to avoid
> them?
Maybe the ATLAS binaries supplied were compiled with g77 instead of
gfortran. If so, they should not be used with gfortran --- need to
recompile.
Also, in the past ATLAS binaries shipped by distributions had severe
bugs. However, 3.8.x may be a new enough version.
base refcounting.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
In case someone is interested in getting notifications of performance
regressions in the Numpy and Scipy benchmarks, this is available as Atom
feeds at:
https://pv.github.io/numpy-bench/regressions.xml
https://pv.github.io/scipy-bench/regressions.xml
--
Pauli Virtanen
emory alignment --- not in dot
products, but in other computations.
Out of curiosity, what is the application where this is necessary?
Maybe there is a numerically stable formulation?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@
urse, working on that requires a somewhat
different level of committment than editing what's essentially
Stackexchange-provided wiki (where content gets relicensed with
attribution clauses where you have to reference stackexchange and not the
original author dire
Fri, 05 Aug 2016 10:06:02 +0300, Matti Picus kirjoitti:
[clip]
> I can submit a pull request to skip on pypy, or should this be solved in
> a more substantial way?
Should also be safe to just skip it on Pypy, it's testing that the wrong
way to use np.load also works on CPython.
also that copies
break assumptions also there.
It might be possible to turn it on by default for operands with COPY or
UPDATEIFCOPY flags --- but I'm not sure if that's helpful (now you'd need
to set the flags to all input operands).
--
Pauli Virtanen
Hi,
In the end some further API additions turn out to appear needed:
* NPY_ITER_COPY_IF_OVERLAP, NPY_ITER_OVERLAP_NOT_SAME
flags for NpyIter_New.
* New API function PyArray_MapIterArrayCopyIfOverlap,
as ufunc.at needs to check overlaps for index arrays
before constructing iterators, and t
Mon, 12 Sep 2016 11:31:07 +0200, Sebastian Berg kirjoitti:
>> * NPY_ITER_COPY_IF_OVERLAP, NPY_ITER_OVERLAP_NOT_SAME
>> flags for NpyIter_New.
>>
>> * New API function PyArray_MapIterArrayCopyIfOverlap,
>> as ufunc.at needs to check overlaps for index arrays before
>> constructing iterators,
Mon, 03 Oct 2016 15:07:28 -0400, Benjamin Root kirjoitti:
> With regards to arguments about holding onto large arrays, I would like
> to emphasize that my original suggestion mentioned weakref'ed numpy
> arrays.
> Essentially, the idea is to claw back only the raw memory blocks during
> that limbo
Sat, 12 Nov 2016 17:00:07 +, Pavlyk, Oleksandr kirjoitti:
[clip]
> if x_arr is not x:
>in_place = 1 # a copy was made, so we can work in place.
>
> The logic is of the last line turns out to be incorrect, because the
> input x can be a class with an array interface.
Please see:
t? 0.1 does not have a terminating representation in base-2:
0.1_10 = 0.0001100110011001100110011.._2
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ma, 2010-03-29 kello 19:13 +0900, David Cournapeau kirjoitti:
> I have worked on porting scipy to py3k, and it is mostly working. One
> thing which would be useful is to install something similar to
> npy_3kcompat.h in numpy, so that every scipy extension could share the
> compat header. Is the cur
2010/3/30 David Cournapeau
> Pauli Virtanen wrote:
[clip]
> > At least, I don't see what I would like to change there. The only thing
> > I wouldn't perhaps like to have in the long run are the PyString and
> > possibly PyInt redefinition macros.
>
> I wou
2010/3/30 David Cournapeau :
> Currently, when building numpy with python 3, the 2to3 conversion
> happens before calling any distutils command. Was there a reason for
> doing it as it is done now ?
This allowed 2to3 to also port the various setup*.py files and
numpy.distutils, and implementing it
ti, 2010-03-30 kello 07:18 -0600, Ryan May kirjoitti:
> Out of curiosity, is there something wrong with the support for 2to3
> that already exists within distutils? (Other than it just being
> distutils)
>
> http://bruynooghe.blogspot.com/2010/03/using-lib2to3-in-setuppy.html
That AFAIK converts
these lines, though mostly
addressing the reduction:
http://github.com/pv/numpy-work/tree/ticket/1143-speedup-reduce
http://projects.scipy.org/numpy/ticket/1143
Not production quality so far, and the non-C-output order would
definitely help also here.)
--
Pauli Virtanen
__
ld be stuffed to the main
namespace, or under numpy.rec.
Another addition to ufuncs that should be though about is specifying the
Python-side interface to generalized ufuncs.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ea.
>
> But I didn't write numpydoc and I'm tired, so I don't want to commit
> this without a second pair of eyes...
Yeah, it's a bug, I think.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
s of Numpy, the code could be
immediately usable in real world, being less of a proof-of-concept
subset.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Probably the only way to ensure this is to recompile Numpy (and
possibly, also Python) with the -ffloat-store option turned on.
When compiling Numpy, you should be able to insert the flag via
OPT="-ffloat-store" python setup.py build
--
Pauli Virtanen
___
Wed, 28 Apr 2010 14:12:07 -0400, Alan G Isaac wrote:
[clip]
> Here is a related ticket that proposes a more explicit alternative:
> adding a ``dot`` method to ndarray.
> http://projects.scipy.org/numpy/ticket/1456
I kind of like this idea. Simple, obvious, and leads
to clear code:
a.dot(b
Sat, 08 May 2010 18:44:59 -0600, Charles R Harris wrote:
[clip]
> Because window's longs are always 32 bit, I think this is a good
> indication that somewhere a long is being used instead of an intp.
The test itself used 32-bit integers. Fix'd.
Pauli
_
ame, e.g. `pareto1` to signal it's the first kind, and deprecate the old
function altogether.
A third option would be just to silently fix the bug. In any case the
change should be mentioned noticeably in the release notes.
--
Pauli Virtanen
___
N
Mon, 17 May 2010 13:22:18 -0400, Skipper Seabold wrote:
[clip]
> What version of Numpy? Can you file a bug ticket with a failing
> example? I couldn't replicated with r8417 on Python 3.
It was fixed in r8411.
--
Pauli Virtanen
___
NumPy
type=str)
array(['1234'],
dtype='|S4')
When I looked at this the last time, it wasn't completely obvious how to
make this to do something more sensible.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
new
files. Try building from a clean checkout.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ficult, as projects aimed doing that in Python exist, for instance
http://code.google.com/p/pycparser/
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
c by
> default,
Anyway, we can probably nevertheless just agree on a readable plain-text/
rst format, and then just use doxygen to generate the docs, as a band-aid.
http://github.com/pv/numpycdoc
--
Pauli Virtanen
___
NumPy-Discussion mailing list
he heavy lifting could then be good for reuse and
be more easy to maintain, but I think how and where they would be exposed
hasn't been discussed so far...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
ke, 2010-05-26 kello 14:07 +0200, Christoph Bersch kirjoitti:
> f = open(fname2, 'w')
[clip]
> Am I doing something substantially wrong or is this a bug?
You are opening files in text mode. Use mode 'wb' instead.
--
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
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
___
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
.
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
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
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
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
___
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
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
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
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
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
___
,
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.
--
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
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
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
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
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
301 - 400 of 1087 matches
Mail list logo
