On Wed, Nov 9, 2011 at 3:34 PM, Dan Amelang <[email protected]>wrote:
> I'm pointing out that, as useful as input prefixing is, it doesn't appear > at all in stream processing languages. Furthermore, it doesn't appear > in stream processing models of computation. > Old wine, new ontology. Elevating common design patterns and library abstractions to language primitives does not, IMO, qualify as any sort of `original contribution`. It's up to you to decide whether to claim forty year old technology as an original contribution. (You won't be the first to do so, nor the last.) Personally, I would choose the more humble route. I would note the utility of having input prefixing uniformly across types with low syntactic overhead, but not claim it. > Is this conclusion really important enough to argue for? That > rendering lines should be considered valuable but not vital? It important to recognize an application of the Inventor's Paradox<http://en.wikipedia.org/wiki/Inventor%27s_paradox>. You attempt to solve a specific problem - rendering lines. This problem is solved more easily, more naturally, by rendering areas. The rendering of lines then becomes a simple, special case of the more general problem. It is also important to recognize that, by rendering areas, the modeling of pen-strokes is, essentially, already solved. Sure, it may be useful to fill out the library with some support for bezier paths. But it is not essential. That's the difference between valuable and vital. > > Pen-strokes with fill is a very imperative approach... > > This is just too much. Let's go over the details. Here are the relevant details to my conclusion: 1) You move a logical pen above a logical canvas by a sequence of move and stroke commands. 2) The move and stroke commands themselves are not commutative, not idempotent, and not referentially transparent - they depend on implicit state of the pen. 3) Filling a shape requires extracting shape from an unstructured history of lines. You effectively cannot extract shapes without executing the program and filling at the right points in history. Imperative isn't about impurity or indeterminism. Imperative is about updating and querying state, implicit time, dependence on history and order of expression. Pen-stroke and fill is the classic example of imperative draw models. You argue that your algorithm is pure (from an external perspective), and your pipeline as a whole is pure. And I agree. Nile is a fine example of `imperative in-the-small, functional in-the-large`, much like using local State or ST monads to implement functions in Haskell. I did not intend for you to take offense. Imperative does not mean `slaughters puppies`. Stroke and fill is certainly a well proven model. > You are apparently partial to implicit surfaces. OK, why not give your > ideas a shot and show us how it turned out? Maybe try rendering > something similar to VPRI's Frank as a benchmark of functionality? > I plan to do so, once I get around to developing the zoomable UI abstractions. > > > Modeling anti-aliased rasterization in a purely functional system is > > quite straightforward, at least if you aren't composing images in > rasterized > > form. > > My challenge to find a previous anti-aliased rasterizer done in a > purely functional style still stands. I issued it to counter what I felt were unsubstantiated claims. I do not need an algorithm written in a functional style to model anti-aliased rasterization in a purely functional system. What I do need is an algorithm that is pure and deterministic up to input. I understand that most rasterization algorithms qualify. I assume you have misread my claim to mean something less obvious. That said, I have no doubts that anti-aliased rasterization can be achieved in a functional style - I've read a few simple functional ray-tracing engines, for example, and I understand that raycast per pixel results in images of a quality on par with many anti-aliasing techniques even without super-sampling or sub-pixel sampling. I would only express some concerns about their efficiency. Anyhow, thanks for answering my earlier queries, and keep up the good work. Regards, Dave
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
