<div dir="ltr"><div><div><div><div><span></span><span></span>Hello everyone, <br></div>I am Tripun Goel and I am glad to announce that I am the selected student sponsored by GSoC '2014 to intern for Software Freedom Conservancy. I am excited to work with my mentor Bradley Kuhn and other community members. Here are some details of the project.<br>
------------------------------------<br><b>Short description:</b> Add a -–precision option to
specify maximum precision you want and set it as default minimum
precision for all amounts.Add suitable tests for the bugs I will close
related to precision. Extend test suite to for better coverage.<br><br><span style="font-size:medium"><b>Project</b>: My proposal has two parts depending upon which design is selected.</span><br><br><span style="font-size:medium"> (1) <b>Convert Ledger-CLI to use fixed-point arithmetic</b></span><br>
<span style="font-size:medium">
The point to note is that Ledger-CLI uses multiple precision
floating point numbers via MPFR library. I got to say that it is robust
in terms of precision with correct rounding, so I compared in terms of
what benefit we may get if we convert and how to implement. I already
responded to bug 992 which show that internally round off errors occur
only when precision is not properly set. There may be other floating
point issues but not the issue rose in the bug. The precision is taken
to be the maximum precision of quantity of a commodity encountered till
the parsing of current transaction and hence precision of fixed lot
price or cost is ignored. The amount of each commodity in each account
should be set to highest precision of the lot price, cost or quantity.
This will automatically prevent balance from being rounded off. However
it is also important to guarantee fixed precision in any accounting
software rather than the arbitrary one. </span><br><span style="font-size:medium"> How to do this?</span><br><br><span style="font-size:medium"> (a) <b>Add a --precision option</b>
to specify maximum precision you want and set it as default minimum
precision for all amounts. Of course the precision will be the maximum
of either of all transactions or of that set by the user. This is in
order to guarantee the user at least the precision specified. It has
following benefits</span><br><br><span style="font-size:medium"> ·Minimal changes to the source.</span><br><br><span style="font-size:medium"> · The previous tests should still pass when this option is not set.</span>
<p style="text-align:left"><b><span style="font-size:medium">or</span></b><br><br><span style="font-size:medium"> (b) <b>Add a fixed point class.</b></span><br><br><span style="font-size:medium">
Although desirable, it will be the least preferred task to do. As
Ledger CLI is actively maintained and uses MPFR library, any effort to
convert to fixed point will be a parallel effort and needs to be
maintained separately. Also fixed point is specific to NPO project as
there may be other use cases which require arbitrary and higher
precision. Many fixed-point implementations are already available on the
internet but we need to have portable integer format and transactions
which may involve calculations well beyond the limits of standard
integer data types provided in C++. The numbers are stored in integer
format with decimal part (base 10) multiplied by 10^p where p is the
number of digits of precision.</span><br><br></p>
<ul><li><span style="font-size:medium"> ·Define a fixed class with
mpz_t (From GMP lib) for integer part and an integer precision
specifying the number of digits required after decimal. Then we overload
the required operators and define necessary constructors. The
intermediate calculations are real numbers which are converted to
fixed point which cause precision loss if the precision involved is
greater than fixed precision.</span></li><li><span style="font-size:medium"> ·Write wrapper classes for mpfr types used in the program and replacing their declaration with the wrapper classes.</span></li><li><span style="font-size:medium"> ·List out the errors caused and correct them by providing appropriate overloaded operators and functions.</span></li>
<li><span style="font-size:medium"> · Test that the build
passes for specified tests as it is bound to fail for tests involving
higher precision than the fixed precision.Eg unit tests for amount
intialization.</span></li></ul>
<p><span style="font-size:medium"> </span><br><br><span style="font-size:medium"> </span><br><br><span style="font-size:medium"> (2) <b>Build a better test suite for Ledger-CLI.</b></span><br><br><span style="font-size:medium">
Keeping in mind it is an NPO accounting project. More test cases can
be written which will focus on the need of this project. Although the
suite is good but not all test cases are covered. Add suitable tests for
the bugs I will close related to precision. Following are the issues I
want to cover in the basic test suites</span></p><p></p><ul style="text-align:left"><li><font face="Arial,Helvetica,sans-serif">Test overflow (input and precision)</font></li><ul><li><font face="Arial,Helvetica,sans-serif"> Input million dummy transactions.</font></li>
<li><font face="Arial,Helvetica,sans-serif"> Each transaction with thousands of entries</font></li></ul><li><font face="Arial,Helvetica,sans-serif">Baseline tests</font></li><ul><li><font face="Arial,Helvetica,sans-serif"> write validation tests for more options and various combinations.</font></li>
</ul><li><font face="Arial,Helvetica,sans-serif">Test Value Expressions</font></li><ul><li><font face="Arial,Helvetica,sans-serif"> Test more evaluation expression,masks, queries and automated transaction expressions</font></li>
</ul><li><font face="Arial,Helvetica,sans-serif"> Add more corner cases</font></li><ul><li><font face="Arial,Helvetica,sans-serif"> for example : pricemap and price history option are not extensively tested</font></li>
</ul><li><font face="Arial,Helvetica,sans-serif"> Unit Tests</font></li><ul><li><font face="Arial,Helvetica,sans-serif"> extend tests to more functions and classes like xact, commodity pool </font></li>
</ul><li><font face="Arial,Helvetica,sans-serif"> Regression tests</font></li><ul><li><font face="Arial,Helvetica,sans-serif"> .Write test for fixed issues which were not included in regression tests </font></li>
</ul><li><font face="Arial,Helvetica,sans-serif">Others</font></li><ul><li><font face="Arial,Helvetica,sans-serif"> Test
cases to determine whether unconfirmed bugs exist or not. Writing and
testing scripts for generating reports in various formats as relevant to
NPO requirements like the ones contributed to ledger project by
Software conservancy.</font></li></ul></ul><p><span style="font-family:Arial,Helvetica,sans-serif"></span></p><p><br></p><p></p><span style="font-size:medium"></span><p style="text-align:left"><span style="font-size:medium"><b> Deliverables</b>:</span><br>
<span style="font-size:medium"> 1. Fixed and closed round-off by one bugs</span><br><span style="font-size:medium"> 2. Extended Test suite.</span><br><br><span style="font-size:medium"> <b>Challenge</b>s:</span><br>
<span style="font-size:medium"> 1. Fix precision bug by either way. </span><br><span style="font-size:medium"> 2. List as many test cases as possible. </span><br><span style="font-size:medium"> 3. Get those tests merged with the main branch.</span></p>
<p style="text-align:left"><span style="font-size:medium"> 4. Prevent new bugs </span></p>
<p style="text-align:left"><span style="font-size:medium"> 5. Pass the build with new as well old tests</span></p>
<p style="text-align:left"><br><span style="font-size:medium"> <b>Benefits:</b></span><br><span style="font-size:medium"> 1. More reliable accounting with fixed precision.</span><br><span style="font-size:medium"> 2. Better the test suite , lesser bugs post release.</span></p>
-------------------------------------<br></div>I hope I will deliver up to the expectations of the community and receive support of its members.<br><br></div>Regards<br></div>Tripun Goel<br><div><div><div><div><br><br><br>
</div></div></div></div></div>