2024/05/21

Newest at the top

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 +0200sayola1(~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 +0200skidoesn'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 +0200skiisn'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 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 08:21:35 +0200 <vladl> Its like... taking an anamorphism and a comonad and trying to thread them through one another somehow.
2024-05-21 08:20:24 +0200 <vladl> Actually, scratch that - we don't have a (w p -> p), we have a (w p -> f p), where f is the coalgebra functor (what contains the subpixels). So the comonad situation is even messier.
2024-05-21 08:18:56 +0200sord937(~sord937@gateway/tor-sasl/sord937)
2024-05-21 08:15:35 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 264 seconds)
2024-05-21 08:14:11 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 08:13:53 +0200internatetional(~nate@182.2.51.214) (Max SendQ exceeded)
2024-05-21 08:13:25 +0200internatetional(~nate@182.2.51.214)
2024-05-21 08:10:56 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net)
2024-05-21 08:01:56 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 08:00:39 +0200 <vladl> Also because my particular use case ultimately does need to synchonize layer-by-layer for other reasons (memory allocation strategy) so I may as well
2024-05-21 07:59:11 +0200 <vladl> That's true but I'm relaxing my focus to the layer scale in hopes of making it easier for me to reason about
2024-05-21 07:58:13 +0200 <probie> I don't see what requires you to synchronize layer-by-layer. A subpixel merely requires its neighbours at the previous resolution to have been computed, not the entire previous layer
2024-05-21 07:57:40 +0200 <vladl> Yes I think I see a comonad in there too, but its also split. Like, lets suppose a 1D array of pixels p with neighborhoods w, so something like [w p]. We have a (w p -> p), but in order to extend and get a (w p) out, we have to step all the way out of the [] in order to propagate neighbor values. So we can go [p] -> [w p], but that [] prevents me from making it a proper comonad.
2024-05-21 07:57:35 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds)
2024-05-21 07:54:55 +0200johnw(~johnw@69.62.242.138)
2024-05-21 07:53:39 +0200 <vladl> At a given resolution j, before interpolating the subpixels at resolution j+1, the neighboring (sub)pixels at resolution j have to have been computed. So we need to sync layer-by-layer. Synchronization like a fence or a barrier.
2024-05-21 07:53:11 +0200geekosauris thinking this sounds more like a comonad
2024-05-21 07:50:40 +0200 <probie> I don't quite understand what you mean by "synchronization" here
2024-05-21 07:45:55 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 268 seconds)
2024-05-21 07:41:35 +0200 <vladl> can't really find much on it, which could definitely be a skill issue. I read "Fantastic Morphisms and where to find them" but none of these really fit the bill. There's a problem on tree nexuses in Richard Bird's Pearls of Functional Algorithm design that I went through that, again, seemed very close to what I wanted but I couldn't make the pieces fit.
2024-05-21 07:41:29 +0200 <vladl> What patterns are present in a recursion scheme that requires synchronization? For example, recursively interpolating subpixels in an image, where the interpolation step requires the parent pixel neighborhood? The subpixels get folded back into the original resolution, so this is almost a hylomorphism, except the coalgebra gets "split" over the synchronization step. This seems like a common pattern but I
2024-05-21 07:40:59 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net)
2024-05-21 07:38:50 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-21 07:37:18 +0200johnw_(~johnw@69.62.242.138) (Quit: ZNC - http://znc.in)
2024-05-21 07:30:42 +0200vladl(~vladl@24.35.90.183)
2024-05-21 07:30:07 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2024-05-21 07:27:43 +0200y04nn(~username@2a03:1b20:8:f011::e10d)
2024-05-21 07:20:52 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds)
2024-05-21 07:18:08 +0200zetef(~quassel@5.2.182.99)
2024-05-21 07:17:01 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2024-05-21 06:46:50 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-21 06:37:54 +0200michalz(~michalz@185.246.207.221)
2024-05-21 06:35:05 +0200michalz(~michalz@185.246.207.203) (Client Quit)
2024-05-21 06:34:50 +0200michalz(~michalz@185.246.207.203)