{"action":"closed","issue":{"url":"https://api.github.com/repos/lenskit/lenskit/issues/472","repository_url":"https://api.github.com/repos/lenskit/lenskit","labels_url":"https://api.github.com/repos/lenskit/lenskit/issues/472/labels{/name}","comments_url":"https://api.github.com/repos/lenskit/lenskit/issues/472/comments","events_url":"https://api.github.com/repos/lenskit/lenskit/issues/472/events","html_url":"https://github.com/lenskit/lenskit/issues/472","id":23988912,"number":472,"title":"Refactor sparse vectors into data tables","user":{"login":"mdekstrand","id":186612,"avatar_url":"https://avatars.githubusercontent.com/u/186612?v=3","gravatar_id":"","url":"https://api.github.com/users/mdekstrand","html_url":"https://github.com/mdekstrand","followers_url":"https://api.github.com/users/mdekstrand/followers","following_url":"https://api.github.com/users/mdekstrand/following{/other_user}","gists_url":"https://api.github.com/users/mdekstrand/gists{/gist_id}","starred_url":"https://api.github.com/users/mdekstrand/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mdekstrand/subscriptions","organizations_url":"https://api.github.com/users/mdekstrand/orgs","repos_url":"https://api.github.com/users/mdekstrand/repos","events_url":"https://api.github.com/users/mdekstrand/events{/privacy}","received_events_url":"https://api.github.com/users/mdekstrand/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/lenskit/lenskit/labels/Data%20Structures","name":"Data Structures","color":"5319e7"},{"url":"https://api.github.com/repos/lenskit/lenskit/labels/proposal","name":"proposal","color":"444444"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2013-12-09T20:02:08Z","updated_at":"2016-03-29T20:54:30Z","closed_at":"2016-03-29T20:54:30Z","body":"The more I think, the more I think that @kluver was probably right. It is likely easier to think of sparse vectors as being data tables: long-keyed tables with columns. The individual columns support vector operations, such as dot products and norms.\r\n\r\nI think that would help make it easier to explain how these tables are different from normal linear algebra vectors.\r\n\r\nThis is distinct from the matrix type.\r\n\r\nThe basic idea is to have a `KeyedDataTable` that has `long` keys and some columns.  Keys are likely fixed, as they are now, but columns can be added.  You can then get a `KeyedNumericColumn`, that has the current `SparseVector` operations, or a `KeyedDataColumn` that has arbitrarily-typed data.\r\n\r\nWe may want a corresponding `IndexedDataTable` to replace the `Table` stuff in the evaluator, or replace that code with Guava tables."}}