Always, *always*, or just with high enough probability that you don't
realistically have to worry about it failing. If the latter, I wonder if
you could do something with random projections. Off the top of my head, I
wonder if something like the sum of ranks when ordered under a set of
random
I added allocation tracking tools to numpy for exactly this reason.
They are not very well documented, but you can see how to use them
here:
https://github.com/numpy/numpy/tree/master/tools/allocation_tracking
Ray
On Mon, Feb 25, 2013 at 8:41 AM, Jaakko Luttinen
jaakko.lutti...@aalto.fi
On Thu, Jan 17, 2013 at 10:27 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Wed, Jan 16, 2013 at 5:11 PM, eat e.antero.ta...@gmail.com wrote:
Hi,
In a recent thread
http://article.gmane.org/gmane.comp.python.numeric.general/52772 it was
proposed that .fill(.) should return self
On Jan 17, 2013 8:01 PM, Olivier Delalleau sh...@keba.be wrote:
2013/1/17 Matthew Brett matthew.br...@gmail.com:
Hi,
On Thu, Jan 17, 2013 at 10:27 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Thu, Jan 17, 2013 at 2:10 PM, Benjamin Root ben.r...@ou.edu wrote:
On Thu, Jan 17, 2013
On Sat, Nov 17, 2012 at 8:28 AM, Chao YUE chaoyue...@gmail.com wrote:
Dear all,
I need to make a linear contrast of the 2D numpy array data from an
interval to another, the approach is:
I have another two list: base target, then I check for each ndarray
element data[i,j],
if base[m] =
On Tue, Oct 30, 2012 at 6:08 PM, Ralf Gommers ralf.gomm...@gmail.com wrote:
[...]
P.S. that ticket has escaped the Github move.
The github move only included up to 2225 or so. Anything after that
will have to be imported when Trac is redirected to github. I believe
David Cournapeau is going
On Tue, Oct 23, 2012 at 10:58 AM, David Cournapeau courn...@gmail.com wrote:
I will look into making the NumPy trac read-only. It should not be too
complicated to extend Pauli's code to redirect the tickets part to
github issues.
If you need the map of trac IDs to github IDs, I have code to
On Fri, Oct 19, 2012 at 9:34 PM, Thouis (Ray) Jones tho...@gmail.com wrote:
On Fri, Oct 19, 2012 at 4:46 PM, Thouis (Ray) Jones tho...@gmail.com wrote:
On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones tho...@gmail.com
wrote:
I started the import with the oldest 75 and newest 125 Trac
I started the import with the oldest 75 and newest 125 Trac issues,
and will wait a few hours to do the rest to allow feedback, just in
case something is broken that I haven't noticed.
I did make one change to better emulate Trac behavior. Some Trac
usernames are also email addresses, which Trac
On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones tho...@gmail.com wrote:
I started the import with the oldest 75 and newest 125 Trac issues,
and will wait a few hours to do the rest to allow feedback, just in
case something is broken that I haven't noticed.
I did make one change to better
On Fri, Oct 19, 2012 at 4:46 PM, Thouis (Ray) Jones tho...@gmail.com wrote:
On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones tho...@gmail.com wrote:
I started the import with the oldest 75 and newest 125 Trac issues,
and will wait a few hours to do the rest to allow feedback, just in
case
Also, it looks like Trac issues 2228 and up weren't in the snapshot of
the DB I had. Those should be imported after Trac is disabled for new
bugs.
Ray
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On Wed, Oct 17, 2012 at 4:44 PM, Ralf Gommers ralf.gomm...@gmail.com wrote:
On Tue, Oct 16, 2012 at 11:54 PM, Nathaniel Smith n...@pobox.com wrote:
On Tue, Oct 16, 2012 at 9:06 PM, Thouis (Ray) Jones tho...@gmail.com
wrote:
On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones tho
On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones tho...@gmail.com wrote:
I plan to import all the Trac issues to github by the end of this
week. I want to get an up-to-date snapshot of the Trac DB, and run
another test import with it (just to make sure there's nothing in
recent bugs
On Tue, Oct 16, 2012 at 5:54 PM, Nathaniel Smith n...@pobox.com wrote:
On Tue, Oct 16, 2012 at 9:06 PM, Thouis (Ray) Jones tho...@gmail.com wrote:
On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones tho...@gmail.com wrote:
I plan to import all the Trac issues to github by the end of this
week
I plan to import all the Trac issues to github by the end of this
week. I want to get an up-to-date snapshot of the Trac DB, and run
another test import with it (just to make sure there's nothing in
recent bugs that isn't handled).
Previous test imports here:
On Mon, Oct 1, 2012 at 8:35 AM, Nathaniel Smith n...@pobox.com wrote:
On Sun, Sep 30, 2012 at 7:22 PM, Gael Varoquaux
gael.varoqu...@normalesup.org wrote:
On Sun, Sep 30, 2012 at 07:17:42PM +0100, Nathaniel Smith wrote:
Is there anything better to do than simply revert np.copy() to its
On Mon, Oct 1, 2012 at 8:20 AM, Nathaniel Smith n...@pobox.com wrote:
[...]
How can we discourage people from doing this in the future? Can we
make .base write-only from the Python level (with suitable deprecation
period)? Rename it to ._base (likewise) so that it's still possible to
peek
On Fri, Sep 28, 2012 at 1:48 AM, Ralf Gommers ralf.gomm...@gmail.com wrote:
Looks great! After a quick browse, the only thing I noticed that still needs
some thought is the color scheme for the labels.
That's easy to adjust afterwards.
___
On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau courn...@gmail.com wrote:
Thouis, what needs to be done to make a testbed of the conversion ?
I just returned to this a couple of days ago [*], and last night
successfully imported all the trac issues (from my somewhat
out-of-date snapshot) to
tl;dr I think I fixed everything mentioned below.
On Thu, Sep 27, 2012 at 7:10 PM, Nathaniel Smith n...@pobox.com wrote:
On Thu, Sep 27, 2012 at 3:22 PM, Thouis (Ray) Jones tho...@gmail.com wrote:
On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau courn...@gmail.com wrote:
Thouis, what needs
On Thu, Sep 27, 2012 at 10:09 PM, Thouis (Ray) Jones tho...@gmail.com wrote:
tl;dr I think I fixed everything mentioned below.
By the way, my current method is to address bugs in the import by just
reimporting tickets that demonstrate the bug, and not worrying about
old versions of that ticket
On Wed, Jul 25, 2012 at 7:36 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
[...]
It looks like you want to discard the Milestones, except for the 1.7.0,
1.8.0 and 2.0.0 ones. Why not keep all of them?
These were the only ones defined in the current numpy repository.
I'll add code to
On Wed, Jul 25, 2012 at 6:53 AM, Fernando Perez fperez@gmail.com wrote:
Hi Thouis,
On Tue, Jul 24, 2012 at 2:46 PM, Thouis (Ray) Jones tho...@gmail.com wrote:
I would estimate I'm between a fourth and halfway through the
implementation of the trac-to-github-issues migration code
Hello,
I would estimate I'm between a fourth and halfway through the
implementation of the trac-to-github-issues migration code. The work
lives in at https://github.com/thouis/numpy-trac-migration , though
without a copy of the trac DB, it's not really possible to experiment
with it. I haven't
On Jul 15, 2012 2:08 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote:
On Sun, Jul 15, 2012 at 12:45 AM, Travis Oliphant tra...@continuum.io
wrote:
Hey all,
We are nearing a code-freeze for NumPy 1.7. Are there any last-minute
changes people are wanting to push into NumPy 1.7? We
On Thu, Jul 12, 2012 at 1:28 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
Hi All,
Travis and I agree that it would be appropriate to remove the current 1.7.x
branch and branch again after a code freeze. That way we can avoid the pain
and potential errors of backports. It is
On Mon, Jul 2, 2012 at 11:52 PM, Sveinung Gundersen svein...@gmail.com wrote:
On 2. juli 2012, at 22.40, Nathaniel Smith wrote:
On Mon, Jul 2, 2012 at 6:54 PM, Sveinung Gundersen svein...@gmail.com
wrote:
[snip]
Your actual memory usage may not have increased as much as you think,
On Tue, Jun 26, 2012 at 5:33 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Calling this and that 'gratuitous' is already damaging to the community.
Them's fightin' words. If you didn't want a fight you could have simply
pointed out a path forward.
I disagree. If a change is
On Tue, Jun 26, 2012 at 10:11 PM, Jason Grout
jason-s...@creativetrax.com wrote:
On 6/26/12 3:06 PM, Dag Sverre Seljebotn wrote:
Something the Sage project does very well is meeting often in person
Another thing we have that has improved the mailing list climate is a
sage-flame list [1]
+1 !
On Fri, Jun 22, 2012 at 7:29 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones tho...@gmail.com
wrote:
On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant tra...@continuum.io
wrote:
I have turned on issue tracking and started a few labels
On Sat, Jun 23, 2012 at 5:14 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
What has been done in the past is that an intent to fork is announced some
two weeks in advance so that people can weigh in on what needs to be done
before the fork. The immediate fork was a bit hasty. Likewise,
On Sat, Jun 23, 2012 at 11:13 AM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
On Sat, Jun 23, 2012 at 11:03 AM, Thouis (Ray) Jones tho...@gmail.com
wrote:
On Fri, Jun 22, 2012 at 7:29 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray
On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant tra...@continuum.io wrote:
I have turned on issue tracking and started a few labels. Feel free to add
more / adjust the names as appropriate. I am trying to find someone who
can help manage the migration from Trac.
Are the github issues set
Based on some previous discussion on the numpy list [1] and in
now-cancelled PRs [2,3], I'd like to solicit opinions on adding an
interface for numpy memory allocation event tracking, as implemented
in this PR:
https://github.com/numpy/numpy/pull/309
A brief summary of the changes:
-
On Mon, Jun 18, 2012 at 3:46 PM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 06/18/2012 12:14 PM, Thouis (Ray) Jones wrote:
Based on some previous discussion on the numpy list [1] and in
now-cancelled PRs [2,3], I'd like to solicit opinions on adding an
interface for numpy memory
On Wed, Jun 13, 2012 at 8:54 PM, Wes McKinney wesmck...@gmail.com wrote:
Nathaniel: my experience (see blog posting above for a bit more) is
that khash really crushes PyDict for two reasons: you can use it with
primitive types and avoid boxing, and secondly you can preallocate.
Its memory
Hello,
I'm rewriting scipy.ndimage.label() using numpy's iterator API, and
would like to add the ability for it to operate in-place. However, to
do so, I need to limit the neighbors consulted to those that have
already been processed in the parent iterator over the input and
output arrays. Is
On Wed, Jun 13, 2012 at 7:58 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
I think there were some changes to the iterator API recently, so please keep
in mind that scipy has to still be compatible with numpy 1.5.1 (at least for
now).
Noted. I'll rewrite using the 1.5 API, and save this
I've volunteered to help manage the migration of numpy tickets from
Trac to github issues. The first part of this process is to decide
which tickets to migrate, and how to map Trac ticket data to github
issue data.
Question 1: Which tickets should be migrated? Open? Open and
recently closed?
I've opened a PR at https://github.com/numpy/numpy/pull/296 for discussion.
A typical result
np.zeros((3,3))[[1,2,3]]
Traceback (most recent call last):
File stdin, line 1, in module
IndexError: index 3 is out of bounds for axis 0: [-3,3)
Ray Jones
On Thu, Jun 7, 2012 at 11:44 AM, Dave Hirschfeld
dave.hirschf...@gmail.com wrote:
Paul Anton Letnes paul.anton.letnes at gmail.com writes:
I would prefer:
IndexError: index 3 is out of bounds for axis 0: [-3,2]
as I find the 3) notation a bit weird - after all, indices are not floats, so
On Fri, Jun 1, 2012 at 6:56 PM, Chris Withers ch...@simplistix.co.uk wrote:
On 01/06/2012 16:39, Benjamin Root wrote:
import numpy
numpy.zeros(10)[-123]
Traceback (most recent call last):
File stdin, line 1, in module
IndexError: index out of bounds
On Mon, Jun 4, 2012 at 4:27 PM, Thouis (Ray) Jones tho...@gmail.com wrote:
On Fri, Jun 1, 2012 at 6:56 PM, Chris Withers ch...@simplistix.co.uk wrote:
On 01/06/2012 16:39, Benjamin Root wrote:
import numpy
numpy.zeros(10)[-123]
Traceback (most recent call last
I'm seeing some strange behavior from .max() on a reshaped array in
the current master, and wanted to raise it here to make sure it's not
something uniquely broken in my setup.
This code fails for me, though changing the context (adding a counter
to the loop, or running under python -i) sometimes
On May 25, 2012 5:30 PM, Thouis (Ray) Jones tho...@gmail.com wrote:
It happens at HEAD in Nathan's separate-maskna branch, as well.
Sorry, Nathaniel's branch. My fingers went into autopilot.
Ray
___
NumPy-Discussion mailing list
NumPy-Discussion
The private libnpysort.a (see https://github.com/numpy/numpy/pull/89
for its history) uses PyDataMem_NEW/FREE. I'm trying to convert these
to actual functions to allow tracing numpy memory allocations (see
https://github.com/numpy/numpy/pull/284).
However, these new functions have to be in the
I submitted a PR for this functionality after cleaning it up a bit:
https://github.com/numpy/numpy/pull/284
I've attached an example that produces HTML for a a sortable table
tracking allocations while running through numpy.test().
Ray Jones
sorttable.js
Description: JavaScript source
On Mon, May 21, 2012 at 7:32 PM, Thouis (Ray) Jones tho...@gmail.com wrote:
I submitted a PR for this functionality after cleaning it up a bit:
https://github.com/numpy/numpy/pull/284
I meant to ask here (and Travis reminded me in the PR):
Currently, the trace_data_allocations() function
On Thu, May 17, 2012 at 9:52 PM, Nathaniel Smith n...@pobox.com wrote:
I'd be tempted to just see if I could get by with massif or another
real heap profiler -- unfortunately the ones I know are C oriented,
but might still be useful...
I got some very useful information from Fabien's
It seems to be a bug in the unicode string length computation in
arraytypes.c.src:UNICODE_compare(), based on comparison to the code in
arrayobject.c:_myunicmp() and arrayobject.c:_compare_strings().
Patch below (against maintenance/1.6.x, but the bug also looks to be
present in master based on
On Thu, Mar 29, 2012 at 11:04, Thouis (Ray) Jones tho...@gmail.com wrote:
It seems to be a bug in the unicode string length computation in
arraytypes.c.src:UNICODE_compare(), based on comparison to the code in
arrayobject.c:_myunicmp() and arrayobject.c:_compare_strings().
Patch below
I am seeing some very strange behavior searching a unicode array. The
attached code outputs the following:
UNICODE
Is sorted: True
Search sorted by iteration, left: [0, 1, 2, 4, 4, 6, 6, 8, 8, 10, 10,
12, 12, 13]
Search sorted by iteration, right: [0, 2, 2, 4, 4, 6, 6, 8, 8, 10, 10,
12, 12, 13]
On Thu, Feb 16, 2012 at 19:25, Ralf Gommers ralf.gomm...@googlemail.com wrote:
In another thread Jira was proposed as an alternative to Trac. Can you point
out some of its strengths and weaknesses, and tell us why you decided to
move away from it?
The two primary reasons were that our Jira
On Tue, Dec 6, 2011 at 22:11, Ralf Gommers ralf.gomm...@googlemail.com wrote:
To be a bit more detailed here, these are the most significant pull requests
/ patches that I think can be merged with a limited amount of work:
meshgrid enhancements: http://projects.scipy.org/numpy/ticket/966
On Thu, Dec 1, 2011 at 17:39, Charles R Harris
charlesr.har...@gmail.com wrote:
Given that strings should be the result, this looks like a bug. It's a bit
of a corner case that probably slipped through during the recent work on
casting. There needs to be tests for these sorts of things, so if
Is this expected behavior?
np.array([-345,4,2,'ABC'])
array(['-34', '4', '2', 'ABC'], dtype='|S3')
np.version.full_version
'1.6.1'
np.version.git_revision
'68538b74483009c2c2d1644ef00397014f95a696'
Ray Jones
___
NumPy-Discussion mailing list
Short summary:
A funded post-doctoral position in data analysis, machine-learning,
and statistics applied to biological image-based high-content
screening is available at the BioPhenics platform of the Curie
Institute (Paris, France).
The position involves development and maintenance of tools in
(Posted for a friend)
This NSF opportunity just renewed last week and might interest the
NumPy/SciPy community:
NSF Software Infrastructure for Sustained Innovation (SI2)
http://www.nsf.gov/funding/pgm_summ.jsp?pims_id=503489
It sounds like it's not suited for end-user software in a particular
On Tue, Apr 26, 2011 at 20:31, Daniel Lepage dplep...@gmail.com wrote:
You need PIL no matter what; scipy.misc.imread, scipy.ndimage.imread,
and scikits.image.io.imread all call PIL.
I believe there are two pure python readers:
http://code.google.com/p/pylibtiff/
How about something like this:
# numpy 1.6
def rowhist(A, bins=100):
assert (bins 0)
assert isinstance(bins, int)
rownum = np.arange(A.shape[0]).reshape((-1, 1)).astype(int) * bins
intA = (bins * (A - A.min()) / float(A.max() - A.min())).astype(int)
intA[intA == bins] = bins
I have done some work on scipy.ndimage.measurements, and was adding to
it recently when I noticed I had made use of the idiom
A[X] = Y
with repeated indices in X, relying on the behavior that the last X,Y
pair at each unique X is the one that is assigned in A (last = last by
position in X).
I
62 matches
Mail list logo
