Look into getting uint128/uint256 for counter and iter #21

Closed
opened 2025-01-27 14:54:51 +01:00 by sacha · 1 comment
Owner

Currently both are of type int64 and can go up to
9223372036854775808

Which is less than the maximum amount of possible solutions:
6670903752021072936960

Even making it uint64 isn't much better:
18446744073709551616

The next step would be uint128 going up to:
340282366920938463463374607431768211456

But this would not cover an all 0 use-case in which we need to check all possible solutions:
362880 * 362880 * 362880 * 362880 * 362880 * 362880 *362880 * 362880 * 362880
109110688415571316480344899355894085582848000000000

So the next best step would be:
115792089237316195423570985008687907853269984665640564039457584007913129639936

Now to find a package that supports this. :-)

Currently both are of type int64 and can go up to `9223372036854775808` Which is less than the maximum amount of possible solutions: `6670903752021072936960` Even making it uint64 isn't much better: `18446744073709551616` The next step would be uint128 going up to: `340282366920938463463374607431768211456` But this would not cover an all 0 use-case in which we need to check all possible solutions: `362880 * 362880 * 362880 * 362880 * 362880 * 362880 *362880 * 362880 * 362880` `109110688415571316480344899355894085582848000000000` So the next best step would be: `115792089237316195423570985008687907853269984665640564039457584007913129639936` Now to find a package that supports this. :-)
sacha added the
Low Priority
label 2025-01-27 20:38:43 +01:00
Author
Owner

This isn't going to work with the atomic.int64. Could retool is to use uint64

This isn't going to work with the atomic.int64. Could retool is to use uint64
sacha closed this issue 2025-01-28 02:30:28 +01:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: golang/sudoku-funpark#21
No description provided.