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 <jralls at ceridwen.us> wrote:

>
>
> > On Jul 27, 2017, at 6:27 PM, Eric Siegerman <pub08-gnc at 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 at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>