Thanks for splitting the thread Guru. The links worked fine for me.
Dennis, I can definitely appreciate your attention to detail here. Firstly, I've interrogated the economic data in as much detail as was availble to me over the past many years. I find there are many assumptions that can alter the amount of child support by a few dollars one way or the other, and sometimes much more than that. I can see where Dr. Pelkowski had to made a decision as to what assumptions to make, and how many significant digits would be required to best fit the economic data while keeping the functions concise.
Speaking to your comment about significant digits. I would agree that technically speaking, the exponent trailing zeros should be carried, and the scaling percentages should be presented to the same degree of precision. However, even if the trailing zeros are carried out to infinity, the calculation doesn't change, only the precision of the solution. Since we are aiming at a solution rounded to the nearest whole dollar, the trailing zeros will not effect the result, but the degree of precision used to round the solution may. I have made the assupmtion that the degree of precision is implied at 10 places. So if only 8 or 9 are given, I assume the additional digits are zeros.
Keep in mind that most computers these days are 32 bit (64 bit is still emerging). Which means even a PC can only express an integer of 2^32 or 4294967296. When you are calculating a floating point number, you must reduce the number of significant digits to allow for the exponent, so being able to carry floating point precision past about 6 significant digits is beyond 32 bit computing. It is possible to create a program to store more precision, but I think that discussion is beyond the scope of our discussion. I target my comment around 32 bit computing because I would suspect that the vast majority of child support awards have been calculated using 32 bit computing using IEEE single precision binary floating-point.
Your comment three about rounding and the scaling percentages leads me to believe that Dr. Pelkowski has probably performed all calculations in a spreadsheet and even though a certain number of digits can be shown in a cell, more precision is carried. So, its possible that 80.1% was used to derive the tables, but 80% has been published. Again, I believe the prescribed equations were given as a means to calculate child support beyond the tabled values rather than to derive the tables. However, I am in complete agreement with you that the presented equations should allow for the exact derivation of the tabled values to eliminate discussions such as this one. If they do not, it generates technical questions and ultimately different calculation methods do not arrive at the same child support award.
A side note - I speak only from my personal experience and observation, but it does not appear to me that the child support committee is attended by anyone other than Dr. Pelkowski who posesses the level of expertise to discover such mathematical errors. There have been small things recently which should have been caught before release. Such as the committees publishing "percentage child support increase" which showed change of only 0.10. Having performed all the calculations myself, I knew this really meant 10.0%. But, when someone technically inclined reads a report which clearly states "percentage child support increase," the data is technically incorrect. Keeping these kinds of errors out of the guidelines is important.
I'm not sure how to respond about your comment five other than I would suspect the committee went with their best judgement and the advisement of the economist to arrive at the 92% and 80% values based on the presented data. I would bet a few numbers were presented, and the committee voted to adopt whatever seemed to minimize complications. But, for me, it makes no difference if I multiply by .80 or .8065. Maybe, the simpler number looks better on paper to some.
I can see your second point, but I would have to kindly disagree. In my profession (engineering), I see numbers like these every day. the number X*Y^Z is very clear because of order of operations. If the equation were written Y^Z*X, as you have suggested, I would be very confused. Now if the same equation were written as (Y^Z)*X, it would then again be perfectly clear. Same as X*(Y^Z). With the parenthases you can see the commutative property better. I don't think there is anything technically wrong with the presentation of the equations, as you have also mentioned. Whether the equations have been presented for a more technical audience, is up to the audience I suppose.