Paradise ponders, walks and drives edition...

Paradise ponders, walks and drives edition...  Yesterday afternoon I took Mako (our giant field spaniel puppy) for a walk up my usual route, 1.5 miles round trip.  It was an absolutely gorgeous day, as you can see in the photos below.  Spring is springing, and green is popping out all over.  I tied Mako to a fence post to take these photos, and as you can see in the first photo he had himself all wrapped up within seconds!

Mako had an adventure on this walk that neither of us expected.  He behaves a lot like Mo'i used to, snuffling along through the grasses in search of something he can eat (a vole or mouse, perhaps).  Yesterday he came across a hole about 8" in diameter, hidden in the grass.  Before I knew what was happening, he had his head in it right down to his shoulders.  A second or so later he came flying backwards out of the hole, followed quickly by a spittin' mad groundhog.  That old ground hog charged Mako fearlessly, and looked damned effective with his teeth and claws.  Mako tumbled backwards and out of range, then promptly pooped. :)  When we continued our walk, he gave that groundhog hole very wide berth!

I saw two other interesting animals on our walk: a white-tailed kite and a very grey red fox.  Those kites are beautiful birds that were quite common where we used to live in California.  This is the first one I've seen here.  It hovered for five minutes or so in a few locations nearly straight overhead, so I had some excellent viewing.  The fox we've seen before; apparently these fields are well within its territory.  Cover is scarce right now, with the alfalfa just barely emerging, so the chances of spotting the fox now are much higher.  Mako never saw either animal. :)

When I got back from the walk, Debbie and I took a drive out toward Hardware Ranch, and then a few miles up Ant Flats Road.  We took the Tesla, and the bumpy Ant Flats Road was a challenge for her because of the pain in her knee's incision.  We probably won't do that again for a few weeks, until she's feeling better.  But ... we did see some animals, especially birds: a golden eagle, Sandhill cranes, blue herons, a pheasant, and lots of deer.  The right-hand fork of Blacksmith Fork River was running at around 8x normal volume, so the waterfalls along the way were really pretty (photos below).

The first photo is of a man-made water feature in the front yard of the cabin on Miller's Ranch.  They get to look at this out their windows.  The other photos are two angles of the same natural falls, just a mile or so from Hardware Ranch along Ant Flats Road.  We've been by this dozens of times, so we're very familiar with its normal flow – a small fraction of what you see here.

Chicken pot pie...

Chicken pot pie...  This was our Easter dinner, mostly made by me but with a spicing assist from Debbie.  We've made this recipe several times before, and we've experimented with some modifications.  This time we added mushrooms and celery, used rotisserie chicken (from Macey's) instead of sauteed chicken, fresh carrots instead of frozen, and frozen peas and corn instead of mixed veggies.  We kept throwing everything that sounded good to us into the pot. :)  Then Debbie got going on the spices, and as far as I could tell she dumped about 30 kinds of spices into the mix, all in enormous quantities.  I have no idea what they were.  Seriously.  So the chance of accurate replication is pretty small.

These deviations from the recipe had another result as well: we ended up with twice as much filling as we were supposed to.  I ended up vacuum-bagging (for freezing) half the filling, and baking the rest with the puff pastry top.  When it was done, we tucked into it with enthusiasm and managed to put away about 1/3 of that pan.  Debbie actually had more than I did!  I took about half the rest and put it in a refrigerator container.  The remainder is now in two more vacuum-bags, waiting to cool down before I vacuum them and toss them in the freezer.  We have much (yummy!) chicken pot pie in our future!

While I was cooking this, I had to add quite a bit of broth and cream to get enough liquid (because we added so much good stuff).  The sauce is thickened with a roux, and I hadn't changed that from the recipe.  That meant the sauce was way too thin, so I whipped up some more butter-and-flour roux in a little frying pan.  That worked great – when I threw that roux in, the sauce thickened right up.  I like the flavor and texture of a roux way better than cornstarch, so I was glad I did it that way...

How about scaled integers for monetary amounts?

How about scaled integers for monetary amounts?  A friend recently wondered why I wouldn't simply use scaled integers for monetary amounts.  For instance, if I determined that all I needed was 10 significant integer digits, plus 4 decimal places, then I could exactly represent any decimal value within that range by multiplying it times 10,000 and using the resulting integer.  For example, I could represent 382.03 as 3,820,300.  When it came time to present that number to a human, I'd just divide by 10,000.

Scaled integers work particularly well for addition and subtraction, and for many financial applications that's the bulk of what they do.  Consider this addition example, unscaled on the left and scaled by 10,000 on the right:

    773.32     7733200
     27.99      279900
    ------     -------
    801.31     8013100
  

Multiplies aren't quite as lovely, though. The scale factor gets multiplied along with the actual number, so you get a result that has to be divided by the scale factor to get a correctly scaled result. Example:

      4.45          44500
      6.02          60200
    ------     ----------
    26.789     2678900000 rescaled to 267890   

And then there's division, where the scale factor essentially is canceled out – requiring you to multiply the result by the scale factor to re-scale it.

    773.32     7733200
     27.99      279900
    ------     -------
     27.63       27.63 rescaled to 276300 (results are rounded)
 
If these numbers at our desired precision all fit into a native integer type, this would be a bit unwieldy, a little less performant than native, but workable.  In an earlier post I figured that we needed a range that encompassed at least 30 decimal digits just to represent amounts of money.  The binary equivalent of 30 decimal digits is about 100 bits.  The largest native integer in Java (the long) has 63 significant bits – not even close.

Well, what if we used two longs?  That would give us 126 significant bits – plenty of room.  Addition and subtraction are still simple with this scheme.  Multiplication is a bit harder, but still workable.  Division is a bear, though, and substantially slower than a native implementation.  Those aren't necessarily deal-killers, just a consideration.  A similar issue arises from the fact that with this scheme it takes 16 bytes to store any number.  That's expensive in database, mass storage, network transmission, and CPU cache (for any application that uses lots of values, i.e. most of them).  But still not necessarily a deal killer.

But, as my mother-in-law would say, there's a worser problem with scaled integers.  It derives from the fact that you don't just represent monetary values in an application – you also do math with them.  I've used the simple example of multiplying price times quantity to get extended price, but many financial applications do much more than such simple math.

Just to pick one example out of my checkered past: I once was charged with building applications that modeled the performance of complex bonds (that is, those with fancy terms in them, not just simple interest), over wide ranges of multiple environmental variables (LIBOR rate, inflation rate, etc.) in combination with each other.  These models had multi-dimensional tables with millions of entries, each of which contained a calculated probable value.  In some of the models I built, these values could be as small as 10^-10, with around 8 significant digits.  That's not something exotic and unusual, either – it's a perfectly normal sort of financial application.

Here's the real point, though: financial applications need to do math with money, and we really can't predict what the range of numbers they'll need will be.  This point has been driven home for me by a number of bad experiences out in that pesky real world.  Every application I've ever worked on that used fixed point numeric representation (which scaled integers are an example of) has run into problems with the range of numbers they could represent.  The failure modes can be very bad, too – especially if the fixed point implementations aren't good at catching overflows (and many of them don't even try, because of the performance penalty). 

This hard stop on the range of numeric values held is the real deal-killer for me with fixed point representations.  The performance and size issues just make it a little bit worse.  In my opinion, fixed point representation and manipulation of monetary values is a dangerous source of fragility in financial applications.  Further, it's one that is very difficult to repair – once the decision to use a particular fixed point representation is made, that decision creates tendrils of dependency that find their way into every nook and cranny of the application.

So how do you avoid this?  There's a good solution, but it comes with its own costs: decimal floating point.  That will be the subject of a few more posts...

Paradise ponders, recoveries, flowers, stairs, and risers edition...

Paradise ponders, recoveries, flowers, stairs, and risers edition...  Debbie had a milestone day yesterday for her post-surgery recovery.  Her bandages came off in the morning (she couldn't do it – got queasy – so I did it for her :).  Then she took a shower; oh, so good.  Then she got down the stairs to our basement cattery to see her babies.  Then we had a steak dinner.  Then we went up to Aggie's Creamery and got ice cream cones.  A great day for her!  But she was tired for some reason after all that.  :)

We've got a few flowers in our yard.  The daffodils have started to bloom, and then the ground cover (at right) we have in several places is also out.  After all the destruction of our yard last year (and continuing this year), I'm amazed anything at all has survived.  The sweet peas are starting to come up, too – probably another two or three weeks and they'll be a big burst of color to the west of our house...

Yesterday I completed the installation of the stairs I built into our sun room (photos below).  All my careful measuring paid off: the stairs fit perfectly on the first try.  The landing is level with our bedroom floor, as intended, and the little “lip” I machined out fit over the door sill exactly as intended.  I'm very pleased with the way the finish blends with our tile floor, too.  Next step: some more careful measurements for the rail (it will be on the left side).  Once I make those, I'll send them off to the folks at Lazy K Wrought Iron to get a rail made.  At that point our sun room will (finally!) be complete.  We'll make another road trip up there to get them!

Mark T., Dave, and Dave's three sons were here all day yesterday installing 6" diameter irrigation pipe to move the line of risers that used to be in the middle of our back yard to just outside the fence.  The new line of risers (visible if you embiggen the photo at right) is a couple of feet onto the property of our friend and neighbor Tim D.  Once my sprinklers are installed (that's the next thing Mark T. will be working on), I won't need them at all – but Tim will, to irrigate the 2.5 acre field to the left (north) in the photo.  It's a big chunk of work to move all that, and Mark and his helpers did a really nice job of it.  The only bit they have left is the easy part: gluing the risers in place onto those vertical 3" pipes.  Then it's on to the sprinklers in our yard! 

A slightly subtle issue with binary representations of money...

A slightly subtle issue with binary representations of money...  This is an issue that I ran into a few times on a stock trading application that initially used double precision floating point to represent monetary values.

Consider the fractional value (in base ten) 11/16.  In exact radix form, that's 0.6875.  Rounded to one decimal digit, that would be 0.7; to two digits 0.69, and to three digits either 0.687 or 0.688 (depending on the rounding rules you choose).  That's the way we usually think of numbers; hopefully you find none of that surprising.

But now look at what happens in binary representations of the same number.  The fractional form is 1011/10000 and the radix form is 0.1011.  If you round that form to three bits (roughly equivalent to one decimal digit), you get 0.110 (or possibly 0.101 with different rounding rules).  When you convert that value to decimal for presentation to one of those pesky humans, you get ... 0.75 (or possibly 0.625).

Oops.

There's nothing actually wrong with the way binary is rounding, it's just (very) unexpected to the average person looking at a rounded monetary value.  The “expected” value of 0.7 for single digit rounding is (in binary) 0.10110011001100...  There's simply no way to round in binary and get a result like that!

This rounding problem crops up most often when doing division operations.  In those stock trading applications, we kept getting it in two places: stock quotes in fractional values (still common in some exchanges, though thankfully not in the U.S.), and when calculating average price for a series of related trades.  The latter problem caused us much grief when the system on the other end represented money using decimal numbers – our average price calculation would give a different result than theirs, we'd get a mismatch, and a human would have to intervene to figure it all out.  That human was not a programmer, so from their point of view our binary rounding was simply wrong.  We never really fixed this problem until we switched to decimal representation...

Paradise ponders, less controlled chaos edition...

Paradise ponders, less controlled chaos edition...  Well, yesterday our furnace guys were here and worked all day long on fixing our furnace issues.  As always, there were about a bazillion little decisions that needed to be made (by me!) along the way.  On the other hand, they got nearly everything done.  The furnace now sits almost two feet higher off the ground than it used to, and underneath it is a ginormous filter.  The goal there was to reduce the resistance of air entering the furnace.  On that same note, they added two new return grills and enlarged two others, approximately tripling the square inches of return grills in our house.  The difference is very obvious down in our basement “mechanical room” (where the furnace is located): the return air duct is rattling and flexing in response to the much higher volume of air now traveling through it.  The guys also installed a large new vent (where the hot air comes out) in the cattery, and the warm air floods out of there in a way that delights the inhabitants.

That's the good furnace news.  Here's the not-so-good: all of this work was done to cure a problem our furnace had.  It cycled on-and-off every few minutes, as the plenum above the burners overheated.  The diagnosis for this problem was insufficient air flow through the furnace, which made good sense to me.  Also, we eliminated all the other causes any of us could think of.  I'm sure you've guessed by now that the furnace is still cycling.  Sigh.  They'll attack it again on Monday.  I don't really feel badly about this, though, as all of these changes are going to improve the heating in the house anyway.  But sigh nonetheless...

The heater guys were here until after 6 pm, so after they left I started my evening chores and was contemplating going to bed.  But just then the lawn sprinkler guys showed up, with a fifth-wheel trailer full of 6" irrigation pipe.  And they went right to work to install it.  I had been expecting them all day, but apparently there was something wrong with their trailer that took nearly all day to fix.  They're supposed to be here again today to finish installing the new risers.  That will make my friend and neighbor Tim D. a happy guy...

Monetary values in computer programs...

Monetary values in computer programs...  Many programmers who first encounter the problem of representing a monetary value in a program don't immediately see much of a challenge.  At first blush, it seem simple to represent a monetary value: all you need is a number plus a way to identify the currency.  Right?

Wrong.

The currency identification really is easy.  There's a widely accepted standard (ISO 4217) that specifies a three-character code for every currency in the world.  It's used in every multi-currency application I've seen in the past 15 years or so.  For instance, United States dollars have the code “USD”.  But the amount of that currency isn't just a simple number.

The first little complication is that monetary amounts aren't always integers.  You might have $5 (a nice integer value), but you might also have $5.27.  Different currencies around the world conventionally have anything from 0 to 4 decimal places for a “usual” amount of money – but they will occasionally have even more.  For instance, the price in USD for a gram of gold is often specified with three or even four decimal places, like $40.625.  Other commodities or financial instruments may have even more decimal places.  At a job I had in the early 2000s I ran into a case where prices in USD were specified to seven decimal places (that's 1/100,000th of a cent!).  The takeaway here is that the number of decimal places needed isn't infinite, but it's also not as small as you might think.  I'd feel pretty safe with 8 decimal places for USD, or 10 for any currency...

The next complication is that monetary amounts can be quite large.  Corporations these days deal with amounts as large as 100s of billions USD, or 12 digits of integer value.  For some currencies you might need to add 4 more digits.  For government systems, you'll need even more – 100s of trillions USD today.  That's 15 digits of integer value, or up to 19 in other currencies.

For presentation to people, most applications will round huge values to the nearest thousand, million, or billion.  I haven't seen rounding to the nearest trillion USD, but I won't be surprised if it happens. :)  However, internally every financial application I've ever seen keeps track of every last digit.  For USD, that means you'd need a total of 17 significant digits to represent government-scale values.  Knowing that government will only get ever more bloated, adding a “pad” of 3 or 4 digits is probably a minimum requirement – so at least 20 or 21 significant digits, maybe a few more if you want to sleep better at night.

An aside here: I once worked on a stock trading application that was USD only, and had 10 significant digits (including cents).  That meant the biggest value it could represent was $99,999,999.99.  Surely that should have been safe for stock trades, right?  Well, it wasn't, as they found out in a spectacular fashion one day.  A trader placed a buy order for a blue-chip stock where the total value of the order was about $400 million.  A very nice order, indeed!  But a price that big couldn't be represented in the system.  Worse, the program didn't detect the overflow, and instead returned a nonsense value for the calculation (number of shares times price per share) – and that nonsense value was only a few thousand dollars!  The order was transmitted to the market correctly, and actually was executed – but the accounting for it was totally messed up.  It took several engineers several days to analyze the logs for each of the thousands of small trades that made up the big order, so that we could get the customer's books in order.  The company ended up making that trade for free to get back in the good graces of its customer.  The CEO told us to fix that problem, and pronto.  Of course he thought the fix would be trivial – just change a couple lines of code and it would all be fixed.  It was actually very far from trivial to fix that problem after the fact.  The assumption about number of significant digits turns out to have been subtly and broadly spread throughout the entire application.  We were fixing related bugs a year later...

Another complication is specific to representing fractional values.  If you've digested the challenges above, you may be saying to yourself “Floating point!  Use floating point!”  For any mainstream programming language I'm aware of, that means floating point compliant with IEEE-754.  More specifically, it means the binary32 (“single precision”) or binary64 (“double precision”) variants of IEEE-754, which are the ones implemented in most hardware floating point units and in most programming language libraries.  As the variant names imply, they are implemented in binary.  The bits to the right of the decimal point have values of 1/2, 1/4, 1/8, and so on (instead of the 1/10, 1/100, 1/1000, and so on we're used to with decimal representations).  There is a consequence to this choice of binary vs. decimal base that many programmers are not aware of, and it's a consequence of special import when representing money.  It's worth taking some time to understand.

First a brief refresher.  In any numeric base, a fraction in radix form is equivalent to a fractional form.  For instance, in decimal 0.446 is equivalent to 446/1000.  Similarly, in binary 0.11011 is equivalent to 11011/100000.  Here's the part that may come as a surprise to you: in any given base, fractional values can only be represented precisely in radix form if the denominator of the fraction is a power of the base or of factors of the base.  That's a mouthful, so here are some examples to make it clearer:

• 382/625 base 10 is 0.6112 exactly, because 625 is 5^4, and 5 is a factor of 10.
• 101/1000 base 2 is 0.101 exactly, because 1000 is 2^4.
• 1/3 base 10 is 0.333..., because 3 is not 10 or a factor of 10.
• 1/1010 base 2 is 0.0001100110011... because 1010 (10 base 10) is not 2 or a factor of 2.

That last bullet shows something that has startled many a programmer: the native floating point types in most programming languages cannot exactly represent a value like 5.10.  It's not that it's hard, or that you have to use a special trick – it simply cannot be done.  Period.  End of story.  No rounding tricks will fix it.  It is not possible.  I know this is hard for many engineers to accept, because I have watched dozens and dozens of engineers try to absorb this simple fact when I showed them.  Some of them spent hours trying to prove me wrong.  Unfortunately for them, that's like trying to prove that the earth is flat, or that celebrities make good role models.  Nope.  This is one of those damned awkward stone-cold facts.

To illustrate how much of a problem this is, consider all the numbers between 0.00 and 0.01 in increments of 0.01 (base 10).  Here's a complete list of those that can be exactly represented in binary floating point: 0.00, 0.25, 0.50, 0.75.  Yup, that's it – just four of the one hundred possible numbers.  All the rest are approximations.  And approximations ain't too good for representing monetary values.  If I have $5.42, I want $5.42, not $5.419999997!

By the way, I've been assuming in here that monetary values are all expressed in base 10.  That's not actually strictly true.  I know from my days working on foreign exchange software that there is at least one currency out there that is not.  Fortunately, though, it's a minor currency (the Mauritanian ouguiya) and
even that one is base 5, so its fractional values can be represented exactly with base 10 fractions.

If you made it this far, perhaps you'll accept that a general-purpose representation of money needs these attributes:

1. Fractions must be represented in decimal format, not binary.
2. At least 20 significant decimal digits including the normal number of fractional digits needed for any given currency, and more if possible.
3. Depending on the currency, up to 10 digits to the right of the decimal point.  

Most programming languages, and certainly all the mainstream languages, do not have an intrinsic data type that can satisfy the above requirements.  However, most mainstream languages do have a library of some kind (such as BigDecimal in Java) that can meet them.  Unfortunately, often those libraries have attributes that make them undesirable for use representing monetary values.  For instance, in the case of BigDecimal there are fairly severe performance penalties, the in-memory footprint is large, there is no support for a standard compact encoding (for storage or transmission purposes), databases don't support it, and precision is inherently unlimited (which exacerbates all the preceding issues). 

I was the CTO for a company building a stock trading application where someone prior to me had made the decision to use BigDecimal to represent monetary values.  We saw lots of issues resulting from this choice, but two of them recurred enough to call them a problem pattern. 

One was the performance issue I mentioned earlier.  There were certain places in the application where we did a fair amount of arithmetic.  None of it was fancy or difficult, but even operations like comparing two values, if done enough, could occupy the CPU for a significant amount of time.  I was able to do an interesting experiment there, as the monetary value representation was nicely isolated in a class.  We profiled a production server and discovered that a little over 40% of our CPU consumption was occurring inside BigDecimal.  That was by far the single largest load on the processor.  The only way we could get more throughput from that server was to get rid of BigDecimal (or rewrite it for higher performance).

The other was a little subtler: the unlimited precision.  We were forever finding places where a multiply or divide operation created results with very large precision because the programmer forgot to properly round.  Once such a number was created, all the arithmetic operations that depended on it (and there might be millions of them) got bogged down using this large number – and then they often created even more giant precision numbers.  Those didn't just create performance problems, either – they consumed so much memory that on several occasions they actually took the server down!  These were surprisingly difficult to track down, too, because our application involved multiple inter-networked servers...

This is the first of what will be a series of posts about the challenges of representing and manipulating monetary values in computer programs.  Most of this is applicable to programs in any computer language, but some will be specific to Java.

Paradise ponders, barely controlled chaos edition...

Paradise ponders, barely controlled chaos edition...  Yesterday was another crazy day around here, mainly because of the contractors.  It's just amazing how many little decisions need to be made for what you might think would be simple projects.  Another such decision got added to the list this morning: our mud room cabinetry is about two weeks from completion, so it's time to pick the handles.  Debbie's got that one. :)

In between all the other things going on, I did manage to get a bit of work done on the sun room stairs project – and hopefully more today.  As in, there is at least a small chance that I could actually have them completely installed today.  Tomorrow is probably more likely.  :)  Anyway, yesterday I fabricated the mounts that will tie the stairs into the wall.  There are two of these, made from short pieces of redwood 4x4.  Each of them will have two toggle bolts to hold them onto the wall.  That wall used to be an exterior wall, so it's sheathed with 1/2" OSB, with 1/2" drywall on top of it.  Then in the center of these 4x4 sections, there's a hole for a 1/2" stainless steel bolt that will connect to the stair's ribs.  The mount wasn't simply 3 holes drilled, though.  The holes for the toggle bolts are 3/4" diameter except for the 1" closest to the wall, where it's just 1/4".  That lets me get the heads of the toggle bolts closer to the wall, so I can use shorter toggle bolts.  Then the hole for the stainless steel bolt is 1/2" all the way through, except for the 1/4" away from the stair ribs.  Those are 7/8" diameter, big enough to allow me to partially sink a nut in there, and glue it.  Here's a couple of photos of the setup I used to drill all these holes (a total of 12 holes with 4 drill bits).

A limitation of not being religious is that you don't know when the religious holidays are.  I went to check the stock market today, and was surprised to see yesterday's graph still up.  At first I thought there was something wrong with the Google finance site.  Later I was checking my calendar, and discovered that today is Good Friday.  I had no idea!

An old mortgage...

An old mortgage...  I found this on eBay a few weeks ago, and picked it up for a few bucks.  What caught my eye was the name “Dilatush” in it.  I scanned the “cover” at right just to give a flavor for the thing.  The entire mortgage is on two sheets of legal sized paper, typed on both sides.  The buyer and debtor is Edward Dilatush, the older brother of my grandfather (father's side) Earle Dilatush.  That makes him my great-uncle, I think.  In 1934, he bought 5 acres of farm land for $1,000, put down $200 and took out a mortgage for the $800 remaining at 6% APR.  He paid it all off in two years and two months.

My favorite part of this mortgage is the legal description of the property.  I've transcribed the beginning of it below:

All that certain farm and premises, situate lying and being in the township of West Windsor, in the County of Mercer and the State of New Jersey, consisting of one tract of land, bounded and described as follows, to wit: Beginning at a stone standing in the middle of the public road leading from Edinburgh to Trenton and running down the same North seventy seven and three quarters degrees East, twenty two chains and seven links to another stone in the middle of said road thence by land of Theodore Tindall and John Applegate South six degrees East, twenty one chains and forty three links to a stone thence still by the said Applegate South twelve and a half degrees West,...

All those references to old-fashioned surveying, in a document less than 100 years old!  Chains and links refer to a now-obsolete method surveyors used to measure distances.  I can't imagine New Jersey still relies on stones in the middle of the street, but “monuments” demarcating surveying “sections” are still the norm, at least in the western U.S.  Often these are concrete blocks, deeply sunk, with a round brass medallion sunk into the top.  We have one of these on our property in Utah.  The angles specified in quarters of a degree (1/1440th of a complete circle) are reflective of the limitations in precision of the surveyor's equipment of the day.  More accurate equipment was available, but was so very expensive that it wasn't used for ordinary surveying.

I know this property, something I didn't expect when I picked up the mortgage.  It was fairly close to the farm I grew up on, along what is today called Edinburg Road.  I believe it was either on or close to the property that the present-day Mercer County Technical Schools are on.  When I was a child, Edward's home was on it.  I don't actually remember Edward – perhaps he had already died by then – but I do remember his wife and two of their daughters.  I have a memory of being at their house with those daughters, playing with their kids, and especially enjoying their backyard pond (literally – this was dug out of the dirt).  This would have been sometime around 1956 or 1957.  I don't remember any of my siblings there, and a little oddly I remember my dad picking me up in our family's old '48 Dodge.  Normally my mom would have been doing that.

Paradise ponders, chaos edition... Man, what a day!

Paradise ponders, chaos edition...  Man, what a day!  Four workers from Leading Edge (the company we use for our heating and air conditioning, and a few other things) showed up to start work on an accumulated list of projects here.  First up was replacing our old water heater.  It was on its last legs, and the capacity was less than we needed.  It's been yanked, and in doing so they discovered the thing was nearly half full of sediment.  Sheesh!  Now we have a pair of brand new 50 gallon water heaters, plumbed in parallel.  That gives us 100 gallons of nice hot water anytime we want it. 

The workers also started on correcting a problem the home's previous owner created: not enough air returns to the furnace.  This was causing us all sorts of problems.  Basically the size of our furnace dictates that there be at least five returns in the house (returns are the grilles that return cold air to the furnace to be reheated; they're generally located near the floor).  Our house only had two, and even those were undersized.  Why did we only have two?  Turns out the previous owner decided to cover up four returns!  Argh!  Today the workers installed two new returns; tomorrow they're going to install a third and enlarge the two existing ones.  They're also going to install a large surface area filter on the furnace to reduce the resistance to air motion in the system.  We're hoping that finally ends our series of heating problems.

After they've finished with the furnace, they're going to plumb our diesel and gasoline tanks to the “filling station” we started last year.  We've talked with our mason, and he's started the project of putting rock on that.  With any luck at all, in a couple of months we'll have our own little filling station here.

Meanwhile, the sprinkler workers were back at it today.  They're still making trenches for the 6" water line and risers they're moving out of our back yard.  Once that's done, it's grade correction, then sprinkler installation, followed by sod installation.  They're going to be here a while.

Both of these groups of workers needed quite a bit of input from me today.  I was constantly being pulled in one direction or another by these guys.  All necessary stuff – I'm not complaining – but not at all conducive to getting anything done on my list of things to do!

But wait, there's more!

Debbie (who's doing fantastically well) really wanted some chicken noodle soup.  To satisfy her requirements for a low sodium diet, that means we have to make it – and right at the moment, we means me!  :)  So I ran to the grocery store this morning, then came home and cleaned and chopped celery, onions, carrots, and roast chicken; sauteed the veggies, spiced up some unsalted chicken broth, dumped in the veggies and chicken, tossed in some fresh fettuccine to make some homemade chicken noodle soup.  It tasted good to me, and got Debbie's enthusiastic approval.  Meanwhile, the water in the house is turned off completely (because they were installing the water heaters), so I couldn't clean anything in the kitchen – not even my hands.  I used paper towels and Pine-Sol to wash up with. :)  Later in the day, when the water was restored, I managed to clean up the disaster area formerly knows as our kitchen.

But wait, there's still more!

Partway through my chicken soup preparations, I saw Miki (our oldest dog) vomiting.  That made it three days in a row that he'd done so.  Time to be worried.  Debbie made a vet appointment, and right after I finished making the soup I headed to the vet with poor little Miki.  We were worried about bloat, something that had happened to Mo'i (another of our field spaniels) nearly ten years ago.  The vet quickly eliminated both bloat and a different kind of blockage.  Good.  But he suspects pancreatitis.  He took blood and urine for testing, and we'll know for sure by Friday if that's what it is.  The vet thinks it's equally likely that this is just some temporary GI disturbance, and will go away all on its own in a few days.  If it is pancreatitis, then Miki will be going on a special low-fat diet for a while, and getting regular doses of anti-nausea and metronidazole (an antibiotic used to treat stomach infections, amongst other things).  Other than the vomiting he seems to be just fine, except that he's gained almost ten pounds over the past year (from 41 to 50).  There may be a diet in his future. :)

For some reason I'm fairly tired this evening.  :)

Paradise ponders, wifely hardware removal, impossible niceness, the return of the Internet, and great big smiles edition...

Paradise ponders, wifely hardware removal, impossible niceness, the return of the Internet, and great big smiles edition...  Today Debbie had a planned surgery to remove the hardware that was inserted last year to hold her knee together while it healed.  The surgery was a relatively minor one; she spent less than 45 minutes in the operating room.  It's hard to imagine how it could possibly have gone any better.  The surgeon reported zero complications, he saw that her bones were healing very nicely, and he found exactly what he suspected has been causing Debbie's pain when she exercises: two “protuberances” poking into a tendon, one from the hardware and one from a bony growth.  He pulled all the hardware out, filled in some of the screw holes (the ones near her tibia plateau), and filed off the bony growth.  She's now all nice and smooth under that troublesome tendon.  She's also lighter by the amount of the hardware removed (the photo at left) – more than I was expecting!  That fancy plate is quite heavy all by itself.  The photo at right is a not-too-wonderful duplicate of the X-rays her surgeon took during the surgery.  The upper right one shows the injector he used to squirt cement into the screw holes. 

For this surgery we were at Cache Valley Hospital instead of the Intermountain Regional Hospital we usually go to.  This was at the surgeon's request; he prefers their operating facilities.  We've been there just once before, for an emergency room visit shortly after we moved here.  We were impressed by the ER staff at the time, but the insurance we got for the following year didn't have Cache Valley hospital as part of their network, so we didn't go there.  Our insurance this year includes both hospitals, so we accepted the surgeon's preference.

If you've been reading this blog for a while, you likely remember how impressed we were with the staff at Intermountain Regional Hospital.  Like most other people here, they were friendly and warm – and competent.  Well, Cache Valley Hospital, I have to say, managed to top even them.  There are so many little ways they made this visit easier; I could be here listing them for hours.  I'll just mention two that jumped out at me.  In the outpatient surgery intake room, the patient's chair was an overstuffed recliner – extremely comfortable, and very comforting for Debbie.  In both the intake area and in the recovery area, there are people whose entire job consists of running around to all the patients there to make sure they're ok.  Drinks, snacks, blankets, pain meds, a cheerful conversation – whatever is needed to make the patients less anxious and more comfortable, that person was right there every 60 seconds or so to make sure it happened.  This is so incredibly different than our experiences in San Diego that I am having trouble finding the words to describe them.  Our entire experience there today was a series of pleasant surprises.  Have you ever had a hospital experience like that?  I certainly hadn't!

There's one other thing about the hospital that I can't fail to mention.  When we scheduled the surgery last week, most of the collection of information was handled over the phone (very convenient, that was!).  Shortly after we finished with that, I got a call from someone in accounting in the hospital.  They'd noted that the entire cost of this surgery would be less (much less, actually) than our insurance deductible – so the entire cost would be out-of-pocket for us.  The hospital made us an offer: if we'd prepay the cost at their fixed rate, they'd give us a 10% discount on their cash rate (lower than the rate they bill insurance companies).  Now I'm sure that makes good business sense for them, as they'd get their money right away and without risk.  But obviously, since we have the money available, it makes good sense for us, too.  I happily took that offer – but I'm delighted that the offer was voluntarily extended.  Someone's on the ball there, identifying a nice win/win for both the hospital and its customers.

On the way home from the hospital today, I asked Debbie if she'd like to pick up something to eat.  She asked for soup (today is beef soup day!) from Los Primos.  We stopped there and Debbie waited in the car while I ran in to pick up that soup.  I placed my takeout order with a young man who's served us several times before.  He asked why weren't eating in the restaurant, so I told him about Debbie's surgery.  That brought a young woman (who has also served us many times) over to join the conversation.  When I got to the part about Debbie requesting the soup, there were two of the biggest, brightest smiles I've ever seen – and I swear the room got considerably brighter.  The two of them scurried off to the kitchen to make sure I left with the best selection of beef and vegetables in the soup.  So sweet!

Yesterday our Comcast technician (a fellow named Tony) came out to our house, exactly as promised (even well within the window they'd said).  Tony was bright, well-equipped with test gear, and had his brain fully engaged during his entire time here.  He actually listened to what I had to tell him, and upon hearing the symptoms agreed that this couldn't be a cable modem problem.  He didn't waste any time getting to a short list of three likely sources of the problem: a bad cable distribution amplifier, a bad connector in the interior wiring, or a bad underground service cable.  That list is in his order of likelihood.  We tested the amp first, and it was fine (and we had a great signal there, so that also eliminated the third possibility).  We located the cable leading from the amp to the office where we have the modem located, and a nifty little tester he had quickly told us there was an intermittent problem in that cable.  It turned out to be the connector behind the wall plate in Debbie's office.  In five minutes Tony had that replaced.  Then he noted that it was a crappy connector (I'm sure installed by our house's previous owner), so he checked all the other connectors in that cable.  Two of them were similar crappy connectors, so he replaced them too.  Then we logged into my cable modem and checked signal levels: rock solid, and 6db stronger than I'd ever seen.  So we did a speed test, and it was about 50% higher for download and 100% higher for upload (compared with previous tests I'd done).  The visit was at no cost to me.  I can't think of any way Tony could have done a better job. If Comcast manages to keep this up (and assuming the same sort of thing is happening everywhere), they just might manage to turn around their worst-company-in-the-universe reputation!

Now I'm off to go coddle Debbie a bit...  :)

Paradise ponders, leaping Sandhill cranes, snowy machines, and acrylic finish edition...

Paradise ponders, leaping Sandhill cranes, snowy machines, and acrylic finish edition...  Yesterday afternoon was beautiful: patchy clouds, lots of blue sky and sunshine, and most of the previous night's snow had melted.  We went for a drive out to Hardware Ranch, hoping to spot some wildlife.  We did see about 4.3 bazillion deer, but also the Sandhill crane pair I took a video of at right.  Be sure to make it full screen so you can see the cranes.  The clicking sound you hear is my car's four-way flashers going – we stopped right in the middle of the road to watch this.  These cranes are migratory, and they've just arrived here for the summer over the past couple of weeks.  A great many more stopped here for a break in their migration, then continued north.  We'll see the reverse of this next fall.  These two were performing a dance of sorts, very much different than their normal quite sedate behavior as they're feeding.  I was uncertain that was a mating dance when I first saw it, but some reading I did today confirmed it.

We had problems all day yesterday with our cable provider (which is actually just Internet connection for us).  It was up and down 35 times according to the logs my server keeps.  That's by far the worst experience we've had yet.  I called Comcast (our ISP), who is notorious for their bad customer service.  My experience was ... not bad, actually.  I got through their automated system and to an actual technician in under a minute.  The technician actually listened to what I described of the symptoms, tried only sensible things (instead of the rote power cycle, reboot the router, etc.), and quickly arrived at the same conclusion that I did: because the problem is isolated to us, there must be a connectivity problem between the junction where our line branches off, and our house.  That's Comcast's responsibility, so they need to get a technician out here to check it out.  That technician is scheduled for today at 2 pm – less than 24 hours after I called.  Either I got really lucky, or Comcast is actually working on their “worst company in the world” image...

Naturally, this morning our Internet is working perfectly. :)

That's our sprinkler contractor's trenching machine at right, in a shot taken yesterday morning.  The snow has all melted now, but the yard is very wet and muddy.  I suspect he won't be able to actually do any work until Tuesday or Wednesday.  Dang it!

Yesterday, as planned, I finished putting the fourth coat of acrylic (water-based polyurethane) on the stairs I'm building for our sun room.  This morning that last coat was nice and dry, so I flipped the stairs over and put the first coat of acrylic on the bottom.  The more I use this modern finish, the more impressed I am with it.  It goes on easily with a brush, and the self-leveling is so good that I'm not sure I could tell brushed from sprayed.  There's little odor, and even that is not foul at all.  It dries quite quickly, so much so that you have to work fairly fast so you don't ruffle some partly-dried surface.  You only have to wait two hours (though I waited three just to be sure) between coats; it's dry enough at that point to sand.  Cleanup is ridiculously easy: warm water to rinse out the bulk of the paint from the brush, a little soap and warm water to get the rest, and in the end the brush is just like new.  Pretty close to ideal!

Paradise ponders, cold snowy morning and polyurethane edition...

Paradise ponders, cold snowy morning and polyurethane edition...  Well, dang it!  We got freezing rain and snow last night, with our low temperature around 29°F.  Our backyard scene at right I took this morning (check the EXIF data if you don't believe me!).  The dogs are loving the snow, but all our trees with their tender new leaves and buds may not.  Our apple and pear trees may have lost their flower buds, which were just starting to swell.  The temperature was right at the borderline for damage.

I just got done putting the first coat of polyurethane on the sun room stairs I'm building.  I'm going to put four coats on the top, sanding between them.  It takes three hours to dry thoroughly, so it will take me all day today to get the top done.  Then tomorrow I'll flip it and do the bottom – probably just three coats on the visible sections and two on the hidden.  That means most of tomorrow will be needed, too – and then Tuesday I'll install them...

A real-life variable-length encoding challenge...

A real-life variable-length encoding challenge...  I've been poking around the idea of building a “money” class for Java.  This would be based on a purpose-made decimal floating point class, with better performance than BigDecimal and with features aimed at use in monetary calculations.  That decimal floating point class will need a way to encode the decimal exponent of the number held.

There are several interesting questions when it comes to the necessary range of that exponent.  For US dollars, a range of 10^-5 (thousandths of cents) to 10^14 (hundreds of trillions of dollars) would seem to be sufficient for just about any financial purpose.  That might not be true for other currencies, though the range of 20 orders of magnitude is probably pretty close to the mark in any currency.  For the rest of this discussion, I'll assume 20 orders of magnitude is what we need.

How should we encode that exponent?  All the existing floating point representations I'm aware of do that with a biased binary number.  For this case, they'd use a 5 bit number (the smallest number of bits that can hold 20 states) with a bias of 5 (meaning that you subtract 5 from the binary number to get the actual exponent).  So, for example, the exponent 3 would be represented by the binary number 01000 (or 8 decimal), as 8 - 5 = 3.  This scheme is very simple, allows asymmetry between the positive and negative ranges, and uses a fixed-length encoding.  If there is a requirement for fixed-length encoding, I don't know any way to beat this method.  But ... those 5 bits could hold 32 states, and we only need 20.  We could expand the range possible to store (that's the usual solution), but for the case we're interested in those extra states would be wasted.  What we'd really like would be a way to use less bits – and if two things are true, that's entirely possible.

First, it must be allowable (and useful!) to use a variable-length encoding.  I the case I'm working, that is allowable, and it's also very useful (in particular, when storing large lists of numbers, like a bookkeeping journal).  Second, the distribution of the numbers to be encoded must be uneven in a reasonably predictable way.  Intuitively it seems clear that monetary amounts in a typical bookkeeping system are distributed unevenly.  It's less clear how predictable that distribution is, but again, intuitively, it seems like at least the shape of the distribution curve should be similar for any size organization.

I happen to have a sample bookkeeping journal leftover from a past work engagement: real data, with about 40,000 numeric entries.  With just a little work, I came up with the exponent distribution at right (click to embiggen).  Three quarters of all the entries are either in the tens of dollars or hundreds of dollars range!  The frequencies fall off very quickly above and below those two exponents.  That's pretty darned uneven, which means we most definitely have an opportunity for a variable-length encoding.

Those frequencies are expressed in a normalized manner, so they all sum to 1.  That means we can use a simple formula to calculate the average encoding length for any encoding we want to test.

The first one I tried has two lengths selected by the leading bit.  The exponent would be encoded as either 0xx (for exponents 0..3) or 1xxxx (for exponents -5..-1 and 4..14).  The average bit length for this encoding on the data I have would be 0.975 * 3 + 0.025 * 5 = 3.05.  That's a pretty good payoff for such an encoding!  Note that in no case does the length exceed 5 bits, which is what we'd have with fixed-length encoding.  Also note that the first form has 4 states and the second 16 states, for a total of 20 states – exactly what we need.  There are no “wasted” states.

The second one I tried has two lengths, with a second (longer) encoding selected by an escape code.  The short code would be just two bits long, with 0..2 representing exponents 0..2, and 3 being the escape indicating a second 5 bit code following (so a total of 7 bits).  This second code would represent exponents -10..-1 and 3..24 – a range considerably larger than what we actually need.  The average bit length for this encoding on the data I have would be 0.915 * 2 + 0.085 * 7 = 2.425.  That's less than half the fixed-length encoding of 5 bits.  However, this encoding has a longer maximum length (7 bits vs. 5 bits) and a bunch of “wasted” states.

I haven't yet decided what encoding I'll actually use, though I'm pretty sure I'll be using some variable-length scheme.  Also, stealing an idea from Gustafson, I'm going to make the parameters (including length and encoding details) configurable, so no matter what I supply as default the end user can still configure his way out of any bind I create.  I would like the defaults to be well-chosen, though.  There are several things I need to investigate a bit more, especially (a) the differences between different currencies, and (b) the differences between kinds of financial applications and the size of the organization using them.  All I really have to go on there is my intuition, derived from several decades of experience.  I'd rather have hard data. :)  Don't know where I'm going to find that, though! 

Paradise ponders, slippery mud, wet wood, and sushi edition...

Paradise ponders, slippery mud, wet wood, and sushi edition...  I was able to spend most of day yesterday (and some this morning, too!) working on my stairs project.  In the first photo below, you see the results of the first round of sanding off the black (using 100 grit and the orbital sander).  The large landing has one round of sanding done (second photo is a closeup), while the smaller step is unsanded.  Quite a difference!  I ended up doing two rounds at 100 grit and a final round at 220 grit, and in the end I was pretty happy with how it looked.  The black color stayed in the dents as I'd originally intended, but it also was infused in some other areas in a way that resembles how wood weathers.  All good!  Then I started applying stain: two coats yesterday, another this morning.  The result (still wet) is in the third photo.  I think I'm going to stop at three, as it looks pretty good.  The stain has the side-effect of making the blackened areas a bit indistinct, again more like wood actually weathers.  Once these stairs are in the sun room, the little bit of red still visible will gradually fade, and the white parts will yellow slightly – both of these effects will, I think, improve the appearance.  So far I've only stained the top; later today I'll flip it over and start the process on the bottom.  By tomorrow I believe I'll be applying the matte polyurethane...

We went out for our lunch yesterday to a local favorite: Black Pearl.  I had sushi (my seafood nanudo roll at right); Debbie had their house pad thai.  Both were excellent!  We were both stuffed by the time we rolled out of there, and Debbie had some leftovers, too.  Not me. :)  On the way there we had an odd thing happen with the Model X.  From appearances, the GPS stopped reporting the car's position to the navigation system.  The car's symbol was stuck in one place on the map.  Nothing I did made any difference at all.  After we ate and started home, the position was still stuck – but only for a couple of blocks.  Then it suddenly started working again, and has been since then.  I've no idea what might have caused that.  The Tesla forums have a couple of mentions of the same problem, with the exact same outcome, so I'm not too worried about it.

Last night and early this morning we got slammed with a big rainstorm.  The snapshot at right shows the total storm accumulation; we got just over a half inch.  That wouldn't be so bad except that our soils were already super-saturated with water – so nearly all the water from this storm is either sitting on the surface or turning the first inch or so of soil into a slurry.  Some areas to our west and southwest got over 2" in this storm.  These are areas that are normally very dry, so this will likely cause a burst of plant growth – and wildflowers!  We have another storm approaching, too – starting around noon today we're expecting rain for 12 hours or so, with another half inch or a bit more in precipitation.  All this water is going to make our sprinkler project quite a bit harder.  I suspect Mark T. will be waiting a few days for things to dry out at least a little.  After today we've got 10 days with little chance of rain in the forecast, with highs in the upper 50s or low 60s, light winds, and lots of sun.  A few days of that and we'll dry out a bit, I hope!  The farmers around here who didn't plant this week are going to have to wait another week or so before their tractors can make it through the fields...

Apple dribbles out some hope...

Apple dribbles out some hope...  I've held off buying any Apple desktop product for over four years now.  Two separate problems have stopped me.  The first was that the new Mac Pro (sometimes called the “trash can”), while interesting from an engineering perspective, was so constrained on upgrades that I couldn't imagine shelling out the bucks for it.  The second was that the iMacs, while very cool products, had limited memory and storage options, just not enough horsepower for me to be happy with them as my development desktop.  So I've been stumbling along on my nearly five-year-old Macbook Pro, which even as I write is busy overheating (as I can tell by its fan sounding like a Pratt & Whitney turbojet) in its stand.

In the past month or so I've been pondering a radical switch for me: moving my desktop to Linux, on a conventional PC.  In that hardware world, getting something with specs I'd be happy with is almost trivial these days.  Furthermore, the price would be substantially less than any Mac would be.  I'd even gotten to the point of starting to check out specific hardware configurations, and pondering just which distro of Linux I'd move to.  I've gotten very used to my Mac tools, though, so this move was not one I was really looking forward to.

Then a couple of days ago Apple did something really surprising for them: they held a meeting with the press and talked about their future plans for “Pro level” Mac products.  I can't recall any similar forward-looking announcement by Apple – they must be really feeling the heat from disappointed “Pro” users, of which I am one.  And what they announced is exactly what I've been waiting for, on both fronts: a modular (upgradable) Mac Pro, and a “Pro” version of the iMac.

So I guess my poor little Macbook Pro will be overheating for a while longer.  I sure hope that fan holds up!

Paradise ponders, boring meeting, giant valve, and blackened wood edition...

Paradise ponders, boring meeting, giant valve, and blackened wood edition...  Last night was the annual shareholders' meeting of the Paradise Irrigation company.  I've attended the past two meetings, both of them interesting mainly because there were some controversial issues to deal with.  Last night's meeting was about as routine and boring as such a meeting can be, mainly because (a) Porcupine Reservoir, the source of our irrigation water, is already overflowing with much more water to come when the snow melts, and (b) the finances of the company were in far better shape than they were last year.  Our Board members were all re-elected by acclamation, so even the voting was boring.  The meeting was over in about 30 minutes.

On Wednesday evening I applied the first coat of the finish on the stairs.  It did not go as expected, nor as my one past experience went.  This coat is a dark grey that I intended to have lodge in all the dents to highlight them.  I expected to be able to just wipe it off the flat surfaces, like the similar product I've used in the past.  From the first moment I wiped it onto the wood it was obvious that this product was more like a stain, soaking into the flat surfaces.  Once I'd made the first wipe, though, I was committed – whatever I did needed to be done over the entire surface.  So I wiped it on everywhere, with the result you see at right.  Yikes!  When I was done, I figured out what happened.  Being the dummy that I am, I assumed this product was similar to the one I'd used in the past, and I didn't read the instructions.  Had I done so, I'd have noticed that you're supposed to apply this product only after you've sealed the wood.  In other words, this stuff was supposed to go on as a second coat, not the first coat.  Dang it!  I'm going to have a lot of sanding to do to get rid of this, as black stairs are the last thing we want.  Hopefully the dark color will remain in the dents after I sand it, so the end result may be just fine anyway – just a lot more work than I'd expected!

Mark T. and Dave were here all day yesterday.  One of the things they did was to start the installation of a gigantic gate valve.  In the first photo below you can see how they cut a hole in the existing 6" water pipe.  Note that the irrigation system is empty all winter, and won't be pressurized for several weeks yet.  That's why they can work on it now without causing geysers.  :)  In the second photo you see the valve body (the red part) before they installed it.  The last photo shows Mark in the process of installing it, and there you can get a good idea of the scale of this beast.  They're all done with the installation except for the step of torquing down the bolts on the various pieces (about 40 bolts in all).  The bolts and nuts on the valve required a 1 1/8" socket (huge!) and will be torqued to 50 ft/lbs.  Mark's bringing the required tools today, and then our shiny, new, gigantic valve will be complete.  They'll be filling in the hole, and installing a vertical pipe that will let us use a “key” to turn the valve on and off.  This will make the valve nearly invisible, especially since the vertical pipe's upper end will be hidden by our willow tree's trunk.  This will give us the ability to shut off the water supply to just Tim and myself, so that when we (inevitably) break a riser or dig through a pipe, we can shut off just us and not our neighbors.

Paradise ponders, playful puppies, gray foxes, and holey yards edition...

Paradise ponders, playful puppies, gray foxes, and holey yards edition...  Yesterday afternoon I took little Cabo for a mile-and-a-half walk, mostly with the aim of doing some leash training.  She did very well, actually – being alone (specifically, without her brother Mako along to make trouble) she was fully engaged in what we were doing and learned her leash-limits quickly.  She was also smelling absolutely everything in sight, especially any little piles of dried grass that might hide a vole within them.  She flushed several of them, but her snapping jaws missed by fractions of an inch each time.  She certainly tried hard, though!

The highlight of the walk happened on the way back.  I was looking at the road ahead, Cabo just ahead and to my right.  Suddenly she went completely berserk, bouncing off the end of the leash, barking like crazy.  When I looked where she was looking, I saw a beautiful gray fox about 50' away, loping quickly away from us while staring back at the fearsome Cabo.  Nice!

Our back yard now has about ten holes in it, dug by Mark T. and his sidekick Dave.  They're locating all the relevant pipes and fittings, and they've now dug out a place to put a 6" gate valve in.  This valve will very conveniently control the flow to our sprinkler system along with Tim's irrigation system (a mix of hand-line and underground sprinklers).  Both Tim and I will appreciate that.  But in the meanwhile, our back yard is a glorious mess – it looks like a WWI battlefield with trenches and places where artillery shells exploded!

Paradise ponders: monetary disappointment, another hole-digger and glue on the stairs edition...

Paradise ponders: monetary disappointment, another hole-digger and glue on the stairs edition...  The fellow at right (Dave) is standing in a hole that he dug in our back yard this morning.  Dave works for Mark T., the contractor who's working on getting sprinklers installed into my yard.  His day job is professor of political science at Utah State University, but when he's not teaching he's working for Mark doing much less frustrating work. :)  He waxes poetic about the joys of digging holes, which instantly reminded me of my dad (as it would anyone who knew him) – for my dad's “hobby” (as we liked to tease him) was digging holes.  As with Dave, the bigger the better.

Dave made an unexpected discovery upon digging this hole.  What he expected to find was an elbow on a 6" diameter irrigation water line.  The plan was to cut the line here, tap into the source side for the water for our new sprinkler system, and use the other side as a tunnel underneath our driveway (for a 4" pipe for the new sprinklers, plus a bunch of control wires).  But he didn't find that elbow.  Instead, he found a 3" diameter pipe for the source of the irrigation water, connecting into a 6" pipe that runs a quarter mile south of there.  With some more work, we figured out that whoever installed this system connected from one 6" main through a 50' long piece of 3" pipe into the second 6" diameter main.  That's like having an interstate highway with a few miles of one-lane country road in the middle of it!  None of us can imagine any good reason for doing this.  I shouldn't be surprised any longer at the crazy things the previous owner did, but this one probably is the new one for top billing...

This morning I rinsed the sodium hydroxide and hydrogen peroxide residue from the wood I bleached yesterday.  That took a lot of elbow grease, but the result was worth it.  That bleach really works well!  Then early this afternoon I enlisted our friend Michelle H. to help me glue up the ribs and the landing board.  The photo at right shows that assembly in clamps.  When I made that landing, I glued it up with a (very) slight bow in it, so that the center was slightly higher than the ends.  That allowed me to use the simple clamping arrangement you see here, with the blocks in the middle pressed down by a pair of clamps on a board.  The result is a nice flat surface as the clamp presses the landing board down onto the flat surface of the ribs.  I've had better results with a center clamp like this than with either a perfectly flat board or a bowed board the other way – I'm pretty sure that's because of the single clamp in the center, as you see here.

A couple of months ago, I posted about a book I'd read about: The End of Error, by John Gustafson.  I've finished it now, and I have to say I'm a bit disappointed.  My biggest hope is that he'd devised a good way to implement floating point arithmetic such that it could (practically) be used to represent money.  I judge that he failed to reach that lofty goal.  He did, however, have a few ideas that I really like.  One of them is the notion of using a bit to specify whether the floating point number is exact or an approximation.  That's a valuable piece of information when you're dealing with money.  Unfortunately, he specifies the approximations as truncations of the actual value – whereas for money you would want the rounded approximation.  Another very interesting idea is the notion of allowing encodings where the precision is specified as part of each number.  That would allow much more compact encodings on average in most applications, assuming you don't actually need a fixed length.  Those are a couple of great ideas that could be incorporated in a pragmatic money representation.  Yet another idea is to associate a context with computation and encodings of numbers in a particular usage – particularly powerful for allowing variable precision for different needs.

The next version of Java is likely to have a better money representation, but what I've read suggests that it will simply be an amalgamation of BigDecimal and Currency.  These are existing classes with much less than ideal characteristics for a general-purpose representation of monetary values.  It amazes me that after over 20 years of use in business applications, Java still does not have support for a pragmatic representation of money...

Your morning smile...

Your morning smile...