overloaded function handles

[Judd Storrs]

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.

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."

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) ;

Since the handle will have an empty list only the first time it is used, the
slow cache creation only happens once in both cases. The "if" test at each
use should be negligable compared to the path search esp. in a complied
language like C++. I'm NOT suggesting that we do this:

# Creation -- not in the style of Matlab
handle = create_new_handle() ;

# Evaluation -- not in the style of Matlab but very slow
handle = populate_function_list_danger_slow(handle, context2) ;
apply_overloaded_handle(handle,context2,args) ;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090729/eaf9932a/attachment.html