Gvar

Latest version: v13.0.2

Safety actively analyzes 630450 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 15 of 18

4.6.1

Not secure
===========================
Cleaning up some small bugs introduced with the new lsqfit.wavg. Also
introduced an approximate but potentially much faster *fast* mode for it.

4.6

========================
The main change here is an upgrade to lsqfit.wavg.

- Somewhat incompatible change in lsqfit.wavg: When averaging arrays or dicts,
wavg used to ignore correlations between different elements of the
array or dict. The new wavg takes account of all correlations between
different pieces of input data. wavg returns a GVar if averaging
a list of GVars, a numpy array of GVars if averaging a list of arrays
of GVars, and a Bufferdict of GVars or arrays of GVars if averaging
a list of dicts. In each case the return value has extra attributes:
chi2, dof, Q, time, fit. The function itself also has these attributes,
coming from the last fit.

- gvar.mean(g) now returns g unchanged if g contains objects of type
other than GVar. This is useful for writing functions that must work
with either GVars or floats as arguments: gvar.mean can be used to
strip the sdev off of GVars where it isn't needed or wanted.

- New function gvar.asbufferdict(g) converts dictionary g to a
BufferDict unless it already is one, in which case it returns g.
The keys in the final result can be restricted by adding a
a list of keys as a second argument: gvar.asbufferdict(g, keylist).

4.5.3

Not secure
===========================

- Fixed bug in gvar._gvarcore that caused problems on win64 systems.

- GVar's __cinit__ has been changed to an __init__, which makes derivation
from GVar possible. GVar also has new property: g.internaldata.
This allows simplifies derivation from GVar --- see, for example,
class WAvg in lsqfit._extras.py. Finally a cython declaration file,
gvar.pxd, is installed for the benefit of other cython modules:
cimport gvar gives the module access to the internal definitions of
cython extension types GVar, svec and smat.

- lsqfit.wavg (weighted averages) now returns a variable
of type WAvg which is a class derived from GVar (with all of
its functionality) but with added attributes: chi2,
dof, and Q which are the chi2, dof, Q from the wavg. In the past these were
read off the function itself (eg, wavg.Q) but this is nonintuitive.
Now ans = lsqfit.wavg(list_of_GVars) is a GVar with the extra
attributes (ans.chi2, ans.dof, ans.Q). lsqfit.wavg still has attributes
chi2, Q etc to help with legacy code. Also this is useful if the average
is over a list of arrays or dictionaries (ie, a multidimensional random
variable). In this case the individual GVars in the result have chi2s, etc
as described above, while lsqfit.wavg has the chi2 for the entire set (ie,
the sum of the chi2s for all the components).

4.5.2

==========================

- str(x) and repr(x) for GVar x both now return strings using the
'2.31(10)' format rather than the older '2.31 +- 0.1'.
The old format is still supported on input, but it will
no longer appear in (default) printing. Use x.fmt(-1) to obtain the old
format.

- Added gv.evalcorr(g) which calculates the correlation matrix of the
GVars in g.

- gv.chi2 has a new option (fmt=True) that causes it to return a string
(describing the chi**2) rather than the numerical value of chi**2.

- Operators > and < are now defined for gvar.GVars. This allows algorithms
to order GVars, which is occasionally useful. The ordering is based upon
the mean values. Operators >= and <= are still *not* defined, because of
incompatibilities with == and !=, which look not just at mean values but
also at all the dependencies. These incompatibilities suggest that one
shouldn't define > and < either, except that there are times when it is
quite useful to be able to order a numerical data type for algorithmic
reasons. The setup here is a compromise (kludge?).

- Fixed very minor bug in lsqfit.nonlinear_fit.format().

4.5.1

==========================

- polishing/minor fixes for nonlinear_fit.simulated_fit_iter. Also now has
a bootstrap option.

- copy.copy and copy.deepcopy now work with GVars.

- very minor fix to gvar.uncorrelated

4.5

========================

- nonlinear_fit.simulated_fit_iter generates fits of new simulated
data that is generated randomly from the original fit data. This
data is useful for testing fits and tuning parameters in them.
Simulated data has the same covariance matrix as the original data but
its mean values fluctuate around values given by the fitting
function evaluated at user-specified parameter values p=pexact.
The values in pexact are the "correct" values that should
be obtained from a fit of the simulated data --- that is, the
results of the fit to simulated data should agree with pexact
to within errors. Knowing the correct answers for the fit
parameters ahead of a fit allows for very realistic testing. See
the documentation in the Tutorial section on Testing Fits with
Simulated Data for more information.

- nonlinear_fit.format() now adds 1 to 5 stars at the end of any
parameter line where the parameter and the prior differ by more
than 1 to 5 (or more) standard deviations, respectively. Stars
are also added when fit data is printed out where fit data
and the fit differ by more than 1 standard deviation. These are
meant to draw attention to potential problems.

- New function: gvar.chi2(g1, g2) computes the chi**2 of g1-g2, where
g1 and g2 are (multi-dimensional) distributions. One of g1 or g2 can
contain numbers instead of GVars (and/or can be missing entries
contained in the other). Also gvar.chi2(diff) where diff = g1 - g2
equals gvar.chi2(g1, g2).

- gvar.dataset.avg_data has new option specified by parameter noerror.
Setting noerror=True causes avg_data to compute averages but not
the errors in those averages.

- gvar.ranseed() called without an argument generates its own random
seed to reinitialize the numpy random number generates. The seed is
returned by the subroutine and can be used to recover the random
number stream in later work. The seed is also stored in gvar.ranseed.seed.
The idea is to use gv.ranseed() at the start of a code and print out
gvar.ranseed.seed so that the seed can, if desired, be used to recreate
the same random numbers in a later run. The key here is the 'if desired';
usually you might not care to recreate a run unless something unusual
happens.

- The tutorial in the documentation has a new section (at the end)
with a pedagogical discussion of simple fit strategies.

Page 15 of 18

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.