If you do decide to keep it as a FloatingPoint subtype, you should probably
go the other route of just making sure it interacts natively with the
standard core operators, promote, convert, etc... Then the colon syntax
should work automatically, returning a FloatRange{JDate} (which can become
an Array{JDate,1} via collect()).
On Wed, May 13, 2015 at 9:06 PM, Chris <7hunderstr...@gmail.com> wrote:
> Now that you mention it, I think the only reason I made it a subtype of
> FloatingPoint was some (very) vague notion of type inference and
> performance. I will re-examine that decision now, I think. Thanks for your
> help.
>
> Chris
>
>
> On Wednesday, May 13, 2015 at 2:30:53 PM UTC-4, Josh Langsfeld wrote:
>>
>> Yeah, I missed that you were subtyping FloatingPoint before. It still
>> worked ok for me though once I also defined colon methods suggested by the
>> ambiguity warnings. in my case it was:
>>
>> colon(::JDate, ::JDate, ::JDate)
>> colon(::JDate, ::FloatingPoint, ::JDate)
>> colon(::JDate, ::Real, ::JDate)
>>
>> It seems to cause a lot of problems to subtype it as a FloatingPoint
>> though, and I'm not sure what benefit you are getting out of it. For
>> example, my installation won't even print a JDate value because it checks
>> for finiteness first which requires subtraction to be defined. But I assume
>> you can work around that by just defining enough methods of operators and
>> promotion rules.
>>
>> On Wednesday, May 13, 2015 at 12:29:30 PM UTC-4, Chris wrote:
>>>
>>> What should the new method be, precisely? I tried colon(start::JDate,
>>> step::Real, stop::JDate) = JDate(colon(float64(start),step,float64(stop)) (I
>>> have conversion rules defined for the JDate to Float64 conversions), but I
>>> get several warning messages of the form:
>>>
>>> Warning: New definition
>>> colon(JDate,Real,JDate) at <path>\types.jl:25
>>> is ambiguous with:
>>> colon(T<:FloatingPoint,T<:FloatingPoint,T<:FloatingPoint) at
>>> range.jl:122.
>>> To fix, define
>>> colon(JDate,JDate,JDate)
>>> before the new definition.
>>>
>>> Then, when I test this, I still get a Array{Float64,1}.
>>>
>>> Thanks,
>>> Chris
>>>
>>> On Wednesday, May 13, 2015 at 12:05:19 PM UTC-4, Josh Langsfeld wrote:
>>>>
>>>> I believe you only need to add a method to Base.colon of the form
>>>> 'colon(start::JDate, step::Real, stop::JDate)'
>>>>
>>>> I just tested it and that was the only thing needed to make the the
>>>> [J1:s:J2] syntax work.
>>>>
>>>> On Wednesday, May 13, 2015 at 11:13:53 AM UTC-4, Chris wrote:
>>>>>
>>>>> I have a simple custom type called JDate:
>>>>>
>>>>> immutable JDate <: FloatingPoint
>>>>>
>>>>> t::Float64
>>>>>
>>>>> end
>>>>>
>>>>> When I construct a range, e.g. [J1:s:J2], where J1::JDate, s::Real,
>>>>> J2::JDate, I'd like the result to be an Array{JDate,1}. What
>>>>> conversion/promotion rules are necessary to do this?
>>>>>
>>>>> Thanks in advance,
>>>>> Chris
>>>>>
>>>>
