The Finance variables definitely speed things up, except they can't be used as the var for a For( loop on CE's for some reason. (Or, at least, they can't be used as the var for a For( loop on my CE without a SYNTAX error...)

[recursiven] isn't a finance variable.

Oh yeah.... Wrong "n"... (quietly steps out of room)

Why are there so many n's!?

The complex number–based algorithm for the Barnsley fern is fairly well suited to code golf in TI-BASIC. Here's an implementation in 156 bytes.


Code:


Note that the part that calculates the next point's coordinates is a one-liner. Here is that line, degolfed and commentated:


Code:


I'm fairly sure 140 bytes is possible; there are places to cut down both the initialization and data decompression. Going much lower than that may require calculating the magic numbers with brute force, which may be computationally infeasible.

Looks pretty good!



Though you could save a byte via:

Code:

Slower, as you have mentioned, but a byte is a byte...

That byte is definitely worth it; I forgot to take it out after testing. So the total is 155 now.

Currently writing better Python code for checking and brute-forcing.

The window you set up for the graph turns out to be pretty square, so you can do:


Code:


to bring it down to 154. The Ymax becomes just larger than .32

Code:


136 bytes; window is a bit smaller but the fern is still clearly visible.

EDIT: 125 bytes.


Code:


EDIT: 124 bytes; saved a byte with 10^(~22+3max(4,int(.07^^-1(rand-.5

After a day of work, I finally succeeded at brute-forcing the coefficients, saving another 4 bytes to bring the total to 120. Values in the list are 8-9 digits each and give the Barnsley fern coefficients within a tolerance of 0.006. I thought I'd have to brute-force the real and imaginary parts together (10^18 integers to check), but they can be done separately, so the search is only 10^9 values each and takes only a few minutes.

The exact byte count is heavily dependent on accuracy of the coefficients. Halving the tolerance adds 5 log_10(16) ~= 6 extra bytes and 16x more computing time, and conversely allowing twice the tolerance reduces the byte count by 6 and computing time by 16x. It may seem strange that I changed 2 to 1.3, but this adds an expected 50% precision for 2 bytes, a relative bargain.

List of difficulties / setbacks:

* Brute-forcing was unbearably slow in Python, so I had to rewrite it in C++
* I had C++ set up wrong on my machine, so used repl.it until I found the problem
* Using cosh( at the end instead of ln( worked fine in double precision, but resulted in rounding errors at 14-digit precision on the actual calculator
* Lost several hours on a dead end trying to shorten 1+[i]-1.3fPart(
* Lost a couple of hours on another dead end trying to use base 200


Code:


It's possible to be lucky and find 8-digit coefficients that work at tolerance 0.006. Therefore, changing some free parameters in this solution could shorten this by 2-5 bytes. The byte count can probably theoretically be reduced further by changing 1+[i]-1.3fPart( to something involving e^(, but without a clever technique that would require the full 10^18 operations (tens to thousands of CPU-years).

Edit: I have an idea to save 3-5 more bytes...
Edit: 120 -> 117

Edit: 117-> 116 using a more straightforward method. Coefficients are exact again!


Code:


Edit: 116 -> 103, rearranged coefficients and changed basis from real(Ans),imag(Ans) to Ans,real(Ans)


Code:

I found this cool platform called Dwitter, where you write JavaScript demos in 140 characters or less. I made Barnsley's fern in it (slow, but only because Dwitter runs iterations at 60FPS).

(This is not a live demo, but this is a small gif. Click on it to direct yourself to the dweet!)



The code behind it (which is compressed to fit on the dweet itself):

Code: