login
Hints
(Greetings from The On-Line Encyclopedia of Bongard Problems!)

Revision history for BP508

Displaying 51-75 of 384 results found. page 1 2 3 4 5 6 7 8 9 ... 16
     Edits shown per page: 25.
BP508 on 2023-06-15 12:53:34 by Aaron David Fairbanks                approved
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 called 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, 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".

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

There is a distinction to be made between a "fuzzy" Bongard Problem that could be made "precise" by including more examples (thereby modifying or clarifying the solution of the Bongard Problem) and a "fuzzy" Bongard Problem that cannot be made "precise" while maintaining a comparably simple solution.

More specifically, considering the examples that would fit in a Bongard Problem's pool of examples but are not included and are ambiguously sorted, there is a distinction to be made between those that could be included (thereby modifying or clarifying the solution of the Bongard Problem) and those that cannot be included while maintaining a comparably simple solution.

BP508 on 2023-06-15 12:47:29 by Aaron David Fairbanks                approved
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 called 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, 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".

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

Considering the examples that would fit in a Bongard Problem's pool of examples but are not included and are ambiguously sorted, there is a distinction to be made between groups of examples that could be included (thereby modifying or clarifying the solution of the Bongard Problem) and groups of examples that cannot be included while maintaining a comparably simple solution.

BP508 on 2023-06-15 12:45:41 by Aaron David Fairbanks                approved
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 called 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, 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".

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

Considering the examples that would fit in a Bongard Problem's pool of examples but are not included and would be ambiguously sorted, there is a distinction to be made between groups of examples that could be included (thereby modifying or clarifying the solution of the Bongard Problem) and groups of examples that cannot be included while maintaining a comparably simple solution.

BP508 on 2023-06-15 12:40:57 by Aaron David Fairbanks                approved
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 called 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, 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".

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

Considering the examples that would fit in a Bongard Problem's pool of examples but are not included and would be ambiguously sorted, there is a distinction to be made between those that could be included (thereby modifying or clarifying the solution of the Bongard Problem) and those that cannot be included while maintaining a comparably simple solution.

BP508 on 2023-06-15 12:40:42 by Aaron David Fairbanks                approved
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 called 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, 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".

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

Considering the examples that would fit in a Bongard Problem's pool of examples but are not included and would be ambiguously sorted, there is a distinction to be made between those that could be included (thereby modifying or clarifying the solution of the Bongard Problem) and those that cannot be included while maintaining a simple solution.

BP508 on 2023-06-15 12:40:14 by Aaron David Fairbanks                approved
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 called 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, 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".

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

Considering the examples that would fit in a Bongard Problem's pool of examples but are not included and would be ambiguously sorted, there is a distinction to be made between those that could be included (thereby modifying or clarifying the solution of the Bongard Problem) and those that cannot be included while maintaining a natural solution.

BP508 on 2023-04-02 13:01:37 by Aaron David Fairbanks                approved
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 called 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, 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".

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

BP508 on 2023-03-26 16:09:56 by Leo Crabbe                approved
+DATA

  

BP508 on 2023-02-13 23:25:27 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-02-13 23:21:45 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-02-13 23:21:41 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-02-13 23:21:38 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-01-08 16:46:17 by Aaron David Fairbanks                approved
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 called 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 redefine "precise" as meaning that once people decide where an example belongs, 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".

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

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.

BP508 on 2023-01-05 21:54:32 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-01-05 21:54:20 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-01-05 21:53:49 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-01-05 21:52:42 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-01-05 21:52:26 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-01-05 21:52:10 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-01-05 21:51:21 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-01-05 21:48:32 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-01-05 21:48:22 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2023-01-05 19:33:45 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2022-12-30 04:10:41 by Aaron David Fairbanks                approved
+DATA

  

BP508 on 2022-12-29 21:12:19 by Aaron David Fairbanks                approved
COMMENTS

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

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

In an exact 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 exact? 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 "exact" can only mean a Bongard Problem's rule seems precise to people who see it. (This "exact vs. fuzzy" Bongard Problem is fuzzy.)

In an exact "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 exact or fuzzy. Just because one can draw a square badly does not mean "triangle vs. quadrilateral" (BP6) should be called 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 "exact" 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 redefine "exact" as meaning that once people decide where an example belongs, 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 "exact".

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


Welcome | Solve | Browse | Lookup | Recent | Links | Register | Contact
Contribute | Keywords | Concepts | Worlds | Ambiguities | Transformations | Invalid Problems | Style Guide | Goals | Glossary