[lp-ca-on] Fwd: Re: tax software design considerations

[Greg Knittl]

For more than 10 years I've struggling with the "spreadsheet" component of the income tax application.
Yesterday I finally realized that the specific spreadsheet component that's required is just a topological
sort to get the income tax formulae in the correct order to evaluate. Topological sort is available on the
 command line where it's called tsort. Here's tsort for the sample equations in the email below

tsort <<EOF
> b a
> c a
> e b
> d b
> c f
> d f
> EOF
c
d
e
f
b
a

For all the graph theorists out there, I may have got the order of the nodes reversed, but you get the idea.
Topological sort is available in Ruby, R seems to have one http://www.inside-r.org/packages/cran/igraph/docs/topological.sort
and probably many other languages have it.

It doesn't even matter because the application could use the bash tsort. In fact both the calculation engine and the tax formulae could
be written in bash. Bash could handle any tax formula that I can think of.

I'm working on a list of design criteria for a tax program.

Greg
-------- Forwarded Message --------

Subject:	Re: [lp-ca-on] tax software design considerations
Date:	Wed, 25 May 2016 08:38:09 -0400
From:	Greg Knittl <address@hidden>
To:	Allan Zhang <address@hidden>
CC:	Libreplanet Canada Ontario <address@hidden>

Hi Allan,

Looks interesting. R seems to be a free language. Able to output in XML 
which is my best guess as to the required format.
I have no knowledge of R at all. Can you write sample code to read and 
execute something like:
A=B+C
B=D+E
F=C+D
It would be good if it could detect dependency loops - There is at least 
one circular calculation in the Income Tax Act (ITA)
if you want to deduct Foreign Non-Business Income Tax - see forms 
T2209/T2036

https://github.com/charliesome/makefile-1-2-3 uses make to manage the 
dependencies and bash to do the calculations
I like this approach because it separates and exposes the dependencies 
and calculations. The tools are libre, widely available
and easily extensible. I think it would be possible to carry descriptive 
information through the process.
I think it would be possible to adapt it to income tax which is cell 
based but not exactly a grid layout.
It would be possible to write the calculations in bash to start with to 
avoid creating a formula language and simplify the compilation step.
On the downside it's definitely "clunky" to treat each variable as a file.
make has it's issues: 
http://www.conifersystems.com/whitepapers/gnu-make/ . Perhaps there are 
better libre dependency managers.

Maybe simplest is to write a program that builds Libre Office 
spreadsheet(s) based on a rules file and then a separate input file of 
user values...
But that will create dependencies on the Libre Office internal format...

Greg

On 16-05-24 11:24 PM, Allan Zhang wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> What about R? It would be extremely easy to do these calculations and output in an appropriate form.
>
>
>
> - -------- Original Message --------
> From: Greg Knittl <address@hidden>
> Sent: May 24, 2016 10:54:35 PM EDT
> To: address@hidden
> Subject: [lp-ca-on] tax software design considerations
>
> Income tax software has to perform spread-sheet like calculations which
> I believe are more generically known as reactive programming.
> It would be nice to feed the calculation rules into the engine as data
> which means either a compile step or a reflexive language.
> I've written my tax calculations in XSLT 2.0 which can do reactive
> programming via global variables. However it is not reflexive as of 2.0.
> This looks to be available in XSLT version 3.0
> https://www.w3.org/TR/xslt-30/#element-evaluate. I'm not sure if there
> is a libre version of XSLT 3.0.
> Meanwhile I've hardcoded the calculation rules in the XSLT 2.0 code.
>
> There is most likely a better way. _javascript_? Lisp?
>
> Greg
>
> -----BEGIN PGP SIGNATURE-----
>
> iQI5BAEBCgAjHBxBbGxhbiBaaGFuZyA8YWxsYW5AYXppYy5jYT4FAldFGtQACgkQ
> lQhQ+uFN8kMpfA//Z5nE21g26ZDqLDNxGw9J6msRIZSK9WDCds7ibinIlnUFL0WX
> maYHjENQq+KyN3E81zKmmxgqlFE0kVbvUR2QRSJiYrq2tuHUj/68KypH1nb2/agj
> ksMdbpCHxdF8Ll1FZBjWtzWAUMAK+9EiKpZ02VLypgtMprfqLV2MiXdXlZV4SJBt
> QXNh9na3zEiQa6WX8G+HqwA7DWBeqiCkvQg97a+W8wyKs5iA5Ld5Y9EhrzwD2V1X
> Z44nFGxGoK2VNLxCSMITfucjQEyql52sBZIp0GJwMt826pOkrwR1uPjR7C8n1wik
> 0/3csySFO7Ngg1jrCLSdk3fkF7ostZ62PKzAAaLnooZ4cHVNhc7srYBhIq03MHIC
> qRKizW0rLT6/9eMOk5Ky4fBgDdxHfeJFQ2Br1osZnAz0gXAkb/mqhbFa6FxckESw
> Njtz3PERdORhcdet8a+ipCectQ+DGFLSzVo0KeuZkFUHyE8yAncYS46fO1jmkfLd
> OmiVS1GtnDcuv4kFpJlHGVSNdNL61PejA8+Md6/YKSHv018s6SRj0FOllxSzDOan
> 0RN2cPbqAAvK7khg9xh3PTzQ4BFBA22eDEd/fCJG9S4uFs/B6viVyS/B52oIZTAw
> kI2vCCXDwXrYmRT/Zp2QXzFKFGMc3Z0nsdvsZ/lVHrpnHGjaTeJThjLhWYw=
> =VxNE
> -----END PGP SIGNATURE-----
>
>
>