Model and decimals in sim screens #57

kathy-phet · 2018-06-13T17:22:47Z

This issue is broken off for a separate discussion reflecting on Hooke's law screens. Below is the initial context that initiated the discussion. But in the next comment I will try to summarize what I am seeing as the differences in the screens and the place value needs.

@kathy-phet wrote:

(Question for Amy): Re significant digits. In playing with this screen and thinking about taking data, I think we need to look even deeper at the significant digits. I like the new snappiness of the position control. Does it need to have 3 digits in this control? Also an issue with three digits in this control is that force is only read out to two digits - so it does not have enough sig figs to register the change from 0.350 to 0.351 or 0.034 in position. There is a fundamental change in this particular screen because we are now adjusting position, not force as in the prior screens.

@pixelzoom replied:

The number of decimal places was carefully chose so that no controls or interactions feel to “coarse”. If you reduce the number of decimal places in displacement (for example), the applied force is going to move in big jumps in some of the screens. Also beware that this sim allows changing all 3 variables in the equation F = kx. So the number of decimal places need to be compatible across all quantities, or we will end up with loops in the model — which I spent 8+ hours investigating and fixing for displacement only today. And “loops” were never an issue until we had to consider the PhET-iO data stream. Which is related to your next bullet.

pixelzoom · 2018-06-13T17:27:38Z

Specifically, this issue was broken off from https://github.com/phetsims/phet-io-wrapper-hookes-law-energy/issues/2#issuecomment-396770874.

pixelzoom · 2018-06-13T17:28:47Z

@kathy-phet also note that there's a more general issue that discusses the topic of "number of decimal places" as related to the PhET-iO message stream. See https://github.com/phetsims/phet-io/issues/1332.

kathy-phet · 2018-06-13T17:43:54Z

Here is a summary of how I am thinking about these screens.

Screen 1:
Here the primary controls are F and k. Displacement is the responding to these slider values.
F is constrained to an integer (1,2,3,.... )
k is constrained to the tens value (100, 110, 120, ...)
Displacement should be the calculated value from x = F/k. And x value needs 3 decimal places because these nice F and k values can divide in such that 3 decimals are needed to capture the value well enough to graph and show the relationship.
Model value will have many decimal places ... displayed value will have 3 decimal places.

One model complication I don't fully follow on this screen is that position is adjustable with the arm, but F should always be the exact integer value shown since it is on the slider and that is exact. So I am not sure how the model is working here.

Screen 2:
Similar behavior and decimal needs as to Screen 1.

Screen 3:
Here we are controlling different parameters, and so what is the dependent and independent variables have changed.
x is now determined by our control all the time (whether slider or arm), and is constrained to be nice steps so as to make it easy to do a controlled experiment (this is pedagogically very useful). It should never need to be anything other than what it is set at and should not be calculated from F and k.
x really only needs 2 decimal places here 0.20. (snappy by 0.05, tweaky by 0.01)
x in the display can be 0.20. x in the model is set to be exactly 0.2000000 (or however many digits there are), but it is not calculated and cannot change.

k is also similarly defined with a set number of digits (100, 110) should not need to be calculated.

F is now the dependent term and should be directly calculated from k and x.
F=kx.
If k can be 110 and x can be 0.21, F is not expected to be a "nice integer number" and it would be best if it is displayed with 3 digits.
F=XX.X in the display. F in the model has many digits.

I guess I am seeing 2 different model variants depending on the screen - one where x=F/k and one where F=kx. How does the third screen work right now? where F is now the calculated value, not the controlled/set value?

Apologies for not having much bandwidth to discuss this today - but I wanted to put these thoughts down for Amy and Christ to look over.

arouinfar · 2018-06-13T18:39:39Z

Displacement definitely needs three decimal places on all three screens, otherwise some interactions will feel coarse, as @pixelzoom described.

We consistently display the same number of decimal places across all screens. I believe we made the decision of how many decimals to display was based on the interaction pattern of the first two screens (user-controlled F and k).

@kathy-phet raises some really great points about the third screen. I do not think there is any pedagogical advantage to controlling x in 0.001 m steps. We could kill the third decimal place altogether, and have the thumb/arm snap to 0.05 m steps, and use the tweaker to adjust by 0.01 m.

When x is small, increasing k results in F increasing in jumps, regardless of whether x has two or three decimals. Since F is the derived quantity on this screen, it would benefit from an additional digit.

I would vote for:

Leave sig figs on Intro & Systems as they are
On Energy, reduce displacement to two decimals. The thumb/arm snaps to the nearest 0.05 m, and the tweaker adjusts in 0.01 m steps.
On Energy, display Applied Force to the nearest tenths place.

@pixelzoom I'd m also curious about this question:

I guess I am seeing 2 different model variants depending on the screen - one where x=F/k and one where F=kx. How does the third screen work right now? where F is now the calculated value, not the controlled/set value?

On the Energy screen, does the model calculate F from the user-controlled x and k?

pixelzoom · 2018-06-13T18:54:21Z

@arouinfar asked:

On the Energy screen, does the model calculate F from the user-controlled x and k?

Intro and Systems screens: Changing x solves for F. Changing F or k solves for x.
Energy screen: Changing x or k solves for F. Changing F solves for x.

pixelzoom · 2018-06-13T19:01:24Z

@arouinfar wrote:

• Leave sig figs on Intro & Systems as they are

The current implementation uses the same sig figs throughout all screens. Changing so that one screen (Energy) can be different will be nontrivial.

• On Energy, reduce displacement to two decimals.
• On Energy, display Applied Force to the nearest tenths place.

As written, this seems to suggest that we constrain displacement in the model, but constrain applied force only in the view ("display"). Is that what you intended? I want to be very clear that model vs view constraint are very different things. Constraining anything in the model typically leads to more floating-point errors.

kathy-phet · 2018-06-13T19:08:01Z

Energy screen: Changing x or k solves for F. Changing F solves for x.

Why do you need a changing F solves for x on this screen? x is fixed by the slider/model value?

arouinfar · 2018-06-13T19:30:23Z

Energy screen: Changing x or k solves for F. Changing F solves for x.

@pixelzoom it's unclear to me how a user could directly change F. The user can move the arm (which changes x) or adjust the k or x sliders.

The current implementation uses the same sig figs throughout all screens. Changing so that one screen (Energy) can be different will be nontrivial.

An alternative would be:

Displacement always has three decimal places. On the Energy screen, the 3rd decimal place would be 0 because the thumb/arm snaps to 0.05 m steps, and the tweaker would adjust in steps of 0.01 m.
Applied Force always has one decimal place. On Intro & Systems, the decimal would be 0 because F is adjusted in 1 N increments.
Spring Force would also need one decimal place to match Applied Force, otherwise things look strange.

As written, this seems to suggest that we constrain displacement in the model, but constrain applied force only in the view ("display"). Is that what you intended?

I'm not sure I completely follow @pixelzoom. Doesn't the Displacement slider set the value of the x in the model? The Applied Force is then calculated, and its displayed value is rounded to the nearest tenths place.

pixelzoom · 2018-06-15T00:19:17Z

About the Energy screen...

@kathy-phet asked:

Why do you need a changing F solves for x on this screen? x is fixed by the slider/model value?

@arouinfar said:

I'm not sure I completely follow @pixelzoom. ...

Sorry, let me try explaining again.

All screens use the same model code. In the model, changing x computes F; changing F computes x. The model has an option that indicates which parameter is computed when k changes. In the first 2 screens, changing k computes x. In the Energy screen, changing k computes F.

In the Energy screen, there is no direct control of F, so the "changing F computes x" part of the model is not exercised. But it's still part of the model code.

pixelzoom · 2018-06-15T00:35:10Z

@arouinfar asked:

I'm not sure I completely follow @pixelzoom. Doesn't the Displacement slider set the value of the x in the model? The Applied Force is then calculated, and its displayed value is rounded to the nearest tenths place.

Correct, the displacement slider and robotic arm are both constrained to set x to values with at most 3 decimal places. So when interacting with the displacement slider or robotic arm, x values will have 3 decimal places in the model.

But values computed by the model (e.g. F is computed when dragging the robot arm changes x) are not similarly constrained to any number of decimal places, and computed values may contain floating-point error. If you want to constrain all model values to the same number of decimal places shown in the view, that is different (and more difficult) than simply controlling the number of decimal places used by view components to control and display values.

kathy-phet · 2018-06-18T18:22:22Z

I don’t want the model to display fewer decimals nor for PhET-io model values to be fewer decimals, but when the slider is set to 0.130, can you not have that set the model to 0.130000000 exactly? So all model position values have decimals that are 0 down the line? I agree F would have some non zeros down at the smallest decimals because of calculations, but not sure why x would need to. Kathy

…

Sent from my iPhone On Jun 14, 2018, at 6:35 PM, Chris Malley <notifications@github.com<mailto:notifications@github.com>> wrote: @arouinfar<https://github.com/arouinfar> asked: I'm not sure I completely follow @pixelzoom<https://github.com/pixelzoom>. Doesn't the Displacement slider set the value of the x in the model? The Applied Force is then calculated, and its displayed value is rounded to the nearest tenths place. Correct, the displacement slider and robotic arm are both constrained to set x to values with at most 3 decimal places. So when interacting with the displacement slider or robotic arm, x values will have 3 decimal places in the model. But the value computed by the model (e.g. F when dragging the robot arm) is not similarly constrained to any number of decimal places, and the computed value may contain floating-point error. If you want to contain all model values to the same number of decimal places shown in the view, that is different (and more difficult) than simply controlling the number of decimal places used by view components to control and display values. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#57 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AE3FZB2QjYYeMkNCTeqiKwiX9eBfIiwjks5t8wE-gaJpZM4UmnOo>.

pixelzoom · 2018-06-18T18:43:17Z

I don’t want the model to display fewer decimals nor for PhET-io model values to be fewer decimals, but when the slider is set to 0.130, can you not have that set the model to 0.130000000 exactly?

UI controls do set their associated Properties to exact values. But as I stated above: ... values computed by the model (e.g. F is computed when dragging the robot arm changes x) are not similarly constrained to any number of decimal places, and computed values may contain floating-point error.

I agree F would have some non zeros down at the smallest decimals because of calculations, but not sure why x would need to.

If you drag a control that changes F, x will be computed. And depending on the values of F and k, x may contain some floating point error.

In Javascript:
0.1 + 0.2 = 0.30000000000000004
0.05 + 0.01 = 0.060000000000000005
Really.

kathy-phet · 2018-06-18T23:48:14Z

On the third screen can we disable the recalculation of x. When k changes only F should change. x should not be calculated or changed on this screen, it should be fixed by the slider position only. Kathy

…

Sent from my iPhone On Jun 18, 2018, at 12:43 PM, Chris Malley <notifications@github.com<mailto:notifications@github.com>> wrote: don’t want the model to display fewer decimals nor for PhET-io model values to be fewer decimals, but when the slider is set to 0.130, can you not have that set the model to 0.130000000 exactly? UI controls do set their associated Properties to exact values. But as I stated above: ... values computed by the model (e.g. F is computed when dragging the robot arm changes x) are not similarly constrained to any number of decimal places, and computed values may contain floating-point error. I agree F would have some non zeros down at the smallest decimals because of calculations, but not sure why x would need to. If you drag a control that changes F, x will be computed. And depending on the values of F and k, x may contain some floating point error. In Javascript .05 + .01 = 0.060000000000000005. Really. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#57 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AE3FZB56AosfgPdASV2vBYfK_i90z2Gaks5t9_TGgaJpZM4UmnOo>.

pixelzoom · 2018-06-18T23:48:28Z

In case anyone is interested in where Javascript floating-point error comes from... This is the simplest explanation that I've been able to find: https://modernweb.com/what-every-javascript-developer-should-know-about-floating-points/.

pixelzoom · 2018-06-18T23:49:24Z

@kathy-phet I'm not at all clear on what problem (specifically) you're trying to solve.

Signed-off-by: Chris Malley <cmalley@pixelzoom.com>

pixelzoom · 2018-06-19T00:11:35Z

When a NumberProperty value in the model changes, its value is now printed to the browser console if you use the ?log query parameter.

There are 2 NumberProperties that (when computed) contain floating-point error that makes them have more decimal places than desired. Those 2 Properties are appliedForceProperty (F) and leftProperty (position of the left end of the robotic arm). So I'm perplexed about why we need to "disable the recalculation of x" in the Energy screen when I see no such recalculation of displacement occurring (that was addressed in #52 (comment)) and all values for displacement (in all screens) appear to have the desired number of decimal places (max 3).

Signed-off-by: Chris Malley <cmalley@pixelzoom.com>

kathy-phet · 2018-06-19T03:51:31Z

I will look again. Goal was to stop the recursion but if it is not being recalculated it should be fine. I thought I saw recursion still when using position tweakers but I will look again when I can. Are the position tweakers at 0.01 steps now? K

…

Sent from my iPhone On Jun 18, 2018, at 6:11 PM, Chris Malley <notifications@github.com<mailto:notifications@github.com>> wrote: When a NumberProperty value in the model change, its value is now printed to the browser console if you use the ?log query parameter. There are 2 Properties that (when computed) contain floating-point error that makes them have more decimal places than desired. Those 2 Properties are appliedForceProperty (F) and leftProperty (position of the left end of the robotic arm). So I'm perplexed about why we need to "disable the recalculation of x" when I see no such recalculation of displacement occurring (that was addressed in #52 (comment)<#52 (comment)>) and all values for displacement appear to have the desired number of decimal places (max 3). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#57 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AE3FZNJMpZPM_HQYdVXKDUoBmgxOdy01ks5t-EG3gaJpZM4UmnOo>.

pixelzoom · 2018-06-19T15:55:29Z

I really think we should table this issue until we can have a real discussion. Getting fragmented/unclear feedback based on no specific version is making me a little crazy and does not feel productive.

pixelzoom · 2018-07-18T15:40:24Z

Unassigning until we resume work on Hooke's Law.

pixelzoom · 2018-08-16T20:27:55Z

8/16/18 design meeting:

We met about this. I'm going to undo the constraints on the model, and revisit this.

pixelzoom · 2018-08-18T17:07:46Z

In 8/16/18 design meeting, we decided that it unnecessary to constrain the number of decimal places in the model, and that it was OK to show model values (including possible floating point errors) in the PhET-iO data stream. To that end, I removed such constrains in #52 (comment). This addresses the problems that @arouinfar reported in #57 (comment).

In #60, we revised the intervals for slider thumbs and tweakers, the number of decimal places shown for values and tick marks, etc. Since this issue was originally about that topic, and has now been addressed, I'm going to close this issue.

pixelzoom · 2018-08-18T18:40:03Z

Reopening. There are still some problems here. For example, we added a decimal place to Spring Force. Shouldn't we then add an additional decimal place to Spring Force components for the parallel system?

…ceDelta, #57 Signed-off-by: Chris Malley <cmalley@pixelzoom.com>

…57 Signed-off-by: Chris Malley <cmalley@pixelzoom.com>

pixelzoom · 2018-08-18T21:15:01Z

Model value constraints have been removed, the number of decimals for displayed values has been revised, and the slider/tweaker intervals have been revised.

Here are the current values, as implemented in HookesLawConstants:

    // number of decimal places for displayed values
    APPLIED_FORCE_DECIMAL_PLACES: 1,
    SPRING_FORCE_DECIMAL_PLACES: 1,
    SERIES_SPRING_FORCE_COMPONENTS_DECIMAL_PLACES: 1, // series system
    PARALLEL_SPRING_FORCE_COMPONENTS_DECIMAL_PLACES: 2, // parallel system
    SPRING_CONSTANT_DECIMAL_PLACES: 0,
    DISPLACEMENT_DECIMAL_PLACES: 3,
    ENERGY_DECIMAL_PLACES: 1,

    // slider thumb intervals
    APPLIED_FORCE_THUMB_INTERVAL: 5, // N
    SPRING_CONSTANT_THUMB_INTERVAL: 10, // N/m
    DISPLACEMENT_THUMB_INTERVAL: 0.05, // m

    // tweaker intervals
    APPLIED_FORCE_TWEAKER_INTERVAL: 1, // N
    SPRING_CONSTANT_TWEAKER_INTERVAL: 1, // N/m
    DISPLACEMENT_TWEAKER_INTERVAL: 0.01, // m

    // drag intervals
    ROBOTIC_ARM_DISPLACEMENT_INTERVAL: 0.05, // m, Energy screen only, see #54

These changes are present in 1.1.0-dev.12. @arouinfar please review.

Here's a scenario that feels a little weird, but is not incorrect based on the number of decimal places that we've chosen. Verify that you're OK with this.

Go to Intro screen.
Check the "Displacement" and "Values" checkboxes.
Set Spring Constant to 300 N/m.
Drag robotic arm as far to the right as possible, 0.333m.
Note that Applied Force is 99.9 N (300 * 0.333 = 99.9)
Press the right tweaker for Applied Force, setting it to 100 N.
Note that Displacement does not change. (100 / 300 = 0.33333333... = 0.333)

arouinfar · 2018-08-20T19:11:59Z

@pixelzoom the updated thumb/tweaker intervals all look good to me. Agreed that PARALLEL_SPRING_FORCE_COMPONENTS_DECIMAL_PLACES should be 2.

Here's a scenario that feels a little weird, but is not incorrect based on the number of decimal places that we've chosen. Verify that you're OK with this.

This is OK with me. It's a consequence of the precision limits, and the values are being correctly rounded. Thanks for checking!

pixelzoom · 2018-08-20T19:15:10Z

OK, we're done here. In summary, the model is unconstrained, and we revised the view.

pixelzoom · 2019-07-03T20:29:50Z

This change has not been published. So reopening and labeling with "fixed-awaiting-deploy".

pixelzoom · 2021-05-12T21:15:24Z

liammulh · 2021-05-12T22:25:25Z

See the above checklist for what's been verified. Reassigning @pixelzoom.

pixelzoom · 2021-05-12T22:32:44Z

Looks like everything passed, thanks @liam-mulhall. Closing.

pixelzoom added the design:phet-io label Jun 13, 2018

kathy-phet assigned pixelzoom and arouinfar Jun 13, 2018

arouinfar removed their assignment Jun 13, 2018

pixelzoom assigned kathy-phet and arouinfar and unassigned pixelzoom Jun 15, 2018

pixelzoom mentioned this issue Jun 18, 2018

Assertion failed: cannot start event while event is in progress #52

Closed

pixelzoom added a commit that referenced this issue Jun 19, 2018

log model NumberProperty values when they change - #52, #57

9aedfb3

Signed-off-by: Chris Malley <cmalley@pixelzoom.com>

pixelzoom added a commit that referenced this issue Jun 19, 2018

log Spring rightProperty - #52, #57

e8e0979

Signed-off-by: Chris Malley <cmalley@pixelzoom.com>

pixelzoom added a commit that referenced this issue Jun 19, 2018

doc #52, #57

b078725

Signed-off-by: Chris Malley <cmalley@pixelzoom.com>

pixelzoom added a commit that referenced this issue Jun 19, 2018

identify specific springs in log messages - #52, #57

32e2e88

Signed-off-by: Chris Malley <cmalley@pixelzoom.com>

pixelzoom removed their assignment Jul 18, 2018

pixelzoom mentioned this issue Jul 19, 2018

PhET-iO design phetsims/gas-properties#30

Closed

pixelzoom assigned pixelzoom and unassigned kathy-phet Aug 16, 2018

pixelzoom mentioned this issue Aug 16, 2018

revise sliders #60

Closed

7 tasks

pixelzoom closed this as completed Aug 18, 2018

pixelzoom reopened this Aug 18, 2018

pixelzoom added a commit that referenced this issue Aug 18, 2018

constrain force using appliedForceDecimalPlaces instead of appliedFor…

5710f67

…ceDelta, #57 Signed-off-by: Chris Malley <cmalley@pixelzoom.com>

pixelzoom added a commit that referenced this issue Aug 18, 2018

remove model constraint on number of decimal places in applied force, #…

0241bb7

…57 Signed-off-by: Chris Malley <cmalley@pixelzoom.com>

arouinfar self-assigned this Aug 20, 2018

arouinfar closed this as completed Aug 20, 2018

pixelzoom reopened this Jul 3, 2019

pixelzoom added status:fixed-awaiting-deploy and removed status:blocks-sim-publication labels Jul 3, 2019

pixelzoom unassigned pixelzoom and arouinfar Jul 3, 2019

liammulh assigned pixelzoom May 12, 2021

pixelzoom closed this as completed May 12, 2021

arouinfar mentioned this issue Jul 1, 2024

Additional decimal in applied force number display #90

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Model and decimals in sim screens #57

Model and decimals in sim screens #57

kathy-phet commented Jun 13, 2018 •

edited by pixelzoom

Loading

pixelzoom commented Jun 13, 2018

pixelzoom commented Jun 13, 2018

kathy-phet commented Jun 13, 2018

arouinfar commented Jun 13, 2018 •

edited

Loading

pixelzoom commented Jun 13, 2018

pixelzoom commented Jun 13, 2018 •

edited

Loading

kathy-phet commented Jun 13, 2018 •

edited

Loading

arouinfar commented Jun 13, 2018

pixelzoom commented Jun 15, 2018 •

edited

Loading

pixelzoom commented Jun 15, 2018 •

edited

Loading

kathy-phet commented Jun 18, 2018 via email

pixelzoom commented Jun 18, 2018 •

edited

Loading

kathy-phet commented Jun 18, 2018 via email

pixelzoom commented Jun 18, 2018

pixelzoom commented Jun 18, 2018

pixelzoom commented Jun 19, 2018 •

edited

Loading

kathy-phet commented Jun 19, 2018 via email

pixelzoom commented Jun 19, 2018

pixelzoom commented Jul 18, 2018

pixelzoom commented Aug 16, 2018

pixelzoom commented Aug 18, 2018

pixelzoom commented Aug 18, 2018

pixelzoom commented Aug 18, 2018 •

edited

Loading

arouinfar commented Aug 20, 2018

pixelzoom commented Aug 20, 2018

pixelzoom commented Jul 3, 2019

pixelzoom commented May 12, 2021 •

edited by liammulh

Loading

liammulh commented May 12, 2021

pixelzoom commented May 12, 2021

Model and decimals in sim screens #57

Model and decimals in sim screens #57

Comments

kathy-phet commented Jun 13, 2018 • edited by pixelzoom Loading

pixelzoom commented Jun 13, 2018

pixelzoom commented Jun 13, 2018

kathy-phet commented Jun 13, 2018

arouinfar commented Jun 13, 2018 • edited Loading

pixelzoom commented Jun 13, 2018

pixelzoom commented Jun 13, 2018 • edited Loading

kathy-phet commented Jun 13, 2018 • edited Loading

arouinfar commented Jun 13, 2018

pixelzoom commented Jun 15, 2018 • edited Loading

pixelzoom commented Jun 15, 2018 • edited Loading

kathy-phet commented Jun 18, 2018 via email

pixelzoom commented Jun 18, 2018 • edited Loading

kathy-phet commented Jun 18, 2018 via email

pixelzoom commented Jun 18, 2018

pixelzoom commented Jun 18, 2018

pixelzoom commented Jun 19, 2018 • edited Loading

kathy-phet commented Jun 19, 2018 via email

pixelzoom commented Jun 19, 2018

pixelzoom commented Jul 18, 2018

pixelzoom commented Aug 16, 2018

pixelzoom commented Aug 18, 2018

pixelzoom commented Aug 18, 2018

pixelzoom commented Aug 18, 2018 • edited Loading

arouinfar commented Aug 20, 2018

pixelzoom commented Aug 20, 2018

pixelzoom commented Jul 3, 2019

pixelzoom commented May 12, 2021 • edited by liammulh Loading

Intro Screen

Systems Screen

Energy Screen

liammulh commented May 12, 2021

pixelzoom commented May 12, 2021

kathy-phet commented Jun 13, 2018 •

edited by pixelzoom

Loading

arouinfar commented Jun 13, 2018 •

edited

Loading

pixelzoom commented Jun 13, 2018 •

edited

Loading

kathy-phet commented Jun 13, 2018 •

edited

Loading

pixelzoom commented Jun 15, 2018 •

edited

Loading

pixelzoom commented Jun 15, 2018 •

edited

Loading

pixelzoom commented Jun 18, 2018 •

edited

Loading

pixelzoom commented Jun 19, 2018 •

edited

Loading

pixelzoom commented Aug 18, 2018 •

edited

Loading

pixelzoom commented May 12, 2021 •

edited by liammulh

Loading