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

Behaviour of Gambit number objects in Python #3

Open
tturocy opened this issue Jun 14, 2011 · 1 comment
Open

Behaviour of Gambit number objects in Python #3

tturocy opened this issue Jun 14, 2011 · 1 comment
Assignees

Comments

@tturocy
Copy link
Owner

tturocy commented Jun 14, 2011

Gambit implements a Number object, which tracks the original representation of a number used to express a payoff or probability. In particular, Numbers should either be decimals or rationals.

This should be transparent to the user.

Initial suggestions for discussion:

  • Be sure to harmonize fully with the Python "numeric tower"
  • The Gambit Number object should be kept entirely internal. All objects returned when, e.g., retrieving payoffs should be decimal.Decimal or fractions.Fraction, as appropriate. Which to return should be controlled by whether there is a decimal point in the stored text representation.
  • Should accept integers when setting payoffs.
  • Probably we should not accept floating point numbers, as the semantics of these are tricky. The Python decimal.Decimal and fractions.Fraction objects do not accept floats, because of problems with numbers like 0.1. This looks like a good decision and Gambit should follow suit.
@ghost ghost assigned tturocy Jun 23, 2011
@tturocy
Copy link
Owner Author

tturocy commented Jun 23, 2011

Commit c8cd42d, recently pushed up to the gambit_python branch, implements this idea for getting and setting outcome payoffs.

The decision was made to accept only int, decimal.Decimal, or fractions.Fraction to set payoffs. Users must explicitly convert a floating point number to, e.g., a decimal.Decimal, to pass it: "explicit is better than implicit"

As expected, this significantly simplifies the Cython wrapper.

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

1 participant