So my question is: how can one reliably detect singularity (or
near singularity) and raise an exception?
Matrix condition number:
http://docs.scipy.org/doc/numpy/reference/generated/numpy.linalg.cond.html
http://en.wikipedia.org/wiki/Condition_number
Stuart
On Tue, 1 Jul 2008, Pauli Virtanen wrote:
Tue, 01 Jul 2008 17:18:55 -0400, Stuart Brorson wrote:
I have noticed a change in the behavior of numpy.flatten(True) between
NumPy 1.0.4 and NumPy 1.1. The change affects 3D arrays. I am
wondering if this is a bug or a feature.
[...]
To me
])
In [5]: A.flatten(True)
Out[5]: array([ 1, 5, 9, 3, 7, 11, 2, 6, 10, 4, 8, 12])
Note that the output of A.flatten(True) is different.
Is this a bug or a feature?
Cheers,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http
solicit the opinions
of other folks in the NumPy community about the proper behavior of
numpy.sign(numpy.nan).
Cheers,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http://www.interactivesupercomputing.com
** 0^0: This is problematic.
Accessible discussion:
URL:http://en.wikipedia.org/wiki/Exponentiation#Zero_to_the_zero_power
Thanks. That was quite informative. Indeed, I communicated with a
math professor at MIT who also more or less convinced me that 0^0 = 1.
Stuart
, -1)
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: math domain error
Why isn't this one inf?
Also, what do these specs say about 0^complex?
Cheers,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http
1. + 1.i
A .^ B
ans =
Inf 1. NaN +NaNi
Any reactions to this? Does NumPy just make library calls when
computing power, or does it do any trapping of corner cases? And
should the returns from power conform to the above suggestions?
Regards,
Stuart Brorson
and Im parts.
Or am I wrong?
Cheers,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http://www.interactivesupercomputing.com/
[1] Sorry for whining, by the way! I'm just poking at the boundaries of
NumPy's feature envelope and trying to see how self
implement round for complex args, then you need to also support ceil,
floor, and fix for complex args, so it's a bug. But I thought I'd ask
the developers what they thought before filing a ticket.
Regards,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http
to do a greater-than or less-than type operation involving
complex numbers. This would force the user to explicitly take the
magnitude or the real imaginary part of his number before doing any
comparisons, thereby eliminating any confusion due to ambiguity.
Just my $0.02.
Cheers,
Stuart Brorson
array is a different
question, and I am agnostic about that one.
Cheers,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http://www.interactivesupercomputing.com/
___
Numpy-discussion mailing list
Numpy
-monotonically increasing bins can lead to confusing or
inexplicable results.
On the other hand, I would support the idea of a new function
numpy.countunique() as you suggest.
Just my two cents...
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http
.
Cheers,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http://www.interactivesupercomputing.com/
On Wed, 23 Jan 2008, Mark.Miller wrote:
Greetings: I just noticed a changed behavior of numpy.histogram. I
think that a recent 'fix' to the code has
math, after all!
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http://www.interactivesupercomputing.com/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman
On Fri, 4 Jan 2008, Stuart Brorson wrote:
I just discovered this today. It looks like a bug to me. Please
flame me mercilessly if I am wrong! :-)
FWIW, here's what Matlab does:
A = rand(1, 4) + rand(1, 4)*i
A =
Columns 1 through 3
0.7833 + 0.7942i 0.6808 + 0.0592i 0.4611
variables is to barf -- throw an exception.
At least that's what I would expect.
Comments?
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http://www.interactivesupercomputing.com/
--- session log -
In [77
into the tracking system.
By the way, this is NumPy 1.0.4:
In [39]: numpy.__version__
Out[39]: '1.0.4'
Cheers,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http://www.interactivesupercomputing.com/
-- session log
take a long time if your matrices are
large.
Cheers,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http://www.interactivesupercomputing.com/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http
from array elements to array elements) I can see if I can figure out
how to fix it then submit a patch. But I won't promise anything!
My brain hurts already after analyzing this feature. :-)
Cheers,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452
)]
Cheers,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http://www.interactivesupercomputing.com/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo
the
old P3 chip couldn't handle.
Can the developers confirm or deny my hypothesis?
Thanks,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http://www.interactivesupercomputing.com/
___
Numpy-discussion mailing
Guys --
I'm a little puzzled by a NumPy behavior. Perhaps the gurus on this
list can enlighten me, please!
I am working with numpy.histogram. I have a decent understanding of
how it works when given an ascending range to bin into. However, when
I give it a *decending* range, I can't figure
Robert,
Thanks for your answers about histogram's meaning for range=(7, 0)!
* If it truely isn't meaningful, why not catch the case and reject
input? Maybe this is a bug ???
Patches are welcome.
OK. I don't know if you have a patch tracking system, so I'll just
post it here. If you
OK. I don't know if you have a patch tracking system, so I'll just
post it here. If you have a patch tracker, point me to it and I'll
enter the patch there.
http://projects.scipy.org/scipy/numpy
OK, entered as ticket #586.
Cheers,
Stuart
___
Thank you for your answer!
As a NumPy newbie, I am still learning things about NumPy which I didn't
expect. Today I learned that for a matrix of complex numbers,
numpy.max() returns the element with the largest *real* part, not the
element with the largest *magnitude*.
There isn't a
On Fri, 21 Sep 2007, Robert Kern wrote:
Stuart Brorson wrote:
Is it NumPy's goal to be as compatible with Matlab as possible?
No.
OK, so that's fair enough. But how about self-consistency?
I was thinking about this issue as I was biking home this evening.
To review my question
Is it NumPy's goal to be as compatible with Matlab as possible?
No.
OK, so that's fair enough. But how about self-consistency?
I was thinking about this issue as I was biking home this evening.
To review my question:
a
array([[ 1. +1.j , 1. +2.j ],
[ 2. +1.j , 1.9+1.9j]])
No. It is a matter of sorting first on the real part, and then resolving
duplicates by sorting on the imaginary part. The magnitude is not used:
[snip]
Oh, OK. So the ordering algorithm for complex numbers is:
1. First sort on real part.
2. Then sort on imag part.
Right?
Stuart
On Fri, 21 Sep 2007, David Goldsmith wrote:
Not to be snide, but I found this thread very entertaining, as,
precisely because there is no single, well-defined (partial) ordering of
C, I regard it as poor coding practice to rely on whatever partial
ordering the language you're using may (IMO
29 matches
Mail list logo
