Intended behavior of automatic decimal point (bug 120940)

Christoph R subscriptions+listen at rohland.net
Thu Jul 27 06:05:53 EDT 2017


> 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. <sunfish62 at yahoo.com>:
> 
> 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
> <subscriptions+listen at rohland.net> 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 <gnucash-devel at gnucash.org <mailto:gnucash-devel at gnucash.org>>:
>> 
>> 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<bhardwajs at gmail.com <mailto:bhardwajs at gmail.com>> 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
>> gnucash-devel at gnucash.org <mailto:gnucash-devel at gnucash.org>
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel <https://lists.gnucash.org/mailman/listinfo/gnucash-devel>
>> 
>> 
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org <mailto:gnucash-devel at gnucash.org>
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel <https://lists.gnucash.org/mailman/listinfo/gnucash-devel>
> 



More information about the gnucash-devel mailing list