I think what would really be helpful here are explicit interfaces. There's an open issue about it: https://github.com/JuliaLang/julia/issues/6975
In a world with interfaces, you would have been told at some point (either inheriting from number or calling certain methods), that your type was missing the "Comparable" interface. You wouldn't see any stack overflows because you'd have been stopped before getting to that point. -Jacob On Wed, Jul 23, 2014 at 9:11 PM, <daniel.m...@gmail.com> wrote: > Wonderful! Thank you! > > The associated problem here is that the error message didn't really help > me. I know the developers are busy, but I hope that there's a way to > eventually improve the error message for this situation. > > Thanks again. > > Daniel > > On Tuesday, July 22, 2014 9:22:31 PM UTC-5, danie...@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 >> >
