[GNC] Loan Mortgage repayment assistant problem

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[GNC] Loan Mortgage repayment assistant problem

David Carlson-4
I just had a scheduled transaction that was set up by the loan/mortgage
repayment assistant appear with 0.01 Imbalance-USD.

I would think that GnuCash should have an accuracy method that would
prevent this from happening.  Is this a bug?

I am using GnuCash 2.6.17 in Ubuntu 16.04 today.

David C
_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

John Ralls-2


> On Jan 7, 2019, at 3:14 PM, David Carlson <[hidden email]> wrote:
>
> I just had a scheduled transaction that was set up by the loan/mortgage
> repayment assistant appear with 0.01 Imbalance-USD.
>
> I would think that GnuCash should have an accuracy method that would
> prevent this from happening.  Is this a bug?
>
> I am using GnuCash 2.6.17 in Ubuntu 16.04 today.

The accuracy method is what created the imbalance entry. ;-)

There’s nothing in the SX system to pre-instantiate future scheduled transactions and ensure that they’re balanced. What would you have the check function do if it found an imbalanced case? How would you handle variables whose values are set by the user in the SLR dialog?

Regards,
John Ralls

_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

David Carlson-4
My point is that the equations are defined by the assistant, and I think
that they can be expressed in a form that concentrates all the errors into
one line where a simple rounding would not generate a problem where the
parts do not add up to 100%.  Granted, the errors may sometimes cause
inaccurate results, but they would not add the imbalance line to the
transaction.

The current equations are three  evaluations called pmt(numbers),
ppmt(numbers) and ipmt(numbers) with no clue how they are actually
evaluated.

Apparently pmt is not always the sum of ppmt and ipmt. when rounding
happens.  If ipmt were expressed as pmt-ppmt, there would be no imbalance,
but one of the other two ways to express all three may be less likely to
generate inaccurate results.

David C

On Mon, Jan 7, 2019 at 10:19 PM John Ralls <[hidden email]> wrote:

>
>
> > On Jan 7, 2019, at 3:14 PM, David Carlson <[hidden email]>
> wrote:
> >
> > I just had a scheduled transaction that was set up by the loan/mortgage
> > repayment assistant appear with 0.01 Imbalance-USD.
> >
> > I would think that GnuCash should have an accuracy method that would
> > prevent this from happening.  Is this a bug?
> >
> > I am using GnuCash 2.6.17 in Ubuntu 16.04 today.
>
> The accuracy method is what created the imbalance entry. ;-)
>
> There’s nothing in the SX system to pre-instantiate future scheduled
> transactions and ensure that they’re balanced. What would you have the
> check function do if it found an imbalanced case? How would you handle
> variables whose values are set by the user in the SLR dialog?
>
> Regards,
> John Ralls
>
>
_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

John Ralls-2
The thee functions are defined in https://github.com/Gnucash/gnucash/blob/maint/libgnucash/app-utils/fin.scm, prefixed with gnc: (so gnc:ipmt etc.).

At line 41ff you'll see that ppmt = pmt - ipmt.

Regards,
John Ralls


> On Jan 8, 2019, at 12:48 PM, David Carlson <[hidden email]> wrote:
>
> My point is that the equations are defined by the assistant, and I think that they can be expressed in a form that concentrates all the errors into one line where a simple rounding would not generate a problem where the parts do not add up to 100%.  Granted, the errors may sometimes cause inaccurate results, but they would not add the imbalance line to the transaction.
>
> The current equations are three  evaluations called pmt(numbers), ppmt(numbers) and ipmt(numbers) with no clue how they are actually evaluated.
>
> Apparently pmt is not always the sum of ppmt and ipmt. when rounding happens.  If ipmt were expressed as pmt-ppmt, there would be no imbalance, but one of the other two ways to express all three may be less likely to generate inaccurate results.
>
> David C
>
> On Mon, Jan 7, 2019 at 10:19 PM John Ralls <[hidden email]> wrote:
>
>
> > On Jan 7, 2019, at 3:14 PM, David Carlson <[hidden email]> wrote:
> >
> > I just had a scheduled transaction that was set up by the loan/mortgage
> > repayment assistant appear with 0.01 Imbalance-USD.
> >
> > I would think that GnuCash should have an accuracy method that would
> > prevent this from happening.  Is this a bug?
> >
> > I am using GnuCash 2.6.17 in Ubuntu 16.04 today.
>
> The accuracy method is what created the imbalance entry. ;-)
>
> There’s nothing in the SX system to pre-instantiate future scheduled transactions and ensure that they’re balanced. What would you have the check function do if it found an imbalanced case? How would you handle variables whose values are set by the user in the SLR dialog?
>
> Regards,
> John Ralls
>

_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

David Carlson-4
John,

Thanks for the reference.  Alas, I will need to do some homework to
properly read SCM.  There must still be some sort of rounding issue
creeping in if the Scheduled Transaction SLR sometimes generates an
imbalance from ppmt = pmt - ipmt.

David C

On Tue, Jan 8, 2019 at 3:44 PM John Ralls <[hidden email]> wrote:

> The thee functions are defined in
> https://github.com/Gnucash/gnucash/blob/maint/libgnucash/app-utils/fin.scm,
> prefixed with gnc: (so gnc:ipmt etc.).
>
> At line 41ff you'll see that ppmt = pmt - ipmt.
>
> Regards,
> John Ralls
>
>
> > On Jan 8, 2019, at 12:48 PM, David Carlson <[hidden email]>
> wrote:
> >
> > My point is that the equations are defined by the assistant, and I think
> that they can be expressed in a form that concentrates all the errors into
> one line where a simple rounding would not generate a problem where the
> parts do not add up to 100%.  Granted, the errors may sometimes cause
> inaccurate results, but they would not add the imbalance line to the
> transaction.
> >
> > The current equations are three  evaluations called pmt(numbers),
> ppmt(numbers) and ipmt(numbers) with no clue how they are actually
> evaluated.
> >
> > Apparently pmt is not always the sum of ppmt and ipmt. when rounding
> happens.  If ipmt were expressed as pmt-ppmt, there would be no imbalance,
> but one of the other two ways to express all three may be less likely to
> generate inaccurate results.
> >
> > David C
> >
> > On Mon, Jan 7, 2019 at 10:19 PM John Ralls <[hidden email]> wrote:
> >
> >
> > > On Jan 7, 2019, at 3:14 PM, David Carlson <[hidden email]>
> wrote:
> > >
> > > I just had a scheduled transaction that was set up by the loan/mortgage
> > > repayment assistant appear with 0.01 Imbalance-USD.
> > >
> > > I would think that GnuCash should have an accuracy method that would
> > > prevent this from happening.  Is this a bug?
> > >
> > > I am using GnuCash 2.6.17 in Ubuntu 16.04 today.
> >
> > The accuracy method is what created the imbalance entry. ;-)
> >
> > There’s nothing in the SX system to pre-instantiate future scheduled
> transactions and ensure that they’re balanced. What would you have the
> check function do if it found an imbalanced case? How would you handle
> variables whose values are set by the user in the SLR dialog?
> >
> > Regards,
> > John Ralls
> >
>
>
_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

Christopher Lam
Well the SCM has numerous references to "round" and "rounding errors" so
it's to be expected.

Please file a bug with example numbers, and hopefully these errors may
be fixed.

On 9/1/19 7:35 am, David Carlson wrote:

> John,
>
> Thanks for the reference.  Alas, I will need to do some homework to
> properly read SCM.  There must still be some sort of rounding issue
> creeping in if the Scheduled Transaction SLR sometimes generates an
> imbalance from ppmt = pmt - ipmt.
>
> David C
>
> On Tue, Jan 8, 2019 at 3:44 PM John Ralls <[hidden email]> wrote:
>
>> The thee functions are defined in
>> https://github.com/Gnucash/gnucash/blob/maint/libgnucash/app-utils/fin.scm,
>> prefixed with gnc: (so gnc:ipmt etc.).
>>
>> At line 41ff you'll see that ppmt = pmt - ipmt.
>>
>> Regards,
>> John Ralls
>>
>>
>>> On Jan 8, 2019, at 12:48 PM, David Carlson <[hidden email]>
>> wrote:
>>> My point is that the equations are defined by the assistant, and I think
>> that they can be expressed in a form that concentrates all the errors into
>> one line where a simple rounding would not generate a problem where the
>> parts do not add up to 100%.  Granted, the errors may sometimes cause
>> inaccurate results, but they would not add the imbalance line to the
>> transaction.
>>> The current equations are three  evaluations called pmt(numbers),
>> ppmt(numbers) and ipmt(numbers) with no clue how they are actually
>> evaluated.
>>> Apparently pmt is not always the sum of ppmt and ipmt. when rounding
>> happens.  If ipmt were expressed as pmt-ppmt, there would be no imbalance,
>> but one of the other two ways to express all three may be less likely to
>> generate inaccurate results.
>>> David C
>>>
>>> On Mon, Jan 7, 2019 at 10:19 PM John Ralls <[hidden email]> wrote:
>>>
>>>
>>>> On Jan 7, 2019, at 3:14 PM, David Carlson <[hidden email]>
>> wrote:
>>>> I just had a scheduled transaction that was set up by the loan/mortgage
>>>> repayment assistant appear with 0.01 Imbalance-USD.
>>>>
>>>> I would think that GnuCash should have an accuracy method that would
>>>> prevent this from happening.  Is this a bug?
>>>>
>>>> I am using GnuCash 2.6.17 in Ubuntu 16.04 today.
>>> The accuracy method is what created the imbalance entry. ;-)
>>>
>>> There’s nothing in the SX system to pre-instantiate future scheduled
>> transactions and ensure that they’re balanced. What would you have the
>> check function do if it found an imbalanced case? How would you handle
>> variables whose values are set by the user in the SLR dialog?
>>> Regards,
>>> John Ralls
>>>
>>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

John Ralls-2
The answer is probably in app-utils/calculation. All of that was probably written before Guile grew a rational number class and I think that GncNumerics get converted to doubles before being passed to the interest functions. That would pretty much guarantee rounding issues.

Regards,
John Ralls

> On Jan 8, 2019, at 5:46 PM, Christopher Lam <[hidden email]> wrote:
>
> Well the SCM has numerous references to "round" and "rounding errors" so it's to be expected.
>
> Please file a bug with example numbers, and hopefully these errors may be fixed.
>
> On 9/1/19 7:35 am, David Carlson wrote:
>> John,
>>
>> Thanks for the reference.  Alas, I will need to do some homework to
>> properly read SCM.  There must still be some sort of rounding issue
>> creeping in if the Scheduled Transaction SLR sometimes generates an
>> imbalance from ppmt = pmt - ipmt.
>>
>> David C
>>
>> On Tue, Jan 8, 2019 at 3:44 PM John Ralls <[hidden email]> wrote:
>>
>>> The thee functions are defined in
>>> https://github.com/Gnucash/gnucash/blob/maint/libgnucash/app-utils/fin.scm,
>>> prefixed with gnc: (so gnc:ipmt etc.).
>>>
>>> At line 41ff you'll see that ppmt = pmt - ipmt.
>>>
>>> Regards,
>>> John Ralls
>>>
>>>
>>>> On Jan 8, 2019, at 12:48 PM, David Carlson <[hidden email]>
>>> wrote:
>>>> My point is that the equations are defined by the assistant, and I think
>>> that they can be expressed in a form that concentrates all the errors into
>>> one line where a simple rounding would not generate a problem where the
>>> parts do not add up to 100%.  Granted, the errors may sometimes cause
>>> inaccurate results, but they would not add the imbalance line to the
>>> transaction.
>>>> The current equations are three  evaluations called pmt(numbers),
>>> ppmt(numbers) and ipmt(numbers) with no clue how they are actually
>>> evaluated.
>>>> Apparently pmt is not always the sum of ppmt and ipmt. when rounding
>>> happens.  If ipmt were expressed as pmt-ppmt, there would be no imbalance,
>>> but one of the other two ways to express all three may be less likely to
>>> generate inaccurate results.
>>>> David C
>>>>
>>>> On Mon, Jan 7, 2019 at 10:19 PM John Ralls <[hidden email]> wrote:
>>>>
>>>>
>>>>> On Jan 7, 2019, at 3:14 PM, David Carlson <[hidden email]>
>>> wrote:
>>>>> I just had a scheduled transaction that was set up by the loan/mortgage
>>>>> repayment assistant appear with 0.01 Imbalance-USD.
>>>>>
>>>>> I would think that GnuCash should have an accuracy method that would
>>>>> prevent this from happening.  Is this a bug?
>>>>>
>>>>> I am using GnuCash 2.6.17 in Ubuntu 16.04 today.
>>>> The accuracy method is what created the imbalance entry. ;-)
>>>>
>>>> There’s nothing in the SX system to pre-instantiate future scheduled
>>> transactions and ensure that they’re balanced. What would you have the
>>> check function do if it found an imbalanced case? How would you handle
>>> variables whose values are set by the user in the SLR dialog?
>>>> Regards,
>>>> John Ralls
>>>>
>>>
>> _______________________________________________
>> gnucash-user mailing list
>> [hidden email]
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

David Carlson-4
I am working on a test scenario.The interest formula is ipmt( 0.03500 /
12.00 : i : 180.00 : 172,000.00 : 0 : 0 ), the others have the same numbers
and the 71st payment contains the error.  I am using these numbers because
they are exactly the same as the numbers that have already generated an
error.
i started the test loan in Jan 2000 with the first repayment in February
and I am creating one month at a time in case that makes a difference.  If
the test can repeat it I will submit the bug report.

David C

On Tue, Jan 8, 2019 at 10:52 PM John Ralls <[hidden email]> wrote:

> The answer is probably in app-utils/calculation. All of that was probably
> written before Guile grew a rational number class and I think that
> GncNumerics get converted to doubles before being passed to the interest
> functions. That would pretty much guarantee rounding issues.
>
> Regards,
> John Ralls
>
> > On Jan 8, 2019, at 5:46 PM, Christopher Lam <[hidden email]>
> wrote:
> >
> > Well the SCM has numerous references to "round" and "rounding errors" so
> it's to be expected.
> >
> > Please file a bug with example numbers, and hopefully these errors may
> be fixed.
> >
> > On 9/1/19 7:35 am, David Carlson wrote:
> >> John,
> >>
> >> Thanks for the reference.  Alas, I will need to do some homework to
> >> properly read SCM.  There must still be some sort of rounding issue
> >> creeping in if the Scheduled Transaction SLR sometimes generates an
> >> imbalance from ppmt = pmt - ipmt.
> >>
> >> David C
> >>
> >> On Tue, Jan 8, 2019 at 3:44 PM John Ralls <[hidden email]> wrote:
> >>
> >>> The thee functions are defined in
> >>>
> https://github.com/Gnucash/gnucash/blob/maint/libgnucash/app-utils/fin.scm
> ,
> >>> prefixed with gnc: (so gnc:ipmt etc.).
> >>>
> >>> At line 41ff you'll see that ppmt = pmt - ipmt.
> >>>
> >>> Regards,
> >>> John Ralls
> >>>
> >>>
> >>>> On Jan 8, 2019, at 12:48 PM, David Carlson <
> [hidden email]>
> >>> wrote:
> >>>> My point is that the equations are defined by the assistant, and I
> think
> >>> that they can be expressed in a form that concentrates all the errors
> into
> >>> one line where a simple rounding would not generate a problem where the
> >>> parts do not add up to 100%.  Granted, the errors may sometimes cause
> >>> inaccurate results, but they would not add the imbalance line to the
> >>> transaction.
> >>>> The current equations are three  evaluations called pmt(numbers),
> >>> ppmt(numbers) and ipmt(numbers) with no clue how they are actually
> >>> evaluated.
> >>>> Apparently pmt is not always the sum of ppmt and ipmt. when rounding
> >>> happens.  If ipmt were expressed as pmt-ppmt, there would be no
> imbalance,
> >>> but one of the other two ways to express all three may be less likely
> to
> >>> generate inaccurate results.
> >>>> David C
> >>>>
> >>>> On Mon, Jan 7, 2019 at 10:19 PM John Ralls <[hidden email]>
> wrote:
> >>>>
> >>>>
> >>>>> On Jan 7, 2019, at 3:14 PM, David Carlson <
> [hidden email]>
> >>> wrote:
> >>>>> I just had a scheduled transaction that was set up by the
> loan/mortgage
> >>>>> repayment assistant appear with 0.01 Imbalance-USD.
> >>>>>
> >>>>> I would think that GnuCash should have an accuracy method that would
> >>>>> prevent this from happening.  Is this a bug?
> >>>>>
> >>>>> I am using GnuCash 2.6.17 in Ubuntu 16.04 today.
> >>>> The accuracy method is what created the imbalance entry. ;-)
> >>>>
> >>>> There’s nothing in the SX system to pre-instantiate future scheduled
> >>> transactions and ensure that they’re balanced. What would you have the
> >>> check function do if it found an imbalanced case? How would you handle
> >>> variables whose values are set by the user in the SLR dialog?
> >>>> Regards,
> >>>> John Ralls
> >>>>
> >>>
> >> _______________________________________________
> >> gnucash-user mailing list
> >> [hidden email]
> >> To update your subscription preferences or to unsubscribe:
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> >> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> >> -----
> >> Please remember to CC this list on all your replies.
> >> You can do this by using Reply-To-List or Reply-All.
> > _______________________________________________
> > gnucash-user mailing list
> > [hidden email]
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

David Carlson-4
With those numbers payment number 2 has an error.

David C

On Wed, Jan 9, 2019 at 2:23 AM David Carlson <[hidden email]>
wrote:

> I am working on a test scenario.The interest formula is ipmt( 0.03500 /
> 12.00 : i : 180.00 : 172,000.00 : 0 : 0 ), the others have the same numbers
> and the 71st payment contains the error.  I am using these numbers because
> they are exactly the same as the numbers that have already generated an
> error.
> i started the test loan in Jan 2000 with the first repayment in February
> and I am creating one month at a time in case that makes a difference.  If
> the test can repeat it I will submit the bug report.
>
> David C
>
> On Tue, Jan 8, 2019 at 10:52 PM John Ralls <[hidden email]> wrote:
>
>> The answer is probably in app-utils/calculation. All of that was probably
>> written before Guile grew a rational number class and I think that
>> GncNumerics get converted to doubles before being passed to the interest
>> functions. That would pretty much guarantee rounding issues.
>>
>> Regards,
>> John Ralls
>>
>> > On Jan 8, 2019, at 5:46 PM, Christopher Lam <[hidden email]>
>> wrote:
>> >
>> > Well the SCM has numerous references to "round" and "rounding errors"
>> so it's to be expected.
>> >
>> > Please file a bug with example numbers, and hopefully these errors may
>> be fixed.
>> >
>> > On 9/1/19 7:35 am, David Carlson wrote:
>> >> John,
>> >>
>> >> Thanks for the reference.  Alas, I will need to do some homework to
>> >> properly read SCM.  There must still be some sort of rounding issue
>> >> creeping in if the Scheduled Transaction SLR sometimes generates an
>> >> imbalance from ppmt = pmt - ipmt.
>> >>
>> >> David C
>> >>
>> >> On Tue, Jan 8, 2019 at 3:44 PM John Ralls <[hidden email]> wrote:
>> >>
>> >>> The thee functions are defined in
>> >>>
>> https://github.com/Gnucash/gnucash/blob/maint/libgnucash/app-utils/fin.scm
>> ,
>> >>> prefixed with gnc: (so gnc:ipmt etc.).
>> >>>
>> >>> At line 41ff you'll see that ppmt = pmt - ipmt.
>> >>>
>> >>> Regards,
>> >>> John Ralls
>> >>>
>> >>>
>> >>>> On Jan 8, 2019, at 12:48 PM, David Carlson <
>> [hidden email]>
>> >>> wrote:
>> >>>> My point is that the equations are defined by the assistant, and I
>> think
>> >>> that they can be expressed in a form that concentrates all the errors
>> into
>> >>> one line where a simple rounding would not generate a problem where
>> the
>> >>> parts do not add up to 100%.  Granted, the errors may sometimes cause
>> >>> inaccurate results, but they would not add the imbalance line to the
>> >>> transaction.
>> >>>> The current equations are three  evaluations called pmt(numbers),
>> >>> ppmt(numbers) and ipmt(numbers) with no clue how they are actually
>> >>> evaluated.
>> >>>> Apparently pmt is not always the sum of ppmt and ipmt. when rounding
>> >>> happens.  If ipmt were expressed as pmt-ppmt, there would be no
>> imbalance,
>> >>> but one of the other two ways to express all three may be less likely
>> to
>> >>> generate inaccurate results.
>> >>>> David C
>> >>>>
>> >>>> On Mon, Jan 7, 2019 at 10:19 PM John Ralls <[hidden email]>
>> wrote:
>> >>>>
>> >>>>
>> >>>>> On Jan 7, 2019, at 3:14 PM, David Carlson <
>> [hidden email]>
>> >>> wrote:
>> >>>>> I just had a scheduled transaction that was set up by the
>> loan/mortgage
>> >>>>> repayment assistant appear with 0.01 Imbalance-USD.
>> >>>>>
>> >>>>> I would think that GnuCash should have an accuracy method that would
>> >>>>> prevent this from happening.  Is this a bug?
>> >>>>>
>> >>>>> I am using GnuCash 2.6.17 in Ubuntu 16.04 today.
>> >>>> The accuracy method is what created the imbalance entry. ;-)
>> >>>>
>> >>>> There’s nothing in the SX system to pre-instantiate future scheduled
>> >>> transactions and ensure that they’re balanced. What would you have the
>> >>> check function do if it found an imbalanced case? How would you handle
>> >>> variables whose values are set by the user in the SLR dialog?
>> >>>> Regards,
>> >>>> John Ralls
>> >>>>
>> >>>
>> >> _______________________________________________
>> >> gnucash-user mailing list
>> >> [hidden email]
>> >> To update your subscription preferences or to unsubscribe:
>> >> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> >> If you are using Nabble or Gmane, please see
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> >> -----
>> >> Please remember to CC this list on all your replies.
>> >> You can do this by using Reply-To-List or Reply-All.
>> > _______________________________________________
>> > gnucash-user mailing list
>> > [hidden email]
>> > To update your subscription preferences or to unsubscribe:
>> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> > If you are using Nabble or Gmane, please see
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> > -----
>> > Please remember to CC this list on all your replies.
>> > You can do this by using Reply-To-List or Reply-All.
>>
>> _______________________________________________
>> gnucash-user mailing list
>> [hidden email]
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> If you are using Nabble or Gmane, please see
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>
>
_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

David Carlson-4
I have created https://bugs.gnucash.org/show_bug.cgi?id=797032.

David C

On Wed, Jan 9, 2019 at 2:29 AM David Carlson <[hidden email]>
wrote:

> With those numbers payment number 2 has an error.
>
> David C
>
> On Wed, Jan 9, 2019 at 2:23 AM David Carlson <[hidden email]>
> wrote:
>
>> I am working on a test scenario.The interest formula is ipmt( 0.03500 /
>> 12.00 : i : 180.00 : 172,000.00 : 0 : 0 ), the others have the same numbers
>> and the 71st payment contains the error.  I am using these numbers because
>> they are exactly the same as the numbers that have already generated an
>> error.
>> i started the test loan in Jan 2000 with the first repayment in February
>> and I am creating one month at a time in case that makes a difference.  If
>> the test can repeat it I will submit the bug report.
>>
>> David C
>>
>> On Tue, Jan 8, 2019 at 10:52 PM John Ralls <[hidden email]> wrote:
>>
>>> The answer is probably in app-utils/calculation. All of that was
>>> probably written before Guile grew a rational number class and I think that
>>> GncNumerics get converted to doubles before being passed to the interest
>>> functions. That would pretty much guarantee rounding issues.
>>>
>>> Regards,
>>> John Ralls
>>>
>>> > On Jan 8, 2019, at 5:46 PM, Christopher Lam <[hidden email]>
>>> wrote:
>>> >
>>> > Well the SCM has numerous references to "round" and "rounding errors"
>>> so it's to be expected.
>>> >
>>> > Please file a bug with example numbers, and hopefully these errors may
>>> be fixed.
>>> >
>>> > On 9/1/19 7:35 am, David Carlson wrote:
>>> >> John,
>>> >>
>>> >> Thanks for the reference.  Alas, I will need to do some homework to
>>> >> properly read SCM.  There must still be some sort of rounding issue
>>> >> creeping in if the Scheduled Transaction SLR sometimes generates an
>>> >> imbalance from ppmt = pmt - ipmt.
>>> >>
>>> >> David C
>>> >>
>>> >> On Tue, Jan 8, 2019 at 3:44 PM John Ralls <[hidden email]> wrote:
>>> >>
>>> >>> The thee functions are defined in
>>> >>>
>>> https://github.com/Gnucash/gnucash/blob/maint/libgnucash/app-utils/fin.scm
>>> ,
>>> >>> prefixed with gnc: (so gnc:ipmt etc.).
>>> >>>
>>> >>> At line 41ff you'll see that ppmt = pmt - ipmt.
>>> >>>
>>> >>> Regards,
>>> >>> John Ralls
>>> >>>
>>> >>>
>>> >>>> On Jan 8, 2019, at 12:48 PM, David Carlson <
>>> [hidden email]>
>>> >>> wrote:
>>> >>>> My point is that the equations are defined by the assistant, and I
>>> think
>>> >>> that they can be expressed in a form that concentrates all the
>>> errors into
>>> >>> one line where a simple rounding would not generate a problem where
>>> the
>>> >>> parts do not add up to 100%.  Granted, the errors may sometimes cause
>>> >>> inaccurate results, but they would not add the imbalance line to the
>>> >>> transaction.
>>> >>>> The current equations are three  evaluations called pmt(numbers),
>>> >>> ppmt(numbers) and ipmt(numbers) with no clue how they are actually
>>> >>> evaluated.
>>> >>>> Apparently pmt is not always the sum of ppmt and ipmt. when rounding
>>> >>> happens.  If ipmt were expressed as pmt-ppmt, there would be no
>>> imbalance,
>>> >>> but one of the other two ways to express all three may be less
>>> likely to
>>> >>> generate inaccurate results.
>>> >>>> David C
>>> >>>>
>>> >>>> On Mon, Jan 7, 2019 at 10:19 PM John Ralls <[hidden email]>
>>> wrote:
>>> >>>>
>>> >>>>
>>> >>>>> On Jan 7, 2019, at 3:14 PM, David Carlson <
>>> [hidden email]>
>>> >>> wrote:
>>> >>>>> I just had a scheduled transaction that was set up by the
>>> loan/mortgage
>>> >>>>> repayment assistant appear with 0.01 Imbalance-USD.
>>> >>>>>
>>> >>>>> I would think that GnuCash should have an accuracy method that
>>> would
>>> >>>>> prevent this from happening.  Is this a bug?
>>> >>>>>
>>> >>>>> I am using GnuCash 2.6.17 in Ubuntu 16.04 today.
>>> >>>> The accuracy method is what created the imbalance entry. ;-)
>>> >>>>
>>> >>>> There’s nothing in the SX system to pre-instantiate future scheduled
>>> >>> transactions and ensure that they’re balanced. What would you have
>>> the
>>> >>> check function do if it found an imbalanced case? How would you
>>> handle
>>> >>> variables whose values are set by the user in the SLR dialog?
>>> >>>> Regards,
>>> >>>> John Ralls
>>> >>>>
>>> >>>
>>> >> _______________________________________________
>>> >> gnucash-user mailing list
>>> >> [hidden email]
>>> >> To update your subscription preferences or to unsubscribe:
>>> >> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>> >> If you are using Nabble or Gmane, please see
>>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>>> >> -----
>>> >> Please remember to CC this list on all your replies.
>>> >> You can do this by using Reply-To-List or Reply-All.
>>> > _______________________________________________
>>> > gnucash-user mailing list
>>> > [hidden email]
>>> > To update your subscription preferences or to unsubscribe:
>>> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>> > If you are using Nabble or Gmane, please see
>>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>>> > -----
>>> > Please remember to CC this list on all your replies.
>>> > You can do this by using Reply-To-List or Reply-All.
>>>
>>> _______________________________________________
>>> gnucash-user mailing list
>>> [hidden email]
>>> To update your subscription preferences or to unsubscribe:
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>> If you are using Nabble or Gmane, please see
>>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>>> -----
>>> Please remember to CC this list on all your replies.
>>> You can do this by using Reply-To-List or Reply-All.
>>
>>
_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

Michael or Penny Novack
In reply to this post by John Ralls-2
On 1/8/2019 11:50 PM, John Ralls wrote:
> The answer is probably in app-utils/calculation. All of that was probably written before Guile grew a rational number class and I think that GncNumerics get converted to doubles before being passed to the interest functions. That would pretty much guarantee rounding issues.
>
> Regards,
> John Ralls
  I will repeat, this sort of "rounding error" is not a bug.

If two persons set out to perform a calculation which can be done by a
number of methods with rounding involved at numerous places and no
agreement as to either the method to be used or the precision maintained
at each step THERE IS NO REASONABLE EXPECTATION THAT THEIR ANSWERS WILL
MATCH EXACTLY.

Treated as a "bug", it might* be possible to change the code so as to
match the answers of a particular lending institution, but then could be
wrong for another lending institution that used different methods or
rounding than the first.

Michael D Novack    << who in my working days often had to compute the
"fuzz" for comparisons >>

* Might, because you have no reason to suppose that a lending
institution necessarily used the same methods/rounding for car loans as
for house mortgages.
_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

John Ralls-2


> On Jan 9, 2019, at 6:26 AM, Michael or Penny Novack <[hidden email]> wrote:
>
> On 1/8/2019 11:50 PM, John Ralls wrote:
>> The answer is probably in app-utils/calculation. All of that was probably written before Guile grew a rational number class and I think that GncNumerics get converted to doubles before being passed to the interest functions. That would pretty much guarantee rounding issues.
>>
>> Regards,
>> John Ralls
> I will repeat, this sort of "rounding error" is not a bug.
>
> If two persons set out to perform a calculation which can be done by a number of methods with rounding involved at numerous places and no agreement as to either the method to be used or the precision maintained at each step THERE IS NO REASONABLE EXPECTATION THAT THEIR ANSWERS WILL MATCH EXACTLY.
>
> Treated as a "bug", it might* be possible to change the code so as to match the answers of a particular lending institution, but then could be wrong for another lending institution that used different methods or rounding than the first.
>
> Michael D Novack    << who in my working days often had to compute the "fuzz" for comparisons >>
>
> * Might, because you have no reason to suppose that a lending institution necessarily used the same methods/rounding for car loans as for house mortgages.

Which is why GnuCash mostly uses rational numbers and no rounding for internal calculations. Using binary floating-point in financial software is a bug on its own, so that “mostly” is a bug. It needs to be “only”.

This isn’t about matching the results with someone else’s computer, this is about internal consistency in GnuCash.

Regards,
John Ralls


_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

David Carlson-4
Absolutely, I was not expecting agreement with the bank, I just think the
creation of an unbalanced transaction is bad form.

David Carlson

On Wed, Jan 9, 2019, 9:03 AM John Ralls <[hidden email] wrote:

>
>
> > On Jan 9, 2019, at 6:26 AM, Michael or Penny Novack <
> [hidden email]> wrote:
> >
> > On 1/8/2019 11:50 PM, John Ralls wrote:
> >> The answer is probably in app-utils/calculation. All of that was
> probably written before Guile grew a rational number class and I think that
> GncNumerics get converted to doubles before being passed to the interest
> functions. That would pretty much guarantee rounding issues.
> >>
> >> Regards,
> >> John Ralls
> > I will repeat, this sort of "rounding error" is not a bug.
> >
> > If two persons set out to perform a calculation which can be done by a
> number of methods with rounding involved at numerous places and no
> agreement as to either the method to be used or the precision maintained at
> each step THERE IS NO REASONABLE EXPECTATION THAT THEIR ANSWERS WILL MATCH
> EXACTLY.
> >
> > Treated as a "bug", it might* be possible to change the code so as to
> match the answers of a particular lending institution, but then could be
> wrong for another lending institution that used different methods or
> rounding than the first.
> >
> > Michael D Novack    << who in my working days often had to compute the
> "fuzz" for comparisons >>
> >
> > * Might, because you have no reason to suppose that a lending
> institution necessarily used the same methods/rounding for car loans as for
> house mortgages.
>
> Which is why GnuCash mostly uses rational numbers and no rounding for
> internal calculations. Using binary floating-point in financial software is
> a bug on its own, so that “mostly” is a bug. It needs to be “only”.
>
> This isn’t about matching the results with someone else’s computer, this
> is about internal consistency in GnuCash.
>
> Regards,
> John Ralls
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

Fred Bone
On Wednesday, January 9, 2019 at 9:44, David Carlson said:

> Absolutely, I was not expecting agreement with the bank, I just think the
> creation of an unbalanced transaction is bad form.

There is no reason to expect that taking three rational numbers A, B and
C, such that A=B+C, converting to decimal and rounding to two decimal
places, will never result in imbalance.

The simplest example I can come up with is 9/7, 5/7 and 4/7 where
 9/7 = 1.285714... -> 1.29
 5/7 = 0.714285... -> 0.71
 4/7 = 0.571428... -> 0.57
with imbalance 0.01


_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

Stephen M. Butler
In reply to this post by Michael or Penny Novack
On 1/9/19 6:26 AM, Michael or Penny Novack wrote:

> On 1/8/2019 11:50 PM, John Ralls wrote:
>> The answer is probably in app-utils/calculation. All of that was
>> probably written before Guile grew a rational number class and I
>> think that GncNumerics get converted to doubles before being passed
>> to the interest functions. That would pretty much guarantee rounding
>> issues.
>>
>> Regards,
>> John Ralls
>  I will repeat, this sort of "rounding error" is not a bug.
>
> If two persons set out to perform a calculation which can be done by a
> number of methods with rounding involved at numerous places and no
> agreement as to either the method to be used or the precision
> maintained at each step THERE IS NO REASONABLE EXPECTATION THAT THEIR
> ANSWERS WILL MATCH EXACTLY.
>
> Treated as a "bug", it might* be possible to change the code so as to
> match the answers of a particular lending institution, but then could
> be wrong for another lending institution that used different methods
> or rounding than the first.
>
> Michael D Novack    << who in my working days often had to compute the
> "fuzz" for comparisons >>
>
> * Might, because you have no reason to suppose that a lending
> institution necessarily used the same methods/rounding for car loans
> as for house mortgages.
And some use generic 30 day months while others use the actual number of
days in each month.  Some compound daily while others use simple interest.

--
Stephen M Butler, PMP, PSM
[hidden email]
[hidden email]
253-350-0166
-------------------------------------------
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: [GNC] Loan Mortgage repayment assistant problem

David Carlson-4
In reply to this post by Fred Bone
Yup!

On the other hand, 1.29-0.71 = 0.58, so while one solution might be to
create a transaction with those particular numbers, that method generates
too much error for some calculations or combinations of values.  That is
why the developers are working to use real math whenever possible.

I recently found the hp49g+ calculator that i bought about a decade ago and
discovered that it can work either in exact or approximate CAS modes, as
they describe them.  And it still works!

David C

On Wed, Jan 9, 2019 at 11:31 AM Fred Bone <[hidden email]> wrote:

> On Wednesday, January 9, 2019 at 9:44, David Carlson said:
>
> > Absolutely, I was not expecting agreement with the bank, I just think the
> > creation of an unbalanced transaction is bad form.
>
> There is no reason to expect that taking three rational numbers A, B and
> C, such that A=B+C, converting to decimal and rounding to two decimal
> places, will never result in imbalance.
>
> The simplest example I can come up with is 9/7, 5/7 and 4/7 where
>  9/7 = 1.285714... -> 1.29
>  5/7 = 0.714285... -> 0.71
>  4/7 = 0.571428... -> 0.57
> with imbalance 0.01
>
>
> _______________________________________________
> gnucash-user mailing list
> [hidden email]
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
_______________________________________________
gnucash-user mailing list
[hidden email]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.