Re: [Numpy-discussion] Removing masked arrays for 1.7? (Was 1.7 blockers)

[Drew Frank]

On Fri, Apr 20, 2012 at 11:45 AM, Chris Barker chris.bar...@noaa.gov wrote:

 On Fri, Apr 20, 2012 at 11:39 AM, Dag Sverre Seljebotn
 d.s.seljeb...@astro.uio.no wrote:
  Oh, right. I was thinking small as in fits in L2 cache, not small as
  in a few dozen entries.

Another example of a small array use-case: I've been using numpy for
my research in multi-target tracking, which involves something like a
bunch of entangled hidden markov models. I represent target states
with small 2d arrays (e.g. 2x2, 4x4, ..) and observations with small
1d arrays (1 or 2 elements). It may be possible to combine a bunch of
these small arrays into a single larger array and use indexing to
extract views, but it is much cleaner and more intuitive to use
separate, small arrays. It's also convenient to use numpy arrays
rather than a custom class because I use the linear algebra
functionality as well as integration with other libraries (e.g.
matplotlib).

I also work with approximate probabilistic inference in graphical
models (belief propagation, etc), which is another area where it can
be nice to work with many small arrays.

In any case, I just wanted to chime in with my small bit of evidence
for people wanting to use numpy for work with small arrays, even if
they are currently pretty slow. If there were a special version of a
numpy array that would be faster for cases like this, I would
definitely make use of it.

Drew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Possible roadmap addendum: building better text file readers

[Drew Frank]

For convenience, here's a link to the mailing list thread on this topic
from a couple months ago:
http://thread.gmane.org/gmane.comp.python.numeric.general/47094 .

Drew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy.arange() error?

[Drew Frank]

On Thu, Feb 9, 2012 at 3:40 PM, Benjamin Root ben.r...@ou.edu wrote:



 On Thursday, February 9, 2012, Sturla Molden stu...@molden.no wrote:
 
 
  Den 9. feb. 2012 kl. 22:44 skrev eat e.antero.ta...@gmail.com:
 
 
  Maybe this issue is raised also earlier, but wouldn't it be more
 consistent to let arange operate only with integers (like Python's range)
 and let linspace handle the floats as well?
 
 
  Perhaps. Another possibility would be to let arange take decimal
 arguments, possibly entered as text strings.
  Sturla


 Personally, I treat arange() to mean, give me a sequence of values from x
 to y, exclusive, with a specific step size.  Nowhere in that statement
 does it guarantee a particular number of elements.  Whereas linspace()
 means, give me a sequence of evenly spaced numbers from x to y, optionally
 inclusive, such that there are exactly N elements. They complement each
 other well.


I agree -- both functions are useful and I think about them the same way.
The unfortunate part is that tiny precision errors in y can make arange
appear to be sometimes-exclusive rather than always exclusive.  I've
always imagined there to be a sort of duality between the two functions,
where arange(low, high, step) == linspace(low, high-step,
round((high-low)/step)) in cases where (high - low)/step is integral, but
it turns out this is not the case.



 There are times when I intentionally will specify a range where the step
 size will not nicely fit.  i.e.- np.arange(1, 7, 3.5). I wouldn't want this
 to change.


Nor would I.  What I meant to express earlier is that I like how Matlab
addresses this particular class of floating point precision errors, not
that I think arange output should somehow include both endpoints.



 My vote is that if users want matlab-colon-like behavior, we could make a
 new function - maybe erange() for exact range?


 Ben Root


That could work; it would completely replace arange for me in every
circumstance I can think of, but I understand we can't just go changing the
behavior of core functions.

Drew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion