# [Numpy-discussion] Array scalar math ideas

Colin J. Williams cjw at sympatico.ca
Thu Mar 16 17:11:13 CST 2006

```Travis Oliphant wrote:

>
> I'm starting to write the remaining array scalar math tables (so that
> we can speed up scalar*scalar arithmetic).
> Right now, all operations involving scalars are converted to 0-d
> arrays - use the ufunc machinery - and are converted back to scalars
> after the operation.
>
> The scalarmathmodule.c.src  file is being written to fix this and
> insert type-appropriate operations for each of the (number-type) array
> scalars.
>
>
> My general strategy for the binary operations is going to be the
> following.  I wanted to bounce it off the list to see what other ideas
>
> Code outline:
>
> Convert inputs so that self is the array scalar of some type and other
> is the other object
>
> if (other is an array scalar of the same data-type as self)
>    arg3 = other
> else if (other is an array scalar of a different data-type as self)
>    arg3 = convert_other_to_self_data_type(other)

--- Shouldn't this depend on whether self or other has the higher type?

> <<<
> else if (other is a Python scalar)
>    arg3 = convert_Python_scalar_to_array_scalar(other)
> else if (other is a 0-d array)
>    arg3 = convert_other_to_self_data_type_from_0-d_array(other)
> else
>     return  (use ufunc to calculate result).
>
> return (operation using self and arg3)
>
> if an error condition is encountered, then only at that point, the
> proper way to handle it will be determined by looking in the local /
> global / builtin scope for the error-handling variable.
> Tthis avoids the overhead of looking up what to do to the case of an
> error actually occurring --- I need to change the ufuncobject.c code
> to also do this and save the overhead there too --- right now what to
> do is looked up every time, rather than waiting until an error is
> actually detected.)
>
> What do people think?
>
> -Travis

Would it make sense to reconsider the costs and benefits of dealing with
dimensionless arrays?

Colin W.

```