I would add the general comment that in julia 0.5 you can use Gallium to step into a call to a base function and explore what's actually being called. For the .< example, from the julia prompt:
using Gallium @enter 0.4 .< 0.5 @enter 0.4 .< 0.5 In operators.jl:159 158 .!=(x::Number,y::Number) = x != y 159 .<( x::Real,y::Real) = x < y 160 .<=(x::Real,y::Real) = x <= y 161 const .≤ = .<= About to run: (<)(0.4,0.5) For your problem, checking the documentation seems like a better place to start than firing up the debugger but it's another good tool to have in the toolbox. Patrick On Sunday, October 16, 2016 at 4:02:21 PM UTC-7, Colin Bowers wrote: > > This was a very helpful answer. Thank you very much for responding. > > Cheers, > > Colin > > On 16 October 2016 at 20:23, Milan Bouchet-Valat <nali...@club.fr > <javascript:>> wrote: > >> Le samedi 15 octobre 2016 à 20:36 -0700, colint...@gmail.com >> <javascript:> a >> écrit : >> > Hi all, >> > >> > Twice now I've thought I had overloaded the appropriate functions for >> > a new type, only to observe apparent inconsistencies in the way the >> > new type behaves. Of course, there were no inconsistencies. Instead, >> > the observed behaviour stemmed from overloading a function that is >> > not at the bottom of the function chain. The two examples where I >> > stuffed up were: >> > >> > 1) overloading Base.< instead of overloading Base.isless, and >> In this case, the help is quite explicit: >> help?> < >> search: < <= << <: .< .<= .<< >> >> <(x, y) >> >> Less-than comparison operator. New numeric types should implement this >> function for two arguments of the new type. Because of the behavior of >> floating-point NaN values, < implements a partial order. Types with a >> canonical partial order should implement <, and types with a canonical >> total >> order should implement isless. >> >> > 2) overloading Base.string(x) instead of overloading Base.show(io, >> > x). >> This one is a bit trickier, since the printing code is complex, and not >> completely stabilized yet. Though the help still gives some hints: >> >> help?> string >> search: string String stringmime Cstring Cwstring RevString RepString >> readstring >> >> string(xs...) >> >> Create a string from any values using the print function. >> >> So the more fundamental function to override is print(). The help for >> print() says it falls back to show() if there's no print() method for a >> given type. So if you don't have a special need for print(), override >> show(). >> >> > My question is this: What is the communities best solution/resource >> > for knowing which functions are at the bottom of the chain and thus >> > are the ones that need to be overloaded for a new type? >> In general, look at the help for a function. If there's no answer >> (which is a most likely a lack in the documentation which should be >> reported), look for it in the manual. The latter can always be useful, >> even if the help already gives a reply. >> >> But documentation is perfectible, so do not hesitate to ask questions >> and suggest enhancements (ideally via pull requests when you have found >> out how it works). >> >> >> Regards >> >> >> > Cheers and thanks in advance to all repsonders, >> > >> > Colin >> > >
