| 17 May 2019 |
 ghollisjr | table-get-field doesn't know about the logical fields | 22:21:12 |
 katco | woohoo! | 22:21:12 |
| katco | ok, how can i best loop over the union of fields and logical fields? | 22:21:41 |
| ghollisjr | The way to access logical fields is through (field :income-category) | 22:21:44 |
| ghollisjr | Ah this is something more difficult, but still possible | 22:22:10 |
| ghollisjr | The logical-fields are stored in a hash-table | 22:22:21 |
| ghollisjr | So long as you're using a define-res-macro definition, you could get these field symbols at compile time and then insert them into the code body | 22:22:56 |
| ghollisjr | The way I've been working with fields due to needing information at compile time is to supply them to macros which define groups of targets that are related to each other | 22:24:01 |
| ghollisjr | E.g., I might have some operator def-special-table and use it like (def-special-table (res src) (some list of fields) ... | 22:24:53 |
| katco | i think for splitting functions i will always know the set of fields up front. i guess at that point it becomes a usability thing. it sounds like the code can discover the complete union of fields and so it should to make it more comfortable to use for the user | 22:25:22 |
| ghollisjr | Ah yes I agree | 22:25:39 |
| ghollisjr | The variable storing the logical fields is cl-ana.makeres-table::*proj->tab->lfields* | 22:26:25 |
| ghollisjr | So you could get them like (gethash 'src (gethash (project) cl-ana.makeres-table::*proj->tab->lfields*)) if you want the lfields for src | 22:27:33 |
| ghollisjr | I believe they are encoded as an alist mapping from field symbol to the expression | 22:28:13 |
| katco | tangential question: i noticed in most of your examples, DOP target names are tuples, e.g. (signal x-sigma). is there something special about that, or will 1 symbol, e.g. signal-x-sigma work just as well? | 22:29:02 |
| ghollisjr | Ah this is just my style choice. It does make it easy to automatically generate target names though | 22:29:50 |
| ghollisjr | E.g., if the table is (src), then I can apply some filter and call the result (src filter) | 22:30:08 |
| ghollisjr | Then any reductions associated with those tables could be ((src) mean x), ((src filter) mean x), etc. | 22:30:53 |
| katco | i can see where you're coming from. it was slightly confusing to me, because even though i was pretty sure they were just names, i wasn't positive, and it looked like there might be some macro expansion or function calls going on | 22:32:04 |
| katco | especially this snippet:
(defres (branching src y-cut)
(branch (res (branching y-cut-nsigmas))
(ltab (res src)
()
(when (funcall (res (branching y-cut))
(field x)
(field y))
(push-fields)))))
| 22:32:30 |
| katco | i stared at that funcall for a good long while XD | 22:32:38 |
| ghollisjr | 😂 I don't think you are alone in that haha | 22:35:49 |
| ghollisjr | I think that the branch operator is also one of the most confusing operators | 22:36:40 |
| ghollisjr | But since it was possible to provide a single symbol, branch, that would be able to perform multiple functions, I couldn't resist just using that one symbol | 22:37:20 |
| katco | if i understand it correctly (and i can remember my linear algebra after years of dissuse), it's kind of like dot multiplication? i.e. it will perform operations for all branches in the graph? | 22:37:48 |
| ghollisjr | Yes it is very similar to that; I can't remember the official term for it but the term that comes to mind is "dumb parallelism" | 22:38:58 |
| ghollisjr | I.e. it's purely parallel | 22:39:09 |
| katco | oh! do you mean "embarassingly parallel"? | 22:39:24 |
| ghollisjr | Yes that's it! | 22:39:30 |
| ghollisjr | :joy: | 22:39:40 |
