Dear Patrick and Steven,
Thanks very much for the informative replies; this is very helpful! Could
I suggest that Steven's succinct explanation of how the compiler generates
multiple implementations as they are needed be inserted in section 1.12.1
of the manual ("defining methods"). Currently the manual does not appear
to explain how Julia deals operationally with functions whose arguments are
of type "Any" (or indeed, of any abstract type).
Thanks,
Steve
On Thursday, July 24, 2014 6:40:45 PM UTC+3, [email protected] wrote:
>
> Dear Julia users,
>
> For my implementation of 2-3 trees (SortOrderDict{K,V}) under development,
> it is necessary for the keys to have a total order with the < operator. In
> many places in my code, I also want to compare keys using other comparison
> operators such as == or <=. It seems that there are three ways to proceed:
>
> (1) The C++ approach: require only that the user of the data structure
> provide a '<' operator. All the other comparison operators can be built on
> top of '<', with a possible loss of performance. For example, a==b can be
> implemented as !(a < b) && !(b < a)
>
> (2) The burden-the-user approach: require the user to provide a complete
> set of comparison operators for the key type. This is possibly higher
> performance than the C++ approach.
>
> (3) The cool Julia approach: Use code introspection to determine which
> operators acting on keys have been provided by the user: only '<', or a
> more complete set. On the fly, compile my various routines (insert,
> delete, etc) to either use the user-provided complete set, or if not they
> are not provided, base everything on the user-provided '<'.
>
> But is the third approach really possible? Can someone show me how to
> write a function
>
> function isequal{K}(k1::K, k2::K)
>
> so that if only <(K,K) (but not ==(K,K)) is available, then the function
> is compiled as !(k1<k2)&&!(k2<k1), but if ==(K,K) is available, then the
> function is compiled as k1==k2 (Note: I don't want this implemented with a
> run-time 'if' statement; the loss of performance from 'if' at run-time
> would outweigh the benefit.)
>
> Thanks,
> Steve Vavasis
>
> P.S. Sorry again for my earlier post in which I complained that
> start/done/next was incorrectly designed in Julia; I'll try to keep future
> questions more intelligent!
>
>
>
