Re: [julia-users] How to determine which functions to overload, or, who is at the bottom of the function chain?

[colintbowers]

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?

[Patrick Belliveau]

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?

[Colin Bowers]

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?

[Milan Bouchet-Valat]

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?

[colintbowers]

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