Newest at the top
| 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. |
| 2024-05-21 08:37:39 +0200 | <ski> | hm, or maybe considering a rectangle of pixels, and then a rectangle of all windows around each pixel, and then a rectangle of all windows around those, &c. (so this is a DAG, not a tree) ? |
| 2024-05-21 08:37:09 +0200 | <vladl> | You guessed right. If it matters, the pixels are actually fluid density distributions and the interpolation is meant to refine the grid cells until they're fine enough for the fluid to advect across in one time step. |
| 2024-05-21 08:36:01 +0200 | <ski> | you're building a quadtree of the pixels, or something ? |
| 2024-05-21 08:34:48 +0200 | ski | isn't too clear on the concrete example with subpixel interpolation |
| 2024-05-21 08:22:50 +0200 | <vladl> | Or, hopefully, I am just overcomplicating things and there is some more elegant formalism for this out there |
| 2024-05-21 08:21:38 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |