store comonad as Delay array

[cartazio]

this idea intrigues me :)

[dorchard]

They are good for doing stencils (e.g., solving partial differentials) - and you can have a store comonad (for a delayed array) and an a comonad over an actual array with a comonad morphism to map between the two.

[cartazio]

@dorchard it also seems like the only sane machinery for supporting any form of array fusion that can be easily split to run in parallel (afaik). Or am I missing something in that idea

This won't be in the alpha version, but noting it for myself for the next release in another month or two thereafter

[cartazio]

@dorchard btw, you should lurk on #numerical-haskell on freenode :)

[cartazio]

@dorchard any good reading on the pde use case?

[cartazio]

I thought about this more, and the PDE example only seems to make sense if the mesh/grid is rectangular (or a multidimensional version thereof). Is there a decent way of reformulating it that doesn't turn into a dynamic "graph neighbor" calculation? (Not that theres any problem with that :) )

[dorchard]

Re parallel/fusion: yes I think the work on Repa provides some nice performance here.
Re the PDE example: I'm thinking mostly the kind of 'laplace' like operations: (I discuss this in http://www.cl.cam.ac.uk/~dao29/drafts/codo-notation-orchard-ifl12.pdf). <- This was in the rectangular case. I suppose something like a triangular mesh (if regular) is not that hard to do (if you have an indexing scheme). Anything 'unstructured' needs more of a dynamic approach (as you say) although providing a 'neighbour' function for the comonad makes sense here and can be iterated to get neighbours of neighbours etc. I discussed this a bit in my thesis (described in terms of coalgebras): (p.160, Section 7.4.1, http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-854.pdf)