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.

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".)

Other fitting names for this keyword besides "invariance" would be "dependence" or "symmetry".

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.

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".)

Other fitting names for this keyword besides "invariance" would be "dependence" or "symmetry".

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

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".)

Other fitting names for this keyword besides "invariance" would be "dependence" or "symmetry".

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.

@Stability Bongard Problems are considered "invariance" Bongard Problems. On one hand, maybe this is wrong, 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.)

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

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

When the transformations used in a "dependence" Bongard Problem vary continuously, there could usually be made a corresponding @stability Bongard Problem. @Stability Bongard Problems are like "dependence" Bongard Problems but for arbitrarily small applications of [transformation] affecting examples' sorting.

@Stability Bongard Problems are considered "dependence" Bongard Problems. On one hand, maybe this is wrong, 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 "dependence" that arguably does not technically fit.)

Although BP575 (@number) concerns a kind of dependence, it is not about invariance under a transformation.

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

When the transformations used in a "dependence" Bongard Problem vary continuously, there could usually be made a corresponding @stability Bongard Problem. @Stability Bongard Problems are like "dependence" Bongard Problems but for arbitrarily small applications of [transformation] affecting examples' sorting.

@Stability Bongard Problems are considered "dependence" Bongard Problems. On one hand, maybe this is wrong, 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 "dependence" that arguably does not technically fit.)

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

Bongard Problems labelled "dependence" may leave out (i.e., treat as ambiguous) the case of a Bongard Problem where [transformation] can make an example no longer fit in at all but will never switch an example's sorting.

(If this convention is kept, then a Bongard Problem sorted by the "dependence" Bongard Problem would be sorted the same way if we were only to consider transformations that leave examples fitting in.)

When the transformations used in a "dependence" Bongard Problem vary continuously, there could usually be made a corresponding @stability Bongard Problem. @Stability Bongard Problems are like "dependence" Bongard Problems but for arbitrarily small applications of [transformation] affecting examples' sorting.

@Stability Bongard Problems are considered "dependence" Bongard Problems. On one hand, maybe this is wrong, 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 "dependence" that arguably does not technically fit.)

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

Bongard Problems labelled "dependence" may leave out (i.e., treat as ambiguous) the case of a Bongard Problem where [transformation] can make an example no longer fit in at all but will never switch an example's sorting.

(If this convention is kept, then a Bongard Problem sorted by the "dependence" Bongard Problem would be sorted the same way if we were only to consider transformations that leave examples fitting in.)

When the transformations used in a "dependence" Bongard Problem vary continuously, there could usually be made a corresponding @stability Bongard Problem. @Stability Bongard Problems are like "dependence" Bongard Problems but for arbitrarily small applications of [transformation] affecting examples' sorting.

@Stability Bongard Problems are considered "dependence" Bongard Problems. On one hand, maybe this is wrong, 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 as a @dependence Bongard Problem that arguably does not technically fit.)

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

Bongard Problems labelled "dependence" may leave out (i.e., treat as ambiguous) the case of a Bongard Problem where [transformation] can make an example no longer fit in at all but will never switch an example's sorting.

(If this convention is kept, then a Bongard Problem sorted by the "dependence" Bongard Problem would be sorted the same way if we were only to consider transformations that leave examples fitting in.)

When the transformations used in a "dependence" Bongard Problem vary continuously, there could usually be made a corresponding @stability Bongard Problem. @Stability Bongard Problems are like "dependence" Bongard Problems but for arbitrarily small applications of [transformation] affecting examples' sorting.

@Stability Bongard Problems are labelled as "dependence" Bongard Problems. On one hand, maybe this is wrong, 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 as a @dependence Bongard Problem that arguably does not technically fit.)

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

Bongard Problems labelled "dependence" may leave out (i.e., treat as ambiguous) the case of a Bongard Problem where [transformation] can make an example no longer fit in at all but will never switch an example's sorting.

(If this convention is kept, then a Bongard Problem sorted by the "dependence" Bongard Problem would be sorted the same way if we were only to consider transformations that leave examples fitting in.)

When the transformations used in a "dependence" Bongard Problem vary continuously, there could usually be made a corresponding @stability Bongard Problem.

@Stability Bongard Problems are like "dependence" Bongard Problems but for arbitrarily small applications of [transformation] affecting examples' sorting.

@Stability Bongard Problems are labelled as "dependence" Bongard Problems. On one hand, maybe this is wrong, 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 as a @dependence Bongard Problem that arguably does not technically fit.)

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

Bongard Problems labelled "dependence" may leave out (i.e., treat as ambiguous) the case of a Bongard Problem where [transformation] can make an example no longer fit in at all but will never switch an example's sorting.

(If this convention is kept, then a Bongard Problem sorted by the "dependence" Bongard Problem would be sorted the same way if we were only to consider transformations that leave examples fitting in.)

When the transformations used in a "dependence" Bongard Problem vary continuously, there could usually be made a corresponding @stability Bongard Problem.

@Stability Bongard Problems are like "dependence" Bongard Problems but for arbitrarily small applications of [transformation] affecting examples' sorting.

@Stability Bongard Problems are labelled as "dependence" Bongard Problems. On one hand, maybe this is wrong, 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 "small applications of [transformation] switch an example's sorting vs. not".

(The keyword @gap is another example of a Bongard Problem currently labelled as a @dependence Bongard Problem that arguably does not technically fit.)

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

Bongard Problems labelled "dependence" may leave out (i.e., treat as ambiguous) the case of a Bongard Problem where [transformation] can make an example no longer fit in at all but will never switch an example's sorting.

(If this convention is kept, then a Bongard Problem sorted by the "dependence" Bongard Problem would be sorted the same way if we were only to consider transformations that leave examples fitting in.)

When the transformations used in a "dependence" Bongard Problem vary continuously, there could usually be made a corresponding @stability Bongard Problem.

@Stability Bongard Problems are like "dependence" Bongard Problems but for arbitrarily small applications of [transformation] affecting examples' sorting.

@Stability Bongard Problems are labelled as "dependence" Bongard Problems. On one hand, maybe this is wrong, 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 actually infinitely many conditions. On the other hand, there is only finitely much detail in the pictures, and in practice a @stability Bongard Problem generally amounts to "small applications of [transformation] switch an example's sorting vs. not".

(The keyword @gap is another example of a Bongard Problem currently labelled as a @dependence Bongard Problem that arguably does not technically fit.)

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

Bongard Problems labelled "dependence" may leave out (i.e., treat as ambiguous) the case of a Bongard Problem where [transformation] can make an example no longer fit in at all but will never switch an example's sorting.

(If this convention is kept, then a Bongard Problem sorted by the "dependence" Bongard Problem would be sorted the same way if we were only to consider transformations that leave examples fitting in.)

When the transformations used in a "dependence" Bongard Problem vary continuously, there could usually be made a corresponding @stability Bongard Problem.

@Stability Bongard Problems are like "dependence" Bongard Problems but for arbitrarily small applications of [transformation] affecting examples' sorting.

@Stability Bongard Problems are also labelled as "dependence" Bongard Problems. On one hand, maybe this is wrong, 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 actually infinitely many conditions. On the other hand, there is only finitely much detail in the pictures, and in practice a @stability Bongard Problem generally amounts to "small applications of [transformation] switch an example's sorting vs. not".

(The keyword @gap is another example of a Bongard Problem currently labelled as a @dependence Bongard Problem that arguably does not technically fit.)

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

Bongard Problems labelled "dependence" may leave out (i.e., treat as ambiguous) the case of a Bongard Problem where [transformation] can make an example no longer fit in at all but will never switch an example's sorting.

(If this convention is kept, then a Bongard Problem sorted by the "dependence" Bongard Problem would be sorted the same way if we were only to consider transformations that leave examples fitting in.)

When the transformations used in a "dependence" Bongard Problem vary continuously, there could usually be made a corresponding @stability Bongard Problem.

@Stability Bongard Problems are like "dependence" Bongard Problems but for arbitrarily small applications of [transformation] affecting examples' sorting.

@Stability Bongard Problems are also considered to be @dependence Bongard Problems. On one hand, maybe this is wrong, 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 actually infinitely many conditions. On the other hand, there is only finitely much detail in the pictures, and in practice a @stability Bongard Problem generally amounts to "small applications of [transformation] switch an example's sorting vs. not".

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

Bongard Problems labelled "dependence" may leave out (i.e., treat as ambiguous) the case of a Bongard Problem where [transformation] can make an example no longer fit in at all but will never switch an example's sorting.

(If this convention is kept, then a Bongard Problem sorted by the "dependence" Bongard Problem would be sorted the same way if we were only to consider transformations that leave examples fitting in.)

When the transformations used in a "dependence" Bongard Problem vary continuously, there could usually be made a corresponding @stability Bongard Problem.

@Stability Bongard Problems are like "dependence" Bongard Problems but for arbitrarily small applications of [transformation] affecting examples' sorting. The @stability Bongard Problems are also labeled as @dependence Bongard Problems.

On one hand, maybe they should not, 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 actually infinitely many conditions. On the other hand, there is only finitely much detail in the pictures, and in practice a @stability Bongard Problem generally amounts to "small applications of [transformation] switch an example's sorting vs. not".

"Dependence" Bongard Problems are @notso Bongard Problems.

"Dependence" Bongard Problems are often keywords (keyword @keyword) on the OEBP.

See keyword @problemkiller, which is about transformations making all sorted examples unsortable.

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

Bongard Problems labelled "dependence" may leave out (i.e., treat as ambiguous) the case of a Bongard Problem where [transformation] can make an example no longer fit in at all but will never switch an example's sorting.

(If this convention is kept, then a Bongard Problem sorted by the "dependence" Bongard Problem would be sorted the same way if we were only to consider transformations that leave examples fitting in.)

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

Bongard Problems labelled "dependence" may leave out (i.e., treat as ambiguous) the case where [transformation] can make an example no longer fit in at all but will never switch an example's sorting.

(If this convention is kept, then a Bongard Problem sorted by the "dependence" Bongard Problem would be sorted the same way if we were only to consider transformations that leave examples fitting in.)

Left-sorted Bongard Problems have the keyword "dependence" on the OEBP.

Bongard Problems labelled "dependence" 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".)

Other fitting names for this keyword besides "dependence" would be "invariance" or "symmetry".

Bongard Problems labelled "dependence" may leave out (i.e., treat as ambiguous) the case where [transformation] can make an example no longer fit in at all but will never switch an example's sorting.

(As a consequence of this convention, a Bongard Problem sorted by the "dependence" Bongard Problem would be sorted the same way if we were only to consider transformations that leave examples fitting in.)