Intended behavior of automatic decimal point (bug 120940)

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

GnuCash - Dev mailing list
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<[hidden email]> 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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]>:
>
> 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<[hidden email] <mailto:[hidden email]>> 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
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email] <mailto:[hidden email]>
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel <https://lists.gnucash.org/mailman/listinfo/gnucash-devel>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

GnuCash - Dev mailing list
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<[hidden email]> 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 <[hidden email]>:
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<[hidden email]> 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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

 
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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. <[hidden email]>:
>
> 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
> <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>>:
>>
>> 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<[hidden email] <mailto:[hidden email]>> 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
>> [hidden email] <mailto:[hidden email]>
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel <https://lists.gnucash.org/mailman/listinfo/gnucash-devel>
>>
>>
>> _______________________________________________
>> gnucash-devel mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel <https://lists.gnucash.org/mailman/listinfo/gnucash-devel>
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Eric Siegerman
In reply to this post by GnuCash - Dev mailing list
On Thu, Jul 27, 2017 at 08:20:50AM +0000, 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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John Ralls-2


> On Jul 27, 2017, at 6:27 PM, Eric Siegerman <[hidden email]> wrote:
>
> On Thu, Jul 27, 2017 at 08:20:50AM +0000, 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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> wrote:

>
>
> > On Jul 27, 2017, at 6:27 PM, Eric Siegerman <[hidden email]> wrote:
> >
> > On Thu, Jul 27, 2017 at 08:20:50AM +0000, 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
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Christoph R
In reply to this post by John Ralls-2
> 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 <[hidden email]>:
>
>
>
>> On Jul 27, 2017, at 6:27 PM, Eric Siegerman <[hidden email]> wrote:
>>
>> On Thu, Jul 27, 2017 at 08:20:50AM +0000, 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
> [hidden email] <mailto:[hidden email]>
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel <https://lists.gnucash.org/mailman/listinfo/gnucash-devel>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frank H. Ellenberger-3
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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

GnuCash - Dev mailing list
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 <[hidden email]> 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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frank H. Ellenberger-3
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

<note>
  <para>When a calculation is entered in the
    <guilabel>Amount</guilabel> field, the decimal sign is inserted into
    <emphasis>every</emphasis> operand that omits a decimal separator.
  </para>
</note>

might be more precise.

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

Frank
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Carlson-4
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 <
[hidden email]> 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
>
> <note>
>   <para>When a calculation is entered in the
>     <guilabel>Amount</guilabel> field, the decimal sign is inserted into
>     <emphasis>every</emphasis> operand that omits a decimal separator.
>   </para>
> </note>
>
> might be more precise.
>
> BTW: are all english speaking regions using the point as decimal separator?
>
> Frank
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

GnuCash - Dev mailing list
In reply to this post by Frank H. Ellenberger-3
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 <[hidden email]> 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
>
> <note>
>  <para>When a calculation is entered in the
>    <guilabel>Amount</guilabel> field, the decimal sign is inserted into
>    <emphasis>every</emphasis> operand that omits a decimal separator.
>  </para>
> </note>
>
> might be more precise.
>
> BTW: are all english speaking regions using the point as decimal separator?
>
> Frank

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frank H. Ellenberger-3
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 <[hidden email]> 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
>>
>> <note>
>>  <para>When a calculation is entered in the
>>    <guilabel>Amount</guilabel> field, the decimal sign is inserted into
>>    <emphasis>every</emphasis> operand that omits a decimal separator.
>>  </para>
>> </note>
>>
>> might be more precise.
>>
>> BTW: are all english speaking regions using the point as decimal separator?
>>
>> Frank
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Loading...