I hadn't thought of using the debugger to step through and see where a function call ends up. That is a great idea.
Thanks, Colin On Tuesday, 18 October 2016 02:01:43 UTC+11, Patrick Belliveau wrote: > > 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> wrote: >> >>> Le samedi 15 octobre 2016 à 20:36 -0700, colint...@gmail.com 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 >>> >> >>
