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

[Frank H. Ellenberger]

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 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, 
> China and Australia use the period.
> 
> Your markup and changes are fine, although I think “decimal sign” would be 
> simpler as just “decimal,” leaving “decimal separator” in the second spot.
> 
> Finally, can I assume that this function correctly inserts a comma when the 
> locale recommends it, or is it always a period?
> 
> David
> 
> 
> 
>> On Jul 30, 2017, at 3:51 AM, Frank H. Ellenberger 
>>  wrote:
>>
>> 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 operand that omits a decimal separator.
>>  
>> 
>>
>> might be more precise.
>>
>> BTW: are all english speaking regions using the point as decimal separator?
>>
>> Frank
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[David T. via gnucash-devel]

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, China and 
Australia use the period.

Your markup and changes are fine, although I think “decimal sign” would be 
simpler as just “decimal,” leaving “decimal separator” in the second spot.

Finally, can I assume that this function correctly inserts a comma when the 
locale recommends it, or is it always a period?

David



> On Jul 30, 2017, at 3:51 AM, Frank H. Ellenberger 
>  wrote:
> 
> 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 operand that omits a decimal separator.
>  
> 
> 
> might be more precise.
> 
> BTW: are all english speaking regions using the point as decimal separator?
> 
> Frank

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[David Carlson]

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 can
be identified properly in any language.

David C

On Sat, Jul 29, 2017 at 5:51 PM, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> 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 operand that omits a decimal separator.
>   
> 
>
> might be more precise.
>
> BTW: are all english speaking regions using the point as decimal separator?
>
> Frank
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Frank H. Ellenberger]

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 operand that omits a decimal separator.
  


might be more precise.

BTW: are all english speaking regions using the point as decimal separator?

Frank
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[David T. via gnucash-devel]

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:
>>> 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 shifted. 
>> Anything with a point is normal. Easy to understand for me.
>> 
>> And I would hate to loose the auto-decimal functionality. It saves me a ton 
>> of typing.
>> 
>> Cheers,
>> Christoph
> 
> ... like the addition machines, the accountants used in my childhood.
> 
> Perhaps one of you could attach an improvement of the documentation to
> the bug, to make it clear.
> 
> Regards
> Frank
> ___
> gnucash-devel mailing list
> gn

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Frank H. Ellenberger]

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 it is pretty consistent: Any number without a point is shifted. 
> Anything with a point is normal. Easy to understand for me.
> 
> And I would hate to loose the auto-decimal functionality. It saves me a ton 
> of typing.
> 
> Cheers,
> Christoph

... like the addition machines, the accountants used in my childhood.

Perhaps one of you could attach an improvement of the documentation to
the bug, to make it clear.

Regards
Frank
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[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 it is pretty consistent: Any number without a point is shifted. Anything 
with a point is normal. Easy to understand for me.

And I would hate to loose the auto-decimal functionality. It saves me a ton of 
typing.

Cheers,
Christoph

> Am 28.07.2017 um 05:24 schrieb John Ralls :
> 
> 
> 
>> 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 preprocessing function
>>> that would apply to every element in an equation.
>> 
>> I'm not sure that would quite work either.
>> 
>> Currently, for simple numbers with no arithmetic, "1000" gets
>> auto-decimal-pointed ("scaled" hereafter), but "4.50" doesn't,
>> which are both just what one wants.  The same should apply in
>> formulas (I think! -- but more about that at the end).  Assuming
>> two auto-decimal places, consider:
>>   1000 + 4.50
>> 
>> I (think I) want the first term to get scaled, but not the
>> second, giving a result of 14.50.
>> 
>> OK, so how about we scale each term separately, so that:
>>   1000 * 3 + 450 -> 34.50
>> but also:
>>   1000 * 3 + 4.50 -> 34.50
>> ("->" meaning "yields a result of", since "=" just looks wrong
>> under the circumstances :-) ).
>> 
>> But then:
>>   10.00 * 3 + 4.50 -> 34.50
>> We didn't want to scale the first term after all.
>> 
>> I've thought of a couple of different approaches:
>> - scale each term's resulting value if the term only contains
>>   integers:
>>   1000*3 + 4000   -> 30 + 40  = 70.00
>>   1000*3 + 4000.  -> 30 + 4000= 4030.00
>>   1000*3. + 4000  -> 3000 + 40= 3040.00
>>   1000*3. + 4000. -> 3000 + 4000  = 7000.00
>> 
>> - scale each term's *first* number if it's an integer,
>>   but never second or subsequent numbers:
>>   1000 * 3   -> 30
>>   1000 * 3.  -> 30
>>   1000. * 3  -> 3000
>>   1000. * 3. -> 1000
>>   This is based on the thought that ($20 * $3) is meaningless;
>>   it only makes sense to multiply money by something that isn't
>>   money
>> 
>> But neither of those works in all situations.
>> 
>> 
>> The easiest way out, I think, is to never scale formulas at all,
>> only simple numbers.  So:
>>   4000   -> 40.00 # as currently happens
>>   40.-> 40.00 # likewise
>> But:
>>   4000+1 -> 4001.00
>> 
>> That's how my truly ancient copy of Excel behaves.  (I don't
>> have access to a modern one.)
>> 
>> 
>> Or perhaps: for formulas, scale the final result (as you say),
>> but only if *all* of the numeric values the user typed are
>> integers:
>>   1000*3 + 4000   -> 70.00
>>   1000*3 + 4000.  -> 7000.00
>>   1000*3. + 4000  -> 7000.00
>>   1000.*3 + 4000  -> 7000.00
>> 
>> That could boil down to:
>>   Scale the final result unless the original input string
>>   contains any "."s (or ","s depending on locale)
>> (without even any need to worry whether it's a number or
>> a formula).
>> 
>> But given that it's not entirely clear how even a simple:
>>   1000 + 4.50
>> should behave, anything with any subtlety at all is going to want
>> a fair amount of testing to see whether people actually find it
>> usable.  So an unsubtle approach like "never scale formulas" is
>> probably the safest place to start.
> 
> 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.
> 
> Regards,
> John Ralls
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org 
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel 
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Sumit Bhardwaj]

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 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 preprocessing
> function
> >> that would apply to every element in an equation.
> >
> > I'm not sure that would quite work either.
> >
> > Currently, for simple numbers with no arithmetic, "1000" gets
> > auto-decimal-pointed ("scaled" hereafter), but "4.50" doesn't,
> > which are both just what one wants.  The same should apply in
> > formulas (I think! -- but more about that at the end).  Assuming
> > two auto-decimal places, consider:
> >1000 + 4.50
> >
> > I (think I) want the first term to get scaled, but not the
> > second, giving a result of 14.50.
> >
> > OK, so how about we scale each term separately, so that:
> >1000 * 3 + 450 -> 34.50
> > but also:
> >1000 * 3 + 4.50 -> 34.50
> > ("->" meaning "yields a result of", since "=" just looks wrong
> > under the circumstances :-) ).
> >
> > But then:
> >10.00 * 3 + 4.50 -> 34.50
> > We didn't want to scale the first term after all.
> >
> > I've thought of a couple of different approaches:
> >  - scale each term's resulting value if the term only contains
> >integers:
> >1000*3 + 4000   -> 30 + 40  = 70.00
> >1000*3 + 4000.  -> 30 + 4000= 4030.00
> >1000*3. + 4000  -> 3000 + 40= 3040.00
> >1000*3. + 4000. -> 3000 + 4000  = 7000.00
> >
> >  - scale each term's *first* number if it's an integer,
> >but never second or subsequent numbers:
> >1000 * 3   -> 30
> >1000 * 3.  -> 30
> >1000. * 3  -> 3000
> >1000. * 3. -> 1000
> >This is based on the thought that ($20 * $3) is meaningless;
> >it only makes sense to multiply money by something that isn't
> >money
> >
> > But neither of those works in all situations.
> >
> >
> > The easiest way out, I think, is to never scale formulas at all,
> > only simple numbers.  So:
> >4000   -> 40.00 # as currently happens
> >40.-> 40.00 # likewise
> > But:
> >4000+1 -> 4001.00
> >
> > That's how my truly ancient copy of Excel behaves.  (I don't
> > have access to a modern one.)
> >
> >
> > Or perhaps: for formulas, scale the final result (as you say),
> > but only if *all* of the numeric values the user typed are
> > integers:
> >1000*3 + 4000   -> 70.00
> >1000*3 + 4000.  -> 7000.00
> >1000*3. + 4000  -> 7000.00
> >1000.*3 + 4000  -> 7000.00
> >
> > That could boil down to:
> >Scale the final result unless the original input string
> >contains any "."s (or ","s depending on locale)
> > (without even any need to worry whether it's a number or
> > a formula).
> >
> > But given that it's not entirely clear how even a simple:
> >1000 + 4.50
> > should behave, anything with any subtlety at all is going to want
> > a fair amount of testing to see whether people actually find it
> > usable.  So an unsubtle approach like "never scale formulas" is
> > probably the safest place to start.
>
> 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.
>
> Regards,
> John Ralls
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[John Ralls]

> 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 preprocessing function
>> that would apply to every element in an equation.
> 
> I'm not sure that would quite work either.
> 
> Currently, for simple numbers with no arithmetic, "1000" gets
> auto-decimal-pointed ("scaled" hereafter), but "4.50" doesn't,
> which are both just what one wants.  The same should apply in
> formulas (I think! -- but more about that at the end).  Assuming
> two auto-decimal places, consider:
>1000 + 4.50
> 
> I (think I) want the first term to get scaled, but not the
> second, giving a result of 14.50.
> 
> OK, so how about we scale each term separately, so that:
>1000 * 3 + 450 -> 34.50
> but also:
>1000 * 3 + 4.50 -> 34.50
> ("->" meaning "yields a result of", since "=" just looks wrong
> under the circumstances :-) ).
> 
> But then:
>10.00 * 3 + 4.50 -> 34.50
> We didn't want to scale the first term after all.
> 
> I've thought of a couple of different approaches:
>  - scale each term's resulting value if the term only contains
>integers:
>1000*3 + 4000   -> 30 + 40  = 70.00
>1000*3 + 4000.  -> 30 + 4000= 4030.00
>1000*3. + 4000  -> 3000 + 40= 3040.00
>1000*3. + 4000. -> 3000 + 4000  = 7000.00
> 
>  - scale each term's *first* number if it's an integer,
>but never second or subsequent numbers:
>1000 * 3   -> 30
>1000 * 3.  -> 30
>1000. * 3  -> 3000
>1000. * 3. -> 1000
>This is based on the thought that ($20 * $3) is meaningless;
>it only makes sense to multiply money by something that isn't
>money
> 
> But neither of those works in all situations.
> 
> 
> The easiest way out, I think, is to never scale formulas at all,
> only simple numbers.  So:
>4000   -> 40.00 # as currently happens
>40.-> 40.00 # likewise
> But:
>4000+1 -> 4001.00
> 
> That's how my truly ancient copy of Excel behaves.  (I don't
> have access to a modern one.)
> 
> 
> Or perhaps: for formulas, scale the final result (as you say),
> but only if *all* of the numeric values the user typed are
> integers:
>1000*3 + 4000   -> 70.00
>1000*3 + 4000.  -> 7000.00
>1000*3. + 4000  -> 7000.00
>1000.*3 + 4000  -> 7000.00
> 
> That could boil down to:
>Scale the final result unless the original input string
>contains any "."s (or ","s depending on locale)
> (without even any need to worry whether it's a number or
> a formula).
> 
> But given that it's not entirely clear how even a simple:
>1000 + 4.50
> should behave, anything with any subtlety at all is going to want
> a fair amount of testing to see whether people actually find it
> usable.  So an unsubtle approach like "never scale formulas" is
> probably the safest place to start.

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.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Eric Siegerman]

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 sure that would quite work either.

Currently, for simple numbers with no arithmetic, "1000" gets
auto-decimal-pointed ("scaled" hereafter), but "4.50" doesn't,
which are both just what one wants.  The same should apply in
formulas (I think! -- but more about that at the end).  Assuming
two auto-decimal places, consider:
1000 + 4.50

I (think I) want the first term to get scaled, but not the
second, giving a result of 14.50.

OK, so how about we scale each term separately, so that:
1000 * 3 + 450 -> 34.50
but also:
1000 * 3 + 4.50 -> 34.50
("->" meaning "yields a result of", since "=" just looks wrong
under the circumstances :-) ).

But then:
10.00 * 3 + 4.50 -> 34.50
We didn't want to scale the first term after all.

I've thought of a couple of different approaches:
  - scale each term's resulting value if the term only contains
integers:
1000*3 + 4000   -> 30 + 40  = 70.00
1000*3 + 4000.  -> 30 + 4000= 4030.00
1000*3. + 4000  -> 3000 + 40= 3040.00
1000*3. + 4000. -> 3000 + 4000  = 7000.00

  - scale each term's *first* number if it's an integer,
but never second or subsequent numbers:
1000 * 3   -> 30
1000 * 3.  -> 30
1000. * 3  -> 3000
1000. * 3. -> 1000
This is based on the thought that ($20 * $3) is meaningless;
it only makes sense to multiply money by something that isn't
money

But neither of those works in all situations.


The easiest way out, I think, is to never scale formulas at all,
only simple numbers.  So:
4000   -> 40.00 # as currently happens
40.-> 40.00 # likewise
But:
4000+1 -> 4001.00

That's how my truly ancient copy of Excel behaves.  (I don't
have access to a modern one.)


Or perhaps: for formulas, scale the final result (as you say),
but only if *all* of the numeric values the user typed are
integers:
1000*3 + 4000   -> 70.00
1000*3 + 4000.  -> 7000.00
1000*3. + 4000  -> 7000.00
1000.*3 + 4000  -> 7000.00

That could boil down to:
Scale the final result unless the original input string
contains any "."s (or ","s depending on locale)
(without even any need to worry whether it's a number or
a formula).

But given that it's not entirely clear how even a simple:
1000 + 4.50
should behave, anything with any subtlety at all is going to want
a fair amount of testing to see whether people actually find it
usable.  So an unsubtle approach like "never scale formulas" is
probably the safest place to start.

  - Eric
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christoph R]

> 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. :
> 
> 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
>  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 
>> >:
>> 
>> 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> > wrote:   ​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 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@gnucash.org 
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel 
>> 
>> 
>> 
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org 
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel 
>> 
> 

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[David T. via gnucash-devel]

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 
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 
:
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 wrote:   
​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 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@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christoph R]

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 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 > wrote:   ​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 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@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org 
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel 
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[David T. via gnucash-devel]

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 wrote:   
​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 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@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Intended behavior of automatic decimal point (bug 120940)

[Sumit Bhardwaj]

​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 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@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel