@test_approx_eq results in stack overflow for custom immutable type

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

@test_approx_eq results in stack overflow for custom immutable type

daniel.matz
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_test.jl (1K) Download Attachment
integer_times.jl (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: @test_approx_eq results in stack overflow for custom immutable type

Jacob Quinn
Very close!

There were actually some changes recently to hashing in general that make it a bit easier to get this working (although undocumented, *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, <[hidden email]> 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 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: @test_approx_eq results in stack overflow for custom immutable type

daniel.matz
In reply to this post by daniel.matz
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, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: @test_approx_eq results in stack overflow for custom immutable type

Jacob Quinn
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, <[hidden email]> 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, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: @test_approx_eq results in stack overflow for custom immutable type

daniel.matz
While I'm not a programming wizard like so many in this community, I do hope that the developers are familiar with the interfaces in Go.  I didn't see any mention of Go in that issue, though.

I like how in Julia the types and methods are decoupled, in that the methods aren't bound to the type, if I'm saying that correctly.  I find my thoughts translating to code more naturally than in C++, where everything seems to get coupled together.

The way Go does interfaces is kind of analogous to this.  The interfaces are defined, but then the types that implement the interface aren't specifically declared as such.  The type just has to provide the required methods.  It seems so lightweight and natural.

Whatever you all come up with, I'm sure it will be great, if the rest of Julia is any indication.

Daniel