Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find Root operation does not follow Excel spec as stated in comment => common.fs #27

Closed
bjgallag opened this issue Dec 17, 2020 · 2 comments · Fixed by #63
Closed

Find Root operation does not follow Excel spec as stated in comment => common.fs #27

bjgallag opened this issue Dec 17, 2020 · 2 comments · Fixed by #63
Labels
bug Code defect in shipping code ready Fix is ready in a feature branch

Comments

@bjgallag
Copy link

Description

Microsoft's documentation for the XIRR function states under the Remarks section that they guarantee 1x10^-6 accuracy; however, this library is using 1x10^-7 accuracy in common.fs findRoot function. Removing one zero would align with Microsoft's standards: https://support.microsoft.com/en-us/office/xirr-function-de1242ec-6477-445b-b11b-a303ad9adc9d

Repro steps

Please provide the steps required to reproduce the problem

  1. Call the financial.XIrr function with the following parameters. These dates are July 3rd, 2020 and Feb 25th, 2021:
    DateTime[] dateTimes = { new DateTime(2020,7,3), new DateTime(2021,2,25)};
    double[] doubles = {-177900000, 8799805.85};
    Financial.XIrr( doubles, dateTimes, 0.1);

Expected behavior

A value should be returned representing the IRR amount, which should be -0.990247691899517.

Actual behavior

Exception is generated saying that the root could not be found.

Known workarounds

N/a
This issue can be fixed by changing the precision value in common.fs's findRoot method from 1x10^-7 to 1x10^-6.

Related information

  • Using a Windows 10 OS
  • On the Master branch
  • .NET Runtime
@jcoliz
Copy link
Member

jcoliz commented Nov 20, 2021

Find root is definitely challenged. In this case, Xirr succeeds if you give a guess of -0.97 or -0.98, but fails with -0.96 or higher. So right now, you just need to guess better 😅 . It's interesting that changing the precision fixes the problem. Worth looking at this. Thanks for diagnosing the issue.

@jcoliz jcoliz added the bug Code defect in shipping code label Nov 20, 2021
@jcoliz
Copy link
Member

jcoliz commented Nov 21, 2021

I committed the proposed change. It passed all the tests including the "console" interop tests. It's resting in the feature/issue-27 branch. I want to release the netcore replatforming out first without code changes. So I'll target this for a following bugfix release.

@jcoliz jcoliz mentioned this issue Nov 21, 2021
@jcoliz jcoliz added the ready Fix is ready in a feature branch label Dec 8, 2021
@jcoliz jcoliz mentioned this issue Dec 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Code defect in shipping code ready Fix is ready in a feature branch
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants