Talk:SELECT.

It would be pretty cool if this language's author would come back and include in the spec the preferred method of selecting branch cuts. I should think 'the first one in the natural order-by-argument' is the most likely candidate, but the issue isn't even raised! --Quintopia (talk) 08:06, 11 November 2013 (UTC)

Another issue: the spec does not specify how one should go about choosing a "random positive real number" k to fill the array with. If I had my druthers, I'd scrap the "random" part and fill the array with e, but if it must be random then we must have a way of choosing such a number. The use of the random number in the spec indicates that the author intends that k≠1, so it would seem that the easiest way to ensure this would be to pick a number in (1,∞). In this range, it would seem apropos, given the idea behind the language, to choose according to an exponential distribution. For instance, pick i with probability p_i = e^(1-x). --Quintopia (talk) 19:31, 13 November 2013 (UTC)

Also, I have half a mind to implement this language (using the principal branch cuts) just to write Mandelbrot in it. It is already the ideal language for drawing the set itself. But it ain't enough to draw the set, as every good mandelbrot set drawer also colors the area around the set according to speed of divergence. As specified, this language does not permit colors, which seems a travesty. I would implement the following additional instruction:

COLOR.   Sets the current output color according to the current cell using the conversion:
         Red-value := |Re(x)|/256
         Green-value := |Re(x)|%256
         Blue-value := |Im(x)|%256

--Quintopia (talk) 04:10, 13 November 2013 (UTC)

Highly probable random problem

I see a possible problem in the random initialization here: If the cells you are using have been initialized to 1, none of the algorithms for getting other useful numbers will work... --Ørjan (talk) 20:00, 19 November 2013 (UTC)

Perhaps you could specify that they are always greater than one, or else simplify it and always use the base of natural logarithms (e) as the initial value of all cells rather than random. --Zzo38 (talk) 05:50, 23 November 2013 (UTC)

You'll notice that I made both of these points in my second comment above. In my implementation, I chose to choose uniformly from the range [1,1.0000001]. I haven't bothered to add a "reselect if 1 is chosen" branch, because so far, Python has never picked 1. (I'm not even sure it can...) In addition, I added a command line argument "v=" to let users select a number themselves.--Quintopia (talk) 07:39, 23 November 2013 (UTC)