What is the _cmp variable for?

[talumbau]

The variable _cmp is only involved in comparison expressions (i.e. where(_cmp == 1...). It appears that it is never assigned to except when it is created in puf.py, where it is set to all zeros. Does anyone have any insight here? I'd like to remove it if it is not actually useful for any comparisons.

[iliakur]

There was talk of making it boolean in #35.

[talumbau]

oh very helpful thanks. Is there any scenario in which we would run the code and _cmp would be something other than 0? It appears to always be 0.

[iliakur]

@feenberg, what do you think?

[feenberg]

The references to _puf and _cmp should probably be replaced with tests
based on the presence or absence of the particular variable that the test
is protecting. That is, if the PUF doesn't include E12345, then instead of

if _puf then c12345=1000; else c12345=e12345;

we should use something like:

if e12345 ne . then c12345 = e12345; else c12345 = 1000;

I am making those changes in the SAS code and they should be
made in the AEI code also.

Note that _cmp == 1-_puf in the SAS code.

dan

On Wed, 12 Nov 2014, T.J. Alumbaugh wrote:

The variable _cmp is only involved in comparison expressions (i.e.
where(_cmp == 1...). It appears that it is never assigned to except when it
is created in puf.py, where it is set to all zeros. Does anyone have any
insight here? I'd like to remove it if it is not actually useful for any
comparisons.

—
Reply to this email directly or view it on
GitHub.[AHvQVZRDp_xGeRnDkmXrYg-_4XMB_Z2Bks5nM3vPgaJpZM4C6LvH.gif]

[feenberg]

On Wed, 12 Nov 2014, T.J. Alumbaugh wrote:

oh very helpful thanks. Is there any scenario in which we would run the code
and _cmp would be something other than 0? It appears to always be 0.

When users take the code inside government, some of them will have the
complete file, however we shouldn't depend on _cmp to control program
flow.

Note that we will be testing the calculator on a file with all the
variables in the complete file, although the data will be random.

dan

—
Reply to this email directly or view it on
GitHub.[AHvQVUWswy5FHfBhuM5-KyrnIF3dee6Oks5nM35agaJpZM4C6LvH.gif]

[MattHJensen]

Closing in favor of #186.