Yep, that'd be a good idea. Want to write a patch? :-)
https://github.com/numpy/numpy/pull/440
Thinking about the other thread, and the 'number of elements' check, I
noticed this:
In [51]: np.__version__
Out[51]: '1.6.1'
In [52]: r4 = range(4)
In [53]: r3 = range(3)
In [54]:
Is this intended? Is there a performance reason to keep the same
strides in 1.7.0?
I believe that this could be because in 1.7.0, NumPy was changed so that
copying does not always default to C-order but to Keep-order.So, in
1.7.0, the strides of b is governed by the strides of a,
I am wondering of this has to do with the size of the array.
It looks like the array is sorted --- but in chunks.
--
Travis Oliphant
(on a mobile)
512-826-7480
On Sep 10, 2012, at 10:46 PM, Jadhav, Alok alok.jad...@credit-suisse.com
wrote:
Hi everyone,
I have a numpy array
Hey Alok,
This is worth taking a look. What version of NumPy are you using?
It is not related directly to the issue you referenced as that was an
endian-ness issue and your data is native-order.
Your example seems to work for me (with a simulated case on 1.6.1)
Best,
-Travis
On Sep
There is an error context that controls how floating point signals are handled.
There is a separate control for underflow, overflow, divide by zero, and
invalid. IIRC, it was decided on this list a while ago to make the default
ignore for underflow and warning for overflow, invalid and
, Ondřej Čertík wrote:
On Tue, Sep 4, 2012 at 8:38 PM, Travis Oliphant tra...@continuum.io wrote:
There is an error context that controls how floating point signals are
handled. There is a separate control for underflow, overflow, divide by
zero, and invalid. IIRC, it was decided
On Aug 22, 2012, at 3:59 AM, Ralf Gommers wrote:
On Tue, Aug 21, 2012 at 12:51 AM, Travis Oliphant tra...@continuum.io wrote:
I'm actually not sure, why. I think the issue is making sure that the
release manager can actually build NumPy without having to buy a particular
compiler
On Aug 22, 2012, at 9:28 AM, David Cournapeau wrote:
On Wed, Aug 22, 2012 at 3:25 PM, Travis Oliphant tra...@continuum.io wrote:
On Aug 22, 2012, at 3:59 AM, Ralf Gommers wrote:
On Tue, Aug 21, 2012 at 12:51 AM, Travis Oliphant tra...@continuum.io
wrote:
I'm actually not sure, why
I'm actually not sure, why. I think the issue is making sure that the release
manager can actually build NumPy without having to buy a particular compiler.
But, I would rather have official builds of NumPy for all platforms with a
compiler paid for by a NumPy-sponsor than not have them.
Donations to NumFOCUS would be helpful in raising money to fund the creation of
64-bit installers.It always comes down to funding, but mostly people's time
is the scarce resource here.
It is more difficult to build 64-bit binaries on Windows which is the real
issue (not the
On Aug 10, 2012, at 5:37 AM, Paul Anton Letnes wrote:
On 10. aug. 2012, at 09:54, Mark Bakker wrote:
I am giving this a second try. Can anybody help me out?
I think there is a problem with assigning a 1D complex array of length one
to a position in another complex array.
Example:
Hey all,
Ondrej has been working hard with feedback from many others on improving
Unicode support in NumPy (especially for Python 3.3). Looking at what Python
has done in Python 3.3 (PEP 393) and chatting on the Python issue tracker with
the author of that PEP has made me wonder if we
This should be completely fine.The fftpack.h file indicates that fftpack
code came from Tela originally anyway and was translated from the Fortran code
FFTPACK.
Good luck with your project.
-Travis
On Aug 2, 2012, at 3:44 PM, Damon McDougall wrote:
Hi,
I have a question about the
Can you file a bug report on Github's issue tracker?
Thanks,
-Travis
On Jul 26, 2012, at 1:33 PM, Phil Hodge wrote:
On a Linux machine:
uname -srvop
Linux 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64
GNU/Linux
this example shows an apparent problem with the where
Hey all,
I'm wondering who has tried to make NumPy work with Python 3.3. The Unicode
handling was significantly improved in Python 3.3 and the array-scalar code
(which assumed a certain structure for UnicodeObjects) is not working now.
It would be nice to get 1.7.0 working with Python 3.3
I'm not sure what the conclusion actually was from this long thread.
But, in trying to update the 1.7.x branch, I ended up in a very odd state with
respect to the github pages. I used git filter-branch to try and get rid of
empty commits that were showing up for some reason. However, this
On Jul 19, 2012, at 4:56 AM, Nathaniel Smith wrote:
On Thu, Jul 19, 2012 at 6:04 AM, Frédéric Bastien no...@nouiz.org wrote:
On Tue, Jul 17, 2012 at 10:20 PM, Travis Oliphant tra...@continuum.io
wrote:
I will hold off on this one, but only because you raised your objection to
-1 (instead
On Jul 19, 2012, at 3:50 AM, Nathaniel Smith wrote:
So the underlying problem with the controversial inplace_increment
PR[1] is that currently, there's actually nothing in the public numpy
API that exposes the workings of numpy indexing. The only thing you
can do with a numpy index is call
On Jul 19, 2012, at 9:14 AM, Charles R Harris wrote:
On Thu, Jul 19, 2012 at 7:45 AM, Travis Oliphant tra...@continuum.io wrote:
I'm not sure what the conclusion actually was from this long thread.
But, in trying to update the 1.7.x branch, I ended up in a very odd state
with respect
Hey all,
We are going to work on a beta release on the 1.7.x branch.The master is
open again for changes for 1.8.x. There will be some work on the 1.7.x branch
to fix bugs including bugs that are already reported but have not yet been
addressed (like the regression against data-type
I don't have a strong preference. Which one do others prefer?
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Jul 18, 2012, at 9:06 AM, Nathaniel Smith n...@pobox.com wrote:
On Wed, Jul 18, 2012 at 7:09 AM, Travis Oliphant tra...@continuum.io wrote:
Hey all,
We are going
://github.com/numpy/numpy/pull/326
).
I'm new to the numpy and python internals, so feedback is greatly
appreciated.
On Tue, Jun 26, 2012 at 12:10 PM, Travis Oliphant tra...@continuum.io
wrote:
On Jun 26, 2012, at 1:34 PM, Frédéric Bastien wrote:
Hi,
I think he
I would like to merge the following pull requests sometime today:
* 326 -- inplace increment function
* 325 -- prefer gfortran on OSX and Linux
* 192 -- meshgrid enhancements
* 327 -- restore commas and update C-API doc a bit
* 352 -- simplifying case for insert and adding tests (#2028)
* 350
On Jul 17, 2012, at 6:48 PM, Nathaniel Smith wrote:
On Tue, Jul 17, 2012 at 9:56 PM, Travis Oliphant tra...@continuum.io wrote:
I would like to merge the following pull requests sometime today:
* 326 -- inplace increment function
-1, for the reasons stated in the comment thread -- we
On Jul 16, 2012, at 1:52 AM, Pierre GM wrote:
Hello,
I'm siding w/ Tom, Nathaniel and Travis. I don't think the change as it is is
advisable. It's a regression, and breaking=bad.
Now, I can understand your frustration, so, what about a trade-off? The first
line w/ a comment after the
On Jul 16, 2012, at 4:50 PM, Ralf Gommers wrote:
On Mon, Jul 16, 2012 at 6:28 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
Hi All,
Working lazy imports would be useful to have. Ralf is opposed to the idea
because it caused all sorts of problems on different platforms when
On Jul 15, 2012, at 2:23 PM, Nathaniel Smith wrote:
On Sun, Jul 15, 2012 at 6:18 PM, jay bourque jay.bour...@continuum.io wrote:
Just added PR #359. The purpose is to allow the nditer object operand and
iter flags to be set for a ufunc to provide better control over how an array
is iterated
On Jul 15, 2012, at 4:07 PM, Chris Ball wrote:
Stefan Krah stefan-usenet at bytereef.org writes:
...
I wonder if this might be a blocker: Python-3.3 will be released in August
and I don't think the issue is fixed yet:
http://projects.scipy.org/numpy/ticket/2145
In case it helps, on a
On Jul 15, 2012, at 7:08 AM, Ralf Gommers 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 should discuss them
That reminds me.
How many NumPy devs are going to be at SciPy this year?It would be good to
have a NumPy sprint there. Ideas for what we could work on:
1) Make progress on the 1.7.0 release
2) Make progress on the conversion to Github
3) Make progress against tickets and PRs
If enough
Bump for: https://github.com/numpy/numpy/pull/351
As requested by njsmith, I gave a more detailed explanation and asked
the list for input at:
http://www.mail-archive.com/numpy-discussion@scipy.org/msg38306.html
There was one qualified negative reply and nothing (yet) further. I'd
it should not have any side effect
problems.
This was a feature frequently requested.
Fred
On Sun, Jul 15, 2012 at 10:40 PM, Travis Oliphant tra...@continuum.io wrote:
Bump for: https://github.com/numpy/numpy/pull/351
As requested by njsmith, I gave a more detailed explanation
In https://github.com/numpy/numpy/pull/350/files ,
javius provides a patch to allow field extraction from a structured array to
return a view instead of a copy.Generally, this is consistent with the
desire to have NumPy return views whenever it can. The same idea underlies
the change
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 should discuss them as soon as
possible.
I'm proposing a code-freeze at midnight UTC on July 18th (7:00pm CDT on July
17th). This will allow the
Thanks for the review. I think it will be safe as well. Ondrej is traveling
to Prague at the moment. When he arrives, let's here what he has to say and
then move forward.
-Travis
On Jul 12, 2012, at 12:42 AM, Charles R Harris wrote:
On Wed, Jul 11, 2012 at 11:21 PM, Thouis (Ray)
On Jul 9, 2012, at 9:24 PM, Yan Tang wrote:
Hi,
I noticed there is an odd issue when I am trying to convert a recarray to
list. See below for the example/test case.
$ cat a.csv
date,count
2011-07-25,91
2011-07-26,118
$ cat b.csv
name,count
foo,1233
bar,100
$ python
from
On Jul 9, 2012, at 10:32 PM, Charles R Harris wrote:
Hi All,
I've been adding type specific sorts for object and structured arrays. It
seems that datetime64 and timedelta64 are also not supported. Is there any
reason why those types should not be sorted as int64?
Also, when sorting
Andrew,
Thank you for your comments. I agree it's confusing coming to github at
first. I still have to refer to the jargon-file to understand what everything
means. There are a lot of unfamiliar terms.
Thank you for your patches. It does imply more work for developers on NumPy,
appreciate any experience with Windows nodes.
Best regards,
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Jul 2, 2012, at 7:18 PM, Stéfan van der Walt ste...@sun.ac.za wrote:
On Mon, Jul 2, 2012 at 5:31 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
Yes, definitely. I will have
This is the expected behavior. It is not a bug.
NumPy arrays after pickling are views into the String that is created by the
pickling machinery. Thus, the base is set. This was done to avoid an
additional memcpy.
This avoids a copy, but yes, it does mean that you can't resize the array
On Jun 27, 2012, at 1:18 AM, Fernando Perez wrote:
On Tue, Jun 26, 2012 at 11:02 PM, Travis Oliphant tra...@continuum.io wrote:
I just want to speak up for the people who are affected by API breakage who
are not as vocal on this list.
Certainly! And indeed I bet you that's a community
Hey all,
I'd like to propose dropping support for Python 2.4 in NumPy 1.8 (not the 1.7
release). What does everyone think of that?
-Travis
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
Yes, the creation of the tmp *is* the creation of a new NumPy array. So, it
is as expensive.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Jun 28, 2012, at 12:44 AM, srean srean.l...@gmail.com wrote:
Yes it does. If you want to avoid this extra copy, and have a
pre-existing
There are some good ideas here.
I propose splitting this list into devel and users lists.
This might best be done by creating a new list for users and using this list
for development.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Jun 27, 2012, at 11:38 PM, srean srean.l
--
Travis Oliphant
(on a mobile)
512-826-7480
On Jun 28, 2012, at 1:20 AM, Pierre Haessig pierre.haes...@crans.org wrote:
Le 28/06/2012 02:34, Nathaniel Smith a écrit :
Yes it does. If you want to avoid this extra copy, and have a
pre-existing output array, you can do:
np.add(a, b
On Jun 27, 2012, at 12:59 AM, Fernando Perez wrote:
On Tue, Jun 26, 2012 at 10:25 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
On Tue, Jun 26, 2012 at 5:33 AM, Travis Oliphant tra...@continuum.io
wrote:
...
What should have happened in this case, in my mind, is that NumPy 1.4.0
should
Great. Yes, the Travis-CI stuff looks great. There are a lot of good CI
things happening on a lot of fronts.
It is encouraging to see.
It would be good to consolidate them --- or at least have a place to go to look
at output from many of them.
Travis
--
Travis Oliphant
(on a mobile
This is cool. It would be nice to put these things somewhere where they could
be available for reference.
-Travis
On Jun 27, 2012, at 10:20 AM, Virgil Stokes wrote:
On 27-Jun-2012 11:40, klo uo wrote:
I continued in this mpl trip, with small animation sequence:
It would be really awesome to have a script like this to generate the logo.
That's pretty amazing. Would you be able to tweak it up a bit and then we
could take a poll here? Perhaps we change the logo to a variation of what
your script produces.
Can you export a PNG?
-Travis
On Jun
On Jun 26, 2012, at 9:00 AM, Charles R Harris wrote:
On Mon, Jun 25, 2012 at 9:10 PM, Ondřej Čertík ondrej.cer...@gmail.com
wrote:
On Mon, Jun 25, 2012 at 7:38 PM, Fernando Perez fperez@gmail.com wrote:
On Mon, Jun 25, 2012 at 6:39 PM, Travis Oliphant tra...@continuum.io
wrote
(I have not read the whole cython discussion yet)
So here's the summary. It's rather complicated but also incredibly neat
:-) And technical details can be hidden behind a tight API.
Could you provide a bit more context for this list. I think this is an
important technology concept.
Hey all,
After some more investigation, I'm not optimistic that we will be able to get a
1.7 release out before SciPy. I would like to get a beta release out by SciPy
(or even an rc1 release). But, given the number of code changes and
differences between 1.5.x and 1.7, I think we will
Let us note that that problem was due to Travis convincing David to include
the Datetime work in the release against David's own best judgement. The
result was a delay of several months until Ralf could get up to speed and
get 1.4.1 out. Let us also note that poly1d is actually not the
On Jun 26, 2012, at 11:29 AM, Thouis (Ray) Jones wrote:
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
I think Chuck alludes to the fact that I was rather reserved about
merging datetime before *anyone* knew about breaking the ABI. I don't
feel responsible for this issue (except I maybe should have pushed
more strongly about datetime being included), but I am also not
interested in making a
On Jun 26, 2012, at 11:46 AM, John Salvatier wrote:
Hello,
If you increment an array using advanced indexing and have repeated indexes,
the array doesn't get repeatedly incremented,
http://comments.gmane.org/gmane.comp.python.numeric.general/50291. I wrote a
C function that does
Or, we could raise funds for NumFOCUS by selling tickets for a brawl between
the two at SciPy2012...
I kid, I kid!
Thanks for the humor. Unfortunately, I would be no match physically with
someone used to the cold of Logan :-)
-Travis
, 2012 at 9:57 AM, Travis Oliphant tra...@continuum.io
wrote:
On Jun 26, 2012, at 11:46 AM, John Salvatier wrote:
Hello,
If you increment an array using advanced indexing and have repeated
indexes, the array doesn't get repeatedly
incremented,
http://comments.gmane.org
On Jun 26, 2012, at 2:10 PM, Ralf Gommers wrote:
On Tue, Jun 26, 2012 at 5:43 PM, Travis Oliphant tra...@continuum.io wrote:
Hey all,
After some more investigation, I'm not optimistic that we will be able to get
a 1.7 release out before SciPy. I would like to get a beta release
I think we need to update this document:
http://projects.scipy.org/numpy/wiki/ApiDeprecation
I don't think this characterizes the opinion of all involved in NumPy
development (it is certainly not the way I view our commitment to users).
Incidentally, in the migration from Trac we should
Exactly.
I don't
feel responsible for this issue (except I maybe should have pushed
more strongly about datetime being included),
I think you left out a 'not'. I don't mean to imply that you were in anyway
the blame. And you have been pretty adamant about not allowing late merges of
Unfortunately, I think there are issues we are just now seeing with code that
was released in 1.6.x, and there are many people who have not moved forward
to 1.6.x yet.
Some examples would be nice. A lot of people did move already. And I haven't
seen reports of those that tried
On Jun 26, 2012, at 3:27 PM, Thouis (Ray) Jones wrote:
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
For the main repos we use buildbot and test on:
Ubuntu Maverick 32-bit
Debian sid 64-bit
OSX 10.4 PPC
OSX 10.5 Intel
Debian wheezy PPC
Debian squeeze ARM (a Raspberry PI no less)
WIndows XP 32 bit
SPARC (courtesy of our friends at NeuroDebian)
http://nipy.bic.berkeley.edu/builders
In my enthusiasm of finding someone to help with the release of NumPy 1.7 and
my desire to get something released by the SciPy conference, I was hasty and
didn't gather enough feedback from others about the release of NumPy 1.7. I'm
sorry about that.
I would like to get NumPy 1.7 out the
C was famous for bugs due to the lack of function prototypes. This was fixed
with C99 and the stricter typing was a great help.
Bugs are not due to lack of function prototypes. Bugs are due to mistakes
that programmers make (and I know all about mistakes programmers make).
Function
---
not whether one is 'right' or not. That is a different discussion entirely.
--
Travis Oliphant
(on a mobile)
512-826-7480
On Jun 25, 2012, at 7:01 PM, Charles R Harris charlesr.har...@gmail.com wrote:
On Mon, Jun 25, 2012 at 4:21 PM, Perry Greenfield pe...@stsci.edu wrote:
On Jun 25, 2012, at 3
On Jun 25, 2012, at 7:21 PM, Fernando Perez wrote:
On Mon, Jun 25, 2012 at 5:10 PM, Travis Oliphant tra...@continuum.io wrote:
You are still missing the point that there was already a choice that was
made in the previous class --- made in Numeric actually.
You made a change
On Jun 25, 2012, at 7:53 PM, josef.p...@gmail.com wrote:
On Mon, Jun 25, 2012 at 8:25 PM, josef.p...@gmail.com wrote:
On Mon, Jun 25, 2012 at 8:10 PM, Travis Oliphant tra...@continuum.io wrote:
You are still missing the point that there was already a choice that was
made in the previous
On Jun 25, 2012, at 9:38 PM, Fernando Perez wrote:
On Mon, Jun 25, 2012 at 6:39 PM, Travis Oliphant tra...@continuum.io wrote:
On Jun 25, 2012, at 7:21 PM, Fernando Perez wrote:
For context, consider that for many years, the word gratuitous has been
used in a non-derogatory way
That's a nice argument for a different convention, really it is. It's not
enough for changing a convention that already exists. Now, the polynomial
object could store coefficients in this order, but allow construction with
the coefficients in the standard convention order. That would
I just want to note that I'm not advocating for *any*
backwards-compatibility breakage in numpy at this point... I was just
providing context for a discussion that happened back in 2009, and in
the scipy list. I certainly feel pretty strongly at this point about
the importance of
On Jun 25, 2012, at 10:35 PM, David Cournapeau wrote:
On Tue, Jun 26, 2012 at 4:10 AM, Ondřej Čertík ondrej.cer...@gmail.com
wrote:
My understanding is that Travis is simply trying to stress We have to
think about the implications of our changes on existing users. and
also that little
In the present climate, I'm going to have to provide additional context to a
comment like this. This is not an accurate enough characterization of
events. I was trying to get date-time changes in, for sure. I generally
like feature additions to NumPy. (Robert Kern was also involved
On Jun 26, 2012, at 12:09 AM, Fernando Perez wrote:
On Mon, Jun 25, 2012 at 9:48 PM, Travis Oliphant tra...@continuum.io wrote:
I agree a decision needs to be made. I think we will need to break the
ABI.At this point, I don't know of any pressing features that would
require it short
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, when I
suggested going to the github issue tracking, I opened a discussion
On Jun 23, 2012, at 4:23 AM, Thouis (Ray) Jones wrote:
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
On Jun 23, 2012, at 7:12 AM, Charles R Harris wrote:
On Sat, Jun 23, 2012 at 3:23 AM, Thouis (Ray) Jones tho...@gmail.com wrote:
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
Accessing individual elements of NumPy arrays is slower than accessing
individual elements of lists --- around 2.5x-3x slower.NumPy has to do more
work to figure out what kind of indexing you are trying to do because of its
flexibility. It also has to create the Python object to return.
-Travis
However, what is the timing/memory cost of converting a large numpy array
that already exists into python list of lists? If all my processing before
the munkres step is using NumPy, converting it into python lists has a cost.
Also, your timings indicate only ~2x slowdown,
The usual practice is to announce a schedule first.
I just did announce the schedule.
There is time before the first Release candidate to make changes on the 1.7.x
branch. If you want to make the changes on master, and just indicate the
Pull requests, Ondrej can make sure they
Hey all,
I made a branch called with_maskna and then merged Nathaniel's PR which removes
the mask_na support from master. I then applied a patch to fix the boolean
indexing problem reported by Ralf.
I then created a NumPy 1.7.x maintenance branch from which the release of NumPy
1.7 will
This is definitely in-line with the purpose of the foundation and so we'll make
the donation. Thanks, for letting us know.
Best,
-Travis
On Jun 16, 2012, at 3:16 PM, Nathaniel Smith wrote:
Thanks to Marc Abramowitz[1], Numpy commits are now being tested by Travis-CI:
I think we should go ahead and merge this PR. It would be ideal to make a
branch with the current code and then merge this into master.
I haven't had the time to do this. If you can do this Nathaniel, then it will
really help with 1.7 release.
Thanks,
-Travis
On Jun 14, 2012, at 11:17
On Jun 14, 2012, at 1:53 PM, James Bergstra wrote:
On Thu, Jun 14, 2012 at 11:01 AM, Nathaniel Smith n...@pobox.com wrote:
Indeed that would be great as sympy already has already excellent math
expression rendering.
An alternative would be to output mathml or something similar that
On Jun 9, 2012, at 4:45 PM, josef.p...@gmail.com wrote:
Is there a way to convert an array to string elements in numpy,
without knowing the string length?
Not really. In the next release of NumPy you should be able to do.
result = array(arr2, str)
and it will determine the length of the
It is unfortunate that this was committed to master. This should be backed out
and is a blocker for 1.7. Can someone help me identify which commit made the
change?
This is a rather significant change and changes the documented behavior of
NumPy substantially. This should definitely not
During the original discussion, Gael pointed out that the changes would
probably break some code (which might need to be cleaned up but still). I
think it was underestimated how quickly people would upgrade and see the
changes and therefore be able to report problems.
We are talking about
I don't think that would work, because looking more closely, I don't
think they're actually doing anything like what
__array_interface__/PEP3118 are designed for. They just have some
custom class (sage.rings.real_mpfr.RealLiteral, I guess an arbitrary
precision floating point of some
There is an interesting project called http://huboard.com/The projects
suggests using a few Column Labels that provides a nice card-based window onto
the Github issues.
I have turned on issue tracking and started a few labels. Feel free to add
more / adjust the names as appropriate.
Can you raise an issue on the Github issue tracker for NumPy? These issues
will be looked at more closely. This kind of change should not have made it
in to the release.
off-topic
Given the lack of availability of time from enough experts in NumPy, this is
the sort of thing that can
Using the 'h2' is redundant, but it should not have been changed so quickly.
I could see raising a deprecation warning and communicating the correct
spelling ('i2').
-Travis
On Jun 3, 2012, at 6:45 PM, Benjamin Root wrote:
On Sunday, June 3, 2012, Ralf Gommers wrote:
On Sun,
Be sure to file a ticket...
-Travis
On May 30, 2012, at 9:05 PM, chris farrow wrote:
Hi all,
I encountered an odd bug today that I wanted to bring to everyone's
attention. First the code:
import numpy as np
shape = (8, 8)
dtype = np.dtype(np.uint8)
image = np.random.randint(0,
On May 28, 2012, at 1:02 PM, Ralf Gommers wrote:
On Mon, May 28, 2012 at 7:58 PM, Travis Oliphant tra...@continuum.io wrote:
I didn't see anyone respond to this, but looking over his simple and elegant
solution it seems like a useful addition to the 2-d functions available in
NumPy
On May 23, 2012, at 8:02 AM, Olivier Delalleau wrote:
2012/5/23 Nathaniel Smith n...@pobox.com
On Wed, May 23, 2012 at 6:06 AM, Travis Oliphant tra...@continuum.io wrote:
I just realized that the pull request doesn't do what I thought it did which
is just add the flag to warn users who
issue or more than likely their aren't enough voices being
heard from real users.
-Travis
On May 23, 2012, at 3:01 PM, Dag Sverre Seljebotn wrote:
On 05/23/2012 10:00 PM, Dag Sverre Seljebotn wrote:
On 05/23/2012 07:29 PM, Travis Oliphant wrote:
On May 23, 2012, at 8:02 AM, Olivier
will end up with two copies for 1.7.
-Travis
On May 16, 2012, at 3:51 PM, Travis Oliphant wrote:
This Pull Request looks like a good idea to me as well.
-Travis
On May 16, 2012, at 3:10 PM, Ralf Gommers wrote:
On Wed, May 16, 2012 at 3:55 PM, Nathaniel Smith n...@pobox.com
This is the right place to ask, it's just that it can take time to get an
answer because people who might know the answer may not have the time to
respond immediately.
The short answer is that this is not really a normal bug, but it could be
considered a design bug (although the issues may
Just to be clear. Are we waiting for the conclusion of the PyArray_Diagonal
PR before proceeding with this one?
-Travis
On May 20, 2012, at 1:06 PM, Nathaniel Smith wrote:
On Sun, May 20, 2012 at 6:59 PM, Nathaniel Smith n...@pobox.com wrote:
I have not reviewed it in detail, but in
Documentation helps are always welcome.
Please make sure to advertise widely, though, that the new Polynomial class
changes the ordering convention of the coefficients away from the Matlab
standard.
I think this will be a point of confusion unless it is carefully documented.
It's also why
101 - 200 of 678 matches
Mail list logo
