Re: [julia-users] How to determine which functions to overload, or, who is at the bottom of the function chain?
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 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 >>> >> >>
Re: [julia-users] How to determine which functions to overload, or, who is at the bottom of the function chain?
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 > 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 >> > >
Re: [julia-users] How to determine which functions to overload, or, who is at the bottom of the function chain?
This was a very helpful answer. Thank you very much for responding. Cheers, Colin On 16 October 2016 at 20:23, Milan Bouchet-Valat wrote: > Le samedi 15 octobre 2016 à 20:36 -0700, colintbow...@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 >
Re: [julia-users] How to determine which functions to overload, or, who is at the bottom of the function chain?
Le samedi 15 octobre 2016 à 20:36 -0700, colintbow...@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
[julia-users] How to determine which functions to overload, or, who is at the bottom of the function chain?
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 2) overloading Base.string(x) instead of overloading Base.show(io, x). 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? Cheers and thanks in advance to all repsonders, Colin