Regarding Steven Johnson's suggestion, I am unclear about a certain point. Suppose, following Steven's suggestion, I define
isless_eq(x,y) = !isless(x,y) && !isless(y,x) First question: this is equivalent to: isless_eq(x::Any,y::Any) = !isless(x,y) && !isless(y,x) correct? Now suppose I have another function in which there is an invocation isless_eq(a,b) where a and b are both Int, and the compiler knows that they are both Int. Does the compiler generate a specialized version of isless_eq with the comparison for Int hard-coded? Or does the above definition of isless_eq generate a single function called isless_eq that decides at run-time using some kind of dispatch table which version of isless should be invoked? I was under the impression that you need to use parametrized types to get Julia to generate specialized versions with hardcoded choices of subroutines, whereas Any arguments lead to one version of the routine with run-time dispatch. For my application, I would prefer to avoid run-time dispatch for performance reasons, which means that I apparently can't use Steven's suggestion if my understanding is correct. Thanks, Steve Vavasis 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! > > >
