This is the keyword "dual" on the OEBP.

Given an example there is some way to "flip sides" by altering it. The left-to-right and right-to-left transformations should be inverses.

It is not required that there only be one such transformation. For example, for many handed Bongard Problem, flipping an example over any axis will reliably switch its sorting.

It is not required that every left example must have its corresponding right example uploaded on the OEBP nor vice versa. See the keyword contributepairs for the BPs the OEBP advises users upload left and right examples for in pairs.

Adjacent-numbered pages:
BP529 BP530 BP531 BP532 BP533  *  BP535 BP536 BP537 BP538 BP539

meta (see left/right), links, keyword, sideless

bp [smaller | same | bigger]

Aaron David Fairbanks

Left examples have the keyword "leftright" on the OEBP.

See updown.

All "leftright" Bongard Problems are handed.

Adjacent-numbered pages:
BP530 BP531 BP532 BP533 BP534  *  BP536 BP537 BP538 BP539 BP540

meta (see left/right), links, keyword, sideless, invariance

handed_visualbp [smaller | same | bigger]

Aaron David Fairbanks

Left examples have the keyword "experimental" on the OEBP.

Right examples have the keyword "traditional" on the OEBP.

Experimental BPs push the boundaries of what makes Bongard Problems Bongard Problems.

Traditional BPs show some simple property of black and white pictures. The OEBP is a place with many wild and absurd Bongard Problems, so it is useful to have an easy way to just find the regular old Bongard Problems.

Adjacent-numbered pages:
BP545 BP546 BP547 BP548 BP549  *  BP551 BP552 BP553 BP554 BP555

subjective, meta (see left/right), links, keyword, left-it

bp [smaller | same | bigger]

Aaron David Fairbanks

Left examples have the keyword "handed" on the OEBP.

If mirroring any example along the any axis can change its sorting the BP is "handed."

Note that BPs about comparing orientation between multiple things in one example fit on the right side.

See BP871 for the version with pictures of Bongard Problems (miniproblems) instead of links to pages on the OEBP.

The keyword leftright is specifically about flipping over the vertical axis, while the keyword updown is specifically about flipping over the horizontal axis.

Bongard Problems tagged rotate are usually "handed", since any rotation can be created by two reflections. Not necessarily, however, since the reflected step in between might not be sorted on either side by the Bongard Problem.

Adjacent-numbered pages:
BP547 BP548 BP549 BP550 BP551  *  BP553 BP554 BP555 BP556 BP557

meta (see left/right), links, keyword, invariance, wellfounded

visualbp [smaller | same | bigger]
zoom in left (handed_visualbp)

Aaron David Fairbanks

Left-sorted examples have the keyword "blackwhite" on the OEBP.

Right-sorted examples have the keyword "blackwhiteinvariant" on the OEBP.

All examples are visual Bongard Problems that allow black to touch the bounding box (keyword bordercontent).

Adjacent-numbered pages:
BP551 BP552 BP553 BP554 BP555  *  BP557 BP558 BP559 BP560 BP561

meta (see left/right), links, keyword, invariance, wellfounded

visualbp [smaller | same | bigger]

Leo Crabbe

Left examples have the keyword "antihuman" on the OEBP.

Right examples have the keyword "anticomputer" on the OEBP.

Easy abstract Bongard Problems are typically anticomputer Bongard Problems.

See keyword help for Bongard Problems that can be made easier for humans to solve by the selection of helpful examples.

Adjacent-numbered pages:
BP560 BP561 BP562 BP563 BP564  *  BP566 BP567 BP568 BP569 BP570

spectrum, anticomputer, meta (see left/right), links, keyword, right-self, viceversa

bp [smaller | same | bigger]

Leo Crabbe

See keyword arbitrary.

Adjacent-numbered pages:
BP768 BP769 BP770 BP771 BP772  *  BP774 BP775 BP776 BP777 BP778

meta (see left/right), links, metaconcept, primitive

bp [smaller | same | bigger]

Harry E. Foundalis

Left examples have the keyword "perfect" on the OEBP.

Right examples have the keyword "ignoreimperfections".

Consider the difference in style between BP344 and BP24.

Hand-drawn figures in BPs are typically imperfect. A "circles vs. squares" BP may only show what are approximately circles and approximately squares. A pedant might append to the solutions of all Bongard Problems the caveat "...when figures are interpreted as the most obvious shapes they approximate."

This is the meaning of the label "ignoreimperfections". On the other hand, the label "perfect" means even the pedant would drop this caveat; either all the images are precise, or precision doesn't matter (see also keyword stable).

Even in BPs tagged "perfect", the tiny rough edges caused by image pixelation are not expected to matter. If the OEBP would indeed prefer users only upload pixel-perfect examples, a BP can be tagged with the stricter keyword pixelperfect.

E.g., for BPs having to do with smooth curves and lines, "perfect" only requires images offer the best possible approximation of those intended shapes given the resolution.

Most Bongard Problems involving small details at all would be tagged "perfect". However, this is not always so; sometimes the small details are intended to be noticed, but certain imperfections are still intended to be overlooked.

BP119 ("small correction results in circle vs. not") is an interesting example: imperfections matter with respect to the outline being closed, but imperfections do not matter with respect to circular-ness.

If a Bongard Problem on the OEBP is tagged "ignoreimperfections" -- i.e., it has imperfect hand drawings -- then other keywords are generally applied relative to the intended idea, a corrected version sans imperfect hand drawings. (For example, this is how the keywords precise and stable are applied. Alternative versions of these keywords, which factor in imperfect hand drawings, could be made instead, but that would be less useful.)

It may be better to change the definition of "perfect" so it only applies to Bongard Problems such that small changes can potentially switch an example's side / remove it from the Bongard Problem. That would cut down on the number of Bongard Problems to label "perfect". There isn't currently a single keyword for "small changes can potentially switch an example's side / remove it from the Bongard Problem", but this is basically captured by unstable or unstableworld. There is also deformunstable which uses a different notion of "small change". - Aaron David Fairbanks, Jun 16 2023

See BP508 for discussion of this topic in relation to Bongard Problems tagged precise.

Stable Bongard Problems are generally "perfect".

Pixelperfect implies "perfect".

The keywords proofsrequired and noproofs (BP1125) have a similar relationship: "noproofs" indicates a lenience for a certain kind of imperfection.

Adjacent-numbered pages:
BP908 BP909 BP910 BP911 BP912  *  BP914 BP915 BP916 BP917 BP918

Many Bongard Problems involving properties of curves (e.g. BP62) really are about those wiggly, imperfect curves; they qualify as "perfect" problems. On the other hand, Bongard Problems involving polygons, (e.g. BP5) often show only approximately-straight lines; they are not "perfect" problems.

Bongard Problems with world "bmp" should be "perfect".

meta (see left/right), links, keyword, wellfounded

visualbp [smaller | same | bigger]
zoom in left (perfect_bp)

Aaron David Fairbanks

Left examples have the keyword "help" on the OEBP.

BPs should be marked "help" when the OEBP wants most examples (at least on one side) to be helpful (not when just one or two uploaded examples are helpful).

Helpfulness can be a spectrum; most Bongard Problems are helpful to some degree just by not using the most convoluted unintelligible examples possible.

Examples that are helpful to people are often not particularly helpful to computers.

Any helpful Bongard Problem has a harder, not helpful version. For example, BP384 (square number of dots versus non-square number of dots) would be much harder if all examples had hundreds of dots that weren't arranged recognizably. Instead, the dots in the examples are always arranged in shapes that make the square-ness or non-square-ness of the numbers easy to check without brute counting.

When all examples in a Bongard Problem are helpful, it may become unclear whether the helpfulness is part of the Bongard Problem's solution.

E.g.: Is the left-hand side of BP384 "square number of dots", or is it "square number of dots that are arranged in a helpful way so as to communicate the square-ness"?

See seemslike, where examples being helpful is an irremovable aspect of the Bongard Problem's solution.

Adjacent-numbered pages:
BP925 BP926 BP927 BP928 BP929  *  BP931 BP932 BP933 BP934 BP935

anticomputer, meta (see left/right), links, keyword, oebp, instruction

bppage [smaller | same | bigger]
zoom in left (help_bp)

Aaron David Fairbanks

Left examples have the keyword "pixelperfect" on the OEBP.

All examples here are perfect Bongard Problems. That is, subtle imperfections in images are meant to be considered.

When a Problem is tagged with "pixelperfect", users are reminded to make sure they do not upload images such that taking the pixelation into account would affect the sorting of that example. That is, the zoomed-in jagged blocky version of the picture should still fit the solution.

For example, in the examples of BP335, which is about tessellation, the pixels interlock properly.

Stable Bongard Problems are generally pixelperfect.

Adjacent-numbered pages:
BP942 BP943 BP944 BP945 BP946  *  BP948 BP949 BP950 BP951 BP952

meta (see left/right), links, keyword, instruction

perfect_bp [smaller | same | bigger]

Leo Crabbe