Limits on challenge generation

[jonathanolson]

Currently challenges can be generated that are cumbersome and cause layout issues:

It looks like limiting things to 20 shape pieces per stack should avoid layout issues, but presumably we'd want to limit things a bit more (for the user experience).

Additionally, limiting the number of number pieces in total quantity should prevent the horizontal overflow case.

Are there specific limits that are desired?

[ariel-phet]

@jonathanolson lets limit shape piece stacks to less than or equal to 10. (a quick sampling of the Java version seems to keep the piece stacks to 10 or under, and that seems still like a reasonable UX).

For the horizontal overflow issue (with number cards), something about your screenshot appears a bit odd. On the "mixed numbers" game, it appears we always kept the number cards to the numbers 1-9. Given that you are using a "mixed number" container, we should probably enforce that rule on the mixed numbers game (which should prevent any horizontal overflow).

The improper fractions game (in Java just labelled "Build a Fraction") appears to limit the number of "whole shapes" to a maximum of two, and never appears to have overflow issues.

Happy to discuss over a call.

[jonathanolson]

On the "mixed numbers" game, it appears we always kept the number cards to the numbers 1-9. Given that you are using a "mixed number" container, we should probably enforce that rule on the mixed numbers game (which should prevent any horizontal overflow).

Mixed numbers level 5 notes in the design doc:

All representations possible, but each target is only one type of representation 1, 2, or 3, as whole number Fractional portion from the set {1/2, 1/3, 2/3, ¼, ¾, 1/5, 2/5, 3/5, 4/5, 1/6, 5/6, 1/7, 2/7, 3/7, 4/7, 5/7, 6/7, 1/8, 3/8, 5/8, 7/8, 1/9, 2/9, 4/9, 5/9, 7/9, 8/9} 2 of the representations match cards exactly, 1 of the representations requires simplifying to a solution

So say it picks (1 2/5, 2 5/6, 1 4/7). It seems impossible to force one that requires a "simplification" since e.g. 2/5 could be represented as 4/10 but that would require a 10 digit (not allowed). So presumably in generation I would need to pick at least one of the fractions with a denominator <=4 (and that one would get a multiplier, e.g. 2/3 2 => 4/6 or 2/3 3 => 6/9)?

[jonathanolson]

So for e.g. shapes (unmixed) level 2, it's essentially pick 3 from (1/2, 1/3, 1/4, 1/5, 2/3, 2/4, 2/5, 3/4, 3/5, 4/5), but also "2 possible ways to make at least one of the targets".

Design doc

Level 2: -- Choosing from a distribution of fractions ranging from 1/2 to 4/5. The numerator can be 1, 2, 3, or 4 and the denominator could be 2, 3, 4, or 5 with the stipulation that the fraction is always less than 1. --No "wholes" in the shapes piles. --2 possible ways to make at least one of the targets

Given that it WAS doing searches only up to denominators of 8 for that level, things get tricky if it picks e.g. 2/5, 3/5, 4/5. Thus we already have 9 1/5ths for the generation, and the "find another way to make one of the targets" can only use 1/5ths since 1/10ths aren't allowed.

For this type of challenge, should it be constrained to pick a sampling of denominators?

Additionally, for "2 possible ways to make at least one of the targets", it should presumably avoid larger denominators? Or can we allow 1/10ths in cases like this? (The Java implementation was limited in searches up to 1/8ths, but the HTML implementation can handle arbitrary denominators)

[jonathanolson]

For shapes unmixed level 2, make sure at least target has denominator <=4, and generate interesting fractions from denominator <=4 that is NOT identical to the straightforward fractions.

[jonathanolson]

Only allow up to denominator 8 in shape levels (for pieces)

[jonathanolson]

I believe the specified limits should be in place.

[jonathanolson]

Both of the game screens should be in https://phet-dev.colorado.edu/html/build-a-fraction/1.0.0-dev.12/phet/build-a-fraction_en_phet.html so I only published one dev version for testing.

Also level 3 (unmixed) shapes doesn't seem fully compatible with the given instructions. It includes taking a sample of fractions up to a denominator of 6, but then says that there should be multiple solutions for ALL fractions (which seems impossible for, e.g. 1/6).

[ariel-phet]

Will use :computer: for implemented items (AP will erase comments noting implemented) Will use :heavy_check_mark: to note if tested and checked on master

Unmixed "Number" challenges

(Shapes as targets, number cards as answers)

All Levels

1. Target shapes should be larger when possible (even if on other screens shapes need to be smaller to fit two shapes) :computer: :heavy_check_mark:
2. Target box shapes are shifting in size, they should be a constant size and position ideally (looks odd when refreshing a game level) :computer: :heavy_check_mark:
3. All challenge types -- after I complete a level I get the "cheering", in Java we use sort of a "bahh-bahmm" sound. The cheering seems associated with reward node (when we rain down fractions), and the Java level complete sound seems nicer, more succinct, and more appropriate for simply finishing a level -- if it is easy to use. :computer: :heavy_check_mark:

Level 3

1. Design doc stipulates that there "could" be multiple ways to construct targets, I interpret this stipulation as not every target needs multiple ways, but there are a few that could be done multiple ways. :computer: :heavy_check_mark:
2. However, not necessarily seeing a major downside, except some of the numbers get big quickly for this low of a level, Java seems to limit the highest card value to 9. Will discuss :computer: :heavy_check_mark:
3. Card value now limited to 9, seems to fix concerns :computer: :heavy_check_mark:

Level 5

1. Denominator should range 1-9 (seeing 10 & 11 appear) :computer: :heavy_check_mark:
2. Fraction should always be less than 1 (according to design doc), seeing lots of fractions equal to 1 appearing. Looks like this is the same behavior in Java. Going to modify the design doc, but I think we should stipulate no more than 2 targets are equal to one. :computer: :heavy_check_mark:

Level 6

1. Denominator should range 1-9 (seeing 10 & 11 appear) :computer: :heavy_check_mark:
2. Java seems to limit number card value to 9, two digit number might be OK since now level 6. Will discuss :heavy_check_mark:

Level 7

1. Seems correct but the design doc stipulates "Always displaying the simplified fraction as the picture." Currently neither Java nor HTML5 always shows the simplified fraction (for instance sometimes showing pictures like 2/4 instead of just a 1/2 representation). Seems like it would be nice to go with the original design intent. :computer: :heavy_check_mark:

Level 9

1. Java constrains these to shapes with a max number of partitions of 9, I think that is a good usability constraint (more partitions become tougher to parse/read) :computer: :heavy_check_mark:

Level 10

1. Looks correct, but again, Java constrains these to shapes with a max number of partitions of 9, I think that is a good usability constraint. :computer: :heavy_check_mark:
   
   

Unmixed "Shapes" challenges

(Numbers as targets, shape pieces for constructing answers)

All Levels

1. Target containers shift up and down depending on the size of shapes container at the bottom of the screen...target containers should probably have a reasonably fixed layout. :computer: :heavy_check_mark:
2. Target numbers could be a bit larger (might be nice if being projected or such) :computer: :heavy_check_mark:

Level 3

1. "Whole" shapes (for instance an entire pie piece), seems to only be present for 1/1 (this is also the case in Java, but 1/1 and some other equivalent to 1/1 show up simulataneously more often in Java in my sampling, such as {1/1, 5/5} ) :computer: :heavy_check_mark:
2. Something seems to be giving more pieces than necessary, especially when numbers equal to 1 are targets, I think this is related to (1). So for instance 3/3 should be able to be made by 3 pieces that are 1/3 slices, or by a single whole. Right now, I see an over abundance of pieces. :heavy_check_mark:
3. Note Java seems a bit whacky as well, but gives whole shapes more often, and more of them :computer: :heavy_check_mark:
4. Also seeing sets of targets like {3/4, 5/6, 4/5} where there are 8 pieces that are 1/5 slices. Why? only 4 of those are useful. Is this coming from trying to find "two ways" to make 4/5? There are now still some extra pieces, but not causing any harm, fine to leave as is.

All else looking correct for Unmixed "Shapes" Challenges and matching design doc

[ariel-phet]

Will use :computer: for implemented items (AP will erase comments noting implemented) Will use :heavy_check_mark: to note if tested and checked on master

Mixed "Number" challenges

(Shapes as targets, number cards as answers)

Level 1

1. Refresh is recoloring, but not randomizing the order of targets :computer: :heavy_check_mark:

Level 5

1. Target shapes should have a maximum of 9 partitions (seeing some 10 for instance) :computer: :heavy_check_mark:
2. For the requirement that "1 of the representations requires fully simplifying to a solution" there appears to be a gap in the logic. For instance, I have a target that is 2 5/10, and the cards available make 2 2/4 (which is mathematically correct), but we want 2 1/2 in this case. :computer: :heavy_check_mark:
3. Requirement (2) seems not to always occur, for instance I have seen 1/6, 1/4, 5/9 as the fractional portions (none reducible). Or 1/4, 1/7, 5/9 as the fractional portion where no 4 card appeared. However there was a 2 and 8 card, so equivalent to 1/4 could be formed, but we want students to be reducing fractions, not making equivalents that are a multiple (on this level anyhow) :computer: :heavy_check_mark:

Level 6

1. Target shapes should have a maximum of 9 partitions (seeing some 10 for instance) :computer: :heavy_check_mark:
2. The requirement for two targets to be reducible might be being fulfilled, but the proper number cards are not available. For instance I see a fraction portion set of 2/6, 3/9, 4/7, 7/9, but there are not cards to form 1/3 :computer: :heavy_check_mark:
3. In Java at this level we allow a "random fill" in the sense of we have the fractional portion not necessarily as the last shape to the right. However you have introduced a "true random fill" where any shape can be filled up in random ways. I think we should reserve that behavior until level 8 :computer: :heavy_check_mark:

Level 7

1. Seems correct but target shapes should have a maximum of 9 partitions :computer: :heavy_check_mark:

Level 8

1. Target shapes should have a maximum of 9 partitions :computer: :heavy_check_mark:
2. Similar issues as Level 6. Here all 4 targets should require simplification of the fractional portion (ie 5/7 should never be a fractional portion). :computer: :heavy_check_mark:
3. I think this means the fractional portion must always be from the following set {2/4, 3/6, 4/8, 2/6, 3/9, 4/6, 6/9, 2/8, 6/8}. :computer: :heavy_check_mark:

Level 9

1. For this level, Java only has circles, squares, and rectangles as target shapes. However the design doc says "all representations possible". Since two of the targets have different internal partitions, circles, squares, and rectangles probably work best for those. But for the other two targets, that have equivalent internal divisions, it seems some other shapes could be used (like the six flower or really any other). Not a requirement, but would be fun on this level :computer: (added other representations for the other two targets, and the checkerboard: NOT sure what to do for the "rectangular" representation, since I don't have anything for it. It seems like it can't take the checkerboard style for this?) :heavy_check_mark:

Level 10

1. Java appears to have circles, squares, and rectangles. Here only squares and circles seemed to be used, and none of the "checkerboard" squares. Perhaps this was done to make everything have equal areas? But I do not feel that targets in Build a Fraction need or should have equal areas. In fraction matcher we are claiming "equivalence" of two shapes, so the area is important. Here we are just matching a numerical representation to a virtual shape representation. :computer: (added checkerboard, but again not sure what to do about "rectangular" representations. they look very similar and I honestly never noticed they had a slightly different shape) :heavy_check_mark:
   
   

Mixed "Shape" challenges

(Numbers as targets, shape pieces for constructing answers)

Level 1

1. Only wholes, 1/2's, and 1/4's to should be available to construct targets (1/3's and 1/6's showing up). The design doc says to have some extra pieces (but this means a few extra 1/2's or 1/4's or such) :computer: :heavy_check_mark:

Level 2

1. 1/6 pieces are showing up, should not be on this level. Again design doc says to have some extra pieces, but no 1/6 slices :computer: :heavy_check_mark:

Level 5

1. Seeing pieces beyond 1/8 pieces (such as 1/10 slices). Shape pieces should be limited to 1/8 at the "finest" partition level :computer: :heavy_check_mark:

Level 7

1. Looks like 7/8 was not included in the selection pool (stipulated in design doc, and does appear in Java) :computer: :heavy_check_mark:

Level 8

1. The "2 targets should require some nontrivial pieces" requirement doesn't seem to be quite holding. The main focus for "nontrivial" should be on the fractional portions. We might need to discuss, since for {1/5, 2/5, 3/5, 4/5} you are always going to be building with 1/5 pieces. We could remove 1/5's or stipulate that for when 1/5's appear there is some limit on the number of whole pieces. :computer: :heavy_check_mark:

[jonathanolson]

All challenge types -- after I complete a level I get the "cheering", in Java we use sort of a "bahh-bahmm" sound. The cheering seems associated with reward node (when we rain down fractions), and the Java level complete sound seems nicer, more succinct, and more appropriate for simply finishing a level -- if it is easy to use.

Is that https://github.com/phetsims/vegas/blob/master/sounds/trumpet.mp3? (It is marked in VEGAS code as the sound for "imperfect score"; should we look into those names internally?)

[jonathanolson]

To get alignment to be consistent, I'm planning on padding out less-wide shapes to take up as much room as the widest shapes we use. Thus for example, the two following screenshots have the exact same collection box locations:

Does that look ok?

[jonathanolson]

(Level 4 mixed numbers is useful for comparisons, since it uses pyramids).

[jonathanolson]

All numbers levels: Target shapes should be larger when possible (even if on other screens shapes need to be smaller to fit two shapes) Target box shapes are shifting in size, they should be a constant size and position ideally (looks odd when refreshing a game level)

This should be done. Each shape should take up the same "layout space", so there shouldn't be minor shifting due to that. In addition, the scale is now adaptive based on "mixed / unmixed 2wholes / unmixed 1whole" (0.6, 0.9 and 1.0 scales respectively).

This ends up scaling up the stroke width of the shapes, which doesn't look great to me. Should the lines stay the same width?

[jonathanolson]

Level 3 Design doc stipulates that there "could" be multiple ways to construct targets, I interpret this stipulation as not every target needs multiple ways, but there are a few that could be done multiple ways. However, not necessarily seeing a major downside, except some of the numbers get big quickly for this low of a level, Java seems to limit the highest card value to 9. Will discuss

Does this mean that things could be potentially simplified as 2/6 => 1/3, 3/6 => 1/2, 4/6 => 2/3? Will wait for more input on that level in particular.

[jonathanolson]

It's not the trumpet sound, but instead in Java trunk/simulations-java/common/games/data/games/audio/gameOver-perfectScore.wav.

[jonathanolson]

• [x] Use improved sound, move to vegas, talk to JB
• [x] Collection boxes/targets shouldn't shift vertically, allow room for stacks of 10 worth of panel below
• [x] Use a specific (old) padding between shape target partitions
• [x] Resize shapes so they have approximately the same width. 6-flowers not too big --- size up to a given maximum width OR height
• [x] Collection boxes are positioned as if the widest shape is used (allow empty space on the right)
• [x] Make the stroke sizes the same across shape target displays
• [x] Add in these representations where possible (if design doc doesn't specify representations): Grid 4 and grid 9 Flowers 6 and hexagons for 7 and pyramid for 9 or 8-star and flowers for 5

[jonathanolson]

Looks like 7/8 was not included in the selection pool (stipulated in design doc, and does appear in Java)

Interesting. It looks like the "ignore levels with 10+ in a stack and regenerate" condition is definitely changing the distribution here.

I've changed the implementation of the piece generation to better match the spec: for each of the two fractions, it gives one set of "straightforward" pieces (e.g. 7/8 => 7x 1/8), and it also gives one set of "difficult" pieces (an interesting mix of fractions usually used for level 9/10).

Due to the chance of the difficult mix for each having 4x+ 1/8 pieces, 7/8 isn't quite as common, but it will definitely occur now.

[jonathanolson]

Mixed Shape level 8:

The "2 targets should require some nontrivial pieces" requirement doesn't seem to be quite holding. The main focus for "nontrivial" should be on the fractional portions. We might need to discuss, since for {1/5, 2/5, 3/5, 4/5} you are always going to be building with 1/5 pieces. We could remove 1/5's or stipulate that for when 1/5's appear there is some limit on the number of whole pieces.

I've changed the selection of fractions so that there are at least 2 ones with "splittable" denominators (<=4). It definitely still is splitting the whole pieces, and that would make it difficult to not use nontrivial pieces. Are there particular examples of how we want things to behave?

[ariel-phet]

Looks like all issues have been addressed! Nice work @jonathanolson :tada: :tada: :tada:

Closing

[samreid]

There are still TODOs marked for this issue, discovered during https://github.com/phetsims/chipper/issues/946

[samreid]

The TODO is:

    // TODO: see decision on https://github.com/phetsims/fractions-common/issues/8, what to do if we lack the
    // number of breakable bits?
    // assert && assert( breakable.length >= quantity );

Unassigning until we return focus to this issue.