Reduce memory consumption in CMAwM

[y0z]

Background

This change was motivated by optuna/optuna#5762, which reported that using CmaEsSampler with margin could significantly increase the Optuna journal file size. In the reported example, ten parameters over [-30, 30] with a step size of 0.001 produced a journal file of about 40 MB after only 12 trials.

The dense discrete-value tables stored in CMAwM contribute to the size of the serialized optimizer state. This PR replaces them with a compact arithmetic representation.

Summary

• Replace dense discrete-value tables with arithmetic representations using lower bounds, step sizes, and choice counts.
• Preserve the existing discretization behavior, including midpoint handling.
• Significantly reduce initialization memory usage and serialized object size.

Results

For 10 dimensions over [-30, 30] with a step size of 0.001 (60,001 discrete values per dimension):

• Discrete representation: 9.16 MiB → 240 B (>99.99% reduction)
• Pickle size: 9.16 MiB → 4.43 KiB (>99.9% reduction)

The new implementation was verified against the previous dense implementation, and all tests pass.

Verification

I compared the new arithmetic representation against the previous dense implementation using a standalone verification and benchmark script: https://gist.github.com/y0z/2a65eb996dccd7f220f1986c250c819a.

  python cmawm_memory.py

The implementations produced equivalent sampling and update results.

[y0z]

The CI run fails for "run python examples/safecma.py", but this is not related to the changes in this PR.
https://github.com/CyberAgentAILab/cmaes/actions/runs/30532727113/job/90838611058?pr=223

[ha-mano]

@y0z
Thank you for your contribution and for providing the detailed explanation.
I will review the changes and follow up shortly.

[ha-mano]

@y0z (cc: @c-bata )
I reviewed and tested this change primarily from the perspective of reproducing the results presented in the CMA-ES with Margin paper.
(Separately, the unrelated CI issues concerning the Ruff configuration and examples/safecma.py have been addressed in #224 and #225.)

Compared with the previous dense implementation, I confirmed that there is no material change in the essential algorithmic behavior, including the trajectory of the distribution parameters under typical float64 inputs. Therefore, I plan to merge this PR as is.

As a minor compatibility note, when bounds and steps are provided as float32, the previous implementation stored the materialized discrete candidate values in a float64 array, whereas the new arithmetic representation retains some values as float32. Consequently, rounding may differ and the optimization trajectory may not strictly match the previous implementation in some cases.

Since the expected use of float32 inputs seems limited, I do not consider this issue significant enough to require changes. However, before merging, could you please confirm whether preserving the previous behavior for float32 inputs is necessary? If not, I plan to merge the PR as is.

[y0z]

Thank you for your response.
I don't have a strong opinion on this minor behavior, so feel free to merge it as-is.

[ha-mano]

Thank you for confirming. I will proceed with merging this PR as is.