Wordle Solver

[snapenilk]

Additional challenge: make a solver for a Wordle variant (Fibble, Xordle, Symble, Caesardle, Crissle Crossle, etc.)

[origamicircuits]

I will look into Xordle and Alphalock

[origamicircuits]

7.0 OUT NOW!!!

It has been a long time since I last worked on this project. But with the new Snap! updates coming out, I put it down for a time. Picking it back up, I have used some scummy methods to make it not only faster, but also smarter while being faster!

Wordle solver 7.0 now not only uses what you tell it about the words, but it uses statistical data to help it find the word!

Link to Project

What do I mean by “Scummy““?

If you are familiar with using loops, that can take a long time to calculate. But using blocks like

you can actually processes entire lists all at once.

Compare

to

What statistical data?

Well letters like a,s, and c are a lot more common than letters like q,z, and x. The algorithm now takes this into account. But it is not hard coded to just those letters, but rather to what ever the final word could be.

[joecooldoo]

@origamicircuits

If you are familiar with using loops, that can take a long time to calculate. But using blocks like

you can actually processes entire lists all at once.

looks like you’ve discovered hyperblocks!

How are hyperblocks so fast? (with inside views from @jens and @bh)

Runtime performance often isn’t that important, especially not for an education-oriented language. Besides, no code written in an interpreted language on top of Javascript is going to be faster than (equally well-written) code in Javascript itself, I suppose. Still, when I “moved” from Scratch to Snap! in 2022 - mainly because Snap! supports recursion, and lists are variables - I was somewhat disappointed at first by its laggish execution; I found a 1:1 translation of a Scratch program to Snap! …

@jens

Hyperblocks are fast because of the halting problem.

Let me explain:

I’m slowing down Snap! execution - even drastically so - in various ways to

1. support parallel animations (Snap’s microworld is 2D cartoons) across a wide variety of hardware platforms with wildly differing performance specs, so I’m shooting for the least performant, slowest options, and to
2. let learners follow along and mentally trace what’s happening in their programs, so they can interact and intervene, e.g. in the case of infinite recursion, which otherwise would crash their environment (as it does in almost every other programming language).

@jens

Hyperblocks are really nothing but a special case for abstracting away “map” for a finite catalog of concrete operations. In the “real” map you can put literally anything into the arg ring, including an infinitely recursive (buggy!) expression. That’s why I need to make it so you can press the red stop button or click on the running script to halt it. Otherwise your system would crash and if you didn’t save before running it you’d loose your work, become frustrated with programming and decide to study business administration and produce bullshitz on LinkedIn for a living :). In the case of hyperblocks, however, I know the exact “funarg” you’re mapping over data, so I can be (reasonably) confident, that this operation - given non-circular data - will actually terminate and not go on forever. I know this not because I’ve solved the “halting problem”, but because I wrote the thing that goes into the imaginary map-ring (e.g. the plus / times / join reporter), not you. Therefore, for these special cases of known and supported reporters I can simply compute the result directly, without having to support parallelism, closures and scopes. That’s why you get what appears to be miraculous performance with hyperblocks.

[origamicircuits]

See, I thought it would have something to do with the fact the ring has go through the interpreter so many more times. I guess that is still a bit true.

In the time I put snap down a learned a bit of JavaScript and HTML. The language it self is definitely much faster. Again why I thought it was the interpreter.