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 <jeffrey.sarn...@gmail.com>
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 <jeffrey...@gmail.com>
>>> 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 ```
>>>>
>>>
>>>

Reply via email to