Re: Re: Fix floats like you do in your head

[tachyon]

Great links. As you say this is not a ceil() or a round() function which behaves in strict mathematical terms, nor does it attempt to solve any of the problems associated with doing decimal fp arithmetic in binary.

The beauty/purpose of it is that is does what a human tends to do. I see 0.9999999 and think 1 or 0.00999999 and think 0.01 which is what you get with the approx() function. I did call it approx() rather than exact(), actually() or really() ;-). I had it in mind for simple display functions not anything serious.

It also only works on the decimal fraction but could be extended to work on the integer component so 999999.9 or 1000000.1 would become 1,000,000.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[mojotoad]

No worries. After I went and perused your Math::Trig::Units work, it became evident that this wasn't an oversight on your part. Ah well, the links are there for posterity, in case anyone else wants to learn about it.

As for names...approx() works. How about fudge()?

At any rate, at least you know that we're dealing with a psychological tendency, here. With 6 sig figs, for example, 1.99999 is no more special than 1.46793 on a mathematical basis. On a psychological basis it is somewhat irritating because of our preference for nice, neat numbers.

Matt

[tachyon]

fudge() is good. I will add it as an alias. I couldn't think of anything better at the time. might_be() looks_like() probably() possibly() neaten() all seemed...well a little wishy washy.

You are of course right about the psychological tendency. That's why the marketers love $9.99 etc because it just seems less than a 10 spot. Still don't get much useful change though.

Do you know if there is anything in Perl that implements the standards. A Math::AcurateFloatingPoint class would be quite possible using Math::BigInt without too much work. You just need to delta to integers for the operations and then return the result as a float object (stringified of course to preserve accuracy). I don't know if there would be much demand though.

The stats about > 50% of database table numerical columns using floats (including financials) was interesting.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[mojotoad]

I think that might have already been done...in the Math::BigInt package we find the interesting Math::BigFloat. These modules will obey either precision (i.e., number of digits beyond the decimal point) as well as accuracy (i.e., significant digits/figures). That's their choice of terminology, precision vs. accuracy. I'm not sure if they properly apply the rules for sig figs when you get a new float from an operation involving two values with different sig figs.

I /msg'd you about this, but as I've thought more about this I like the name snap() for the function in question (yea, even better than fudge()). Because really, what's happening is a gravitation towards more psychologically appealing numbers -- no different than applying a layout grid on a canvas, and having things 'snap' towards the grid lines.

The problem with the BigInt stuff is probably always going to be speed (this is speculation on my part). Perhaps you can use native floats unless specified otherwise, in which case the operations shift into Math::BigFloat mode. (this should be reasonably transparent since the BigInt modules override operators for DWIMery).

Oh, also -- I found Math::FixedPrecision, which is built on top of Math::BigFloat. It appears to simplify precision math, i.e., nail down the number of decimal places. I see an analagous need here for a 'Math::SigFig' or somesuch. I notice that John Peacock, the author of Math::FixedPrecision, is also the author of Math::Currency -- one obvious application of precision arithmetic vs. significant figures.

Matt