numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] dtype names and titles

[Francesc A. <fa...@ca...>]

El dg 12 de 02 del 2006 a les 09:02 +0000, en/na N. Volbers va escriure:
> I still don't understand the reason for keeping two different names.=20
> IMHO it adds some extra complexity and might be a potential source for=20
> errors. If I keep an extra title in the array, then I think I should be=20
> allowed to name it whatever I want. If this is not the case, then I=20
> would be better off to just have unique field names and keep my extra=20
> information about the fields in a separate dictionary with the field=20
> names as keys and the extra information as value. This is my current=20
> approach, which works quite well; unfortunately the extra information is=20
> not saved in the array itself.

Yes. I agree that accessing fields by both name and title might become a
common source of confusion. So, in order to avoid problems in the
future, I wouldn't let the users to access the fields by title.

>=20
> Is anybody actually using both names and titles?

Not me.

--=20
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   C=E1rabos Coop. V.   Enjoy Data
 "-"

[Numpy-discussion] ANN: first release of IVuPy-0.1

[Gerard V. <ger...@gr...>]

I am proud to announce IVuPy-0.1 (I-View-Py).

IVuPy is a Python extension module developed to write Python programs
for 3D visualization of large data sets using Qt and PyQt.  Python is
extended by IVuPy with more than 600 classes of two of the Coin3D C++
class libraries: Coin and SoQt.

Coin is compatible with the Open Inventor API.  Open Inventor is an
object-oriented 3D toolkit built on OpenGL that provides a 3D scene
database, a built-in event model for user interaction, and the ability
to print objects and exchange data with other graphics formats.
The SoQt library interfaces Coin to Qt. See http://www.coin3d.org for
more information on Coin3D.

IVuPy requires at least one of the Numerical Python extension modules:        
NumPy, Numeric, or numarray (IVuPy works with all of them at once).
Data transfer between the Numerical Python arrays and the Coin data
structures has been implemented by copying.

The design of the Open Inventor API favors ease of use over performance.
The API is a natural match for Python, and in my opinion it is fun to
program with IVuPy.

The performance penalty of the design choice is small. The first example
at http://ivupy.sourceforge.net/examples.html demonstrates this: NumPy
calculates a surface with a million nodes in 1.7 seconds and Coin3D
redisplays the surface in 0.3 seconds on my Linux system with a 3.6 GHz
Pentium and a nVidea graphics card (NV41.1).

The Inventor Mentor ( http://www.google.com/search?q=inventor+mentor ) 
is essential for learning IVuPy.  The IVuPy documentation supplements
the Inventor Mentor.  IVuPy includes all C++ examples from the Inventor
Mentor and their Python translations.  There are also more advanced
examples to show the integration of IVuPy and PyQt.

IVuPy has been used for almost 6 months on Linux and Windows in the
development of a preprocessor for a finite element flow solver and has
been proven to be very stable.

Prerequisites for IVuPy are:
- Python-2.4.x or -2.3.x
- at least one of NumPy, numarray, or Numeric
- Qt-3.3.x, -3.2.x, or -3.1.x
- SIP-4.3.x or -4.2.1
- PyQt-3.15.x or -3.14.1
- Coin-2.4.4 or -2.4.3
- SoQt-1.3.0 or -1.2.0

IVuPy is licensed under the terms of the GPL.  Contact me, if the GPL is
an obstacle for you.

http://ivupy.sourceforge.net is the home page of IVuPy.

Have fun -- Gerard Vermeulen

Re: [Numpy-discussion] gnuplot problem with numpy

[Brian B. <bb...@br...>]

David TREMOUILLES wrote:
> Hello,
>   Maybe you have to upgrade your numeric to 24.2

bingo!  thanks.  I had already upgraded my numpy, and since I kept seeing 
"numpy=Numeric" in many threads, I didn't think to upgrade that as well.


		thanks,


			Brian Blais

-- 
-----------------

             bb...@br...
             http://web.bryant.edu/~bblais

Re: [Numpy-discussion] dtype names and titles

[N. V. <mit...@we...>]

(sorry Travis, I accidentally replied first to you directly, and not to 
the list)

Travis Oliphant wrote:

> N. Volbers wrote:
>
>> [...]This seems to be caused by the fact that you can access a field 
>> by both the name and the field title. Why would you want to have two 
>> names anyway?
>
>
> This lets you use attribute look up on the names but have the titles 
> be the "true name" of the field.
>
I still don't understand the reason for keeping two different names. 
IMHO it adds some extra complexity and might be a potential source for 
errors. If I keep an extra title in the array, then I think I should be 
allowed to name it whatever I want. If this is not the case, then I 
would be better off to just have unique field names and keep my extra 
information about the fields in a separate dictionary with the field 
names as keys and the extra information as value. This is my current 
approach, which works quite well; unfortunately the extra information is 
not saved in the array itself.

Is anybody actually using both names and titles?

Best regards,

Niklas.

Re: [Numpy-discussion] More numpy and Numeric differences

[Travis O. <oli...@ie...>]

Pearu Peterson wrote:

>
> I have created a wiki page
>
>   http://scipy.org/PearuPeterson/NumpyVersusNumeric
>
> that reports my findings on how numpy and Numeric behave on various 
> corner cases. Travis O., could you take a look at it?
> Here is the most recent addition:
>
I fixed the put issue.  The problem with clip is actually in choose 
(clip is just a specific application of  choose). 

The problem is in PyArray_ConvertToCommonType.  You have an integer 
array, an integer scalar, and a floating-point scalar. 

I think the rules implemented in PyArray_ConvertToCommonType are not 
allowing the scalar to dictate anything.  But, this should clearly be 
changed to allow scalars of different "kinds" to up-cast the array.  
This would be consistent with the umath module.

So, PyArray_ConvertToCommonType needs to be improved.  This will have an 
impact on several other functions that use this C-API.

-Travis

Re: [Numpy-discussion] dtype names and titles

[Travis O. <oli...@ie...>]

N. Volbers wrote:

> I continue to learn all about the heterogeneous arrays...
>
> When I was reading through the records.py code I discovered that 
> besides the 'names' and 'formats' for the fields of a numpy array you 
> can also specify 'titles'. Playing around with this feature I 
> discovered a bug:
>
> >>> import numpy
> >>> mydata = [(1,1), (2,4), (3,9)]
> >>> mytype = {'names': ['col1','col2'], 'formats':['i2','f4'], 
> 'titles': ['col2', 'col1']}
> >>> b = numpy.array( mydata, dtype=mytype)
> >>> print b
> [(1.0, 1.0) (4.0, 4.0) (9.0, 9.0)]
>
> This seems to be caused by the fact that you can access a field by 
> both the name and the field title. Why would you want to have two 
> names anyway?

This lets you use attribute look up on the names but have the titles be 
the "true name" of the field.

I've fixed this in SVN, so that it raises an error when the titles have 
the same names as the columns.

Thanks for the test.


-Travis

[Numpy-discussion] bug with NO_IMPORT_ARRAY / PY_ARRAY_UNIQUE_SYMBOL? was Re: [SciPy-user] segfault when calling PyArray_DescrFromType

[Martin W. <mar...@gm...>]

Hi Travis,

thanks for your help!

I think there is a small bug with NO_IMPORT_ARRAY / PY_ARRAY_UNIQUE_SYMBOL in 
numpy-0.9.4. For ease of reference I've pasted part of __multiarray_api.h 
below.

The problem I ran into is, that my "non-importing" source files, the ones 
defining NO_IMPORT_ARRAY, cannot see PyArray_API, because they obviously 
cannot know which name I chose in the importing file.

E.g. I do

#define PY_ARRAY_UNIQUE_SYMBOL my_name

in the file which calls import_array (). Then the object generated will not 
have the symbol PyArray_API, because PyArray_API is replaced with my_name.

But the sources with NO_IMPORT_ARRAY look for PyArray_API, because for them it 
is not replaced. Indeed inserting

#define PyArray_API my_name

into these files seems to fix the problem for me.

Regards,
Martin.


#if defined(PY_ARRAY_UNIQUE_SYMBOL)
#define PyArray_API PY_ARRAY_UNIQUE_SYMBOL
#endif

#if defined(NO_IMPORT) || defined(NO_IMPORT_ARRAY)
extern void **PyArray_API;
#else
#if defined(PY_ARRAY_UNIQUE_SYMBOL)
void **PyArray_API;
#else
static void **PyArray_API=NULL;
#endif
#endif


On Thursday 09 February 2006 16:48, Travis Oliphant wrote:
> Martin Wiechert wrote:
> >Found it (in the "old" docs).
> >Must #define PY_ARRAY_UNIQUE_SYMBOL and call import_array ().
>
> To be clear, you must call import_array() in the modules init function.
> This is the only requirement.
>
> You only have to define PY_ARRAY_UNIQUE_SYMBOL if your extension module
> uses more than one file.  In the files without the module initialization
> code you also have to define NO_IMPORT_ARRAY.
>
> -Travis

Re: [Numpy-discussion] arange(start, stop, step) and floating point (Ticket #8)

[Charles R H. <cha...@gm...>]

On 2/9/06, Travis Oliphant <oli...@ie...> wrote:
> Sasha wrote:
>
> >Well, my results are different.
> >
> > [snip]
> Yes, I think it's worth submitting.  Most of the suggestions for
> pointer-arithmetic for fast C-code were developed when processors spent
> more time computing than fetching memory.  Now it seem it's all about
> fetching memory intelligently.
>
> The buffer[i]=3D
>
> style is even recommended according to the AMD-optimization book Sasha
> pointed out.

Pointers vs indexing is architecture and compiler dependent. My own
experience is that recent gcc compilers produce better indexing code
than they used to and the indexing instructions on newer cpus are
faster. When I wrote the sorting routines pointers were faster, so I
used them for quicksort and mergesort. Now I think indexing is faster
and I am tempted to change the code. Indexing also looks cleaner to
me.

Chuck

[Numpy-discussion] More numpy and Numeric differences

[Pearu P. <pe...@sc...>]

I have created a wiki page

   http://scipy.org/PearuPeterson/NumpyVersusNumeric

that reports my findings on how numpy and Numeric behave on various corner 
cases. Travis O., could you take a look at it?
Here is the most recent addition:

"""
Clipping integer array with Inf

In Numeric (v24.2) clip returns float array:

>>> from Numeric import *
>>> Inf = array(1.0)/0
>>> clip([1,2],0,Inf)
array([ 1.,  2.])
>>>

In numpy (v0.9.5.2092) Overflow error is raised:

>>> from numpy import *
>>> clip([1,2],0,Inf)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/local/lib/python2.3/site-packages/numpy/core/oldnumeric.py", 
line 336, in clip
     return asarray(m).clip(m_min, m_max)
OverflowError: cannot convert float infinity to long

Comment: is it a numpy bug? Should clip take optional dtype argument and 
return asarray(m, dtype=dtype).clip(m_min, m_max)? Then also array.clip 
should have optional dtype..
"""

Pearu

Re: [Numpy-discussion] gnuplot problem with numpy

[David T. <dav...@gm...>]

Hello,
  Maybe you have to upgrade your numeric to 24.2
Refer to the recent thread in gnuplot-py-user list:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D11272&max_rows=3D25=
&style=3Dnested&viewmonth=3D200602


David

2006/2/10, Brian Blais <bb...@br...>:
>
> Hello,
>
> I have been trying to use the Gnuplot1.7.py module, but it doesn't seem t=
o
> work with
> numpy (although it works with Numeric).  The following code plots two
> "identical"
> sets of data, but the numpy data gets rounded to the nearest integer when
> passed to
> Gnuplot.  What is odd is that the offending code in utils.py, is the
> function
> float_array(m), which does the conversion that I do in this script, but i=
t
> doesn't
> seem to work.  Any ideas?
>
> #----------------------------
> import numpy
> import Numeric
> import Gnuplot
>
> g =3D Gnuplot.Gnuplot(debug=3D1)
> dh=3D.1;
> x=3Dnumpy.arange(dh,2+dh,dh,'d')
> y1 =3D x**2
>
>
> y2=3Dy1
>
> d1 =3D Gnuplot.Data(x, y1,
>                   title=3D'numpy',
>                   with=3D'points')  # doesn't work
> d2 =3D Gnuplot.Data(Numeric.asarray(x,'f'), Numeric.asarray(y2,'f'),
>                   title=3D'Numeric',
>                   with=3D'points')   # works
>
> g.plot(d1,d2)
>
> #----------------------------
>
>
>
>
>                         thanks,
>
>                                 bb
>
> --
> -----------------
>
>              bb...@br...
>              http://web.bryant.edu/~bblais<http://web.bryant.edu/%7Ebblai=
s>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] NumPy Glossary: a request for review

[Sasha <nd...@ma...>]

At this point the only change I would like to make to the glossary
page is to rename it to NumPy_Glossary.  I don't have a permission to
change file names on the wiki, so I have to defer this task to someone
else.  I don't have any view on where this page should be linked, so I
will not make any more changes relating to this page.

Re: [Numpy-discussion] Test test_minrelpath.py on unix for me

[Tim H. <tim...@co...>]

Pearu Peterson wrote:

>
>
> On Fri, 10 Feb 2006, Tim Hochberg wrote:
>
>>
>> Could someone try the attached diff on a unixy system? It works under 
>> windows, but it's easy to mess up those \/'s.
>
>
> Hmm, minrelpath does not need
>
>     if os.sep != '/':
>         path = path.replace('/',os.sep)
>
> In functions (see njoin, for instance) that call minrelpath already 
> have applied this codelet.
>
> I have commited the tests fix with some modifications to svn, tested 
> on Linux.

That seems to do the trick under VC7 as well.

Thanks,

-tim

>
> Pearu
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>

Re: [Numpy-discussion] Test test_minrelpath.py on unix for me

[Pearu P. <pe...@sc...>]

On Fri, 10 Feb 2006, Tim Hochberg wrote:

>
> Could someone try the attached diff on a unixy system? It works under 
> windows, but it's easy to mess up those \/'s.

Hmm, minrelpath does not need

     if os.sep != '/':
         path = path.replace('/',os.sep)

In functions (see njoin, for instance) that call minrelpath already have 
applied this codelet.

I have commited the tests fix with some modifications to svn, tested on 
Linux.

Pearu

[Numpy-discussion] dtype names and titles

[N. V. <mit...@we...>]

I continue to learn all about the heterogeneous arrays...

When I was reading through the records.py code I discovered that besides 
the 'names' and 'formats' for the fields of a numpy array you can also 
specify 'titles'. Playing around with this feature I discovered a bug:

 >>> import numpy
 >>> mydata = [(1,1), (2,4), (3,9)]
 >>> mytype = {'names': ['col1','col2'], 'formats':['i2','f4'], 
'titles': ['col2', 'col1']}
 >>> b = numpy.array( mydata, dtype=mytype)
 >>> print b
[(1.0, 1.0) (4.0, 4.0) (9.0, 9.0)]

This seems to be caused by the fact that you can access a field by both 
the name and the field title. Why would you want to have two names anyway?

By the way, is there an easy way to access a field vector by its index? 
Right now I retrieve the field name from dtype.fields[-1][index] and 
then return the 'column' by using myarray[name].

Best regards,

Niklas.

Re: [Numpy-discussion] Re: NumPy Glossary Was:Matlab page on scipy wiki

[Bill B. <wb...@gm...>]

On the point of professionalism, I'd like to change the matlab page's title
from "NumPy for Matlab Addicts" to simply "NumPy for Matlab Users".  It's
been bugging me since I put it up there initially... but I'm not really sur=
e
how to chage the name of a page in the wiki.

On 2/11/06, Joe Harrington <jh...@oo...> wrote:
>
>   My point now is to get our community culture to include a
> sense of professionalism and pride about what we present to the world.
> Unless you're a fool or you have no competition, you dress well for a
> job interview.  We're not fools, and we have very healthy competition.
> The main site is the first impression we make on new users.  My goal
> is to prevent it from being the last.
>
>

Re: [Numpy-discussion] Re: NumPy Glossary Was:Matlab page on scipy wiki

[Bill B. <wb...@gm...>]

Definitely a very clear and convincing explanation, Joe.  I guess my proble=
m
is mostly that I pretty much just walked in here, and I'm wondering how was
I supposed to know that new things go in this DevZone?  I saw a wiki, it
didn't have the page I wished were there, so I registered and added it,
figuring that's how Wikis are supposed to work.

Seems like the information in your email needs to be communicated to new
registrants to the wiki.  And maybe permissions for creating new pages
limited to the DevZone?

--bb

On 2/11/06, David M. Cooke <co...@ph...> wrote:
>
> Joe Harrington <jh...@oo...> writes:
>
> > [...]
>
> Put this it on the wiki (seriously).
>
> Another thing to look at is the "Producing Open Source Software" book
> that's been mentioned before (http://producingoss.com/). There's a
> section on wiki's that useful to keep in mind at
> http://producingoss.com/html-chunk/index.html
>
> --

Re: [Numpy-discussion] NumPy Glossary: a request for review

[Sasha <nd...@ma...>]

I updated the "broadcasting" entry. I don't think examples belong to a
glossary. I think a glossary should be more like a quick reference
rather than a tutorial.  Unfortunately the broadcasting is one of
those concepts that will never be clear without examples.

On 2/11/06, Zachary Pincus <zp...@st...> wrote:
> The "broadcasting" entry is somewhat unclear in terms of what
> "conforming" array shapes are. Perhaps "compatible shapes" would be
> better, coupled with an example or two of "compatible" shapes, and/or
> a precise definition of how compatibility is determined.

Re: [Numpy-discussion] NumPy Glossary: a request for review

[Zachary P. <zp...@st...>]

The "broadcasting" entry is somewhat unclear in terms of what  
"conforming" array shapes are. Perhaps "compatible shapes" would be  
better, coupled with an example or two of "compatible" shapes, and/or  
a precise definition of how compatibility is determined.

Zach Pincus

Program in Biomedical Informatics and Department of Biochemistry
Stanford University School of Medicine



On Feb 10, 2006, at 9:55 PM, Gary Ruben wrote:

> David Cooke corrected my misconceptions, so the glossary all looks  
> good to me.
>
> Gary R.
>
> Sasha wrote:
>> On 2/11/06, Gary Ruben <gr...@bi...> wrote:
>>> Stride isn't the distance in bytes is it?  Isn't it just the index
>>> increment or alternatively the distance in terms of the  
>>> multiplier of
>>> the word length of the contained type.
>> Unfortunately it is in bytes and Travis convinced me that there is no
>> way to change it.
>>> Also, a slight typo: concecutive -> consecutive.
>> I've changed that.  In the future, please just edit the wiki for
>> obvious misspellings.  Spell check does not work for me on that wiki
>> and English is not my first language, so any spelling/grammar
>> corrections are more than welcome.
>>> Record
>>>        A composite element of an array similar to C struct.
>>>
>>> This implies that you can contain different types in a record,  
>>> which I
>>> think is only true if you have an object array.
>> Record arrays is a new feature in numpy.  I think what I wrote is
>> correct, but this entry will definitely benefit from a review by
>> someone familiar with record arrays since I am not.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] NumPy Glossary: a request for review

[Gary R. <gr...@bi...>]

David Cooke corrected my misconceptions, so the glossary all looks good 
to me.

Gary R.

Sasha wrote:
> On 2/11/06, Gary Ruben <gr...@bi...> wrote:
>> Stride isn't the distance in bytes is it?  Isn't it just the index
>> increment or alternatively the distance in terms of the multiplier of
>> the word length of the contained type.
> 
> Unfortunately it is in bytes and Travis convinced me that there is no
> way to change it.
> 
>> Also, a slight typo: concecutive -> consecutive.
> 
> I've changed that.  In the future, please just edit the wiki for
> obvious misspellings.  Spell check does not work for me on that wiki
> and English is not my first language, so any spelling/grammar
> corrections are more than welcome.
> 
>> Record
>>        A composite element of an array similar to C struct.
>>
>> This implies that you can contain different types in a record, which I
>> think is only true if you have an object array.
> 
> Record arrays is a new feature in numpy.  I think what I wrote is
> correct, but this entry will definitely benefit from a review by
> someone familiar with record arrays since I am not.

Re: [Numpy-discussion] NumPy Glossary: a request for review

[Sasha <nd...@ma...>]

On 2/11/06, Gary Ruben <gr...@bi...> wrote:
> Stride isn't the distance in bytes is it?  Isn't it just the index
> increment or alternatively the distance in terms of the multiplier of
> the word length of the contained type.

Unfortunately it is in bytes and Travis convinced me that there is no
way to change it.

> Also, a slight typo: concecutive -> consecutive.

I've changed that.  In the future, please just edit the wiki for
obvious misspellings.  Spell check does not work for me on that wiki
and English is not my first language, so any spelling/grammar
corrections are more than welcome.

>
> Record
>        A composite element of an array similar to C struct.
>
> This implies that you can contain different types in a record, which I
> think is only true if you have an object array.

Record arrays is a new feature in numpy.  I think what I wrote is
correct, but this entry will definitely benefit from a review by
someone familiar with record arrays since I am not.

Re: [Numpy-discussion] NumPy Glossary: a request for review

[<co...@ph...>]

Gary Ruben <gr...@bi...> writes:

> Hi Sasha,
> A couple of points:
>
> Stride
>       The distance (in bytes) between the two concecutive elements
> along an axis.
>
> Stride isn't the distance in bytes is it?  Isn't it just the index
> increment or alternatively the distance in terms of the multiplier of
> the word length of the contained type. Also, a slight typo:
> concecutive -> consecutive.

In numpy usage, it's bytes. It's particularly important when you've
got a record array of mixed types. Travis's example is

temp = array([(1.8,2),(1.7,3)],dtype='f8,i2')
temp['f1'].strides
(10,)

> Record
>       A composite element of an array similar to C struct.
>
> This implies that you can contain different types in a record, which I
> think is only true if you have an object array.

Nope; see above.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] NumPy Glossary: a request for review

[Gary R. <gr...@bi...>]

Hi Sasha,
A couple of points:

Stride
       The distance (in bytes) between the two concecutive elements 
along an axis.

Stride isn't the distance in bytes is it?  Isn't it just the index 
increment or alternatively the distance in terms of the multiplier of 
the word length of the contained type. Also, a slight typo: concecutive 
-> consecutive.


Record
       A composite element of an array similar to C struct.

This implies that you can contain different types in a record, which I 
think is only true if you have an object array.

Everything else looks OK.

Gary R.

Sasha wrote:
> Sorry for cross posting.  This request clearly relevant to the NumPy
> list, but Wiki instructs that such requests should be posted on
> scipy-dev. Please review http://scipy.org/NumPyGlossary .

[Numpy-discussion] NumPy Glossary: a request for review

[Sasha <nd...@ma...>]

Sorry for cross posting.  This request clearly relevant to the NumPy
list, but Wiki instructs that such requests should be posted on
scipy-dev. Please review http://scipy.org/NumPyGlossary .

Re: [Numpy-discussion] Matlab page on scipy wiki

[Gary R. <gr...@bi...>]

Sasha wrote:
> On 2/10/06, Gary Ruben <gr...@bi...> wrote:
>> ...  I must say that Travis's
>> example numpy.r_[1,0,1:5,0,1] highlights my pet hate with python - that
>> the upper limit on an integer range is non-inclusive.
> 
> In this case you must hate that an integer range starts at 0 (I don't
> think you would want len(range(10)) to be 11).

Actually, that wouldn't bother me and I'm not really fussed by whether a 
language chooses 0 or 1 based integer ranges, as long as you can 
override the default, but 0 seems more natural for any programming language.

 > If this is the case,
> I don't blame you: it is silly to start counting at 0, but
> algorithmically it is quite natural.  Semi-closed integer ranges have
> many algorithmic advantages as well such as length = (stop -
> start)/step,  empty range can be recognized by start=stop test
> regardless of step, adjacent ranges - start2=stop1 (again no need to
> know step) etc.

Thanks for the explanation Sasha. It does make some sense in terms of 
your examples, but I'll remain unconvinced.

>> I'm sure the BDFL has some excuse for this silliness.
> 
> Maybe he does not like Fortran :-)
> 
> PS: What's your second favorite language (I assume that python is the first :-)?

It's not Fortran-77! If I say it's Object Pascal (i.e. Delphi) you may 
begin to see where my range specifier preference comes from. Pascal lets 
you define things like enumeration type ranges like Monday..Friday. It 
would seem nonsensical to define the range of working weekdays as 
Monday..Saturday.

I'm pretty competent with C, less-so with C++ and I've totally missed 
out on Java. One day I might have a play with Haskell and Ruby. Actually 
I see that Ruby sidesteps my pet hate by providing both types of range 
specifiers. I can't see myself defecting to the enemy just because of 
this though,

Gary R.

Re: [Numpy-discussion] Matlab page on scipy wiki

[Sasha <nd...@ma...>]

On 2/10/06, Gary Ruben <gr...@bi...> wrote:
>...  I must say that Travis's
> example numpy.r_[1,0,1:5,0,1] highlights my pet hate with python - that
> the upper limit on an integer range is non-inclusive.

In this case you must hate that an integer range starts at 0 (I don't
think you would want len(range(10)) to be 11).   If this is the case,
I don't blame you: it is silly to start counting at 0, but
algorithmically it is quite natural.  Semi-closed integer ranges have
many algorithmic advantages as well such as length =3D (stop -
start)/step,  empty range can be recognized by start=3Dstop test
regardless of step, adjacent ranges - start2=3Dstop1 (again no need to
know step) etc.

> I'm sure the BDFL has some excuse for this silliness.

Maybe he does not like Fortran :-)

PS: What's your second favorite language (I assume that python is the first=
 :-)?