> 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 <jra...@ceridwen.us>: > > > >> On Jul 27, 2017, at 6:27 PM, Eric Siegerman <pub08-...@davor.org> 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 > gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > <https://lists.gnucash.org/mailman/listinfo/gnucash-devel> _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel