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

Right-sorted Bongard Problems have the keyword "hard" on the OEBP.

"Easy" means easy for human beings to solve, not computers.

Adjacent-numbered pages:
BP496 BP497 BP498 BP499 BP500  *  BP502 BP503 BP504 BP505 BP506

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

bp [smaller | same | bigger]

Aaron David Fairbanks

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

Right-sorted Bongard Problems have the keyword "less." They are not necessarily "bad," but we do not want more like them.

Adjacent-numbered pages:
BP498 BP499 BP500 BP501 BP502  *  BP504 BP505 BP506 BP507 BP508

subjective, meta (see left/right), links, keyword, oebp, right-finite, left-it, feedback, time

bp [smaller | same | bigger]

Aaron David Fairbanks

Bongard Problems sorted left have the keyword "precise" on the OEBP.

Bongard Problems sorted right have the keyword "fuzzy" on the OEBP.

In an precise Bongard Problem, any relevant example is either clearly sorted left, clearly sorted right, or clearly not sorted.

(All relevant examples clearly sorted either left or right is the keyword allsorted.)

How can it be decided whether or not a rule is precise? How can it be decided whether or not a rule classifies all "examples that are relevant"? There needs to be another rule to determine which examples the original rule intends to sort. Bongard Problems by design communicate ideas without fixing that context ahead of time. The label "precise" can only mean a Bongard Problem's rule seems precise to people who see it. (This "precise vs. fuzzy" Bongard Problem is fuzzy.)

In an precise "less than ___ vs. greater than ___" Bongard Problem (keyword spectrum), the division between the sides is usually an apparent threshold. For example, there is an intuitive threshold between acute and obtuse angles (see e.g. BP292).

As a rule of thumb, do not consider imperfections of hand drawn images (keyword ignoreimperfections) when deciding whether a Bongard Problem is precise or fuzzy. Just because one can draw a square badly does not mean "triangle vs. quadrilateral" (BP6) should be labelled fuzzy; similar vagueness arises in all hand-drawn Bongard Problems. (For Bongard Problems in which fine subtleties of drawings, including small imperfections, are meant to be considered, use the keyword perfect.)

Sometimes the way a Bongard Problem would sort certain examples is an unsolved problem in mathematics. (See e.g. BP820.) There is a precise criterion that has been used to verify each sorted example fits where it fits (some kind of mathematical proof); however, where some examples fit is still unknown. Whether or not such a Bongard Problem should be labelled "precise" might be debated.

(Technical note: some properties are known to be undecidable, and sometimes the decidability itself is unknown. See https://en.wikipedia.org/wiki/Decision_problem .)

(See the keyword proofsrequired.)

One way to resolve this ambiguity is to define "precise" as meaning that once people decide where an example belongs for a reason, they will all agree about it.

Sometimes the class of all examples in a Bongard Problem is imprecise, but, despite that, the rule sorting those examples is precise. Say, for some potential new example, it is unclear whether it should be included in the Bongard Problem at all, but, if it were included, it would be clear where it should be sorted (or that it should be left unsorted). A Bongard Problem like this can still be tagged "precise".

(If all examples are clearly sorted except for some example for which it is unclear whether it belongs to the class of relevant examples, the situation becomes ambiguous.)

On the other hand, sometimes the class of all examples is very clear, with an obvious boundary. (Keyword preciseworld.)

There is a subtle distinction to draw between Bongard Problems that are precise to the people making them and Bongard Problems that are precise to the people solving them. A Bongard Problem (particularly a non-allsorted one) might be labeled "precise" on the OEBP because the description and the listed ambiguous examples explicitly forbid sorting certain border cases; however, someone looking at the Bongard Problem without access to the OEBP page containing the definition would not be aware of this. It may or may not be obvious that certain examples were intentionally left out of the Bongard Problem. A larger collection of examples may make it more clear that a particularly blatant potential border case was left out intentionally.

See BP876 for the version with pictures of Bongard Problems instead of links to pages on the OEBP.

See both and neither for specific ways an example can be classified as unsorted in an "precise" Bongard Problem.

Adjacent-numbered pages:
BP503 BP504 BP505 BP506 BP507  *  BP509 BP510 BP511 BP512 BP513

fuzzy, meta (see left/right), links, keyword, right-self, sideless

bp [smaller | same | bigger]

Aaron David Fairbanks

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

This sorts Bongard Problems based on how BP513 (left-narrow) would sort them if they were flipped; see that page for a description.

Adjacent-numbered pages:
BP509 BP510 BP511 BP512 BP513  *  BP515 BP516 BP517 BP518 BP519

dual, meta (see left/right), links, keyword, side

bp [smaller | same | bigger]

Aaron David Fairbanks

This refers to all Bongard Problem solution ideas. No need to be a particularly well-made or well-defined Bongard Problem.

Adjacent-numbered pages:
BP536 BP537 BP538 BP539 BP540  *  BP542 BP543 BP544 BP545 BP546

notso, meta (see left/right), links, world, left-self, right-null, left-it, feedback

everything [smaller | same]
zoom in left (bp)

Aaron David Fairbanks

Adjacent-numbered pages:
BP602 BP603 BP604 BP605 BP606  *  BP608 BP609 BP610 BP611 BP612

meta (see left/right), links, metaconcept

bp [smaller | same | bigger]

Harry E. Foundalis

Alternatively, BP pages on the OEBP with number less than or equal to 100 vs. other BP pages.

Bongard's original Problems have the keyword "bongard" on the OEBP.

Adjacent-numbered pages:
BP793 BP794 BP795 BP796 BP797  *  BP799 BP800 BP801 BP802 BP803

meta (see left/right), links, keyword

bppage [smaller | same | bigger]

Aaron David Fairbanks

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

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

For the purposes of this Bongard Problem, "small change" means adding to or removing from an arbitrarily small portion of the image. Other kinds of small change could be explored, such as making changes in multiple small places, translating, rotating, scaling, or deforming the whole image slightly (see also keywords deformunstable vs. deformstable), or even context-dependent small changes (e.g., changing the shadings slightly in BP196, or making small 3d changes to the represented 3d objects in BP333), but they are not considered here.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It is allowed for a small change to make an example sorted slightly more ambiguously.

Small changes that make an example no longer even fit in with the format of a Bongard Problem are not considered. (Otherwise, far fewer Bongard Problems would be called "stable".)

For whether small changes make an example no longer fit in with the Bongard Problem, see unstableworld vs. stableworld.

If a Bongard Problem is shown with imperfect hand drawings (keyword ignoreimperfections), it is fine to apply the keyword "unstable" ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could make an example switch sides, no longer fit in with the format of the Bongard Problem, or otherwise be ambiguously sorted.)

Stable Bongard Problems are generally perfect and pixelperfect.

Gap (technically) implies stable. (However, in practice it has seemed unnatural to tag BPs "stable" when ALL small changes render certain examples unsortable, as is sometimes the case in "gap" BPs.)

Unstable Bongard Problems are often precise.

Stable Bongard Problems tend to either be fuzzy or otherwise either have a gap or be not allsorted.

See BP1144, which is about all small changes making all examples unsortable rather than some small change making some example switch sides.

See BP1140, which is about any (perhaps large) additions of detail instead of small changes.

Adjacent-numbered pages:
BP958 BP959 BP960 BP961 BP962  *  BP964 BP965 BP966 BP967 BP968

BP1 is unstable because it's possible to change nothing slightly by adding a pixel to end up with something.

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

Aaron David Fairbanks

Right-sorted BPs have the keyword "gap" on the OEBP.

A Bongard Problem with a gap showcases two completely separate classes of objects.

For example, the Bongard Problem "white vs. black" (BP962) has a gap; there is no obvious choice of shared context between the two sides. One could imagine there is a spectrum of grays between them, or that there is a space of partially filled black-and-white images between them, or any number of other ambient contexts.

Bongard Problems about comparing quantities on a spectrum should not usually be considered "gap" BPs. (Discrete spectra perhaps.) A spectrum establishes a shared context, with examples on both sides of the BP landing somewhere on it. (However, if it is reasonable to imagine getting the solution without noticing a spectrum in between, it could be a gap, since the ambient context is unclear.)

Bongard Problems with gaps may seem particularly arbitrary when the two classes of objects are particularly unrelated.

If a Bongard Problem has a "gap" it is likely precise: it will likely be clear on which side any potential example fits.

"Gap" implies stable. (This technically includes cases in which ALL small changes make certain examples no longer fit in with the Bongard Problem, as is sometimes the case in "gap" BPs. See also BP1144.)

See also preciseworld. "Gap" Bongard Problems would be tagged "preciseworld" when the two classes of objects are each clear; it is then apparent that there is no larger shared context and that no other types of objects besides the two types would be sorted by the Bongard Problem.

See BP1140, which is about any (perhaps large) additions instead of repeated small changes.

Adjacent-numbered pages:
BP959 BP960 BP961 BP962 BP963  *  BP965 BP966 BP967 BP968 BP969

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

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.

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.

Closely related to gap Problems and stable Problems.

Bongard Problems tagged finishedexamples will fit right.

Adjacent-numbered pages:
BP1135 BP1136 BP1137 BP1138 BP1139  *  BP1141 BP1142 BP1143 BP1144 BP1145

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

Leo Crabbe