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

Examples of "structures": Bongard Problem, Bongard's Dozen, 4-panel analogy board, sequence of objects with a constant quantity changing from object to object that together represent the quality that is changing, sequence of objects paired with clump of n dots together representing the nth object that should come in the sequence.

If the solver hasn't become familiar with the featured structure, the Bongard Problem's solution may seem convoluted or inelegant. (See keyword assumesfamiliarity.) Once the solver gets used to seeing a particular structure it becomes easier to read that structure and solve Bongard Problems featuring it.

One can non-verbally teach someone how a particular structure works via a Bongard Problem, showing valid examples of that structure versus non-examples. E.g., BP968 for the structure of Bongard Problems and BP981 for the structure of analogy grids. (See the keyword teach.)

Adjacent-numbered pages:
BP784 BP785 BP786 BP787 BP788  *  BP790 BP791 BP792 BP793 BP794

meta (see left/right), links, keyword

bp [smaller | same | bigger]

Aaron David Fairbanks

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

Be encouraged to contribute new interesting examples to Bongard Problems with this keyword.

There is much overlap with the keyword hardsort.

This is what it usually means to say examples fit on (e.g.) the left of a Bongard Problem in various creative ways: there is no (obvious) general method to determine a left-fitting example fits left.

There is a related idea in computability theory: a "non recursively enumerable" property is one that cannot in general be checked by a computer algorithm.

But keep in mind the tag "creativeexamples" is supposed to mean something less formal. For example, it requires no ingenuity for a human being to check when a simple shape is convex or concave (so BP4 is not labelled "creativeexamples"). However, it is not as if we use an algorithm to do this, like a computer. (It is not even clear what an "algorithm" would mean in this context, since it is ambiguous both what class of shapes the Bongard Problem sorts and how that would be encoded into a computer program's input. There are usually many options and ambiguities like this whenever one tries to formalize the content of a Bongard Problem.)

Adjacent-numbered pages:
BP861 BP862 BP863 BP864 BP865  *  BP867 BP868 BP869 BP870 BP871

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

bp [smaller | same | bigger]

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-sorted Bongard Problems have the keyword "rules" on the OEBP.

In the typical "rules" Bongard Problem, it is possible to come up with many convoluted rules that fit each example, but the intended interpretation is the only simple and obvious one.

Since it is difficult to communicate a rule with little detail, "rules" Bongard Problems are usually infodense.

Typically, each example is itself a bunch of smaller examples that all obey the rule. It is the same as how a Bongard Problems relies on many examples to communicate rules; it likely wouldn't get the answer across with just one example.

Often, each rule is communicated just by showing some examples of things satisfying it placed next to each other. (See keywords left-narrow and right-narrow.) Contrast Bongard Problems, which are more communicative, by showing some examples satisfying the rule and some examples NOT satisfying the rule.

BP1157 is an example of a "rules" Bongard Problem in which each intended rule is communicated by just one example of its application; these rules have to be particularly simple and intuitive, and the individual examples have to be complicated enough to communicate them.

A "rules" Bongard Problem is often collective. Some examples may admit multiple equally plausible rules, and the correct interpretation of each example only becomes clear once the solution is known. The group of examples together improve the solver's confidence about having understood each individual one right.

It is common that there will be one or two examples with multiple reasonable interpretations due to oversight of the author.

All meta Bongard Problems are "rules" Bongard Problems.

Many of the other Bongard-Problem-like structures seen on the OEBP are also about recognizing a pattern. (See keyword structure.)

"Rules" Bongard Problems are abstract, although the individual rules in them may not be abstract. "Rules" Bongard Problems also usually have the keyword creativeexamples.

Adjacent-numbered pages:
BP1153 BP1154 BP1155 BP1156 BP1157  *  BP1159 BP1160 BP1161 BP1162 BP1163

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

Aaron David Fairbanks