Computed Deviation Overwriting bug for set1=at.Dataset(...);set2=at.Dataset(...); set1.compute(); set2.compute()

[Deleted user]

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

[aewallin]

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

[Deleted user]

Hello Anders, Happy to contribute a little as we are massive users of AllanTools :) Florian Le 11/12/2018 à 20:57, Anders Wallin a écrit :

…

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 <https://github.com/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** — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AmhmMqg1A8quIDNL6D91zwK2bOZjx_kfks5u4A4egaJpZM4ZN6zo>.

[fmeynadier]

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.

[aewallin]

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?

[aewallin]

closing. please reopen if this is still a problem!