Hello Thomas,
Am 23.12.20 um 09:25 schrieb Thomas Lenherr:
> Thank you all for your responses.
>
> For the record, this is for private bookkeeping purposes (mainly splitting
> costs for different things with roommates), and so regulations generally
> don't apply as accuracy to a cent is more
On 23 December 2020 at 0:25, Thomas Lenherr said:
> Thank you all for your responses.
>
> For the record, this is for private bookkeeping purposes (mainly splitting
> costs for different things with roommates), and so regulations generally
> don't apply as accuracy to a cent is more than enough
The ability to use one split's value as the variable input to a
subsequent split would be nice for many such formulas. (or say, the
sum/average of all other splits as part of a formula)
The rounding issue aside, I think this enhancement would be quite useful
and open up lots of possibilities.
Thank you all for your responses.
For the record, this is for private bookkeeping purposes (mainly splitting
costs for different things with roommates), and so regulations generally
don't apply as accuracy to a cent is more than enough and I mostly just
want to prevent having to fix imbalances
On 12/22/2020 5:17 PM, Liz wrote:
I think that we have taken a peek down a rabbit hole and found
enormous complexity past the entrance.
Liz
For us pros it gets far worse than that. In my working days often had to
compute the "fuzz" value to use in comparisons because of "rounding
errors"
On Tue, 22 Dec 2020 10:22:44 -0500
Michael or Penny Novack wrote:
> > Thomas
> >
> > Another perspective on this is that in practice what rounding
> > procedure a bank or other external body may apply may depend on any
> > legislative requirements (usually by taxation bodies) and their
> >
Thomas
Another perspective on this is that in practice what rounding procedure a
bank or other external body may apply may depend on any legislative
requirements (usually by taxation bodies) and their internal accounting
policies and these are not under GnuCash's control and may also vary
Thomas
Another perspective on this is that in practice what rounding procedure a
bank or other external body may apply may depend on any legislative
requirements (usually by taxation bodies) and their internal accounting
policies and these are not under GnuCash's control and may also vary
An important thing to keep in perspective, is this entire thread is
about at most 12¢ per year, and that would be on the far outside of
statistical probability. (Can you get 12 'heads' or 'tails' in a row
flipping a coin?)
Mind you, no one would be prevented from accounting for the alleged
I think this rounding problem (if you want to call it that) is not unique
to Gnucash. You would see the same thing if you were using a spreadsheet,
for example.
For the particular type of example given, it might make sense to track
running totals and calculate monthly amounts required to make
Just by the way, there’s a fascinating illustration of the floating point
problem in the history of TeX. When Knuth and co. wrote TeX, the intention was
that a TeX document would reproduce identical printed documents irrespective of
the hardware it ran on. After a while, it was reported that
Granted, but that only applies if total_amount is a floating point number. I
didn’t think that one through.
$1.01/2 = 0.505
$1.01 - (1.01/2) = 1.01 - 0.505 = 0.505
Both results rounded = .50
I _never_ used floating point for monetary amounts, for reasons demonstrated
above, and I pretty soon
Or just correct a single digit as desired upon review when the
transaction is created? (on the off chance the original sum is an odd
number, which isn't always, and if I recall correctly, this is a *one
time per month* transaction, thus from 1 to 12 times *per year* the
transaction won't
I think the problem is that with late rounding the formula may not work.
Suppose the amount is 0.21.
Compute amount/2 exactly: 0.21/2=0.105
Subtract from amount 0.21 - 0.105=0.105
For a fixed rounding scheme both will either be 0.11 or 0.10 and the sum
will be 0.22, respectively, 0.20. Neither is
There’s no rounding as such involved in the formulae. The timing will only
matter if total_amount changes between the two calculations, which I assume it
will not do. If x/2, when x is an integer (be it number of cents or number of
pennies or whatever), does not give identical results for the
Fred,
When I said no rounding as such I was referring to integer division. In integer
division, 14/5 = 2, the same as 10/5, and all integers between. The rounding is
simply throwing away the rubbish left over; the remainder.
Peter
--
Peter West
p...@pbw.id.au
“Blessed are you among women, and
On 21 December 2020 at 22:14, Peter West said:
> There’s no rounding as such involved in the formulae. The timing will
> only matter if total_amount changes between the two calculations, which I
> assume it will not do. If x/2, when x is an integer (be it number of cents
> or number of pennies or
On 21 December 2020 at 12:12, Peter West said:
> I don’t understand why "total_amount-(total_amount/2)” doesn’t work.
> I’m assuming that two formulae are used: total_amount/2 &
> total_amount-(total_amount/2), as the OP specifies.
>
> If the amount is odd, the first should be (given consistent
I don’t understand why "total_amount-(total_amount/2)” doesn’t work. I’m
assuming that two formulae are used:
total_amount/2
&
total_amount-(total_amount/2),
as the OP specifies.
If the amount is odd, the first should be (given consistent truncation of the
dividend by integer division)
I don't know if the math functions are available, but various languages
have rounding functions. If there's a rounding function, perhaps round up
and round down can be used?
odd_cent_total/2 will have a fractional cent value in the answer, so
round up to the nearest cent for you and down to
Note, I'm not aware of a 'proper' solution that you are looking for.
Sounds like a lot of effort to avoid changing a single digit on review
when occasionally the original amount is odd.
I would expect your try at "total_amount-(total_amount/2)" to only work
half the time, thus a coin flip.
Hi,
I've been using gnucash for a few years now, including scheduled
transactions with variables/formulas, but one thing I never figured out is
how to avoid imbalances in them when variables cause "bad" rounding,
requiring me to fix those manually.
Simple example:
I use a scheduled transaction
22 matches
Mail list logo
