[comp.lang.postscript] Byte's fern postscript program

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)