I hadn't thought of using the debugger to step through and see where a
function call ends up. That is a great idea.
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
> 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.
>> 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
>>> 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
>>> 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
>>> > 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).
>>> > Cheers and thanks in advance to all repsonders,
>>> > Colin