I wasn't at all arguing that having complex data chopped and
downcast into an int or float container was the right thing to do.
indeed, it is an clearly bad thing to do -- but a bug magnet? I'm not so
sure, surely, anyone that had any idea at all what they were doing with
complex numbers
There are two related hierarchies of datatypes: different kinds
(integer,
floating point, complex floating point) and different precisions
within a given
kind (int8, int16, int32, int64). The term downcasting should
probably be
reserved for the latter only.
It seems to me that Zach
On Jan 3, 2008, at 18:29 , Steve Lianoglou wrote:
Anyway, somewhere in my codebase (for a long time now) I'm doing:
from numpy.matlib import *
Now, when I try to use this code, or just type that in the
interpreter, I get this message:
AttributeError: 'module' object has no attribute
On Jan 4, 2008, at 13:58 , Fernando Perez wrote:
My vote so far is for hg, for performance reasons but also partly
because sage and sympy already use it, two projects I'm likely to
interact a lot with and that are squarely in line with the
ipython/numpy/scipy/matplotlib world. Since they
On Jan 5, 2008 12:08 PM, David M. Cooke [EMAIL PROTECTED] wrote:
On Jan 4, 2008, at 13:58 , Fernando Perez wrote:
My vote so far is for hg, for performance reasons but also partly
because sage and sympy already use it, two projects I'm likely to
interact a lot with and that are squarely in
On Jan 5, 2008 8:15 PM, Fernando Perez [EMAIL PROTECTED] wrote:
On Jan 5, 2008 12:08 PM, David M. Cooke [EMAIL PROTECTED] wrote:
On Jan 4, 2008, at 13:58 , Fernando Perez wrote:
My vote so far is for hg, for performance reasons but also partly
because sage and sympy already use it, two
David M. Cooke wrote:
On Jan 4, 2008, at 13:58 , Fernando Perez wrote:
My vote so far is for hg, for performance reasons but also partly
because sage and sympy already use it, two projects I'm likely to
interact a lot with and that are squarely in line with the
This is the behaviour you'd get if the module's __all__ attribute
lists objects which don't exist in the module. Looks like a regression
in r4659; fixed in SVN now as r4674.
Thanks!
-steve
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
On Sat, Jan 05, 2008 at 03:00:21PM -0600, Travis E. Oliphant wrote:
I suspect there are others with serious reservations about jumping off
of SVN just now (just when a lot of people have finally figured out how
to use it).
I recall something you said to David last week, regarding merges with
I'd like to briefly provide a different perspective on this question,
which is not a technical one but a more social/process one.
It seems to me (but I could be wrong; this is opinion, not research!)
that a DVCS encourages a more open participation model for newcomers.
Since anyone with a
On Jan 6, 2008 8:25 AM, Stefan van der Walt [EMAIL PROTECTED] wrote:
I recall something you said to David last week, regarding merges with
SVN: that a person never knows how to do it until *after* you've done
it! We often make branches in scipy and numpy, and stand a lot to
gain from a
Hi Pierre
On Fri, Jan 04, 2008 at 04:30:47PM -0500, Pierre GM wrote:
Here's a patch to the current version of svn/numpy/branches/maskedarray, that
corrects several bugs.
Those tests at the end of core.py should be included in the test suite
before we commit (otherwise they won't be ran by
Fernando Perez fperez.net at gmail.com writes:
Incidentally, the emacs guys seem to be worrying about the same thing:
http://thread.gmane.org/gmane.emacs.devel/85893
If they actually do the work of comparing tools, that work may be
useful for us. I'm pretty sure that any tool that can
On Jan 5, 2008 4:38 PM, Robert Kern [EMAIL PROTECTED] wrote:
Chris Barker wrote:
hmmm. Everyone posting so far seems to be positive on this idea, but I'm
not so sure. A few thoughts:
1) change is bad. It may be worth it, but this decision needs to be made
very differently than if we
Travis E. Oliphant wrote:
David M. Cooke wrote:
On Jan 4, 2008, at 13:58 , Fernando Perez wrote:
My vote so far is for hg, for performance reasons but also partly
because sage and sympy already use it, two projects I'm likely to
interact a lot with and that are squarely in line with the
15 matches
Mail list logo
