Re: inherted overload & mixed type operations

[Marc Lehmann <marc@gimp.org>]

On Sun, Jan 09, 2000 at 08:57:21PM -0500, Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
> > a) would it be (computationally) feasible to detect this case and use
> >    the subclass operator always?
> 
> Yes.  PDL overloaded multiplication can (and should) do it.

No, I asked wether the subclass operator could be used all the time, on
the assumption that the subclass knows about itself, but it's superclass
does not know (cannot know) anything about it's subclasses.

One way to "fix" this would be for PDL::Complex to overwrite the operators
of it's superclass, but.....

> > b) would it make sense except for obvious cases like complex and real-valued
> >    types?
> 
> Polymorphism by two arguments is always a tricky topic.

Well, other languages do not share this problem, since they do not
overload based on one of the operands chosen randomly. But indeed it *is*
a tricky problem.

Especially when perl acts _totally_ randomly. For example:

   $sin = i * zeroes(50)->xlinvals(2,4) + 5

uses the PDL::Complex-*, while

   $sin = i * zeroes(50)->xlinvals(2,4)

uses the PDL-* operator. While

   $sin = i * pdl(1,2,3) # and
   $sin = i * pdl(1,2,3) + 5

Both work. How can this be anything but a bug? Even if I had to check in
_both_ the sub- and the superclass for this problem, I would expect that
there would be at least _some_ logic.

Even worse, look at this:

perldl> use PDL::Complex
perldl> p ref i
PDL::Complex
perldl> p i * zeroes(5)->xlinvals(2,4) + 5 
PDL: PDL::Ops::my_biop1(a,b,c): Parameter 'b'
Mismatched implicit thread dimension 0: should be 2, is 5 at /usr/app/lib/perl5/PDL/Ops.pm line 89.

perldl> p i * zeroes(5)->xlinvals(2,4) + 5

[
 [  5   2]
 [  5 2.5]
 [  5   3]
 [  5 3.5]
 [  5   4]
]

(perldl is an interactive perl shell). The first time the PDL-operator is
called, the second time the PDL::Complex-operator is called.

So not only does perl have very weird rules of when to apply which
operator, it also changes it's mind at runtime. So perl choses semantics
at will.

BTW: I didn't know all this just yesterday. Expecially the last case
(identical calls, different results) make me very nervous (perl5.005_03,
still ;)

> > BTW, "use overload" automatically inherits all the ops from its
> > superclass, which is not always a good thing: I do not want to
> > inherit >=, > etc.. but instead want to perl to synthesize it from my
> > <=>-operator. Unfortunately, doing ">" => undef does not do that.
> 
> This is an interesting topic...  Specify 'fallback'-per-optype?

Not as interesting as the other topic ;) It's not critical, either, as it
requires a simple(?) map on all these ops, so it would just be a "nice to
have".

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

---

Follow-Ups from:

Ilya Zakharevich <ilya@math.ohio-state.edu>

References to:

Marc Lehmann <marc@gimp.org>
Ilya Zakharevich <ilya@math.ohio-state.edu>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---