XML Dump random problem with VDouble

[Ruslan Zasukhin]

On 22/3/07 9:18 AM, "Thorsten Hohage" <thohage at objectmanufactur.com> wrote:

>> You use DOUBLE value to keep money value?
>> 
>> This is not a good idea. DOUBLE is not infinite sequence in the
>> computer
>> CPU.
>> 
>> Better use STRING
>> or I have hear people use 2 INT fields:
>> 
>>         194.25  =>  194 and 25
> 
> 
> and what are the next steps, then?
> 
> Writing my own "library" dealing with money values stored in two
> different Integers?

No, I think just combine them back into double when you read from db.

> Always convert String <> Double - do operation here - Double <>
> String??? Only when looking at this single task converting between
> String and Double it could be a source of endless errors when you're
> not living in the "default local area" and especially when you using RB.
> 
> Several years ago, we tend to simply shift the decimal separator by
> multiplication of 10^n and use ONE Integer to store. The advantage a
> lot of mathematical operations can be done even on this numbers, but
> in a lot of situations you're forced to define your own set of
> rules / methods for rounding.

Yes, this is another method. It can be used if size of single INT enough to
keep all significant digits
 
> Btw. the situation becomes much worse with the introduction of the
> Euro in Europe, when you need to deal with several different
> currencies. You must use seven(!) decimal places for calculations -
> a nightmare between "rounding stability" and "nice looking
> invoices" (without a1 + a2 + ... + aN <> sum(ai) )
> 
> 
> So a REAL currency field type would help a lot, where the "system"
> handle all the roundings for you, but I'm afraid this is a dream.

Yes, this is kind of challenge


-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]