{"action":"created","issue":{"url":"https://api.github.com/repos/lspector/Clojush/issues/149","labels_url":"https://api.github.com/repos/lspector/Clojush/issues/149/labels{/name}","comments_url":"https://api.github.com/repos/lspector/Clojush/issues/149/comments","events_url":"https://api.github.com/repos/lspector/Clojush/issues/149/events","html_url":"https://github.com/lspector/Clojush/issues/149","id":94960554,"number":149,"title":"on `atom-generators` and biases","user":{"login":"Vaguery","id":81171,"avatar_url":"https://avatars.githubusercontent.com/u/81171?v=3","gravatar_id":"","url":"https://api.github.com/users/Vaguery","html_url":"https://github.com/Vaguery","followers_url":"https://api.github.com/users/Vaguery/followers","following_url":"https://api.github.com/users/Vaguery/following{/other_user}","gists_url":"https://api.github.com/users/Vaguery/gists{/gist_id}","starred_url":"https://api.github.com/users/Vaguery/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Vaguery/subscriptions","organizations_url":"https://api.github.com/users/Vaguery/orgs","repos_url":"https://api.github.com/users/Vaguery/repos","events_url":"https://api.github.com/users/Vaguery/events{/privacy}","received_events_url":"https://api.github.com/users/Vaguery/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-07-14T14:45:30Z","updated_at":"2015-07-14T14:46:21Z","closed_at":null,"body":"One point of \"manglish resistance\" I've just identified in the \"hard\" problem I've been setting up is the unexpected way `atom-generators` is defined in many problems I've examined.\r\n\r\nIntuitively—that is, from the stance of a new user examining the examples to emulate their \"best practices\"—setting up the `atom-generators` list should in some sense preserve the visible probabilities they imply. So for example in many cases I've looked at, the resulting probability that an input or ERC is created is no higher than the probability that any given instruction is used.\r\n\r\nI understand that evolutionary search can \"fix\" any shortfall, and that one doesn't want to \"bias\" the search towards obvious needs, but I can't imagine it's a good thing for random mutation (for example) to tend towards the elimination of ERCs _in all cases_, which is the case in several problem setups I've looked at.\r\n\r\nHere's an example from [the digits problem](https://github.com/lspector/Clojush/blob/25ffe4efa42ed2d70f611446a7d165f06275a9d1/src/clojush/problems/software/digits.clj)\r\n\r\n``` clojure\r\n(def digits-atom-generators\r\n  (concat (list\r\n            \\newline\r\n            ;;; end constants\r\n            (fn [] (- (lrand-int 21) 10))\r\n            ;;; end ERCs\r\n            (tag-instruction-erc [:integer :boolean :string :char :exec] 1000)\r\n            (tagged-instruction-erc 1000)\r\n            ;;; end tag ERCs\r\n            'in1\r\n            ;;; end input instructions\r\n            )\r\n          (registered-for-stacks [:integer :boolean :string :char :exec :print])))\r\n```\r\nIn other words: if there's only one copy of each input or ERC function (as is true here), and _hundreds_ of instructions (about 127 in this case), then all the actual ERCs and inputs will tend to be eliminated by mutation, and scant to begin with.\r\n\r\n### alternative:\r\n\r\nI'd suggest an approach that takes a list of collections, and calls each one of the _root_ items with equal probability, and then samples from that. So a list like the one above would produce 1/6 newlines, 1/6 inputs, 1/6 instructions, and so forth."},"comment":{"url":"https://api.github.com/repos/lspector/Clojush/issues/comments/121259985","html_url":"https://github.com/lspector/Clojush/issues/149#issuecomment-121259985","issue_url":"https://api.github.com/repos/lspector/Clojush/issues/149","id":121259985,"user":{"login":"Vaguery","id":81171,"avatar_url":"https://avatars.githubusercontent.com/u/81171?v=3","gravatar_id":"","url":"https://api.github.com/users/Vaguery","html_url":"https://github.com/Vaguery","followers_url":"https://api.github.com/users/Vaguery/followers","following_url":"https://api.github.com/users/Vaguery/following{/other_user}","gists_url":"https://api.github.com/users/Vaguery/gists{/gist_id}","starred_url":"https://api.github.com/users/Vaguery/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Vaguery/subscriptions","organizations_url":"https://api.github.com/users/Vaguery/orgs","repos_url":"https://api.github.com/users/Vaguery/repos","events_url":"https://api.github.com/users/Vaguery/events{/privacy}","received_events_url":"https://api.github.com/users/Vaguery/received_events","type":"User","site_admin":false},"created_at":"2015-07-14T14:46:21Z","updated_at":"2015-07-14T14:46:21Z","body":"By the way, I've just checked this, and the qualitative behavior of the problem I'm working through is completely different when I increase the proportional representation of inputs and ERCs."}}