Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expected outcome effects dictionary #260

Open
jmafoster1 opened this issue Feb 7, 2024 · 2 comments
Open

Expected outcome effects dictionary #260

jmafoster1 opened this issue Feb 7, 2024 · 2 comments

Comments

@jmafoster1
Copy link
Contributor

When we set up a driver for the JSON front end, we have something like the following:

        expected_outcome_effects = {
            "Positive": Positive(),
            "Negative": Negative(),
            "NoEffect": NoEffect(),
            "SomeEffect": SomeEffect()
            }

This works great for this kind of effects, but when I want to test for exact values, I have:

        expected_outcome_effects = {
            "Positive": Positive(),
            "Negative": Negative(),
            "NoEffect": NoEffect(),
            "SomeEffect": SomeEffect(),
            "1.0": ExactValue(1.0),
            "0.8": ExactValue(0.8),
            "0.7": ExactValue(0.7),
            "0.65": ExactValue(0.65),
            "0.6": ExactValue(0.6),
            "0.5": ExactValue(0.5),
            "-0.01": ExactValue(-0.01),
        }

This is expanding as I need to add more literal values. Could we perhaps use a function instead, so I could have something like

def expanded_outcome_effects(effect):
  if effect == "Positive":
    return Positive()
  elif effect == "Negative":
    return Negative():
  else:
    return ExactValue(float(effect))

or would that be bad?

@christopher-wild
Copy link
Contributor

christopher-wild commented Jul 10, 2024

Sorry for only just looking at this, going through all the old issues now.

I definitely agree that having to specify each ExactValue isn't ideal. The main downside of the function approach above is that any numeric effect will be assumed to be an ExactValue. Are there ever situations where you may have another numeric based effect?

If not we can refactor to this approach, it would be a breaking change for the frontend though

@jmafoster1
Copy link
Contributor Author

I'm not sure. At the moment, I think the only supported numerics are exact values. The other possibility, which I've just thought of, is to specify, in the tests.json file, the name of the effect class (Positive, Negative, etc.) and have an additional field for the arguments with which to initialise the class. I think that would be better, and might not necessarily need to be a breaking change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants