Yes another prime question



#15

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.


#16

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

#17

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

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

-Clayton


#18

ARRRRRRGGGHHHHHHH

the colon did it!

Thanks Clayton


#19

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


#20

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.


#21

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.


#22

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

Geoff


#23

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 ;)

#24

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


#25

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.


#26

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!

:-)

#27

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


#28

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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime Matrix TERRIBLE bug and question uklo 19 2,003 11-25-2013, 12:10 PM
Last Post: Mic
  HP Prime - vector question bluesun08 3 567 11-18-2013, 07:26 PM
Last Post: Han
  Question about transfering programs to the HP Prime Namir 10 1,221 11-17-2013, 04:01 PM
Last Post: Namir
  Another HP Prime CAS question Michael de Estrada 3 615 11-09-2013, 10:56 AM
Last Post: Michael de Estrada
  XCas / Prime "solve" question Nigel J Dowrick 4 773 11-08-2013, 04:01 AM
Last Post: Nigel J Dowrick
  Non-Prime question alert: Hp-41 and synthetic instructions Marcel Samek 11 1,443 11-04-2013, 09:31 PM
Last Post: sjthomas
  HP PRIME - APP Programing question dg1969 2 487 10-27-2013, 10:23 AM
Last Post: dg1969
  WP-34S (Prime Number Test) question Barry Mead 3 596 10-20-2013, 05:28 PM
Last Post: Dieter
  HP Prime EVAL function question Jonathan Cameron 2 475 09-28-2013, 08:58 PM
Last Post: Han

Forum Jump: