Re: Intended behavior of automatic decimal point (bug 120940)

Hi all, commit fe1d819, [Bug 120940] "automatic decimal point & calculations fail" closed. Thanks for your input! Regards Frank Am 30.07.2017 um 09:04 schrieb David T.: > According to Wikipedia, there is no single format predominant. The green > areas in the picture below use commas, while

Re: Intended behavior of automatic decimal point (bug 120940)

According to Wikipedia, there is no single format predominant. The green areas in the picture below use commas, while the blue use a period. If the picture doesn’t make it through, Europe, West Africa and South America predominantly use commas, whereas The US, UK, East/Southern Africa, India,

Re: Intended behavior of automatic decimal point (bug 120940)

Frank, In common usage here in the US we call the decimal separator a period or decimal point depending on the context. As you know, we commonly call the thousands separator a comma. I think most coding languages treat both punctuation marks as separators when embedded in numbers, so that they

Re: Intended behavior of automatic decimal point (bug 120940)

Am 29.07.2017 um 13:13 schrieb David T.: > How about: > > Note: When a calculation is entered in the Amount field, the decimal is added > to every operand that omits a decimal. > > David When a calculation is entered in the Amount field, the decimal sign is inserted into every

Re: Intended behavior of automatic decimal point (bug 120940)

How about: Note: When a calculation is entered in the Amount field, the decimal is added to every operand that omits a decimal. David > On Jul 29, 2017, at 12:43 AM, Frank H. Ellenberger > wrote: > > Hi all, > > Am 28.07.2017 um 14:28 schrieb Christoph R: >>>

Re: Intended behavior of automatic decimal point (bug 120940)

Hi all, Am 28.07.2017 um 14:28 schrieb Christoph R: >> I agree that the only sane way to have auto-decimal is to disable it if the >> input is a formula. The other sane approach is to remove it completely. > > I cast my vote again: I never found the current behaviour buggy. I actually > think

Re: Intended behavior of automatic decimal point (bug 120940)

> I agree that the only sane way to have auto-decimal is to disable it if the > input is a formula. The other sane approach is to remove it completely. I cast my vote again: I never found the current behaviour buggy. I actually think it is pretty consistent: Any number without a point is

Re: Intended behavior of automatic decimal point (bug 120940)

Based on all this, I propose we remove auto-decimal feature in v2.8. Meanwhile, I will look for another bug to fix. Feel free to point me to a bug that could use some attention. Thanks, Sumit On Thu, Jul 27, 2017 at 8:24 PM, John Ralls wrote: > > > > On Jul 27, 2017, at

Re: Intended behavior of automatic decimal point (bug 120940)

> On Jul 27, 2017, at 6:27 PM, Eric Siegerman wrote: > > On Thu, Jul 27, 2017 at 08:20:50AM +, David T. via gnucash-devel wrote: >> 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

Re: Intended behavior of automatic decimal point (bug 120940)

On Thu, Jul 27, 2017 at 08:20:50AM +, David T. via gnucash-devel wrote: > 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. I'm not

Re: Intended behavior of automatic decimal point (bug 120940)

> 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

Re: Intended behavior of automatic decimal point (bug 120940)

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

Re: Intended behavior of automatic decimal point (bug 120940)

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 > : > > Sumit, > As I

Re: Intended behavior of automatic decimal point (bug 120940)

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

Intended behavior of automatic decimal point (bug 120940)

​Hi, In an attempt to fix a long-standing bug ( 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), I see this description for automatic decimal