[ale] Database consulting in return for homebrew?

[Mike Harrison]

On Mon, 8 Dec 2008, Brian Pitts wrote:
> Michael B. Trausch wrote:
>> Sounds like MySQL still needs to gain NUMERIC support.  *shrugs*
Brian:
> It has it.
> http://dev.mysql.com/doc/refman/5.1/en/precision-math.html

Thanks for the link Brian, the issue isn't a MySQL or PHP or PERL one..
It's a programmer one. It's a keep the data and math at significant 
numbers issue, and display whatever you want issue. You should not be 
doing (usually) cumulative math with the displayed 
(rounded/shortened) numbers.

And that being said, there are times you make the display show the rounded
decimal places using the shortened numbers at mega/kilo resolutions with
displayed math that works using the rounded numbers... just to keep people 
sane.

For example, I do a lot of math with energy expressed in watts or 
watt/hours natively because my data gathering and vending devices are that 
exact. In other cases, I -vend- electricity in decawatthours, aka a tenth 
of a kilowatthour, and the tariffs are sometimes 6 decimal places per killowat 
hour. ie: .505695 per kWh. VAT taxes and fuel charges are also often 6 
decimal places per kWh.  MySQL works just fine, if you are careful. :)
When displaying, how you use sprintf, round() floor() and ceil()
are all very particular.

I'm in the process of replacing a system written in Delphi
and MS-SQL that has incredible math errors in it. It is possible
to do some vend/calculations 6 times in a row, and get answers
that vary by a tenth of a kWh each time, and the VAT taxes
vary by several cents each time. And the best part of their code:
In one part of their math it looks like a kWh is 1024 watts.
or at least, it's the only way I can make their math work
is if I use that value. And no, it's not in the customers favor.

Other weird note: in one country, by law, all math is rounded
in the customers favor, usually floor() in most parts
of the calculations.. In another, the utilities favor.

Guess which one is the government owned utility?

Cumulative error happens. By design.

Sometimes it even makes it to an interesting general ledger entry just so 
everything in the GL balances. I want to be the guy that gets to put that 
cumulative error in a checking account... Sigh.. But that ain't gonna 
happen. That's the CFO's job. :)