wirelyre / tetra-tools Goto Github PK

Proposed groupings:

1. Pieces used (e.g. IISTZ, unordered shapes of pieces composing the solution)
   • Simple analysis on each solution. Every solution belongs to exactly one group.
2. Piece saved (piece in hold after final placement, or in queue if nothing held)
   • Requires additional information from the solver. Some solutions belong to multiple groups.

The two groupings are likely to be very similar for queries where a grouping is useful.

Sort of depends on #5.

This is all throughout the crate, but especially solution-info and its deserializer. Passing other data is very inconvenient.

JSON should be used for all Rust–JS data marshalling.

Perhaps srs-4l should use Serde for real and implement Serialize and Deserialize on its several relevant types. Many of them will turn into strings.

Whenever you have a full solid row in the initial field, it drops down to the bottom of the field in each of the possible solves. The pieces within the possible solves don't shift up after the full solid row is moved to the bottom, so said pieces get partially covered. In some cases, depending on where the solid row in the initial field is, a gap is formed in the middle of pieces.

Some examples:

How they "should" look (if we were to assume that the solid row dropping to the bottom is intentional):

fumen codes with special characters do not load properly through direct link
example: v115@9gF8DeF8CeG8BeH8CeA8JeAgWEAa+VWC

the fumen link is able to load the fumen from its url code but the pc solver link is not

this is because special characters in the fumen code are raw and get parsed differently than intended

Currently implemented as SRS with six 180º kicks. But TETRIO uses SRS+, a variant that changes I quarter kicks.

All pieces other than I match the current implementation. The correct full kick table for I under TETRIO:

{
    "ne": [[ 2, -2], [ 3, -2], [ 0, -2], [ 0, -3], [ 3,  0]],
    "es": [[-2,  1], [-3,  1], [ 0,  1], [-3,  3], [ 0,  0]],
    "sw": [[ 1, -1], [ 3, -1], [ 0, -1], [ 3,  0], [ 0, -3]],
    "wn": [[-1,  2], [ 0,  2], [-3,  2], [ 0,  0], [-3,  3]],

    "ns": [[ 0, -1], [ 0,  0], [ 1,  0], [-1,  0], [ 1, -1], [-1, -1]],
    "sn": [[ 0,  1], [ 0,  0], [-1,  0], [ 1,  0], [-1,  1], [ 1,  1]],
    "ew": [[-1,  0], [ 0,  0], [ 0,  2], [ 0,  1], [-1,  2], [-1,  1]],
    "we": [[ 1,  0], [ 0,  0], [ 0,  2], [ 0,  1], [ 1,  2], [ 1,  1]]

    "nw": [[ 1, -2], [ 0, -2], [ 3, -2], [ 3, -3], [ 0,  0]],
    "en": [[-2,  2], [-3,  2], [ 0,  2], [-3,  0], [ 0,  3]],
    "se": [[ 2, -1], [ 0, -1], [ 3, -1], [ 0,  0], [ 3, -3]],
    "ws": [[-1,  1], [ 0,  1], [-3,  1], [ 0,  3], [-3,  0]],
}

It's not possible to just paste these in, because these reversed rotations don't have inverted offsets.

Options:

1. KickTable<const QUARTER: usize, const HALF: usize>, full kick tables for each physics–shape pair
2. (&[Kick], &[Kick], &[Kick]), each component selected at runtime and runtime-sized
3. Special case for I in placement machine

I have low hopes for (2) because I suspect the compiler unrolls the kick loops and it's fast. (3) seems ugly. On the other hand, (1) would clean up some existing code too!

The downsides of (1) are more static data and monomorphized code. The latter can be reduced if necessary by duplicating final kicks.

legal-boards will also need to handle Jstris 180 and TETRIO separately, because some Jstris placements will be illegal in TETRIO and vice versa.

This project should have a Python interface.

Right now, everyone's fumen/stacker/search code is strewn around and not easily compatible. This could be fixed with a nice Python interface, so that simple scripts can call into high-performance solvers. Ideally, research would be easily reproducible with a single script.

Current formats and tools

• fumen — de facto standard for sharing fields and solutions
• knewjade/solution-finder, a.k.a. sfinder — huge toolbox for searches
• wirelyre/tetra-tools web solver — the 4-line solver in this repo!
• Hsterts/Fumenities — small collection of tools to manipulate fumens
• MinusKelvin/pcf — 4-line solver running a subset (maybe?) of SRS

Missing pieces

• Representation for solutions (fumens only use colored cells, which loses information)
• Serialized form for huge data sets (solution sets and placement graphs)
• Resumable and cached searches
• Fast approximate and exact cover searches

There are plenty of values which can be Python objects at no practical cost. Basically, the inputs and outputs of searches. Performance only really matters during a search.

Roadmap

• Interface to 4-line solver
  • Field representation
  • Solution representation
• Queue tools
  • e.g. holding / unholding, parsing sfinder patterns
• fumen interface
  • Representation and parser
  • Utilities
• Flexible-size Rust solver
  • Vectorized placements using multiple 6-line u64 chunks
  • Impossible field detection
  • Heuristics for bad fields
  • Cached solutions
• GPU implementation?
• Cover finder
  • Exact (resumable)
  • Approximate
• sfinder interface
  • Solver
  • Setup