Computed Deviation Overwriting bug for set1=at.Dataset(...);set2=at.Dataset(...); set1.compute(); set2.compute()
Closed this issue · 5 comments
Hi,
we stumbled upon what seems to be an overwriting bug:
when creating 2 differents datasets with = at.Dataset(...), and then calling the computing jobs on the 2 datasets with .compute('tdev', ... ), the 2nd computed deviation job overwrites the 1st computed deviation job ie we end up with exactly the same deviation values.
However when doing dataset1= at.Dataset(...) ; dataset1.compute() and then dataset2= at.Dataset(...) ; dataset2.compute()
the computed deviation jobs & values don't get overwriten each other.
This behaviors could be reproduced with: AllanTools 2018.03, Python3, Ubuntu 64 bits, and AllanTools 2018.11, Python3, Windows 7 64 bits
Greetings from LNE-Syrte, Paris
Florian, Mikkel
Thanks for finding and reporting this!
A minimal example (I think) is something like:
` import allantools as at
x1 = at.noise.white(num_points=1024)
x2 = at.noise.pink(N=1024)
produces wrong results:
ds1 = at.Dataset(x1)
ds2 = at.Dataset(x2)
r1 = ds1.compute('oadev')
r2 = ds2.compute('oadev')
print "r1",r1['stat'][0]
print "r1",r2['stat'][0]
produces correct results:
ds1 = at.Dataset(x1)
r1 = ds1.compute('oadev')
ds2 = at.Dataset(x2)
r2 = ds2.compute('oadev')
print "r1",r1['stat'][0]
print "r2",r2['stat'][0]
`
As far as I can tell this is because the inp and out variables are defined after class, but before init over here:
https://github.com/aewallin/allantools/blob/master/allantools/dataset.py#L52
That will make them "static", i.e. they belong to the class, not an individual object/instance of the class.
@fmeynadier Ping! is there any design-idea here or is it just a mistake? Ofcourse you might save memory if you don't store big time-series in each Dataset, but static data leads to this surprising/unwanted behaviour...
To make the variables belong to the instance/object they need to be defined as self.foo, under init
Hi everyone,
Definitely a blunder from my side, sorry ! Thanks for pointing it out.
I filed a pull request that corrects this behavior, and added the example provided by Anders as an additional test.
433298a should fix this.
will close this issue if nobody reports more problems within a week or two.
a new release on PyPi might be a good idea - early January 2019?
closing. please reopen if this is still a problem!