When a character has a decimal value for unspend funds "ie 68.8" some times the output sheet is reporting a long string. See attached pcg & html file.

It doesn't seem to be a code bug because in the program the value moved appropriately when items are purchased.

None

Show:

Paul Grosse

December 28, 2013, 12:24 PM

FIrst reported here

http://paizo.com/threads/rzs2qgex?PCGen-PCGen-60200RC2-Released#12

Andrew Maitland

December 28, 2013, 12:40 PM

HTM isn't my strong suit here, any chance we can filter the output to only two places after the decimal?

Andrew Maitland

December 28, 2013, 1:26 PM

6.4 - At revision: 22684

6.2 - At revision: 22685

Mark Means

December 28, 2013, 1:38 PM

This is a single to double precision floating point error. In the OS code, somewhere it is converting a single precision floating point number to double precision. Certain numbers, like 6.8, are undefined and do not have an exact representation in either single or double precision. Commonly the core floating point math code will round the uncertain digit (for single precision, this is something like the 17th digit). But when converting to double precision, the nearest approximation of the original value is not near enough to the uncertain digit in the double precision number (like the 48th digit) to round to 6.8. There is two ways to handle this, code should either always use the same floating point depth or round the output. I think in PCGen, Every gold calculation should round to the least value coin, like copper, or 0.01. Not sure about the other game modes. However, an alternate way to handle this without any rounding, and to speed up all math calculations dealing with gold, a better way to hand this is with fixed point math. i.e. keep all wealth values as an integer total of the least value item. For Pathfinder, this is copper, so all values would be internally represented in copper pieces, and then displayed as copper/100 as gold. So the only conversion is done in the UI or OS code. This maintains data integrity no matter how many things are added or subtracted and you never get floating point imprecision in any total. Accounting packages use this approach, all monetary values are stored and manipulated as fixed point numbers, at least 5 decimals down (so 1/1,000th of a cent), so $ 1 would be stored internally as 100,000 thousandths of a cent.

Fixed

None

None

0m

0m

Minor