Skip to content
This repository has been archived by the owner on Sep 9, 2024. It is now read-only.

Drafted some general API documentation #28

Merged
merged 1 commit into from
Mar 11, 2014
Merged

Drafted some general API documentation #28

merged 1 commit into from
Mar 11, 2014

Conversation

ivarne
Copy link
Contributor

@ivarne ivarne commented Mar 11, 2014

I think the time has now come to try to agree on some sort of document that describes the basic elements of a ODE solver interface in Julia.

The long discussions in the last few issues, has been very enlightening, but very hard to follow by outsiders who just wonder what the result of the discussion was.

I think this should be merged fairly soon, and then we can discuss details in later PR/issues. I have definitely ignored a few arguments, so please put them back in if you feel strongly for them.

@tomasaschan
Copy link
Contributor

Yeah, this looks good to me - at least it's a very good start towards documenting the API we're aiming for, and I think the discussion will benefit from us being able to do it in terms of pull requests with changes to this document.

Any idea why the travis build fails? (It's the nightlies build, so it's not unlikely that something has changed due to changes in julia master - I don't see why this PR would cause braking changes...)

@ivarne
Copy link
Contributor Author

ivarne commented Mar 11, 2014

Travis is failing because of #29, so it is not related.

tomasaschan pushed a commit that referenced this pull request Mar 11, 2014
Drafted some general API documentation
@tomasaschan tomasaschan merged commit e600ca5 into master Mar 11, 2014
@tomasaschan
Copy link
Contributor

There. Now discussion can continue in more pull requests.

@tomasaschan tomasaschan deleted the in/api_doc branch March 11, 2014 14:04

Each (adaptive) solver accepts 3 arguments

- `F`: the RHS of the ODE `dy/dt = F(t,y)`, which is a function of `t` and `y(t)` and returns `dy/dt::typeof(y./t)`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why y./t rather than y/t? Division by a scalar should always be defined (though we could also write it as y*inv(t)), and I think we should specify that t will be a scalar.

(In principle, you could have an interface where a vector of times are passed, but this is more important in languages that rely on vectorization for performance. It greatly simplifies the implementation of F if you know that t will always be a scalar.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because of JuliaLang/julia#5810. If you think "Division by a scalar should always be defined", you must raise your concern there. (Or maybe I'm just plaint wrong, in which case you should tell me here)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A/α is still defined. JuliaLang/julia#5810 only deprecated α/A.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I was confused in that regard. Thanks for the clarification. I'll change this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants