{"action":"created","issue":{"url":"https://api.github.com/repos/rreusser/ode-euler/issues/1","labels_url":"https://api.github.com/repos/rreusser/ode-euler/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/rreusser/ode-euler/issues/1/comments","events_url":"https://api.github.com/repos/rreusser/ode-euler/issues/1/events","html_url":"https://github.com/rreusser/ode-euler/pull/1","id":121628570,"number":1,"title":"Updates + Comments ","user":{"login":"Planeshifter","id":1913638,"avatar_url":"https://avatars.githubusercontent.com/u/1913638?v=3","gravatar_id":"","url":"https://api.github.com/users/Planeshifter","html_url":"https://github.com/Planeshifter","followers_url":"https://api.github.com/users/Planeshifter/followers","following_url":"https://api.github.com/users/Planeshifter/following{/other_user}","gists_url":"https://api.github.com/users/Planeshifter/gists{/gist_id}","starred_url":"https://api.github.com/users/Planeshifter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Planeshifter/subscriptions","organizations_url":"https://api.github.com/users/Planeshifter/orgs","repos_url":"https://api.github.com/users/Planeshifter/repos","events_url":"https://api.github.com/users/Planeshifter/events{/privacy}","received_events_url":"https://api.github.com/users/Planeshifter/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-12-11T03:22:04Z","updated_at":"2015-12-14T12:02:55Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/rreusser/ode-euler/pulls/1","html_url":"https://github.com/rreusser/ode-euler/pull/1","diff_url":"https://github.com/rreusser/ode-euler/pull/1.diff","patch_url":"https://github.com/rreusser/ode-euler/pull/1.patch"},"body":"Thanks again for your contribution!\r\n\r\nDid you use the yeoman generator to set up the module? It's outdated, unfortunately, sorry about that. Will be updated shortly. I have updated the dotfiles and switched from `coveralls` to `codecov`, as the former code coverage service had frequent outages in the past. With `codecov`, if you happen to use Chrome, there is also a nice plugin to directly view the coverage reports on Github in the Browser. You might want to check that one out.\r\n\r\nI made some other slight changes with respect to the code style, and added comments to outline our current thinking. Please share your thoughts and objections in case something sounds unreasonable to you. \r\n\r\nWith respect to the Factory function, I removed it and simply exported the constructor function. The only rationale for the Factory function was that it would be invoked without the `new` keyword, correct? I changed the constructor function so that it can be also invoked without `new`, as this is how we have handled constructors in the past. Does this sound reasonable or are there reasons to revert this change?\r\n\r\nSome other comments are directly attached to the relevant lines.\r\n\r\nPlease let me know any questions or comments you have. "},"comment":{"url":"https://api.github.com/repos/rreusser/ode-euler/issues/comments/164420467","html_url":"https://github.com/rreusser/ode-euler/pull/1#issuecomment-164420467","issue_url":"https://api.github.com/repos/rreusser/ode-euler/issues/1","id":164420467,"user":{"login":"kgryte","id":2643044,"avatar_url":"https://avatars.githubusercontent.com/u/2643044?v=3","gravatar_id":"","url":"https://api.github.com/users/kgryte","html_url":"https://github.com/kgryte","followers_url":"https://api.github.com/users/kgryte/followers","following_url":"https://api.github.com/users/kgryte/following{/other_user}","gists_url":"https://api.github.com/users/kgryte/gists{/gist_id}","starred_url":"https://api.github.com/users/kgryte/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kgryte/subscriptions","organizations_url":"https://api.github.com/users/kgryte/orgs","repos_url":"https://api.github.com/users/kgryte/repos","events_url":"https://api.github.com/users/kgryte/events{/privacy}","received_events_url":"https://api.github.com/users/kgryte/received_events","type":"User","site_admin":false},"created_at":"2015-12-14T12:02:55Z","updated_at":"2015-12-14T12:02:55Z","body":"A convenience wrapper seems reasonable. We provide something like that with `dstructs/matrix`, where the main export has a polymorphic interface, but the constructor is an extended argument list. We see two use cases here: the former for a REPL, the latter for application code. One of principal reasons for validating input arguments is for interactive environments. For application code having tests, etc, we like to expose lower level interfaces. Something similar could possibly be done here.\r\n\r\nRe: `lists` and `arrays`. Numpy methods seem to typically accept `array-like` args, which means `lists` are accepted (e.g., [`sin`](http://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.sin.html#numpy.sin)).\r\n\r\nIn JS and input args, yeah, this is tricky. So much of what people currently do, especially in data visualization, involves vanilla `arrays` and JSON. D3, in particular, essentially codified the accessor pattern, thus allowing complex data structures to be leveraged for data viz **without** requiring intermediate data formats, etc.\r\n\r\nGranted, life would be easier from a development perspective if we forced people to use particular data structures / interfaces. I could, however, see this as a deterrent for actually using the modules; e.g., why marshal and unmarshal when I can just write a `function` which operates on the data (in an `array`) directly?\r\n\r\nOf course, it is worth pointing out that the reality is `matrices`, `ndarrays`, etc, are just vanilla `arrays` and `typed-arrays` with some API sugar. In which case, seems a bit odd that we would reject vanilla data sets and only accept the same data sets with a couple extra attributes, especially if those attributes are not required for `function` to work. For instance, `sin()`, `cos()`, etc, don't need to know a `matrix` shape when performing an element-wise operation.\r\n\r\nFor other operations, say, inverting a `matrix`, then, sure, requiring a `matrix` is understandable, as the extra meta-information is necessary. So, here, the question is whether the extra meta information is necessary for the module to work? My thinking is no.\r\n\r\nRe: testing. The usual gamut refers to checking that validators work correctly. Meaning, if an argument must be an `array`, then we should test that a `string`, `number`, `boolean`, `null`, `undefined`, `{}`, `function(){}`, `NaN`, etc are not allowed through (i.e., the `function` should `throw`). The gamut is mainly used to test argument validation.\r\n\r\nRe: `typed-arrays`. Does it make sense to only accept `float64` `arrays`? Or maybe we could accept all types of `typed-arrays`, but, internally, anything other than `float64` gets [cast](https://github.com/dstructs/cast-arrays) to `float64`? I might go for the latter.\r\n\r\nRe: `matrices`. Accepting a `matrix` would mean accepting multiple initial states, not that `matrix` operations are necessarily involved. For example, each `matrix` row could be a set of initial parameters. The algorithm would then solve the ODE for each row. (ala axis based operations) Obviously, this could be complex in the general case where multiple input arguments are `matrices` and thus argument combinations are permitted (e.g., a collection of 10 initial states where each state is tested against a collection of 10 parameter sets; thus 100 different combinations). (__NOTE__: I am not necessarily advocating for this. More about who shoulders the complexity.)\r\n\r\nDo we have any reference APIs for how these algos are implemented in other platforms? e.g., [scipy](http://docs.scipy.org/doc/scipy-0.14.0/reference/integrate.html)."}}