[fonc] maru bootstrap implementation in common lisp
I've been working on an implementation of boot.c in common lisp for the past few weeks; my code now correctly generates eval.s. You can find the code here https://github.com/burrows-labs/below-the-top. I had been considering for some time that lisp evaluation could be broken down into an abstract transformation machine. Each stage composing on the results of the previous stage until finally execution stops after doing the evaluation transformation. Each stage has it's own set of semantics pertaining to the different data types. ie, expansion treats a macro differently than the reader. I implemented boot.c using this model. The code still needs a bath and it's very slow; largely because it's using an assoc list and string= to lookup symbols. In order to run the code, you will also need this file https://github.com/burrows-labs/lisp/blob/master/repl-utils.lisp. And you will have to make these changes to the maru code https://gist.github.com/burrows-labs/1f2edcdd92271a9c8ef7. My implementation uses a graph for environments and this doesn't play well with what maru expects for current-environment(...) (being the global environment usually). I also didn't spend time trying to get *globals* to work; so you have to use _global-environment(...). The c implementation of maru uses encode(...); which changes the semantics of doing lookups in ``operators'' and ``forms'' (global variables) as emit.l expects symbols to already have been substituted for fixed and expr. Implementing quote(...) and set(...) nicely proved to be challenging. I introduced the ``pseudoexpansion'' transformer to handle with set(...). Here (set (that other) x) we want to expand set(...) after it's arguments are expanded (because ``that'' might be a macro). We could explicitly expand the arguments in maru-primitive-set; currently we use ``pseudoexpansion''. During ``pseudoexpansion'' we know that all other expansions have occurred. I never came up with a satisfactory solution for quote; currently the expansion transformer has to use a conditional for fixed leads in order to prevent the expansion of quote args. _lead_ is what the implementation calls the first form in an sexpression. _args_ are the other forms. There are more than 100 tests at the bottom of 'metalang.lisp' that may help in understanding how the code works. I also kept a list of notes about the original boot.c that you can find here https://gist.github.com/burrows-labs/7369854. the ``='' operator is broke; it gives incorrect results for things that aren't strings, symbols and numbers. but it works well enough to run the compiler. Generalizing the processing of the sexpressions into the transformers model was pretty straightforward for the most part. But note that *forwarding-symbol* is a bit of a hack. Because I want to deal with each type of object in it's particular handler for each stage of execution (and not just do everything in the symbol handler); some combinations of transformer and data type require me to return the symbol instead of the thing it's binded to. In particular if I'm doing an expansion and I get forwarded to an expr, it needs to know what symbol it's binded to (instead of replacing the symbol with the expression object as we would during evaluation). maru is a pretty ecosystem; the simplicity of the multimethod implementation speaks for itself. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
Hi Shawn, It is not aliasing that is different, but the algorithms for rasterization. When doing ray tracing for a 3d scne, you don't have an analytical model of the function to be sampled. Quoting Shawn Morel : > On Dec 6, 2013, at 6:58 AM, J. Vuletich (mail lists) > wrote: > > > > Stochastic sampling (1) is a method for trading aliasing for noise. Result > > are neither alias free nor noise free. But it allows using Ray Tracing and > > related techniques, and that is great for photorealistic rendering of 3D > > stuff. This the kinds of problems Pixar works on. > > I?m actually curious to understand the distinction here between aliasing from > rays sampling the 3d scene (geometry intersection, texture UV mapping, env > lighting etc) and how that?s different from sampling a continuous function to > figure out pixel coverage. > > > shawn Cheers, Juan Vuletich___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
On Dec 6, 2013, at 6:58 AM, J. Vuletich (mail lists) wrote: > Stochastic sampling (1) is a method for trading aliasing for noise. Result > are neither alias free nor noise free. But it allows using Ray Tracing and > related techniques, and that is great for photorealistic rendering of 3D > stuff. This the kinds of problems Pixar works on. I’m actually curious to understand the distinction here between aliasing from rays sampling the 3d scene (geometry intersection, texture UV mapping, env lighting etc) and how that’s different from sampling a continuous function to figure out pixel coverage. shawn___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
Hi Gath, Stochastic sampling (1) is a method for trading aliasing for noise. Result are neither alias free nor noise free. But it allows using Ray Tracing and related techniques, and that is great for photorealistic rendering of 3D stuff. This the kinds of problems Pixar works on. OTOH, I focus in 2D vector graphics, and not in 3D rendering. And yes, common implementations of OpenGL and libraries such as Cairo and AGG don't do prefiltering (called 'Analytical Algorithms' by Cook). I hope this helps. Cheers, Juan Vuletich (1) http://www.cs.virginia.edu/~gfx/Courses/2003/ImageSynthesis/papers/Sampling/Stochastic%20Sampling%20in%20Computer%20Graphics.pdf Quoting Gath-Gealaich : On Tue, 03 Dec 2013 23:24:12 -0300 "J. Vuletich (mail lists)" wrote: Hi Folks, The first defensive disclosure about Morphic 3 has been accepted and published at http://www.defensivepublications.org/publications/prefiltering-antialiasing-for-general-vector-graphics and http://ip.com/IPCOM/000232657 .. Morphic 3 is described at http://www.jvuletich.org/Morphic3/Morphic3-201006.html On http://www.jvuletich.org/Morphic3/Morphic3-201006.html, you claim: Anti-aliasing is usually considered a technique to avoid "stairway" artifacts on rendered images. This is a simplistic view on the problem. Aliasing is a consequence of sampling continuous functions (images, photos, sound, etc). Makers of digital cameras and audio software know and use the theory behind it. You can read more at http://en.wikipedia.org/wiki/Nyquist–Shannon_sampling_theorem. Researches know all this. The best text books say it. However, existing graphics software completely ignore the theory. ... This allows for mathematically proved alias free rendering. As no existing application does this ... I'm sort of puzzled by this. I've always thought that this was the whole idea behind the stochastic sampling thingy that the ILM/Pixar people patented (http://www.google.com/patents/US4897806) in the 1980's to achieve mathematically proven alias-free rendering (as you said) of arbitrarily shaded arbitrary geometry (even shaded with non-analytical functions). Of course, it trades aliasing for noise, but I believe that you can have the noise arbitrarily low (and for animations, it may not matter all that much anyway since one can expect some grain or noisiness on live footage so completely noise-free sampling may even look unnatural). They certainly didn't ignore the problem; they had been studying numerous analytical and non-analytical solutions for a better part of the 1980s and then finally striked gold with stochastic sampling and PRMan. -- Gath ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc Cheers, Juan Vuletich ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
