lester@infonode.ingr.com (Lester Bartel) (10/19/90)
Has anyone gotten the fern postscript program to run? It was published in Byte magazine a few months ago but seems to have one or more bugs in it. I would like a copy of it if it has been fixed. I recall that someone else posted a question similar to this shortly after the issue was on the newsstand, so you may want to post it here. Thanks, - Lester -- Lester Bartel b23b!naomi!lester@ingr.com Intergraph Corp. uunet!ingr!b23b!naomi!lester
nelson@melodian.cs.uiuc.edu (Taed Nelson) (10/19/90)
This is the same code as from Byte, except that I made it larger, centered it on the page, and added many more points. By the way, I found no "bugs" -- this is typed exactly (except indenting). -------------------- %! /problistcreate { mark /counter 0 def probabilities { 128 mul round cvi { transforms counter get } repeat /counter counter 1 add def } forall counttomark 128 sub neg dup 0 gt { [1 0 0 1 0 0] repeat } {pop} ifelse] /problist exch def } bind def /doit { problistcreate 1 1 20 { problist rand -24 bitshift get transform 2 copy moveto 0.001 10 rlineto } repeat newpath numdots { problist rand -24 bitshift get transform 2 copy moveto 0.001 0 rlineto stroke } repeat } bind def /numdots 600000 def /transforms [ [ 0 0 0 .16 0 0 ] [ .2 .23 -.26 .22 0 1.6 ] [ -.15 .26 .28 .24 0 .44 ] [ .85 -.04 .04 .85 0 1.6 ] ] def /probabilities [ .01 .07 .07 .85 ] def 1 setlinecap 0 setlinewidth 300 0 translate 100 75 scale doit showpage quit
schuster@cup.portal.com (Michael Alan Schuster) (10/19/90)
>Has anyone gotten the fern postscript program to run? It was >published in Byte magazine a few months ago but seems to have >one or more bugs in it. I would like a copy of it if it has >been fixed. I recall that someone else posted a question >similar to this shortly after the issue was on the newsstand, >so you may want to post it here. % Title: Fractal fern % Copyright c 1990 by Don Lancaster and Synergetics, 3860 West First Street, % Box 809, Thatcher AZ 85552. (602) 428-4073. All commercial rights reserved. % Personal use permitted so long as this header remains present and intact. % Show and Tell disk for Apple, Mac, or IBM costs $39.50. Free voice helpline. % X % % This routine create a fractal fern. % Additional details appear in Don Lancaster's LaserWriter Secrets text. % Approximate NTX run time: Varies depending on numdot length. % .................................... /problistcreate {mark /counter 0 def probabilities {128 mul round cvi {transforms counter get} repeat /counter counter 1 add def} forall counttomark 128 sub neg dup 0 gt {[1 0 0 1 0 0] repeat} {pop} ifelse] /problist exch def} bind def /doit {problistcreate 1 1 20 {problist rand -24 bitshift get transform 2 copy moveto 0.001 10 rlineto} repeat newpath numdots {problist rand -24 bitshift get transform 2 copy moveto 0.001 0 rlineto stroke} repeat} bind def % /// demo - remove before use /// /numdots 6000 def % increase for denser image; descrease to print faster /transforms [ [0 0 0 .16 0 0] [.2 .23 -.26 .22 0 1.6] [-.15 .26 .28 .24 0 .44] [.85 -.04 .04 .85 0 1.6] ] def /probabilities [.01 .07 .07 .85] def 1 setlinecap 0 setlinewidth 200 300 translate 30 dup scale doit showpage quit
CXT105@psuvm.psu.edu (Christopher Tate) (10/19/90)
I got it working quite well over the summer, and the only "typo" I can
recall (and looking at the posted code, I believe I'm right) is that
in both occurences, the line "moveto .001 10 rlineto" should rightly
read "moveto .001 0 rlineto."
Note that this is a purely cosmetic bug, which affects only the manner
in which some of the "dots" are drawn.
-------
Christopher Tate |
| Mathematics is skill in the use
cxt105@psuvm.psu.edu | of very small words.
{...}!psuvax1!psuvm.bitnet!cxt105 |
cxt105@psuvm.bitnet | -- Adrian Ocneanu
flar@bendenweyr.Eng.Sun.COM (Jim Graham) (10/20/90)
In article <1990Oct18.204534.9186@julius.cs.uiuc.edu>, nelson@melodian.cs.uiuc.edu (Taed Nelson) writes: |> /doit { |> problistcreate 1 1 20 { |> problist rand -24 bitshift get transform 2 copy |> moveto 0.001 10 rlineto |> } |> repeat newpath numdots { |> problist rand -24 bitshift get transform 2 copy |> moveto 0.001 0 rlineto stroke |> } |> repeat |> } |> bind def What am I missing here? In the first repeat loop, a lot of moveto rlineto's get generated but the result is never stroked or filled, it is just thrown away with a newpath. What's the point (only side effect that I can see is the execution of 20 rand's, so it essentially just throws out 20 random numbers and takes a long time to do it. The other posting of this same piece of code was the same (modulo indentation), so it doesn't seem to be a posting error. Also, the "10 rlineto" doesn't have to be a "0 rlineto" since the result of the rlineto is thrown out anyway. ...jim
danielce@ecr.mu.oz.au (Daniel Ake Massimo Paolo Carosone) (10/21/90)
In article <1990Oct19.160619@bendenweyr.Eng.Sun.COM> flar@bendenweyr.Eng.Sun.COM (Jim Graham) writes: >In article <1990Oct18.204534.9186@julius.cs.uiuc.edu>, >nelson@melodian.cs.uiuc.edu (Taed Nelson) writes: > >> [Some PS code involving rlineto] > >What am I missing here? In the first repeat loop, a lot of moveto >rlineto's get generated but the result is never stroked or filled, >it is just thrown away with a newpath. What's the point (only side >effect that I can see is the execution of 20 rand's, so it essentially >just throws out 20 random numbers and takes a long time to do it. But it *does* move the Current Point. There is *no* gsave ... grestore, so this has the effect of going through the IFS transformations, and eventually places ink at the appropriate places.. -- Daniel Carosone, System Administrator, TeXworks (Australia) Pty. Ltd. From postnews Sun Oct 21 19:17:08 1990 In article <1990Oct19.160619@bendenweyr.Eng.Sun.COM> flar@bendenweyr.Eng.Sun.COM (Jim Graham) writes: >In article <1990Oct18.204534.9186@julius.cs.uiuc.edu>, >nelson@melodian.cs.uiuc.edu (Taed Nelson) writes: > >> [Some PS code involving rlineto] > >What am I missing here? In the first repeat loop, a lot of moveto >rlineto's get generated but the result is never stroked or filled, >it is just thrown away with a newpath. What's the point (only side >effect that I can see is the execution of 20 rand's, so it essentially >just throws out 20 random numbers and takes a long time to do it. But it *does* move the Current Point. There is *no* gsave ... grestore, so this has the effect of going through the IFS transformations, and eventually places ink at the appropriate places.. -- Daniel Carosone, System Administrator, TeXworks (Australia) Pty. Ltd.
flar@bendenweyr.Eng.Sun.COM (Jim Graham) (10/24/90)
In article <5830@munnari.oz.au>, danielce@ecr.mu.oz.au (Daniel Ake Massimo Paolo Carosone) writes: |> In article <1990Oct19.160619@bendenweyr.Eng.Sun.COM> |> flar@bendenweyr.Eng.Sun.COM (Jim Graham) writes: |> >In article <1990Oct18.204534.9186@julius.cs.uiuc.edu>, |> >nelson@melodian.cs.uiuc.edu (Taed Nelson) writes: |> > |> >> [Some PS code involving rlineto] |> > |> >What am I missing here? In the first repeat loop, a lot of moveto |> >rlineto's get generated but the result is never stroked or filled, |> >it is just thrown away with a newpath. What's the point (only side |> >effect that I can see is the execution of 20 rand's, so it essentially |> >just throws out 20 random numbers and takes a long time to do it. |> |> But it *does* move the Current Point. There is *no* gsave ... grestore, |> so this has the effect of going through the IFS transformations, |> and eventually places ink at the appropriate places.. Not only is a newpath executed (which tosses the currentpoint), but the code in the following repeat loop does a moveto before each rlineto, so the currentpoint after the first repeat loop would be meaningless even if it weren't destroyed by newpath. So, the question still remains: What does the first loop do? |> /doit { |> problistcreate 1 1 20 { |> problist rand -24 bitshift get transform 2 copy |> moveto 0.001 10 rlineto |> } |> repeat newpath numdots { |> problist rand -24 bitshift get transform 2 copy |> moveto 0.001 0 rlineto stroke |> } |> repeat |> } |> bind def ...jim
pollack@dendrite.cis.ohio-state.edu (Jordan B Pollack) (10/24/90)
Its not the postscript, its the mathematics. The theory embodied in Iterated Fractal Systems is that a sequence of affine transformations (chosen from a finite set with some probability distribution) applied to any starting point will land on an underlying fractal attractor. There is no way to know if any particular starting point is on the attractor, so the first 20 moves is just a hack to get onto it. -- Jordan Pollack Assistant Professor CIS Dept/OSU Laboratory for AI Research 2036 Neil Ave Email: pollack@cis.ohio-state.edu Columbus, OH 43210 Fax/Phone: (614) 292-4890
flar@bendenweyr.Eng.Sun.COM (Jim Graham) (10/24/90)
Whoops. I see my mistake. There is a pair of coordinates being left on the stack after each iteration that is changed each time throught the loop (the moveto and lineto in the first repeat loop are still useless as they aren't stroked). This is the "current point" that is modified. ...jim
shiva@well.sf.ca.us (Kenneth Porter) (11/02/90)
> But it *does* move the Current Point.
Somewhat misleading. newpath sets the current point to undefined.
What is happening is that the "1 1" before the loop functions
as a seed. The loop transforms this coordinate randomly to
come up with a new coordinate pair. You can see this by doing
a pstack after each iteration.
Ken (shiva@well.sf.ca.us)