{"action":"created","issue":{"url":"https://api.github.com/repos/RobotLocomotion/drake/issues/2308","repository_url":"https://api.github.com/repos/RobotLocomotion/drake","labels_url":"https://api.github.com/repos/RobotLocomotion/drake/issues/2308/labels{/name}","comments_url":"https://api.github.com/repos/RobotLocomotion/drake/issues/2308/comments","events_url":"https://api.github.com/repos/RobotLocomotion/drake/issues/2308/events","html_url":"https://github.com/RobotLocomotion/drake/pull/2308","id":154083616,"number":2308,"title":"Introduce the SystemInterface and ContinuousSystemInterface.","user":{"login":"david-german-tri","id":17437069,"avatar_url":"https://avatars.githubusercontent.com/u/17437069?v=3","gravatar_id":"","url":"https://api.github.com/users/david-german-tri","html_url":"https://github.com/david-german-tri","followers_url":"https://api.github.com/users/david-german-tri/followers","following_url":"https://api.github.com/users/david-german-tri/following{/other_user}","gists_url":"https://api.github.com/users/david-german-tri/gists{/gist_id}","starred_url":"https://api.github.com/users/david-german-tri/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/david-german-tri/subscriptions","organizations_url":"https://api.github.com/users/david-german-tri/orgs","repos_url":"https://api.github.com/users/david-german-tri/repos","events_url":"https://api.github.com/users/david-german-tri/events{/privacy}","received_events_url":"https://api.github.com/users/david-german-tri/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/RobotLocomotion/drake/labels/priority:%20high","name":"priority: high","color":"b60205"},{"url":"https://api.github.com/repos/RobotLocomotion/drake/labels/team:%20software%20core","name":"team: software core","color":"0052cc"}],"state":"open","locked":false,"assignee":{"login":"sherm1","id":4088016,"avatar_url":"https://avatars.githubusercontent.com/u/4088016?v=3","gravatar_id":"","url":"https://api.github.com/users/sherm1","html_url":"https://github.com/sherm1","followers_url":"https://api.github.com/users/sherm1/followers","following_url":"https://api.github.com/users/sherm1/following{/other_user}","gists_url":"https://api.github.com/users/sherm1/gists{/gist_id}","starred_url":"https://api.github.com/users/sherm1/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sherm1/subscriptions","organizations_url":"https://api.github.com/users/sherm1/orgs","repos_url":"https://api.github.com/users/sherm1/repos","events_url":"https://api.github.com/users/sherm1/events{/privacy}","received_events_url":"https://api.github.com/users/sherm1/received_events","type":"User","site_admin":false},"milestone":null,"comments":48,"created_at":"2016-05-10T19:11:19Z","updated_at":"2016-05-19T18:30:08Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/RobotLocomotion/drake/pulls/2308","html_url":"https://github.com/RobotLocomotion/drake/pull/2308","diff_url":"https://github.com/RobotLocomotion/drake/pull/2308.diff","patch_url":"https://github.com/RobotLocomotion/drake/pull/2308.patch"},"body":"Also introduce the Context and Output structures that are used for System input and output, and the first concrete System2 system, an Adder.\n\n<!-- Reviewable:start -->\n---\nThis change is [<img src=\"https://reviewable.io/review_button.svg\" height=\"35\" align=\"absmiddle\" alt=\"Reviewable\"/>](https://reviewable.io/reviews/robotlocomotion/drake/2308)\n<!-- Reviewable:end -->\n"},"comment":{"url":"https://api.github.com/repos/RobotLocomotion/drake/issues/comments/220412390","html_url":"https://github.com/RobotLocomotion/drake/pull/2308#issuecomment-220412390","issue_url":"https://api.github.com/repos/RobotLocomotion/drake/issues/2308","id":220412390,"user":{"login":"david-german-tri","id":17437069,"avatar_url":"https://avatars.githubusercontent.com/u/17437069?v=3","gravatar_id":"","url":"https://api.github.com/users/david-german-tri","html_url":"https://github.com/david-german-tri","followers_url":"https://api.github.com/users/david-german-tri/followers","following_url":"https://api.github.com/users/david-german-tri/following{/other_user}","gists_url":"https://api.github.com/users/david-german-tri/gists{/gist_id}","starred_url":"https://api.github.com/users/david-german-tri/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/david-german-tri/subscriptions","organizations_url":"https://api.github.com/users/david-german-tri/orgs","repos_url":"https://api.github.com/users/david-german-tri/repos","events_url":"https://api.github.com/users/david-german-tri/events{/privacy}","received_events_url":"https://api.github.com/users/david-german-tri/received_events","type":"User","site_admin":false},"created_at":"2016-05-19T18:30:08Z","updated_at":"2016-05-19T18:30:08Z","body":"\n\n\n\n\n\nReview status: 17 of 20 files reviewed at latest revision, 6 unresolved discussions.\n\n---\n\n*[drake/systems/framework/basic_vector.h, line 19 \\[r9\\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2308#-KI-B12esCxMZNohW-OI:-KI8zLpYuM_3ZIj5Vhku:1258637166) ([raw file](https://github.com/robotlocomotion/drake/blob/26acf62455e37e2bb58fff7d128ddaf6cb8d5c11/drake/systems/framework/basic_vector.h#L19)):*\n<details><summary><i>Previously, amcastro-tri (Alejandro Castro) wrote…</i></summary>\n> I don't agree with that. The point of initializing with NaN's by default is that you are actually forgetting to initialize something and now you wanna find where. This might seem obvious but it really happens a LOT in simulation engines and sometimes takes months to just find the one variable that is not initialized (or actually, improperly initialized to zero here). \n> \n> I like what @sherm1 suggests. It actually works with AutoDiffScalar's!!! (I tested this) the reason being that AutoDiffScalar has a constructor from a double's. The same should be true for all other types since it makes sense to have a constant `Polynomial` (zero degree) which is simply initialized from a double. If that constructor doesn't exist, it should be added!\n</details>\nDone.  Note new test cases for int, Polynomial, and FunctionalForm.\n\n---\n\n*[drake/systems/framework/primitives/adder.cc, line 52 \\[r9\\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2308#-KI-C9-oC9ieklN91sWC:-KI8Tsy8UED-t4lx4Mi7:-1635878196) ([raw file](https://github.com/robotlocomotion/drake/blob/26acf62455e37e2bb58fff7d128ddaf6cb8d5c11/drake/systems/framework/primitives/adder.cc#L52)):*\n<details><summary><i>Previously, amcastro-tri (Alejandro Castro) wrote…</i></summary>\n> Again, it is not. That is how you write simulation engines that scale up to millions of unknowns running in thousands of processors (this will happen in a future closer than we think and we should be ready for it if we don't wan't to get crashed by the competition) . What I am trying to stimulate is the culture of writing very specialized fast code from the very internals. The devil is in the detail. I am afraid we will just stop \"prematurely optimizing\" everywhere (as it currently happens now withing Drake) and two years from now when our engine is real slow we'll have to back up everything we've done and find where the bottlenecks are (doing the work twice). \n> \n> > You're proposing that we design and build a whole new API feature to resolve a hypothetical performance problem.\n> \n> No. I am proposing something much simpler. \n> 1. Let's check connection, sizes, etc at initialization stage\n> 2. Let's do computation in methods designed to do just that.\n> \n> This only requires you to put those checks in a different method, called only once at initialization and not on every single non-linear iteration per time step (which will be variable by the way) within our super complex solution strategy. Unacceptable to have those checks there.\n> \n> See #2287 for an example of this.\n</details>\n#2287 uses data to identify some algorithm changes that will improve performance.  That's great.  Good work.\n\nThis discussion is not analogous.  We are debating a single instruction of performance cost.  There is no data demonstrating it is a performance bottleneck.  If it becomes a performance bottleneck in the future, we have numerous options to resolve it (the simplest of which is to use a debug-only assert instead).\n\nAs currently designed and implemented (in both System1 and System2), Systems are not aware that they are part of a larger graph.  There is no \"initialization stage\".  You want me to add one.  That is a significant new API feature.  I am not going to add it to improve inner loop performance by a few hypothetical picoseconds.\n\nI don't think further discussion on this thread will be productive.  If you continue to feel that this approach is unacceptable, please escalate to Russ.\n\n---\n\n*[drake/systems/framework/primitives/adder.h, line 36 \\[r9\\]](https://reviewable.io:443/reviews/robotlocomotion/drake/2308#-KHzTF_siXCA-Gqo7kqh:-KI8Xsp83jwHXCm31Ryp:-1420728823) ([raw file](https://github.com/robotlocomotion/drake/blob/26acf62455e37e2bb58fff7d128ddaf6cb8d5c11/drake/systems/framework/primitives/adder.h#L36)):*\n<details><summary><i>Previously, amcastro-tri (Alejandro Castro) wrote…</i></summary>\n> Shouldn't we all agree on a convention for Drake? at least for small methods like this. \n> I personally don't like `get_` when what I am getting has a particularly long name: `get_collision_model_dispatcher_callback`\n</details>\nYou're welcome to send a documentation PR to add such a style rule.  I will argue against merging it.  For the purposes of this PR, the name of this function is not a defect.\n\n---\n\n\n*Comments from [Reviewable](https://reviewable.io:443/reviews/robotlocomotion/drake/2308)*\n<!-- Sent from Reviewable.io -->\n"}}