Could you also update the source in https://pkgd.racket-lang.org/pkgn/package/sudoku-solver to a newer version? Right now it’s pinned at v0.15.1, so the bug is still there.

Thanks for the reminder. Done. :slightly_smiling_face:

I had thought I had already done this, but after applying your patch, I had to clean up some CI build issues (unrelated to your patch) and forgot to push the new tag and change it on the package server.

Fortunately, the bug was only in the tests. Just to be sure: Did you get any failed tests or even exceptions before the patch? Both here locally and on the package server, the tests passed (even though due to the bug the wrong tests might not have had the intended effect).

You can use for with in-vector. The documentation of in-vector says An in-vector application can provide better performance for vector iteration when it appears directly in a for clause.

I used a (relatively short) vector instead of a set in another program where the set was also part of the bottleneck. If I remember correctly, I got an additional speedup by using an unsafe vector and unsafe operations (but of course, that’s kinda … unsafe :wink: ). If you use the unsafe variants, you should measure how much the difference is.

You can also use <https://docs.racket-lang.org/foreign/homogeneous-vectors.html|more compact vectors>, but I’m not sure if these work with the unsafe ref and set! operations.

This works: #lang racket/base (require ffi/vector racket/unsafe/ops) (define a-vector (make-u16vector 5 0)) (for ([i 5]) (u16vector-set! a-vector i i)) (for ([i 5]) (displayln (u16vector-ref a-vector i))) but not with the unsafe operations. You’d need to check whether a regular vector plus unsafe operations or fixed-data (FFI) vectors with their specific safe operations are faster.

So if nothing failed or raised an exception, the effect of the bug was only less test coverage than expected, I think.

Matthew Butterick has an, I think, interesting article: https://beautifulracket.com/appendix/why-racket-why-lisp.html

I don’t think vector-for-each is even provided in Racket. It’s defined at the Chez Scheme level but not exposed to Racket.

One can use vm-primitive to require it, however, but from a quick test it appears to be slower than for + in-vector.

meet-up in 5 minutes https://gather.town/app/wH1EDG3McffLjrs0/racket-users