dim Value1 as Double = 46.78
dim Value2 as Double = 1.509
dim Value3 as Currency = 46.78
dim Value4 as Currency = 1.509
dim Result1 as Double = Value1/Value2 ' = 31,00066
dim Result2 as Currency = Value3/Value4 ' = 31,1866The result of currency is incorrect! Why?
Currency apparently rounds down to 2 decimal places so the 1.509 becomes 1.50.
Should it round nearest, e.g. 1.509 to 1.51?
Better i take double …
Search for “currency” on the forum. There are several long threads about issues with 3rd decimals, both with Currency and Double when you reach large sums.
Also, which version of the IDE are you using? I believe there was a currency issue that was recently resolved.
Nope. Currency is 64-bit fixed-point number format that holds 15 digits to the left of the decimal point and 4 digits to the right. That’s some bug.
You are comparing to non-comparable divisions, a division by a Double and a division by a Currency - you will get different results:
Double / Double <> Currency / Currency
What you want to compare is:
Double / Double = Currency / Double
Which gives you the correct result:
dim Result1 as Double = Value1/Value2 ' = 31,00066
dim Result2 as Currency = Value3/Value2 ' = 31,0007
Doubles almost never can hold the intended value:
dim Value1 as Double = 46.78
dim Value2 as Double = 1.509
dim v1 As Double = Value1 // v1 is 46.7800000000000011
dim v2 as Double = Value2 // v2 is 1.5089999999999999
But they should at least be close. In this instance, they are way off. The currency value is obviously being truncated.
Just checked and it is still broken in 2015r1.
There was a very long thread not long ago about that precise issue :
https://forum.xojo.com/15425-is-currency-data-type-really-usable
There were interesting suggestions there, including one from Bob Keeney I found especially interesting, to do everything in Int64, and convert when presenting the data.
thats what i was taught when leaning COBOL in the late 80’s. Funnily enough, almost every language i’ve used since has involved people (including me!) trying to use other types and eventually deciding there is only really one good way. use INTs and format it!
[quote=172492:@Michel Bujardet]There was a very long thread not long ago about that precise issue :
https://forum.xojo.com/15425-is-currency-data-type-really-usable
There were interesting suggestions there, including one from Bob Keeney I found especially interesting, to do everything in Int64, and convert when presenting the data.[/quote]
This is something you can do when you don’t have a Currency data type, but since it exists, it should be working or deprecated.
Again, what they do with the Currency is fundamentally the same, but hey, we can’t reinvent the wheel every time.
[quote=172508:@Massimo Valle]This is something you can do when you don’t have a Currency data type, but since it exists, it should be working or deprecated.
Again, what they do with the Currency is fundamentally the same, but hey, we can’t reinvent the wheel every time.[/quote]
I agree, it should work reliably. You did good filing the bug report https://xojo.com/issue/35189
Until the issue is resolved, though, we cannot sit on our hands and moan. Users expect applications to work, especially when it involves money, and I doubt they care if one had to reinvent the wheel to make it so.
I did not follow the whole Thread, but i had been hit by theese issues a few times already.
Why not just use only Double and present it to the user with Format(Double, “-#.00”)?
[quote=172514:@Sascha S]I did not follow the whole Thread, but i had been hit by theese issues a few times already.
Why not just use only Double and present it to the user with Format(Double, “-#.00”)?[/quote]
Because Double create rounding errors and this is not allowed when you handle money.
Cobol , being a business oriented language , had a BCD type I’d kill for.
I’ve worked in it and a couple other language primarily for accounting apps and BCD is wonderful for that purpose.
[quote=172514:@Sascha S]I did not follow the whole Thread, but i had been hit by theese issues a few times already.
Why not just use only Double and present it to the user with Format(Double, “-#.00”)?[/quote]
With large enough values doubles will lose precision
2015r1
and yes, i use only double with Format(Double, “-#.00”)
exists another way?
In the Windows version 2013r2 the results are correct.
31.00066 (double)
31.0006 (currency)
Just for fun I tried them as integers, scaled as necessary. On Windows 7, Xojo 2015r1
[quote] dim Value1 as Double = 46.78
dim Value2 as Double = 1.509
dim Value3 as Currency = 46.78
dim Value4 as Currency = 1.509
Dim Value5 As UInt64 = 4678000000
Dim Value6 As UInt64 = 1509
dim Result1 as Double = Value1/Value2 ’ = 31,00066
dim Result2 as Currency = Value3/Value4 ’ = 31,1866
dim Result3 as UInt64 = Value5/Value6 ’ = 3100066
[/quote]
Since Doubles and Integers are in agreement I can only assume that Currency is doing something wrong.