implement ifelse() as union of results

[gwater]

as suggested in #11

[gwater]

unfortunately ifelse() is a builtin and therefore cannot be extended:

julia> import Base: ifelse
julia> ifelse(::Int) = nothing
ERROR: cannot add methods to a builtin function
Stacktrace:
 [1] top-level scope at none:0

FYI @oschulz

[oschulz]

I know. :-(

Ran into this when I did the benchmark example in #11, that's why I had to use a custom interval_ifelse().

[gwater]

Ok, I started a discussion on the Julia discourse, maybe there is some way around it

[oschulz]

Thanks!

[oschulz]

@gwater , should we reopen this now that ifelse is becoming generic in Julia v1.8.0?

[gwater]

I was thinking about that the other day… I'm currently working on an overhaul of the internals, basically separating the notion of numbers and intervals. Essentially I define a type

struct FuzzyReal{T} <: AbstractFloat
    interval::IEEE1788_Interval{T}
end

and then the method would look like this

ifelse(::Missing, a::FuzzyReal{T}, b::FuzzyReal{T}) = FuzzyReal(hull(a.interval, b.interval))

correct?

Notably, if the two underlying intervals are disjoint, we cannot describe their union using a single IEEE1788 interval. That's why we need to take the hull of their union.

[oschulz]

I agree, that definition would be best - anything other than the hull (tracking the separate intervals) would have the potential of growing exponentially.

I wonder if there's a better name than FuzzyReal - sounds a bit like fuzzy logic, which it's not, for course. And it may sound a bit to, well, fuzzy, for something that follows rigorous rules and gives guarantees (true result will be in the interval). Why not NumberInterval, in line with the package name?

[oschulz]

ifelse(::Missing, a::FuzzyReal{T}, b::FuzzyReal{T}) is problematic, though, it forces the user to pass FuzzyReal explicitly, which makes it difficult to use intervals in generic code. If comparisons of intervals would return a custom value, e.g. Indeterminate() or so, ifelse could be specialized in a more generic way like ifelse(::Indeterminate, a, b) = interval_hull(a, b).

[gwater]

ifelse(::Missing, a::FuzzyReal{T}, b::FuzzyReal{T}) is problematic, though, it forces the user to pass FuzzyReal explicitly, which makes it difficult to use intervals in generic code. If comparisons of intervals would return a custom value, e.g. Indeterminate() or so, ifelse could be specialized in a more generic way like ifelse(::Indeterminate, a, b) = interval_hull(a, b).

That's an interesting point. I have been wondering if it might be worth defining this new type (regardless of its name) with a field for the third logical value. So:

struct FuzzyReal{T, V}
    interval::IEEE1788_Interval{T}
    indeterminate::V
end

then we could set the field indeterminate to missing by default but users could choose to set a different value to define custom behavior in indeterminate cases. What do you think?

[gwater]

Why not NumberInterval, in line with the package name?

In thinking about the relationship between the number subtype and the IEEE intervals more deeply I have found that I would rather separate the notions of intervals and numbers completely. So the FuzzyReal should, in my opinion, not provide any set behaviours such as intersections, hulls, etc. Consequently, the name should make that clear, too.

[oschulz]

with a field for the third logical value.

Nowadays, a Julia Union should handle that efficiently, I hope. I would suggest that comparison operators return a Union{Indeterminate,Bool}, with numeric intervals being a separate thing.