Search: author:Aaron David Fairbanks
|
|
BP575 |
| Non-number-based Bongard Problems vs. Bongard Problems whose solutions only depend on counting the number of something. |
|
| |
|
|
COMMENTS
|
Right examples have the keyword "number" on the OEBP. The solution must only depend on counting the number of something: no comparison between numbers of different things.
When a "number" Bongard Problem sorts numbers unambiguously (keyword precise), the left side and the right side define disjoint sets of numbers. When a "number" Bongard Problem sorts all numbers (keyword allsorted), the subsets are complements of one another.
Many but not all right examples require nontrivial mathematical knowledge to solve (keyword math). |
|
CROSSREFS
|
BP200 is a version of this with sides flipped, sorting pictures of Bongard Problems (miniproblems) instead of links to pages on the OEBP, and with emphasis on feature-based solutions as an alternative to number-based solutions.
Adjacent-numbered pages:
BP570 BP571 BP572 BP573 BP574  *  BP576 BP577 BP578 BP579 BP580
|
|
KEYWORD
|
meta (see left/right), links, keyword, dependence
|
|
WORLD
|
bp [smaller | same | bigger]
|
|
AUTHOR
|
Aaron David Fairbanks
|
|
|
|
|
BP574 |
| BP page intends to include all possible examples fitting right vs. other BP pages. |
|
| |
|
|
|
|
|
BP573 |
| BP page intends to include all possible examples fitting left vs. other BP pages. |
|
| |
|
|
COMMENTS
|
Left-sorted BPs have the keyword "left-full" on the OEBP.
For meta-BPs about solution ideas, left-full only means the BP page hopes to include all fitting BP pages on the OEBP (as opposed to all possible Bongard Problems).
As with applying the keywords left-finite and right-finite, deciding what should count as "different" examples depends on the Bongard Problem.
Note this is not just BP574 (right-full) flipped.
TODO: Maybe this should be changed into two keywords: one for non-meta-BPs and one for meta-BPs. - Aaron David Fairbanks, Feb 11 2021 |
|
CROSSREFS
|
For non-meta BPs, left-full implies left-finite (at least until the OEBP implements a feature that allows algorithmic generation of infinite examples).
Adjacent-numbered pages:
BP568 BP569 BP570 BP571 BP572  *  BP574 BP575 BP576 BP577 BP578
|
|
KEYWORD
|
meta (see left/right), links, keyword
|
|
WORLD
|
bppage [smaller | same | bigger]
|
|
AUTHOR
|
Aaron David Fairbanks
|
|
|
|
|
BP572 |
| Physical Bongard Problems vs. other visual Bongard Problems |
|
| |
|
|
|
|
|
BP571 |
| Bongard Problems that require mathematical understanding to solve vs. other Bongard Problems. |
|
| |
|
|
|
|
|
BP570 |
| Shape outlines that aren't triangles vs. black shapes that aren't squares. |
|
| |
|
|
|
|
|
BP568 |
| Solution idea would not be chosen as the simplest solution vs. there is not a simpler solution that always comes along with it. |
|
| |
|
|
COMMENTS
|
Left examples have the keyword "overriddensolution" on the OEBP.
An "overriddensolution" is solution idea for a Bongard Problem that would not be chosen by the solver because there is a simpler solution that always comes with it.
An overridden solution occurs when the Bongard Problem's examples on both sides all share some constraint, and furthermore within this constrained class of examples, the intended rule is equivalent to a simpler rule that can be understood without noticing the constraint. See e.g. BP1146. The solver of the Bongard Problem will get the solution before noticing the constraint.
There is a more extreme class of overridden solution: not only is the solution possible to overlook in favor of something simpler, but even with scrutiny it will likely never be recognized. See e.g. BP570. This happens when intended left and right side rules are not direct negations of one another, but one or both of these rules is not "narrow"-- it can only be communicated in a Bongard Problem by its opposite being on the other side.
TO DO: Should this more extreme version have its own keyword? - Aaron David Fairbanks, Nov 23 2021
The keyword left-narrow (resp. right-narrow) is for Bongard Problems whose left-side (resp. right-side) rule can be recognized alone without examples on the other side.
The keyword notso is for Bongard Problems whose two sides are direct negations of one another. |
|
CROSSREFS
|
See keyword impossible for solution ideas that cannot even apply to any set of examples, much less be communicated as the best solution.
Adjacent-numbered pages:
BP563 BP564 BP565 BP566 BP567  *  BP569 BP570 BP571 BP572 BP573
|
|
EXAMPLE
|
BP570 "Shape outlines that aren't triangles vs. black shapes that aren't squares" was created as an example of this. |
|
KEYWORD
|
meta (see left/right), links, keyword
|
|
WORLD
|
bp [smaller | same | bigger]
|
|
AUTHOR
|
Aaron David Fairbanks
|
|
|
|
|
BP567 |
| Visual Bongard Problems that would sort a blank panel on the left vs. visual Bongard Problems that would sort a blank panel on the right. |
|
| |
|
|
|
|
|
BP566 |
| Meta Bongard Problems of the form "[transformation] applied to some examples switch their sorting vs. sorting is invariant under [transformation]" vs. other meta Bongard Problems. |
|
| |
|
|
COMMENTS
|
Left-sorted Bongard Problems have the keyword "invariance" on the OEBP.
Bongard Problems labelled "invariance" are usually (but not always) about transformations that can be undone by other transformations of the same class. (The technical term for this kind of transformation is an "isomorphism".)
When the transformations used in a "invariance" Bongard Problem vary continuously, there could usually be made a corresponding stability Bongard Problem. Stability Bongard Problems are like "invariance" Bongard Problems but for arbitrarily small applications of [transformation] affecting examples' sorting.
Potentially, stability Bongard Problems could be considered "invariance" Bongard Problems. On one hand, they are different, since checking whether arbitrarily small transformations switch an example's sorting is different from checking whether a particular transformation switches an example's sorting; the former is infinitely many conditions. On the other hand, there is actually only finitely much detail in any of the examples, and in practice a stability Bongard Problem generally just amounts to "a small application of [transformation] switches an example's sorting vs. not".
(The keyword gap is another example of a Bongard Problem currently labelled with "invariance" that arguably does not technically fit.)
Also, dependence Bongard Problems could be considered "invariance" Bongard Problems, where the relevant kind of transformation is swapping the example out for any other example that shares the relevant property. |
|
CROSSREFS
|
"Invariance" Bongard Problems are notso Bongard Problems.
"Invariance" Bongard Problems are often keywords (keyword keyword) on the OEBP.
See keyword problemkiller, which is about transformations making all sorted examples unsortable.
Adjacent-numbered pages:
BP561 BP562 BP563 BP564 BP565  *  BP567 BP568 BP569 BP570 BP571
|
|
KEYWORD
|
meta (see left/right), links, keyword, metameta
|
|
WORLD
|
linksbp [smaller | same | bigger]
|
|
AUTHOR
|
Aaron David Fairbanks
|
|
|
|
|
BP562 |
| There exists a closed trail that hits each vertex exactly once vs. not so. |
|
| |
|
|
|
|
Welcome |
Solve |
Browse |
Lookup |
Recent |
Links |
Register |
Contact
Contribute |
Keywords |
Concepts |
Worlds |
Ambiguities |
Transformations |
Invalid Problems |
Style Guide |
Goals |
Glossary
|
|
|
|
|
|
|
|
|
|