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 |
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 |
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 |
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 |
> 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 |
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 |
> 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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |