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

Here "information" will mean, in a rough abstract way, the amount of data a person has to consciously unpack from each example in the process of sorting an example with respect to the Bongard Problem. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is always important to parse various qualities of every tiny shape shown.

There is much grey-area. What seems like relevant data to a human is different from what could be relevant in designing a computer algorithm to sort examples. A computer would not immediately see the shapes in BP3; first it would probably have to unpack the images as bitmap data and apply an algorithm that determines which part of the image the shape even is. (There are more efficient algorithms for sorting examples in this particular Problem, but the principle stands in general.) On the other hand, if a super-person could immediately intuit all properties of all things, as most people can intuit the colors of shapes in BP3, they would not have to consciously "unpack" extra data ever. As such, use human beings as the standard for deciding whether to call a Problem "dense" or not.

Images of Bongard Problems that are "dense" typically need to include a large number of examples in order to communicate the solution clearly without admitting alternative solutions. With so much data packed in each example, it becomes more likely that some of the random patterns in the data will happen to distinguish between the two sides in an unintended way. A similar issue appears in "convoluted" Problems (right-BP549).

Contrast "dense" Problems to "hardsort" (right-BP864) Problems, in which examples are difficult to sort, but perhaps that difficulty does not stem from parsing a high amount of information in the examples; perhaps there is a small amount of information extracted from the examples, but it is hard to determine whether that small amount of information fits the rule.

Bongard Problems in which all examples have a high amount of information that a person must unpack in order to sort them vs. Bongard Problems in which all examples have a low amount of information that a person must unpack in order to sort them.

Bongard Problems in which all examples have a high amount of information that must be unpacked in order to sort them vs. Bongard Problems in which all examples include very little information.

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

Here "information" will mean, in a rough abstract way, the amount of data a person has to consciously unpack from each example in the process of solving the Bongard Problem. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is always important to parse various qualities of every tiny shape shown.

There is much grey-area. What seems like relevant data to a human is different from what could be relevant in designing a computer algorithm to sort examples. A computer would not immediately see the shapes in BP3; first it would probably have to unpack the images as bitmap data and apply an algorithm that determines which part of the image the shape even is. (There are more efficient algorithms for sorting examples in this particular Problem, but the principle stands in general.) On the other hand, if a super-person could immediately intuit all properties of all things, as most people can intuit the colors of shapes in BP3, they would not have to consciously "unpack" extra data ever. As such, use human beings as the standard for deciding whether to call a Problem "dense" or not.

Images of Bongard Problems that are "dense" typically need to include a large number of examples in order to communicate the solution clearly without admitting alternative solutions. With so much data packed in each example, it becomes more likely that some of the random patterns in the data will happen to distinguish between the two sides in an unintended way. A similar issue appears in "convoluted" Problems (right-BP549).

Contrast "dense" Problems to "hardsort" (right-BP864) Problems, in which examples are difficult to sort, but perhaps that difficulty does not stem from parsing a high amount of information in the examples; perhaps there is a small amount of information extracted from the examples, but it is hard to determine whether that small amount of information fits the rule.

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

Here "information" will mean, in a rough abstract way, the amount of data a person has to consciously unpack from each example in the process of solving the Bongard Problem. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is always important to parse various qualities of every tiny shape shown.

There is much grey-area. What seems like relevant data to a human is different from what could be relevant in designing a computer algorithm to sort examples. A computer would not immediately see the shapes in BP3; first it would probably have to unpack the images as bitmap data and apply an algorithm that determines which part of the image the shape even is. (There are more efficient algorithms for sorting examples in this particular Problem, but the principle stands in general.) On the other hand, if a super-person could immediately intuit all properties of all things, as most people can intuit the colors of shapes in BP3, they would not have to consciously "unpack" extra data ever. Use human beings as the standard for deciding whether to call a Problem "dense" or not.

Images of Bongard Problems that are "dense" typically need to include a large number of examples in order to communicate the solution clearly without admitting alternative solutions. With so much data packed in each example, it becomes more likely that some of the random patterns in the data will happen to distinguish between the two sides in an unintended way. A similar issue appears in "convoluted" Problems (right-BP549).

Contrast "dense" Problems to "hardsort" (right-BP864) Problems, in which examples are difficult to sort, but perhaps that difficulty does not stem from parsing a high amount of information in the examples; perhaps there is a small amount of information extracted from the examples, but it is hard to determine whether that small amount of information fits the rule.

Bongard Problems in which all examples have a high amount of information that must be interpreted in order to sort them vs. Bongard Problems in which all examples include very little information.

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

Here "information" will mean, in a rough abstract way, the amount of data a person has to consciously unpack from each example in the process of solving the Bongard Problem. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is always important to parse various qualities of every tiny shape shown.

There is much grey-area. What seems like relevant data to a human is different from what could be relevant in designing a computer algorithm to sort examples. A computer would not immediately see the shapes in BP3; first it would probably have to unpack the images as bitmap data and apply an algorithm that determines which part of the image the shape even is. (There are more efficient algorithms for sorting examples in this particular Problem, but the principle stands in general.) On the other hand, if a super-person could immediately intuit all properties of all things, as most people are able to for the colors of shapes in BP3, they would not have to consciously "unpack" extra data ever. Use human beings as the standard for deciding whether to call a Problem "dense" or not.

Images of Bongard Problems that are "dense" typically need to include a large number of examples in order to communicate the solution clearly without admitting alternative solutions. With so much data packed in each example, it becomes more likely that some of the random patterns in the data will happen to distinguish between the two sides in an unintended way. A similar issue appears in "convoluted" Problems (right-BP549).

Contrast "dense" Problems to "hardsort" (right-BP864) Problems, in which examples are difficult to sort, but perhaps that difficulty does not stem from parsing a high amount of information in the examples; perhaps there is a small amount of information extracted from the examples, but it is hard to determine whether that small amount of information fits the rule.

Aaron David Fairbanks