{"action":"created","issue":{"url":"https://api.github.com/repos/HazyResearch/deepdive/issues/495","repository_url":"https://api.github.com/repos/HazyResearch/deepdive","labels_url":"https://api.github.com/repos/HazyResearch/deepdive/issues/495/labels{/name}","comments_url":"https://api.github.com/repos/HazyResearch/deepdive/issues/495/comments","events_url":"https://api.github.com/repos/HazyResearch/deepdive/issues/495/events","html_url":"https://github.com/HazyResearch/deepdive/issues/495","id":135184701,"number":495,"title":"Weight dumping is not sorted by id, but sampler expects so","user":{"login":"alldefector","id":5607717,"avatar_url":"https://avatars.githubusercontent.com/u/5607717?v=3","gravatar_id":"","url":"https://api.github.com/users/alldefector","html_url":"https://github.com/alldefector","followers_url":"https://api.github.com/users/alldefector/followers","following_url":"https://api.github.com/users/alldefector/following{/other_user}","gists_url":"https://api.github.com/users/alldefector/gists{/gist_id}","starred_url":"https://api.github.com/users/alldefector/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alldefector/subscriptions","organizations_url":"https://api.github.com/users/alldefector/orgs","repos_url":"https://api.github.com/users/alldefector/repos","events_url":"https://api.github.com/users/alldefector/events{/privacy}","received_events_url":"https://api.github.com/users/alldefector/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/HazyResearch/deepdive/labels/bug","name":"bug","color":"fc2929"}],"state":"open","locked":false,"assignee":{"login":"netj","id":53634,"avatar_url":"https://avatars.githubusercontent.com/u/53634?v=3","gravatar_id":"","url":"https://api.github.com/users/netj","html_url":"https://github.com/netj","followers_url":"https://api.github.com/users/netj/followers","following_url":"https://api.github.com/users/netj/following{/other_user}","gists_url":"https://api.github.com/users/netj/gists{/gist_id}","starred_url":"https://api.github.com/users/netj/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/netj/subscriptions","organizations_url":"https://api.github.com/users/netj/orgs","repos_url":"https://api.github.com/users/netj/repos","events_url":"https://api.github.com/users/netj/events{/privacy}","received_events_url":"https://api.github.com/users/netj/received_events","type":"User","site_admin":false},"milestone":null,"comments":7,"created_at":"2016-02-21T09:52:50Z","updated_at":"2016-02-22T04:27:09Z","closed_at":null,"body":"We ran the chunking example with DD 0.8 on Greenplum (with 20 segments) but always get this error:\r\n```\r\n2016-02-21 00:24:11.464530 ################################################\r\n2016-02-21 00:24:11.661727 LOADED VARIABLES: #270052\r\n2016-02-21 00:24:11.661813          N_QUERY: #49389\r\n2016-02-21 00:24:11.661828          N_EVID : #220663\r\n2016-02-21 00:24:11.722552 LOADED WEIGHTS: #268970\r\n2016-02-21 00:24:12.756042 LOADED FACTORS: #1049594\r\n2016-02-21 00:24:12.995216 sampler-dw.bin: src/dstruct/factor_graph/factor_graph.cpp:375: void dd::FactorGraph::safety_check(): Assertion `this->weights[i].id == i' failed.\r\n2016-02-21 00:24:13.171646 process/model/learning/run.sh: line 22: 184415 Aborted                 (core dumped) \r\n```\r\n\r\nThe corresponding code verifies that the weight vector is loaded in the order of id = 0, 1, 2, ...:\r\nhttps://github.com/HazyResearch/sampler/blob/master/src/dstruct/factor_graph/factor_graph.cpp#L395\r\n\r\nThe `dump_weights/run.sh` scripts run queries similar to\r\n```\r\nselect * from dd_weightsmulti_inf_istrue_tag limit 10;\r\n```\r\n\r\nWhile the above query returns results consistently in the same order for PG, the order can vary if we run it on GP again and again. So the weight vector ordering seems to have relied on an implementation detail of Postgres, and now it's broken in Greenplum (we are running latest GP release as of today).\r\n\r\nInterestingly, we could run the spouse example on GP. With spouse, the first column is `isfixed` -- which seems to be always `f`. With chunking, the first column of `dd_weightsmulti_inf_istrue_tag` is `dd_weight_column_0`, which could take on different values. And GP by default distributes on the first column. So that seems to explain the ordering issue:\r\n```\r\n# select * from dd_weightsmulti_inf_istrue_tag limit 3;\r\n dd_weight_column_0 | isfixed | initvalue | id  | categories \r\n--------------------+---------+-----------+-----+------------\r\n word=Results       | f       |         0 | 296 | 0\r\n word=obliged       | f       |         0 | 307 | 0\r\n word=Eurocom       | f       |         0 | 318 | 0\r\n(3 rows)\r\n\r\n# select * from dd_weightsmulti_inf_istrue_tag limit 3;\r\n dd_weight_column_0 | isfixed | initvalue | id  | categories \r\n--------------------+---------+-----------+-----+------------\r\n word=Leahy         | f       |         0 | 170 | 0\r\n word=banana        | f       |         0 | 176 | 0\r\n word=9.875         | f       |         0 | 182 | 0\r\n(3 rows)\r\n\r\n# select * from dd_weightsmulti_inf_istrue_tag limit 3;\r\n dd_weight_column_0 | isfixed | initvalue | id  | categories \r\n--------------------+---------+-----------+-----+------------\r\n word=Results       | f       |         0 | 296 | 0\r\n word=obliged       | f       |         0 | 307 | 0\r\n word=Eurocom       | f       |         0 | 318 | 0\r\n(3 rows)\r\n```\r\n\r\nBetween adding `ORDER BY` to the dump_weights code and revising the sampler, which would be a better solution?"},"comment":{"url":"https://api.github.com/repos/HazyResearch/deepdive/issues/comments/187001133","html_url":"https://github.com/HazyResearch/deepdive/issues/495#issuecomment-187001133","issue_url":"https://api.github.com/repos/HazyResearch/deepdive/issues/495","id":187001133,"user":{"login":"alldefector","id":5607717,"avatar_url":"https://avatars.githubusercontent.com/u/5607717?v=3","gravatar_id":"","url":"https://api.github.com/users/alldefector","html_url":"https://github.com/alldefector","followers_url":"https://api.github.com/users/alldefector/followers","following_url":"https://api.github.com/users/alldefector/following{/other_user}","gists_url":"https://api.github.com/users/alldefector/gists{/gist_id}","starred_url":"https://api.github.com/users/alldefector/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alldefector/subscriptions","organizations_url":"https://api.github.com/users/alldefector/orgs","repos_url":"https://api.github.com/users/alldefector/repos","events_url":"https://api.github.com/users/alldefector/events{/privacy}","received_events_url":"https://api.github.com/users/alldefector/received_events","type":"User","site_admin":false},"created_at":"2016-02-22T04:27:09Z","updated_at":"2016-02-22T04:27:09Z","body":"Looks like this is the bug: the `db-assign_sequential_id` script for GP didn't keep up with the `inc` parameter (step size between consecutive IDs) that was presumably introduced for categorical variables:\r\n\r\nhttps://github.com/HazyResearch/deepdive/blob/6786a806ec04b087db6b29fbdd1f5c469a6e6601/compiler/compile-config/compile-config-2.01-grounding#L385-L396\r\nhttps://github.com/HazyResearch/deepdive/blob/13e8788b9bf39e2d3aa83d0883a6391c9c9d6592/database/db-driver/postgresql/db-assign_sequential_id\r\nhttps://github.com/HazyResearch/deepdive/blob/13e8788b9bf39e2d3aa83d0883a6391c9c9d6592/database/db-driver/greenplum/db-assign_sequential_id\r\n"}}