Good day.

I came from Java world, where 'double' type inadequate for money calculation. BigDecimal serves for it. This is ugly type, but gives precise results.

Which type I must use for money in D?

On 1/1/20 10:41 AM, Vitaly Livshic wrote:
> Good day.
> 
> I came from Java world, where 'double' type inadequate for money calculation. BigDecimal serves for it. This is ugly type, but gives precise results.
> 
> Which type I must use for money in D?

I generally used a fixed-point type. Recently, I was going to use a project in code.dlang.org called fixed, but the string-based constructor uses a conversion to double first, negating the precision of a fixed point type.

Another developer is making a new fixed point type here: https://github.com/m3m0ry/fixedpoint

But it's not completely ready yet.

-Steve

On Wednesday, 1 January 2020 at 15:41:32 UTC, Vitaly Livshic wrote:
> Good day.
>
> I came from Java world, where 'double' type inadequate for money calculation. BigDecimal serves for it. This is ugly type, but gives precise results.
>
> Which type I must use for money in D?

There's a BigInt type in the standard library which might work - https://dlang.org/phobos/std_bigint.html

 Thanks Steve, JN.

 JN, BigInt is big integer. It cannot works with fractional numbers. It is sadly, that wide-spread languages have no convinient money type. This is abnormal.
 Hope, D will have fixed point type either as built-in type or library.

On Wednesday, 1 January 2020 at 18:16:01 UTC, Vitaly Livshic wrote:
>  Thanks Steve, JN.
>
>  JN, BigInt is big integer. It cannot works with fractional numbers. It is sadly, that wide-spread languages have no convinient money type. This is abnormal.
>  Hope, D will have fixed point type either as built-in type or library.

That's probably because there is no standard how to deal with currencies. Think about Shillings and it goes 12 pence on one Shilling, weird stuff like that.

Also why use fixed point? Why not have currency * 100 as there goes hundred cents in one base currency, for many currencies. To convert it back you just divide by 100 and you get the value and the cent value. Well * 100 is fixed point, but in computer land fixed point usually means some scale factor of the power of 2.

On 1/1/20 1:46 PM, IGotD- wrote:
> On Wednesday, 1 January 2020 at 18:16:01 UTC, Vitaly Livshic wrote:
>>  Thanks Steve, JN.
>>
>>  JN, BigInt is big integer. It cannot works with fractional numbers. It is sadly, that wide-spread languages have no convinient money type. This is abnormal.
>>  Hope, D will have fixed point type either as built-in type or library.
> 
> That's probably because there is no standard how to deal with currencies. Think about Shillings and it goes 12 pence on one Shilling, weird stuff like that.

Well, that is just odd, as you then need 2 number systems, one with base 12, and one with base 10. Probably best to split that into a byte for pence and some other integer for the shillings.

> 
> Also why use fixed point? Why not have currency * 100 as there goes hundred cents in one base currency, for many currencies. To convert it back you just divide by 100 and you get the value and the cent value. Well * 100 is fixed point, but in computer land fixed point usually means some scale factor of the power of 2.

That is what I use. Fixed point with a factor of power of 10. In other words, a fixed point number with 2 decimal places would be sufficient for such currency. When doing math on such types, you just need to deal with the underlying numbers, and it works fine.

-Steve

On Wednesday, 1 January 2020 at 18:16:01 UTC, Vitaly Livshic wrote:
>  Thanks Steve, JN.
>
>  JN, BigInt is big integer. It cannot works with fractional numbers. It is sadly, that wide-spread languages have no convinient money type. This is abnormal.
>  Hope, D will have fixed point type either as built-in type or library.

https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency

> It cannot works with fractional numbers.

Nothing can give you a better answer if your fraction is 176/100. You can always convert from int to some other type without losing precision on the initial calculations if you're in a situation where you want to calculate the per-unit cost for 37 units that cost a total of $500.17.

On Wednesday, 1 January 2020 at 19:01:36 UTC, Steven Schveighoffer wrote:
> That is what I use. Fixed point with a factor of power of 10. In other words, a fixed point number with 2 decimal places would be sufficient for such currency. When doing math on such types, you just need to deal with the underlying numbers, and it works fine.

You don't need fixed point, just store cents in 64 bit floating point and you get at least the same accuracy as a 53 bit integer fixed point.

On 1/1/20 3:20 PM, Ola Fosheim Grøstad wrote:
> On Wednesday, 1 January 2020 at 19:01:36 UTC, Steven Schveighoffer wrote:
>> That is what I use. Fixed point with a factor of power of 10. In other words, a fixed point number with 2 decimal places would be sufficient for such currency. When doing math on such types, you just need to deal with the underlying numbers, and it works fine.
> 
> You don't need fixed point, just store cents in 64 bit floating point and you get at least the same accuracy as a 53 bit integer fixed point.
> 

It is stored that way. Stored as a long. Just nicer to deal with printing and such. And instead of having to remember the factor, it's stored with the type.

-Steve

On Wednesday, 1 January 2020 at 20:20:14 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 1 January 2020 at 19:01:36 UTC, Steven Schveighoffer wrote:
>> That is what I use. Fixed point with a factor of power of 10. In other words, a fixed point number with 2 decimal places would be sufficient for such currency. When doing math on such types, you just need to deal with the underlying numbers, and it works fine.
>
> You don't need fixed point, just store cents in 64 bit floating point and you get at least the same accuracy as a 53 bit integer fixed point.

Using floating point is not recommended. For some fractional number it is actually impossible to store the value as a rational binary number. For example 8.90 would be stored as 8.89999999999+ (in reality this is binary values so just think of my example in an equivalent binary value case). This would lead to some rounding errors, especially when chaining several operations.

You should go for a representation that always calculates the currency exact, down to the cent or whatever it is. Not doing so you might even be breaking the law for some appliances.