# Fun with Spheres

I’ve been getting the feeling that my random planet generator isn’t finished yet. I’d really have liked to polish it up and make it look really nice, so a couple days ago I set out to fix the most daunting thing, the aliasing near the poles. The issue is basically that some points are too close together while others are too far apart. While this problem isn’t easy to solve mathematically, you can get pretty close by making each point act as a repeller, and then constraining all of them to move along a sphere:

An initial set of 100 random points after it’s settled into stability. It’s pretty even, but the points don’t have the regularity that I’d like them to.

The rectangular projection after it has been repelling for a short while; you can still clearly see the sampled lines. This is already significantly better than before, partly because of the repelling but also partly because I created proper nodes for the two poles. What’s interesting is that if you KEEP letting this run, pretty soon the symmetry of the lines gets broken and a pattern similar to the random points appears.

This one starts with a surface refinement described in http://paulbourke.net/miscellaneous/sphere_cylinder/. You start with an octahedron and then turn each face into four faces by bisecting the edges of the faces and creating new triangles out of the resulting shapes… the URL describes it much better :P This has good spread and regularity, and also has the added bonus of already having calculated the edges that each node is next to (so I don’t have to triangulate it to get a mesh).

Just for funzies, I decided to wrap the whole thing in a GUI and give some options to play with.

Here is one of many ways to achieve awesome:

• Take any image
• Map regions of the image into ASCII characters of equal dimension
• Make sure your font metrics are equivalent to those of Facebook’s
• ???
• PROFIT

It is quite difficult to turn this sketch into an applet since I was using the webcam, but you can see the source code here. Originally I tried matching the font of Processing to be the same as that of Facebook but there’s too many CSS subtleties; in the end I had to write some JS to manually get the char-width of each character. Unfortunately the image starts skewing depending on your browser zoom and whether you have certain fonts installed or not, but there’s nothing to be done about such things.

# Phasors, Appletception, More Expressions, Pack200 is the shit!

A while back I was struck by inspiration from an applet that was shown in my EE20 lecture about phasors. I went about writing my own version of this applet, but combined with the expression parsing powers of Scala. I decided to try some Appletception, putting no less than four PApplets contained within a normal Applet class. This was both a boon and a… uh…. unboon? anti-boon? noob? HA. Let me tell you why: (P.S. I’m also trying this bold important phrases thing that was semi-mostly-completely inspired by coding horror’s blogging style.)

### Good things about embedding PApplets

• Different parts of code live in different methods; the concepts in my mind are reflected accurately in the hierarchy. Instead of having a huge setup/draw method that would do four things at once, I instead have four classes each doing one thing at a time. This keeps the code closer to our mental model, which is what we want.
• Swing’s windowed, focusable event system can be fully taken advantage of! I don’t have to worry about what “region” the mouse is in, or which applet should respond to my key-presses/mouse wheel scrolls, because swing does it for me.
• The positioning of the applets is determined by the layout manager; so I don’t have to. Again, swing does it for me.
• It’ll be simple to extend this sketch to include other swing-y things like easy resizing, or adding a border (which was implemented, to wonderful effect, in four lines).
• It’s multithreaded, so one PApplet may go really slowly (say 5 fps) but the other one will still be at 60 fps. This isn’t necessarily a good thing depending on how you look at it.

• Multithreading bites you in the ass. Each PApplet starts its own thread, and only that thread will run the draw() method correctly, and there’s nothing you can do about it. I was able to keep my issues to a minimum by having only one method that might be called concurrently, and then just synchronizing that method. But it could easily get messy.
• Because they’re not all synchronized, the frames won’t line up. If you drag the Argand diagram quickly, you’ll notice that the plots for the Real and Imaginary parts get very blocky and very NOT function-y. This is because they depend on the state of the camera in the Argand diagram, which changes as they’re asking about it. The fundamental problem is that the rendering of the Real and Imaginary parts is much, much slower than the rendering of the Argand diagram, so one frame in one applet is actually 5-10 frames in the other.
• You have to connect the wires together. I forgot to override and delegate the start, stop, and destroy methods from my outer Applet to all my inner PApplets so my applet would freeze every time I refreshed the page. This isn’t too much overhead but can still bite you.

I wanted to finish this sketch for several weeks but silly, silly things like homework and midterms kept getting in the way, and I really wanted to polish this one up a little bit and make it usable. In particular, I re-wrote my parser library to return an Expr class instead of just a float (this effectively caches the parsed structure), resulting in speedups of ~600x. Drastic but not unexpected, considering the massive, complex machinery that parser combinators are.

I also finally figured out how to use pack200 compression; the resulting applet is down from 472kb to just 102kb, smaller than normal Java Processing applets. Amazing what Proguard + pack200 can do.

See the sketch here.

# Bizarre Love Triangle Explained

Earlier I wrote about issues I have with Tuples and Functions. It was kind of long, rambling and tangential, so I decided to write about some concrete examples of what I’m talking about.

My first example pertains to the FunctionN implementations. For the linear transformation drawer, I tried writing a DSL with some sort of function application syntax that maps to underlying Scala methods (e.g. a Parser for “functionCall(arg0, arg1, … argX)”). I would like to simply write one method that takes any function and gives back a Parser for that function:

```def makeParser(functionX:SomeFunctionType):Parser[FunctionReturnType] = { ... }

val absParser = makeParser(math.abs _)
val powParser = makeParser(math.pow _)
```

What do I put in for SomeFunctionType? Nothing makes sense. Instead, I have to write makeParser1Arg, makeParser2Arg, etc. Code repetition should be avoided – but in this case, there’s no way around it. Even the Scala core library “solves” this problem through code repetition (that is, Scala has a TON of copypasta in FunctionN and TupleN).

As a second example, I wrote a simple grapher for the Lorenz Attractor that plotted each individual coordinate over time. I wanted to show each coordinate in a different color and also laid out below each other:

So I wrote a method that looked like this:

```def draw(color:Int, y:Float, list:Seq[Float]) = {
translate(0, y);
stroke(color);
//handle draw...
}
```

I have a Seq[(Float, Float, Float)] representing the attractor’s states as it progresses through time. I can use unzip3 to get a (Seq[Float], Seq[Float], Seq[Float]) holding each individual coordinate as it progresses through time. Now, I want to call draw three times, passing each Seq as the third argument. I could hard-code it like so:

```//the original seq of the attractor's states
val states:Seq[(Float, Float, Float)] = ...

//Three Seqs of individual coordinates
val coords = states.unzip3;

draw(color(255, 0, 0), 0, coords._1);
draw(color(0, 255, 0), height/3f, coords._2);
draw(color(0, 0, 255), height*2/3f, coords._3);
```

The code repetition is pretty blatant. What if I wanted to draw 10 different lines? What about 100? Instead of explicitly calling draw with different values, I’d like to create two other containers – be them lists, tuples, whatever – holding the corresponding colors and y coordinates to be passed to the draw method.

```val colors = List(color(255, 0, 0), color(0, 255, 0), color(0, 0, 255));
val ys     = List(0f, height/3f, height*2/3f);
```

FunctionN’s have a .tupled method to let you pass a single TupleN to the function, letting you treat the arguments to pass to a Function as one object. All I have to do now is combine the three coords, colors, and ys Seqs into one Seq of Tuple3s, with each Tuple3 holding the corresponding arguments to pass to draw.

```//combine colors, ys, and coords somehow
val args:Seq[(Int, Float, Seq[Float])] = ...

args foreach (draw _).tupled //pass each set of args to the draw method
```

How do I do it? The answer is: very ugily (like, ugly-ly?). At the very least, you have to convert the coords from a Tuple3 of Seq[Float]s into a Seq of Seq[Float]s. There is no pretty way to do this. You can explicitly code it:

```//ewwwww
val coordsList = Seq(coords._1, coords._2, coords._3);
```

Or you can use the productIterator method of Tuple3, and then cast to an iterator of Seq[Float]s:

```//oh my jesus
val coordsList = coords.productIterator.asInstanceOf[Iterator[Seq[Float]]];
```

The first option isn’t extensible (if you want to plot a 5-dimensional attractor you’ll need to go back and explicitly change the code); the second option isn’t type-safe (if coords isn’t actually ALL Seq[Float]s, this won’t even exception until we try to actually explicitly grab one of the elements, at god knows what place).

But lets say we’ve gotten beyond that. Now we want to create the args sequence. We basically want the inverse of unzip3, taking in three seq arguments (one of them can be the caller) and outputting one Seq of Tuple3s. Seq has a “zip” method that does very, very close to what we want; Seq.zip only takes one argument and outputs a Seq of Tuple2s. But it’s not good enough. You can’t chain a zip with another zip, because that still only creates a Tuple2.

```//Seq[(Int, Float)]
val args2 = colors.zip(ys)

//Seq[((Int, Float), Seq[Float])]
val almost = args2.zip(coordsList)
```

Here are some solutions I’ve ended up with:

```//iterate through the index
val args = for(i &lt;- 0 until colors.length) yield (colors(i), ys(i), coordsList(i))

//same thing only slower! wooooo!
val args = colors.zipWithIndex.map { case (c, i) =&gt; (c, ys(i), coordsList(i)) }

//actually not terrible
val args = almost.map{ case ((a, b), c) =&gt; (a, b, c) }
```

# Bizarre Love Triangle

Correct me if I’m wrong (and I’m sure I am), but I’m not sold on the Tuple and Function implementations in Scala. A Tuple is just a typed wrapper around multiple elements, allowing you to treat multiple objects as one object. Their difference with other wrapper/container constructs like List (or Collection in general) is that we know, at compile time, a) the number of elements and b) the type of each element. Functions follow a similar compile-time pattern, since you know the number and type of elements for the function at compile time. Tuples are very useful constructs – for example, you can imagine any n-arity Function as being a 1-arity Function taking a single TupleN argument; this elegance is expressed in Scala’s FunctionX.tupled, overloaded for functions of arity two through five. If you have some Traversable of Tuple2s, you can create a Tuple2 of Traversables holding the corresponding elements of each Tuple2 by simply calling Traversable.unzip. There’s a similar method for Tuple3’s called unzip3.

Unfortunately, design imperfections start to creep in when you try taking advantage of Tuples. None of the TupleNs have any class relation to each other except for all being subclasses of Product. I haven’t explicitly run into this problem yet, but it’s still troubling to think that Scala treats Tuple1._1, Tuple2._1, and Tuple3._1 as completely different properties. Product has a productElement(int) method that returns the nth element of the Product, but the guarantee is so weak that the method a) returns an Any and b) can only throw a runtime exception. productElement breaks both type safety and compile time guards, two of Scala’s stronger selling points. productIterator similarly returns an Iterator[Any]. I’m not sure why productIterator can’t return an iterator of the common supertype of all its elements. None of the FunctionN’s are even related to each other except for AnyRef. The Function object’s tupled, untupled, and uncurried methods have separate, overloaded implementations for Function2, Function3, Function4, and Function5. Function lacks a method returning the number of arguments it takes, which I feel should be easily done without copypasta. I guess the number of arguments is embedded within the Function’s type, but that’s programmatically annoying and unintuitive to access. unzip and unzip3 exist and satisfy most use cases, but it smells (as a consequence of the way Tuples are implemented). Code repetition is to be avoided – but the Scala core library itself contains lots of repetition on this front.

I feel like the problem lies in characterizing the relationship between Tuples of different sizes. We can think of any Tuple2 as a Tuple3 with an “empty” element (perhaps a Tuple3[A, B, Nothing] type or Tuple3[A, B, Unit]); a Tuple3 can also be seen as a Tuple4 with an “empty” element, etc. etc. One could put some upper limit on the Tuple arity (Scala’s already doing this) and have all other Tuples descend from that class, but there will still be a bunch of code boilerplate (create 21 classes, with each TupleN extending Tuple(N+1)), and the performance penalty of carrying a bunch of Units around would be hefty to say the least (perhaps specialization could help us here). Also, is Tuple3[A, Nothing, B] the same “thing” as Tuple3[A, B, Nothing]? I guess it depends on the application and programmer to assign meaning to the elements in the Tuple. If we instead build up, a Tuple3 can be seen as a Tuple2[A, Tuple2[B, C]]; a Tuple4 is a Tuple3[A, Tuple2[B, Tuple2[C, D]], or some similar Tuple nesting scheme, etc. etc. This looks to be a more reasonable approach to building Tuples, and is also the way Lisp and most of FP does it. Scala’s own List class has :: and Nil. The relation between Tuples and Lists is something to be explored. This connection is further complicated when Functions enter the scene, especially with regards to function currying. Naively, I think the problem lies in that there are multiple representations, in code, to achieve roughly the same meaning, and that there are no ways to easily convert from one representation to another. A Function3[A, B, C, R] and a Function1[(A, B, C), R] and a Function3[(A), (B), (C), (R)] and a Function2[(A, B), C, R] could all be the same thing. I don’t even want to get into the different ways you could group smaller Tuples to create a larger one.

# I’m on Github!

I’ve uploaded all of the p5wscala source code onto Github. You can find me at https://github.com/hellochar. The source code for these sketches is at the p5wscala repository, but a lot of the code depends on the other two repositories (Scala-lib and Zhang-Camera-etc). Please let me know if there are any problems with the libraries (and I know there will be). Also, I’ve got a new sketch coming up, so stay tuned!

# Expression Evaluator

I’ve always wanted to have the capability to type in expressions into a sketch and have it react accordingly; to me, it’s kind of always been the “next level” of interactivity with a sketch. I remember a while back there was a sketch, possibly on OpenProcessing (but I can’t find it now) that had a series of about 20 circles rotating about like some sort of solar system, and there was a text field letting you type in an expression as a function of n (presumably the “number” of the circle) which determined the size of the n-th circle. Or something like that. I LOVED that sketch since you could get a massive variety of beautiful interactions by just changing what the expression was.

To be honest I’m very surprised that there isn’t a math/symbolic expression library within the Java standard library. Imagine if there was a standard mathematical input widget within AWT, or Swing, or even controlP5 – great ideas would spring out from all corners of the sketch community. I might even consider creating and maintaining a simple math library to help others along. I personally have always felt a longing for a simple math library for several years. I remember trying to write a symbolic evaluator back in 10th grade of high school – and I got SWAMPED. Of course, I lacked the necessary understanding of both math and programming back then, but I didn’t even get close. I wanted to write programs involving mathematical functions, but the libraries just didn’t exist.

Anyways, enough of the rambles. An arithmetic calculator is the flagship example of Parser Combinators, and I found it enjoyable to extend the “usual” grammar to include variables and functions. I have a feeling that this grammar is going to be heavily used in my future sketches. Sep12 isn’t fancy; it just demonstrates the evaluation capabilities.

See the sketch here.