On Thursday, 2 January 2020 at 17:57:19 UTC, Ola Fosheim Grøstad wrote:
>
> So if you want the same representation on the server and the client then it can be useful to use 64bit floating point.

Disagree with that.

You shouldn't even do money calculations on the client side and thus you only need the representation of it and hence you can just send it formatted as a string.

Of course if your client is not JS or anything similar then there is no problem since you can represent the value just fine.

On Thursday, 2 January 2020 at 18:20:38 UTC, Ola Fosheim Grøstad wrote:
>
> You can set the rounding mode. Round to even is the common default I believe (bankers rounding). Although I think it is common to just round up at 0.5 when doing manual accounting.
>

You are right about this and the reason is that otherwise large numbers start being very inaccurate very fast.

On Thursday, 2 January 2020 at 18:26:25 UTC, Ola Fosheim Grøstad wrote:
> truncating.  E.g. you can do the same calculation twice with round up/round down and do basic rounding. If you get the same result, then it is right. But easy to make mistakes... like I just demonstrated.. :-P

For those interested there work done on a standard for doing exactly this (interval arithmetics) called IEEE1788:

https://en.wikipedia.org/wiki/Interval_arithmetic#IEEE_Std_1788-2015_%E2%80%93_IEEE_standard_for_interval_arithmetic

So all computations are done twice, once rounding up and once rounding down. If the error gets too large then you can switch to a slower algorithm. So then you can safely do base 2 floating points using fast hardware without all the issues and fall back on a slower base 10 software implementation where it fails.

On Thursday, 2 January 2020 at 18:30:54 UTC, bauss wrote:
> You shouldn't even do money calculations on the client side and thus you only need the representation of it and hence you can just send it formatted as a string.
>
> Of course if your client is not JS or anything similar then there is no problem since you can represent the value just fine.

As I've pointed out double can represent anything you can represent as 53 bits unsigned integers, so this is a non-issue...

It can be very useful to do calculations on currencies on the client side, but you don't use it for any other purpose than display.

On Thursday, 2 January 2020 at 19:03:47 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 2 January 2020 at 18:30:54 UTC, bauss wrote:
>> You shouldn't even do money calculations on the client side and thus you only need the representation of it and hence you can just send it formatted as a string.
>>
>> Of course if your client is not JS or anything similar then there is no problem since you can represent the value just fine.
>
> As I've pointed out double can represent anything you can represent as 53 bits unsigned integers, so this is a non-issue...
>
> It can be very useful to do calculations on currencies on the client side, but you don't use it for any other purpose than display.

I'll just throw out that Lua has no integer type:
https://www.lua.org/pil/2.3.html

I've never had a reason to avoid integers for performance reasons, but I suppose there are cases in which it's relevant...

On Thursday, 2 January 2020 at 19:12:11 UTC, bachmeier wrote:
> I've never had a reason to avoid integers for performance reasons, but I suppose there are cases in which it's relevant...

Scripting languages try to keep things simple, so having only one numeric type is an advantage from an implementation point of view. So, not really for performance.

However, if you mean fixed point integers, then you need a rather big bit width to avoid overflow errors to do the same calculations as with floating point. And it is easy to make mistakes, but older DSPs didn't have floating point units so they used fixed point math (and also older computer games) and programmers had to be very clever to make it perform well with good accuracy. In some ways fixed point is more tiresome than writing in assembly if you try to do something nontrivial.

E.g. in fixed point you would have to do 3% of 123 as (123*3+50)/100... Or 3.14% of 123 as (123*314+5000)/1000. Except division is slow so you would instead convert the divisor into a reciprocal and do a multiply instead (modern compilers do this for you if the divisor is known at compile time). So if the percentage isn't known at compile time you have much work to do as a programmer to get it right...

On Thursday, 2 January 2020 at 19:25:08 UTC, Ola Fosheim Grøstad wrote:
> (123*3+50)/100... Or 3.14% of 123 as (123*314+5000)/1000.

So easy to make mistakes with fixed point, should've been /10000...

> Except division is slow so you would instead convert the divisor into a reciprocal and do a multiply instead (modern compilers do this for you if the divisor is known at compile time).

Well, in this specific case you could probably do

     result=percentage*value

like this:

     result  = (value*percentage_reciprocal+5)/10;

but that is just one simple formula... it gets tricky real fast when trying to do something more advanced in fixed point efficiently and correctly.

On Thursday, 2 January 2020 at 19:12:11 UTC, bachmeier wrote:
> I'll just throw out that Lua has no integer type:
> https://www.lua.org/pil/2.3.html
>
> I've never had a reason to avoid integers for performance reasons, but I suppose there are cases in which it's relevant...

Lua 5.3 (released five years ago) has got integers. The text you are linking is 17 years old.

On Thursday, 2 January 2020 at 20:05:18 UTC, lithium iodate wrote:
> On Thursday, 2 January 2020 at 19:12:11 UTC, bachmeier wrote:
>> I'll just throw out that Lua has no integer type:
>> https://www.lua.org/pil/2.3.html
>>
>> I've never had a reason to avoid integers for performance reasons, but I suppose there are cases in which it's relevant...
>
> Lua 5.3 (released five years ago) has got integers. The text you are linking is 17 years old.

Okay, I'm not a Lua expert, obviously. The point still stands that you can have a successful programming language without even having an integer type.

On Thursday, 2 January 2020 at 21:03:42 UTC, bachmeier wrote:
> Okay, I'm not a Lua expert, obviously. The point still stands that you can have a successful programming language without even having an integer type.

*cough* *cough* JavaScript *cough*