Search: ex:BP1028
|
Displaying 1-10 of 12 results found.
|
( next ) page 1 2
|
|
Sort:
id
Format:
long
Filter:
(all | no meta | meta)
Mode:
(words | no words)
|
|
|
|
|
BP508 |
| Bongard Problems with precise definitions vs. Bongard Problems with vague definitions. |
|
| |
|
|
|
COMMENTS
|
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. |
|
CROSSREFS
|
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
|
|
KEYWORD
|
fuzzy, meta (see left/right), links, keyword, right-self, sideless
|
|
WORLD
|
bp [smaller | same | bigger]
|
|
AUTHOR
|
Aaron David Fairbanks
|
|
|
|
|
BP509 |
| Bongard Problems that sort all relevant examples vs. Bongard Problems that would leave some unsorted. |
|
| |
|
|
|
COMMENTS
|
Left-sorted Bongard Problems have the keyword "allsorted" on the OEBP.
A Bongard Problem is labelled "allsorted" when the type of thing it sorts is partitioned unambiguously and without exception into two groups.
Similarly to using the precise and fuzzy keywords, calling a Bongard Problem "allsorted" is a subjective/intuitive judgment. The collection of all relevant potential examples is not clearly delineated anywhere.
(Sometimes it's ambiguous whether to consider certain examples that are ambiguously sorted relevant.)
The solution to an "allsorted" Bongard Problem can usually be re-phrased as "___ vs. not so" (see the keyword notso).
But not every "___ vs. not so" Bongard Problem should be labelled "allsorted"; there could be ambiguous border cases in a "___ vs. not so" Bongard Problem.
Bongard Problems in which the two sides are so different that there is no middle ground between them (keyword gap) are sometimes still labelled "allsorted", since the intuitive pool of all relevant examples just amounts to the two unrelated sides. But some "gap" Bongard Problems are not like that; for example sometimes there are more related classes of examples besides the two shown.
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. A Bongard Problem like this can still be tagged "allsorted".
On the other hand, sometimes the class of all examples is very clear, with an obvious boundary. (Keyword preciseworld.)
In deciding where to sort an example, we think about it until we come to a conclusion; an example isn't here considered ambiguous just because someone might have a hard time with it (keyword hardsort).
However, sometimes the way a Bongard Problem would sort certain examples is an unsolved problem in mathematics, and it may be unknown whether there is even a solution. Whether or not such a Bongard Problem should be labelled "allsorted" might be debated.
(See the keyword proofsrequired.)
One way to resolve this ambiguity is to redefine "allsorted" as meaning that once people decide where an example belongs, it will be on one of the two sides, and they will all agree about it.
There is a distinction to be made between a non-"allsorted" Bongard Problem that could be made "allsorted" by making (finitely many) more examples sorted (thereby modifying or clarifying the solution of the Bongard Problem) and one such that this is not possible while maintaining a comparably simple solution. The former kind would often be labelled precise, in particular when these border cases have been explicitly forbidden from being sorted in the Bongard Problem's definition.
For instance, discrete Bongard Problems that are not allsorted usually fall into the former category. |
|
CROSSREFS
|
See BP875 for the version with pictures of Bongard Problems instead of links to pages on the OEBP.
"Allsorted" implies precise.
"Allsorted" and both are mutually exclusive.
"Allsorted" and neither are mutually exclusive.
Adjacent-numbered pages:
BP504 BP505 BP506 BP507 BP508 * BP510 BP511 BP512 BP513 BP514
|
|
KEYWORD
|
fuzzy, meta (see left/right), links, keyword, right-self, sideless, right-it, feedback
|
|
WORLD
|
bp [smaller | same | bigger]
|
|
AUTHOR
|
Aaron David Fairbanks
|
|
|
|
|
BP535 |
| Visual Bongard Problems such that flipping over the vertical axis (left/right) can switch an example's side vs. visual Bongard Problems whose examples' sorting doesn't change under such a transformation. |
|
| |
|
|
|
|
|
|
BP537 |
| Meta Bongard Problems vs. other Bongard Problems. |
|
| |
|
|
|
|
|
|
BP552 |
| Orientation-dependent Bongard Problems vs. orientation-independent visual Bongard Problems. |
|
| |
|
|
|
COMMENTS
|
Left examples have the keyword "handed" on the OEBP.
If mirroring any example along the any axis can change its sorting the BP is "handed."
Note that BPs about comparing orientation between multiple things in one example fit on the right side. |
|
CROSSREFS
|
See BP871 for the version with pictures of Bongard Problems (miniproblems) instead of links to pages on the OEBP.
The keyword leftright is specifically about flipping over the vertical axis, while the keyword updown is specifically about flipping over the horizontal axis.
Bongard Problems tagged rotate are usually "handed", since any rotation can be created by two reflections. Not necessarily, however, since the reflected step in between might not be sorted on either side by the Bongard Problem.
Adjacent-numbered pages:
BP547 BP548 BP549 BP550 BP551 * BP553 BP554 BP555 BP556 BP557
|
|
KEYWORD
|
meta (see left/right), links, keyword, invariance, wellfounded
|
|
WORLD
|
visualbp [smaller | same | bigger] zoom in left (handed_visualbp)
|
|
AUTHOR
|
Aaron David Fairbanks
|
|
|
|
|
BP571 |
| Bongard Problems that require mathematical understanding to solve vs. other Bongard Problems. |
|
| |
|
|
|
|
|
|
BP789 |
| Bongard Problems in which all examples have the same format, a specific multi-part structure vs. other Bongard Problems. |
|
| |
|
|
|
COMMENTS
|
Left examples have the keyword "structure" on the OEBP.
Examples of "structures": Bongard Problem, Bongard Problem with extra unsorted panel ("Bongard's Dozen"), 4-panel analogy grid, sequence of objects with a quantity changing by a constant amount.
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.
A Bongard Problem can non-verbally teach someone how a particular structure works, 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. |
|
CROSSREFS
|
Adjacent-numbered pages:
BP784 BP785 BP786 BP787 BP788 * BP790 BP791 BP792 BP793 BP794
|
|
KEYWORD
|
meta (see left/right), links, keyword
|
|
WORLD
|
bp [smaller | same | bigger]
|
|
AUTHOR
|
Aaron David Fairbanks
|
|
|
|
|
BP867 |
| Bongard Problem with solution that can be naturally expressed as "___ vs. not so" vs. not so. |
|
| |
| | BP6
 |  | Qat | blimp | notso |
|
|
|
|
COMMENTS
|
Left-sorted BPs have the keyword "notso" on the OEBP.
This meta Bongard Problem is about Bongard Problems featuring two rules that are conceptual opposites.
Sometimes both sides could be seen as the "not" side: consider, for example, two definitions of the same Bongard Problem, "shape has hole vs. does not" and "shape is not filled vs. is". It is possible (albeit perhaps unnatural) to phrase the solution either way when the left and right sides partition all possible relevant examples cleanly into two groups (see the allsorted keyword).
When one property is "positive-seeming" and its opposite is "negative-seeming", it usually means the positive property would be recognized without counter-examples (e.g. a collection of triangles will be seen as such), while the negative property wouldn't be recognized without counter-examples (e.g. a collection of "non-triangle shapes" will just be interpreted as "shapes" unless triangles are shown opposite them).
BP513 (keyword left-narrow) is about Bongard Problems whose left side can be recognized without the right side. When a Bongard Problem is left-narrow and not "right-narrow that usually makes the property on the left seem positive and the property on the right seem negative.
The OEBP by convention has preferred the "positive-seeming" property (when there is one) to be on the left side.
All in all, the keyword "notso" should mean:
1) If the Bongard Problem is "narrow" on at least one side, then it is left-narrow.
2) The right side is the conceptual negation of the left side.
If a Bongard Problem's solution is "[Property A] vs. not so", the "not so" side is everything without [Property A] within some suitable context. A Bongard Problem "triangles vs. not so" might only include simple shapes as non-triangles; it need not include images of boats as non-triangles. It is not necessary for all the kitchen sink to be thrown on the "not so" side (although it is here). |
|
CROSSREFS
|
See BP1001 for a version sorting pictures of Bongard Problems (miniproblems) instead of links to pages on the OEBP. (This version is a little different. In BP1001, the kitchen sink of all other possible images is always included on the right "not so" side, rather than a context-dependent conceptual negation.)
Contrast keyword viceversa.
"[Property A] vs. not so" Bongard Problems are often allsorted, meaning they sort all relevant examples--but not always, because sometimes there exist ambiguous border cases, unclear whether they fit [Property A] or not.
Adjacent-numbered pages:
BP862 BP863 BP864 BP865 BP866 * BP868 BP869 BP870 BP871 BP872
|
|
KEYWORD
|
notso, meta (see left/right), links, keyword, left-self, funny
|
|
WORLD
|
everything [smaller | same] zoom in left
|
|
AUTHOR
|
Aaron David Fairbanks
|
|
|
|
|
BP895 |
| Meta Bongard Problems that sort Bongard Problems based on other information than just their solutions (e.g. what format the Bongard Problem is, or what specific examples are shown in it) vs. Meta Bongard Problems that sort Bongard Problems purely based on solution. |
|
| |
|
|
|
COMMENTS
|
Left-sorted Bongard Problems have the keyword "presentationmatters" on the OEBP.
Right-sorted Bongard Problems have the keyword "presentationinvariant" on the OEBP.
Meta Bongard problems that sort Bongard Problems purely based on their solutions usually have two versions in the database: one that sorts images of Bongard Problems and one that sorts links to pages on the OEBP. If both versions exist, users should make them cross-reference one another. (Meta Bongard Problems that sort images of Bongard Problems have the keyword miniproblems, whereas meta Bongard Problems that sort links to OEBP pages have the keyword links.)
For meta-pages on the OEBP that sort other pages on the OEBP (keyword links), "presentationmatters" means factoring in content like the BP number, the currently uploaded examples, the wording of the title, the description, and so on, rather than just the solution (that is, how the page would sort all potential examples). This is unusual.
"One solution vs. multiple solutions" (BP828) seems like a border-case. - Aaron David Fairbanks, Aug 01 2020 |
|
CROSSREFS
|
See BP1010 (projectionmatters versus 3d) for a similar idea: there 2D representations are to 3D objects as here Bongard Problems are to Bongard Problem solutions.
Adjacent-numbered pages:
BP890 BP891 BP892 BP893 BP894 * BP896 BP897 BP898 BP899 BP900
|
|
KEYWORD
|
fuzzy, meta (see left/right), links, keyword, right-self, sideless, metameta, right-it, dependence, presentationinvariant
|
|
WORLD
|
metabp [smaller | same | bigger]
|
|
AUTHOR
|
Jago Collins
|
|
|
|
|
BP1111 |
| Bongard Problem requires solver to already be interpreting all examples in a specific way for the answer to seem simple vs. not so. |
|
| |
|
|
|
COMMENTS
|
Left-sorted Bongard Problems have the keyword "assumesfamiliarity" on the OEBP.
Sometimes all the examples in a Bongard Problem need to be interpreted a certain way for the Bongard Problem to make sense. Only once the representation is understood, the idea seems simple.
For example, all meta Bongard Problems (Bongard Problems sorting other Bongard Problems) assume the solver interprets the examples as Bongard Problems.
TO DO: Maybe it is best to stop putting the label "assumesfamiliarity" on all meta-Bongard Problems. There are so many of them. It may be better to only use the "assumesfamiliarity" keyword on meta-BPs for a further assumption than just that all examples are interpreted as Bongard Problems. - Aaron David Fairbanks, Feb 11 2021 |
|
CROSSREFS
|
Many Bongard Problems in which all examples take the same format (keyword structure) assume the solver already knows how to read that format.
Some Bongard Problems assume the solver will be able to understand symbolism that is consistent between examples (keyword consistentsymbols).
Bongard Problems tagged math often assume the solver is familiar with a certain representation of a math idea.
Adjacent-numbered pages:
BP1106 BP1107 BP1108 BP1109 BP1110 * BP1112 BP1113 BP1114 BP1115 BP1116
|
|
EXAMPLE
|
BP1032: The solution should really read "Assuming all images are Bongard Problems sorting each natural number left or right ..." This Bongard Problem makes sense to someone who has been solving a series of similar BPs, but otherwise there is no reason to automatically read a collection of numbers as standing for a larger collection of numbers. |
|
KEYWORD
|
fuzzy, meta (see left/right), links, keyword
|
|
WORLD
|
bp [smaller | same | bigger]
|
|
AUTHOR
|
Aaron David Fairbanks
|
|
|
|