>>>>>Calvin,
>>>>>
>>>>>According the the VFP5 help file:
>>>>>
>>>>>If you specify more than four decimal places in a currency expression, Visual FoxPro rounds to four places before evaluating the expression.
>>>>>
>>>>>So it's working as documented the 0.41116 is being rounded to 0.4112 before the expression is evaluated. You may have to take the currency numeric to get the precision you need during the operation.
>>>>>
>>>>>snip...
>>>
>>>>Another case of failing to RTFM...just be glad we're not doing C - I'm in working today because someone failed to properly cast some pointers to structures before doing some (in theory) simple pointer math....
>>>
>>>
>>>Well Ed, I reckon just because it works like the manual says doesn't make it right. 'Correct' maybe, but not 'right'. Doesn't this mean really that we should avoid the currency type? I do, :-), but for other reasons, like the way it displays in a grid.
>>
>>From my POV, yes, because of the types of rounding errors that may be accidentally introduced when the precision of an intermediate computation exceeds the precision supported by a currency field. For addition, or even multiplicative, operations where the final precision of a computation uses fewer decimal places than the precision of the currency field, and where rounding forced by reduced precision of the intermediate computation is better than the result of inexact representation due to magnitude of a floating point number, the currency data type is a better choice. I only wish that VFP supported something like a scalable 80 bit BCD type...
>>
>>IOW, if you need to compute a value with more precision than currency supports, don't use currency. If fixed precision is a bigger issue for you, then currency or another fixed decimal representation is a better choice (there are a whole range of values that would display as .000100, two decimal places better precision than used for currency, that would not all be exactly equal for comparison purposes.) That's the tradeoff in the two representations.
>>
>>Ed
>
>Ok, that's a good technical summary of what's going on. In practice then the everyday developer needs to understand the tradeoff. 'N(16,2)' is going to give generally better results but take up twice the storage space of 'Y'.

Within reason. If your primary issue is adding columns of things together, and you round after each stage of computation, currency is fine where 2 decimal places of representation is adequate, and none of the values require more decimal places of accuracy. IOW, if you're using the 'Y' data type, the value of which is never needed to more than 2 decimals, and you never need to multiply by a number with more than 2 decimal places to the right of the decimal, currency works fine. If you have a result where rounding an operand or a result to the decimal precision of currency causes a problem, then currency is a bad choice. The same would be the case if we had an integer type which, if used in computation, forced all operations to be done with integers. there's nothing inherently wrong with an integer type, it just isn't suited to being used for decimal computation if the operands are coerced to the least precise representation, and decimal fractions or floating point numbers are involved.

IOW, know what you have to do, and how your language will behave, before using a feature. I lucked out - I correctly interpreted how currency would behave. Others might not read the docs the same way. I tested to find out what would happen before commiting to using the currency feature.