Very close! There were actually some changes recently to hashing in general that make it a bit easier to get this working (although undocumented <https://github.com/JuliaLang/julia/issues/6833>, *cough*, Stefan Karpinski, *cough*).
Here are the only changes I made to get `@test_approx_eq` working:
<(x::IntegerTime, y::IntegerTime) = compute_time(x) < compute_time(y)
Base.zero(x::Union(Type{IntegerTime},IntegerTime)) = IntegerTime()
(full code attached).
You don't need the other definitions of isless/< because Base already has
the promotion forms, so as long as you define your promotion rules, you're
set. You only need to define your own IntegerTime isless rule.
Cheers,
-Jacob
On Tue, Jul 22, 2014 at 10:22 PM, <daniel.m...@gmail.com> wrote:
> Inspired by the mighty ModInt example, I tried my hand at making a new
> immutable type. I wanted to make a FloatingPoint type that won't drift as
> it gets incremented, for use as a time in an integration loop. I've
> attached my code.
>
> The short story is: I try to compare the type's value to a Float64 literal
> with @test_approx_eq and I get the following error:
>
> ERROR: stack overflow
>> in <= at promotion.jl:170 (repeats 80000 times)
>> while loading
>> /Users/dmatz/Data/Projects/simulations/julia/time/integer_times_test.jl, in
>> expression starting on line 28
>
>
> If I manually convert my type to Float64, it of course works. I've
> provided a promote_rule to Float64, which seems to automatically make a lot
> of operators work. But why does @test_approx_eq not work? The stack trace
> doesn't really help. I tried to manually do a <=, and that works just
> fine...
>
> Thanks!
>
> Daniel
>
integer_times.jl
Description: Binary data
