--On 10 décembre 2012 17:44:55 -0500 Raul Miller <[email protected]>
wrote:
The type system seems way too complex -- why should I care in the
typical case, what type of value is used to represent the numeric
value 1? Why can't it give me consistent operations? For example, I
Before you judge NumPy, you have to consider its design criteria, which are
probably a bit different from your personal evaluation criteria:
- provide fast and flexible operations on arrays in Python
- integrate as well as possible into the Python ecosystem
- provide an in-memory representation for arrays that is compatible
with C and Fortran libraries
The lots of types are a result of the third criterion, but you can actually
use a subset of NumPy without ever worrying about types, at the price of
some memory efficiency.
Booleans as separate types were imposed by Python. In the past, both Python
and NumPy used 0 and 1. Then Python switched to a True/False
representation, and NumPy followed. I prefer the old approach as well, but
nobody asked me ;-)
I was part of the original team that developped Numeric (NumPy's
predecessor), and I pushed for as much APL similarity as was possible
within the Python/C/Fortran constraints. Later on, the community grew quite
a bit and attracted in particular refugees from Matlab, with the
consequence that today's NumPy has more and more Matlab-like functions and
semantics. That explains some of the inconsistency, which is regrettable,
but probably unavoidable for a tool that serves such a large and diverse
community.
I am also a bit dubious about some of the mechanisms (for example, why
does dot product sum along the second to last axis of the second
argument, rather than the first axis of the second argument?)
It didn't in the old Numeric. I haven't understood the reason for that
change either, but most changes between Numeric and NumPy were done either
for efficiency or for similarity with Matlab. I guess it's the latter.
Anyways, these are just grumbles -- and I doubt I will ever use numpy
as a replacement for J. Still, I might find myself translating J code
to numpy rather than regular python in some cases.
My personal dream would be a J implementation that uses NumPy arrays
internally, letting me combine Python and J easily.
Konrad.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
