Intended behavior of automatic decimal point (bug 120940)

Christoph R subscriptions+listen at rohland.net
Fri Jul 28 08:28:04 EDT 2017


> 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 <jralls at ceridwen.us>:
> 
> 
> 
>> 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 <mailto:gnucash-devel at gnucash.org>
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel <https://lists.gnucash.org/mailman/listinfo/gnucash-devel>


More information about the gnucash-devel mailing list