> Put another way, the current behavior would result in the decimal being moved > four places on an entry like "1200/35", which would be at variance with the > actual setting.
Actually not since (1200/100)/(35/100) = 1200/35. But you are right for 1200*35 which yields 12.0*0.35 = 4.2. As a stupid user I accepted this behaviour as correct so far :-) Cheers, Christoph > Am 27.07.2017 um 10:20 schrieb David T. <[email protected]>: > > Christoph, > > I disagree, and clearly the people on the bug don't see it that way either. > > I think of the decimal placement as applying to the final number in the field > (as a sort of edit mask, if you will), rather than a preprocessing function > that would apply to every element in an equation. > > The current behavior yields different decimal placement results in the same > register, which is highly confusing. > > Put another way, the current behavior would result in the decimal being moved > four places on an entry like "1200/35", which would be at variance with the > actual setting. > > I can't see how that is appropriate. > > David > > > On Thu, Jul 27, 2017 at 11:04, Christoph R > <[email protected]> wrote: > I do not even see this as a bug. Any number without a decimal point is > divided by 100. Which makes the input “20.44/2” in fact 20.44/0.02 which is > 1,022.00 > > Cheers, > Christoph > >> Am 26.07.2017 um 09:58 schrieb David T. via gnucash-devel >> <[email protected] <mailto:[email protected]>>: >> >> Sumit, >> As I understand it, the example you gave (560 becomes 5.60) is intended >> behavior. And, as far as I am concerned, the explanation in the help is >> sufficient, if not inspiring. >> It seems to me the problem in the underlying bug is that the decimal >> algorithm needs to be applied after any calculations, but that is not how >> it's being done. The age of the bug suggests that the feature is not heavily >> used, or that users have worked around the oddity. >> David >> >> >> >> On Wed, Jul 26, 2017 at 11:50, Sumit Bhardwaj<[email protected] >> <mailto:[email protected]>> wrote: Hi, >> >> In an attempt to fix a long-standing bug ( >> https://bugzilla.gnome.org/show_bug.cgi?id=120940 >> <https://bugzilla.gnome.org/show_bug.cgi?id=120940>), I looked at the code >> and have a question on intended behavior of automatic decimal point. >> >> From the doc (http://gnucash.org/viewdoc.phtml?doc=help >> <http://gnucash.org/viewdoc.phtml?doc=help>), I see this >> description for automatic decimal point. >>> *Automatic Decimal Point:* This option will automatically insert a >> decimal point into numbers you type in. >> >> It's not clear from the help that "560" will be converted to "5.60" with >> automatic decimal points set to 2. Is that the intended behavior? If so, >> should we edit the help? >> >> There is a bug in handling the fractions when auto-decimal points. I can >> try to fix that, but wanted to get the developers' take on the intended >> behavior first. >> >> Thanks, >> Sumit >> _______________________________________________ >> gnucash-devel mailing list >> [email protected] <mailto:[email protected]> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> <https://lists.gnucash.org/mailman/listinfo/gnucash-devel> >> >> >> _______________________________________________ >> gnucash-devel mailing list >> [email protected] <mailto:[email protected]> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> <https://lists.gnucash.org/mailman/listinfo/gnucash-devel> > _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
