# Bunny Living Space

For more than a year now, two indoor bunnies – Nutmeg (left) and Tila (right) – have been part of our family. Our bunnies are very inquisitive and get along with each other only MOST of the time.  As a result, they spend most of their time in separate, adjacent pens that take up most of our living room, each with her own custom-built 3-story "condo" (the white, wire-mesh, structure at the back): I wondered how large a space does this "feel" like to them, compared to the humans in the house?  To put it another way, if you were to shrink a human down to the size of the bunnies, how large of a house would this feel like?

## Measuring the Pens

First, I needed to figure out how many square feet of space the pens actually take up.  The walls of the pens are flexible, so I choose one of the simplest configurations to compute: The condos take up 14×42" of space per level.  6 levels result in 3,528in2 of space.

Each condo has a front porch, which allows the bunnies to climb up or go under, doubling the floorspace provided.  Each porch has an additional 196in2 of space.

I’ve broken the pen itself into three blocks – A, B, and C.

A: 140 x 33 = 4620in2
B: 76 x 32 = 2432in2
C: 0.5 x 32 x 32 = 512in2

So, the total space is

 Floor Space Area 3528 Condos 196 Condo Porch 1 196 Condo Porch 2 4620 Pen Area A 2432 Pen Area B 512 Pen Area C 11484 Total

11,484in2 works out to 79.8ft2.

## Bunny:Human Ratio

Next I needed a bunny-to-human ratio.  I came up with a few possible approaches here.

The first was simply measuring the bunnies’ feet compared to my own.  With my shoe on, my foot is exactly 12 inches long.  The bunnies REALLY don’t like me touching their feet, let alone measuring them, so I decided to estimate them at 1in long, which gives a nice ratio of 12:1.  Converting "human feet" to "bunny feet", then:

122 / 12 = x / 79.8

x = 79.8ft2 * 144

x = 11,491ft2

So, if we shrank a human to be 5.9" tall (1/12 my current height), would the pens feel like an 11,491ft2 home?  Possibly, but to me that seems too large.

A second is to compare our relative heights.  I’ll use Tila’s dimensions here since she was the more accessible one when I took this photo: This is probably their most common snoozing positions – the "loaf".  When loafed, Tila is 6" tall at her highest point.

I stand 71" tall, which means there is a ratio of 11.8:1 between us.  Using the second formula above, we get:

x = 79.8ft2 * (11.8)2
x = 11,111ft2

A pleasantly repeating solution, but subjectively it still seems too large.

A third possible approach is to compare the bunny’s length to my height.  I walk upright, but bunnies spend virtually all of their time with "four on the floor".  When loafed, Tila is 10" long.  Compared to my 71" of height, that’s a ratio of 7.1:1.  Using the formula above:

x = 79.8ft2 * (7.1)2
x = 4,023ft2

So, at the bunny’s scale, their pens are the equivalent to a 4,000ft2 home with each bunny getting roughly half of that.  Would each pen feel like a 2,000ft2 home to a 10" tall person?  I think that’s closer to what I was expecting.

# Squares Squared

Let’s say we’re going to calculate the product, P, of two integers, X and Y, each of which are squares.  Their product will also be a square:

P = X • Y

But since X and Y are squares, they can each be broken down into their roots, Xr and Yr, and the problem rewritten as follows:

P = Xr • Xr • Yr • Yr

Next, we can rearrange the terms like so:

P = Xr • Yr • Xr • Yr

P = (Xr • Yr) • (Xr • Yr)

P = (Xr • Yr)2

Therefore, P will be a square.

# More Positive

Here’s a numerical curiosity I came across.  I checked out a book from the library, and while the librarian correctly recorded the due date as “6/10/22”, the latter “2” looked like a 0 from a distance, so I read it as “6/10/20”.  I wondered if there was a clever way to relate the three numbers together.

There are probably many ways, but what I came up with was “If you add 6 and 10, and then add the difference between those two, you’ll get 20”.  Then I started playing with other pairs of numbers – 3 and 5, 1 and 4, and so on.  All of the results came out even.  Was that a general rule?  Given 2 integers a and b, will this always produce an even result?

Let a and b be positive integers, and r the result of our arithmetic machinations.  Our formula becomes:

r = a + b + |a – b|

Now, let’s consider the possibilities:

• If a is larger, then the absolute value portion reduces to simply “a – b”, the b’s cancel, and what’s left is 2a
• If b is larger, then the absolute value portion reduces to simply “b – a”, the a’s cancel, and what’s left is 2b
• If a and b are the same, then the absolute value portion is 0, leaving 2a (or alternatively, 2b)

Interestingly, not only will this always produce a positive result, it will always be twice the larger integer.

That works if we start with positive integers.  What happens if we introduce other combinations?

• Two negative integers: the result ends up being twice the smaller of the two negatives.  For example –6 and –10 produce a result of –12.  You can also define “the result will be twice the more positive value”.
• One positive and one negative: The result is still twice the more positive.
• One positive and 0?  Still twice the more positive number.

What about one negative and 0?  That interestingly follows the same rule – the result will continue to be the more positive of the two, which is 0 in this case.  If we let a be the negative number and b be 0, the formula reduces to

r = a + |a|

With a being negative, this will always cancel out, leaving 0.

Is there a name for any of this?

* Edited to correct the origin story of this proof.

# Nesso Technologies, Epilogue

From 2015 through early 2022, I worked on a side project called “Nesso”. Its goal was to build a system that could find gaps – potentially missing datapoints – in a given dataset. I made the decision in April 2020 to form a company around this idea – Nesso Technologies.

While I made some great progress in those seven years taking a very vague idea and turning it into real software, I wasn’t able to generate much outside interest in it, let alone paying customers. So, in January 2022, I decided to close the company and the project down. I think the idea still has merit, but despite the time and energy I had put into it, I had to admit I was not up to the challenge of executing on it.

Following that decision, there was a little sadness, some disappointment, but mostly a sense of relief. There are a lot of other activities and projects that I’ve put on hold over the years, and now that I am no longer working on Nesso I’ll have the capacity to pursue them. That sense of relief reinforced that I made the right choice.

To the people who cheered for me, encouraged me, and gave me feedback along the way – thank you.

# The Last Word

Yesterday, I installed Office 365, and retired some of the oldest pieces of software I ran on my home machine – Office 2007: That particular suite spanned:

• 13 years
• 2 different machines
• 3 versions of Windows
• 3 jobs
• 1.5 kids (my younger daughter hadn’t even been born when I first installed it)

Word and Excel were by far the most used components of the suite, but PowerPoint was sprinkled in there as well.  Word ran like a champ all that time.  Excel, though, developed a tic in the last couple of years.  Somewhere along the way, it decided it needed to try to install itself again every time I booted it up.  The first couple of times I tried to let it finish, thinking that something had gotten corrupted and it was trying to run a Repair.  What I found, though, is that it didn’t matter if I let it finish or not – it would run through it again the next time I started it.  So, I took to cancelling the installation, which required 3-4 extra clicks (depending on whether I caught it soon enough after it started), and several additional seconds.  I dealt with it, but I’m not sorry to be finally rid of that extra boot-up sequence.

With Office 2007 gone, I think the title of "oldest piece of software" falls to Visio 2007.  I’ll get around to that one eventually.

# Pumping iron to keep the headache at bay

Back in October 2017 I ran an experiment where I determined that not staying hydrated throughout the day aggravated my headache.  This past month, I tested another couple of variables.  Just as before, for the several days leading up to the beginning of Week 1, I stopped taking all Excedrin, and didn’t take it at all during the experiment so it wouldn’t interfere with my results.

Week 1 – Establishing Baseline
I tracked my headache for this first week, striving for a pain reading every 15 minutes.  My scale runs from 0-10, where 0 is no headache at all, and 10 is "curled up in a ball, whimpering".

Week 2 – Windows Nightlight Mode
For the second week, I switched Windows Nightlight Mode on, to cut down on the amount of blue light I was seeing on my monitors during the evenings.  I configured it to be enabled on my laptop and my phone from 7:30 until midnight.  Since I am very frequently on my computer until just before I go to bed, I was curious to see if the blue light from my screens was contributing to my headache at all.

As it turns out, I felt no perceivable difference in my headache pain with Nightlight on or off. After Week 2, I turned this mode off.

Week 3 – Iron Supplements
A friend of mine mentioned that an iron deficiency can contribute/cause headaches.  I did a bit of research into that angle, and sure enough, there are ample references to the link between these two (for example, see this article or this article).  So, for Week 3, I started taking a daily iron supplement.

The results here were much more interesting. On average, I saw a 0.4 drop in my headache rating when I was on the iron supplement (compared to Week 1’s baseline).

Week 4 – Blood pressure
On more than one occasion, I’ve noticed that bending over to tie my shoes, or doing something very strenuous aggravates my headache.  I began to wonder if there was a correlation between my blood pressure and my headaches.  I had an automatic home blood pressure monitor, so during Week 4 I intended to record my blood pressure alongside my headaches, and see if there was a relationship.

Unfortunately, I stopped this part of the way through the week, for two reasons.  First, I was getting consistently higher readings for my blood pressure than any of the times I’ve had it measured by a professional.  I wondered if a) I was either not placing the cuff on my arm correctly (too high/too low on the arm, too tight around it, etc.), or b) the machine needed to be recalibrated.

Second, and more seriously, I didn’t want to take readings every 15 minutes because it would have driven my co-workers nuts.  So, I tried taking a couple of readings in the mornings before I went to work and a couple in the evenings after I got home.  I was initially concerned that only getting 3-4 readings a day wouldn’t be enough to really determined correlation.  That thought continued to nag me until I decided to stop the experiment.  Perhaps I’ll revisit this later.

Summary
So, to date, I’ve found that the following aggravate my headaches:

• Not staying sufficiently hydrated throughout the day
• Too much sodium
• Not enough iron in my diet

That’s progress.

# What am I doing on Twitter?

What can you expect from me on Twitter?  I start by posing questions, every day.  Some will be silly.  Most will be about science fiction, science, or technology.  Hopefully they will all inspire some thought, and perhaps a conversation.

A good question, crafted from a place of curiosity, can cut through the noise and lead to the signal.  Let’s learn to ask better ones.  Follow me @NessoAsks.

# Tweet, tweet?

I’ve written on my personal blog about a project I started called "Nesso" (https://markofquality.wordpress.com/category/nesso/ ).  That project has grown into something much larger than just my headaches.  At its core, Project Nesso is about asking better questions.  For the last two years I’ve been developing ways to ask questions about a given dataset.

This weekend I started a new one.  You can now follow me on Twitter @NessoAsks.  My goal is to tweet at least one question a day, which forces me to be more mindful of what is going on around me every day.  I’m curious to see how my questions improve over time, and if those questions can spur some interesting discussion.

Join the conversation!

# Formatting Terms and Operations

I mentioned in my last post that the logic for displaying terms and operations was much more complicated than I originally anticipated.  The logic evolved as the game development progressed, and CJ and I identified new and interesting edge cases to be addressed.

I’ll begin with the logic behind the operations.  Both ConstantOperation and VariableOperation have their ToString() methods overridden.  ConstantOperation is the simpler of the two:

public override string ToString()
{
return Utility.ToConstantOperationString(this.Numerator, this.Denominator, this.Operand);
}

The ToConstantOperationString method does all of the heaving lifting here:

public static string ToConstantOperationString(int Numerator, int Denominator, Operands Operand)
{
string OperandSymbol, Sign;
OperandSymbol = "";
Sign = "";
switch (Operand)
{
OperandSymbol = ((float)Numerator / (float)Denominator < 0 ? "-" : "+");
Sign = "";
break;
case Operands.Subtract:
OperandSymbol = ((float)Numerator / (float)Denominator < 0 ? "+" : "-");
Sign = "";
break;
case Operands.Multiply:
OperandSymbol = "*";
Sign = ((float)Numerator / (float)Denominator < 0 ? "-" : "");
break;
case Operands.Divide:
OperandSymbol = "/";
Sign = ((float)Numerator / (float)Denominator < 0 ? "-" : "");
break;
}

return string.Format("{0}{1}{2}{3}{4}{5}{6}",
OperandSymbol,
Sign,
(Math.Abs(Denominator) == 1 ? "" : "("),
Math.Abs(Numerator),
(Math.Abs(Denominator) == 1 ? "" : "/"),
(Math.Abs(Denominator) == 1 ? "" : Math.Abs(Denominator).ToString()),
(Math.Abs(Denominator) == 1 ? "" : ")"));
}

The switch statement sorts out which operand and which sign will be displayed.  The latter is dependent on the former.  For adds & subtracts, the operand and the sign end up effectively merged with each other.

• Adding a positive 4: "+4"
• Adding a negative 4: "-4"
• Subtracting a positive 4: "-4"
• Subtracting a negative 4: "+4"

Multiplication and division, however, preserve both the operand and the sign (at least when the number is negative):

• Multiplying a positive 4: "*4"
• Multiplying a negative 4: "*-4"
• Dividing by a positive 4: "/4"
• Dividing by a negative 4: "/-4"

Then we need to format the final value, which includes the operand, the sign, and the number itself.  Whole numbers like the above examples are straightforward.  Fractional numbers present an additional challenge.  I made the decision to surround fractional operations in parentheses, to set the absolute value apart from the sign, operand, and (as we’ll see later this post), the variable letter:

• +(4/3)
• -(4/3)
• /-(4/3)
• *-(4/3)

As the Format() function at the end suggests, each constant is made up of 7 pieces:

• The operand itself (+, -, *, or /)
• The sign of the constant
• An open parenthesis, if this is a fraction (denoted by a non-1 denominator)
• The numerator
• A slash, if this is a fraction
• The denominator, if this is a fraction
• A closing parenthesis, if this is a fraction

It is also important to note that the numerator, the denominator, or both, may be negative.  However, it all cases, the presentation of that value will never be something like "-4/-3".  The signs of the two components effective get evaluated in the expression:

((float)Numerator / (float)Denominator < 0 ? … : … )

VariableOperation.ToString() use the exact same logic for coming up with the coefficient, but includes two additional pieces of logic:

public override string ToString()
{
String InitialCoefficientString;

InitialCoefficientString = Utility.ToConstantOperationString(this.Numerator, this.Denominator, this.Operand);
if(Math.Abs(this.Numerator) == 1 && Math.Abs(this.Denominator) == 1) { InitialCoefficientString = InitialCoefficientString.Replace("1", ""); }

return string.Format("{0}{1}", InitialCoefficientString, this.Var);
}

First, it appends the variable letter itself, in the Format() call.  Second, it evaluates the coefficient to see if it is exact "1".  If so, it drops the coefficient completely, so that the player sees "+x" rather than "+1x", by simply replacing the "1" with an empty string.  (However, since this version of the game does not allow you to "multiply by x" or "divide by x", the player wouldn’t see something like "*x" or "/x" anyway, so this bit of logic is really just future-proofing.)

That’s all there is for rendering operations.  Let’s move on to how terms are presented.

***

Terms have a slightly different set of concerns than operations.  The operations have to show one of four operands, every time, while terms only have to worry about rendering "+" and "-".  In some cases, an operand is not shown at all, as in the case of leading, positive values:

4x – 1 = 15

This concept of "leading term" crops up a couple of times in the other methods we’ve looked at.  The signs for the first term on either side of the equal sign get treated a little differently.

As with the operations, the Constant and Variable classes have their ToString() methods overridden.  Let’s start with Constant:

public override string ToString()
{
if(this.Numerator == 0) { return "0"; }

return string.Format("{0}{1}{2}{3}",
(((float)this.Numerator / (float)this.Denominator) > 0f ? (this.IsFirstOnThisSide ? "" : "+ ") : (this.IsFirstOnThisSide ? "-" : "- ")),
Math.Abs(this.Numerator),
(Math.Abs(this.Denominator) == 1 ? "" : "/"),
(Math.Abs(this.Denominator) == 1 ? "" : Math.Abs(this.Denominator).ToString()));
}

Much of this should look familiar from ConstantOperation.  The notable exceptions being the lack of parentheses, and the presentation of the sign.  The latter gets subtly modified depending on whether this is the first term in the equation or not.  First-term additions show no sign:

4 + 3x = 2

While other additions show a "+" followed by a space.

3x + 4 = 2

The space improves the look of the equation.  Without it, it would look like

3x +4 = 2

First-term subtractions show the minus sign with no intervening space (the "-3" here), but other subtractions (the "- 9" here) include the space:

4x = -3 – 9

****

Now let’s look at Variable terms.  The Variable version of ToString() combines these the approaches:

public override string ToString()
{
return string.Format("{0}{1}{2}{3}{4}{5}{6}",
(((float)this.Numerator / (float)this.Denominator) > 0f ? (this.IsFirstOnThisSide ? "" : "+ ") : (this.IsFirstOnThisSide ? "-" : "- ")),
(Math.Abs(this.Denominator) == 1 ? "" : "("),
(Math.Abs(this.Numerator) == 1 && Math.Abs(this.Denominator) == 1 ? "" : Math.Abs(this.Numerator).ToString()),
(Math.Abs(this.Denominator) == 1 ? "" : "/"),
(Math.Abs(this.Denominator) == 1 ? "" : Math.Abs(this.Denominator).ToString()),
(Math.Abs(this.Denominator) == 1 ? "" : ")"),
this.Var);
}

Parentheses are included (to distinguish the sign, coefficient, and variable more clearly), as is the "first term" logic.

***

At this point, you might be asking why I ended up with three different approaches to formatting the values.  The requirements for operations, constant terms, and variable terms have overlap, but none of them were complete subsets of the others.  That makes it trickier to factor anything out.  I think you can make the argument, though, that showing a constant operation of "-(3/4)", and a constant term of "-3/4" (as the game currently does) is inconsistent and should be normalized.  Doing so would go a long way to making it easier to refactor the logic together.  Another improvement for a later version.

This concludes the series on the algebra game.  There are still plenty of things that we’d like to do with the game before we consider submitting it to one or both app stores: replace the temporary graphics, add usage tracking, add error logging, and so on.  I’ve had a blast building it to this point and (for the most part) loved the discussions with CJ about its direction.  (We won’t speak of the "I’m sorry dear; I really think you need to represent numbers as fractions" conversation again.)

# Validating the Operations Applied

In my last post, I walked through how the player’s operations get applied to the equation.  The first step in that was to validate that the operations applied were actually valid.  Today, I’m going to go through that validation method: ValidatateOperationsBeingApplied.

The method is passed a list of the operations to apply, and a boolean called ShouldForceOperationsToMatchTerms.  The general design is that it makes a single pass through the list of operations, calculating statistics as it goes, and then does a series of comparisons to verify everything is in order.

it begins by performing a couple of sanitation checks on the list:

if (OperationsToApply == null) { throw new OperationsValidityException(OperationsValidityException.InvalidStates.ListIsNull); }
if (OperationsToApply.Count != this.Terms.Count) { throw new OperationsValidityException(OperationsValidityException.InvalidStates.ListCountMismatch); }

In theory, the application should not allow either of these cases to occur, but #BugsHappen.

Next, the method calculates a couple of quick statistics on the terms.  These will be used as the baseline that the operations will be compared to.

NumberOfTermsOnLeft = 0;
NumberOfTermsOnRight = 0;
FoundEqualSign = false;
foreach (IAmATerm CurrentTerm in this.Terms)
{
if (CurrentTerm is EqualSign) { FoundEqualSign = true; }
else if (FoundEqualSign) { NumberOfTermsOnRight++; }
else { NumberOfTermsOnLeft++; }
}

Next is the main loop:

NumberOfOperationsOnLeft = 0;
ListContainsEqualSign = false;
FirstOperation = null;
NumberASsOnLeft = 0;
NumberASsOnRight = 0;
NumberMDsOnLeft = 0;
NumberMDsOnRight = 0;
TermIndex = 0;
foreach (IAmAnOperation CurrentOperation in OperationsToApply)
{
…
}

The variables that begin "NumberAS" refer to the number of Addition/Subtraction operations.  The variables that begin "NumberMD" refer to the number of Multiplication/Division operations.  The loop-logic begins by checking whether the equation was configured to require the variable operations to line up with the variable terms, and constant operations with constant terms:

if(ShouldForceOperationsToMatchTerms)
{
if (this.Terms[TermIndex] is Variable &&
CurrentOperation is ConstantOperation &&
(CurrentOperation.Operand == Operands.Add || CurrentOperation.Operand == Operands.Subtract))
{
throw new TermOperationMismatchException();
}

if (this.Terms[TermIndex] is Constant
&& CurrentOperation is VariableOperation)
{
throw new TermOperationMismatchException();
}
}

The first conditional checks to see if a constant operation is being applied to a variable one.  That’s ok when the player is multiplying or dividing by that constant, but not when they’re trying to add or subtract it.  The second conditional checks to see if a variable operation is being applied to a constant one, which is never allowed.  In both cases, a TermOperationMismatchException is thrown.

If the equation is configured to allow mismatches, then the player can try it, but ApplyOperations will simply carry both the original term and the new operation forward into the next equation state.  For the current iteration of the game, all of the levels are configured to allow mismatches to occur, so this logic is not actually executed during regular gameplay.

Next, the logic looks to see if it’s encountered the equal sign yet in the list of operations.  If not, then it’s still going through the terms on the left side of the equal sign, and it increments a counter to that effect:

if (CurrentOperation is EqualSignOperation) { ListContainsEqualSign = true; }
else if (!ListContainsEqualSign) { NumberOfOperationsOnLeft++; }

Next it looks at what kind of operations (addition, division, etc.) is being applied.

if (!(CurrentOperation is EqualSignOperation) && !(CurrentOperation is NoOperation))
{
if (FirstOperation == null) { FirstOperation = CurrentOperation; }
else if (!FirstOperation.Equals(CurrentOperation)) { throw new OperationsValidityException(OperationsValidityException.InvalidStates.ListContainsMoreThanOneOperation); }

if (FirstOperation.Operand == Operands.Add || FirstOperation.Operand == Operands.Subtract)
{
NumberASsOnLeft += (!ListContainsEqualSign ? 1 : 0);
NumberASsOnRight += (ListContainsEqualSign ? 1 : 0);
}

if (FirstOperation.Operand == Operands.Multiply || FirstOperation.Operand == Operands.Divide)
{
NumberMDsOnLeft += (!ListContainsEqualSign ? 1 : 0);
NumberMDsOnRight += (ListContainsEqualSign ? 1 : 0);
}
}

Recall from "Applying Operations” that the player is only allowed to apply a single operation to the equation at a time.  The if-then-else-if verifies that that is the case.  It looks for the "first" operation being applied, and makes sure that all of the other ones match it.

Then it increments 2 of 4 counters, depending on what kind of operation is being applied, and whether or not it’s encountered the equal sign already.

• NumberASsOnLeft
• NumberASsOnRight
• NumberMDsOnLeft
• NumberMDsOnRight

Finally, it increments the index it uses to keep track of which term it is inspecting:

TermIndex++;

After the loop, it evaluates the statistics that it’s been collecting:

if (!ListContainsEqualSign)
{
throw new OperationsValidityException(OperationsValidityException.InvalidStates.ListLacksEqualSign);
}

First, if the list of operations didn’t even include an equal sign, it’s clearly invalid.

if (NumberOfOperationsOnLeft != NumberOfTermsOnLeft)
{
throw new OperationsValidityException(OperationsValidityException.InvalidStates.ListIsUnbalanced);
}

This verifies that the number of operations on the left matches the number of terms on the left.  I only have to verify that the left sides match in number.  At this point in the logic, I can safely assume that the right sides also match since a) I’ve already verified that the total number of operations matches the total number of terms, and b) I’ve verified that the former contains an equal sign.

if (NumberASsOnLeft == 0 && NumberASsOnRight == 0 && NumberMDsOnLeft == 0 && NumberMDsOnRight == 0)
{
throw new NoOperationException();
}

Now it verifies that the player applied SOMETHING to the equation – at least one of these statistics (and ideally 2) should be non-0.

if (NumberASsOnLeft != NumberASsOnRight) { throw new AddSubtractOperationException(); }

This confirms that the number of addition/subtraction operations applied on the left match those on the right…

if (NumberASsOnLeft > 1) { throw new AddSubtractOperationException(); }

…and that there was at most 1 operation applied on each side (again, if the left matches the right, I only have to check the count on the left).

if (NumberASsOnLeft == 0)
{
if (NumberMDsOnLeft != NumberOfTermsOnLeft) { throw new MultiplyDivideOperationException(); }
if (NumberMDsOnRight != NumberOfTermsOnRight) { throw new MultiplyDivideOperationException(); }
}

Finally, if the player didn’t apply an addition/subtraction operation, then they must have applied a multiplication/division operation.  Check that the number of multiplication operations applied on the left matches the ones on the right.  Then check that the number of division operations match left and right.

If all of these checks pass, then the operations being applied are valid, and the player can proceed.

In my next post, I’ll go through the logic involved in displaying an operation in the UI.  As it turns out, it’s not as simple as "is the number negative or not?"  It was surprising how many scenarios had to be accounted for to get it right.