JeffB's FixedPointNumbers does it; seeing that, I have a model.
On Tuesday, December 1, 2015 at 2:05:25 PM UTC-5, Jeffrey Sarnoff wrote:
>
> As an example: using JuliaGeometry/Quaternion.jl and initializing a
> Quaternion with FlexFloats instead of Float64s. I have all of the
> mathematical support necessary to handle every operation that the
> Quaternion package uses where the Quaternion elements are FlexFloats. The
> type there is:
>
> ```julia
> immutable Quaternion{T<:Real} <: Number s::T v1::T v2::T v3::T norm::Bool
> end
> ``` Without changing to my abstract hierarchy, any conversion function
> tried responds "ERROR: TypeError: Quaternion: in T, expected T<:Real, got
> Type{FlexibleFloat.FlexFloat{_,_}}." Altering my type to be ```julia
> immutable FlexFloat{T<:WorkFlex, F<:WorkFloat} <: Real lo::F hi::F end
> ``` Does not help; it wants my 'F' to be <: Real (or something like that).
> My 'F' is Union{Float64, Float32} (now) -- reasonably <: Real, but it does
> noe convert. There are many good packages that use a similar setup, type
> T{..} <: Real, or type T{..} <: Number. I am looking for the generalized
> perspective and associated way of coding that lets such
> conversions/promotions just work.
>
>
> On Tuesday, December 1, 2015 at 1:05:27 PM UTC-5, Tom Breloff wrote:
>>
>> I think I'm slightly confused on your end goal. Can you maybe give a
>> concrete example of the types involved and the operation, and tell us 1)
>> what type you want the result to be, and 2) why simple conversions won't do
>> the trick.
>>
>> If you can do "f(convert(T1, x1), convert(T2, x2))" for some method f,
>> types T1/2, and values x1/2 and get your result, then I expect the
>> promotion system will work fine.
>>
>> On Tuesday, December 1, 2015, Jeffrey Sarnoff <[email protected]>
>> wrote:
>>
>>> There may be some way to leverage the promotion system for this
>>> purpose. I do not know how to do that.
>>>
>>> On Tuesday, December 1, 2015 at 12:30:57 PM UTC-5, Jeffrey Sarnoff wrote:
>>>>
>>>> Yes -- it rocks. Promotion+conversion needs to know detailed stuff
>>>> about the destination type (unsurprisingly). I'm hoping for a [partial]
>>>> meta- or supra- way that would simplify work for me and for other people
>>>> who may want this as another way to use their own packaged number stuff.
>>>> Is there an avenue that [partially] obviates the need to deeply code each
>>>> package's preparation?
>>>>
>>>> On Tuesday, December 1, 2015 at 12:01:27 PM UTC-5, Tom Breloff wrote:
>>>>>
>>>>> Have you tried Julia's promotion mechanism? This has worked well for
>>>>> me in the past, although there may be a slight performance penalty... I
>>>>> can't comment on that.
>>>>>
>>>>>
>>>>> http://docs.julialang.org/en/release-0.4/manual/conversion-and-promotion/#promotion
>>>>>
>>>>> On Tue, Dec 1, 2015 at 11:54 AM, Jeffrey Sarnoff <[email protected]
>>>>> > wrote:
>>>>>
>>>>>> I am working on a module that uses bounded intervals. It would be
>>>>>> great if the result were easy to use with other's packaged
>>>>>> floating-point
>>>>>> based or Real derived types.
>>>>>> They work like stretchy Float64s, and support arith, exp, log,
>>>>>> [a]trig[h], and cdf+pdf+quantile for univariate continuous distributions.
>>>>>>
>>>>>>
>>>>>> Is there any type hierarchy modification with some generalized code
>>>>>> that would make "conversion to __ not found" happen less when using
>>>>>> this as if it were Float64 with others' floating point based types
>>>>>> that are not dependant on sizeof()?
>>>>>>
>>>>>> ```julia
>>>>>>
>>>>>> abstract EnhancedFloat <: Real abstract AnyFlexFloat <:
>>>>>> EnhancedFloat # FlexFloat is a (lo,hi) bounded interval # either or
>>>>>> both bounds may be Closed(Cl) or Open(Op) # e.g. ClOp(lo,hi) is a
>>>>>> ClOpen interval.
>>>>>> abstract OpOp <: AnyFlexFloat abstract ClOp <: AnyFlexFloat abstract
>>>>>> OpCl <: AnyFlexFloat abstract ClCl <: AnyFlexFloat typealias WorkFlex
>>>>>> AnyFlexFloat; # was Union{ClCl,ClOp,OpCl,OpOp} typealias WorkFloat
>>>>>> Union{Float64,Float32}; immutable FlexFloat{T<:WorkFlex, F<:WorkFloat} #
>>>>>> <:
>>>>>> Real does not seem to help much lo::F hi::F end ```
>>>>>>
>>>>>
>>>>>
