# Simple Javascript Calculator

• Nov 3, 2003, 08:53
dtennant9
Simple Javascript Calculator
Hi

I have a project that I have to do for uni in which I have to make a simple calculator in Javascript. It must let you enter 2 numbers then give the user the chance tho decide whether the numbers are added, subtracted or multiplied. So far I have managed to have three different functions with three different buttons and this works. I am however trying to get it to work so that the user could enter the sign in a text box and then click on one button to perform the calculation as this gets better marks. I am totally stumped on how to do this with just one function and is it possible?

Cheers
• Nov 3, 2003, 12:47
beetle
Yes, it's possible. I'll give you some pointers.

1) I assume you know how to get the value of a textbox, so read the value of the field with the operator

2) If the operator is a plus sign, add the two operands. If a minus sign, subtract the two operands, etc.

Basically, you will need to use either of these two control structures

1) if...else
2) switch...case

Are you familiar with how to setup and if...else statement or a switch...case statement?
• Nov 3, 2003, 16:13
awestmoreland
Quote:

Originally Posted by beetle
Basically, you will need to use either of these two control structures
1) if...else
2) switch...case

That sounds like a lot of faffing about when an eval() statement will do the job :D

Example

Of course you could always change the select box to another text field enabling you to enter your own operand manually if you wanted.

Andy
• Nov 3, 2003, 16:16
beetle
What would he be learning if he resorted to eval()?

This is obviously a school assignment. "Faffing" is the whole point.

:rolleyes:
• Nov 3, 2003, 16:26
awestmoreland
Quote:

Originally Posted by beetle
What would he be learning if he resorted to eval()?

He'd be learning eval() and a more efficient way of coding.
Quote:

Originally Posted by beetle
This is obviously a school assignment. "Faffing" is the whole point.:rolleyes:

If by that you mean that we should be giving hints rather than resolving a request, then I've misunderstood the point of this forum. I'm not sure why you think it has to be long-winded. Dtennant9 asked for a way to minimize the code. That's what I've offered.

Don't fret, I'm sure your award isn't in danger ;)

Andy
• Nov 3, 2003, 16:30
beetle
That's not what I'm saying at all, dude.

My point is, that if someone comes here for help with school, a solution should not be handed to them. That is my suggestion as a Mentor, not as the JavaScript Guru.

And eval() is not a more efficient way of coding. It's more brief, but that's it. Brevity and efficacy are not always the same thing.

There are times and places to use eval(), but it's not something easily understood, therefore best avoided until that knowledge is attained. That's why I never recommend eval() to newbies.
• Nov 3, 2003, 16:43
awestmoreland
Quote:

Originally Posted by beetle
My point is, that if someone comes here for help with school, a solution should not be handed to them.

Well I'm here to answer, not to tutor ;)
Quote:

Originally Posted by beetle
And eval() is not a more efficient way of coding. It's more brief, but that's it. Brevity and efficacy are not always the same thing.

Agreed, but I'm fairly sure that in this case they are. There is no conditional branching and no redundant code as far as I can see. I'm happy to be proved wrong however if it means that I can improve my coding in future.
Quote:

Originally Posted by beetle
There are times and places to use eval(), but it's not something easily understood, therefore best avoided until that knowledge is attained. That's why I never recommend eval() to newbies.

Really? Maybe it has hidden depths, but I thought it did exactly what it said on the tin :)

Cheers,

Andy
• Nov 3, 2003, 17:10
beetle
Quote:

Originally Posted by awestmoreland
Well I'm here to answer, not to tutor [img]images/smilies/wink.gif[/img]

That's fine. But an answer doesn't have to be a solution. All I'm asking is to be mindful of students and the value of learning in the future. dtennant9 is much better off learning control structures than eval().

Quote:

Originally Posted by awestmoreland
Really? Maybe it has hidden depths, but I thought it did exactly what it said on the tin

Yes: to both. First of all, it's the single most costly (overhead-wise) function in javascript. Secondly, it jiggers the scope chain -- a concept too advanced to explain to newbies, so again, it's just best avoided until understanding is possible. Remember, eval() is not a portable skill, but things like control structures and hashtables are.

Quote:

Originally Posted by awestmoreland
Agreed, but I'm fairly sure that in this case they are. There is no conditional branching and no redundant code as far as I can see. I'm happy to be proved wrong however if it means that I can improve my coding in future.

In this case, yes, they are the same. But that's not the point. Code efficacy comes in many flavors, and semantics are always important. You can improve your JS coding in other ways:
HTML Code:

```<html>   <head>         <title>Two Value Calculator</title>         <script type="text/javascript">   function calculate( f )   {   var opElem = f.operator;   var operator = opElem.options[opElem.selectedIndex].value;   f.result.value = eval( f.operand1.value + operator + f.operand2.value );   }         </script>   </head>   <body>         <form>           <input name="operand1" type="text" size="5" />&nbsp;           <select name="operator">                 <option value="+">+</option>                 <option value="-">-</option>                 <option value="*">*</option>                 <option value="/">/</option>           </select>&nbsp;           <input name="operand2" type="text" size="5" />&nbsp;=&nbsp;           <input name="result" type="text" size="10" readonly="readonly" />&nbsp;           <input name="submit" type="button" value="Calculate" onClick="calculate( this.form );" />         </form>   </body> </html>```
• Nov 3, 2003, 17:27
awestmoreland
I really wish that one of the brainboxes around here would invest some time in sorting out the bug that makes code look like that :-/

I can see what you've done there within the function (and by calling it referencing "this.form") however I've always shied away from that in the past. Surely by the end of your function, you're dealing with constructs which equate to things such as "form.operator.options" and "form.result.value" which seem more IE4 than the constructs that I had using getElementById?

Thanks for the pointers,

Andy
• Nov 3, 2003, 17:43
beetle
First of all, you run document.getElementById 4 times. Methods are always more costly than property lookups. Secondly, you run document.getElementById twice for the same element. Storing a reference is much better for something like this, I even mention that in my post at the tips thread.

We are only concerned with two processes.

1) Obtaining references to the form elements
2) Getting or setting their value property.

#2 will always be the same. Therefore, all our optimizations must be with step #1. Referencing a form's elements via either the elements collection or the exposed form properties that all modern browsers provide, is faster and cleaner than the top-down approach using document.getElementById. Not to mention more compatible, since document.getElementById doesn't work in IE4, whereas my solution will.

BTW, the forum software replaces every 4 spaces with a tab, and every tab with a single space. Kinda annoying.
• Nov 6, 2003, 07:53
dtennant9
cheers Guys