Add Symmetry Area as variant of Fillomino.

[tausbn]

WIP. Still needs tests to verify that everything works as expected, though my manual testing seems to indicate that this is the case.

Tests added. I think this is ready for review now.

[robx]

The change looks fine.

I'm a bit curious about the type: Do you have some reference for it? E.g. is this what it's called in Nikoli? Are people making these?

At first glance it seems like not the most obvious fillomino variant to add, and I don't really want to add tons of fillomino variants over time.

[robx]

I think they're called "blocks" here. If we were to change that, I think I'd prefer "area". "room" sounds like something given for me.

So the small change would be: bkNotSymm ... "The block is not..."

[tausbn]

Fair enough. I didn't see any consistency there already (cf. line 424), so I wasn't sure what word to use. Using "block" is fine by me.

[robx]

the 1 seems inaccurate, or does kanpen support this type?

[tausbn]

Ah, this is what happens when I blindly copy-paste what's written for Fillomino, and forget to check what the values mean. I doubt this is supported by kanpen.

[tausbn]

It appears in Toketa vol. 2, pages 60-64, which in turn points to http://puzzle-kai.blogspot.com/2013/03/jzdc2013.html in its description.

I don't know that anyone is actively making these puzzles, but I think it's an enjoyable genre, and I'm hoping people will pick it up. (And that it doesn't suffer the same fate as, say, Araf, which sadly has not seen very much activity. 😢)

I'm curious: what Fillomino variants would you prefer to see added? Checkerboard fillomino? Snake Pit?

Also, I would like to understand the argument against adding "somewhat" obscure variants like this one. Of course, I wouldn't want to add every strange ruleset out there, and I would probably also draw the line at types that have only a handful of puzzles written for them (e.g. some of Inaba's inventions). (Actually, thinking of this now, that would probably disqualify New NEWS. I may decide to remove that from my other PR.)

I can see one big argument: it bloats the codebase, which is especially problematic if, say, a major rewrite was needed (and I am inclined to agree that this is the case).
I am happy to not have this merged for the time being (especially if #178 is being seriously considered). I mostly did it as a way of getting familiar with the codebase. 🙂

[robx]

Bunch of random thoughts, the question of which types and which variants to include is a pretty vague one.

There's certainly no hard line anywhere and somebody caring enough to implement a type is already a pretty strong argument in favour of merging it. It's also an entirely possible course of action to merge this and then say no to / discourage similar additions in the future.

One extra downside besides what you mention above is that every extra type and variant makes the list of puzzle types more overwhelming. That is, say as an author you look through puzz.link/list.html to look for a type to make. Although to some extent that's a lost cause anyway.

For this particular type, the extra maintenance burden is pretty much negligible, since it just adds an extra check. That would be a bigger argument against e.g. adding greater-than fillomino.

In terms of Fillomino variants: There's so many nice ones around. How would we choose which to add? E.g. greater-than mentioned above. Or the variant with the killer-like sum cages. Or non-consecutive.

One reasonable criterion could be that it's been published. Toketa is an argument in favour of symmetry area, there. Another could be that people have been making them, e.g. if there were a bunch of these showing up on puzsq or twitter. Or you'd made a set yourself and wanted to publish them with applet.

As another argument against adding this: Why not just publish such puzzles as fillominos and note that it's a variant of this type? We've got plenty of puzzles that work as variants like that already. There's still the plan to extend the DB's variant handling (the /v:/ thing) with a tag that allows referring to a proper type definition. At that point, the only thing missing would be integrated answer checking. And there might even ways to work that part out.

I'm happy to have Araf in btw despite it not being taken up so far. It feels like an established type

[robx]

Oh, also: I don't think potential plans to rewrite are a strong argument against adding anything. Certainly I wouldn't hold any PRs back for #178. It is very much something to seriously consider though, after breaking the change up into more manageable chunks. It should not fundamentally interfere with adding types though.

[tausbn]

Thank you for your thoughts! They were very illuminating.

As another argument against adding this: Why not just publish such puzzles as fillominos and note that it's a variant of this type? We've got plenty of puzzles that work as variants like that already. There's still the plan to extend the DB's variant handling (the /v:/ thing) with a tag that allows referring to a proper type definition. At that point, the only thing missing would be integrated answer checking. And there might even ways to work that part out.

That's a very compelling argument. In fact, I think you may just have convinced me that we shouldn't merge this PR!

Perhaps a reasonable rule of thumb here is that if a puzzle variant does nothing but add further rules, without adding further elements (e.g. kinds of givens), then it's better implemented as the base type with a variant marker. (Which, I'll be completely honest, I'd forgotten we had.)

Thus, something like Checkerboard Fillomino would not be suitable (as it is simply a Fillomino with extra rules), but something like Snake Pit (which adds e.g. markers for snake ends and for squares where the ends are not allowed to be) would be.

[robx]

I'd really like to have checkered fillomino, though! I think it's different enough from fillomino to feel like its own type. And it could benefit from dedicated solver support, i.e., allowing shaded/unshaded input or similar.

(But mostly I think it's just that I really like the type so would find excuses to justify making it first class...)

[tausbn]

I was surprised to see your comment about checkerboarding, since I've just been treating checkered fillomino as if the only extra constraint is that no interior corner can be next to exactly three regions. (I think I can see how the colouring can be used in deductions, however.)

The main problem with maintaining the checkerboard colouring is that local choices in colouring may be globally inconsistent with each other. Thus, we would need to either automatically adjust the colouring when two such regions are connected, or allow a "flip shading" operation. I'm not sure which would be preferable.

Either way, I would be interested to see this implemented (or to implement it myself). My long-term plan is to implement most of the types I've seen in Toketa -- or at least the ones I enjoyed solving, and would like to experiment with myself. (I'm thinking I might try my hand at doing one from scratch next. Possibly Sunglasses or (Anti)-Magnets.)

[robx]

Regarding checkered fillomino, it's true that the rule is equivalent absent holes in the grid, but there are a couple arguments better expressed in terms of shading. And yes, it's not obvious how to choose the shading across the grid, even on paper. E.g. https://maybepuzzles.com/2015/04/16/puzzles-64-65-checkered-fillomino/

But yes, there's no real need for a dedicated implementation. It's more that I think the type could admit an implementation that would make it really fun to solve with a tool like this, but then there's also probably a much improved base fillomino interface to make first.

Toketa types sound great. Sunglasses in particular, and (plain) Magnets would be good to have. Anti-Magnets would fall into a similar case as this one, where I'd probably rather leave the variant out.

Still not entirely sure what to do about this one. I might merge it and reserve the right to be inconsistent in such decisions in the future. Will let it rest for a bit and look at other types first.

[robx]

Merged (by hand), should be live soon.