overloaded function handles

[Robert T. Short]

FYI.  The obviousness concept applies only to the granting of patents.  
The patents that Mathworks holds have been granted and it is now up to 
potential infringers to show that either the patent is really invalid 
because of obviousness or other reason or that the implementation is not 
infringing.

Does someone have a copy of the patent in question?

Bob
--
Robert T. Short, Ph.D.
PhaseLocked Systems


Jaroslav Hajek wrote:
> hi,
>
> the following patch is a first attempt at implementing overloaded
> function handles:
> http://hg.savannah.gnu.org/hgweb/octave/rev/cf714e75c656
>
> a short discussion follows:
>
> Matlab docs say that an overloaded handle stores the base function
> path (pointer?) as well as overloads for *standard* classes (double,
> cell, logical etc.). When arguments contain objects (user classes),
> the dispatch is determined by dynamic lookup (as if normally
> referenced).
> After considering a couple of alternatives, I eventually found this to
> be a good compromise - this way the time to construct a function
> handle does not grow linearly with the number of existing classes.
> Apparently MathWorks are not that dumb guys :). So I used the same
> approach. The downside is that handles to all built-in and library
> functions are stored as overloaded (even if actually no overload
> exists), because you don't know whether user class overloads exist.
> This means a certain performance hit, but I have yet to evaluate its
> significance.
>
> ov-fcn-handle also distinguishes the case when a handle is constructed
> from a non-overloadable function (subfunction, private function, or
> class constructor; shortly, anything that has a higher precedence than
> class methods) or is an anonymous function handle. In that case the
> dynamic dispatch type is not computed.
>
> This mechanism is provided in a standard manner via the
> do_multi_index_op and subsref methods. Now the problem is that many
> Octave functions actually use a more "hacky" way to call function
> handles: they extract the pointer to the function object via
> function_value and then pass that to feval (which calls
> do_multi_index_op).
> For a long time I played with an implementation overloading
> octave_function rather than extending octave_fcn_handle, but in the
> end it always seemed to be getting clunky, so I eventually dropped it.
> I think that the "normal" manner to call a function should be via
> subsref or do_multi_index_op. Extracting the function pointer still
> works, but simply ignores the overloads.
>
> So the present state is that overloaded function handles work from
> m-files, cellfun, bsxfun (I fixed those) and any other compiled
> functions using do_multi_index_op directly. Functions using the hacky
> method simply ignore overloads, so existing code should work. For some
> functions (e.g. quad) overloaded handles make little or no sense, so
> it's maybe useless to attempt to fix those. Right now I couldn't find
> out what other built-ins needs adjustments, but I suppose time will
> tell.
>
> enjoy!
>
> PS. Information has been previously given on this list that overloaded
> handles are covered by certain US patents by MathWorks. I leave it to
> anyone interested to check whether any patents may apply. Personally,
> I care little about that, partly because I disregard software patents
> in general, partly because as an EU citizen US patents do not directly
> affect me anyway (isn't that selfish thinking? sorry).
> As an "expert in the field" (in terms of the relevant lawyer language)
> I can say that the implementation was "obvious" in the sense that it
> was straightforward once I chose *what* to implement, and I only
> borrowed the idea of caching dispatch to built-in classes from
> MathWorks (maybe it would occur to me anyway, but I confess that I saw
> that on their site). IMHO such abstract ideas are not patentable, not
> even in the US.
>
>