Trig-based Coordinate Systems

[jwaters10]

More specifically, Snap, and other versions of BYOB, have 0 degrees programmed to be vertical. This is not a bug in of itself, but creates errors when applied to typical trigonometric equations. Ex:

X=R_Cos(theta) Y=R_Sin(Theta) Theta=(90-(90x/abs(x))+arcTan(Y/X)) // Works try it with any right triangle in all four quadrants.

If the sprite is pointed in any direction, and we press the upArrowKey, the code does not work properly.

if(upArrowKeyPressed) { changeXBy(Cos(Direction)) changeYBy(Sin(Direction)) }

The key mistake is that the Y changes by what the X should change by, and vice versa. According to the formulas taught in trigonometry, this should work. I have been using this program for years, and I have found a work around.

if(upArrowKeyPressed) { changeXBy(Cos(90-Direction)) changeYBy(Sin(90-Direction)) }

When this change is implemented, the sprite moves in the direction it is pointed.

While this works, its a clunky fix. I ended up using BYOB years ago to make an orbital simulation where the distance between the sprites affected the force of gravity, and the angle between them was the direction the were being accelerated in. All my logic was in polar coordinates, then I'd translate to rectangular before changing the X and Y velocities. I'd always need to use the (90-Theta) conversion factor to make use of the trig functions. As you may imagine, it got really convoluted doing high level math needing to pander to the limitations of BYOB.

However; I love snap, it offered an outlet for my creativity before I had the skill to code. I want it to be as simple and effective as possible. If 0 degrees was designated to be to the right, then all these problems would be fixed. Hope this helps.

[cycomachead]

I tend to agree with the position that traditional trig-based coordinate systems are nicer to work with, but that's because i also learned them first.

Unfortunately, there's not a 100% satisfactory solution to this problem -- we either must break existing projects, or add a setting to projects or Snap! to solve it in a built in way.

However, a nice(ish) and easy solution is that you can build your own library that is a wrapper around the direction reporter and the point in (direction) command to use traditional trig values. (Maybe we should include this as a library.)

[brianharvey]

Yeah, sadly, it's you and 1000 math teachers (I've heard from all of them personally) against 1,000,000 Scratch users.

[jwaters10]

Who can actually fix this though? It is definately a glitch if you have to implement a workaround. It definately would break all existing projects, but it would be easier to fix them than to work around this glitch in the first place. Snap is for inexperienced coders/game makers, and they barely understand trig anyway starting out. We need to make something as basic as trig work for those starting out.

[brianharvey]

Snap! is meant to provide a minimal platform in which experienced programmers can build anything they want. Teachers of many widely different subject will use it; we expect that teachers will write starter projects for their students, customized however that teacher wishes. This is not "a glitch." If you want ccw-from-east coordinates, more power to you! Write a starter project! (While you're at it, maybe you'll want to measure angles in radians; that's better for trig, too.)

Many of our users are even more inexperienced than you're imagining; they've never seen trig, and they're following a curriculum that doesn't depend on understanding or using trig.

What I found broken in Scratch->BYOB->Snap! was the lack of the Logo word and sentence primitives, LAST LETTER OF and so on. So I wrote a library with the blocks I wanted. If I found myself wanting to teach trig, I'd write a library for that too.

The people who can't be expected to write their own libraries are the kids coming up from Scratch, who aren't really comfortable defining blocks altogether. Those are the users for whom Snap! should feel comfortable right out of the box. I apologize for saying this in a snarkier and less detailed way two messages ago.

[jwaters10]

Hey so when you say "write a library," what do you mean? Also what is a starter project, and how would I go about leaning to make both those things? Im most intersted in helping to improve snap as a whole, how can I do that?

Also what is the benefit to having 0 degrees be up, and cw?

If I were somehow able to change snap as a whole, I would have settings that could be toggled that would allow a switch between degrees and radians, with degrees as default. Also perhaps a toggle for cw 0 degrees up and ccw 0 degrees right, with the convention taught in school as the default. Logically anyone that is using a trig function will probably refer to equations taught by there teacher, and found on the web. I see this as a glitch because its function does not correspond with what I was taught nor the common knowledge found on the internet, still I am open to input if you have a compelling reason why it should remain the same.

Also how does the hierarchy of power work with snap? If I want to get involved with development who do I talk to, and what skills do I need?

Thank you for addressing my concern properly, I was upset a little by how you closed the issue without addressing it, I found your snarky remark funny though :)

Thanks again

[towerofnix]

A Snap! library is an XML file that you can drag into Snap! to import custom blocks that you or someone else made. It's basically The Way to make portable custom blocks.

Hopefully this screenshot shows it all:

[jwaters10]

Yeah that totally helps! So how do I reach someone who actually has the power to make real changes to this program? It's ok to improve your own use of Snap! with libraries and such, but what good is our effort if it doesnt improve the whole?

I personally dont use Snap!. I am at a skill level with Java now that I can do more using a real language. However this program helped me to decide to be a programmer and I made some really cool stuff in byob. That said, I have no interest in making libraries or otherwise working to improve Snap! if it doesn't help the kids(and adults) who are just learning what it means to program.

[towerofnix]

So how do I reach someone who actually has the power to make real changes to this program?

You were talking to one of them just a few hours ago. :)

Jens does the actual programming, mostly, but I'm sure he'll see (the new updates on) this issue (or he has, and he's just stalking it right now).

Once everyone's come to an agreement of how to go about doing this (ha, ha..), if at all, making a pull request to this repository would probably be the best way to continue.

[brianharvey]

Ooh, "real language" is fighting words! Snap! is way more real than Java, since we have a proper λ and they just have an ugly kludge. Javascript is a real language, and of course Scheme is God's language.

"Hierarchy of power" is kind of funny -- we're not Linux, with thousands of contributors. Basically, Jens is the absolute czar of Snap! itself, and I guess I'm in charge of the library and the documentation, although Jens is the czar of those things too, when he wants to be.

There are, at this moment, 17,731,978 compelling reasons for using directions clockwise from North: that's how many Scratch projects are shared online. By the time I finish typing this paragraph there will be more reasons. (I am of course cheating a bit here; not all of those projects use absolute directions.)

I feel like you're just not getting it that different people have different needs. Most of our users don't know trig. The whole idea of turtle geometry (using motion and turning relative to the sprite's current position and direction, rather than absolute motion or directions) is that you can do pretty much anything without trig, which is hidden underneath an abstraction barrier. Anyone sophisticated enough to know trig is sophisticated enough to write Someone who is learning trig has a teacher (not necessarily in a school) who's sophisticated enough to write those blocks.

By the way, Scratch inherited the cw-from-North direction system from Logo, which took it from orienteering/cartography. The idea is that eight year olds don't know trig, but maybe they do know which way is North on a map. Our own audience is older than eight, but they do often know Scratch and we don't want to conflict with it.

So, why don't I just put those two blocks in a library? It's always a challenge to decide what to provide. We don't want to take away good programming problems by preempting them in a library. Sometimes, for subtle things, we end up deciding that using a certain capability is way easier than programming it, and so we gain more by making it widely available than we lose. The paradigmatic example is the higher order list functions MAP, KEEP, and COMBINE. Another good example is CATCH and THROW, which are implemented using first class continuations (another feature you won't find in "real" Java, by the way). In the case of the ccw-from-East blocks, they're so easy to write that I don't think it's worth a library, although I imagine trig teachers would provide them.

[jwaters10]

Hey I mean no slight in calling Java a "real language!" I simply meant that in the sense that Snap! is a gui, where as Java is a written language using an IDE.

Please explain map, keep, combine? I haven't brushed up on Snap! much since BYOB. Also I'm curious about how Snap! uses TRY CATCH and how it's different from Java?

How about you add a setting somewhere that creates a toggle for degrees/radians (that was a good idea), and a toggle for cw ccw mode, making the current system a default. That way the millions of existing projects arent ruined.

I literally didnt understand what a cosine was until I started using scratch when I was 14(thank you guys!), but 4 years later I took a precalculus class and had to completely redefine of understanding of trig. To this day, because the whole my understanding of trig is from Scratch and BYOB, I think Y=Rcos (Theta), which is wrong. It has been hard for me to relearn those equations, and I still second guess myself every time I must recall them.

And while it may be simple for you and I to understand how easy the work-around is, a year ago I didnt even understand that there was an inconsistancy, and I feel that for many people trying out a trig function for the first time would be discouraged to find that the most simple trig formulas dont work properly.

I guess my point is that correct functioning of the trig functions out of the box is more important than making a parallel between North and 0 for children. I think that the greatest purpose of Snap! is to prepare middle/high schoolers for a career as computer scientists, and that this program would best serve students by forcing them to conform to a coordinate system that will be familiar once they reach trig. Also you give people and high school teachers too much credit, they arent that smart :)

Still since I am talking to one of creators of Scratch, I would like to thank you for helping to create such a wonderful program! The use of this program has put me far ahead of my peers in both Java and Calculus, by allowing me to sharpen my algorithm making skills, as well as learn to make functions that are then drawn into fantastic and colorful shapes. You guys should make a program that conbines Snap! with a tutorial system that explains how to code in other languages.

[jwaters10]

Also compairing Snap! and Java is like compairing apples to oranges. Java runs on a billion devises, and is a powerful tool that runs on any devise, and can do many more things than Snap! can, you know that. Java is really confusing and frustrating, there are mazes of objects within objects, and filled with exceptions and syntax errors.

Snap! is very simple and not intimidating to use. Snap! is a tool that helped me ridiculously to acheive the modest coding tallent I have now. I think when I knew I was a big fish in a small pond, was when each time I added a block to my project in BYOB, it took ten seconds to load. I dont know if that problem still exists, but you may as well fix that too if you can. I think BYOB compiles as you go, each time you add a block. If you separated writing and running the code, it would be more stable as the number of IF statements reaches around 100. There are numerous confusing and powerful languages that do a ton of stuff, there is only one Snap!, thank you guys for helping make the step from not-code to code more doable!

Let me know if I can help you guys in any way other than just reporting bugs, I would love to help you guys out, and it'd be great to put something as well known as Snap! on my resume a couple years down the line. I have some experience in java, but I have an increadibly strong creative ability, and math ability as well, particularly at making new equations. I don't know if you guys could use my help, but I would be honered if you could.

Thanks

[brianharvey]

I have an increadibly strong creative ability

Modest, too! :-P

Sorry, couldn't resist.

Still since I am talking to one of creators of Scratch,

Jens, a bit, but not me. I've just been part of BYOB3 and Snap! (and Logo, long ago). But you probably meant Snap!, in which case, thank you! It's great to hear from satisfied users.

Snap! is faster than BYOB was, but neither is compiled, even while running. It's an interpreted language. Indeed compiling (probably to a bytecode that pretty much only has push, pop, call, and return instructions) would speed it up a lot, but at the cost of making it less "lively," in the sense that you can shove a block into a running script and it all works as expected.

Snap! runs on every device with a browser. It's not as fast as compiled Java code, but the only things it can't do come from the sandboxing that browsers apply to Javascript programs. A version of Snap! installed as a native desktop app (e.g., by loading with node.js) can, I believe, do anything Java or any other language can do. And do it more elegantly, because of first class functions.

I'm going to refer you to the reference manual (click on the Snap! logo, choose "Reference manual") for the higher order functions and the catch/throw implementation. Ask something more specific if you have questions after reading it.

If we were designing Snap! with no past history, we'd definitely use ccw-from-East directions. But... well, I've already said the "but" part.

You'd be interested in the Codification project under File>Open>Examples.

[jwaters10]

Would you at least consider/propose to Jens adding it to a setting within the program, and on the next build making it the default before any projects are uploaded? That way there is no harm done to current projects, and the issue is addressed.

Im not sure how hard this would be to do, but you could have another toggle where the program isnt running constantly, but is more similar to a traditional IDE where changes are made, then the program is run. As you said compile to byte code, and have a desktop evolution of Snap! that is much faster than the previous versions.

I made a gravity similation where two sprites orbited around each other, and one of them could be accelerated/decelerated/turned using arrow keys, but BYOB started bugging out as I insirted the last commands. I did nothing further with BYOB after that because I had reached the limit of the program, I knew I needed to move on to a faster language.

If you guys did this(I know its a huge idea) you could market it as a legitimate game development environment and make money. Since Snap! Runs on any device, it is the perfect environment to make games on. You could also make an android app that runs the project, one for each OS, then have each game individually in the app store for money or buy coins or whatnot. When they download the game, download the runtime environment at the same time.

Though I'm not familiar with the Snap! Interface, I can tell you its appealing. Perhaps the future of coding.... if you guys make this as fast and versitile as Java, while running on any device (as Java does), you guys could make big money, hire a big team, and be the creators of the next most advanced language. See how creative and greedy I am? Sadly all the money would be for you two.

Add support for devise independant peripherials, make one coded game run on apple/android-mac/windows/linux, or on all of them if they have a bluetooth keyboard. Even add support for bluetooth or wired controlers if you were able.

Anything that can be done with typed code can be done the the GUI that was designed by Jens. You guys can be some of the big players(bigger) if you just indulge in a little greed, ambition, and elbow greese :)

[jwaters10]

And what're first class functions? I read up on those a tad but didnt understand.

[jmoenig]

And what're first class functions? I read up on those a tad but didnt understand.

It's what Snap! is all about:

where map can be expressed as:

[towerofnix]

There are, at this moment, 17,731,978 compelling reasons for using directions clockwise from North: that's how many Scratch projects are shared online. By the time I finish typing this paragraph there will be more reasons. (I am of course cheating a bit here; not all of those projects use absolute directions.)

Excuse me for interrupting with something meta that's relevant only to a post that's been well progressed past, but you've actually only got 534 reasons according to Scratch's statistics - that's how many times a "point in direction" block was found from a random sample of... well, I'm not sure how many projects. I suppose that section of the statistics page isn't very helpful :)

[towerofnix]

Though I'm not familiar with the Snap! Interface, I can tell you its appealing. Perhaps the future of coding.... if you guys make this as fast and versitile as Java, while running on any device (as Java does), you guys could make big money, hire a big team, and be the creators of the next most advanced language. See how creative and greedy I am? Sadly all the money would be for you two.

Big money - how would that happen? A royalty on apps/games created (like UE4)?

Why a big team? I don't know how Snap! is really developed, of course, but I've always enjoyed making stuff like this (!) mostly either as the sole developer or with maybe one or two other people.

I'm just curious. I don't have the willpower to google any of this on Google, and I'm more interested in your answer anyways! :)

(Sorry for following a tangent even farther..!)

[brianharvey]

@liam4: Thanks, I didn't realize those statistics were available. But if I'm reading it right, the numbers are how many times the block was used in their sample, not the number of projects using it. So, 1% is actually a pretty big number -- an order of magnitude bigger than the percentage of POINT TOWARDS ___ blocks, for example. Probably half the projects start with when flag clicked point east and then never use the POINT IN DIRECTION block again, but that still means half the projects would be broken.

@jwaters10: Where do I start? First of all, you're not the first person to think about the direction issue. We've talked about a checkbox in settings repeatedly over the last eight years. It might happen eventually, just to shut up all the math teachers, but since the problem is solvable with a trivial library, our instinct is to minimize the number of settings. (It might not seem that way because Jens always makes settings to control new features, just in case they break something. If you shift-click the gear icon you'll see a bunch of no-longer-relevant checkboxes, e.g., one for zebra coloring. Some of the current checkboxes will be gone in 4.1.)

It's not just breaking old projects, which could indeed be solved by versioning -- although another goal is not to have a bloated code base, and project loading is slow enough already. It's also breaking old users of Scratch, who (like you, as you've said!) have the orienteering directions in their heads.

Making money isn't the object of the exercise. For one thing, there are already a dozen or so different extensions of Snap! made by other people for purposes from teaching graph theory to 3D printing to big data processing to robotics. Those people, most of whom didn't know us until after they built their languages, wouldn't have been able to do it if we had a restrictive code license. But also, we wouldn't have hundreds of thousands of users if they had to pay for the privilege. We want to rule the world, not to be rich. You know, imagine, program, share.

Compiling for speed would be nice, but it's a major project, especially if you want things like error messages to work properly (referring to the source code location of the error rather than the compiled code location). Eventually we'll get some grad student to do it as a thesis project, probably.

[bromagosa]

Making money isn't the object of the exercise. For one thing, there are already a dozen or so different extensions of Snap! made by other people for purposes from teaching graph theory to 3D printing to big data processing to robotics. Those people, most of whom didn't know us until after they built their languages, wouldn't have been able to do it if we had a restrictive code license. But also, we wouldn't have hundreds of thousands of users if they had to pay for the privilege. We want to rule the world, not to be rich. You know, imagine, program, share.

Totally agree, but let me add yet another argument to that. Snap! being a free software project is the single thing that made it possible for all these people to make a living out of it.

[brianharvey]

... although if anyone's going to make a living out of it, it should be Jens!

[jwaters10]

For the people who arent serious computer science majors in the making, it would be annoying and disadvantagous to change the direction system. Yet I see the higher calling of Snap! being to prepare budding engineers/computer scientists for the problem solving and critical thinking they will need for their careers. I think that the future engineers are more important than people that see Snap! as only a fun toy. That being said you are potentially training thousands of future engineers to have deeply engrained confusion about trig. I don't regret my experience with BYOB as a whole, but to this day I struggle to evaluate cos (0)=X. Conceptually BYOB did wonders for my understanding of both math and trig, and was the sole factor driving my life choice to become a software engineer. Yet algebraically is has crippled my ability to deal with simple trig functions. But dont feel too bad either haha, now that I'm coding in Java, X=X, and Y=-Y, meaning that as Y increases the object goes down the screen, you guys arent the only programmers who refuse mathematical conformity. I think that if every platform functioned exactly the same that it would make them all simpler to use.

And I know making it faster would be a huge project. As would adding support for a wide range of peripherials. But as far as monetizing it goes, you could make it free to use non-commercially, and charge a large sum for those who are making tons of money off you and Jens hard work. That way people could develop things for free, then purchase the licence when they're ready to publish.

[BookOwl]

But as far as monetizing it goes, you could make it free to use non-commercially, and charge a large sum for those who are making tons of money off you and Jens hard work.

I highly doubt that anybody is making tons of money off of Snap​!

[bromagosa]

This is digressing from a feature discussion to a political one. @jwaters10 would have probably closed the sources and charged for usage, but Snap! has a different perspective, and although possibly nobody's going to get awfully rich, maybe that wasn't the aim of the project in the first place.

The aim was to get people to learn computing, and trying to get people to learn computing while hiding away how your software works feels pretty dishonest to me.

Can we discuss politics somewhere else and stick to actual issues, bug reports and feature requests in GitHub?