Re: [Numpy-discussion] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 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/ |[EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 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 _R = 10:15 from numpy import index_exp _T = index_exp[6:10] _R = index_exp[10:15] A = identity(20) foo = A[_T, _R] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Run length encoding of an ndarray
Michael Hoffman wrote:
I am trying to do a type of run-length encoding of a 2D array by axis. I
have an array of values arranged along two axes, state and position.
These are many (180, 3) uint8 arrays.
I would like to have a list of tuples like
(state, start_pos, end_pos, values)
only separating out a set of values into a new tuple if they are all the
same value in a run of at least 10 cells.
Is there a clever way to do this in NumPy? I was thinking of using
itertools.groupby() but it would be nicer to have something faster.
I just realized I could convert this to a string and use something like
re.compile(r(.)\1{9,}).finditer() but I'm still wondering if there's
something more NumPythonic.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Run length encoding of an ndarray
On Tue, Oct 02, 2007 at 01:36:02PM +0100, Michael Hoffman wrote: I am trying to do a type of run-length encoding of a 2D array by axis. I have an array of values arranged along two axes, state and position. These are many (180, 3) uint8 arrays. I would like to have a list of tuples like (state, start_pos, end_pos, values) only separating out a set of values into a new tuple if they are all the same value in a run of at least 10 cells. This snippet does run-length encoding for one row. x = N.array([1,1,1,1,1,1,1,1,1,1,0,0,2,2,9,9,9,9,9,9,9,9,9,9]) pos, = N.where(N.diff(x) != 0) pos = N.concatenate(([0],pos+1,[len(x)])) rle = [(a,b,x[a]) for (a,b) in zip(pos[:-1],pos[1:])] [(0, 10, 1), (10, 12, 0), (12, 14, 2), (14, 24, 9)] Maybe you can use that as a starting point. Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.distutils.cpuinfo bugs?
On Tue, 02 Oct 2007, Pearu Peterson apparently wrote: 1. The printed '0' traces to an undesirable print statement. (I've reported this before.) Travis seemed to fix this about two weeks ago. Sorry for the noise. 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? It is a student's machine, running Windows XP. I did check the system information to confirm that it is really a Pentium M. I will be happy to convey any suggested diagnostics to the student. (I have sent David's suggestion.) Thank you, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.distutils.cpuinfo bugs?
Here is the processor information using the Intel utility. Cheers, Alan Isaac Intel(R) Processor Identification Utility Version: 3.7.20070907 Time Stamp: 2007/10/02 14:21:29 Number of processors in system: 1 Current processor: #1 Cores per processor: 1 Disabled cores per processor: 0 Processor Name: Intel(R) Pentium(R) M processor 735 1.70GHz Type: 0 Family: 6 Model: D Stepping: 6 Revision: 18 L1 Instruction Cache: 32 KB L1 Data Cache: 32 KB L2 Cache: 2 MB Packaging: µFCPGA/µFCBGA EIST: Yes MMX(TM): Yes SSE: Yes SSE2: Yes SSE3: No SSE4: No Enhanced Halt State: No Execute Disable Bit: No Hyper-Threading Technology: No Intel(R) 64 Architecture: No Intel(R) Virtualization Technology: No Expected Processor Frequency: 1.70 GHz Reported Processor Frequency: 1.70 GHz Expected System Bus Frequency: 400 MHz Reported System Bus Frequency: 400 MHz * ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] adopting Python Style Guide for classes
Jarrod Millman wrote: I am hoping that most of you agree with the general principle of bringing NumPy and SciPy into compliance with the standard naming conventions. +1 3. When we release NumPy 1.1, we will convert all (or almost all) class names to CapWords. What's the backwards-compatible plan? - keep the old names as aliases? - raise deprecation warnings? What about factory functions that kind of look like they might be classes -- numpy.array() comes to mind. Though maybe using CamelCase for the real classes will help folks understand the difference. What is a class in this case -- with new-style classes, there is no distinction between types and classes, so I guess they are all classes, which means lots of things like: numpy.float32 etc. etc. etc. are classes. should they be CamelCase too? NOTE: for i in dir(numpy): if type(getattr(numpy, i)) == type(numpy.ndarray): print i Yields 86 type objects. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] adopting Python Style Guide for classes
On 10/2/07, Christopher Barker [EMAIL PROTECTED] wrote: Jarrod Millman wrote: I am hoping that most of you agree with the general principle of bringing NumPy and SciPy into compliance with the standard naming conventions. Excellent plan - and I think it will make the code considerably more readable (and writeable). 3. When we release NumPy 1.1, we will convert all (or almost all) class names to CapWords. What's the backwards-compatible plan? - keep the old names as aliases? - raise deprecation warnings? Both seem good. How about implementing both for the next minor release, with the ability to turn the deprecation warnings off? What about factory functions that kind of look like they might be classes -- numpy.array() comes to mind. Though maybe using CamelCase for the real classes will help folks understand the difference. Sounds right to me - factory function as function, class as class. What is a class in this case -- with new-style classes, there is no distinction between types and classes, so I guess they are all classes, which means lots of things like: numpy.float32 etc. etc. etc. are classes. should they be CamelCase too? I would vote for CamelCase in this case too. Matthew ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] adopting Python Style Guide for classes
Matthew Brett wrote: On 10/2/07, Christopher Barker [EMAIL PROTECTED] wrote: What is a class in this case -- with new-style classes, there is no distinction between types and classes, so I guess they are all classes, which means lots of things like: numpy.float32 etc. etc. etc. are classes. should they be CamelCase too? I would vote for CamelCase in this case too. I would prefer to leave them as they are. While they are implemented as classes, they're usually used as data. Also, they are more similar to builtin types than classes one might write, and Python itself has a convention of leaving these lowercase (e.g. int, float, etc.). -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] adopting Python Style Guide for classes
On 10/2/07, Christopher Barker [EMAIL PROTECTED] wrote: Jarrod Millman wrote: I am hoping that most of you agree with the general principle of bringing NumPy and SciPy into compliance with the standard naming conventions. +1 3. When we release NumPy 1.1, we will convert all (or almost all) class names to CapWords. What's the backwards-compatible plan? - keep the old names as aliases? - raise deprecation warnings? What about factory functions that kind of look like they might be classes -- numpy.array() comes to mind. Though maybe using CamelCase for the real classes will help folks understand the difference. I'm not a big fan of this kind of distinction distinction between factory functions and real classes based on the concrete types of the objects.. In some cases whether an object is a class or a factory function is simply an implementation detail. The real distinction, as I see it, is whether the object in question is meant to be subclassed. Thus an object is conceptually a class if it can be called to create an instance and it can be usefully subclassed. A factory function, on the other hand is only meant to be called to get an instance, regardless whether it is implemented as a class or a function. Of course, in the case of ndarray/array the distinction is clear since array cannot be subclassed, so the minor rant above doesn't apply. What is a class in this case -- with new-style classes, there is no distinction between types and classes, so I guess they are all classes, which means lots of things like: numpy.float32 etc. etc. etc. are classes. should they be CamelCase too? Core Python makes an additional distinction between types built into the core (float, int, etc...) which are all lower case and library classes, which generally use CapWords. So I guess there are two questions, IMO: 1. Can float32 and friends be usefull subclassed? I suspect the answer is no. And in my head at least, these are conceptually mostly marker objects that can also be used as coercion functions, not classes. FWIW. 2. Are these enough like builtin types to leave them alone in any case? One approach would be CapWords the superclasses of these that are subclassable, but leave the leaf types alone. For example, looking at float32 and its bases : - numpy.generic - numpy.Generic - numpy.number - numpy.Number - numpy.inexact - numpy.Inexact - numpy.floating - numpy.Floating - numpy.float32 stays the same This is probably a lot less painful in terms of backwards compatibility. My $0.02. NOTE: for i in dir(numpy): if type(getattr(numpy, i)) == type(numpy.ndarray): print i Yields 86 type objects. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- . __ . |-\ . . [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] adopting Python Style Guide for classes
A Tuesday 02 October 2007, Robert Kern escrigué: Matthew Brett wrote: On 10/2/07, Christopher Barker [EMAIL PROTECTED] wrote: What is a class in this case -- with new-style classes, there is no distinction between types and classes, so I guess they are all classes, which means lots of things like: numpy.float32 etc. etc. etc. are classes. should they be CamelCase too? I would vote for CamelCase in this case too. I would prefer to leave them as they are. While they are implemented as classes, they're usually used as data. Also, they are more similar to builtin types than classes one might write, and Python itself has a convention of leaving these lowercase (e.g. int, float, etc.). I would prefer to leave them as they are now too. In addition to what Robert is saying, they are very heavily used in regular NumPy programs, and changing everything (both in code and docs) would be rather messy. Cheers, -- 0,0 Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data - ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Default value in documentation
All,
I'm starting to update the documentation of maskedarray to the latest
standard.
How should I represent the default value of an optional parameter ?
I was thinking something like
def function(a, value=None)
Does something
*Parameters*:
a : {ndarray}
Input array.
value : {float} *[None]*
Some value. If None, a default based on the dtype of a is used.
Suggestions/ideas are welcome.
Thanks a lot in advance
P.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] adopting Python Style Guide for classes
A Tuesday 02 October 2007, Timothy Hochberg escrigué: One approach would be CapWords the superclasses of these that are subclassable, but leave the leaf types alone. For example, looking at float32 and its bases : - numpy.generic - numpy.Generic - numpy.number - numpy.Number - numpy.inexact - numpy.Inexact - numpy.floating - numpy.Floating - numpy.float32 stays the same This is probably a lot less painful in terms of backwards compatibility. Yeah. I second this also. -- 0,0 Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data - ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Default value in documentation
On 10/2/07, Robert Kern [EMAIL PROTECTED] wrote:
Pierre GM wrote:
All,
I'm starting to update the documentation of maskedarray to the latest
standard.
How should I represent the default value of an optional parameter ?
I was thinking something like
def function(a, value=None)
Does something
*Parameters*:
a : {ndarray}
Input array.
value : {float} *[None]*
Some value. If None, a default based on the dtype of a is used.
I prefer this:
value : {float}, optional
Some value. If not provided, a default based on the dtype of a is
used.
So label it optional and describe the default in prose in the parameter
description if necessary. While this is less descriptive for meaningful
defaults
(axis=-1), the case you show above is precisely suited to it. None is not
really
the default value, it's really just being used as a marker for argument
not
provided. And for the meaningful defaults, the function signature is more
than
adequate to provide the necessary information.
I've been putting the default value first among the options. Thus
axis : {-1, integer}, optional
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Default value in documentation
On Tue, 2 Oct 2007, Pierre GM apparently wrote: is there any kind of standard to describe the attributes of a class, a la :IVariables: in epydoc ? I thought it was ... :IVariables: i.e., I thought the standard was reST as handled by epydoc. URL:http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines URL:http://epydoc.sourceforge.net/api/epydoc.markup.restructuredtext-module.html#CONSOLIDATED_DEFLIST_FIELDS Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Default value in documentation
On 10/2/07, Alan G Isaac [EMAIL PROTECTED] wrote: On Tue, 2 Oct 2007, Pierre GM apparently wrote: is there any kind of standard to describe the attributes of a class, a la :IVariables: in epydoc ? I thought it was ... :IVariables: i.e., I thought the standard was reST as handled by epydoc. URL:http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines URL: http://epydoc.sourceforge.net/api/epydoc.markup.restructuredtext-module.html#CONSOLIDATED_DEFLIST_FIELDS We're avoiding consolidated fields because they behave badly. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
