Newest at the top
| 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 |
| 2024-05-21 08:53:21 +0200 | <ski> | still not following what you mean by the synchronization |
| 2024-05-21 08:53:07 +0200 | acidjnk_new | (~acidjnk@p200300d6e714dc192d105e993ca958d7.dip0.t-ipconnect.de) |
| 2024-05-21 08:50:16 +0200 | <vladl> | yes, exactly |
| 2024-05-21 08:50:06 +0200 | <ski> | so this would be `w p -> f p' |
| 2024-05-21 08:49:38 +0200 | <vladl> | yes, that's more accurate |
| 2024-05-21 08:49:25 +0200 | <ski> | (or `[y0,y1] = g [x1,x2,x3]') |
| 2024-05-21 08:49:03 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-05-21 08:48:51 +0200 | <ski> | hm, i see |
| 2024-05-21 08:46:51 +0200 | sayola | (~sayola@ip-109-42-241-195.web.vodafone.de) |
| 2024-05-21 08:46:40 +0200 | <vladl> | yes |
| 2024-05-21 08:46:36 +0200 | <vladl> | so a 1D example, say you have [x0, x1, x2, x3, x4...] and you want to expand x2 into [y0, y1], then y0 = f 0 [x1, x2, x3] and y1 = f 1 [x1, x2, x3] for some interpolation function f |
| 2024-05-21 08:45:49 +0200 | <ski> | mhm, so first stage is basically from root toward leaves (but including from siblings to children). and then later from leaves to root again ? |
| 2024-05-21 08:44:50 +0200 | <vladl> | Both ways, but not at the same time. We unfold all the way, then do some transformations, and then fold it back up to the original resolution. |
| 2024-05-21 08:44:29 +0200 | <ski> | well, to sibling children as well, yea |
| 2024-05-21 08:44:08 +0200 | sayola1 | (~sayola@ip-109-42-241-195.web.vodafone.de) (Read error: Connection reset by peer) |
| 2024-05-21 08:44:07 +0200 | <ski> | hmm |
| 2024-05-21 08:44:00 +0200 | <ski> | so how does information flow ? only from root towards leaves ? |
| 2024-05-21 08:43:41 +0200 | <ski> | mhm |
| 2024-05-21 08:43:28 +0200 | sayola | (~sayola@ip-109-42-242-108.web.vodafone.de) (Ping timeout: 260 seconds) |
| 2024-05-21 08:42:34 +0200 | <vladl> | Only from parent sibling cells. So a cell at resolution j only depends on cell values at resolutoin j-1 |
| 2024-05-21 08:42:21 +0200 | sayola1 | (~sayola@ip-109-42-241-195.web.vodafone.de) |
| 2024-05-21 08:42:05 +0200 | <ski> | hm, interpolated from parent cell, and parentsibling cells ? or also from cousin cells ? |
| 2024-05-21 08:41:58 +0200 | <vladl> | Er, cells, sorry, I should stop mixing terminology |
| 2024-05-21 08:40:59 +0200 | <vladl> | No, no child cells are shared. So imagine each pixel gets broken up into 4 child pixels, but the values of the child pixels gets interpolated from the parent pixels and its adjacent neighbors (for a first-order interpolation scheme) |
| 2024-05-21 08:40:09 +0200 | <ski> | does two adjacent parent cells share child cells ? |
| 2024-05-21 08:40:06 +0200 | <vladl> | It just means the movement of materials. So basically it is the fluid traversing space. |
| 2024-05-21 08:39:32 +0200 | ski | doesn't know the term "advect" |
| 2024-05-21 08:38:50 +0200 | <ski> | (windows of a particular fixed size, in terms of the elements of the layer below, say) |
| 2024-05-21 08:38:49 +0200 | <vladl> | Well it is a tree in the sense that every parent cell is exactly decomposed into its child cells, like they overlap. But in terms of data dependencies, it is a DAG. |