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

Consider the amount of data a person has to consciously unpack in each example in the process of determining how it should be sorted. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is important to read various qualities of every tiny shape shown.

Images of Bongard Problems that are "infodense" typically need to include a large number of examples in order to communicate the solution clearly without admitting unintended 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 Bongard Problems.

Contrast "infodense" Problems to @hardsort Bongard Problems, in which examples are difficult to sort, but perhaps that difficulty does not stem from reading a high amount of information; perhaps there is a small amount of information extracted from the examples, but it is hard to determine whether or not that information fits a rule.

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

Consider the amount of data a person has to consciously unpack in each example in the process of determining how it should be sorted. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is important to read various qualities of every tiny shape shown.

Images of Bongard Problems that are "infodense" typically need to include a large number of examples in order to communicate the solution clearly without admitting unintended 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 "infodense" Problems to "hardsort" (right-BP864) Problems, in which examples are difficult to sort, but perhaps that difficulty does not stem from reading a high amount of information; perhaps there is a small amount of information extracted from the examples, but it is hard to determine whether or not that information fits a rule.

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

Consider the amount of data a person has to consciously unpack in each example in the process of determining how it should be sorted. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is important to read various qualities of every tiny shape shown.

Images of Bongard Problems that are "infodense" typically need to include a large number of examples in order to communicate the solution clearly without admitting unintended 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 "infodense" 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 or not that small amount of information fits a rule.

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

Consider the amount of data a person has to consciously unpack in each example in the process of determining how it should be sorted. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is important to parse various qualities of every tiny shape shown.

Images of Bongard Problems that are "infodense" typically need to include a large number of examples in order to communicate the solution clearly without admitting unintended 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 "infodense" 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 or not that small amount of information fits a rule.

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

Here "information" roughly will mean the amount of data a person has to consciously notice in each example in the process of determining how it should be sorted. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is important to parse various qualities of every tiny shape shown.

Images of Bongard Problems that are "infodense" typically need to include a large number of examples in order to communicate the solution clearly without admitting unintended 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 "infodense" 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 or not that small amount of information fits a rule.

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

Here "information" roughly will mean the amount of data a person has to consciously unpack from each example in the process of determining how it should be sorted. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is important to parse various qualities of every tiny shape shown.

Images of Bongard Problems that are "infodense" typically need to include a large number of examples in order to communicate the solution clearly without admitting unintended 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 "infodense" 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 or not that small amount of information fits a rule.

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

Here "information" roughly will mean the amount of data a person has to consciously unpack from each example in the process of determining how it should be sorted. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is important to parse various qualities of every tiny shape shown.

Images of Bongard Problems that are "infodense" typically need to include a large number of examples in order to communicate the solution clearly without admitting unintended 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 "infodense" 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 or not that small amount of information fits a rule.

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

Here "information" will mean, roughly, the amount of data a person has to consciously unpack from each example in the process of determining how it should be sorted. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is important to parse various qualities of every tiny shape shown.

Images of Bongard Problems that are "infodense" typically need to include a large number of examples in order to communicate the solution clearly without admitting unintended 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 "infodense" 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 or not that small amount of information fits a rule.

Left examples have the keyword "infodense" 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 determining how it should be sorted. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is important to parse various qualities of every tiny shape shown.

Images of Bongard Problems that are "infodense" typically need to include a large number of examples in order to communicate the solution clearly without admitting unintended 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 "infodense" 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 or not that small amount of information fits a rule.

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

Here "information" will mean, in a rough abstract way, the amount of data a person has to consciously see in each example in the process of determining how it should be sorted. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is 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 "infodense" or not.

Images of Bongard Problems that are "infodense" typically need to include a large number of examples in order to communicate the solution clearly without admitting unintended 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 "infodense" 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 or not that small amount of information fits a 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 see in each example in the process of determining how it should be sorted. In BP3, it is only necessary to notice the color of the shape. In BP871, however, it is 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 unintended 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 or not that small amount of information fits a 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 see in each example in the process of determining how it should be sorted. 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 unintended 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 or not that small amount of information fits a 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 see in each example in the process of determining how it should be sorted. 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 unintended 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 see in each example in the process of determining how it should be sorted. 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 see in each example in the process of determining how an example is sorted. 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 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.

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 pixel 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.