Issue 27002 - Precision problem in the financial function xirr
Summary: Precision problem in the financial function xirr
Status: CLOSED FIXED
Alias: None
Product: Calc
Classification: Application
Component: code (show other issues)
Version: OOo 1.0.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: kla
QA Contact: issues@sc
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-26 15:41 UTC by jemo
Modified: 2013-08-07 15:15 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description jemo 2004-03-26 15:41:41 UTC 
The precision of the internal return rate calculated by the function xtri is 
insufficient (in fact, i use the french translated function tri.paiements).

Precision problem in the financial function xtri

Example, enter the following cash-flow/date couples :

-100   1/1/04
10    1/1/05
10    1/1/06
110   1/1/07

The xtri function on these cashes should have returned 0.1. It returns 0.099.

I guess that it is caused by an inproper test of the end of the iteration loop.

Best,
JJ
Comment 1 frank 2004-03-29 10:11:53 UTC 
Hi,

I'm sorry but I could not find this function.

Please attach a document showing your problem.

Thanks.

Frank
Comment 2 frank 2004-03-29 13:00:26 UTC 
Hi Jean-Jacques,

this is in the basics of the statistical functions and therefore a double to
Issue 18704. Eike has set the needhelp keyword for this Issue and appreciates
any help you can give.

Thanks.

Frank

*** This issue has been marked as a duplicate of 18704 ***
Comment 3 frank 2004-03-29 13:01:38 UTC 
Ooopps,

wrong handling.

Reopened

Frank
Comment 4 frank 2004-03-29 13:03:13 UTC 
Hi Eike,

I think this one is for you.

I've set the blocks value.

Frank
Comment 5 ooo 2004-03-31 09:57:21 UTC 
Adding needhelp keyword for time reasons.
Comment 6 ooo 2004-04-08 16:59:11 UTC 
It turned out that the difference observed results from the fact that
calculation is based on a 365 days per year basis, ignoring leap years. This is
identical to what the main competitor does and documents, and the AddIn
functions try to mimic it as close as possible.

@Uwe: Please add a sentence about the 365 days per year calculation to the XIRR
function's documentation. The same holds true for the XNPV function, being the
reverse operation of XIRR.

Eike
Comment 7 ooo 2004-04-08 17:01:34 UTC 
Reassigning, forgot to click the radio button..
Uwe, please see the previous comment.
Comment 8 chris319 2004-04-13 01:16:45 UTC 
The difference between 365 and 365.25 days in the XIRR calculation can be worked
around (multiply the result by 365/365.25) IF you know about the difference to
begin with. Agreed that this should be documented.
Comment 9 Uwe Fischer 2004-04-13 08:22:29 UTC 
Will add a sentence about the 365 days per year calculation to the XIRR
function's documentation. The same holds true for the XNPV function, being the
reverse operation of XIRR.
Comment 10 Uwe Fischer 2004-04-20 10:47:02 UTC 
help for XIRR and XNPV edited
Comment 11 Uwe Fischer 2004-10-21 11:51:34 UTC 
.
Comment 12 Uwe Fischer 2004-10-21 11:51:57 UTC 
UFI: QA, pls verify in CWS helpcontentbeta and close
Comment 13 Uwe Fischer 2004-10-21 11:52:15 UTC 
.
Comment 14 kla 2004-11-19 16:11:05 UTC 
kla: verified in cws helpcontentbeta
Comment 15 kla 2004-12-03 15:19:26 UTC 
kla: ok in master m64 ->closed