Scratch Graphing Calculator

TheMonsterOfTheDeep

One of the strangest things about me is that I really like graphing calculators. Sometimes just for fun I go and graph things on Desmos - I find it fun to experiment with functions and see how they work and try to construct functions to do specific things.

If you didn't know, one of my largest and most active projects is FADS - a graphing calculator for terminal emulators (that support curses and unicode

).

Of course, one of the most interesting platforms to write a graphing calculator would be Scratch - which is exactly what I'm doing.

I actually haven't worked on this project in a month or two, but so far it has camera controls (panning and zooming) and also it has a list-based evaluation system that should make it possible to implement some sort of equation editor.

The main challenge in Scratch is creating a general expression evaluator that works quickly - mine is actually still quite slow. The reason is because the main way I know to graph is by evaluating an expression at a whole bunch of points and then connecting them. This, I think, is actually the only way to evaluate a function - if somebody has a better idea please tell me.

One improvement I plan to make is caching all the points that are evaluated, so that when panning the graph merely has to evaluate a small number of new points.

So…

Thoughts?
Suggestions?

gtoal

TheMonsterOfTheDeep wrote:
One of the strangest things about me is that I really like graphing calculators. Sometimes just for fun I go and graph things on Desmos - I find it fun to experiment with functions and see how they work and try to construct functions to do specific things.

If you didn't know, one of my largest and most active projects is FADS - a graphing calculator for terminal emulators (that support curses and unicode ).

Of course, one of the most interesting platforms to write a graphing calculator would be Scratch - which is exactly what I'm doing.

I actually haven't worked on this project in a month or two, but so far it has camera controls (panning and zooming) and also it has a list-based evaluation system that should make it possible to implement some sort of equation editor.

The main challenge in Scratch is creating a general expression evaluator that works quickly - mine is actually still quite slow. The reason is because the main way I know to graph is by evaluating an expression at a whole bunch of points and then connecting them. This, I think, is actually the only way to evaluate a function - if somebody has a better idea please tell me.

One improvement I plan to make is caching all the points that are evaluated, so that when panning the graph merely has to evaluate a small number of new points.

So…

Thoughts?
Suggestions?

Well, you *could* duplicate all the expression parsing and evaluation logic of scratch, and maybe even add your own programming language in order to enter more complex functions - but why do so much work and why make users learn another way of expressing equations? Much simpler just to tell them to edit the source of your project and change the block where the function is evaluated! You supply the harness and call the custom block that evaluates the function across a range of values, and they write the function. Easy.

TheMonsterOfTheDeep

gtoal wrote:
Well, you *could* duplicate all the expression parsing and evaluation logic of scratch, and maybe even add your own programming language in order to enter more complex functions - but why do so much work and why make users learn another way of expressing equations? Much simpler just to tell them to edit the source of your project and change the block where the function is evaluated! You supply the harness and call the custom block that evaluates the function across a range of values, and they write the function. Easy.

That is certainly an interesting idea!

However, I don't think I'm going to do that because the purpose of this project is not actually to make something useful.

Rather, I basically want to build a fully functional graphing calculator in Scratch as if I were programming in C (that is, the user does not need to edit the source code in order to modify the program). For whatever reason I want to build an entire interface from the ground up - I think the challenge is somewhat appealing.

Jonathan50

I don't know anything about graphing calculators, but what about doing as much analysis of the expression is possible without knowing the points in it's own pass and then executing it as many times as necessary? Similar to as done here.

Last edited by Jonathan50 (Nov. 4, 2016 02:17:47)

TheMonsterOfTheDeep

Jonathan50 wrote:
I don't know anything about graphing calculators, but what about doing as much analysis of the expression is possible without knowing the points in it's own pass and then executing it as many times as necessary? Similar to as done here.

Gosh I really need to learn Lisp

From what I can understand of that article, I'm already (trying to

) do that. If I understand right, it's saying evaluate expressions after they have been parsed. My evaluator right doesn't actually do any real parsing - it is entirely based on (a rather slow and ugly) stack system, where functions are listed on a stack and the whole stack is evaluated recursively. The only real parsing is determining which function to call.

Of course, I'm probably completely misunderstanding what that article is saying…

Jonathan50

TheMonsterOfTheDeep wrote:
From what I can understand of that article, I'm already (trying to ) do that. If I understand right, it's saying evaluate expressions after they have been parsed. My evaluator right doesn't actually do any real parsing - it is entirely based on (a rather slow and ugly) stack system, where functions are listed on a stack and the whole stack is evaluated recursively. The only real parsing is determining which function to call.

It does some stuff other than parsing before execution (dispatching on what type of expression it is, etc.). Btw, the page I linked to is a chapter of the book The Structure and Interpretation of Computer Programs.

I wonder if broadcasting would be faster than using IF THENs, because you can put a reporter in the BROADCAST AND WAIT block's input. And if you do still use IF THENs then putting STOP THIS SCRIPTs after the calls to EVALTO should make it a little faster because then it doesn't have to test for the functions tested for after the correct one is found.

Edit: I really doubt that broadcasting will be faster since, among other things, BROADCAST looks through all the scripts in your project to find the ones to run: https://github.com/LLK/scratch-flash/blob/3c1671b38e692637974c676064d140bc04957e36/src/interpreter/Interpreter.as#L583

(So the more scripts in your project the slower broadcasting is…)

Last edited by Jonathan50 (Nov. 4, 2016 02:44:27)

TheMonsterOfTheDeep

Jonathan50 wrote:
TheMonsterOfTheDeep wrote:
-snip-
It does some stuff other than parsing before execution (dispatching on what type of expression it is, etc.). Btw, the page I linked to is a chapter of the book The Structure and Interpretation of Computer Programs.

I wonder if broadcasting would be faster than using IF THENs, because you can put a reporter in the BROADCAST AND WAIT block's input. And if you do still use IF THENs then putting STOP THIS SCRIPTs after the calls to EVALTO should make it a little faster because then it doesn't have to test for the functions tested for after the correct one is found.

Edit: I really doubt that broadcasting will be faster since, among other things, BROADCAST looks through all the scripts in your project to find the ones to run: https://github.com/LLK/scratch-flash/blob/3c1671b38e692637974c676064d140bc04957e36/src/interpreter/Interpreter.as#L583

(So the more scripts in your project the slower broadcasting is…)

Ah, yes, it seems there are probably quite a few micro-optimizations to do, which might actually make a significant difference!

Hopefully I can work on this some this weekend.

CodeLegend

Beat you to it

but there's certainly room for improvement.

EDIT: Plus a lot of that project was just griffpatch's mathematical evaluator. There was really no point in making one when he had already done the dirty work - I just altered it slightly to run the same calculation repeatedly (without parsing again), and made a GUI. It also caches values, so it's quite fast.

EDIT 2: There's also some strange glitch-like behavior where there's a little hump on the graph dependent on the actual Scratch x-coordinate… bizarre.

Last edited by CodeLegend (Nov. 4, 2016 02:53:18)

TheMonsterOfTheDeep

CodeLegend wrote:
Beat you to it but there's certainly room for improvement.

EDIT: Plus a lot of that project was just griffpatch's mathematical evaluator. There was really no point in making one when he had already done the dirty work - I just altered it slightly to run the same calculation repeatedly (without parsing again), and made a GUI. It also caches values, so it's quite fast.

That is pretty good. I'm going to have to step up my game.

NickyNouse

You could try basing the number of points you calculate on the change in slope between 2 neighbor secant lines. So like this: http://i.imgur.com/oLLxrQcl.png

TheMonsterOfTheDeep

NickyNouse wrote:
You could try basing the number of points you calculate on the change in slope between 2 neighbor secant lines. So like this: http://i.imgur.com/oLLxrQcl.png

Yeah. The other (calculus-related

) thing would be to make sure it passed through all maxima / minima, but that might be a bit much…

NickyNouse

TheMonsterOfTheDeep wrote:
NickyNouse wrote:
You could try basing the number of points you calculate on the change in slope between 2 neighbor secant lines. So like this: http://i.imgur.com/oLLxrQcl.png
Yeah. The other (calculus-related ) thing would be to make sure it passed through all maxima / minima, but that might be a bit much…

is there a good way to do actual derivatives or do you just have to find limits?

TheMonsterOfTheDeep

NickyNouse wrote:
TheMonsterOfTheDeep wrote:
NickyNouse wrote:
You could try basing the number of points you calculate on the change in slope between 2 neighbor secant lines. So like this: http://i.imgur.com/oLLxrQcl.png
Yeah. The other (calculus-related ) thing would be to make sure it passed through all maxima / minima, but that might be a bit much…
is there a good way to do actual derivatives or do you just have to find limits?

It should be possible to find the derivative of any elementary function, and it should be pretty simple for most of them - just do the derivative of each expression recursively, so each function pretends as if both of its arguments are functions and then just does the chain rule.

The only (elementary) function that would seem to be hard to differentiate is f(x)^g(x), but I just did the math and it appears there is a pretty simple relationship:

This is, I guess, the most general form of the power rule…

Of course it would be nice to know when the function was of the form x^c or c^x so that a simpler, faster to evaluate function could be used instead.

chooper100

If you want another example of a graphical calculator, I made one not too long ago

Effectively, the way it worked was it converted the equation into a series of easily computable instructions.

Example:
2-4*(x+1)

a=x+1
b=4*a
c=2-b

The output of the equation would then be c (the actual system used identifiers like %2 though)

This was done by having 3 lists: data 1, data 2 and data 3

Data 1: Data 2: Data 3:
+ x 1
* 4 %1
- 2 %2

The way the instructions were generated was by using recursion to find brackets and evaluate them top down (so the most nested bracket was parsed first, then the next, etc.)
To parse brackets, I looped through the operations in BIDMAS order, searching for them and generating instructions for them

To deal with square root having positive and negative values, when evaluating instructions I used recursion to create a list of possible solutions for f(x), displaying the primary solution to f(x) as a solid line and other solutions as dotted lines

Hope I added some potential insight

CodeLegend

TheMonsterOfTheDeep wrote:
The only (elementary) function that would seem to be hard to differentiate is f(x)^g(x), but I just did the math and it appears there is a pretty simple relationship:

TheMonsterOfTheDeep wrote:
I just did the math

I'd like to know how you ‘just did’ this…

TheMonsterOfTheDeep

CodeLegend wrote:
TheMonsterOfTheDeep wrote:
The only (elementary) function that would seem to be hard to differentiate is f(x)^g(x), but I just did the math and it appears there is a pretty simple relationship:

TheMonsterOfTheDeep wrote:
I just did the math
I'd like to know how you ‘just did’ this…

gtoal

TheMonsterOfTheDeep wrote:
CodeLegend wrote:
Beat you to it but there's certainly room for improvement.

EDIT: Plus a lot of that project was just griffpatch's mathematical evaluator. There was really no point in making one when he had already done the dirty work - I just altered it slightly to run the same calculation repeatedly (without parsing again), and made a GUI. It also caches values, so it's quite fast.
That is pretty good. I'm going to have to step up my game.

do you want a parser/evaluator to hack?

https://scratch.mit.edu/projects/116441427/

CodeLegend

TheMonsterOfTheDeep wrote:
CodeLegend wrote:
TheMonsterOfTheDeep wrote:
The only (elementary) function that would seem to be hard to differentiate is f(x)^g(x), but I just did the math and it appears there is a pretty simple relationship:

TheMonsterOfTheDeep wrote:
I just did the math
I'd like to know how you ‘just did’ this…
-snip-

Ah, I know how to do everything past the first step but I didn't think to start that way.

gtoal

what's all this calculus about? I thought this was a numerical methods graphing calculator we were talking about, not a symbolic equation manipulator like Mathematica?

Isn't Simpson's Rule all you need? (“Add first to last, and to this add twice even, four times odd; by one sixth N then multiply, and the area is found, by God!”)

TheMonsterOfTheDeep

gtoal wrote:
what's all this calculus about? I thought this was a numerical methods graphing calculator we were talking about, not a symbolic equation manipulator like Mathematica?

Well technically the best way to graph would be to make sure that the graph went through all the maxima / minima, which I suppose *could* be found without calculus…

But in terms of derivatives, there's really no reason to *not* do them symbolically.

Discuss Scratch