You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
The text was updated successfully, but these errors were encountered: