Why narray could be better than numpy

Numpy is the current gold standard among scripting-language-based numerical libraries--it is an outstanding library. NArray is a tight, beautiful numeric library for ruby, still considered to be in its development stage. With further development, could NArray become an equal or even better library than Numpy?

Here are some reasons NArray stands a chance. The remainder of this document is obviously highly biased towards NArray and Ruby.

Method chaining

Can override normal order of operations and just chain along operations. Sometimes, this is more clear than lots of parentheses. Think of the 'J' programming language.

  >> a = NArray[1,2,3,4]
  => NArray.int(4): 
  [ 1, 2, 3, 4 ]
  >> b = NArray[5,6,7,8]
  => NArray.int(4): 
  [ 5, 6, 7, 8 ]

  # you'd like to do a simple series of calculations, shown here with full parentheses:
  >> ((a+b)*3)**4
  => NArray.int(4): 
  [ 104976, 331776, 810000, 1679616 ]

  # if you space-out on your order of operations, you're getting the wrong answer:
  >> a+b*3**4
  => NArray.int(4): 
  [ 406, 488, 570, 652 ]

  # however, because '.' (dot) methods take highest precendence, we can do this:
  >> a.+(b).*(3).**(4)
  => NArray.int(4): 
  [ 104976, 331776, 810000, 1679616 ]

Also, everything returns a value

  # need some good examples of how that allows easier chaining, etc.

More pervasive object orientation

While python claims to be as object oriented as ruby, it is not in practice:

  # from Tentative Numpy Tutorial
  a = floor(10*random.random((3,4)))

  # trying to 'floor' the numpy array results in an error:
  >>> (10*random.random((3,4))).floor()
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  AttributeError: 'numpy.ndarray' object has no attribute 'floor'

To be fair, floor is tucked away in some module and so it is technically object oriented, but ruby tends to put more methods in the hands of the objects that need them.

Notice that ruby nearly always reads from left to right as a consequence of its design. (We end up with an int NArray because of floor, but could easily cast with '.to_f' if needed)

  # all are equivalent
  a = NArray.int(4,3).random!(10)
  a = NArray.float(4,3).random!.*(10).floor
  a = (10*NArray.float(4,3).random!).floor

Inconsistencies in accessing the size of a python list vs. numpy array:

  >>> array( [1,2,3] ).size
  3
  >>> [1,2,3].size
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  AttributeError: 'list' object has no attribute 'size'
  >>> len([1,2,3])  # len( obj ) really messes with the flow IMHO
  3

Very consistent between NArray and Ruby. Object orientation makes chaining more clear.

  >> [1,2,3].size
  => 3
  >> NArray[1,2,3].size
  => 3
  # works the same for '.length'

Enumerators are better than for loops

Easy extension? (needs work)

(with lots of work: More features)

(with lots of community involvement: More libraries using it)

Also see What NArray needs?