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

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

Users are not able to add or remove examples from Problems tagged "finished." (This is unusual; most Bongard Problems on the OEBP can be expanded indefinitely by users.)

A "finished" Bongard Problem will always admit the alternative, convoluted solution "is [left example 1] OR is [left example 2] OR . . . OR is [last left example] vs. is [right example 1] OR is [right example 2] OR . . . OR is [last right example]".

Bongard's original Problems are tagged "finished."

Adjacent-numbered pages:
BP499 BP500 BP501 BP502 BP503  *  BP505 BP506 BP507 BP508 BP509

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

bppage [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 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

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

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

For every "noproofs" Bongard Problem there could be made a stricter "proofsrequired" version. This stricter version will be hardsort.

Deciding to make a Bongard Problem noproofs adds subjectivity to the sorting of examples (keyword subjective).

One interpretation of topology (a subject of mathematics -- see https://en.wikipedia.org/wiki/Topology ) is that a topology describes the observability of various properties. (The topological "neighborhoods" of a point are the subsets one could determine the point to be within using a finite number of measurements.) The analogue of restricting to just the cases where a property is observably true (i.e. "proofsrequired") corresponds to taking the topological "interior" of that property.

TO DO: It may be better to split each of these keywords up into two: "left-proofsrequired", "right-proofsrequired", "left-noproofs", "right noproofs".

See keyword hardsort.

Bongard Problems that are left-unknowable or right-unknowable will have to be "noproofs".

Adjacent-numbered pages:
BP1120 BP1121 BP1122 BP1123 BP1124  *  BP1126 BP1127 BP1128 BP1129 BP1130

In "proofsrequired" BP335 (shape tessellates the plane vs. shape does not tessellate the plane), shapes are only put in the Bongard Problem if they are known to tessellate or not to tessellate the plane. A "noproofs" version of this Bongard Problem would instead allow a shape to be put on the right if it was just (subjectively) really hard to find a way of tessellating the plane with it.

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

Aaron David Fairbanks