Dodd: No one will know until this is actually in place how it works

Key House and Senate lawmakers approved far-reaching new financial rules early Friday after weeks of division, delay and frantic last-minute dealmaking. The dawn compromise set up a potential vote in both houses of Congress next week that could send the landmark legislation to President Obama by July 4.

The final and most arduous compromise began to fall into place just after midnight. Sen. Blanche Lincoln (D-Ark.) agreed to scale back a controversial provision that would have forced the nation's biggest banks to spin off their lucrative derivatives-dealing businesses.

The panel also reached accord on the "Volcker rule," named after former Federal Reserve chairman Paul Volcker. That measure would bar banks from trading with their own money, a practice known as proprietary trading.

Lawmakers pulled an all-nighter, wrapping up their work at 5:39 a.m. -- more than 20 messy, mind-numbing hours after they began Thursday morning.

"It's a great moment. I'm proud to have been here," said a teary-eyed Sen. Christopher J. Dodd (D-Conn.), who as chairman of the Senate Banking Committee led the effort in the Senate. "No one will know until this is actually in place how it works. But we believe we've done something that has been needed for a long time. It took a crisis to bring us to the point where we could actually get this job done."

It is an inherent precision of floating-point representations using binary arithmetic: but with enough bits for each floating point number, you can go to more and more precision before running into problems, e.g. IIRC, according to IEEE754 64-bit precision allowed floating point decimals from 10³⁰⁸ to 10^-308, much better than the range allowed by 32-bit precision.

That being said, you are right, there are some numbers which cannot be represented exactly using floating-opoint arithmetic, including (I think) the square root of two (or was it three?).

I recall working on optimizing an engineering simulation program where we had to turn off compiler options in order to get the answers to come out right: the compiler was taking a group of operands and rearranging the order they were being added in -- with the side effect that some of the smaller numbers were "dropped" as rounding errors. We had to change the code by hand so that it sorted the numbers first, and then began adding from smallest to largest...

Cheers!

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.