Is it possible to save the solver results?

[CharlieYu1]

I just ran a sim, while I can export to CSV, it is only for the particular spot and doesn't include future actions. Can I save the whole sim so I can load it later without solving it again?

[b-inary]

Duplicate of #2.
The saving feature is planned but not yet implemented. I expect it will take about two more months. This feature requires future compatibility, so careful implementation is needed.
To prevent another duplication, please keep this issue open until it is implemented. I would appreciate your patience.

[Thomas-MMJ]

This feature requires future compatibility, so careful implementation is needed.

I wouldn't worry about future compatibility, writing a script that converts from a old to updated format would be fairly straightforward.

[mtastafford]

Just chiming in here to express some enthusiasm in your project, as well as this specific issue.

[addy0099]

The only thing this needs is the ability to save, or just atleast reload an already ran SIM. Otherwise this is just perfect. Kudos to the developer. Can't thank you enough,

Please let us know when the save option is to be expected.

[b-inary]

I am really sorry that development has been delayed. I have been very busy lately and have not been able to spend much time on this hobby project.

Just saving and loading results is not that difficult, but I think I also need to implement a just-in-time solving feature while traversing with the result viewer. This feature is needed for loading reduced tree data, i.e., the data without post-turn or post-river node information. Paid solvers such as PioSOLVER and GTO+ also use this technique.

Saving data without this reduction, i.e., saving a full tree, requires several gigabytes of disk space per single tree, so implementing such a feature is pretty straightforward, but I don't think it is sufficient.

I would like to try to implement these features as soon as I find the time, but I cannot guarantee a specific date. I apologize for this, but I appreciate your patience.

[addy0099]

I Understand, and as i said, already appreciate what you have done already a lot! .
Please take your time, It's a killer software otherwise

[addy0099]

It will be fine if it just saves everything in CSV formats and quickly reads and reloads solved data till the flop and from thereon we can solve the turn and river, This will be a good way for us to save RAM as well. Not a software guy , But Just something that occurred to me.

Or maybe even if there is a separate viewer for the whole solve just to be viewed in Java/Html or something, which is light and doesnt needs solving again! Something that can just read the exported data and visually plot it.

[bkushigian]

Hey @b-inary, thanks again for all the hard work you've put into this, and no worries whatsoever about taking time away from the project! This should be fun, and if it's not then you should definitely do other things!

I'm wondering if there is anything I can do in my spare time to help get this going. Do you have a rough design for what this would look like? I haven't thought about this a ton (and don't know the code base that well), but my first draft design would be to introduce the notion of a Stub, an unsolved node without any memory allocated.

I'm imagining that a stub will be something like a PostFlopNode either with a stub flag or some state like storage{1,2,3} set to an empty value (make these Options?). The tree navigation API should be able to detect when a requested node is a stub (or would be within a stub), and the caller of the navigation would be responsible for using the tree configuration to build out the subtree rooted at the stub and invoke something like solve_stub (would this be as simple as a call to solve_recursive??).

So yeah, TLDR:

1. Make PostFlopNodes stubbable (not sure where subtree data is located, would probably require global updates)
2. Make tree navigation API return a Result<Node, TreeNavError> or something to indicate that we tried to move into a stub (or a subtree of a stub). An error indicating a stub should actually have a ref/global index to the stub node
3. The caller can optionally rebuild/solve the tree rooted at the stub.

Let me know what you think. I might start poking around a bit, but I'm sure there are all sorts of annoying issues with this that I'll discover as I dive in.

[bkushigian]

hey @b-inary just wanted to follow up on this. Is there any way that others can be of help here?

[addy0099]

Hello @b-inary ,
Glad to hear that you shall be pursuing it commercially,
Does the latest release has ability to save? Cant find that option.

[PokerAibot]

你有其他联系方式吗？我是中国的人工poker智能公司。想和你交流。