I do not understand why this is needed? gnm_solve returns a MixedStrategyProfileDouble which already expresses everything as float.

When I run the tutorial myself it works fine.

I do not understand why this is needed? gnm_solve returns a MixedStrategyProfileDouble which already expresses everything as float.

When I run the tutorial myself it works fine.

Same here actually which is why this didn't come up before, I wonder if this is also related to python version somehow? @d-kad which python version are you running locally?

I wouldn't think this would have to do with Python version. Those numbers are always going to be float. My feeling is it is more possible that it is some kind of out-of-order execution that is causing that variable not to be the result of gnm_solve?

But also I don't think the solution is the right one anyway. If in fact we have a situation where the data are rational we should print them as rational, not cast them to float. The whole point in computing with rationals is for precision! So if we did have such a situation the remedy I'd recommend is not to use the float-format specifier in the f-string. Rationals do have a __str__ and a __repr__ that should do the right thing in a f-string.

I do not understand why this is needed? gnm_solve returns a MixedStrategyProfileDouble which already expresses everything as float.
When I run the tutorial myself it works fine.

Same here actually which is why this didn't come up before, I wonder if this is also related to python version somehow? @d-kad which python version are you running locally?

Python 3.9.6

It could be to do with 3.9 - on 3.11 or 3.13 the f string is able to handle both float and rational without any conversion required:

I will check if I can replicate the error with 3.9, if so then I think we can reject this change, see Ted's issue opened today #635 - in the meantime @d-kad if you create a new venv with a more recent python version you shouldn't have any issues :)

The thing is gnm_eqm ought to be a double-precision profile no matter what, so I'm not seeing why it would be generating a rational here.

But also @d-kad see #635 - 3.9 is now EOL and we won't be supporting it for this release, time to upgrade! :)

The thing is gnm_eqm ought to be a double-precision profile no matter what, so I'm not seeing why it would be generating a rational here.

But also @d-kad see #635 - 3.9 is now EOL and we won't be supporting it for this release, time to upgrade! :)

It's the LCP eqm that is a rational here - see the types in my screenshot above

Ahh, right, I was fixated on the change to the GNM output, which definitely ought not to be necessary.

But yes, if for some reason we need to make a change, I would do it by removing the :.4f specifier on the LCP profile and showing it as rational rather than casting it.

The distinction between exact and floating-point/approximate methods is an important one to get across to users, so I'm suggesting we try to set good examples by avoiding casting from rational to float ourselves.

I will check if I can replicate the error with 3.9, if so then I think we can reject this change, see Ted's issue opened today #635 - in the meantime @d-kad if you create a new venv with a more recent python version you shouldn't have any issues :)

Ahh, right, I was fixated on the change to the GNM output, which definitely ought not to be necessary.

But yes, if for some reason we need to make a change, I would do it by removing the :.4f specifier on the LCP profile and showing it as rational rather than casting it.

The distinction between exact and floating-point/approximate methods is an important one to get across to users, so I'm suggesting we try to set good examples by avoiding casting from rational to float ourselves.

Sounds good, will push it shortly!

It could be to do with 3.9 - on 3.11 or 3.13 the f string is able to handle both float and rational without any conversion required

@edwardchalstrey1:

As I mentioned test_tutorials errored for me on 3.11. I just created a new venv and got the same error again :

platform darwin -- Python 3.11.14, pytest-9.0.0, pluggy-1.6.0

E                 6     print(
E           ----> 7         f"At information set {action.infoset.number}, "
E                 8         f"when playing {action.label} - "
E                 9         f"gnm: {gnm_eqm.as_behavior().action_value(action):.4f}"
E                10         f", lcp: {eqm.action_value(action):.4f}"
E                11     )
E                12 print()
E
E           TypeError: unsupported format string passed to Rational.__format__

It works for me on 3.12:

platform darwin -- Python 3.12.9, pytest-8.3.5, pluggy-1.5.0

Ok thanks all, as I mentioned for now the code runs on 3.13+ (looks like 3.12 as well as per Rahul's experiment), I'll open a better fix later - see #639