In a previous article I wrote, I introduced a way to compare expressions on the basis of their makeup as opposed to simple reference equality checks. This functionality was provided in the form of an IEqualityComparer<T> implementation, which itself was supported by several components.

Like all equality comparers, our expression equality comparer must be able to perform two functions:

  1. Determine the equality between two given expression instances
  2. Generate a hash code for a given expression instance

The previous article covered the first of these jobs; in this article, we’ll be covering the hash code generation aspect of the comparer.

Revisiting Our Equality Comparer

Just to make sure we’re all on board in regards to how and where our hash code generator will be used, let’s take a second to revisit the equality comparer presented in the previous article.

ExpressionEqualityComparer.cs
/// <summary>
/// Provides methods to compare <see cref="Expression"/> objects for equality.
/// </summary>
public sealed class ExpressionEqualityComparer : IEqualityComparer<Expression>
{
    private static readonly ExpressionEqualityComparer _Instance = new ExpressionEqualityComparer();

    /// <summary>
    /// Gets the default <see cref="ExpressionEqualityComparer"/> instance.
    /// </summary>
    public static ExpressionEqualityComparer Instance
    {
        get { return _Instance; }
    }

    /// <inheritdoc/>
    public bool Equals(Expression x, Expression y)
    {
        return new ExpressionComparison(x, y).ExpressionsAreEqual;
    }

    /// <inheritdoc/>
    public int GetHashCode(Expression obj)
    {
        return new ExpressionHashCodeCalculator(obj).Output;
    }
}

As we can see above, the brunt of the equality comparison work is performed by the ExpressionComparison class, which is a type that we covered in the first article in this series.

If you look at the code for the ExpressionComparison type, you’ll see that it is a derivative of the .NET provided ExpressionVisitor class. The reason why ExpressionComparison was subclassed from ExpressionVisitor is because hooking into that infrastructure is logically congruent with the structure of the expressions it would be comparing.

In order to take into account all the various types of expressions and their properties, we needed to override the majority of the virtual (Visit[x]) methods exposed by ExpressionVisitor. We did not have to override all of them, only the ones targeting expression types whose makeup was unique among all other types.

Just like we did with ExpressionComparison, our ExpressionHashCodeCalculator will also subclass ExpressionVisitor, and it will behave in much the same way, except it will be calculate a running total of the hash codes of all the various properties significant to the given type of expression.

Expression Hash Code Calculator

Now, let’s get into the meat of the matter. As usual, I need to state a disclaimer regarding the usage of the code before we go over it. Although I’ve personally tested all part of the code, I would encourage you to do so yourself before just plopping into what you’re doing.

This code has received a fair amount of scrutiny and is used in some important parts of a larger project I’ve been authoring. In fact, the hash code generation aspect of my comparer rests at the heart of the reasons why I started out on this endeavor (it was my wish to be able to use expressions as keys in a dictionary).

We’ll first take a look at the code for the ExpressionHashCodeCalculator type, and then discuss its merits afterwards.

ExpressionHashCodeCalculator.cs

Update: Thanks to Denis in the comments for pointing out that there was a lack of support for constant collections; code has now been updated to support constant collections.

/// <summary>
/// Provides a visitor that calculates a hash code for an entire expression tree.
/// This class cannot be inherited.
/// </summary>
public sealed class ExpressionHashCodeCalculator : ExpressionVisitor
{
    /// <summary>
    /// Initializes a new instance of the <see cref="ExpressionHashCodeCalculator"/> class.
    /// </summary>
    /// <param name="expression">The expression tree to walk when calculating the has code.</param>
    public ExpressionHashCodeCalculator(Expression expression)
    {
        Visit(expression);
    }

    /// <summary>
    /// Gets the calculated hash code for the expression tree.
    /// </summary>
    public int Output
    { get; private set; }

    /// <summary>
    /// Calculates the hash code for the common <see cref="Expression"/> properties offered by the provided
    /// node before dispatching it to more specialized visit methods for further calculations.
    /// </summary>
    /// <inheritdoc/>
    public override Expression Visit(Expression node)
    {
        if (null == node)
            return null;

        Output += node.GetHashCode(node.NodeType, node.Type);

        return base.Visit(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitBinary(BinaryExpression node)
    {
        Output += node.GetHashCode(node.Method, node.IsLifted, node.IsLiftedToNull);

        return base.VisitBinary(node);
    }

    /// <inheritdoc/>
    protected override CatchBlock VisitCatchBlock(CatchBlock node)
    {
        Output += node.GetHashCode(node.Test);

        return base.VisitCatchBlock(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitConstant(ConstantExpression node)
    {
        IEnumerable nodeSequence = node.Value as IEnumerable;

        if (null == nodeSequence)
            Output += node.GetHashCode(node.Value);
        else
        {
            foreach (object item in nodeSequence)
            {
                Output += node.GetHashCode(item);
            }
        }

        return base.VisitConstant(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitDebugInfo(DebugInfoExpression node)
    {
        Output += node.GetHashCode(node.Document,
                                        node.EndColumn,
                                        node.EndLine,
                                        node.IsClear,
                                        node.StartColumn,
                                        node.StartLine);

        return base.VisitDebugInfo(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitDynamic(DynamicExpression node)
    {
        Output += node.GetHashCode(node.Binder, node.DelegateType);

        return base.VisitDynamic(node);
    }

    /// <inheritdoc/>
    protected override ElementInit VisitElementInit(ElementInit node)
    {
        Output += node.GetHashCode(node.AddMethod);

        return base.VisitElementInit(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitGoto(GotoExpression node)
    {
        Output += node.GetHashCode(node.Kind);

        return base.VisitGoto(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitIndex(IndexExpression node)
    {
        Output += node.GetHashCode(node.Indexer);

        return base.VisitIndex(node);
    }

    /// <inheritdoc/>
    protected override LabelTarget VisitLabelTarget(LabelTarget node)
    {
        Output += node.GetHashCode(node.Name, node.Type);

        return base.VisitLabelTarget(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitLambda<T>(Expression<T> node)
    {
        Output += node.GetHashCode(node.Name, node.ReturnType, node.TailCall);

        return base.VisitLambda(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitMember(MemberExpression node)
    {
        Output += node.GetHashCode(node.Member);

        return base.VisitMember(node);
    }

    /// <inheritdoc/>
    protected override MemberBinding VisitMemberBinding(MemberBinding node)
    {
        Output += node.GetHashCode(node.BindingType, node.Member);

        return base.VisitMemberBinding(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitMethodCall(MethodCallExpression node)
    {
        Output += node.GetHashCode(node.Method);

        return base.VisitMethodCall(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitNew(NewExpression node)
    {
        Output += node.GetHashCode(node.Constructor);

        return base.VisitNew(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitParameter(ParameterExpression node)
    {
        Output += node.GetHashCode(node.IsByRef);

        return base.VisitParameter(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitSwitch(SwitchExpression node)
    {
        Output += node.GetHashCode(node.Comparison);

        return base.VisitSwitch(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitTypeBinary(TypeBinaryExpression node)
    {
        Output += node.GetHashCode(node.TypeOperand);

        return base.VisitTypeBinary(node);
    }

    /// <inheritdoc/>
    protected override Expression VisitUnary(UnaryExpression node)
    {
        Output += node.GetHashCode(node.IsLifted, node.IsLiftedToNull, node.Method);

        return base.VisitUnary(node);
    }
}

As you can see from the above code, the general method for calculating the hash code of a given expression is by visiting all its manifestations and parts and then generating hash codes from the properties significant to those parts.

The GetHashCode methods being invoked in the code are not native to the types they are being invoked on. Rather, they are extension methods, and are something I talked about in another article I wrote.

Each part of the calculate tacks on the total value of the various parts to an Output property, which holds the running total for our hash code. Calculation will end upon our Visit override being executed with a null node being passed.

There are many virtual Visit[x] methods offered by the ExpressionVisitor type. As I stated in the first article of this series, there were in general a large number of new types of expressions added to the .NET framework with 4.0.

When creating our ExpressionComparison class, we overrode many of these methods, but only the ones that held some bearing on the actual shape of the expression as far as an equality check was concerned. The same applies to our hash code calculator; it visits many of the same parts as was visited by the equality comparer, with some differences, namely, some overrides found in ExpressionComparison are not found in ExpressionHashCodeCalculator, and vice versa.

The reasons for not overriding a particular virtual method typically boil down to a lack of properties offered from which to grab hash codes that wouldn’t be offered in another, more centrally invoked override.

For example, one virtual method not overridden is the VisitBlock, method. This method accepts a single BlockExpression typed parameter. If we look at the BlockExpression type, we’ll notice that it offers no additional properties unique to what’s offered by more base Expression types. Well…at least except for the Result property. But even the presence of this property is not cause enough for us to override the method, the reason being that the Result property itself (which is an Expression) is visited by the base VisitBlock implementation, and therefore would be end up being visited by another block of our code anyways.

There are a few more methods not included, but I’ll leave them as an exercise for the reader.

If anyone finds any types of expressions that the above code does not account for, I’d appreciate your input. When constructing this code, however, I tried to be fairly exhaustive in my efforts.

 

This article is meant to serve as a reference for a particular set of functions that may be present in code snippets found in subsequent articles.

Every so often one may find themselves tasked with writing hash code generation algorithms for a particular type of object. This sort of requirement typically arises whenever we’re authoring either a value type or an implementation of an interface which requires such functionality (e.g. IEqualityComparer<T>).

While the way hash codes end up being calculated tends to differ between object types, hash code generation mechanisms can only be considered proper if the following requisites are met:

  1. If two objects are deemed equal, then the hash code generation mechanism should yield an identical value for each object.
  2. Given an instance of an object, its hash code should never change (thus using mutable objects as hash keys and actually mutating them is generally a bad idea).
  3. Although it is acceptable for the same hash code to be generated for objects instances which are not equal, the way in which the hash code is calculated should be such so that these kinds of collisions are as infrequent as possible.
  4. Calculation of the hash code should not be an expensive endeavor.
  5. The generation mechanism should never throw an exception.

Naturally, it makes sense to abstract the steps involved in satisfying such requirements into an independent function which can be used by any kind of object. Unfortunately, for the most part, it simply isn’t possible to guarantee the satisfaction of  points #1 and #2 with common code. We can, however, build something that contributes towards the success of #3.

To do this, we can create a set of functions that calculate a hash code based on the property values provided to them, with each function differing in the number of properties that they accept. A static helper class could serve as a home for these functions, but since I like to avoid static helper classes whenever possible, I thought it prudent to craft them as extension methods instead, such as the one shown below:

GetHashCode<TFirstProperty,TSecondProperty>
/// <summary>
/// Calculates the hash code for an object using two of the object's properties.
/// </summary>
/// <param name="value">The object we're creating the hash code for.</param>
/// <typeparam name="TFirstProperty">The type of the first property the hash is based on.</typeparam>
/// <typeparam name="TSecondProperty">The type of the second property the hash is based on.</typeparam>
/// <param name="firstProperty">The first property of the object to use in calculating the hash.</param>
/// <param name="secondProperty">The second property of the object to use in calculating the hash.</param>
/// <returns>
/// A hash code for <c>value</c> based on the values of the provided properties.
/// </returns>
/// ReSharper disable UnusedParameter.Global
public static int GetHashCode<TFirstProperty,TSecondProperty>([NotNull]this object value,
                                                              TFirstProperty firstProperty,
                                                              TSecondProperty secondProperty)
{
    unchecked
    {
        int hash = 17;

        if (!firstProperty.IsNull())
            hash = hash * 23 + firstProperty.GetHashCode();
        if (!secondProperty.IsNull())
            hash = hash * 23 + secondProperty.GetHashCode();

        return hash;
    }
}

Note: IsNull is another extension method that properly deals with checking if an instance is null when we don’t know whether we’re dealing with a value or reference type.

We’re using two prime numbers (17 and 23) for our seeds to aid in the effort of reducing collisions. It can be argued that they are not optimal; however, that would most likely end up being a weak argument, and such a discussion is not even in the scope of this article. The values originate from other sources out there that address the issue of collisions (e.g. stackoverflow.com). We have the code inside an unchecked block so that overflows do not result in exceptions.

Again, this could easily be placed into a helper class instead; regardless, I wanted to tap into the portability offered by extension methods. Also, given that all objects have a GetHashCode method, I don’t view the extension of the object type in this manner as harmful, even if we aren’t actually using the source object itself.

I have about six of these methods, with the number of parameters accepted ranging from one to six. All of this is neither earth shattering nor rocket science. As I stated at the beginning, I’m mainly sharing this with you, the reader, so I can refer to this if questions arise from their usage in articles subsequent to this one.

 

As I have stated elsewhere on this site, it is my intent to limit the scope of the articles I write to areas that fall within my field of expertise. Once again, however, I desire to break away from my usual routine to cover another legislative issue making the rounds in the current events sphere; namely, the bill recently passed by Congress to avert the “fiscal cliff” (H.R. 8).

Whenever a great deal of press is being generated by a piece of legislation, I always find it most informative and therapeutic to ignore most of the chatter and read the raw text of the bill yourself. Obviously, this will allow one to reach their own conclusions regarding the item(s) at hand.

If the first paragraph has not made this clear to you already: know that I am neither a lawyer nor an economist.

Objective and Scope

My intention at the onset of analyzing the newly made law was to determine exactly how the “fiscal cliff” was averted. I had studied this issue before when the Budget Control Act of 2011 was passed in order to understand the inner workings of the sequestration mechanism, and had gained such an understanding to an adequate degree. Thus, as soon as H.R. 8 was passed on January 2nd, I wanted to find out answers to the following questions:

  1. Were the automatic sequestration cuts avoided by reaching the budget goal within the parameters set forth in the Budget Control Act of 2011?
  2. Were the automatic sequestration cuts avoided simply by amending the nature of the budget goal’s enforcement?
  3. How does H.R. 8 impact the long term deficit reduction goal?

Analysis

The specific piece of legislation here is titled as the American Taxpayer Relief Act of 2012. It is a large document, however only a small portion of it is relevant to the objective at hand. Specifically, we’re going to be taking a look at the majority of Section 901, which makes modifications to various aspects of the sequestration mechanism.

It is an amendment to the same section in the Balanced Budget and Emergency Deficit Control Act of 1985 that was amended by the Budget Control Act of 2011 in order to (in part) create the much talked about automatic deficit reductions. Of course, because it is an amendment, simply reading it doesn’t tell you so much, as you should immediately see upon reading it.

Total Deficit Reduction Calculation Changes

The first paragraph we’ll be poring over is Section 901(a), which makes modifications to the enforcement mechanism of the automatic sequestration cuts.

Section 901(a) of the American Taxpayer Relief Act of 2012
(a) Adjustment- Section 251A(3) of the Balanced Budget and Emergency Deficit Control Act of 1985 is amended--
 (1) in subparagraph (C), by striking `and' after the semicolon;
 (2) in subparagraph (D), by striking the period and inserting` ; and'; and
 (3) by inserting at the end the following:
 `(E) for fiscal year 2013, reducing the amount calculated under subparagraphs (A) through (D) by $24,000,000,000.'.

Hmm, although incremental changelogs are swell, this isn’t very helpful without seeing the text that’s being amended. Remember, Section 251A didn’t even exist in the Balanced Budget and Emergency Deficit Control Act of 1985 until the Budget Control Act of 2011 was passed. Let’s take a look at the effective text of Section 251A(3) of the BCA as it existed before this most recent law, then:

Section 251A(3) of the Balanced Budget and Emergency Deficit Control Act of 1985 as amended by Section 302(a) of the Budget Control Act of 2011
(3) CALCULATION OF TOTAL DEFICIT REDUCTION- OMB shall calculate the amount of the deficit reduction required by this section for each of fiscal years 2013 through 2021 by--
 (A) starting with $1,200,000,000,000;
 (B) subtracting the amount of deficit reduction achieved by the enactment of a joint committee bill, as provided in section 401(b)(3)(B)(i)(II) of the Budget Control Act of 2011;
 (C) reducing the difference by 18 percent to account for debt service; and
 (D) dividing the result by 9.

So, because of the amendment put in place by the American Taxpayer Relief Act, this text now looks like:

Section 251A(3) of the Balanced Budget and Emergency Deficit Control Act of 1985 as amended by Section 901(a) of the American Taxpayer Relief Act of 2012
(3) CALCULATION OF TOTAL DEFICIT REDUCTION- OMB shall calculate the amount of the deficit reduction required by this section for each of fiscal years 2013 through 2021 by--
 (A) starting with $1,200,000,000,000;
 (B) subtracting the amount of deficit reduction achieved by the enactment of a joint committee bill, as provided in section 401(b)(3)(B)(i)(II) of the Budget Control Act of 2011;
 (C) reducing the difference by 18 percent to account for debt service;
 (D) dividing the result by 9; and for fiscal year 2013, reducing the amount calculated under subparagraphs (A) through (D) by $24,000,000,000.

Alright. So, the total deficit reduction prior to this most recent law being passed would have been equal to 82% of the difference between $1,200,000,000,000 and an unknown amount which we have to calculate, all divided by 9 (which I assume refers to the time frame of this deficit reduction plan). However, with the American Taxpayer Relief Act of 2012, that value is being reduced by $24,000,000 for just this year.

In order to figure out the significance of the $24,000,000,000, we’ll need to fill in the rest of this little puzzle here by taking a look at Section 401(b)(3)(B)(i)(II).

See? Isn’t reading the law fun? It’s like a bunch of GOTO statements that control your life!

Section 401(b)(3)(B) of the Budget Control Act of 2011
(B) REPORT, RECOMMENDATIONS, AND LEGISLATIVE LANGUAGE-
 (i) IN GENERAL- Not later than November 23, 2011, the joint committee shall vote on--
 (I) a report that contains a detailed statement of the findings, conclusions, and recommendations of the joint committee and the estimate of the Congressional Budget Office required by paragraph (5)(D)(ii); and
 (II) proposed legislative language to carry out such recommendations as described in subclause (I), which shall include a statement of the deficit reduction achieved by the legislation over the period of fiscal years 2012 to 2021.

Ah yes, we can see the Joint Select Committee on Deficit Reduction being referred to in subclause (II). Well, as we all know, the committee failed to reach an agreement and was terminated January 31st, 2012. So, I guess that value comes out to be “0″.

Using this knowledge, we now know that the previously required deficit reduction for 2012 was in the ballpark of $109,333,333,333. With the recent law being passed, that figure has dropped to around $85,333,333,333.

So we now know that the part of the law which essentially both triggered and determined the amount of the automatic cuts was changed to be “less severe”. While interesting, this does not, at least by itself, tell us how the “fiscal cliff” was averted. So we read on.

Postponement of the Sequestration Date

The next part of Section 901 is purely temporal in nature.

Section 901(b) and 901(c) of the American Taxpayer Relief Act of 2012
(b) After Session Sequester- Notwithstanding any other provision of law, the fiscal year 2013 spending reductions required by section 251(a)(1) of the Balanced Budget and Emergency Deficit Control Act of 1985 shall be evaluated and implemented on March 27, 2013.
(c) Postponement of Budget Control Act Sequester for Fiscal Year 2013- Section 251A of the Balanced Budget and Emergency Deficit Control Act of 1985 is amended--
 (1) in paragraph (4), by striking `January 2, 2013' and inserting `March 1, 2013'; and
 (2) in paragraph (7)(A), by striking `January 2, 2013' and inserting `March 1, 2013'.

Although nothing in the above paragraphs explicitly state that the point in time in which the automatic cuts would occur has been delayed, the amending of dates in the law would certainly seem to indicate so. The first paragraph mentions the date March 27th, 2013, and the second paragraph throws March 1st, 2013 at us.

The former is applied “globally”, whereas the latter replaces “January 2, 2013″ in the following texts:

Section 251A(4) of the Balanced Budget and Emergency Deficit Act of 1985 as amended by Section 302(a) of the Budget Control Act of 2011
(4) ALLOCATION TO FUNCTIONS.—On January 2, 2013, for
 fiscal year 2013, and in its sequestration preview report for
 fiscal years 2014 through 2021 pursuant to section 254(c), OMB
 shall allocate half of the total reduction calculated pursuant
 to paragraph (3) for that year to discretionary appropriations
 and direct spending accounts within function 050 (defense function)
 and half to accounts in all other functions (nondefense
 functions).
Section 251A(7)(A) of the Balanced Budget and Emergency Deficit Act of 1985 as amended by Section 302(a) of the Budget Control Act of 2011
(7) IMPLEMENTING DISCRETIONARY REDUCTIONS.—
 (A) FISCAL YEAR 2013.—On January 2, 2013, for fiscal
 year 2013, OMB shall calculate and the President shall
 order a sequestration, effective upon issuance and under
 the procedures set forth in section 253(f), to reduce each
 account within the security category or nonsecurity category
 by a dollar amount calculated by multiplying the
 baseline level of budgetary resources in that account at
 that time by a uniform percentage necessary to achieve—

So it is now quite apparent that the new law has changed the time at which the automatic cuts would occur for this year (and this year alone). While it is unclear to me as to the significance of throwing March 27th, 2013 into the mix, it is very clear that the “fiscal cliff” has not completely been averted, rather the point in time in which its true onus could be felt has merely been moved to March 1st, 2013.

Instead of happening now, the cuts, if they do happen, would occur on the aforementioned date. This would seem to further indicate that some additional legislation is required in order to avoid the automatic cuts; something which, in the political landscape today, is hardly guaranteed.

One Year Stagnation of Limits

Moving on, we see some adjustments being made to the discretionary appropriation limits for the current and ensuing fiscal years.

Section 901(d) of the American Taxpayer Relief Act of 2012
(d) Additional Adjustments-
 (1) SECTION 251- Paragraphs (2) and (3) of section 251(c) of the Balanced Budget and Emergency Deficit Control Act of 1985 are amended to read as follows:
 `(2) for fiscal year 2013--
 `(A) for the security category, as defined in section 250(c)(4)(B), $684,000,000,000 in budget authority; and
 `(B) for the nonsecurity category, as defined in section 250(c)(4)(A), $359,000,000,000 in budget authority;
 `(3) for fiscal year 2014--
 `(A) for the security category, $552,000,000,000 in budget authority; and
 `(B) for the nonsecurity category, $506,000,000,000 in budget authority;'.

You can find the dollar amounts being replaced by referring to the Budget Control Act of 2011, which was responsible for adding Section 251(c) to the 1985 bill.

Section 251(c) of the Balanced Budget and Emergency Deficit Control Act of 1985 as amended by the Budget Control Act of 2011
(c) DISCRETIONARY SPENDING LIMIT.—As used in this part,
 the term ‘discretionary spending limit’ means—
 (1) with respect to fiscal year 2012—
   (A) for the security category, $684,000,000,000 in new
budget authority; and
   (B) for the nonsecurity category, $359,000,000,000 in
new budget authority;
 (2) with respect to fiscal year 2013—
   (A) for the security category, $686,000,000,000 in new
budget authority; and
   (B) for the nonsecurity category, $361,000,000,000 in
new budget authority;

The most recent amendment effectively renders the discretionary spending limit in fiscal year 2013 to be identical to the limit in effect for 2012. I cannot offer any insight as to the “why” behind this, however, I can add that the spending limit, in the original text of the 2011 act, was meant to be increased each year through 2021.

It also defines the limits for the individual categories for fiscal year 2014. These previously were left as a sum total in the 2011 act. They appear to further reflect a shrinking military and a growing amount of spending in other things.

Voodoo Magic

Finally, the last bit of the recently passed American Taxpayer Relief Act of 2012 that I’ll cover deals with additional adjustments made to the limits done in a very interesting way.

Section 901(e) of the American Taxpayer Relief Act of 2012
(e) 2013 Sequester- On March 1, 2013, the President shall order a sequestration for fiscal year 2013 pursuant to section 251A of the Balanced Budget and Emergency Deficit Control Act of 1985, as amended by this section, pursuant to which, only for the purposes of the calculation in sections 251A(5)(A), 251A(6)(A), and 251A(7)(A), section 251(c)(2) shall be applied as if it read as follows:
 `(2) For fiscal year 2013--
 `(A) for the security category, $544,000,000,000 in budget authority; and
 `(B) for the nonsecurity category, $499,000,000,000 in budget authority;'.

A bit of voodoo going on here. The numbers above reflect the amount of spending that would be safe from being automatically cut in both the “nonsecurity category” and “security category”. The “security category” refers to all discretionary appropriations in budget function 050 (National Defense), whereas the “nonsecurity category” is every other category.

Even though the limits effective for 2013 now reflect what was amended by Section 251(c), this last amendment here instructs us to ignore those limits for several types of calculations. Instead of $684 billion for defense spending, $544 billion is now the limit. Regarding everything else, there is now a $499 billion limit instead of $361 billion. Seems to be a rather drastic reduction in the ratio between Defense to all other spending.

What to Take Away

One would do well to draw their own conclusions from the above data. For myself, I felt that my questions were, for the most part, answered, and that I gained the following insights:

  1. The automatic cuts were not averted under the original parameters of the 2011 act.
  2. The automatic cuts were averted, for now, simply by delaying the date at which they would occur.
  3. The amount of deficit reduction required in order to avoid the cuts for 2012 is now around $85,333,333,333, or around a 22% reduction in what it previously was.
  4. Given that the required amount of cuts has been reduced by 22% for this 2012, it does not seem that H.R.8 helps the overall deficit picture.
  5. The discretionary spending limits were amended to reflect the limits of last year in an attempt, I believe, to make up “lost ground” in the effort of reducing the deficit long term, although it would be preferable to have an official answer behind the adjustments as opposed to mere assumptions.
  6. The just mentioned spending limit adjustments, however, do not seem to actually reflect the effective limits, which are put in place by the magic of Section 901(e). The limits mentioned there seem to be the ones used in all the important calculations; I’m unsure exactly where they are not used.
  7. The limits mentioned in Section 901(e) are concerning somewhat both in the manner they’re introduced as well as both the large cut being made to defense spending and large allowance being granted to all other matters.

So, we’ve covered many things, and just in matters concerning the sequestration mechanism itself. I’m sure there are many other conclusions one could derive from the other portions of the law as well, but the strongest impression I’m left with is that incentivizing law makers to behave a certain way in order to avoid punishments meted out by the law, the very thing they malleate day to day, appears to be a pointless exercise.

© 2012-2013 Matt Weber. All Rights Reserved. Terms of Use.