Newest at the top
| 2024-05-21 09:52:49 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-21 09:51:58 +0200 | <ski> | (and then i want to be able to say things like `[] -> Maybe', which would be a right kan extension. `([] -> Maybe) a' amounting to `forall b. (a -> [b]) -> Maybe b'. and `(exists n. t n) a', i think (?), amounting to `exists n. t n a' (and similarly for `forall')) |
| 2024-05-21 09:51:37 +0200 | <vladl> | i'm guessing you might be able to derive equivalent-but-different traversals if you had some syntax like that? |
| 2024-05-21 09:49:30 +0200 | <vladl> | s/expression/equation |
| 2024-05-21 09:48:51 +0200 | <vladl> | i think i'm following. i read `sum(| a ; b |)` as sum of b's ranging over a, so this expression shows how different views of the structure relate to one another, which tells you about the structure as a whole |
| 2024-05-21 09:43:06 +0200 | <ski> | s/i was to/i want to/ |
| 2024-05-21 09:42:49 +0200 | <ski> | e.g. with `concat :: [[a]] -> [a]' and `sum :: [Integer] -> Integer' we have a law `sum . map sum = sum . concat'. i was to express this as `sum (| l0 ; sum (| l1 ; n |) |) = sum (| concat (| l0,l1 |) ; n |)'. here `l0' is the name of the outer list structure, and `l1' is the name of each inner list structure (it's plural), and `n' is the name of each element (it's doubly plural) |
| 2024-05-21 09:42:45 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-21 09:41:39 +0200 | ubert | (~Thunderbi@p200300ecdf1a44e6bddfe2bf28cca96e.dip0.t-ipconnect.de) (Quit: ubert) |
| 2024-05-21 09:39:54 +0200 | <ski> | well .. it's an idea i've been pondeing, on and off. basically, given a structure/collection with elements, i want to name the structure (the layer(s)) itself, separately from the elements |
| 2024-05-21 09:38:39 +0200 | <vladl> | you mean like how ListF a b is a functor over its recursive structure, that kind of thing? |
| 2024-05-21 09:36:59 +0200 | <ski> | (hm, this all is making me think of "structure syntax" now .. although that's tangential to what you're pondering) |
| 2024-05-21 09:36:00 +0200 | <vladl> | yeah, and I was considering the dynamorphism as a model but its that lateral dependency that trips me up. |
| 2024-05-21 09:34:53 +0200 | kuribas | (~user@ptr-17d51encis8jg2ccf48.18120a2.ip6.access.telenet.be) |
| 2024-05-21 09:34:13 +0200 | <ski> | yup, just like dynamic programming with fixed memory/history |
| 2024-05-21 09:33:21 +0200 | <vladl> | instead of O(log n) and storing the entire tree |
| 2024-05-21 09:33:10 +0200 | <vladl> | that's another reason I go layer-by-layer, I can access neighbors in O(1) and I only have to store 2 layers at a time |
| 2024-05-21 09:32:31 +0200 | ubert | (~Thunderbi@p200300ecdf1a44e6bddfe2bf28cca96e.dip0.t-ipconnect.de) |
| 2024-05-21 09:31:50 +0200 | chele | (~chele@user/chele) |
| 2024-05-21 09:30:52 +0200 | <vladl> | so in my case, in a sense i have to pair the topology with the entire parent layer (since the offsets are with respect to the layer) in order to compute the child cells |
| 2024-05-21 09:29:22 +0200 | <ski> | mhm |
| 2024-05-21 09:28:09 +0200 | <vladl> | i don't think so, because the new cell only knows where its neighbors are, not what their values are |
| 2024-05-21 09:27:14 +0200 | <ski> | hm, so instead of `t p >-> t (w p) >-> t (f p)', could one do `t (w p) >-> t (w (f p)) >-> t (f (w p))' ? |
| 2024-05-21 09:26:49 +0200 | <vladl> | So when a cell gets expanded, it actually computes this right away, so it knows from the moment of birth where its neighbors are, so to speak |
| 2024-05-21 09:26:24 +0200 | <vladl> | So the way I do it in my specific case, is that, during the unfolding, each cell carries with it an object called a "topology" that you can basically think of as a list of pointers to the neighbors |
| 2024-05-21 09:25:41 +0200 | <ski> | .. i'm wondering if you could carry siblings with you, as you go down, so that you don't have to traverse arbitarily high up again to retrieve them |
| 2024-05-21 09:24:52 +0200 | <vladl> | Yeah, something like that |
| 2024-05-21 09:20:58 +0200 | <ski> | the interesting part, of course, is how to do the `t p -> t (w p)' part |
| 2024-05-21 09:20:22 +0200 | <ski> | (where `TreeB f p' amounts to `exists n :: Nat. TreeD f n p') |
| 2024-05-21 09:19:35 +0200 | <ski> | i guess, something like `data TreeD f :: Nat -> * -> * where Leaf :: TreeD f Zero p; Branch :: f (TreeD f n p) -> TreeD f (Succ n) p' or `data TreeB f p = Conquer p | Divide (TreeB f (f p))' |
| 2024-05-21 09:16:09 +0200 | <vladl> | yes. t needs to be able to absorb f (and remember it so it can form it later) so it seems like a tree with layer-wise views |
| 2024-05-21 09:13:58 +0200 | <ski> | given `t p', you can get to `t (w p)', and then to `t (f p)'. then that becomes `t p' with one level deeper |
| 2024-05-21 09:09:32 +0200 | <vladl> | yes. the flattening complicates things significantly, and yes that is what i mean by synchronization |
| 2024-05-21 09:09:09 +0200 | <ski> | "consider dependencies at the scale of an entire layer at a time" -- i suppose you mean generating a layer completely, before increasing the resolution. is this what you meant by "synchronization" ? |
| 2024-05-21 09:08:02 +0200 | <ski> | the flattening, to generate `w', is complicating stuff |
| 2024-05-21 09:06:30 +0200 | <ski> | oh right. i was misthinking here |
| 2024-05-21 09:06:18 +0200 | <ski> | hmm |
| 2024-05-21 09:06:08 +0200 | <vladl> | yes, but note the common ancestor could be pretty far up, if the cell's position is near a power-of-two. |
| 2024-05-21 09:06:07 +0200 | <ski> | at least, for your example above, `n' would seem to be `2' |
| 2024-05-21 09:05:35 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-05-21 09:05:29 +0200 | <ski> | (only thinking of fairly "regular" `w' and `f' here (e.g. probably linear), rather than say more arbitrary ones) |
| 2024-05-21 09:04:48 +0200 | <ski> | hmm .. so i guess you only need siblings,cousins,&c. ("same generation") up to a common ancestor `n' levels up, where `n' would depend on the width of `w' and the branching factor of `f' |
| 2024-05-21 09:03:54 +0200 | <vladl> | And then i just try to simplify it for myself and consider dependencies at the scale of an entire layer at a time, instead of worrying about the implicit DAG in the window-wise dependencies |
| 2024-05-21 08:59:58 +0200 | <ski> | mm, right |
| 2024-05-21 08:59:36 +0200 | <vladl> | we don't expand x0, because it doesn't have a complete interpolation domain |
| 2024-05-21 08:59:05 +0200 | <ski> | (hm, or maybe you don't have cropped windows/neighbourhoods at the edges. that would make it `x1' and `x2' though, i think) |
| 2024-05-21 08:58:24 +0200 | <ski> | "but x2 only computes y0 and y1, so we need x3" -- hm, shouldn't `x2' and `x3' be `x0' and `x1' ? |
| 2024-05-21 08:57:09 +0200 | <vladl> | which means x2 and x3 have to both finish their expansions before either y1 or y2 can be expanded |
| 2024-05-21 08:56:25 +0200 | <vladl> | so z's have to wait until all of the y's in their interpolation domain are done |
| 2024-05-21 08:55:09 +0200 | <vladl> | so, suppose we have [[y0, y1], [y2, y3], ...] from the expansion and we flattened it down to [y0, y1, y2, y3,...]. So we want to expand y1 into [z0,z1] but we need [y0, y1, y2] to do this. but x2 only computes y0 and y1, so we need x3 to have been expanded into y2 and y3 before we can compute z0,z1 |