This just started on A True History Book Three. I don't know if I hit a magic number for the spreadsheet to not multiply things properly or what, but the last cents don't read .96, they read .9599999999. I did send in an email on the Bookapy site about it but that was before I went into the hospital and I haven't seen a response.
SubTotal column on the Book Sales
Correct. That should simply be displaying the calculation of the book price multiplied by the number of units sold. The NET shows correctly, with only two decimal places.
Correct. That should simply be displaying the calculation of the book price multiplied by the number of units sold.
All of my books have a 2-decimal number in that column.
My guess would be that Lazeez isn't formatting the number optimally. Computers don't handle decimal portions of numbers perfectly, but they usually hold enough digits to be 'good enough'. However the end digits are usually not reliable. By default a spreadsheet won't show the last two or three digits but where there's a danger of the unreliability creeping in to the visible digits, it's up to the programmer to round them.
All those 9s suggest it will be several lifetimes before it affects how much you get paid.
AJ
My guess would be that Lazeez isn't formatting the number optimally.
This is a simple calculation. Let's say is was 25 sales time $5.99 price, it should display $149.75 because there's nothing to be unreliable here. Instead, for purposes of discussion, it's displaying $149.7499999999.
The number where it started showing this odd end behavior is considerably larger than $149.75, I'm just using that for example.
This is a simple calculation. Let's say is was 25 sales time $5.99 price, it should display $149.75 because there's nothing to be unreliable here. Instead, for purposes of discussion, it's displaying $149.7499999999.
That's a floating point number thing. All floating point numbers are approximations. There is a small amount of error in every floating point number, even if you use double precision floating point numbers you can't completely get rid of the error. Display enough decimal places and it will show up, just like that.
A floating point number can't even hold something super simple like 0.1 exactly. Display enough decimal places and eventually you get back 0.0999999999999
On the IBM mainframes they had a way around that. They called it Binary Coded Decimal(BCD). it was a fixed decimal point number stored where each digit of the number was stored as a nibble (4 bits). The IBM mainframes could do mathematical operations on the BCD numbers
but the last cents don't read .96, they read .9599999999
I didn't put a rounding function to make it look decent. I'm too busy with other stuff. I will get it fixed soon.
