There is a long-standing challenge I want to tackle, and I wonder if the affordances in Snap! will allow a solution. In teaching physics to this younger than 19, relationships between physical quantities come in two kinds: accumulation and constraint. Relationships where one quantity accumulates another are not too hard to represent elegantly in a number of computational environments, including Snap! (Translated, that means I’ve done it and am happy with the work in progress.)Constraint relationships on the other hand, I’ve not found an elegant solution to in the past decades. I’m not familiar with the imperative programming paradigm, and am hoping some of the structures in Snap! might afford an elegant solution( intelligibility to a reader who is not the author is a prime factor in determining elegance). The manual suggests there is hope.
A simple example of a constraint relationship is I=V/R. The divergence from functional coding lies in the “=“ which is not an assignment operator, but rather describes possible sets of values of I, V and R it represents an atemporal connection : given the values of any two, the third is determined. Vary any one of the three, and the possible values of the remaining pair are constrained. (There are 4 and 5 term constraint relationships as well, so an inelegant brute-force, procedural approach does not help: the “=“ sign in algebra is just too successful. )
In effect I’m trying to create a means of expressing such relationships in aw way that allows the environment to be used to explore the relationship, as a stepping stone or complement to an algebraic understanding of the relationship.
My question for anyone a more in -depth understanding of Snap! is whether this might be possible in the environment? I’m not asking for a solution, just some wise advice.
Assuming 3 variable case, create a reporter than determines which of its 3 inputs is blank and then assumes that is the value that needs to be reported and makes the appropriate calculation based on the other two values.
The block could look a bit like this
I'm sure this isn't what your asking for but it gives a concrete basis for further clarification of your requirements
Thanks for the quick reply. I’m new to Snap!, so everything helps. I did try to puit some linka in to some writing I did last time I parked this problem, but the forum does no love links pasted in the body. I’ll try the button above...
I’ll write more directly here later, about how I think this could play out in Snap!, but I’m very aware that I tend to think to code procedurally, which I think I might need to sidestep to crack this nut.
AARGH …still bans links. Ah well, if interested find Slow Thinking Physics, then from the root url /teachingPhysicsModelling/Mm13/ ,Mm14 and Mm11.
Pasting links and stuff isn't allowed until you've been active for a while (to slow down spammers)
https://www.slowthinkingphysics.space/teachingPhysicsModelling/Mm13/
https://www.slowthinkingphysics.space/teachingPhysicsModelling/Mm14/
https://www.slowthinkingphysics.space/teachingPhysicsModelling/Mm11/
Quite understandable - thanks for adding the links. Definitely above & beyond
Interesting; your pictures look as if you're conceptually building an analog computer! That is, a machine to solve differential equations, like Babbage's. Functions are first class in Snap!, so we should be able to build tools for that elegantly.
In particular, I commend to your attention the amazing SciSnap! library from Eckart Modrow.
As for constraints, there's a nice object-oriented solution in SICP 3.3.5 that can be directly reproduced in Snap!, or, since you say "imperative" in passing :~), maybe you'd like @qw23's Prolog in Snap!.
Thank you. I’m gaining confidence with Snap. But slowly, as is my way
- The idea is to enable thought experiments with physical quantities on screen. Then there are preferred forms of equations: a=F/m and I=V/R may be algebraically equivalent to F=ma and V=IR, but I think there are pedagogic reasons to prefer the former because of the physical resonances. These are connected with physical arrangements that you might set up, and the resulting connections between the physical quantities. These guide the thought experiments.
- The hope is that the code will provide some tools for thought: for contemplative manipulation to develop a visceral feeling for any constraint relationship.
- Taking I=V/R as an example, imagine setting up a simple loop: wires and a battery and a lamp. This can be reimagined as a constrained interplay between three characters: current, potential difference and resistance. (Physicists do lots of reimagining, and that should not be elided from a description of what’s being done). After some transients, usually glossed over in early work on circuits, a steady state is reached in which the current is set by the potential difference/ resistance. The constraint relationship then defines other permissible states, corresponding to different values of the three quantities. There are three independent quantities, so it is a three dimensional space that’s being explored. That’s quite hard to represent on a screen or even in my head. (The demands intensify if for relationships constraining more independent physical quantities.) How you might explore such a relationship on the laboratory bench-top suggests a fruitful simplification. In effect, you proceed pairwise: locking all except two variables, and then exploring how the selected pair are connected. (Conveniently, back to a two-dimensional, screen and paper friendly dimensionality). So, for example, fix the resistance and vary the potential difference and note how the current changes( or vice versa), or fix the current and vary the resistance and note how the potential difference changes(again, or vice versa). This pair wise approach works for relationships with more than three physical quantities.
- So, back to the outlines of a tool for thinking with. On stage and in the building blocks of the scripts, I’m hoping to be able to enable the following set of actions, as an interpretation of this kind exploration of the relationship.
- Select some physical quantities
- Assemble them into a constraint relationship
- select a pair of quantities, to vary either and see how the other quantity changes, The remaining quantities in the relationship should be locked.
- Select one quantity to vary, the other changes as fixed by the relationship.
- Select a different pair of quantities, and repeat until contentment sets in.
- I’d like to pick up on the analogue computer comparison. That’s certainly the case, the diagrams are a recasting of a Java app from the turn of the century which enabled a process for accumulation relationships similar to the one I’ve just described for constraint relationships. That is you could “wire up” variables and relationships graphically and then numerically integrate the resulting equations to see how what you’d build behaved( Java seemed like a good plan at the time…). As such it’s a moderately successful modelling system (Somewhat like Stella, but more elegant and better attuned to 8-14 year old children). What made that work was getting the right level of abstraction, and intelligible & fruitful building blocks. Working out if a similar set of good building blocks for constraint relationships is the target for this extended footle with Snap! (Maybe, somewhat later, these could be put together with a blocks to allow accumulation relationships.)
Of course you choose these forms because in most actual situations, including actual experiments in physics class, mass and resistance are constant. In principle, you could just as well have chosen m=F/a, but that would be less useful. So in practice you don't really have to worry about 3D visualizations.