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 examples have the keyword "rotate" on the OEBP.

If rotating an example about the center can change its sorting the BP is a left example here.

Note that BPs about relative rotation comparisons fit on the right side.

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

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:
BP548 BP549 BP550 BP551 BP552  *  BP554 BP555 BP556 BP557 BP558

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

visualbp [smaller | same | bigger]

Aaron David Fairbanks

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

If applying a scaling to the whole of any example can change its sorting the BP fits on the left side here. (For BPs with bounding boxes means scaling an object appearing in a box within the bounding box.)

Note that BPs about relative size comparisons of multiple objects fit on the right side.

Adjacent-numbered pages:
BP549 BP550 BP551 BP552 BP553  *  BP555 BP556 BP557 BP558 BP559

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

visualbp [smaller | same | bigger]

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-sorted BPs have the keyword "left-null" on the OEBP.

Right-sorted BPs have the keyword "right-null" on the OEBP.

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

See BP1160 for the version about an all-black panel instead of all-white.

Adjacent-numbered pages:
BP562 BP563 BP564 BP565 BP566  *  BP568 BP569 BP570 BP571 BP572

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

visualbp [smaller | same | bigger]

Aaron David Fairbanks

Left examples have the keyword "physics" on the OEBP. These are visual Bongard Problems that are most easily recognized by people as depicting some physics-related phenomenon. Usually, since physics is described by mathematics, this means there is also a (perhaps complicated) solution that can be described in terms of pure geometry.

See also keyword math.

Adjacent-numbered pages:
BP567 BP568 BP569 BP570 BP571  *  BP573 BP574 BP575 BP576 BP577

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

visualbp [smaller | same | bigger]

Aaron David Fairbanks

Left-sorted Bongard Problems have the keyword "consistentsymbols" on the OEBP.

A most extreme "consistentsymbols" Bongard Problem is BP121: the solution is about codes consistently symbolizing objects. However, "consistentsymbols" Bongard Problems may have solution unrelated to the symbolism; the symbolism may just be implicit, e.g. always meaning dots as numbers, always meaning stacked dots as fractions, repeatedly using the same simple drawings as shorthand to represent platonic solids. Most BPs have some symbolism in this sense; a Bongard Problem should only be labelled "consistentsymbols" if there is a relatively high amount of varied symbolism, particularly if it is visual symbolism not all people would naturally understand.

A Bongard Problem featuring a real language would be another extreme example of "consistentsymbols".

A Bongard Problem with many varied images meant to be interpreted in unique ways is not necessarily "consistentsymbols," since there is no specific-to-this-Bongard-Problem vocabulary of symbols that must be known to understand it. (Even so, some might say that how people intuitively interpret images is a vocabulary on its own.)

Sometimes, the symbolism isn't an important part of the Bongard Problem, and it just helps make the Bongard Problem easier to read (see the help keyword). For example, a Bongard Problem may include many clumps of dots, and the solution of the Problem may have to do with counting the number of dots in each clump; the Bongard Problem might build up a symbolic context by always arranging each number of dots in a consistent way (e.g. how they conventionally appear on dice faces).

"Consistentsymbols" is related to the keyword structure, a format that all examples fit that the solver needs to know how to read. In "consistentsymbols" Bongard Problems, not all examples need to fit a rigid format; instead there may be various smaller structures of meaning that only appear in some examples.

"Consistentsymbols" is related to assumesfamiliarity, BPs that require the solver to take certain assumptions about what the examples are for the solution to seem simple. A "consistentsymbols" Bongard Problem may have a very convoluted solution that involves explaining the meaning of each appearing object; however, the solution can become simple given correct interpretations of all objects. This effect works best when each object must be interpreted the same way across all boxes in order for the simple solution to fit. The comments sections of "consistentsymbols" BP pages on the OEBP ought to explain the symbolism used.

Adjacent-numbered pages:
BP833 BP834 BP835 BP836 BP837  *  BP839 BP840 BP841 BP842 BP843

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

visualbp [smaller | same | bigger]

Aaron David Fairbanks

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 "infinitedetail" on the OEBP.

Image files on the OEBP do not really have infinite detail. For a panel to be intuitively read as having infinite detail, there usually needs to be some apparent self-similarity, or perhaps a sequence of objects following an easy to read pattern getting smaller and smaller with increasing pixelation.

Usually in "infinitedetail" Bongard Problems, not only is it a puzzle to figure out the solution, but it is another puzzle to find self-similarities and understand the intended infinite detail in each example.

BPs tagged with the keyword "infinitedetail" usually feature pixelated images that give the closest approximation of the intended infinite structure up to pixelation. This means they should be tagged with the keyword perfect, but should not be tagged with the keyword pixelperfect.

Just because a Bongard Problem has "infinitedetail" does not necessarily make it infodense. Some fractal images might be encoded by a small amount of information (just the information about which places within itself it includes smaller copies of itself) and may be recognized quickly.

Adjacent-numbered pages:
BP953 BP954 BP955 BP956 BP957  *  BP959 BP960 BP961 BP962 BP963

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

visualbp [smaller | same | bigger]

Aaron David Fairbanks

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

Adjacent-numbered pages:
BP971 BP972 BP973 BP974 BP975  *  BP977 BP978 BP979 BP980 BP981

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

visualbp [smaller | same | bigger]

Leo Crabbe