[Matrix-SIG] Space-saving arrays and authoring tools.

Travis Oliphant Oliphant.Travis@mayo.edu
Thu, 20 Jan 2000 01:08:32 -0600 (CST)


Well, the changes to NumPy to provide space-saving (I used to call them
active) are in CVS.  Anyone who wants to try them out can check out the
current source tree from sourceforge.net

Three new syntax items:

1) array() now takes a savespace keyword (default is 0) which if non-zero
specifies that the constructed array be a "spacesaver" array.  This has
two effects: first, construction from Python (nested) lists and scalars
produces  single-precision arrays, and second, the new array has the
savespace flag set so that it will control the casting in ufunc
operations.

Suppose a is a NumPy array
2) a.savespace(flag=value) sets the savespace flag to value (1 or 0)

3) a.spacesaver()  queries the flag.


Currently, the behavior if two spacesaving arrays are found in an
operation is to cast to the largest precision spacesaving array.  However,
when a similar proposal was made several months ago by Michael Hudson,
several people said that it would be better to throw an exception under
such circumstances.  I would like more opinions on this.  I haven't had
enough experience to decide which is better, but I'm leaning towards the
throwing-the-exception option.

**** Proposal buried in the next paragraph ****

Eventually we have to fix this rank-0 array/ scalar question.  Right now
rank-0 arrays are sort of scalars and sort of not which makes things messy
both from a users point of view and a programmers point of view.  I think
rank-0 arrays should be given their rightful existence and be the return
type for all indexing operations, math operations, etc.  (basically, get
rid of Pyarray_Return).  Because Python allows you to define methods to
determine how your types are interpreted as numbers, the rank-0 arrays
will behave rather nicely.  We could even use them to index into NumPy
arrays with little trouble.    Then, we define a method .toscalar() that
gets the appropriate Python scalar for those times when you really need
it. 

The truth is NumPy arrays are not Python numbers, lists, or dictionaries,
even though they can act like them (often seemlessly) sometimes.  I don't
think it is confusing to separate the concepts for the user (since the
differences will get you someday if you don't understand them). 


About authoring tools.

I find it interesting that 5 people have said that a controlled LaTeX or
LyX would be a good option for documentation (and I know of another 2 as
well).  Are David and Paul the only ones that don't like the idea of using
LaTeX or are the rest of you remaining silent?

There are important points to consider regarding the opposition to LaTeX:

1) LyX reduces the learning curve to LaTeX dramatically.
2) LaTeX installations have matured: teTeX is standard package that
contains what you really need.