HP Forums
Yes another prime question - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: Yes another prime question (/thread-251538.html)



Yes another prime question - Geoff Quickfall - 09-27-2013

It seems that there is allot in common with Basic in some aspects of the programming language.

I am having a problem with the correct formatting of an IF THEN test:

Ex.

IF B<0 then B=B+360;

Generates 'no errors in program' but does not change the negative value into a positive value after adding to 360 when the test is positive. In fact nothing happens and B stays the same as though that line does not exist.

Any thoughts for this newbie.

Geoff

Edited: 27 Sept 2013, 9:31 p.m.


Re: Yes another prime question - iconmaster - 09-27-2013

Try an END; statement in there at the, well, end.


Re: Yes another prime question - Clayton Workman - 09-27-2013

You need a colon before the = sign when defining B as follows:

IF B<0 then B:=B+360;

-Clayton


Re: Yes another prime question - Geoff Quickfall - 09-27-2013

ARRRRRRGGGHHHHHHH

the colon did it!

Thanks Clayton


Re: Yes another prime question - Geoff Quickfall - 09-27-2013

Does beg the question on why "syntax error" did not show?


Re: Yes another prime question - kris223 - 09-28-2013

I think this is due to it being an operation that returns a boolean value. The "=" statement is the same as the other equality and relational operators.

In his statement:
IF B<0 then B=B+360;

the "<" returns a boolean in the same manner as the "=".
Here B remains unchanged but the "=" operation returns a boolean that can be caught by any conditional statement it just isn't used in the above statement.

I wrote a test:

EXPORT fft(A)
BEGIN
B:=A=1;
MSGBOX("Result: " +B);
END;

Here B gets the boolean value of "A=1" and if you test it with A being any other value than 1 the result will be 0 and 1 otherwise. This is why there is no syntax error as the syntax is valid.


Edited: 28 Sept 2013, 12:40 a.m.


Re: Yes another prime question - kris223 - 09-28-2013

Perhaps this is a better example:

EXPORT gggg(B)
BEGIN
Z:=B=B+360;
RETURN "B:" +B +" Z:" +Z;
END;

B=B+360 is the same expression as was originally use. I have assigned the boolean value of the "=" operation to the variable Z.

When one runs the the program, B remains whatever value was passed in as nothing is done to it. Because we compare value of B to the sum of B and 360, it's an inequality and Z will get zero.

Although that's not what we originally thought we were doing, the syntax is valid and it did what we told it to do.

If one were to change the statement of "Z:=B=B+360;" to "Z:=B=B+0;" then Z will always return 1.


Edited: 28 Sept 2013, 1:24 a.m.


Re: Yes another prime question - Geoff Quickfall - 09-28-2013

Got it, thanks for explanation. So a legal statement, just not what I thought was happening.

Geoff


Re: Yes another prime question - David Hayden - 09-28-2013

This illustrates a problem with many existing computer programming languages. They are designed to be expressive, but they aren't designed to help the programmer avoid simple mistakes like this.

It takes some horsepower in the compiler, but one way to mitigate mistakes like this is to analyze the statement and give a warning for statements that have no effect. It isn't perfect, but it's better than nothing.

Dave


Re: Yes another prime question - kris223 - 09-28-2013

Yes, that's it. I would think of it like this:

IF (boolean condition) 
THEN (consequentA)
ELSE (consequentB)

Any of the conditional statements whenever used returns a boolean value. So X<Y returns a boolean of true (1) or false(2) based on the result of X being smaller than Y. Then we throw that into the conditional construct to make things happen.

True (1) we go to consequentA, False (2) we branch to consequentB ... I know doh, but the thing is that what I'm trying to say here is that the boolean conditional (<,>,=, ...) does not require that the conditional construct (IF, CASE, WHILE, FOR) be there. Its very happy to scream TRUE!! even if nobody is listening. It's their job and they are very proud of comparing things :)

I wish there was more documentation on the language. The manual is very limited, and this is my first time using this syntax. Simple things like what is greater than or equal? I assume >=, but it should be written down somewhere. This is my first time using this particular language, and there must be something somewhere ... the manual has a little example basically and the help files on the calculator are very helpful, but it's not enough in my opinion. I'm guessing HP will provide it soon if not already. I may be looking in all the wrong places ;)


Re: Yes another prime question - kris223 - 09-28-2013

I don't view it as a problem of the language. One must know what one is saying is all. Like in Java or C/C++ "=" is completely different than "==" and if one uses the wrong one it's not a mistake of the language, but the orator's. In this language they have chose to use ":=" as a get statement and "=" as a comparator. I'm fine with that.

I think this is a natural byproduct of having the ability to overload functions/methods and having the ability to ignore a function/method's return statement. What holds true for one aspect of a language must hold true for all of it I'd guess.

My two cents of nadda ... :)

Edited: 28 Sept 2013, 10:12 a.m.


Re: Yes another prime question - Geoff Quickfall - 09-28-2013

It's like spell check, sometimes it is just plain silly. As with my fortran days and key punch cards where a typo creates 20000 error messages and 5 dead trees, I should be careful about what passes muster!

Remember, If you spell Geoff this way 'Goeff' spell check corrects it to Goof, which may be correct some of the time!

:-)


Re: Yes another prime question - David Hayden - 09-30-2013

Quote:
I don't view it as a problem of the language. One must know what one is saying is all. Like in Java or C/C++ "=" is completely different than "==" and if one uses the wrong one it's not a mistake of the language, but the orator's.

I agree completely that is a mistake of the orator. My point is that people are people and they do make mistakes. I've been programming professionally in C/C++ for 28 years and occasionally STILL make the = vs. == mistake. Most of our tools and inventions are designed to prevent us from making mistakes. You can't start a car if it's in drive. You can't plug a lamp into the wall with the polarity set wrong. My point is that a computer language should be similarly designed to help prevent errors. Java did this with memory leaks. They saw that memory leaks were a very common source of errors so they designed the language so the problem went away.

Hmm. Getting philosophical here, one could argue that avoiding errors is a major purpose of high level languages. Structured language makes spaghetti code nearly impossible. Typed variables make it hard to perform the wrong operation on data, etc.

Dave


Re: Yes another prime question - kris223 - 09-30-2013

Java went one step further ... they have "=" and "==" and .... .equals()! now we have another spot to make a mistake because its an object and not a primitive. I like pointers in c/c++, and I like Java as the whole lang forced object orientation. In my opinion pointers can get out of hand in c/c++ and overriding methods can get out of hand in Java, but I think these things make the lang what it is and I like both of them. One thing to note is that by getting rid of pointers Java was much slower and a larger memory hog (when one declares an array list for example its wasting memory and the garbage collector is a resource that comes at a price) ... there no free lunch. C++ can make object orientation a mess because the issue isn't forced. I think these are necessary evils. The analogy holds with the car as an object but in order to work on the car one must open the hood. Nasty moving parts in there! This is the environment we must work in sometimes or we could play it safe and stick to shell scripts and the like. It's a dangerous thing walking out one's door LOL. If one were to have the compiler take care of all this it may become convoluted. Perhaps this is a job best left to an IDE.

It's a balancing act I think with high level lang's ... why not skip the different data types ... float, double, int ... why not go the way of perl and use "$"? It's because their high level languages and there must be enough rope to hang oneself in order to control things at a high level. If you want to use power tools you can mess some stuff up. Best to use the right tool on the car and say what ya mean when you program LOL. Just some thoughts from the peanut gallery ;)


Edited: 1 Oct 2013, 12:15 a.m.