great! Till Am 07.12.2009 um 01:09 schrieb Bill Marriott:
> Hi Mark, > >>>> what about using task/code examples from >>>> http://shootout.alioth.debian.org/. Revcoders (us, runrev ltd?..) will >>> I think that's a great idea. >> Sorry, Kevin, I think it's a Very Bad Idea. > > Thanks so much for taking the time to do this! But I think it's a *great* > example, and I am going to show you why. > > Let's start out with a few observations: > > - How "practical" is this? I took a closer look at the site. > > http://shootout.alioth.debian.org/u64/benchmark.php?test=mandelbrot&lang=all&box=1 > > The goal of the routine is to generate a mandelbrot image in the .PBM > format. Now, this has some relevance I suppose in testing CPU performance, > but not exactly in the real world. How many programs read PBM, for one? None > on my Mac, but Photoshop and Paint Shop Pro could read it on my Windows PC. > How fun is it to run this program, then load the result up in a graphics > editor? About as much fun as punch-card, batch programming. > > - The original Pascal program (or at least your transliteration of it) *has > a bug!* Give the output file an extension of .pbm and load it into a program > that can read that format. You'll find that the image is skewed more and > more as the dimensions increase. > > http://revuser.com/mandel/orig-600.png > > In either Pascal or revTalk, as coded, it's going to be a challenge to find > out where that bug lies. > > - It doesn't seem like it was that hard to "transliterate" the original > Pascal code. I was impressed by the similarities, actually. Even then, there > are portions of your revTalk version that are a little more readable. Since > the vast majority of this is mathematics, and we're not out to reinvent > algebraic notation, you're right that it's not the best showcase. Math is > going to be math in any programming language. It's certainly not *less* > readable. What makes it hard is the Mandelbrot formulas and especially the > encoding into .pbm format (which is what requires all those bit operations. > (Maybe all of the examples from that site are like this?) > > - Pascal is considered a pretty "easy" language. Did you check out what the > "solution" looks like in Java? > > http://shootout.alioth.debian.org/u64/benchmark.php?test=mandelbrot&lang=javaxint&id=3 > > In C++? > > http://shootout.alioth.debian.org/u64/benchmark.php?test=mandelbrot&lang=gpp&id=5 > > Woah! :) > > - Well our performance is a is a bit disappointing relative to the "command > line" Pascal version, we *do* beat out variants of PHP, Python, Ruby, and > Perl, depending on what your processor was versus the one used for the > benchmarks. > > - You were able to add a nice GUI file selector dialog trivially. Now, > imagine that your goal isn't to produce a .pbm image, but rather to show > something on-0screen the user could interact with in some way. Things > get more interesting. This is where Rev starts to shine. The > further away you get from "pure" math and have to get into user interface, > interaction with local and remote file systems, manipulating data sets, and > business logic issues, the better we look. Our language abstracts the > operating system, so developers don't need to be concerned with the proper > API to call for common tasks. > > - Most (but not all) of us are not using Rev to generate Mandelbrot data. > We're creating usable applications for business tasks, entertainment and > educational software, database front-ends, etc. It might well be that this > site/link is all about these kinds of math-intensive routines. I didn't look > too closely at them, admittedly. What I did like about Viktoras' suggestion > was that he found a site with some sample code in a variety of languages. I > think it's healthy for us to look for such examples and discover the > strengths and weaknesses that emerge when we try to express them in revTalk. > > My take on the "productivity" equation is that it's not merely the number of > lines of code produced, and it's ultimately not even how fast the code > executes. In most situations, it's how long it takes to express the > algorithm, and debug it later on. To encapsulate algorithms in flexible user > interfaces. To take things to an extreme: a routine > built with machine code or assembly will always execute faster than one > built in a high-level language. But how many of us could sit down and write > a database front-end in assembly? How long would it take? How usable and > adaptable would it be? > > Another way to look at things is from the artist's viewpoint. There are > people who will never touch digital photography because they are expert at > the analog process. There are illustrators who will never give up their > charcoals. There are Lego builders who spurn the non-rectangular bricks! And > thank heaven for them, because I respect the desire for control and > attention to nuance. In a similar vein, other languages can indeed reward > sweating details like what kind of number you're trying to store, manually > allocating and releasing memory, etc. > > We're not promising to be the tool that lets you rewrite OpenGL or even > build a competitor to Excel. Instead, we're a tool that complements these > other technologies, and opens up the idea that -- for example -- instead of > spending hours "steering" Excel you might automate your workflow such that > data acquisition, processing, and presentation might all be handled with a > single click. > > Enough pontificating eh? Let's get to coding. I'm going to deliver on my > promise to show you why this actually shows off why Rev is so fantastic. > > I was intrigued by this example, because Mandelbrots are beautiful things. I > knew they had something to do with imaginary numbers, that they are > infinitely variable -- you can zoom in on them forever and not find a > repeated pattern. But I didn't understand the math, so of course I couldn't > really analyze the original Pascal code effectively. > > I had to become a "mini" content expert. So I read up on Mandelbrots. I > found some useful pages: > > http://www.wikihow.com/Plot-the-Mandelbrot-Set-By-Hand > > http://www.olympus.net/personal/dewey/mandelbrot.html > > and especially > > http://steve.hollasch.net/cgindex/misc/mandelbrot.html > > Now I was getting somewhere. I learned that a Mandelbrot is a graph where > the x axis represents a "real" number, and the y axis represents an > imaginary number (a number involving the element "i" -- which is the square > root of -1). The unique thing about a Mandelbrot set is that you don't know > for sure whether a given coordinate is within the set until you test it > iteratively. Some coordinates reveal themselves to be part of the set > quickly, and some not so quickly. The "depth" you have to go in this > iterative calculation varies for each coordinate. It also involves a kind of > "digital sampling" phenomenon, where things look different depending on the > "resolution" at which you're charting. That hardly covers the whole topic, > but it was enough to give me a handle on what the routines were trying to > do. > > I found George Taylor's page to be much more useful than the Pascal code as > a launch point for understanding how to chart a Mandelbrot in revTalk. For > one thing, he didn't break it up into multiple nested functions, which made > it easier for me to understand. Second, I'm much more familiar with BASIC > from my early days with the Sinclair ZX81 than I am with Pascal. I took his > code example: > > INPUT "Initial Real value of C",CRL > INPUT "Final Real value of C",CRH > INPUT "Initial Imaginary value of C",CIL > INPUT "Final Imaginary value of C",CIH > INPUT "Iteration limit",MAXITER > WIDTH=320 > HEIGHT=200 > XSIZE=(CRH-CRL)/(WIDTH-1) > YSIZE=(CIH-CIL)/(HEIGHT-1) > FOR Y=0 TO 199 > CI=CIH-Y*YSIZE > FOR X=0 TO 319 > CR=X*XSIZE+CRL > REM Now CR, CI are scaled > REM Do Z<-Z^2+C iteration > MEMBER=TRUE > ZR=0 > ZI=0 > FOR I=1 TO MAXITER > NEWZR=ZR*ZR-ZI*ZI+CR > NEWZI=2*ZR*ZI+CI > ZR=NEWZR > ZI=NEWZI > Z=SQR(ZR*ZR+ZI*ZI) > IF Z>2 THEN > MEMBER=FALSE > EXIT (exits the FOR loop) > ENDIF > NEXT I > IF MEMBER=TRUE THEN > PLOT X,Y > ELSEIF ((MAXITER-I) AND 1)=0 THEN > PLOT X,Y > ENDIF > NEXT X > NEXT Y > END > > And I did my own revTalk translation, this time making generous use of long > variable names that made more sense to me: > > on mouseUp > put fld "cRstart" into cRstart > put fld "cRend" into cRend > put fld "cIstart" into cIstart > put fld "cIend" into cIend > put fld "maxIterations" into maxIterations > put fld "myWidth" into myWidth > put fld "myHeight" into myHeight > > put (cRend-cRstart)/(myWidth-1) into plotWidth > put (cIend-cIstart)/(myHeight-1) into plotHeight > > -- for each y-axis value (scaled) > repeat with y=0 to myHeight-1 > put cIend-y*plotHeight into cImaginary > > -- for each x-axis value (scaled) > repeat with x=0 to myWidth-1 > put x*plotWidth+cRstart into cReal > > -- test the coordinate iteratively > put true into itBelongs > put 0 into zReal; put 0 into zImaginary > > repeat with i = 1 to maxIterations > > put zReal * zReal - zImaginary * zImaginary + cReal into newZreal > put 2*zReal*zImaginary+cImaginary into newZimaginary > > put newZreal into zReal; put newZimaginary into zImaginary > put sqrt(zReal*zReal+zImaginary*zImaginary) into z > > if z>2 then > put false into itBelongs > exit repeat > end if > > if z> 2 then exit repeat > > end repeat > > if itBelongs then > put i into myPlot[x][y] > else > if maxIterations-i > 0 then > put i into myPlot[x][y] > end if > end if > > end repeat > end repeat > end mouseUp > > Now you'll notice that even now I'm able to do something a little different > from Taylor's original algorithm. Where he says, "plot x,y" -- which marks > the pixel at x,y black -- I store i within a multi-dimensional array. This > stores the number of generations it took to determine whether x,y was part > of > the Mandelbrot set. It will enable me to produce a prettier graph, and also > separates the output code (whether I'm going to create a .pbm file or > display > on-screen or do something else from it) from the code used to generate the > Mandelbrot itself. > > Showing the image on-screen in Rev was a piece of cake, relative to creating > a .pbm file. > > repeat with y=0 to myHeight-1 > repeat with x=0 to myWidth-1 > -- more iterations yields a lighter color > put numToChar(trunc(myPlot[x][y]/maxIterations*256)) into c > -- create a shade of grey > put numToChar(0) & c & c & c after bitmapData > end repeat > end repeat > set the width of image "mandelPlot" to myWidth > set the height of image "mandelPlot" to myHeight > set the imageData of image "mandelPlot" to bitmapData > > That's because the imageData is simply four whole bytes representing 0 and > the R, G, B values of the pixel. Inefficient perhaps, but really simple. No > bitwise > operations unless I really need to (and I won't need to, since Rev can > export > snapshots to a variety of common formats). > > It didn't take me much work to display a beautiful, greyscale image of a > real Mandelbrot on-screen. Plus I had a nice UI that would let me set all > the parameters of the equation visually. I had one final thing I wanted to > do, and that was to make it so I could "zoom in" on the Mandelbrot to > explore its infinitely variable nature. > > All I did was overlay a graphic on top of the "mandelPlot" image I created, > then attach a script which would make note of where I clicked on it, set > that as the new origin, and set a new scale around that point. > > My "finished" stack is at: > > http://revuser.com/mandel/MyMandelbrot.zip > > I would say that I got much further along exploring and understanding the > magic of fractals. In the end, I'm looking at a 300x300 or maybe a 900x900 > screen image; I'm not generating 16,000x16,000 bitmaps. So it doesn't really > matter if it takes 3 or 30 seconds to generate. I have a solution that has a > nice user interface so I can tweak various settings and interactively see > their effect on the graph. I already added niceties like a progress bar, and > zooming. > > I could add more customizations like the ability to set the colors I want to > use. The code I have written to generate the Mandelbrot is about as clear as > it could be. (And I'd like to see what the Pascal or C++ code would be to > replicate my little stack's UI/functionality!) > > By analogy, when constructing business applications, the "hard part" -- the > part you have to get right -- should be understanding your business. It > shouldn't be expressing that business logic/mechanics within code. Rev > enabled me to focus on the science of Mandelbrots, not the mechanics of > creating a bitmap. It allowed me to create a program that I could use to > explore what Mandelbrots are in a beautiful, fun, engaging way. And if I > ultimately decided that I needed blistering performance in rendering the > graphs, I could always crack open my Pascal or C++ compiler and make an > external that did the "heavy lifting" down the road. > > Look at it this way -- would an organization prefer a piece of code that > runs in 3 seconds but does only one thing, and can't be modified except > by the original coder? To change the parameters of the graph in Pascal, > one must load up the compiler, edit the right bits of the code, do a "build" > and all that stuff. Or, would you like an application like my stack, which > might > take 10 times longer to execute, but gives the end user a lot of control > and flexibility to understand what's going on? > > Productivity isn't about processor cycles, and it's not always about lines > of code. It's about how much one can accomplish with the knowledge > they have. > > > _______________________________________________ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution