Thanks, Brian, primarily it was a fun thing (and simulation is not mathematically correct, only approximate) to do.
I agree with Jens (and you) that, at least for teaching Snap!, the way to go is - turtle geometry only.
Further down the (turtle/relative metrics) path, I want to ditch absolute metrics absolutely. (I know that the idea is too revolutionary for most adults).
What do I mean?
Take for example, MOVE 10 (steps). I want to get rid of idea of steps altogether and replace it by idea of relative size, e.g. for example 1/30th of Stage's longer side.
Why?
Because it is similar to the situation of cutting one big pizza so each of our 30 friends gets one little piece and nobody wants to really measure it in inches (or centimeters) or steps in case of Snap!, not to mention Scratch (or even ScratchJr) - so I ask you seriously: what can be more natural that using only relative metrics?
If anything, it should be based on the shorter side, so you can be sure that something smaller than 1 by 1 will fit.
But really, it should only be at the last moment that there is any fixed scale. A picture fits in a 1 by 1 square, and you don't worry about how big that is, and it might be different depending on where you render the picture -- the width of a roll of butcher paper if the picture is rendered by a floor turtle.
This is how the picture project in SICP 2.2.4 works.
But do you want this only for mathematical elegance, or are you arguing that there's a pedagogic virtue to it?
Right, this would prevent a simple MOVE 1 (if directed alongside the shorter side's direction) from going over the edge.
Yes, just in time of actually running a script. I love it that something like this has been proposed by a serious people who wrote the Structure and Interpretation of Computer Programming 2.2.4 (not that I was aware of it) and not just some silly user, like me, who insist on seeing things through the eyes of a five years old kid.
That's also my answer to your question about my motivation.
It's neither pedagogical per se (although my both parents were teachers and I did read pedagogical journals that my Dad was subscribed to), nor mathematical per se, but just a 'plain' 'childish' playfulness, I guess.
Now it is not possible to MOVE "one half of the stage" or "one third of the stage", because I must first calculate how many steps this is, when I really don't care how many steps this is, and it's not as entertaining/fun/playful as I wish it was
P.S.
I think that this idea was behind a project that I made some time ago and is listed besides one of yours among the featured projects (they are both on the last page, 3/3), titled "Following_the_fish":
Shouldn't a lot of these posts be split to a new topic?
like what happened here:
edit: by a lot of these posts i mean the ones suggesting we should get rid of the steps feature
No, because CENTER serves a pedagogic purpose: it promotes thinking in terms of vectors. The vector (0,0) doesn't completely fill that need, but the fact that you can drag a two-item list onto that input slot makes the point (sorry for the pun) even more forcefully.
Someday we'll work up the courage to have a mechanism for deprecated blocks in old projects, and we'll replace X POSITION and Y POSITION with a single POSITION block that reports a vector. Similarly, when we extended the MY block's input menu to include things like WIDTH, HEIGHT, LEFT, ... X ROTATION, ... I wanted to report vectors instead: BOUNDS, CORNERS (a list of two points), ROTATION CENTER, etc. @jens agreed in principle but thought we weren't fully ready to endorse vectors, and he also didn't want to construct a list that the user is probably just going to tear apart again. But someday.
STAGE LEFT etc. don't have that property, not unless we report a list of the left border as X and the current position as Y.
I don't think there's anything terribly wrong with adding those to the menu, but we're busy, and I don't see a big payoff.
I like your idea that someday you will "automagically" replace every "X POSITION" block used in existing projects by "ITEM <1> OF < POSITION >" very much. So, if STAGE LEFT block would report {X_of_left_border, Current_Y} list, the additional options to "MOVE TO < >" could be added and everyone would be happy !
!
?