aehmlo/ku

A sudoku crate.

ku's Issues

Re-enable higher orders

03fdeda changed the backing storage of PossibilitySet to use a u64 and bitwise operations. This limits users to a maximum order of 8 (the square root of 64). The backing store can be changed to a u128 to allow a maximum order of 11, but this isn't much better (and, unless done very carefully, can result in some pretty major performance regressions). u256 would only allow a maximum order of 16 (O(n²) is somewhat unwieldy).

Ideally, I'd like to use u64 as a backing until u128 becomes necessary and then downgrade to heap allocation (probably just a Vec) thereafter to enable arbitrary orders at the cost of performance. I think the only realistic way to implement this right now is probably something like typenum.

Fix CI configuration

This may require some finagling with rustfmt, or simply allowing nightly to fail if it won’t be tamed.

Generate Sudoku::groups tests for dimensionality and all axes

I'd like to use a procedural macro to do this, but hygiene seems to get in my way every time I try.

Give PossibilityMap value knowledge

As it stands, the possibility map has no idea whether there's no freedom because an element exists there or because the position is over-constrained. Giving it this knowledge would let us short-circuit on otherwise expensive recursion. This may also be related to the hang encountered in gen::grid.

Revisit lifetimes

There's at least one location (it's marked) which should be revisited when NLL lands, but a review of all lifetime/reference-related code might not be a bad idea.

Implement solving

Investigate mutable vs. immutable performance

Make fmt::Display CSS-compatible where C: Color

This will enable things like ctx.set_fill_style_color(format!("{}", c)).

Add more test cases for Sudoku::into::<PossibilityMap>

Allow user to choose dimensionality

Ensure that relevant tests are not run extradimensionally (as this will undoubtedly result in incorrect outcomes).

Improve color accuracy

There's a lot of rounding going on in ui/color.rs current; I'd like to avoid this.

Implement puzzle scoring

Implement at least basic scoring functionality, based on the naïve solving mechanism.

Investigate Cow for performance

If the lifetime annotations become excessive, it’s okay to give up.

Improve FromStr robustness

Strip whitespace (including newlines), allow borders, whatever.

Improve generation efficiency

Reduce the amount of backtracking required by generating more components "statically."

Prettify noscript

It exists now, but it's not very pretty. This can be easily fixed, but I don't really want to do it right now.

Implement puzzle generation

Make color palettes shared

Move color palettes and color manipulation into shared code, and give it a prettier structure. Since this is getting into the area of metadata, it may be a good idea to use serde to let us specify these things as JSON/TOML so that it's parseable by other things.

Implement (de)serialization

It is most definitely overkill to use serde for this, as we only need to support unsigned integer types. This will probably consist of FromStr and fmt::Display only.

Implement positive tests for Sudoku::groups

Ensure that the portions returned are as they should be.

Add hexadecimal puzzle support

This allows us to use single-character representations for everything in a puzzle of order 4.

In order for this to be considered complete, we need:

• impl fmt::UpperHex for Sudoku
• Improvements to FromStr (#15)

Implement (de)serialization in higher dimensions

As of now, FromStr is limited to two dimensions, since I haven't thought of a good 2D representation for a higher-order puzzle. I'd be happy with just adding 3D, without being concerned about higher dimensions than that.

Once a format's specced out, FromStr and fmt::Display should be implemented as inverse functions (composable).