Help needed fixing stack overflow

General Usage
, ,
1

I have a composite type that I use to simplify xy and xyz vector operations. I use it instead of an array or a static array because it doesn’t rely on external packages and is fairly quick and allows me to easily overload other functions that may expect it.

I also tried to define the iterator and eltype so it could be used with differntialequations. Not knowing any better and just starting to use the diffeq packages.

It causes julia to blow chunks in a stack overflow way. Can someone show me the syntax of the eltype overload to stop this from happening. It is caused by the determination of the eltype by the function: recursive_unitless_bottom_eltype used by DifferentialEquations.

I have a much simpler composite type that fails in exactly the same way. I feel if someone can point out my noob error on this one I can fix it on my function.

using DifferentialEquations

struct mytest
       a::Float64
       b::Float64
       end

recursive_unitless_bottom_eltype([mytest(1.0,2.0),mytest(3.0,4.0)])
ERROR: StackOverflowError:
Stacktrace:
 [1] recursive_unitless_bottom_eltype(::Type{Any}) at C:\Users\bakerar\.julia\packages\RecursiveArrayTools\DBKJE\src\utils.jl:86 (repeats 65234 times)
 [2] recursive_unitless_bottom_eltype(::Type{Array{mytest,1}}) at C:\Users\bakerar\.julia\packages\RecursiveArrayTools\DBKJE\src\utils.jl:87
 [3] recursive_unitless_bottom_eltype(::Array{mytest,1}) at C:\Users\bakerar\.julia\packages\RecursiveArrayTools\DBKJE\src\utils.jl:85
 [4] top-level scope at none:0
2

This looks like it’s just a bug in RecursiveArrayTools.jl. You’re calling a function which ends up calling itself over and over forever. I’d suggest opening an issue in that package with the same example. If you’re feeling more adventurous and helpful, you can try to use Debugger.jl to step into the function call and try to figure out why it keeps calling itself over and over.

2 Likes
3

It’s because the element type of mytest is Any:

eltype(eltype([mytest(1.0,2.0),mytest(3.0,4.0)])) # Any

This will work:

using RecursiveArrayTools

struct mytest <: Number
    a::Float64
    b::Float64
end
Base.eltype(::Type{mytest}) = Float64
recursive_unitless_bottom_eltype([mytest(1.0,2.0),mytest(3.0,4.0)])

which is a lot like how Complex works. I guess the real question is, what are you trying to do here? Is something like ComponentArrays.jl a better fit?

2 Likes
4

Debugger crashes Julia.

5

Thank you for the syntax of the eltype. Nowhere in the documentation could I find that syntax. I thought I could find that and searched other repos, but it doesn’t pop up on google, it’s tough. Will it work without the <:Number, or does it need <:Number. I think I can put that in, but I’m not sure what side effects there will be.

I’ll check out ComponentArrays.jl as I am not familiar with it. The component type started out as one of the first things I tried to do to learn Julia. I ended up sticking with it because it worked fairly well and seemed to be faster when I timed other alternatives. But I’m asking it to do a lot more now, so it may be worth another look.

It’s main job is 3DOF/6DOF type information and vector manipulations associated with those and related simulations.

6

I say “nowhere in the documentation” but it could have been looking me straight in the face.

7

It does seem like anything that Stack overflows vs giving me a concise error could be looked at. I’ll make a note to post this example as an issue which overflows on that repo.

8

Well… it is known that the Julia docs has problems of discoverability, but the documentation for eltype itself has a source button in the lower right side that may give an idea of how to define it.

1 Like
9

It doesn’t have to be <: Number, but it needs to have enough dispatches to work.

FWIW, we could replace uEltypeNoUnits and this recursion for bottom types with u ./ u to initialize the unitless values.

1 Like
10

It shouldn’t (and doesn’t for most people). Can you file an issue with details about your setup?

1 Like
11

Follow up. I’ve been hacking on my composite type a little. It seems to run into a problem because the type is a “struct” and not a mutable struct. It doesn’t really boil down into a single number so I took off the <:Number qualified and have been defining the Base overrides I didn’t have like adjoint, abs2, etc.
The thing I don’t know how to handle is the setindex!. It’s not mutable. Is it a problem it wants to call setindex! on it instead of setindex?
Any thoughts?

12

what’s it trying to setindex!? I’d have to see where that shows up. But least right now, there’s weird issues with arbitrary amounts of nesting because broadcast doesn’t have a way to recurse without a special type, so DiffEq doesn’t support arbitrary levels of nesting, i.e. array of arrays. Abstract arrays of abstract number types are fine, but I think you’re treading into the array of array no-mans-land. ComponentArrays, MultiScaleArrays, etc. all make it work by defining the recursion of the broadcast on its own.

1 Like
13

OK. Thanks. Trying to get enough of an understanding so I can get it clear in my mind how to proceed. I need to figure out how to map these vectors and quaternions I hold together in a vehicle state type object in and out of the diffeq engine efficiently especially since what I really care about is the software based controller that needs to affect the dynamics. But the software inputs will becoming from sensor models using these states from one, two or more of these vehicle objects.

14

If you could remind me which command I need to run to dump the package and language state and env variables, I could supply that with the issue. The package status only seems to get the active setup which I think is reaching into the default profile to grab some of the packages because I haven’t added the Diffeq stuff to the active package, but it still is able to find it.

15 
julia> versioninfo()
pkg> st