Adjacent-numbered pages:
BP633 BP634 BP635 BP636 BP637  *  BP639 BP640 BP641 BP642 BP643

meta (see left/right), links, metaconcept

bp [smaller | same | bigger]

Harry E. Foundalis

Adjacent-numbered pages:
BP682 BP683 BP684 BP685 BP686  *  BP688 BP689 BP690 BP691 BP692

meta (see left/right), links, metaconcept, primitive, left-it, feedback

bp [smaller | same | bigger]

Harry E. Foundalis

Adjacent-numbered pages:
BP686 BP687 BP688 BP689 BP690  *  BP692 BP693 BP694 BP695 BP696

meta (see left/right), links, metaconcept, primitive, left-it, feedback

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.

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

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

Aaron David Fairbanks

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

When this keyword is added to a Problem, OEBP users are advised to add a corresponding right example for every left example they add and vice versa.

It is common for Bongard Problems to present left examples on the left side and corresponding altered versions of those examples on the right side, tweaked only slightly, to highlight the difference and make the solution easier to see (see keyword help).

This is common in more abstract Bongard Problems that admit a wide range of examples, a variety of different styles or types (e.g. BP360). Showing two versions of the same thing, one on the left and one on the right, helps a person interpret what that thing is meant to be in the context of the Bongard Problem; whatever qualities vary between the two in the pair must be relevant.

If a person cannot sort an example according to the solution property without seeing its corresponding opposite example, the Bongard Problem is invalid (see https://www.oebp.org/invalid.php ). There is no one rule dividing the sides; the solution is not a method to determine whether an arbitrary example fits left or right. See also Bongard Problems with the keyword collective, which are similarly borderline-invalid.

A BP in which each left example corresponds to a right example and vice versa could be remade as a Bongard Problem in which the left examples are the pairs. For example BP360 would turn into "a pair consisting of the ordered version of something and the chaotic version of the same thing vs. a pair of things not satisfying this relationship." This process would turn a Bongard Problem that is invalid in the sense described above into a valid one.

(See keyword orderedpair.)

In some "contributepairs" Bongard Problems there really is a natural choice of left version for every right example and vice versa (see keyword dual); in others the choice is artificially imposed by the Bongard Problem creator.

When "contributepairs" Bongard Problems are laid out in the format with a grid of boxes on either side of a dividing line, the boxes may be arranged so as to highlight the correspondence: either

A B | A B

E F | E F

G H | G H

or

A B | B A

E F | F E

G H | H G.

Adjacent-numbered pages:
BP914 BP915 BP916 BP917 BP918  *  BP920 BP921 BP922 BP923 BP924

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

bppage [smaller | same | bigger]
zoom in left (correspondence_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

This classification is specifically concerned with changes to examples that leave them sortable, as there are almost always ways of adding details to a BP's examples that make them unsortable.

Right-sorted BPs in this Bongard Problem are often Bongard Problems where there is always a way of adding to left-sorted examples to make them right-sorted, but not the other way around, or vice versa.

Another version of this Bongard Problem could be made about adding white (erasure of detail) instead of black (addition of detail).

Another version could be made about adding either white or black, but not both.

Where appropriate, you can assume all images will have some room in a lip of white background around the border (ignoring https://en.wikipedia.org/wiki/Sorites_paradox ).

You can't expand the boundary of an image as you add detail to it. If image boundaries could be expanded, then any shape could be shrunken to a point in relation to the surrounding whiteness, which could then be filled in to make any other shape.

How should this treat cases in which just a few examples can't be added to at all (like an all-black box)? E.g. BP966. Should this be sorted right (should the one special case of a black box spoil it) or should it be sorted left (should examples that can't at all be further added be discounted)? Maybe we should only sort BPs in which all examples can be further added to. (See BP1143^left.) - Aaron David Fairbanks, Nov 12 2021

Is "addition of detail" context-dependent, or does it just mean any addition of blackness to the image? Say you have a points-and-lines Bongard Problem like BP1100, and you're trying to decide whether to sort it left or right here. You would just want to think about adding more points and lines to the picture. You don't want to get bogged down in thinking about whether black could be added to the image in a weird way so that a point gets turned into a line, or something. - Aaron David Fairbanks, Nov 13 2021

See BP1139 for Bongard Problems in which no example can be added to, period.

Adjacent-numbered pages:
BP1134 BP1135 BP1136 BP1137 BP1138  *  BP1140 BP1141 BP1142 BP1143 BP1144

meta (see left/right), links, sideless

Leo Crabbe