On Thu, Aug 7, 2008 at 9:51 AM, Charles Day <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 7, 2008 at 1:48 AM, Christian Stimming <[EMAIL PROTECTED]>wrote: > >> Am Mittwoch, 6. August 2008 18:43 schrieb Charles Day: >> > On Thu, Jul 31, 2008 at 5:13 PM, Charles Day <[EMAIL PROTECTED]> wrote: >> > >> Sorry, yes, you're right. Here's a corrected second table: >> > >> >> > >> round force_fit decimal non-decimal >> > >> ===== ========= ======= ============= >> > >> 0 0 0.999 0 + 1/3 >> > >> 1 0 1.000 0 + 1/3 >> > >> 0 1 0.999 0.333 *a better example might be 2/3 >> > >> (prints as 0.666) >> > >> 1 1 1.000 0.333 *a better example might be 2/3 >> > >> (prints as 0.667) >> > > >> > > While I'm at it, shall I make 1/3 print simply as "1/3" instead of "0 >> + >> > > 1/3" in the first two cases? >> > >> > Can anyone confirm the intended meaning of the force_fit option? Shall I >> go >> > ahead with these changes? >> >> I can't confirm the *intended* meaning, but your explained meaning makes >> perfect sense to me. IMHO you can go ahead with these changes. >> > > When reading through the code again, I realized that "force_fit" works > slightly different than I thought. Without "force_fit" turned on, any number > of digits will be printed. So I think what I will do is just make fractions > always print as fractions and rounding will not work on them. > > If we need to display non-decimal numbers in decimal form, using either > truncation or rounding, then I think we need to add a new option of > "force_decimal". If you want me to add that option, let me know. Below is > the corrected (again) before and after. > > Let's say there is a decimal value of 9999/10000, a non-decimal value of > 2/3, and max_decimal_places is 3. Depending on how you set round and > force_fit, you CURRENTLY get the following output by calling > xaccPrintAmount(): > > round force_fit decimal non-decimal > ===== ========= ======= ============= > 0 0 0.9999 0 + 2/3 > 1 0 0.9999 0 + 2/3 > 0 1 0.999 0 + 2/3 > 1 1 1.000 0 + 4003/6000 > > After patching, this is how it would work. Only the non-decimal column is > different: > > round force_fit decimal non-decimal > ===== ========= ======= ============= > 0 0 0.9999 2/3 > 1 0 0.9999 2/3 > 0 1 0.999 2/3 > 1 1 1.000 2/3 > > If we add a "force_decimal" option (and I don't know that this is needed), > this is how it would work. Note that "force_decimal" implies using > max_decimal_places on non-decimals: > > round force_fit force_decimal decimal non-decimal > ===== ========= ============= ======= ============= > 0 0 0 0.9999 2/3 > 1 0 0 0.9999 2/3 > 0 1 0 0.999 2/3 > 1 1 0 1.000 2/3 > 0 0 1 0.9999 0.666 > 1 0 1 0.9999 0.667 > 0 1 1 0.999 0.666 > 1 1 1 1.000 0.667 > > So for now I will just write a patch to go from the first table to the > second. > Patch committed as r17457 with backport requested. > > >> Regards >> >> Christian >> > > Cheers, > Charles > _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
