On Monday, July 23, 2012, OC wrote:
> > It's unPythonic just in the sense that it is unlike every other type
> > constructor in Python. int(x) returns an int, list(x) returns a list,
> > but np.complex64(x) sometimes returns a np.complex64, and sometimes it
> > returns a np.ndarray, depending
> It's unPythonic just in the sense that it is unlike every other type
> constructor in Python. int(x) returns an int, list(x) returns a list,
> but np.complex64(x) sometimes returns a np.complex64, and sometimes it
> returns a np.ndarray, depending on what 'x' is.
This "object factory" design
On Sat, Jul 21, 2012 at 4:44 PM, OC wrote:
> Thank you for your answers.
>
> Chris Barker wrote:
> > for consistency with the rest of the numpy types
>
> Then, why do "numpy.complex64(A)", "numpy.complex128(A)",
> "numpy.uint8(A)",... all work with arrays? It's very convenient that it
> works lik
Thank you for your answers.
Chris Barker wrote:
> for consistency with the rest of the numpy types
Then, why do "numpy.complex64(A)", "numpy.complex128(A)",
"numpy.uint8(A)",... all work with arrays? It's very convenient that it
works like this! It's awkward that "numpy.complex(A)" is the only
20.07.2012 22:17, OC kirjoitti:
> The syntax "numpy.complex(A)" seems to be the most natural and obvious
> thing a user would want for casting an array A to complex values.
I think I disagree here -- that something like that works at all is
rather surprising. Remember that
numpy.complex,
On Fri, Jul 20, 2012 at 1:17 PM, OC wrote:
>> numpy.complex is just a reference to the built in complex, so only works
>> on scalars:
> What is the use of storing the "complex()" built-in function in the
> numpy namespace, when it is already accessible from everywhere?
for consitancy with teh r
The syntax "numpy.complex(A)" seems to be the most natural and obvious
thing a user would want for casting an array A to complex values.
Expressions like "A.astype(complex)", "array(A, dtype=complex)",
"numpy.complex128(A)" are less obvious, especially the last two ones,
which look a bit far-fe
On 18 July 2012 15:14, Molinaro Céline
wrote:
> Hello,
>
> In [2]: numpy.real(arange(3))
> Out[2]: array([0, 1, 2])
> In [3]: numpy.complex(arange(3))
> TypeError: only length-1 arrays can be converted to Python scalars
I think you're looking for the dtype keyword to the ndarray constructor:
imp
On Wed, 2012-07-18 at 15:14 +0200, Molinaro Céline wrote:
> In [2]: numpy.real(arange(3))
> Out[2]: array([0, 1, 2])
> In [3]: numpy.complex(arange(3))
> TypeError: only length-1 arrays can be converted to Python scalars
>
>
> Are there any reasons why numpy.complex doesn't work on arrays?
> Shou
Hello,
In [2]: numpy.real(arange(3))
Out[2]: array([0, 1, 2])
In [3]: numpy.complex(arange(3))
TypeError: only length-1 arrays can be converted to Python scalars
Are there any reasons why numpy.complex doesn't work on arrays?
Should it be bug reported?
Thanks for your help
C. Molinaro
Neal Becker wrote:
> [EMAIL PROTECTED] wrote:
>
>
>> In creating an array of type numpy.complex128, I'm having problems
>> passing in Sage types that should be considered complex numbers since
>> they implement the standard __complex__ method. However, numpy doesn't
>> recognize that. Here's a
[EMAIL PROTECTED] wrote:
> In creating an array of type numpy.complex128, I'm having problems
> passing in Sage types that should be considered complex numbers since
> they implement the standard __complex__ method. However, numpy doesn't
> recognize that. Here's a minimal example:
>
I had tri
In creating an array of type numpy.complex128, I'm having problems
passing in Sage types that should be considered complex numbers since
they implement the standard __complex__ method. However, numpy doesn't
recognize that. Here's a minimal example:
In [1]: class MyNum:
...: def __comp
13 matches
Mail list logo
