+1. We need number traits for a variety of circumstances; I was also
contemplating them as a step in generalizing the FloatRange/StepRange
distinction, for example to Unitful numbers (numbers with physical units).
You need type-stability for the created range object, so I think a trait is
the only way to go here.
--Tim
On Mon, Oct 24, 2016 at 3:30 PM, Jeffrey Sarnoff <jeffrey.sarn...@gmail.com>
wrote:
> for values, something like this may do:
>
> function isexact(x)
> if isa(x, Integer) || isa(x, Rational)
> true
> elseif isa(x, Complex)
> isExact(x.re)
> else
> false
> end
> end
>
>
>
>
> On Monday, October 24, 2016 at 2:09:09 PM UTC-4, jw3126 wrote:
>>
>> A couple of times I was in a situation, where I had two algorithms
>> solving the same problem, one which was faster and one which was more
>> numerically stable. Now for some types of numbers (FloatingPoint,
>> Complex{Float64}...) numerical stability is important while for others it
>> does not matter (e.g. Integer, Complex{Int64}...) etc.
>> In such situations it would be handy to have a mechanism (a trait) which
>> decides whether a type is exact or prone to rounding.
>> Maybe there is already such a thing somewhere?
>>
>
