> Inserts a string slice into this String at a byte position. This is an O(n) operation as it requires copying every element in the buffer.
you can probably draw an l-system graphic of more than a million drawing commands on your screen, let alone a laser cutter or something (in http://canonical.org/~kragen/sw/laserboot/cut-6/ for example i laser-cut a sierpiński triangle with an l-system implemented in postscript) so the problem size starts to get into the range where being accidentally quadratic matters
if i'm not just mistaken, which is possible since i haven't tested it, but i thought it was a likely enough problem to be worth mentioning
— ⁂ —
also where the article says
> The function above can also be written recursively but for larger iterations, you would run out of stack depth way before running out of heap memory.
it is exactly backwards, at least with the straightforward recursive approach; 40 generations would require 40 stack frames occupying perhaps 4096 or 8192 bytes of stack, but for the non-barnsley non-fern given as the first example, produces something more than 18 × 3⁴⁰ = 218837978263024718418 bytes of output, which is sufficiently larger than 8192 that the heap runs out first
(you can of course maintain an explicit stack and write an iterative loop)
— ⁂ —
i hope these corrections and other comments are helpful and not discouraging. keep creating beauty! keep hacking!
this is barnsley's fern https://en.wikipedia.org/wiki/Iterated_function_system#Const...
you can clearly generate barnsley's fern with an l-system but i've never seen it done
otherwise this seems like a nice explanation of l-systems
— ⁂ —
i'm a bit dubious about the implementation strategy because even though i'm not a rustacean this looks like accidentally quadratic code to me
https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/sh... says:> Inserts a string slice into this String at a byte position. This is an O(n) operation as it requires copying every element in the buffer.
you can probably draw an l-system graphic of more than a million drawing commands on your screen, let alone a laser cutter or something (in http://canonical.org/~kragen/sw/laserboot/cut-6/ for example i laser-cut a sierpiński triangle with an l-system implemented in postscript) so the problem size starts to get into the range where being accidentally quadratic matters
if i'm not just mistaken, which is possible since i haven't tested it, but i thought it was a likely enough problem to be worth mentioning
— ⁂ —
also where the article says
> The function above can also be written recursively but for larger iterations, you would run out of stack depth way before running out of heap memory.
it is exactly backwards, at least with the straightforward recursive approach; 40 generations would require 40 stack frames occupying perhaps 4096 or 8192 bytes of stack, but for the non-barnsley non-fern given as the first example, produces something more than 18 × 3⁴⁰ = 218837978263024718418 bytes of output, which is sufficiently larger than 8192 that the heap runs out first
(you can of course maintain an explicit stack and write an iterative loop)
— ⁂ —
i hope these corrections and other comments are helpful and not discouraging. keep creating beauty! keep hacking!