faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
|
Classic difference
by David Walser on Monday 27/Sep/2004, @15:55
|
This is just another example of a big difference between different types of people when it comes to doing calculations. Some people have to write things out, think slower, and prefer using graphing calculators where they have to type a whole problem in some horrible mess of parentheses, not thinking linearly through the problem as to the order of calcuations as they type, but of the order they have to type to get the calculator to do the right thing.
Then there's people who think faster, can keep track of some things in their head, and prefer scientific calcuators with memories (yes plural, mine has 7 instead of one), and can fly through complicated calculations (in a much more linear and logical fashion I might add) much faster than others.
And it's not to say there's anything wrong with you whether you fall into one group or the other, you can't change who you are. Some people will just prefer the style of interface you have shown, and for some KCalc just is more usable. Not that there isn't room for improvement. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Classic difference
by Roberto Alsina on Monday 27/Sep/2004, @16:41
|
I am sure you can calculate 20% of 75 plus 15% of 64 faster using your calculator, right?
I mean, .2*75+.15*64(enter) is so much slower than .2*75(push into mem).15*64+(pop from mem)= :-)
For each approach used to interface the calculator, there is some set of problems that are slower. My own guess (and nothing more than that) is that this approach is faster for a significant set of problems.
|
[
Reply To This | View ]
|
RPN
by Rich Jones on Tuesday 28/Sep/2004, @02:55
|
.. And this is where an rpn interface would shine.
.2 [enter] 75 [*] .15 [enter] 64 [*] [+]
You get to see intermediate results, and get to enter in the order written, evaluating as you go. The only practical problem with the RPN approach is stack height, but that's not a problem with a calculator based on a computer, with kaboodles of memory.
PGCalc2 lets you enter number and operators directly from the numpad, and use the mouse for things like SIN.
|
[
Reply To This | View ]
|
Re: RPN
by Chanan Oren on Sunday 03/Oct/2004, @19:10
|
You don't need to use the mouse for things like SIN, just press it's letter. S for SIN, T for COS, U for TAN, etc. Also CTRL, ESC to quit or SHIFT, ESC to minimize to the tray.
|
[
Reply To This | View ]
|
Re: Classic difference
by David Walser on Tuesday 28/Sep/2004, @03:02
|
The example you gave should take the exact same keystrokes actually, so no advantage either way there. With other problems, *nothing* will be faster with a usecalc/graphing calculator interface if you know what you are doing.
|
[
Reply To This | View ]
|
Re: Classic difference
by Roberto Alsina on Tuesday 28/Sep/2004, @03:55
|
Sorry, but I can't parse your post. Are you saying that with other problems a scientific calculator will be faster, or that a graphig calculator is never faster?
|
[
Reply To This | View ]
|
Re: Classic difference
by ScottZ on Tuesday 28/Sep/2004, @05:53
|
This reminds me of a feature that I would like to see on all history/tape calculators. I wish that they would include the calculation next to the answer.
When all you see is the answer it can be hard to remember which calculation created the answer.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
