On those machines it certainly *still is* a nice feature. Yes, some
small businesses still use 40–50 year old adding machines. Why? Because
they still work and are always at hand. You don't have to open an app
with 'features', you just do quick math. (and yes, some companies still
manufacture
Years ago - like in the 60s and 70s, there were adding machines - things that
were replaced with what we now call calculators - that had a ‘feature’ - in
some case the only mode of operating - that the decimal point was assumed two
to the left of the last digit. This was a great time saver -
I assumed that with auto-decimal on, entering "6" means ".06"... if I want
.06, I'll enter ".06", so I don't want this. I always assumed it works this
way in the calculations, too.
On Fri, Dec 1, 2023 at 1:40 PM Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:
> Indeed, I'm not sure
Dec 1, 2023 13:37:32 Adrien Monteleone :
> It seems the code for auto-decimal is occurring with each numerical entry,
> rather than the final result.
To me it seems the least surprising way for auto-decimal to work would be if it
only applied when you enter an amount directly. I wouldn't
Indeed, I'm not sure how it worked for me earlier, but it is failing for
each type of operand.
It seems the code for auto-decimal is occurring with each numerical
entry, rather than the final result.
I'd call that a bug.
Regards,
Adrien
On 12/1/23 12:52 PM, Fred Bone wrote:
On 01 December
Can confirm that GnuCash is performing the calculation as the OP originally
described in 5.4 on Linux MInt with the 'automatic decimal point "setting
checked. It isn't something I normally have set
David Cousens
On Fri, 2023-12-01 at 17:41 +, Fred Bone wrote:
> On 01 December 2023 at 0:27,
On 01 December 2023 at 9:56, Fred Tydeman said:
> In GC of 4.14 using Automatic Decimal, 1/3 gets 0.33, while 1./3 gets
> 33.33
That figures.
Arguably it's correct. With "automatic decimal" active, the first of
those means "0.01/0.03" and the second means "1/0.03"
Just that people don;t
In GC of 4.14 using Automatic Decimal, 1/3 gets 0.33, while 1./3 gets 33.33
On Fri, Dec 1, 2023 at 9:42 AM Fred Bone wrote:
> On 01 December 2023 at 0:27, Adrien Monteleone said:
>
> > It is working fine here on MacOS and Linux Mint.
> >
> > Can you replicate it with a fresh test book using
In GC 4.14, using Automatic Decimal of 2
On Fri, Dec 1, 2023 at 9:42 AM Fred Bone wrote:
> On 01 December 2023 at 0:27, Adrien Monteleone said:
>
> > It is working fine here on MacOS and Linux Mint.
> >
> > Can you replicate it with a fresh test book using all default settings?
>
> I can
On 01 December 2023 at 0:27, Adrien Monteleone said:
> It is working fine here on MacOS and Linux Mint.
>
> Can you replicate it with a fresh test book using all default settings?
I can readily replicate it on my copy of 2.6.21:
1. Check the "automatic decimal point" setting (with 2dp)
2.
It is working fine here on MacOS and Linux Mint.
Can you replicate it with a fresh test book using all default settings?
Regards,
Adrien
On 11/30/23 10:25 PM, Michael Campbell via gnucash-user wrote:
Fixed. Eventually.
I unchecked the "Numbers, Date, Time" -> "Automatic decimal point" check
Fixed. Eventually.
I unchecked the "Numbers, Date, Time" -> "Automatic decimal point" check
box in settings where it was set to 2 decimal places and now amounts
will be calculated correctly.
Is anyone else able to replicate this bug?
Regards,
Michael Campbell
On 12/1/23 09:27, Adrien
12 matches
Mail list logo
