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

Right examples have the keyword "stable" on the OEBP.

For the purpose of this Bongard Problem, "small change" means adding to or removing from an arbitrarily small portion of the image. Other kinds of small change could be explored, such as translating or deforming the whole image slightly, or even context-dependent small-changes, but they are not considered here.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

The border-case situation where small changes may make an example no longer fit in with the Bongard Problem, but never switch its sorting, is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

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

Right examples have the keyword "stable" on the OEBP.

For the purpose of this Bongard Problem, "small change" means adding to or removing from an arbitrarily small portion of the image. More general kinds of small change could be explored, such as translating or deforming the whole image slightly, or even context-dependent small-changes, but they are not considered here.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

The border-case situation where small changes may make an example no longer fit in with the Bongard Problem, but never switch its sorting, is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

The border-case situation where small changes may make an example no longer fit in with the Bongard Problem, but never switch its sorting, is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

The border-case situation where small changes may render an example outright unsortable, but never switch its sorting, is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

Neither "stable" nor "unstable" covers the case where small changes may render an example outright unsortable, but never switch its sorting. This border-case situation is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

Neither "stable" nor "unstable" is meant to include the case where small changes may render an example outright unsortable, but never switch its sorting. This border-case situation is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

Neither "stable" nor "unstable" includes the case where small changes may render an example outright unsortable, but never switch its sorting. This border-case situation is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

Neither "stable" nor "unstable" includes the case where small changes may render an example entirely unsortable, but never switch its sorting. This border-case situation is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

Neither "stable" nor "unstable" includes the case where small changes may completely render an example unsortable, but never switch its sorting. This border-case situation is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

Neither "stable" nor "unstable" includes the case where small changes may render an example unsortable, but never switch its sorting. This border-case situation is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

Neither "stable" nor "unstable" includes the case where small changes may render an example unsortable, but never switch its sorting. This border-case situation is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

"Stable" includes the case where small changes may render an example unsortable, but never switch its sorting. This subtler distinction is handled by the keywords @strictlystable vs. @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

Stable implies @perfect.

Stable implies @pixelperfect.

@Gap (technically) implies stable. (However, in practice it has seemed unnatural to tag BPs "stable" when ALL small changes render certain examples unsortable, as is sometimes the case in "gap" BPs.)

Unstable Bongard Problems are often @precise.

Stable Bongard Problems tend to either be @fuzzy or otherwise either have a @gap or be not @allsorted.

See BP1144, which is about all small changes making all examples unsortable rather than some small change making some example switch sides.

See BP1140, which is about any (perhaps large) additions of detail instead of small changes.

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

"Stable" includes the case where small changes may render an example unsortable, but never switch its sorting. This subtler distinction is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

Bongard Problems in which small changes to examples can switch their sorting vs. Bongard Problems in which slightly changed examples remain sorted the same way.

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

Neither "stable" nor "unstable" includes the case where small changes may render an example unsortable, but never switch its sorting. This border-case situation is handled by the keyword @stableincontext.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

Note: neither "stable" nor "unstable" includes the case where small changes may render an example unsortable, but never switch its sorting.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

Stable implies @perfect.

Stable implies @pixelperfect.

@Gap (technically) implies stable. (However, in practice it has seemed unnatural to tag BPs "stable" when all small changes render certain examples unsortable, as is sometimes the case in "gap" BPs.)

Unstable Bongard Problems are often @precise.

Stable Bongard Problems tend to either be @fuzzy or otherwise either have a @gap or be not @allsorted.

See BP1144, which is about all small changes making all examples unsortable rather than some small change making some example switch sides.

See BP1140, which is about any (perhaps large) additions of detail instead of small changes.

Stable implies @perfect.

Stable implies @pixelperfect.

@Gap (technically) implies stable. (However, in practice it has seemed unnatural to tag BPs "stable" when all small changes render certain examples unsortable, as is sometimes the case in "gap" BPs.)

Unstable Bongard Problems are often @exact.

Stable Bongard Problems tend to either be @fuzzy or otherwise either have a @gap or be not @allsorted.

See BP1144, which is about all small changes making all examples unsortable rather than some small change making some example switch sides.

See BP1140, which is about any (perhaps large) additions of detail instead of small changes.

Stable implies @perfect.

Stable implies @pixelperfect.

@Gap implies stable.

Unstable Bongard Problems are often @exact.

Stable Bongard Problems tend to either be @fuzzy or otherwise either have a @gap or be not @allsorted.

See BP1144, which is about all small changes making all examples unsortable rather than some small change making some example switch sides.

See BP1140, which is about any (perhaps large) additions of detail instead of small changes.

Stable implies @perfect.

Stable implies @pixelperfect.

@Gap implies stable.

Unstable Bongard Problems are often @exact.

Stable Bongard Problems tend to either be @fuzzy or otherwise either have a @gap or be not @allsorted.

See BP1144, which is about small changes making examples unsortable rather than switching sides.

See BP1140, which is about any (perhaps large) additions of detail instead of small changes.

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

Right examples have the keyword "stable" on the OEBP.

In a "stable" Bongard Problem, no small change should outright flip an example's sorting. It IS allowed for a small change to make an example sorted slightly more ambiguously.

If a Bongard Problem is shown with imperfect hand drawings (keyword @ignoreimperfections), the keyword "unstable" can be applied ignoring this. For instance, a hand-drawn version of BP344 would still be tagged "unstable", even though it would show examples wrong by small amounts.

(Note: a BP would only be tagged "ignoreimperfections" in the first place if the underlying idea were such that several small changes could switch an example's side or could make it unsortable.)

Stable implies @perfect.

Stable implies @pixelperfect.

@Gap implies stable.

Unstable Bongard Problems are often @exact.

Stable Bongard Problems tend to either be @fuzzy or otherwise either have a @gap or be not @allsorted.

See BP1140, which is about any (perhaps large) additions of detail instead of small changes.

BP1 is unstable because it's possible to change nothing slightly by adding a pixel to end up with something.