Talk:Calculate: Difference between revisions
(→Implementation Discussion: graphing) |
m (Talk pages aren't (normally) categorized) |
||
Line 136: | Line 136: | ||
The graphing functionality is unfortunately lacking here. Do any of you know the Grapher program on Mac OS-X (I forget the name of the similar linux program). It is relatively simple and can export the graphs. Here, kids need to be able to take and plot data (rainfall, height, etc) as well as play with plotting in x-y. Then they need to add the plots to reports. Examples will be useful too. This program has great potential, especially in explaining Fourier analysis :) |
The graphing functionality is unfortunately lacking here. Do any of you know the Grapher program on Mac OS-X (I forget the name of the similar linux program). It is relatively simple and can export the graphs. Here, kids need to be able to take and plot data (rainfall, height, etc) as well as play with plotting in x-y. Then they need to add the plots to reports. Examples will be useful too. This program has great potential, especially in explaining Fourier analysis :) |
||
[[Category:Sugar]] |
|||
[[Category:Software]] |
|||
[[Category:Developers]] |
|||
[[Category:Mathematics]] |
Revision as of 08:50, 5 October 2008
Feature Requests
RPN mode needed for scientific calculations.--Mokurai 22:01, 19 May 2007 (EDT) (not sure whether this still applies to the new version Rwh 10:27, 15 July 2007 (EDT))
I suggest that a better solution would be to allow multistep calculations with saved 'variables'. This can do everything that RPN enables, but is easier to teach to children, closer to the global standard language of mathematics, and it leads directly to programming as a logical outgrowth of multistep calculations.
Integrate material from and link to Derivations of Applied Mathematics. -- Jpritikin 07:52, 9 September 2007 (EDT)
6 December 2007
The essential operational model (user interface) underlying RPN is an implicit stack with postfix operator application. Both of these conceptual models much more closely resemble typical programming paradigms in actual use, both at the machine level and higher levels of abstraction, than simplistic multistep variable saving scripts, which remind me of infantile "languages" like Basic or Cobol or similar such.
Keeping in mind that the goal is to provide a useful numerical tool for children, and bearing in mind that children, contrary to historical habit, are not imbeciles who need to be coddled, but rather intelligent conscious beings who simply have an unprejudiced blank slate to be filled, would it not be better to devise a calculator which fills that blank slate with the very best the world has to offer, in an intuitive compelling manner, and avoids dumping the same old trash that most of us have had to endure, sift through, and ultimately jettison?
With that in mind, and remembering that the physical limitations of commodity calculators are not in play, but rather a high resolution display with multiple megabytes of memory are at our disposal, I make the following suggestions:
1) Separate the keypad, display, and mode selection function keys into three separate windows which may be independently positioned (or hidden), and opened in multiple instances.
2) By all means, have a rudimentary operating mode suitable for the very youngest of children where the keypad displays only ten digits and four functions with the ancillary keys necessary to formulate an infix operator paradigm using a single display.
3) Provide a mode selection key to convert the key pad into optional prefix and postfix operator paradigms, after all, the goal is education and enlightenment, not sheltering, confining, and hiding the great diversity of truth.
4) When I work with typical calculator programs, I typically use three of four instances of the program to compute along three or four threads, and then cut and paste to merge the calculations in a fourth (or fifth) instance of the program. The point here is the singleton memory of typical calculator programs is inadequate for complex calculations, and the cheat I use quickly clutters the screen, apart from being inefficient, although it does obviate the need to use pencil and paper as an auxiliary memory.
With a separate display window, one need not replicate the keypad and mode keys. By including a mode key to create a new display, and by connecting a particular display to the keypad by clicking on it and highlighting the display, the cheat I use can be much more efficiently and elegantly implemented. As for memory, the stack paradigm can be intuitively and graphically mimicked and extended by imagining the display to be a single numeric window on a virtual "paper tape" connected in a loop under the window (a circular buffer implemented by a dynamic doubly linked list in programmer parlance). By putting a toggle widget on the side of the display, the window can be moved backward and forward to navigate previous intermediate results on the "tape". Better still, show one or two of those other results grayed out above and below the window. The keypad intuitively obviously only operates on the contents of the current window, and a visual model of stack, queue, and buffer operations is intuitively made available. In postfix mode (RPN) the value above the window can be colored instead of shaded, indicating it can also be operated upon, as well as eliminating the need to remember what the "entered" (stack) values are.
Beyond the intuitive appeal, the "paper tape" paradigm eliminates the need to define, name, and remember variables, making the whole interface easier to use for complex computations.
5) Finally, the same paper tape paradigm can be used in a keystroke window, which logs keystrokes, so that a complex calculation may be rerun with different data, once the first sequence is worked out.
6) Needless to say, there should be mode keys to expand the keypad for various more specialized computations, e.g. scientific, hexadecimal, statistical, complex numbers, or even quaternions, octonions, or vector operations.
Obviously all this can't be done in the first cut, but by using multiple windows to start with, a modular design paradigm is established which can easily accommodate future directions that none of us now can even imagine. Moreover, the design paradigm is intrinsically conceptually hierarchical, so a child can work at his or her own level, but always have the opportunity to grow and learn, and perhaps ultimately even customize the calculator for his or her own purposes.
To conclude, my main point here is to please, please avoid patronizing children. They are imaginative, extremely capable beings, and they will mirror whatever you show them. Give them mediocrity and that is what they will give in return, give them your best, and they will take that places no stodgy adult could ever imagine.
6 December 2007
- This is my own feelings about the above:
- RPN: my first exposure to RPN was in 1975-6 when the first HP pocket calculator appeared with it. It is okay for us engineers, but my wife hates it. It's totally natural for the technologist and absolutely not the way folks write equations. I believe that the TI graphing pocket calculators you see in classrooms (that my kids used, as a matter of fact) enter formulas the "normal" way.
- Graphing activity: What you do want is a graphing function, so the kids can learn about X-Y coordinates
- Spreadsheet activity: I'm not a developer. But I've been doing a lot of writing for wikipedia (see next post, too). I would suggest the simple "pocket calculator", but also a spreadsheet using relations/functions as well as typical non-RPN, somewhat akin to Excel. Apparently a simple spreadsheet is an activity to be designed for the future. I strongly encourage this. Most kids (e.g. my own and my nephews etc etc) in our schools by 7th grade if not earlier have encountered simple spreadsheet work.
- Request to change "square" to "exponent" or add a new exponent function : i.e. 3^3 = 27 rather than "square" causing 3^2 and the kid having to change the "2" to "3". (I had to discover that 3^3 would indeed evaluate correctly). I do understand that simple work around the Pythagorean theorem etc uses ^2 so there is an advantage to having a separate function "square".
- What's going on with the "Label" in the "algebra" function?: I don't see how this works, yet. I entered "x=3" in the "label" box, and 3+x into where the formula appears to go. It returns this into the box:
- x=3: 3+x Error at 2: Variable 'x' not defined.
- My guess all of this will evolve/resolve as developers set their minds to it. But perhaps some feedback such as this will be useful. Bill Wvbailey 17:21, 21 December 2007 (EST)
Boolean operations: request NOT
(3) I have some suggestions for the activity's functionality, but am not sure they should be here. I will enter them here anyway. The philosophy behind this is to provide the kids with the same symbolism and functionality that they will find on wikipedia.
(3a) The symbol | (stroke): Why use the "Sheffer stroke" for OR? this symbol was classically used for NAND (NOT AND). Why not use V for "von", the more classical symbol? I've never seen | used for OR.
(3b) Logical NOT: I was rather ... stunned shall we say ... to see XOR rather than NOT (i.e. ~ or "bent bar" 2-shift-alt, or whatever). XOR would be an okay addition but not without NOT; NOT is virtually mandatory. I am quite aware that the three functions chosen (AND, OR, XOR) are sufficient, but hey, so is NAND (stroke) by itself or NOR by itself or implication by itself -- and using them by themselves is ugly.
(3c) What happens when we plug in numbers not { 0, 1 }? The numerical results such as 3&4 => 4, and 3|4 => 3 are rather peculiar; they seem reversed (from a Venn-diagram point-of-view). For example, as "4" contains "3" we would expect that 3|4 might be "4". I will pursue this with my wikipedia cohorts to get their opinions. Usually Boolean functions have to do with predicates in particular "equality" that evaluate to { TRUE, FALSE } or values { 1, 0 }, e.g. =AND(3,4) yields TRUE in Excel.
Bill Wvbailey 14:19, 21 December 2007 (EST)
": I'm not sure about the other issues, but I assume the reason they chose the vertical bar for "or" is that a single vertical bar is traditionally used as the (binary, not logical!) "or" operator in a number of computer languages (C/C++, Java, and Python, among others). Using a keyboard symbol rather than a letter or more complex symbol has the advantage that it can be easily entered into formulas without being confused for variable names (e.g. "V"). —Joe 15:07, 21 December 2007 (EST)
- The "and" and "or" operators seem to be using the Python short-circuiting interpretation for logical operators, which I agree makes little sense in a calculator application. If the first operand of an "or" operator is true (i.e. non-zero), then the value of the expression is the value of the first operand, otherwise it is the second. Likewise, if the first operand of an "and" operator is false, then the value of the expression is the value of the second operand, otherwise it is the first. This means that "3|4" will not give the same value as "4|3", for instance. The behavior gives the expected result when using zero and one, but I agree it is confusing with other values. (I note the activity also interprets "True" and "False" as variables rather than boolean values...) —Joe 21:23, 21 December 2007 (EST)
- I double-checked and yes, Joe is correct: the "eq" and "neq" functions return "False" and "True" but these output values are interpreted as variables when used as input. This is a shame because if "False" and "True" were recognized as input values rather than the names of variables then the following would be possible (here "input_A" and "input_B" are variables to be filled in with any old number):
- ("input_A" != 0)&("input_B" != 0)
- For example (3 != 0)&(4 != 0) yields the value "True" whereas (3 != 0)&(4 != 0) yields the value "False".
- I double-checked and yes, Joe is correct: the "eq" and "neq" functions return "False" and "True" but these output values are interpreted as variables when used as input. This is a shame because if "False" and "True" were recognized as input values rather than the names of variables then the following would be possible (here "input_A" and "input_B" are variables to be filled in with any old number):
- Given this correction, one could substitute the first equation into another equation, and proceed with as complex formulas as they would like. Strangely, this is sort of happening now in the sense that the examples above do compute correctly.
- A bug: The above also seems related to the glitch that if one is using the Boolean activity, pulls down "Help" and clicks on it, the word "Help" enters as a variable.
- Moreover if an "indicating function" (see http://en.wikipedia.org/wiki/Indicator_function) is available to convert "False" into "0" and "True" into "1" then true Boolean math is possible (here I will use "IND", thus IND(False)=0, IND(True)=1:
- IND(3 != 0) will yield 1
- IND(0 != 0) will yield 0
- Moreover if an "indicating function" (see http://en.wikipedia.org/wiki/Indicator_function) is available to convert "False" into "0" and "True" into "1" then true Boolean math is possible (here I will use "IND", thus IND(False)=0, IND(True)=1:
- Given this ability to convert "False" to "0" and True to "1", then the classical Boolean equivalences will result from the arithmetic operations { +, -, * } (in the following, ~ is NOT, x and y can only have values {1, 0} ). These equivalences also appear in the article cited above (also see http://en.wikipedia.org/wiki/Propositional_formula for more):
- ~(x) = 1-x
- x & y = x*y
- x|y = x+y-x*y
- x|y = (1 - ((1-x)*(1-y))) = (1-(1 -x -y +x*y)) = x+y-x*y
- x^y = x+y-2*x*y
- (x & ~y) | (~x & y) = (x*(1-y))|((1-x)*y) = (x-x*y)|(y-x*y) = (x-x*y)+(y-x*y)-(x-x*y)*(y-x*y) = x+y-2*x*y - (x*y-x*y*y-x*x*y+x*x*y*y). As x*x=x and y*y=y in Boolean math, we end up with: x^y = x+y-2*x*y - (x*y-x*y-x*y+x*y) = x+y-2*x*y - 0 = x+y-2*x*y.
- Given this ability to convert "False" to "0" and True to "1", then the classical Boolean equivalences will result from the arithmetic operations { +, -, * } (in the following, ~ is NOT, x and y can only have values {1, 0} ). These equivalences also appear in the article cited above (also see http://en.wikipedia.org/wiki/Propositional_formula for more):
- Of course the kids don't have to see all this, but I'm arguing that this should be "in the background" for an educator who is interested, plus it would be a thorough and correct emendaton of the Boolean activity. Bill Wvbailey 15:01, 22 December 2007 (EST)
Here is my wikipedia correspondent's take on (3a)-(3c) above:
- The output when the inputs aren't 0 or 1 do seem strange, but somehow I have become accustomed to software implementations using strange notation and conventions. Including NOT would certainly be a good idea. — Carl (User:CBM|CBM · User talk:CBM|talk) 23:35, 21 December 2007 (UTC)
Bill Wvbailey 10:28, 22 December 2007 (EST)
This is from the Python web-site http://docs.python.org/lib/boolean.html:
- Operation Result Notes
- "x or y" is defined as follows: if x is false, then y, else x (1)
- "x and y" is defined as follows: if x is false, then x, else y (1)
- "not x" is defined as follows: if x is false, then True, else False (2)
- Notes:
- (1) These only evaluate their second argument if needed for their outcome.
- Notes:
- (2) "not" has a lower priority than non-Boolean operators, so not a == b is interpreted as not (a == b), and a == not b is a syntax error
Bill Wvbailey 12:31, 23 December 2007 (EST)
Implementation Discussion
gallery of Calculate examples
It would be great to have a place for a gallery of successfull examples for each mode. For example, plot(ln(x*100)-sin(x*180)/2-ln((1-x)*100),x=0..1) (I'll keep looking around on the wiki for them too....) If there is a better place, I'll also post screenshots here too. --ixo 08:45, 30 December 2007 (EST)
- The gallery picture that Rwh posted is very helpful. Am confused about what "commands" (functions, instructions) the Calculate activity can respond to, their syntax, and where/how to input them. Is there a list somewhere? Thanks, Bill Wvbailey 16:01, 30 December 2007 (EST)
Use of Label and Programming
I come under the category of learning by experimenting. With regard to the use of Labels, I have found that to program an expression, first define the variables with default values, then define the expression, The variables are defined by entering te name followed by a colon in the main window. The variable name will then appear in the Label window. Enter a default value in the main window, press Enter and the variable will be assigned that value. Do this for all of the variables you are going to use. Next, define the name of the expression by entering it's name followed by a colon. The expression name will appear in the Label window. Now, enter your expression with the variable names and press Enter. The expression will be evaluated with the default values. To evaluate the expression for different values simply enter them like the default values, enter the expression name and voila! For example, to compute the hypotenuse of a right triangle from the two sides, first define the sides with defauilt values, ie.,
sideA: (Press Enter, this places sideA in the Label window) 3 (Press enter, this assigns 3 to sideA) sideB: 4 Now, the default values of sides A and B are defined. Hyp: (Press enter, this is the name of the expression and appears as a Label) sqrt(sideA^2 +sideB^2) (Press enter, this defines Hyp and produces an answer, 5)
Now try, other values of sides A and B by reassigning the values and entering Hyp to evaluate it. There may be other sublties with this but this my first attempt.
Graphing
The graphing functionality is unfortunately lacking here. Do any of you know the Grapher program on Mac OS-X (I forget the name of the similar linux program). It is relatively simple and can export the graphs. Here, kids need to be able to take and plot data (rainfall, height, etc) as well as play with plotting in x-y. Then they need to add the plots to reports. Examples will be useful too. This program has great potential, especially in explaining Fourier analysis :)