[SciPy-dev] Suppressing of numpy __mul__, __div__ etc

[Dag Sverre Seljebotn]

Charles R Harris wrote:
>
>
> 2009/12/14 Dmitrey <tmp50 at ukr.net <mailto:tmp50 at ukr.net>>
>
>
>
>     --- Исходное сообщение ---
>     От кого: Charles R Harris <charlesr.harris at gmail.com
>     <mailto:charlesr.harris at gmail.com>>
>     Кому: SciPy Developers List <scipy-dev at scipy.org
>     <mailto:scipy-dev at scipy.org>>
>     Дата: 14 декабря, 20:26:12
>     Тема: Re: [SciPy-dev] Suppressing of numpy __mul__, __div__ etc
>
>         > --- Исходное сообщение ---
>         > От кого: Charles R Harris <charlesr.harris at gmail.com
>         <mailto:charlesr.harris at gmail.com>>
>         > Кому: SciPy Developers List <scipy-dev at scipy.org
>         <mailto:scipy-dev at scipy.org>>
>         > Дата: 14 декабря, 20:06:46
>         > Тема: Re: [SciPy-dev] Suppressing of numpy __mul__, __div__ etc
>
>         > I think it should have numpy or ndarray in the name
>         somewhere to indicate
>         > that it is numpy specific. Hmm <looks in thesaurus>, maybe,
>         >
>         > __supercede_ndarray__,
>         > __disallow_ndarray__,
>         > __deny_ndarray__,
>         > __reject_ndarray__,
>         > __refuse_ndarray__,
>         > __exclude_ndarray__,
>         > __reject_ndarray__, ...
>         >
>         > My preference among those would be __deny_ndarray__.
>         >
>         >
>         > But isn't the issue present with numpy matrices or
>         scipy.sparse matrices as
>         > well?
>         > So I guess instead of ndarray another word should be used.
>         >
>
>         __has_precedence__
>         __is_prior__
>
>         Chuck
>
>     N
>     I guess some numpy developers should choose the final name in
>     numpy IRC channel and inform the list (ASAP) about their
>     collective (and hence final) decision. I'm not skilled in English
>     quite enough, but so short names seems too uninformative to me,
>     they will be not used too often so I guess more informative should
>     be preferred.
>
>
> I don't think we should rush this. I'm waiting for more people to 
> weigh in or offer different solutions.

Well, a different solution would be to have a standard with "operand 
precedence", i.e. an integer which could be compared between objects, 
and the highest one wins and gets to decide how the arithmetic operation 
is carried out.

This could be used to simplify NumPy itself. I.e. assign e.g. 
__operand_precedence__ = 0 for ndarray, 100 for matrix, and use it 
internally in NumPy to decide who carries out the operation.

Between other libraries it gets messy to try to figure out what range of 
values to use though. One would really want to be able to make 
statements about a partially ordered set ("I take priority over ndarray; 
a Frobnicator takes priority over me..."), but it's probably way too 
time consuming and complicated.

I like the "precedence" word though. So my suggestions are
  __operand_precedence__ # boolean or integer?
  __numpy_operand_precedence__ # boolean or integer?
  __precedence_over_ndarray__ # bool


Dag Sverre