Menu
▾
▴
numpy-discussion
|
From: George S. <geo...@gm...> - 2006-11-03 19:11:00
|
Can anyone explain this ?
>>> import numpy as N
>>> x = N.arange(1,6,dtype='B')
>>> x
array([1, 2, 3, 4, 5], dtype=uint8)
>>> N.repeat(x, N.ones(5,'H'))
array([1, 2, 3, 4, 5], dtype=uint8)
>>> N.repeat(x, N.ones(5,'l'))
array([1, 2, 3, 4, 5], dtype=uint8)
>>> N.repeat(x, N.ones(5,'L'))
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File
"/usr/local/lib/python2.4/site-packages/numpy/core/fromnumeric.py",
line 83, in repeat
return repeat(repeats, axis)
TypeError: array cannot be safely cast to required type
Thanks,
George
|
|
From: Tim H. <tim...@ie...> - 2006-11-03 19:43:43
|
George Sakkis wrote:
> Can anyone explain this ?
>
>
>>>> import numpy as N
>>>> x = N.arange(1,6,dtype='B')
>>>> x
>>>>
> array([1, 2, 3, 4, 5], dtype=uint8)
>
>>>> N.repeat(x, N.ones(5,'H'))
>>>>
> array([1, 2, 3, 4, 5], dtype=uint8)
>
>>>> N.repeat(x, N.ones(5,'l'))
>>>>
> array([1, 2, 3, 4, 5], dtype=uint8)
>
>>>> N.repeat(x, N.ones(5,'L'))
>>>>
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File
> "/usr/local/lib/python2.4/site-packages/numpy/core/fromnumeric.py",
> line 83, in repeat
> return repeat(repeats, axis)
> TypeError: array cannot be safely cast to required type
>
It means you can't safely a value of type uint32 ('L') to a value of
type int32 ('i'). The second argument of repeat needs to be castable to
type int32.
A style note: please use the named dtypes (int32, uint32, etc) rather
than the old-style letter codes; the former is much clearer. The answer
to your question might have been immediately apparent had you been
using named dtypes.
Personally, I'd also prefer people use the "ones([n])" syntax instead
of the I-wish-it-were-deprecated-but-it's-too-much-to-hope-for "ones(n)"
syntax. T
-tim
|
|
From: George S. <geo...@gm...> - 2006-11-03 20:25:55
|
Tim Hochberg wrote:
> George Sakkis wrote:
> > Can anyone explain this ?
> >
> >
> >>>> import numpy as N
> >>>> x = N.arange(1,6,dtype='B')
> >>>> x
> >>>>
> > array([1, 2, 3, 4, 5], dtype=uint8)
> >
> >>>> N.repeat(x, N.ones(5,'H'))
> >>>>
> > array([1, 2, 3, 4, 5], dtype=uint8)
> >
> >>>> N.repeat(x, N.ones(5,'l'))
> >>>>
> > array([1, 2, 3, 4, 5], dtype=uint8)
> >
> >>>> N.repeat(x, N.ones(5,'L'))
> >>>>
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in ?
> > File
> > "/usr/local/lib/python2.4/site-packages/numpy/core/fromnumeric.py",
> > line 83, in repeat
> > return repeat(repeats, axis)
> > TypeError: array cannot be safely cast to required type
> >
> It means you can't safely a value of type uint32 ('L') to a value of
> type int32 ('i'). The second argument of repeat needs to be castable to
> type int32.
I see. I suppose there is a better reason for this than a "why on earth
would anyone repeat a value more than 2**32-1 times". Besides, why
should it be castable to a signed type since we're talking about number
of repetitions ?
> A style note: please use the named dtypes (int32, uint32, etc) rather
> than the old-style letter codes; the former is much clearer. The answer
> to your question might have been immediately apparent had you been
> using named dtypes.
I'm using numpy along with the struct module, so the letter codes are
convenient for talking to both modules.
George
|
|
From: Tim H. <tim...@ie...> - 2006-11-03 20:39:31
|
George Sakkis wrote:
> Tim Hochberg wrote:
>
>
>> George Sakkis wrote:
>>
>>> Can anyone explain this ?
>>>
>>>
>>>
>>>>>> import numpy as N
>>>>>> x = N.arange(1,6,dtype='B')
>>>>>> x
>>>>>>
>>>>>>
>>> array([1, 2, 3, 4, 5], dtype=uint8)
>>>
>>>
>>>>>> N.repeat(x, N.ones(5,'H'))
>>>>>>
>>>>>>
>>> array([1, 2, 3, 4, 5], dtype=uint8)
>>>
>>>
>>>>>> N.repeat(x, N.ones(5,'l'))
>>>>>>
>>>>>>
>>> array([1, 2, 3, 4, 5], dtype=uint8)
>>>
>>>
>>>>>> N.repeat(x, N.ones(5,'L'))
>>>>>>
>>>>>>
>>> Traceback (most recent call last):
>>> File "<stdin>", line 1, in ?
>>> File
>>> "/usr/local/lib/python2.4/site-packages/numpy/core/fromnumeric.py",
>>> line 83, in repeat
>>> return repeat(repeats, axis)
>>> TypeError: array cannot be safely cast to required type
>>>
>>>
>> It means you can't safely a value of type uint32 ('L') to a value of
>> type int32 ('i'). The second argument of repeat needs to be castable to
>> type int32.
>>
>
> I see. I suppose there is a better reason for this than a "why on earth
> would anyone repeat a value more than 2**32-1 times". Besides, why
> should it be castable to a signed type since we're talking about number
> of repetitions ?
>
I suspect it's just a matter of simplicity although I haven't looked at
the code in question. On the way in all of the arrays are going to need
to be cast to some standard integral type. While unit32 might make
sense, int32 is by far the more common type. If one was to use uint32 as
the type, before casting int32 to uint32, one would have to scan the
array looking for negative values lest they get cast into really big
positive values. An analogous problem exists for casting uint32 to
int32, but since unit32 is rather uncommon, one can just make users do
the necessary checking and casting by hand and probably someone will
only notice every couple of years.
>> A style note: please use the named dtypes (int32, uint32, etc) rather
>> than the old-style letter codes; the former is much clearer. The answer
>> to your question might have been immediately apparent had you been
>> using named dtypes.
>>
>
> I'm using numpy along with the struct module, so the letter codes are
> convenient for talking to both modules.
>
I imagine they are, but they're harder for me, and I suspect many
others, to remember. Your more likely to get a useful answer if your
readers don't have to go look stuff up.
-tim
|
|
From: Colin J. W. <cj...@sy...> - 2006-11-04 12:30:27
|
Tim Hochberg wrote: [snip] > A style note: please use the named dtypes (int32, uint32, etc) rather > than the old-style letter codes; the former is much clearer. The answer > to your question might have been immediately apparent had you been > using named dtypes. > > +1 > Personally, I'd also prefer people use the "ones([n])" syntax instead > of the I-wish-it-were-deprecated-but-it's-too-much-to-hope-for "ones(n)" > syntax. T > > -tim > > Could you elaborate please? Colin W. |
|
From: Tim H. <tim...@ie...> - 2006-11-04 20:23:28
|
Colin J. Williams wrote:
> Tim Hochberg wrote:
> [snip]
>
>> A style note: please use the named dtypes (int32, uint32, etc) rather
>> than the old-style letter codes; the former is much clearer. The answer
>> to your question might have been immediately apparent had you been
>> using named dtypes.
>>
>>
>>
> +1
>
>> Personally, I'd also prefer people use the "ones([n])" syntax instead
>> of the I-wish-it-were-deprecated-but-it's-too-much-to-hope-for "ones(n)"
>> syntax. T
>>
>> -tim
>>
>>
>>
> Could you elaborate please?
>
>
Sure. The general form of the zeros function, and several others[1], is:
zeros(shape, dtype)
Here 'shape' is a sequence of one sort or another. There's also a
second form that's applicable only to one dimensional arrays:
zeros(length, dtype)
Where length is an integer. I don't recall if this is a historical
legacy or is intended as a convenience function or a bit of both. Either
way, the result is that there are two ways to spell "give me a 1D array
of zeros with a given length and dtype":
zeros([length], dtype)
and
zeros(length, dtype)
I have two issues with having this second spelling. First, it's one more
thing to remember. Whenever I see the scalar spelling I have to use a
little bit extra of my limited brainpower to remember that it is not in
fact a typo, but is instead a shortcut. The second issue is pedagogical.
If people are initially exposed to the first form, the extension to
multiple dimensions is straightforward. They'll probably guess the
correct way right off the bat, and if not, they'll get it right away
when it's explained. On the other hand, if they are initially exposed to
the second form, the multidimensional form is far from obvious. In
addition, they'll probably spend a long time thinking that the
one-dimensional way is the normal way, but that we have to jump through
weird hoops to get multidimensional arrays to work. That's bad
propaganda for numpy. This all seems like a rather large price to pay to
avoid typing the occasional pair of brackets.
That's my two cents. Just say not to form #2.
-tim
... [1] Yes, I'm neglecting the order parameter; I don't think it
matters for this discussion.
|
|
From: Stefan v. d. W. <st...@su...> - 2006-11-06 21:43:03
|
On Mon, Nov 06, 2006 at 03:10:20PM -0500, Colin J. Williams wrote: > Many thanks. In general, there is sense in the Python dictum about hav= ing one > way to do things. Although, in this case [length] vs length for one di= mension > doesn't > exercise me greatly. I would be a bit more concerned about synonyms. >=20 > Nobody has proposed using English yet - zeroes. If Cambridge Advanced Learner's is happy with zeros, then so we should be: http://dictionary.cambridge.org/define.asp?key=3D92164&dict=3DCALD zero Show phonetics noun plural zeros or zeroes 1 [C or U] (the number) 0; nothing: I think the American-english speakers on the list outnumber the rest of us, so we'd better be careful :) Cheers St=E9fan |
|
From: Victoria G. L. <la...@st...> - 2006-11-06 23:00:07
|
Stefan van der Walt wrote: > On Mon, Nov 06, 2006 at 03:10:20PM -0500, Colin J. Williams wrote: > >> Many thanks. In general, there is sense in the Python dictum about having one >> way to do things. Although, in this case [length] vs length for one dimension >> doesn't >> exercise me greatly. I would be a bit more concerned about synonyms. >> >> Nobody has proposed using English yet - zeroes. >> > > If Cambridge Advanced Learner's is happy with zeros, then so we should > be: > > http://dictionary.cambridge.org/define.asp?key=92164&dict=CALD > > zero Show phonetics > noun plural zeros or zeroes > 1 [C or U] (the number) 0; nothing: > > I think the American-english speakers on the list outnumber the rest > of us, so we'd better be careful :) > You know, I spell this wrong at least every other time I use it. But of course, if we changed it to "zeroes", I'd -still- spell it wrong every other time I used it. Are synonyms really *always* evil???? wistfully, Vicki Laidler |
|
From: Colin J. W. <cj...@sy...> - 2006-11-06 20:10:49
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Tim Hochberg wrote:
<blockquote cite="mid...@ie..." type="cite">
<pre wrap="">Colin J. Williams wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Tim Hochberg wrote:
[snip]
</pre>
<blockquote type="cite">
<pre wrap="">A style note: please use the named dtypes (int32, uint32, etc) rather
than the old-style letter codes; the former is much clearer. The answer
to your question might have been immediately apparent had you been
using named dtypes.
</pre>
</blockquote>
<pre wrap="">+1
</pre>
<blockquote type="cite">
<pre wrap=""> Personally, I'd also prefer people use the "ones([n])" syntax instead
of the I-wish-it-were-deprecated-but-it's-too-much-to-hope-for "ones(n)"
syntax. T
-tim
</pre>
</blockquote>
<pre wrap="">Could you elaborate please?
</pre>
</blockquote>
<pre wrap=""><!---->Sure. The general form of the zeros function, and several others[1], is:
zeros(shape, dtype)
Here 'shape' is a sequence of one sort or another. There's also a
second form that's applicable only to one dimensional arrays:
zeros(length, dtype)
Where length is an integer. I don't recall if this is a historical
legacy or is intended as a convenience function or a bit of both. Either
way, the result is that there are two ways to spell "give me a 1D array
of zeros with a given length and dtype":
zeros([length], dtype)
and
zeros(length, dtype)
I have two issues with having this second spelling. First, it's one more
thing to remember. Whenever I see the scalar spelling I have to use a
little bit extra of my limited brainpower to remember that it is not in
fact a typo, but is instead a shortcut. The second issue is pedagogical.
If people are initially exposed to the first form, the extension to
multiple dimensions is straightforward. They'll probably guess the
correct way right off the bat, and if not, they'll get it right away
when it's explained. On the other hand, if they are initially exposed to
the second form, the multidimensional form is far from obvious. In
addition, they'll probably spend a long time thinking that the
one-dimensional way is the normal way, but that we have to jump through
weird hoops to get multidimensional arrays to work. That's bad
propaganda for numpy. This all seems like a rather large price to pay to
avoid typing the occasional pair of brackets.
That's my two cents. Just say not to form #2.
-tim
... [1] Yes, I'm neglecting the order parameter; I don't think it
matters for this discussion.
</pre>
</blockquote>
Tim,<br>
<br>
Many thanks. In general, there is sense in the Python dictum about
having one<br>
way to do things. Although, in this case [length] vs length for one
dimension doesn't<br>
exercise me greatly. I would be a bit more concerned about synonyms.<br>
<br>
Nobody has proposed using English yet - zeroes.<br>
<br>
Colin W.<br>
</body>
</html>
|
|
From: Charles R H. <cha...@gm...> - 2006-11-06 21:30:39
|
On 11/6/06, Colin J. Williams <cj...@sy...> wrote: <snip> Nobody has proposed using English yet - zeroes. > It seemed a bridge too far. Chuck |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X