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]
> <javascript:>> 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 ```
>>>>>
>>>>
>>>>
