From the author of the gvar package: The use of gvar.factory instead of gvar.gvar should solve the problem and is compatible with the use of the lsqfit package.
Peter Lepage:
The GVar variables created in your last line are being discarded, but their variances are being retained (in case those variables were used to create other variables). To illustrate what is going on consider the following example:
import gvar as gv
import numpy as np
def f():
x = gv.gvar('1(1)')
y = gv.gvar('2.0(5)')
return [x + y, x - y, y * gv.cos(x / y), gv.log(x * y)]
z = f()
print(gv.evalcov(z))
Here the GVar variables x and y are discarded at the end of f(), but their variances are stored (globally) so that the covariances between the different components of z can be constructed when needed. The covariance matrix for the z[i] is printed by the last line and is:
[[ 1.25 0.75 -0.20010171 1.125 ]
[ 0.75 1.25 -0.75874937 0.875 ]
[-0.20010171 -0.75874937 0.54193606 -0.33976362]
[ 1.125 0.875 -0.33976362 1.0625 ]]
The variances (or covariances) for any new GVar(s) created using gvar.gvar(...) are automatically retained for this purpose. The gvar module would be a lot simpler if it wasn't required to capture the correlations between the different z[i]s.
This behavior doesn't seem to make sense for your example where you create 40 billion GVars that you never use, but I assume that your real code actually does use these variables. If it is the case that the GVars used in one iteration are of no relevance to any other iteration of the loop, then it is possible to avoid the memory build up by using a different version of the function gvar.gvar in each iteration:
import gvar as gv
import numpy as np
for i in range(4000000):
tmp_gvar = gv.gvar_factory()
spectrum = np.arange(100)
spectrum = tmp_gvar(spectrum, np.ones(100))
This hasn't been useful for the things I do, but it might be relevant for other work.
From the author of the gvar package: The use of gvar.factory instead of gvar.gvar should solve the problem and is compatible with the use of the lsqfit package.
Peter Lepage:
The GVar variables created in your last line are being discarded, but their variances are being retained (in case those variables were used to create other variables). To illustrate what is going on consider the following example:
import gvar as gv
import numpy as np
def f():
x = gv.gvar('1(1)')
y = gv.gvar('2.0(5)')
return [x + y, x - y, y * gv.cos(x / y), gv.log(x * y)]
z = f()
print(gv.evalcov(z))
Here the GVar variables x and y are discarded at the end of f(), but their variances are stored (globally) so that the covariances between the different components of z can be constructed when needed. The covariance matrix for the z[i] is printed by the last line and is:
[[ 1.25 0.75 -0.20010171 1.125 ]
[ 0.75 1.25 -0.75874937 0.875 ]
[-0.20010171 -0.75874937 0.54193606 -0.33976362]
[ 1.125 0.875 -0.33976362 1.0625 ]]
The variances (or covariances) for any new GVar(s) created using gvar.gvar(...) are automatically retained for this purpose. The gvar module would be a lot simpler if it wasn't required to capture the correlations between the different z[i]s.
This behavior doesn't seem to make sense for your example where you create 40 billion GVars that you never use, but I assume that your real code actually does use these variables. If it is the case that the GVars used in one iteration are of no relevance to any other iteration of the loop, then it is possible to avoid the memory build up by using a different version of the function gvar.gvar in each iteration:
import gvar as gv
import numpy as np
for i in range(4000000):
tmp_gvar = gv.gvar_factory()
spectrum = np.arange(100)
spectrum = tmp_gvar(spectrum, np.ones(100))
This hasn't been useful for the things I do, but it might be relevant for other work.