tag:blogger.com,1999:blog-11295132.post6955711671212108366..comments2017-05-19T20:38:17.775-07:00Comments on A Neighborhood of Infinity: The Monads Hidden Behind Every ZipperDan Piponihttps://plus.google.com/107913314994758123748noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-11295132.post-5770582848351653232017-04-17T10:28:05.207-07:002017-04-17T10:28:05.207-07:00Really cool! One question though, could left' ...Really cool! One question though, could left' and right' be replaced by something like,<br /><br />left' (Zipper a b) = left $ Zipper (a ++ repeat 0) (b ++ repeat 0)<br /><br />And would this implementation have any disadvantages over the original?ad29111http://www.blogger.com/profile/00909603781026796442noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-50910523156497707172008-03-21T04:06:00.000-07:002008-03-21T04:06:00.000-07:00Enlighting! This gives me an idea what comonads ar...Enlighting! This gives me an idea what comonads are. However, I associated Zipper with things like List.zip and Control.Applicative.ZipList. But instead it represents a list which is infinite to the left and to the right ("doubly infinite" as you call it).Lemminghttp://www.parallelnetz.de/MonadTransformer?source=http%3A%2F%2Fwww%2Ehaskell%2Eorg%2Fhaskellwiki%2FCategory%3AMonadnoreply@blogger.comtag:blogger.com,1999:blog-11295132.post-23444023097924327472008-02-12T11:25:00.000-08:002008-02-12T11:25:00.000-08:00Luke,The paper's finished but not submitted. For r...Luke,<BR/><BR/>The paper's finished but not submitted. For reasons mentioned above, it's based on C code rather than functional code. My submission for publication is a bit held up because it connects a tiny bit with a patent application my employer wants me to do. That also means there are probably awkward legal implications of showing it to anyone.<BR/><BR/>OTOH I think I can argue that the patent doesn't really hinge on what's in this paper. I'll raise that with my manager and if you give me contact info I can send it to you if you're still interested.sigfpehttp://www.blogger.com/profile/08096190433222340957noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-28785903943847216272008-02-12T10:37:00.000-08:002008-02-12T10:37:00.000-08:00This is a great post.Did you ever finish that pape...This is a great post.<BR/><BR/>Did you ever finish that paper? If not, can I see a draft?Lukehttp://www.blogger.com/profile/09807388788677769669noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-3536069505946333542007-09-14T03:53:00.000-07:002007-09-14T03:53:00.000-07:00Thanks for the nice post!Thanks for the nice post!Michaelhttp://free-ps3-for-me.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-11295132.post-44356441288353905052007-01-29T20:57:00.000-08:002007-01-29T20:57:00.000-08:00Here's a hunch into the connection.
if C is the c...Here's a hunch into the connection.<br /><br />if C is the category of interest for Haskell programs (eg, C is such that we can say the IO monad is a functor: C->C) I have two guesses about what's really going on.<br /><br />Guess (A):<br /><br />for some nontrivial CD, DC, CD', D'C : C->D, D->C, C->D', and D'->C respectively we actually have, say,<br /><br />IO : C -> (D -> C -> D') -> C<br />OI : C -> (D' -> C -> D) -> C<br /><br />formed by use of the relevant compositions. I'm not sure what this would give us, but am throwing it out for completeness.<br /><br />Guess (B):<br /><br />At least for some comonads ( OI, maybe others ) we are actually in different categories (ie, OI:D->D but IO:C->C), but one of the mappings F:D->C or G:C->D is so trivial we don't know we're using it; alternatively, both F:D->C and G:C->D are nontrivial but at program launch we're "transparently" applying some (apparently trivial) I:C->D (or I:D->C) and we haven't figured out that we're doing it (or what the equivalent I':D->C (or I':C->D) would be).<br /><br />Guess (B) feels correct to me, but a good proof would be needed to convince me.<br /><br />What most comes to mind is the suspicion that all of Haskell outside of the monads compiles into a comonad:<br />if we make the relabelings: <br /><br />extend -> defer<br />extract -> request<br /><br />then<br /><br />defer request == id<br />request . (defer f) == f<br />(defer f) . (defer g) == defer (f . defer g)<br /><br />is almost precisely how programs are lazily evaluated. (And: perhaps that's why naive OI has problems: there's not a natural way to do truly lazy IO in a safe fashion...)<br /><br />I'm running out of steam here, but: we already know that most useful haskell programs are a sequence of evaluations of purely-functional code, with the sequence ordering (and thus the values fed in to be evaluated) coerced by encapsulating it in a monad. <br /><br />As currently evaluated the code called between binds and returns is already in a transparent comonad (it's transparent to the programmer, b/c the compiler handles the transformation). What would we gain by bundling the code into explicit comonads?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11295132.post-71200250215009507042007-01-27T08:21:00.000-08:002007-01-27T08:21:00.000-08:00I know the Per Christensen paper well though I fir...I know the Per Christensen paper well though I first thought about this stuff in the context for forward/reverse mode automatic differentiation. (Closely related is my practical experiment <a href="http://sigfpe.blogspot.com/2005/05/dual-photography-part-ii.html">here</a> based on a SIGGRAPH paper.)<br /><br />Adjunctions were loosely 'modelled' on adjoints but I haven't yet thought hard about whether the connection is deeper. But there are distinct push and pull algorithms for matrix multiplication (the difference is important when writing sparse matrix routines) so I expect I could get a monad/comonad distinction out of it.sigfpehttp://www.blogger.com/profile/08096190433222340957noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-10606493391640653032007-01-27T05:11:00.000-08:002007-01-27T05:11:00.000-08:00The deep link between ray tracing and scanline ren...The deep link between ray tracing and scanline rendering actually goes much deeper than than.<br /><br />I'll leave the full details to <a href="http://www.seanet.com/~myandper/abstract/tvcg03.htm">a paper</a> on the topic, but intuitively, you can think of the 3D scene as a vector space, the vectors of which are an assignment of output irradiance (emitted light) from each point.<br /><br />If you think of the "source" lights as a vector x and the "destination" film plane as a vector y, then scanline rendering is an inner product < M x | y > (using Dirac bracket notation), where M is an operator that moves light from the source. So you can think of M transporting light from the light sources, and then the camera just samples.<br /><br />Ray tracing, then, is the following inner product: < x | M* y >, where M* is an operator that traces some quantity (usually called "importance") out from the camera in the direction of the light sources.<br /><br />Linear algebraists will recognise that in the matrix formulation M* is the <i>adjoint matrix</i> of M Quantum mechanics/operator calculoids will also recognise the adjoint operator. One of the interesting results of rendering theory is that most of the basic light transport operations are self-adjoint, which is why ray tracing works.<br /><br />Now compare this with the category theory adjunction (F and G are adjoint if C[x, F y] = D[G x, y] for all x, y). Is there a deeper connection here? Are the natural monad/comonads here in some way adjoint?Pseudonymhttp://www.blogger.com/profile/04272326070593532463noreply@blogger.com