New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename 'linear' state updater? #877

Closed
mstimberg opened this Issue Sep 7, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@mstimberg
Member

mstimberg commented Sep 7, 2017

During the review of the recent paper comparing neural simulators, the authors mentioned that they were somewhat confused that our state updater is called "linear". I never gave this much thought, but there is a certain inconsistency: most of our state updater use as a name the method they use ("Euler", "RK2", etc.), but the "linear" state updater is named after the type of equations it can solve. The authors mentioned above were actually thinking about "linear" as a method, i.e. they thought it would be a linear approximation (or in other words, the forward Euler method).

Following the logic for the names of all other updaters (except the "independent" updater, but I'll open another issue about that one right away), I have to agree that a better name might be "exact" (my preference), or maybe "analytic"?

Of course we'd have to be careful changing this, given that it is in examples all over the place. I would just have it raise a warning first, and change it everywhere in the documentation/examples/tutorials. When/if we finally remove it, it should still give an error message that states what to use instead.

@thesamovar , @romainbrette: thoughts?

@thesamovar

This comment has been minimized.

Show comment
Hide comment
@thesamovar

thesamovar Sep 7, 2017

Member

It's logical but I don't think it's important enough to justify a backwards incompatibility. I'd be happy to introduce a new name, but not eliminate the old name. If we do that, I'd be happy with exact but might we ever want to have an exact solver that can handle more complicated equations than linear? Would that be an issue?

Member

thesamovar commented Sep 7, 2017

It's logical but I don't think it's important enough to justify a backwards incompatibility. I'd be happy to introduce a new name, but not eliminate the old name. If we do that, I'd be happy with exact but might we ever want to have an exact solver that can handle more complicated equations than linear? Would that be an issue?

@mstimberg

This comment has been minimized.

Show comment
Hide comment
@mstimberg

mstimberg Sep 8, 2017

Member

It's logical but I don't think it's important enough to justify a backwards incompatibility.

Fully agree, we don't want to break scripts using it. For me it would be just a question of adding a new name "silently", or raising a warning if the old name is used.

If we do that, I'd be happy with exact but might we ever want to have an exact solver that can handle more complicated equations than linear? Would that be an issue?

What kind of equations would that be? If there is a relevant class of such equations, I'd be happy to add a solver for them rather sooner than later (not impossible that we can do this via sympy already). Either way, we'd probably include such a solver in the exact solver instead of creating a new one?

Member

mstimberg commented Sep 8, 2017

It's logical but I don't think it's important enough to justify a backwards incompatibility.

Fully agree, we don't want to break scripts using it. For me it would be just a question of adding a new name "silently", or raising a warning if the old name is used.

If we do that, I'd be happy with exact but might we ever want to have an exact solver that can handle more complicated equations than linear? Would that be an issue?

What kind of equations would that be? If there is a relevant class of such equations, I'd be happy to add a solver for them rather sooner than later (not impossible that we can do this via sympy already). Either way, we'd probably include such a solver in the exact solver instead of creating a new one?

@thesamovar

This comment has been minimized.

Show comment
Hide comment
@thesamovar

thesamovar Sep 8, 2017

Member

OK, I'd be happy with this then. Indeed, if we ever did extend our exact solver to cover more equations then we could include that with the same name.

Member

thesamovar commented Sep 8, 2017

OK, I'd be happy with this then. Indeed, if we ever did extend our exact solver to cover more equations then we could include that with the same name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment