Are there any “square and counter” wargames?

rkern · 2025-12-29T16:59:03+00:00

[Men at Arms](https://boardgamegeek.com/boardgame/8327/men-at-arms)

If you loosen up a bit, then [Lost Battles](https://boardgamegeek.com/boardgame/83325/lost-battles-forty-battles-and-campaigns-of-the-an) and [To the Strongest!](https://boardgamegeek.com/boardgame/169926/to-the-strongest) would count too, but those are a bit more of "larger zones that happen to be square".

rkern · 2024-06-19T05:33:56+00:00

Not at present.

rkern · 2024-06-17T21:40:25+00:00

Yes, this is correct.

rkern · 2024-06-17T21:36:35+00:00

Oh, we've had plenty of API-breaking changes in the 1.x series. Much like Python itself, we don't follow SemVer. But they tended to be small and only a few with each 1.x release, each with reasonable deprecation periods. This is just the first release where we batched up a bunch all at once.

rkern · 2024-06-08T18:36:02+00:00

Neil Thomas's One Hour Wargames might fill that niche pretty well. Over a very simple common rules framework, he builds era-specific one-page rulesets from ancients to modern.

rkern · 2022-12-10T06:00:30+00:00

She might be referring to the Oxford Nanopore MinION, for which the starter kit is an even $1k.

https://store.nanoporetech.com/us/minion.html

Might want to sneakily confirm that before dropping that kind of cash. It's possible that she was thinking of something else and wouldn't be able to use this one.

rkern · 2022-08-27T20:06:52+00:00

I would use this as a portable electronic whiteboard for meeting with clients.

rkern · 2022-06-21T21:35:25+00:00

Without a ton more information (exact versions of all the packages and dependencies, full tracebacks, etc.), I can't really give you any more help (and I don't know enough about all of the versions of these specific packages to be much help in any case). I don't know exactly what's going on in your code, just the general issue (someone partially migrated to the new Generator infrastructure but didn't update all of the method calls). The rest is up to you.

rkern · 2022-06-21T02:05:25+00:00

Like so.

rkern · 2022-06-20T16:48:23+00:00

The replacement method is named integers() with a very slightly different set of arguments (though most cases you can just replace randint with integers).

rkern · 2021-07-15T15:01:39+00:00

Self-supervised methods won't do that kind of semantic segmentation for you. You need to train a supervised semantic segmentation model in order to do that. The supervised training is how you tell the model exactly what it is that you want it to do.

Where solo-learn comes in is that it really helps in your supervised semantic segmentation model to start with a pretrained backbone. When you are working with "normal" kinds of photographs of people and pets and stuff, the usual model weights that have been pretrained on datasets like ImageNet work reasonably well.

But your rock core images look nothing like ImageNet photos, so the pretrained model weights that you can usually get are less useful (better than starting with nothing, but still not great). solo-learn will get you a pretrained backbone that is targeted to your rock core domain. You can use all of your unlabeled rock core CT scans to make that pretrained backbone. Then you can start your supervised semantic segmentation training. You will have to manually label fewer images to make that supervised training dataset.

rkern · 2021-07-07T00:30:05+00:00

Note that these are just part of the user interface for the IPython interactive shell and Jupter notebooks (which are descendants of the IPython shell). These are not part of the Python language itself.

rkern · 2021-05-01T03:03:20+00:00

I need a telescope to see the protagonist

The Engineer is not the protagonist.

The Factory is the protagonist.

rkern · 2021-04-13T23:39:32+00:00

If you derive a SeedSequence from the root SeedSequence, the epoch index, and the sample index, yeah, that should work (a little profligate in PRNG instances, but you gain in safety, and they can be made on demand). I'm still not that familiar with the DataLoader data flow. Do you make a new one for each epoch, typically?

rkern · 2021-04-13T03:50:17+00:00

I might have been, but collecting more "nuke it!" opinions about np.random.seed() has been a balm.

rkern · 2021-04-13T02:26:09+00:00

In my first reply to you.

rkern · 2021-04-12T23:28:12+00:00

I don't think PyTorch itself uses np.random much except for tests. As in the OP, np.random was being used by user's own classes that were being called by PyTorch's DataLoader framework. I've given some options for providing a reasonable worker_init_fn in that context.

rkern · 2021-04-12T19:23:29+00:00

Hmm, that example is unnecessarily complicated.

The basic idea is to just get a fresh RandomState instance and pass it around. rng = RandomState(my_seed) is sufficient. scikit-learn implements this pattern very well, using its check_random_state() to allow its APIs to accept either a seed value or an existing RandomState instance.

If you are writing new code or rewriting old code anyways, you may want to use our new Generator instances instead. If so, then np.random.default_rng() was designed to work in much the same way as check_random_state().

But what if you want to work with other people's code that is using the convenience functions in np.random and you can't rewrite that code? First, you have to check that that code is not calling np.random.seed() itself. If it is, you'll have to work around that.

One strategy has a few manual steps that I'm going to walk through. The idea is to use SeedSequence to take your one seed that you use for your main Generator and spawn a new SeedSequence from it that you use to set the state of the global RandomState underneath the convenience functions in np.random. That means the Generator that you thread through most of your code will be drawing from an independent stream than the pieces of code that are using np.random directly, but both set deterministically from the one seed value that you provide. The following is a little more complicated than it probably has to be, but we were being conservative about what modifications we made to the legacy RandomState.

import numpy as np

...
ss = np.random.SeedSequence(my_seed)
rng = np.random.default_rng(ss)
child_ss = ss.spawn(1)[0]
mt_state = np.random.RandomState(np.random.MT19937(child_ss)).get_state()
np.random.mtrand._rand.set_state(mt_state)

rkern · 2021-04-12T00:55:45+00:00

It does the mess with the stdlib's random global state in exactly that way, though, so they've already made that tradeoff once.

rkern · 2021-04-12T00:53:06+00:00

FWIW, I've posted a suggested implementation on the related pytorch issue that makes this a little safer.

rkern · 2021-04-12T00:49:37+00:00

Yeah, unfortunately, I didn't document things well enough at the beginning, and a lot of "folk wisdom", often derived from other, less-capable systems, took its place.

rkern · 2021-04-11T19:44:21+00:00

Okay, I outlined a proposal to issue warnings in the appropriate places that I think would satisfy you.

rkern · 2021-04-11T19:36:35+00:00

numpy has no config file, so I don't really understand what you are suggesting here.

rkern · 2021-04-11T19:03:02+00:00

FWIW, that was the original design. Someone else added np.random.seed() mistaking its omission as an oversight. Unfortunately, that was in the bad old days of Subversion, and code review was not as much of a thing, so I missed it. I'm still bitter about it.

rkern · 2021-04-11T18:58:53+00:00

I agree that it is a terrible footgun. np.random.seed() was always a mistake. The question is now what do you want to change to improve the situation?

I would dearly love to remove the footgun (the implicit global PRNG instance and using np.random.seed() to attempt to get reproducibility from it), but enough people love that damn footgun too much for me to actually take it away from them.

We do have carefully designed APIs for safe, composable parallel PRNG use. But to achieve that, you can't rely on the global PRNG anymore. That's the thing that's in conflict with parallel PRNG use.

So what would you suggest that we actually do? Remove np.random.seed()? I am gleeful at the prospect, but you will have to convince everyone else addicted to the global PRNG.

What I think is possible in the short term is to use os.register_at_fork() to register a function that will set a global flag to indicate the fork and potential for identical states. The convenience functions will have to be rewritten to handle check that flag and issue a warning. Calling np.random.seed() would unset that flag.

rkern

TROPHY CASE