What's it all about, Alfie?

I was in a meeting, but when I got out, I was greeted by the news from Robinhood that Bitcoin has hit $12,000 - which was the limit price I set on the sell order for my initial buy of Bitcoin. I bought it at about $9,000, and then up it went, and it looked to me to be topping out at about $12,000 - so that's where I put the sell order.

I think I'll wait and see it fall back below $10,000, and then buy it again. It's not like I'm buying a lot of this - just a couple of hundred dollars... not real money at all. But it's fun to chat with an old friend about investing... and this has been really fun to watch - no matter how it turned out.

For now, my plans are pretty simple - just pay enough attention to things to have fun, but don't let it get out of hand. Balance. 🙂

This morning I was just checking over a few Google Docs where I'd made some comments for the author, and wanted to see if there was still a reason to keep the doc(s) open to make it easy to respond to the notes, or resolve them for the author. And I noticed that the author had chosen to use an odd color for the word Draft in the header - Goldenrod. Now I'm not a style snob... but that struck me as an odd color for something that you might want to draw attention to. I mean, the text is black on white, and then there's the obvious red for alarm, and green for good... but what about the non-obvious Draft?

And then it got me thinking about the other really unusual uses of color I've seen at The Shop on documents -- and I"m not talking about spreadsheets - I think those are universally accepted as examples of hideous color combinations... No, these are documents that have had background colors... foreground colors... just amazing combinations, that seem to have no sense as to why they are colored this way.

And it isn't something that I have to correct - it's just something that makes me giggle, and I need to put a face with the color choices, and it's usually someone that is not what I'd call a Creative Professional. It's understandable - they want things to stick out - but with so many things that need to stick out, they have to use colors to classify them. It's just like the line from The Incredibles:

Then when everyone is super, no one will be.
- Syndrome

But that doesn't stop some folks from making the most creative color pairings I think I've seen. It's just something I find funny about people... we're all different, and we all bring our own background to everything we do. 🙂

Well... this morning the year is half over, and I find it hard to believe. It's nice to see that Summer has arrived... the sun is out, the temps are in the 90s... the year has really left Spring behind. It's going to be a while before the leaves fall... there's a lot of yard work to do this summer, and it's going to be a nice summer.

Yet today really has crept up on me. It was quite something to look back and think how much has really happened this year. A daughter graduated college... I made it to a year at The Shop... things are settling down. Life moves on.

It's important to try to make a note of these passages of time.

This morning I finally downloaded the Robinhood app, and funded my account, and put in an order for AAPL, and a little Bitcoin. What brought this all out is a couple of things:

1. I interviewed with Robinhood - it was a few years ago, and it was with one of the Google's Founders brothers, which I thought was interesting, but it is a sound business model for retail trading, and I really liked the guys I talked to. It would have required relocation, and that was a problem for me at the time.
2. I have wanted to own AAPL stock for a while - and while I was in Finance, that wasn't possible, and then the divorce, etc. and it really hasn't been reasonable to get into the market until very recently. Sure, I've been doing ETFs and the like for my retirement, and that has gone very well indeed, but not straight-up retail trades.
3. I have wanted to have a little Bitcoin - I don't think this is anything more than a fancy, but I like the idea of a digital currency that's traded based on some idea of value... but I'm not really sure that Bitcoin or Facebook's Libra is going to really replace dollars.

What I found was a beautiful UI for the Robinhood app. And the ability to use 2FA and/or Face ID, I think it's just fantastic. I don't mind 2FA, but I prefer to be able to use the better (less friction) Face ID, and I think the new "Sign in with Apple" should go a long way to making this a preferred way to get the job done in more places.

Also, making it possible on a MacBook Pro wouldn't hurt. 🙂

So now, I can have a little fun with investing. Nothing I can't afford to loose, that's for sure... but it's not about the win/loss, it's about the participation in the Markets. For so long, I was working in them, and I'd like to again, but then I couldn't do this... so it's a trade-off, and if I can't work in them, at least I can participate in them. 🙂

This morning I was looking for a little something in the Potentials code, and looked at the following code:

  x = MAX( MAX(_values[r+1][c], _values[r+1][c+1]),
           MAX(_values[r][c], _values[r][c+1]) );

And while it wasn't bad code, the MAX function will execute each argument, and then the winner will be executed again. So while the inner MAX implementations were not really doing any extra work, the outer MAX is causing each of them to be doing more work than necessary.

If we switched from that to the C function fmax:

  x = fmax(fmax(_values[r+1][c], _values[r+1][c+1]),
           fmax(_values[r][c], _values[r][c+1]));

we now know that the inner calls will be executed once, and then the outer is now working with doubles as opposed to macro expansions, and that will make things a little faster - without compromising the readability of the code.

For the traditional test case, the original code reported:

2019-06-19 ...-0500 Potentials[...] [ResultsView -drawRect:] - plot drawn in 18.533 msec

and with the fmax, the results were:

2019-06-19 ...-0500 Potentials[...] [ResultsView -drawRect:] - plot drawn in 16.382 msec

which was a repeatable difference. Now this isn't huge, but it's more than a 10% drop in the execution, so it's not trivial, and more to the point - the redundancy was just unnecessary. Good enough.

For the last several days, I have been noodling on a problem with Potentials that hasn't been the top thing to do - until today. And I wanted to figure this out once and for all, and get things really lined up properly. The problem starts with the simulation grid. It's an nxm grid, where the solution will be calculated on each of the grid points - exactly. It's then up to me to visually represent that as best I can.

The initial code took each of these points and created a rectangle for each on the viewport of the NSView, and then selected the best color, and filled in that rectangle. So far, so good.

But then the contour lines required that we take groups of 4 points and (possibly) draw a line in the box they defined. Now we have a problem. As you look at the box for a contour line, it will be "colored" by the node value in the lower-left corner. Not ideal. This means that there would be a row, and a column, of rectangles that represent the edge nodes of the simulation - but no way to put contour lines in those boxes.

The solution was to treat the rectangle fill the same way as the contour lines - to take all four points in each square and compute a single value for the painting that rectangle. For a first cut, it seemed reasonable to have a simple MAX() function of all four values - yes, this will inflate the effect of an isolated node, but that's OK... it's the maximum value - in that area. I can live with that.

The results are really nice. The contour lines and the items under simulation and colors line up very nicely. This is a blown up section around the point conductor in the example:

At the same time, the contour lines now go to the edge of the display, as they should, and if I need to change the algorithm for the colorization of the rectangles - based on the four point values - that's easy enough to change.

Looking better and better. 🙂

Today I noticed that the display code for Potentials was filling the display viewport - and distorting the shapes in the simulation. For example, a "square" could be made to look like a long rectangle, simply by resizing the window. This wasn't right. So today I spent a little time to fix this.

The code wasn't that hard, and to save a little time, I computed the drawing "origin" as well as the scale factor for the drawing to the NSView so that each part of the drawing didn't have to recompute these. Nothing fancy - just scale to the one dimension that will fit in the viewport, and then fix that, adjust everything else.

At this point, you can see the added white "letter boxing" on the window as we have respected the ratio of the workspace, and the drawing is being constrained in the vertical dimension. Simple, but very nice.

Little by little, it's getting better. 🙂

This morning, I was taking another crack at increasing the performance of the graphing in Potentials, as my initial tests of just draw red seemed to show that I could cut a significant amount of time off the drawing, if I didn't have to allocate all those NSColor objects. Seemed like a reasonable thing to try, and after all... performance tuning can be fun.

So it's not like the CGColor or NSColor would allow me to directly access the values of red, green, and blue - so I had to move them from the NSColor instance into a simple array of CGFloat values. No big deal - now I'm passing around a simple, fixed-size array that is easily indexed, and because I can make them on the stack, there's no way these are leaking.

Then I needed to peel back the existing methods on ResultsView and make it so that they allowed for passing in, and returning, arrays of CGFloat values. Again, this is a simple refactoring, as I could then simply use these new methods within the existing methods, and I didn't loose any capabilities of using NSColor arguments. Still good.

Finally, I was then able to update the drawing method and have it convert the input colors to linear space, and arrays of CGFloat values, and then run the same processing on these arrays of CGFloats, and we had what we'd hoped for.

Almost.

What I saw was that there was 2 msec difference - out of 17+ msec - that this changed. Nothing. So I backed out the changes, and realized that I had a new respect for the macOS developers - they have really tuned this machine to make the AppKit/Foundation way of doing things about as fast as humanly possible - and the difference with just plotting red was that of a single color versus a range. This was the case all along, and I was mistakenly thinking that I was seeing some effect that wasn't really there.

So it's not faster... but I am wiser about the inner workings of macOS and drawing, and I'll be sure to remember this in the future. 🙂

Today at lunch, I was scanning the class notes on the Contour Lines I'd used in Potentials, and I was thinking that their solution of sub-dividing the grid ever smaller - until you get to the resolution of the display was nice, but that there was a better way - analog. Meaning, to ratio the value of the contour, and the relative values of the grid points. My notes were pretty simple:

And when we look at the previous work, it's clear where the nodes are, as it's crude, and not very smooth at all. But when we take the values from the data and then test them:

  // grab the four corner values from the data
  vul = _values[r+1][c];
  vur = _values[r+1][c+1];
  vll = _values[r][c];
  vlr = _values[r][c+1];
  // now compute the in/out state of the four corners
  ul = (vul < value);
  ur = (vur < value);
  ll = (vll < value);
  lr = (vlr < value);

then the code for the individual line segments of the contour are simply:

  // line from left to top
  sy = (value - vll)/(vul - vll);
  pbeg = NSMakePoint(x, y+dy*sy);
  sx = (value - vul)/(vur - vul);
  pend = NSMakePoint(x+dx*sx, y+dy);

where the effect of sx and sy are to modify the value from 0.5 in the previous version, which is half-way between nodes, to that percentage represented by the values of the nodes, and the contour. This makes a huge difference:

And it's just amazing how much nicer it looks. The code isn't doing anything that complex - it's just doing the work a little smarter... and that is just elegant.

Today I spent some time refactoring the [ResultsView -drawRect:] method in Potentials as it was a monster method with all kinds of access to ivars, and lots of code - and it really needed to have setters and getters, and the code needed to be broken up so that it was a lot easier to manipulate and compose. That wasn't too bad. Then it was time to look at the Contour Lines.

I ran across this slide deck for a class from the University of Edinburgh on this exact subject. Turns out it was a lot simpler than I had thought. By simply using the gridding I'd used for the solution, it was possible to think of the contours as separators and not just lines of "constant value" - because then it comes down to 16 different patterns where the state of each node value with respect to a threshold is concerned.

Then it was a simple task of drawing the lines, and boom! Done!

Sure... there's a lot I can do to make this nicer - reduce the gird size... go non-uniform mesh and refine the mesh based on the magnitude of the electric field, and at less than 10 msec per solution set, I could easily refine this 5 or 6 times and come up with something really pretty nice.

But Wow... this has been something I've wanted for years... and now it's checked-in, and it runs faster than I ever would have imagined. Life is good. 🙂