On Thu, Jul 31, 2008 at 5:13 PM, Charles Day <[EMAIL PROTECTED]> wrote:
> > > On Thu, Jul 31, 2008 at 10:19 AM, Charles Day <[EMAIL PROTECTED]> wrote: > >> >> >> On Thu, Jul 31, 2008 at 10:01 AM, Derek Atkins <[EMAIL PROTECTED]> wrote: >> >>> Quoting Charles Day <[EMAIL PROTECTED]>: >>> >>> Working this way would seem to make little sense. The first three cases >>>> print identically, and the last doesn't work for non-decimal values. >>>> Here's >>>> how I'm guessing it was intended to work: >>>> >>>> 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.999 >>>> 1 1 1.000 1.000 >>>> >>>> Is this correct? If so, I can readily provide a patch. >>>> >>> >>> I would expect given your inputs that the last two rows in the far >>> right column would both be 0.333 >> >> >> 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? >> >>> >>> Cheers, >>>> Charles >>>> >>> >>> -derek >>> >>> -- >>> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >>> Member, MIT Student Information Processing Board (SIPB) >>> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >>> [EMAIL PROTECTED] PGP key available >>> >>> >> > _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
