Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #21847 > unrolled thread

Injecting some activity through "questions" (DSLs)

Back to article view | Back to comp.lang.javascript

Contents

  Injecting some activity through "questions" (DSLs) "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-11-01 21:06 -0700
    Re: Injecting some activity through "questions" (DSLs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-11-02 20:15 +0000
      Re: Injecting some activity through "questions" (DSLs) "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-11-03 15:30 -0800
        Re: Injecting some activity through "questions" (DSLs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-11-04 02:06 +0000
          Re: Injecting some activity through "questions" (DSLs) "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-11-11 13:11 -0800
            Re: Injecting some activity through "questions" (DSLs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-11-11 21:55 +0000
    L-system construction of Lévy C curves (was: Injecting some activity through "questions" (DSLs)) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-02 21:31 +0100
      Re: L-system construction of Lévy C curves (was: Injecting some activity through "questions" (DSLs)) "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-11-03 15:38 -0800
        Re: L-system construction of Lévy C curves Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-04 03:12 +0100
          Re: L-system construction of Lévy C curves "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-11-03 19:17 -0800
    Re: Injecting some activity through "questions" (DSLs) John Harris <niam@jghnorth.org.uk.invalid> - 2013-11-03 11:23 +0000
      Re: Injecting some activity through "questions" (DSLs) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-11-03 12:43 +0000
      Re: Injecting some activity through "questions" (DSLs) "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-11-03 15:41 -0800

#21847 — Injecting some activity through "questions" (DSLs)

Since there have been complaints about lack of questions and activity in the group, I've decided to ask a question once in awhile to hopefully spark some more activity. These will probably be questions I already know the answer to or something which is in the realm of opinion/style and a point of conflict in the JS community in general. On the former kind of questions I'll feign ignorance in order to draw out some hopefully useful discussions and aspects. So if you're willing to play along, here is my first question:

I have a <canvas/> element upon which I draw shapes and lines. To abstract away the dirty details, I've created a small language with which I use to draw the desired shapes:

F: Draw Forward
f: Move Forward
[: Push State
]: Pop State
-: Rotate Left
+: Rotate Right

An example of usage would be:

defSystem({
    name:"Levy C Curve",
    start: "F",
    x: 450,
    y: 300,
    depth:11,
    stepSize: 5,
    angle: Math.PI,
    stepAngle: Math.PI/4,
    rules: {
        "F": "+F--F+"
    }
})

which would draw the expected shape:
<https://en.wikipedia.org/wiki/Levy_C_curve>

"start" is the initial rule,
"rules" lists the substitution rules on each step
"depth" is how many times the substitutions should occur
"x","y" is the initial drawing position
"depth" is how many times the rules
"stepSize" controls how far "F" and "f" go
"stepAngle" defines how much "+" and "-" turn

So after just 4 steps, the rule to draw the shape looks like this:

F
+F--F+
++F--F+--+F--F++
+++F--F+--+F--F++--++F--F+--+F--F+++
++++F--F+--+F--F++--++F--F+--+F--F+++--+++F--F+--+F--F++--++F--F+--+F--F++++

you can begin to see how big this is starting to become, and this is just
a simple drawing... These can get complicated quite fast:

defSystem({
    name:"Islands and Lakes",
    start: "F+F+F+F",
    x: 500,
    y: 480,
    depth: 3,
    stepSize: 2,
    stepAngle: Math.PI/2,
    angle: Math.PI,
    rules: {
        "F": "F+f-FF+F+FF+Ff+FF-f+FF-F-FF-Ff-FFF",
        "f": "ffffff"
    }
})

Which looks similar to: <http://www.ph2.net/XLinden/bilder2d/TABOP-1.8.gif>

Currently my program works by initially performing the replacements and expanding the drawing commands out as far as necessary before executing the final string (which as you've seen, can be quite large).

How would you approach this problem and prevent the exponential expansion of the string while still being able to execute the drawing rules?

[toc] | [next] | [standalone]

#21855

"Michael Haufe (TNO)" <tno@thenewobjective.com> writes:

> Since there have been complaints about lack of questions and activity
> in the group, I've decided to ask a question once in awhile to
> hopefully spark some more activity. These will probably be questions I
> already know the answer to or something which is in the realm of
> opinion/style and a point of conflict in the JS community in
> general. On the former kind of questions I'll feign ignorance in order
> to draw out some hopefully useful discussions and aspects.

I think the feigned ignorance will be a little odd, but there must be
lots of people with "I wonder how you'd do this" kind of questions.

> So if
> you're willing to play along, here is my first question:
>
> I have a <canvas/> element upon which I draw shapes and lines. To
> abstract away the dirty details, I've created a small language with
> which I use to draw the desired shapes:
>
> F: Draw Forward
> f: Move Forward
> [: Push State
> ]: Pop State
> -: Rotate Left
> +: Rotate Right
>
> An example of usage would be:
>
> defSystem({
>     name:"Levy C Curve",
>     start: "F",
>     x: 450,
>     y: 300,
>     depth:11,
>     stepSize: 5,
>     angle: Math.PI,
>     stepAngle: Math.PI/4,
>     rules: {
>         "F": "+F--F+"
>     }
> })

A nice idea.  My inner compulsive wants to put the start string into the
rules under a special "initial rule" name.  If you make it a single
letter name, then other rules can refer back to the start rule, but I
don't suppose that will happen much in practice.

<snip>
> Currently my program works by initially performing the replacements
> and expanding the drawing commands out as far as necessary before
> executing the final string (which as you've seen, can be quite large).
>
> How would you approach this problem and prevent the exponential
> expansion of the string while still being able to execute the drawing
> rules?

I tried to methods.  The first was just to interpret the string and look
up the non-rotation characters as I went.  The second was to "compile"
the string into a function so that the main drawing operation became:

  compile(curve.start, curve)(0);

and each of the rules was compiled to

  curve.compiled_rules[rule] = compile(curve.rules[rule], curve);

The compile function ran through the string building a function whose
execution would be the same a interpreting the string.  Here is more of
the code:

  function rotater(angle, curve) {
       return function (level) {
            curve.angle += angle;
            set_dx_dy(curve);
       };
  }

  function action(fun, curve) {
       return function (level) {
            curve.x += curve.dx;
            curve.y += curve.dy;
            fun(curve.x, curve.y);
       };
  }

  function chooser(cmd, fun, curve) {
       return function (level) {
            if (level < curve.depth)
                 curve.compiled_rules[cmd](level + 1);
            else fun(level);
       };
  }

  /* Make a function that does f1() then f2() */
  function sequence(f1, f2) {
       return function (level) { f1(level); f2(level); };
  }

  function compile(string, curve) {
       var len = string.length;
       var fun = function (level) {}; /* no-op */
       for (var i = len - 1; i >= 0; --i) {
            switch (string[i]) {
                 case '+':
                      fun = sequence(rotater( curve.stepAngle, curve),
                                     fun);
                      break;
                 case '-':
                      fun = sequence(rotater(-curve.stepAngle, curve),
                                     fun);
                      break;
                 case 'F':
                      fun = sequence(chooser(string[i],
                                             action(ctx.lineTo.bind(ctx),
                                                    curve),
                                             curve),
                                     fun);
                      break;
                 case 'f':
                      fun = sequence(chooser(string[i],
                                             action(ctx.moveTo.bind(ctx),
                                                    curve),
                                             curve),
                                     fun);
                      break;
            }
       }
       return fun;
  }

This is more than twice as slow as the plain interpretation version in
my test browser (using your second, more complex, curve example).

It might get a bit faster if there were some way to remove the look-up
of the drawing command in the result of 'chooser'.  The rules are
mutually recursive, so there is no order in which they can be compiled so
that the look-ups can be done in the compile function.  I could not see
a simple way to avoid it.  If I could pass a 'reference' to

  'curve.compiled_rules[string[i]]'

i.e. to the place where the compiled code either has been or will
eventually be put, that would do it, but I don't think that's possible
in ECMAScript.  (I have to put 'reference' in quotes because it's not
the usual meaning of the term i the language.)

This seems very much not the ECMAScript way to do things.  Maybe there
is a way to do this "compiling" using objects and prototypes that is
more true to the spirit of the language.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#21884

On Saturday, November 2, 2013 3:15:25 PM UTC-5, Ben Bacarisse wrote:
> 
> I think the feigned ignorance will be a little odd, but there must be
> lots of people with "I wonder how you'd do this" kind of questions.

One of the problems with the group I think is that many are either afraid to ask question due to the fear of reprisal, or they're experienced enough that there isn't anything that comes to mind to ask.

> A nice idea.  My inner compulsive wants to put the start string into the
> rules under a special "initial rule" name.  If you make it a single
> letter name, then other rules can refer back to the start rule, but I
> don't suppose that will happen much in practice.

Initially I intended to use the common practice in Context Free Languages to have the first rule be the start rule. We know this is unreliable though for object literals.

> I tried to methods.  The first was just to interpret the string and look
> up the non-rotation characters as I went.  The second was to "compile"
> the string into a function so that the main drawing operation became:
> 
>   compile(curve.start, curve)(0);
> 
> and each of the rules was compiled to
> 
>   curve.compiled_rules[rule] = compile(curve.rules[rule], curve);
> 
> The compile function ran through the string building a function whose
> execution would be the same a interpreting the string.  Here is more of
> the code:
> 
>   function rotater(angle, curve) {
>        return function (level) {
>             curve.angle += angle;
>             set_dx_dy(curve);
>        };
>   }
> 
>   function action(fun, curve) {
>        return function (level) {
>             curve.x += curve.dx;
>             curve.y += curve.dy;
>             fun(curve.x, curve.y);
>        };
>   }
> 
>   function chooser(cmd, fun, curve) {
>        return function (level) {
>             if (level < curve.depth)
>                  curve.compiled_rules[cmd](level + 1);
>             else fun(level);
>        };
>   }
> 
>   /* Make a function that does f1() then f2() */
>   function sequence(f1, f2) {
>        return function (level) { f1(level); f2(level); };
>   }
> 
>   function compile(string, curve) {
>        var len = string.length;
>        var fun = function (level) {}; /* no-op */
>        for (var i = len - 1; i >= 0; --i) {
>             switch (string[i]) {
>                  case '+':
>                       fun = sequence(rotater( curve.stepAngle, curve),
>                                      fun);
>                       break;
>                  case '-':
>                       fun = sequence(rotater(-curve.stepAngle, curve),
>                                      fun);
>                       break;
>                  case 'F':
>                       fun = sequence(chooser(string[i],
>                                              action(ctx.lineTo.bind(ctx),
>                                                     curve),
>                                              curve),
>                                      fun);
>                       break;
>                  case 'f':
>                       fun = sequence(chooser(string[i],
>                                              action(ctx.moveTo.bind(ctx),
>                                                     curve),
>                                              curve),
>                                      fun);
>                       break;
>             }
>        }
>        return fun;
>   }
> 
> This is more than twice as slow as the plain interpretation version in
> my test browser (using your second, more complex, curve example).
> 
> It might get a bit faster if there were some way to remove the look-up
> of the drawing command in the result of 'chooser'.  The rules are
> mutually recursive, so there is no order in which they can be compiled so
> that the look-ups can be done in the compile function.  I could not see
> a simple way to avoid it.  If I could pass a 'reference' to
> 
>   'curve.compiled_rules[string[i]]'
> 
> i.e. to the place where the compiled code either has been or will
> eventually be put, that would do it, but I don't think that's possible
> in ECMAScript.  (I have to put 'reference' in quotes because it's not
> the usual meaning of the term i the language.)
> 
> This seems very much not the ECMAScript way to do things.  Maybe there
> is a way to do this "compiling" using objects and prototypes that is
> more true to the spirit of the language.

I enjoyed the new perspective you brought to this, I followed (mostly) an object oriented approach. In the hopes of bringing some clarity, I've uploaded an older version of my implementation:

<https://thenewobjective.com/temp/L-System/>

Primarily:
    p.drawSystem (line 127)
    p.ops (line 153)

On line 138, the following completely expands the initial rule before the drawing:

for(var i = 0; i < depth; ++i)
    str = str.replace(re,replacer)

[toc] | [prev] | [next] | [standalone]

#21891

"Michael Haufe (TNO)" <tno@thenewobjective.com> writes:

> On Saturday, November 2, 2013 3:15:25 PM UTC-5, Ben Bacarisse wrote:
<snip>
>> A nice idea.  My inner compulsive wants to put the start string into the
>> rules under a special "initial rule" name.
<snip>
> Initially I intended to use the common practice in Context Free
> Languages to have the first rule be the start rule. We know this is
> unreliable though for object literals.

Yes, though I did not mean that one should rely on any notion of "first"
rule in the enumeration of a literal.  The initial rule would have a
predetermined name (S or 0 or some such).

<snip>
> I enjoyed the new perspective you brought to this,

I'm glad.

> I followed (mostly)
> an object oriented approach. In the hopes of bringing some clarity,
> I've uploaded an older version of my implementation:
>
> <https://thenewobjective.com/temp/L-System/>
>
> Primarily:
>     p.drawSystem (line 127)
>     p.ops (line 153)
>
> On line 138, the following completely expands the initial rule before
> the drawing:
>
> for(var i = 0; i < depth; ++i)
>     str = str.replace(re,replacer)

For the record, when I said that compiling to closures was more than
twice as slow as direct interpretation, I was comparing it to an
interpretation method that did not expand the string.

As I mentioned in a reply to John Harris, expanding the string is like an
optimising compiler inlining code.  My version recursively interpreted
the string as if the Fs and fs were function calls.  I imagine your
expanded string interpretation would be faster yet.

In a language with lazy lists (like Haskell) one could expand the string
and iterate through it without the full string ever existing.  In a
attempt so simulate that effect, here's another go: keep a stack of
strings and provide a method to generate the characters one at a time:

    p.next = function () {
         while (true) {
              while (this.stack.length > 0 && this.stack[0] == '')
                   this.stack.shift();
              if (this.stack.length == 0)
                   return "";
              var nc = this.stack[0].charAt(0);
              this.stack[0] = this.stack[0].substring(1);
              if (this.rules[nc] != null && this.stack.length <= this.depth)
                   this.stack.unshift(this.rules[nc]);
              else return nc;
         }
    }

After priming by setting the stack to [this.start], repeatedly calling
next() delivers the drawing operations in sequence.

(One could, of course, make a "rule expander" class for this sole
purpose.  It would be created using the start string, the rules and the
required depth, and its next method would be as above.)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#21967

On Sunday, November 3, 2013 8:06:21 PM UTC-6, Ben Bacarisse wrote:
 
> Yes, though I did not mean that one should rely on any notion of "first"
> rule in the enumeration of a literal.  The initial rule would have a
> predetermined name (S or 0 or some such).

I do like the organization better. A reserved symbol that won't/can't appear on the RHS is a good idea.

 
> For the record, when I said that compiling to closures was more than
> twice as slow as direct interpretation, I was comparing it to an
> interpretation method that did not expand the string.

Yes, I understood where you were coming from.

> As I mentioned in a reply to John Harris, expanding the string is like an
> optimising compiler inlining code.  My version recursively interpreted
> the string as if the Fs and fs were function calls.  I imagine your
> expanded string interpretation would be faster yet.

Indeed, and with the tradeoff mentioned and you've recognized

> In a language with lazy lists (like Haskell) one could expand the string
> and iterate through it without the full string ever existing.

I think this would be depend highly on the particular grammar. Left recursion comes to mind.

>  In a attempt so simulate that effect, here's another go: keep a stack of
> strings and provide a method to generate the characters one at a time:
> 
>     p.next = function () {
>          while (true) {
>               while (this.stack.length > 0 && this.stack[0] == '')
>                    this.stack.shift();
>               if (this.stack.length == 0)
>                    return "";
>               var nc = this.stack[0].charAt(0);
>               this.stack[0] = this.stack[0].substring(1);
>               if (this.rules[nc] != null && this.stack.length <= this.depth)
>                    this.stack.unshift(this.rules[nc]);
>               else return nc;
>          }
>     }
> 
> After priming by setting the stack to [this.start], repeatedly calling
> next() delivers the drawing operations in sequence.
> 
> (One could, of course, make a "rule expander" class for this sole
> purpose.  It would be created using the start string, the rules and the
> required depth, and its next method would be as above.)

And there it is...

That's where I am now. Using an explicit stack to track depth + a cursor to track position in the current rule.

I am considering the practicality of using the implicit call stack for this though as the depth on modern implementations is pretty decent in size, or perhaps a trampoline.

It was interesting though, once again your perspective was appreciated.

[toc] | [prev] | [next] | [standalone]

#21969

"Michael Haufe (TNO)" <tno@thenewobjective.com> writes:

> On Sunday, November 3, 2013 8:06:21 PM UTC-6, Ben Bacarisse wrote:
<snip>
>>     p.next = function () {
>>          while (true) {
>>               while (this.stack.length > 0 && this.stack[0] == '')
>>                    this.stack.shift();
>>               if (this.stack.length == 0)
>>                    return "";
>>               var nc = this.stack[0].charAt(0);
>>               this.stack[0] = this.stack[0].substring(1);
>>               if (this.rules[nc] != null && this.stack.length <= this.depth)
>>                    this.stack.unshift(this.rules[nc]);
>>               else return nc;
>>          }
>>     }
<snip>
> That's where I am now. Using an explicit stack to track depth + a
> cursor to track position in the current rule.

Maybe we think alike?  I also tried a "cursor" in order to avoid the
in-place modification of the strings, but I found it made things look
more complicated with no obvious run-time advantage.  I image that most
ECMAScript implementations take care to make string operations fast.

> I am considering the practicality of using the implicit call stack for
> this though as the depth on modern implementations is pretty decent in
> size, or perhaps a trampoline.

If you do, I'd like to see that.

> It was interesting though, once again your perspective was
> appreciated.

Yes, I found it interesting.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#21856 — L-system construction of Lévy C curves (was: Injecting some activity through "questions" (DSLs))

Michael Haufe (TNO) wrote:

> Since there have been complaints about lack of questions and activity in
> the group, I've decided to ask a question once in awhile to hopefully
> spark some more activity. These will probably be questions I already know
> the answer to or something which is in the realm of opinion/style and a
> point of conflict in the JS community in general. On the former kind of
> questions I'll feign ignorance in order to draw out some hopefully useful
> discussions and aspects.

Don’t.  And watch your Subject header fields.

<http://www.catb.org/~esr/faqs/smart-questions.html>

> So if you're willing to play along, here is my first question:
> 
> I have a <canvas/> element upon which I draw shapes and lines. To abstract
> away the dirty details, I've created a small language with which I use to
> draw the desired shapes:
> 
> F: Draw Forward
> f: Move Forward
> [: Push State
> ]: Pop State
> -: Rotate Left
> +: Rotate Right
> 
> An example of usage would be:
> 
> defSystem({
>     name:"Levy C Curve",
>     start: "F",
>     x: 450,
>     y: 300,
>     depth:11,
>     stepSize: 5,
>     angle: Math.PI,
>     stepAngle: Math.PI/4,
>     rules: {
>         "F": "+F--F+"
>     }
> })
> 
> […]
> Currently my program works by initially performing the replacements and
> expanding the drawing commands out as far as necessary before executing
> the final string (which as you've seen, can be quite large).
> 
> How would you approach this problem and prevent the exponential expansion
> of the string while still being able to execute the drawing rules?

I am not sure what you are asking here.  AIUI, the very point of the 
L(indenmayer)-system construction of Lévy C curves and other self-similar 
fractal curves is iterative simultaneous application of production rules. 

String values are probably the most efficient way in ECMAScript 
implementations to represent the resulting turtle graphics operations (with 
String values consisting of 16-bit units, and Number values each being 64 
bit in memory instead; add to that the complexity of substitute Array 
operations), and the Canvas API is a way to draw turtle graphics.

I also see the alternative to represent the resulting operations as a 
trinary number (e.g., “F” ≡ 0, “+” ≡ 1, “−” ≡ 2).  However, producing the 
operations value this way would not only be less time-efficient, but would 
also quickly reach the limit of IEEE-754 integer precision (at 2⁵³ [1]), 
probably allowing for fewer iterations than with a string value.

[1] <news:7523620.37GnReVopu@PointedEars.de>

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#21885 — Re: L-system construction of Lévy C curves (was: Injecting some activity through "questions" (DSLs))

On Saturday, November 2, 2013 3:31:55 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Don’t.

Why not?

>  And watch your Subject header fields.
> 
> <http://www.catb.org/~esr/faqs/smart-questions.html>

I wouldn't have minded the change of subject if you had changed it to one more accurate...
 

> 
> I am not sure what you are asking here.  AIUI, the very point of the 
> L(indenmayer)-system construction of Lévy C curves and other self-similar 
> fractal curves is iterative simultaneous application of production rules. 

The question is how to draw the final rule without generating a string of exponential size before hand:

See: <https://thenewobjective.com/temp/L-System/>

In my initial posting I presented a very small example of the issue:

F
+F--F+
++F--F+--+F--F++
+++F--F+--+F--F++--++F--F+--+F--F+++
++++F--F+--+F--F++--++F--F+--+F--F+++--+++F--F+--+F--F++--++F--F+--+F--F++++ 

[toc] | [prev] | [next] | [standalone]

#21892 — Re: L-system construction of Lévy C curves

Michael Haufe (TNO) wrote:

> On Saturday, November 2, 2013 3:31:55 PM UTC-5, Thomas 'PointedEars' Lahn
> wrote:
>> Don’t.
> 
> Why not?

You are not ready for the answer yet.

>>  And watch your Subject header fields.
>> 
>> <http://www.catb.org/~esr/faqs/smart-questions.html>
> 
> I wouldn't have minded the change of subject if you had changed it to one
> more accurate...

You must be joking.  It is *your* responsibility to post with a proper 
Subject; I have merely attempted to fix your error.

>> I am not sure what you are asking here.  AIUI, the very point of the
>> L(indenmayer)-system construction of Lévy C curves and other self-similar
>> fractal curves is iterative simultaneous application of production rules.
> 
> The question is how to draw the final rule without generating a string of
> exponential size before hand: […]

I have read the question.  It did not and still does not make sense to me.
 
Score adjusted

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#21894 — Re: L-system construction of Lévy C curves

On Sunday, November 3, 2013 8:12:39 PM UTC-6, Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
> > On Saturday, November 2, 2013 3:31:55 PM UTC-5, Thomas 'PointedEars' Lahn
> > wrote:
> >> Don’t.
> > 
> > Why not?
>
> You are not ready for the answer yet.

I'll be the judge of that

> >>  And watch your Subject header fields.
> >> 
> >> <http://www.catb.org/~esr/faqs/smart-questions.html>
> > 
> > I wouldn't have minded the change of subject if you had changed it to one
> > more accurate...
> 
> You must be joking.  It is *your* responsibility to post with a proper 
> Subject; I have merely attempted to fix your error.

On a subject/question you admittedly didn't understand. Measure twice, cut once, or in this case abstain. 

> I have read the question.  It did not and still does not make sense to me.

You are not ready for the answer yet.

> Score adjusted

Back to this old behavior are we? I thought we moved beyond this. See above and you'll see that the "score" is not adjusting in your favor...

[toc] | [prev] | [next] | [standalone]

#21872

On Fri, 1 Nov 2013 21:06:41 -0700 (PDT), "Michael Haufe (TNO)"
<tno@thenewobjective.com> wrote:

>Since there have been complaints about lack of questions and activity in the group, I've decided to ask a question once in awhile to hopefully spark some more activity. These will probably be questions I already know the answer to or something which is in the realm of opinion/style and a point of conflict in the JS community in general. On the former kind of questions I'll feign ignorance in order to draw out some hopefully useful discussions and aspects. So if you're willing to play along, here is my first question:

I see you've been admonished for not having a longer Subject.


>I have a <canvas/> element upon which I draw shapes and lines. To abstract away the dirty details, I've created a small language with which I use to draw the desired shapes:
>
>F: Draw Forward
>f: Move Forward
>[: Push State
>]: Pop State
>-: Rotate Left
>+: Rotate Right

  <snip>
>    rules: {
>        "F": "+F--F+"
>    }

  <snip>
>Currently my program works by initially performing the replacements and expanding the drawing commands out as far as necessary before executing the final string (which as you've seen, can be quite large).
>
>How would you approach this problem and prevent the exponential expansion of the string while still being able to execute the drawing rules?

That explosion problem can be avoided by enhancing your turtle
graphics language to include subroutines, aka functions, and function
calls.

Where F expands into +F--F+ you have an F-call to a function that can
do a further F-call without making a mess of it. Your language has to
have a way of defining functions and to test whether the depth limit
has been reached.

The length of the string is now constant whatever depth is needed. 

But not the time needed to draw the exponentially increasing number of
pixels :-(

  John

[toc] | [prev] | [next] | [standalone]

#21875

John Harris <niam@jghnorth.org.uk.invalid> writes:

> On Fri, 1 Nov 2013 21:06:41 -0700 (PDT), "Michael Haufe (TNO)"
> <tno@thenewobjective.com> wrote:
<snip>
>>    rules: {
>>        "F": "+F--F+"
>>    }
>
>   <snip>
>>Currently my program works by initially performing the replacements
>>and expanding the drawing commands out as far as necessary before
>>executing the final string (which as you've seen, can be quite large).
>>
>>How would you approach this problem and prevent the exponential
>>expansion of the string while still being able to execute the drawing
>>rules?
>
> That explosion problem can be avoided by enhancing your turtle
> graphics language to include subroutines, aka functions, and function
> calls.

Here's an alternate way to look at it: the language already has
subroutines, but the current execution environment (AKA "the program")
aggressively inlines functions.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#21886

On Sunday, November 3, 2013 5:23:35 AM UTC-6, John Harris wrote:
> 
> I see you've been admonished for not having a longer Subject.

Even so, I still do my best to sleep at night... 

> That explosion problem can be avoided by enhancing your turtle
> graphics language to include subroutines, aka functions, and function
> calls.

Hopefully my posted example in other responses would help make the problem clearer and more accessible: <https://thenewobjective.com/temp/L-System/>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web