Here's an idea that's been in the back of my mind for a long time, after using the Generator for a while.
Would it be possible to also include the number of fingerings for a problem set (besides the actual answer). For example 8+2 requires 5 fingerings (even if setting 5/3 as one movement, it would be counted as 2 fingerings).
That's because I have noticed that, due to the "luck of the draw", some problems sets require more time that others, because they happen to require a lot more fingerings (e.g. if a lot of numbers had zeroes in them, the number of fingerings was a lot less).
As an alternative, the random generation of the problem sets could be improved to guarantee that different problem sets require about the same amount of fingerings.
I recall reading that problem sets generated by humans were carefully crafted to ensure that all number combinations appeared about the same number of times (i.e. a "balanced mix"), rather than being purely random, as a computer program would naively do. This also would imply about the same number of fingerings between problem sets.
yes. that's a good idea. But that needs work. Almost a complete rewrite of the way that numbers are generated.
Even if I wouldn't necessarly go to as far as to count the number of fingering, having some heuristics so that numbers are not totally random would be good to avoid "bad" draw.
What I have understood, is that each kyu level is more based on the number of digit in each problem operation) than fingering. but why not as an option, someday...
Hi.
So if you are still around, after 8 years, I finally implemented this. Meaning, the fingering count is displayed per demand, for each set. The number generator has not been modified.
The fingering count is displayed, if you request it, inside brackets [] after the index of the solution, either after each operation, or at the end.
This is based on an algorithm that count the changed on the soroban beetween each step of an operation. This should match the fingering count for the japanese fingering.
For operation with decimals, the count is not accurate because it does take into account the number of decimal needed for the answer.
And you can expect bugs. I hope the least possible.
Cheers.