Attempt to improve type stability

[ctessum]

Fixes #38

[mykelk]

Thanks for the PR! It looks like some of the tests are not passing?

[ctessum]

I'll try to fix it. I will also add some additional tests.

[ctessum]

OK, the tests are passing now. I also attempted to reduce the allocations in the interpolants function, and marked the remaining allocations with a @test_broken. Let me know what you think.

[mykelk]

It seems to break on Julia 1.0. We don't necessarily have to provide backward support to 1.0, but it might be nice if it is not too complicated.

ERROR: LoadError: LoadError: UndefVarError: @allocations not defined
Stacktrace:
 [1] top-level scope
 [2] include at ./boot.jl:317 [inlined]
 [3] include_relative(::Module, ::String) at ./loading.jl:1044
 [4] include(::Module, ::String) at ./sysimg.jl:29
 [5] include(::String) at ./client.jl:392
 [6] top-level scope at none:0
in expression starting at /home/runner/work/GridInterpolations.jl/GridInterpolations.jl/test/runtests.jl:417

[ctessum]

Sure, I think just removing the test for allocations might fix that. (I don't have julia 1.0 installed to check) Does it work now?

[mykelk]

Got it. I think we can merge this after @zsunberg gives us a thumbs up!

[zsunberg]

Thanks @ctessum ! This is a huge help. The only thing I am concerned about is replacing zeros/ones with undef. Can you respond to that before we merge?

[zsunberg]

I am a bit concerned about this change. How can we be completely sure that it does not change the code logic to initialize these to undef rather than ones or zeros? (note that the tests may pass most of the time even if the code relies on zeros since memory is often initialized to zeros or small numbers.)

I think we should either leave this as is (with ones or zeros) or carefully go through the code below looking at all of the assignments to these variables and write out a brief proof that the initialization does not matter.

[mykelk]

Good point. Zeroing memory typically does not have an impact on runtime.

[ctessum]

The original goal for that change was to reduce allocations, because the ones() and zeros() calls would theoretically be allocating arrays, although I guess the compiler could be factoring that out. From looking at the code I don't believe the arrays need to be explicitly initialized, but just in case I've added it back in, just using broadcasting instead of allocating new arrays for the initialization.

[zsunberg]

Thanks @ctessum ! Yeah, If I remember correctly, we verified that @MVector zeros(...) etc. does not allocate as long as the MVector does not leave the scope of the function. I added an explanatory note.

If we wanted to avoid this and be explicit about proving that the initialization doesn't matter, we could use PushVectors backed with MVectors, but that might require some work.

[mykelk]

Cool. I think we can merge once @zsunberg concerns are addressed in this PR.

[zsunberg]

Looks good to me now

[zsunberg]

@ctessum Thanks again!

One note for the future: this PR was a bit hard to read because it included both substantive changes to the code and a bunch of minor style changes (e.g. adding spaces). The style changes are nice, but it is better to make separate PRs, just so that it is easy to see and deal with the important changes 😄

[zsunberg]

BTW I tried to add allocation tests in #50, but they are failing :/ It seems like we didn't quite prevent all the allocations. The results were the same before this PR though.

[ctessum]

Sorry about the style changes, they were just added automatically and I didn't notice until later.