Re: overloaded function handles

[Jaroslav Hajek]

On Wed, Jul 29, 2009 at 9:19 PM, Judd Storrs<address@hidden> wrote:
> Ok. Let me try again. I'm sorry for these long emails, but I feel like what
> I'm trying to say isn't being understood. The way I see it the reality is
> that octave can either infringe on Matlab's patent, not implement overloaded
> function handles or find some way to work around the claims. We all know
> about the patent so infringing at this point is willful infringement which
> triples damages.
>

Actually, I think I understood you quite well.

> I'm trying to work around the claims because I would like to be able to use
> overloaded function handles. I think I see a hole in the patent that relates
> to this statement in the Detailed Description:
>
> "ii. Path and scope are not considered when applying a function handle. The
> work of initial function lookup is performed when the function handle is
> constructed. This does not need to be done each time the function handle is
> applied. Indeed it cannot be done when applying the handle, because scope at
> the point of application is not the same as the scope at the point the
> function handle was constructed."
>

Detailed Description is irrelevant w.r.t. possible infringement,
AFAIK. It's the patent claims that are relevant.

> What I am saying is that "it cannot be done when applying the handle" is
> false in practice for the specific case of overloaded functions in the
> Matlab language if the path does not change between creation and use of the
> handle.
>
> I don't see how full compatibility can be achieved without infringing the
> patent, so I'm trying to propose a compromise. What I'm trying for is a loss
> of strange corners of compatibility in exchange for compatibility with what
> I suspect are the overwhelming number of cases. Of course, it would be
> possible to write code that behaves differently in Matlab and octave by
> exploiting the differences, but I'm unsure how likely it is that such code
> would be encountered in the wild?
>
> My questions are whether the discrepancy in implementation (i.e. overloaded
> functions created in context2 instead of context1) makes any real world
> difference to actual useful code? And whether anyone else agrees that it
> avoids the claims of the patent.
>
>
> --judd
>
>
>
>
> Shifting path lookup to the first (and *only* the first use) instead of at
> the time of creation will not significantly impact performance. i.e. the
> following analogous codes:
>
> # Creation -- in the style of Matlab
> handle = create_new_handle() ;
> handle = populate_function_list__danger_slow(handle, context1) ;
>
> # Evaluation -- in the style of Matlab
> apply_overloaded_handle(handle,context2,args) ;
>
> IMHO this implementation infringes because it is exactly what is
> claimed--the function list is created at the same time in the same scope
> that the handle is created. What I am suggesting is that instead
>
> # Creation -- not in the style of Matlab
> handle = create_new_handle_with_empty_function_list() ;
>
> # Evaluation -- not in the style of Matlab with cacheing
> if handle_has_empty_function_list(handle)
>     handle = populate_function_list_danger_slow(handle, context2) ;
> end
> apply_overloaded_handle(handle,context2,args) ;
>

I'm afraid this is not so easy - the function list can be, and often
will be, empty. You'd need a special flag for that, then it would
possibly work, at the cost of one extra test and storing an (otherwise
useless) extra bool inside the class. But I don't see what it's good
for, because the populate_xxx simply does not care what scope it is
run in. And I also really, really doubt that this workaround would
turn an infringing implementation into non-infringing. Any proofs?

cheers

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz