headers
Eagle Jones | 1 Oct 18:32
Favicon

Naming a slice index?

New to python and numpy; hopefully I'm missing something obvious. I'd
like to be able to slice an array with a name. For example:

_T = 6:10
_R = 10:15
A = identity(20)
foo = A[_T, _R]

This doesn't work. Nor does _T=range(6:10); _R = range(10:15). Any ideas?

Thanks,
Eagle
Permalink | Reply | 3 comments |
headers
Robert Cimrman | 1 Oct 18:35
Picon

Re: Naming a slice index?

Eagle Jones wrote:
> New to python and numpy; hopefully I'm missing something obvious. I'd
> like to be able to slice an array with a name. For example:
> 
> _T = 6:10

_T = slice( 6, 10 )

...
Permalink | Reply | 0 comments |
headers
Timothy Hochberg | 1 Oct 18:35
Picon

Re: Naming a slice index?



On 10/1/07, Eagle Jones <eagle <at> newdream.net> wrote:
New to python and numpy; hopefully I'm missing something obvious. I'd
like to be able to slice an array with a name. For example:

_T = 6:10
_R = 10:15
A = identity(20)
foo = A[_T, _R]

This doesn't work. Nor does _T=range(6:10); _R = range(10:15). Any ideas?

Try slice(10,15)
 

Thanks,
Eagle
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion



--
.  __
.   |-\
.
.  tim.hochberg <at> ieee.org 
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Permalink | Reply | 0 comments |
headers
Alan G Isaac | 2 Oct 03:40
Picon
Favicon
Gravatar

numpy.distutils.cpuinfo bugs?

Two problems noted::

    >>> from numpy.distutils import cpuinfo
    0
    >>> cpu = cpuinfo.cpuinfo()
    >>> print "Has SSE2? %s"%cpu._has_sse2()
    Has SSE2? False
    >>>

1. The printed '0' traces to an undesirable print statement.
(I've reported this before.)

2. The 'False" report is on a Pentium M.  Should that not be 
True? <URL:http://en.wikipedia.org/wiki/Pentium_M>
Or am I misusing the test?

Thank you,
Alan Isaac
Permalink | Reply | 6 comments |
headers
Jarrod Millman | 2 Oct 07:37
Picon
Favicon
Gravatar

adopting Python Style Guide for classes

Hello,

NumPy and SciPy should conform with Guido's style guide as closely as possible:
http://www.python.org/dev/peps/pep-0008/
The only serious divergence that I am aware of between the NumPy and
SciPy codebase and the Python recommended standards is in class
naming.  According to Guido,  class names should use the CapWords
convention.  Most Python projects (eg, ETS, matploltlib) adhere to the
Python naming conventions and it is confusing that NumPy and SciPy
don't.

Currently, both NumPy and SciPy use either lower_underscore_separated
or CapWords for class names.  By my rough count, NumPy has about 752
classes using CapWords and 440 using  lower_underscore_separated.
While SciPy has about 256 classes using CapWords and 815 using
lower_underscore_separated.  Moreover, a far amount of the
lower_underscore_separated classes are tests.  That a number of
classes currently use CapWords despite the NumPy convention to use
lower_underscore_separated names may indicate it would make more sense
to switch to the Python convention.

I am hoping that most of you agree with the general principle of
bringing NumPy and SciPy into compliance with the standard naming
conventions.  I have already talked to a few people including Travis
about this switch and so far everyone supports the change in general.
Please let me know if you have any major objections to adopting the
Python class naming convention.

Once we have agreed to using CapWords for classes, we will need to
decide what to do about our existing class names.  Obviously, it is
important that we are careful to not break a lot of code just to bring
our class names up to standards.  So at the very least, we probably
won't be able to just change every class name until NumPy 1.1.0 is
released.

Here is what I propose for NumPy:
1.  Change the names of the TestCase class names to use CapWords.  I
just checked in a change to allow TestCase classes to be prefixed with
either 'test' or 'Test':
http://projects.scipy.org/scipy/numpy/changeset/4144
If no one objects, I plan to go through all the NumPy unit tests and
change their names to CapWords.  Ideally, I would like to get at least
this change in before NumPy 1.0.4.
2.  Any one adding a new class to NumPy would use CapWords.
3.  When we release NumPy 1.1, we will convert all (or almost all)
class names to CapWords.  There is no reason to worry about the exact
details of this conversion at this time.  I just would like to get a
sense whether, in general, this seems like a good direction to move
in.  If so, then after we get steps 1 and 2 completed we can start
discussing how to handle step 3.

Cheers,

--

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
Permalink | Reply | 9 comments |
headers
Pearu Peterson | 2 Oct 09:03
Picon
Picon
Favicon

Re: numpy.distutils.cpuinfo bugs?


Alan G Isaac wrote:
> Two problems noted::
> 
>     >>> from numpy.distutils import cpuinfo
>     0
>     >>> cpu = cpuinfo.cpuinfo()
>     >>> print "Has SSE2? %s"%cpu._has_sse2()
>     Has SSE2? False
>     >>>
> 
> 1. The printed '0' traces to an undesirable print statement.
> (I've reported this before.)

Travis seemed to fix this about two weeks ago.

> 2. The 'False" report is on a Pentium M.  Should that not be 
> True? <URL:http://en.wikipedia.org/wiki/Pentium_M>
> Or am I misusing the test?

What OS are you using? If Linux, then can you send the content
of /proc/cpuinfo?

Pearu
Permalink | Reply | 2 comments |
headers
David Cournapeau | 2 Oct 09:00
Picon
Picon

Re: numpy.distutils.cpuinfo bugs?

Pearu Peterson wrote:
>
> Alan G Isaac wrote:
>
>> 2. The 'False" report is on a Pentium M.  Should that not be 
>> True? <URL:http://en.wikipedia.org/wiki/Pentium_M>
>> Or am I misusing the test?
>
> What OS are you using? If Linux, then can you send the content
> of /proc/cpuinfo?
On Windows, you can use this software, I think:

http://www.intel.com/support/processors/tools/frequencyid/

which is essentially the same method (getting the info from the cpuid 
instruction provided on x86).

cheers,

David
Permalink | Reply | 0 comments |
headers
Pearu Peterson | 2 Oct 09:12
Picon
Picon
Favicon

Re: adopting Python Style Guide for classes


Jarrod Millman wrote:
> Hello,
> 
..
> Please let me know if you have any major objections to adopting the
> Python class naming convention.

I don't object.

> Once we have agreed to using CapWords for classes, we will need to
> decide what to do about our existing class names.  Obviously, it is
> important that we are careful to not break a lot of code just to bring
> our class names up to standards.  So at the very least, we probably
> won't be able to just change every class name until NumPy 1.1.0 is
> released.
> 
> Here is what I propose for NumPy:
> 1.  Change the names of the TestCase class names to use CapWords.  I
> just checked in a change to allow TestCase classes to be prefixed with
> either 'test' or 'Test':
> http://projects.scipy.org/scipy/numpy/changeset/4144
> If no one objects, I plan to go through all the NumPy unit tests and
> change their names to CapWords.  Ideally, I would like to get at least
> this change in before NumPy 1.0.4.

It is safe to change all classes in tests to CamelCase.

> 2.  Any one adding a new class to NumPy would use CapWords.
> 3.  When we release NumPy 1.1, we will convert all (or almost all)
> class names to CapWords.  There is no reason to worry about the exact
> details of this conversion at this time.  I just would like to get a
> sense whether, in general, this seems like a good direction to move
> in.  If so, then after we get steps 1 and 2 completed we can start
> discussing how to handle step 3.

After fixing the class names in tests then how many classes use
camelcase style in numpy/distutils? How many of them are implementation
specific and how many of them are exposed to users? I think having this
statistics would be essential to make any decisions. Eg would we
need to introduce warnings for the few following releases of numpy/scipy
when camelcase class is used by user code, or not?

Pearu
Permalink | Reply | 2 comments |
headers
David M. Cooke | 2 Oct 11:22
Picon
Picon

Re: adopting Python Style Guide for classes

On Tue, Oct 02, 2007 at 09:12:43AM +0200, Pearu Peterson wrote:
> 
> 
> Jarrod Millman wrote:
> > Hello,
> > 
> ..
> > Please let me know if you have any major objections to adopting the
> > Python class naming convention.
> 
> I don't object.

Me either.

> > 2.  Any one adding a new class to NumPy would use CapWords.
> > 3.  When we release NumPy 1.1, we will convert all (or almost all)
> > class names to CapWords.  There is no reason to worry about the exact
> > details of this conversion at this time.  I just would like to get a
> > sense whether, in general, this seems like a good direction to move
> > in.  If so, then after we get steps 1 and 2 completed we can start
> > discussing how to handle step 3.
> 
> After fixing the class names in tests then how many classes use
> camelcase style in numpy/distutils? How many of them are implementation
> specific and how many of them are exposed to users? I think having this
> statistics would be essential to make any decisions. Eg would we
> need to introduce warnings for the few following releases of numpy/scipy
> when camelcase class is used by user code, or not?

In numpy/distutils, there's the classes in command/* modules (but note
that distutils uses the same lower_case convention, so I'd say keep
them), cpu_info (none of which are user accessible; I'm working in there
now), and system_info (which are documented as user accessible). Poking
through the rest, it looks like only the system_info classes are ones
that we would expect users to subclass. We could document the lower_case
names as deprecated, and alias them to CamlCase versions.

--

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm <at> physics.mcmaster.ca
Permalink | Reply | 0 comments |
headers
Pearu Peterson | 2 Oct 11:40
Picon
Picon
Favicon

Re: adopting Python Style Guide for classes


Pearu Peterson wrote:
..
> After fixing the class names in tests then how many classes use
> camelcase style in numpy/distutils? How many of them are implementation
..                   ^^^^^^^^^^^^^^^
Btw, I meant numpy/scipy here.

Pearu
Permalink | Reply | 0 comments |

Gmane