[PEP draft 2] Adding new math operators

Huaiyu Zhu hzhu at localhost.localdomain
Thu Aug 10 18:13:42 EDT 2000


On Thu, 10 Aug 2000 20:16:58 GMT, Tim Hochberg <tim.hochberg at ieee.org> wrote:

>I'm going to punt on the scalar issue, not because I don't think it's
>important, but rather because I agree that it's a mess.

Certainly.  And this is the reason I think the .E approach is not realistic
even though I have favorable opinion towards the shadow class variant.

 >> >a * f()
>> >a ~* f()
>> >
>> >will both fail if f() doesn't have the prevailing type.
>> 
>> The point I was making was: if you use the prevailing-type approach, you can
>> just write wrapper functions accepting given type and return given type, so
>> you do know the return type.  This is not possible in mixed-type approach,
>> because you don't know in what context the function will be used.  That's
>> what I meant earlier by "not having enough information to decide".
>> 
>> In essence, I really don't like a programming language in which the
>> semantics of operation depends on far away context.
>
>This makes no sense to me, perhaps you need to clarify what you mean
>by the prevailing type approach. 

I can see where our difficulties are: I'm talking about using functions in a
context, while you are talking about what it does inside a function.

In the prevailing-type approach, every function accepts a given type and
returns a given type, so does all operators.  The semantics of all operators
are also of the same type, except occasional ~op operators that does the
other flavor of operation (but the operands and results remain the same as
prevailing type).  Every function is only used in the same context as it is
supposed to.  If one wants to avoid occasional misuse one could put asserts
on the input types inside a function. 

In this scenario the following example just does not come up.

>As far as I can tell, the effect of *
>and ~* would be completely determined by the objects they operate
>on. So the following oversimplified function:
>
>def f(a,b):
>   return a ~* b
>
>will return:
>
>(a.E * b.E).M if a and b are matrices,
>(a.M * b.M).E if a and b are arrays.
>
>and fail for mixed types.

But f would be written to only accept one type of inputs (or convert to one
type), because it is meant to be used only in one context.  If it is to be
used in another context, write a wrapper that converts the inputs and
converts back the return values.

The reason I favor the prevailing-type approach is that one either does
substantial array operations with some matrix operations, or substantial
matrix operations with some array operations.  It is rarely the case that
there is no prevailing one, as appears to be confirmed by retrospections
made by discussants.  With this approach one does not need to switch mental
context very often, except when seeing the explicit ~op, but then the
influence does not extend to more than 2 characters away.

Huaiyu



More information about the Python-list mailing list