std_dev calculation stuck in newer versions

[anchal-physics]

Hi
I've been trying to use uncertainties in my module. I've tried to create the smallest code I could create to regenerate the issue I've been seeing. Please find it attached.
The code tries to create a class ucomplex to hold complex numbers as tuples made out of ufloat numbers.
Then a recursive calculation is done to calculate some parameters and the output is displayed. The thing is that the calculations run really fast in the latest version (3.1.2) of uncertainties but the final display step takes a long time. You can see that with just nol=5, which increases the recursive steps, the time taken becomes really long. Here is the output:

Calculations done.
Took me 0.023484230041503906 s to calculate
Just trying to print
Coat CTR (2.63+/-0.10)e-05
Took me 101.55465269088745 s to display
Coat del CTE (1.85+/-0.25)e-05
Took me 0.0003113746643066406 s to display

While in version 2.4.8.1, this calculation is slower but the display is lightning fast even for nol=57 which is my required value to use. Output:

Calculations done.
Took me 99.11081385612488 s to calculate
Just trying to print
Coat CTR (5.2+/-0.5)e-05
Took me 0.04099583625793457 s to display
Coat del CTE (1.83+/-0.25)e-05
Took me 0.010044097900390625 s to display

But this still takes overall much less time than the nol=5 case for 3.1.2.
My guesses are:

1. The new version(3.1.2) just goes with nominal_value calculations during the run and calculates the std_dev for only those values which are asked for by retracing the whole path that was taken to calculate the value. And this is why the display part takes more time.
2. The older version(2.4.8.1) calculates std_dev along with
   uncErrorRegeneration.zip

the calculations and hence is slower but the display is instant.
3) Somehow, there is some part in calculation with ucomplex which is taken long time for uncertainties to get derivative of for calculation of std_dev.

I would like to know if there is some feature which can enable std_dev calculation on the run as being done in 2.4.8.1 or suggest some changes in my definition of ucomplex which might be causing this problem. I would like to make my module compatible with the latest version of uncertainties.

[lebigot]

Before version 3.0, each intermediate result stores its exact dependence on the relevant variables (eager calculation). Starting with version 3.0, this dependence is indeed probably calculated only when the uncertainty is needed (this is to be confirmed; presumably, #30 contains most of the relevant information, but finding it is not so obvious). This brought a massive (think like 5,000 x) for a calculation like sum(ufloat(1, 1) for _ in xrange(100000)).

Doing something like a cumulative sum of independent variables is still very expensive: it runs in quadratic time, because each term as 1, 2, 3,… etc. variables and the current algorithm (very likely) keeps a separate structure in memory for each term. Could your case be similar to this?

[lebigot]

There is more information on the optimizations introduced in version 3.0 in issue #53.

The general key point to keep in mind about any version is that any intermediate result that is printed prompts a calculation that requires the evaluation of derivatives with respect to all its variables. Thus, printing each term of a cumulative sum requires a quadratic calculation time, which is slow. Could this be the problem in your case?

[anchal-physics]

Hi
Thanks for the reply. My code is indeed doing cumulative calculations (not just sums). It is implementing a recursive formula, so I do not really have a way of unwrapping it and make it a simple expression. But to answer your second question, no, I do not print out or even use the intermediate terms in the recursive calculation and only the final term is used.
I'm actually thinking of doing some part of the uncertainty calculation manually as the code actually calculates first derivatives with respect to each variable. This might solve the problem but I'm not sure this will be compatible with the rest of the error calculations done by uncertainty package in terms of error propagation theory as to uncertainty package, the calculated variable would just look like an independent variable.

[lebigot]

OK. What do you mean exactly by "the code calculates first derivatives": that you wrote custom code for this? I'm asking this because uncertainties does just this, and the code may be doing unnecessary work, that may in addition be optimized in uncertainties.

[anchal-physics]

Jinx!
Because as I was writing that, I thought of the same thing. So I went back to try out the derivatives functionality of uncertainty package. But it was taking a very long time to compute the derivatives (as expected because it was taking a long time to calculate the uncertainties too). My guess is that your derivatives code would might indeed be more powerful for generic calculation, but in my case, things are little bit messy due to the presence of complex quantities.
That is my other guess actually, that the uncertainties package might be stuck in someplace where variation is not smooth, like taking a conjugate or pulling out the real part, although none of this is present in the calculations.
For a cherry on the top, I actually don't know if my own custom code works correctly because this is a research calculation and I don't know if a new thing that I'm calculating is correct. So I'm testing that out through other means to confirm that. I'll update here if things work out or I get more hint of what is happening.
Thanks

[lebigot]

If I understand correctly, the total run time (calculation + display) is essentially the same for both version 3 and version 2 of uncertainties, right? If this is the case, where is the problem? If you do a calculation and don't need to display it, then it's good that it's fast (like in version 3), but if you need to display it, then only the total calculation + display time matters, right?

[lebigot]

I am closing this, as it looks like there is no problem (same total run time with versions 2 and 3). If this is not the case, please reopen the issue.