Maintaining accuracy of ratios in numpy
All your ratios are rational numbers, so you could use the Fraction class in the fractions module. Each "fraction" is the ratio of two integers. And since Python's integers have no upper limit, neither do the fractions. You can treat them much like float values--add, subtract, multiply, divide, and print them.
I did something very much like your operations in a previous project of mine, to track ratios in the tree structure of Windows Registry. I did this project in Delphi but have started redoing it in Python. I have already decided to use fractions.
The problem is that the values will be kept exactly, as well as the operations on them. But if you plot them on a graph, the values may still be overwhelmed by other values.
I am using numpy to analyze graphs.  One type of analysis I am doing is traversing, while enumerating: "how often is node K in a path with node J, up to this point". In this analysis, many of my values are ratios, or percentages, or however you want to think of it.
Since graphs often branch, they are often exponential when it comes to combinations or permutations.  And so, some of the time, my ratios become very small.  And, numpy loses accuracy.  And, eventually, numpy says that the ratio is zero even though it should still be greater than zero.
To elaborate a bit more, I use rows of the matrix to represent depth of my search, and I use columns to represent nodes.  The value of the [row,column] is the ratio of said node, at said depth, to whatever other node I am comparing it to.  And so it's the case, that depending upon the graph, that ratio may be cut in half at every next level.  From 1, to .5, to .25, to ..... 1.369^(-554) and suddenly it's zero next iteration.  Not to mention, when it gets small enough I lose accuracy in all my other calculations as well.
If I want extreme accuracy even on large graphs, what options do I have?  I suppose I could enumerate in the opposite direction, getting total counts and doing division to recalculate ratios when necessary (it is necessary at time in my program).  But if I do this, I still expect I would lose a ton of accuracy when I divide one huge number by another huge number, yes?