macOS My F Statement is not working...

[lee1210]

If you're nervous about depending on the exact return of a conditional, even if it is in the standard (every compiler is 100% adherent, right? =) ) you could just go ternary.

(velocity > 1)?1:0 + ...

I'm not bashing the original version, but even if C doesn't have a separate true/false primitive I try to treat it that way... which would mean you don't add true + true + false.

If you really wanted to go nuts with ternary (not recommended this, there's just lots of ways to skin a cat):

level = (velocity > 64)?5:
	(velocity > 48)?4:
	(velocity > 28)?3:
	(velocity > 4)?2:
	(velocity > 1)?1:0;

You'll end up doing fewer operations when it's windy, but this is an eyesore.

-Lee

 

[balamw]

even if C doesn't have a separate true/false primitive I try to treat it that way... which would mean you don't add true + true + false.

That's fair criticism, although the nested if/then/else statements in cybrscot's original version might actually be easier to read than the ternary version.

I was also trying to show how relational operators are just like arithmetic operators and can be used in expressions so cybrscot might help separate them from assignment in his mind.

B

 

[Sander]

In my terrible example code that you looked at, I did
calm < 1 ;
light < 4 ;
etc
etc

Actually, you can do this; it just probably doesn't mean what you think it does. These are "expressions", not "assignments". You're free to put them in your program, but to the compiler it means "Generate code to evaluate whether the value of the variable calm is less than one." So when you run the program, the computer will evaluate whether this is the case. And then what, you ask? And that's the crux of the matter: Then nothing. The compiler will probably have given you a warning about this, something along the lines of "Warning: Statement with no effect".

Remember, the computer will do exactly what you tell it to, nothing more. You ask it to check something, but then not take any action based in the outcome.

Cheers,
Sander

 

[Bill McEnaney]

I'm not bashing the original version, but even if C doesn't have a separate true/false primitive I try to treat it that way... which would mean you don't add true + true + false.

Why not include stdbool.h? "True" and "false" become zero and one, but I don't know anyone who would write "true + true," "true + false," etc.

I'm a purist when I program in any programming language.

 

[balamw]

I'm a purist when I program in any programming language.

I think you have this backwards, in the C standard (x<1) is an expression that already returns an int that can be 1/0, not a bool that is true/false. lee1210's use of the ternary operator explicitly enforces the int, but really doesn't add anything since it already returns 1/0.

I'd only include stdbool if I wanted to think about it as true/false which takes me further away from the code I originally posted. I don't want to add true+true+false+true.

FWIW MATLAB encourages this kind of stuff and it makes for some very readable code. For example:

A12=A(A>12);

Will extract a subarray that includes all of the elements of A that are greater than 12 rather than writing a loop and checking each value ... http://www.mathworks.com/company/newsletters/digest/sept01/matrix.html

B

 

[lee1210]

I really wasn't trying to knock balmw's method at all. It's concise, clear, and gets the job done. The behavior is reliable and to spec. I only posted the bit about using the result of comparisons for addition to give a different point of view. I believe that there was a time that 1/0 wasn't spec, that it was 0/non-zero, but I'm not a spec historian.

My real point was that I'd just as well think of the result of comparisons as true or false and be done with it. With that said, if I came up with the solution balmw did, I'd probably commit it and call it a day.

-Lee

 

[Bill McEnaney]

I think you have this backwards, in the C standard (x<1) is an expression that already returns an int that can be 1/0, not a bool that is true/false. lee1210's use of the ternary operator explicitly enforces the int, but really doesn't add anything since it already returns 1/0.

I have what backwards? I know that (x < 1) is an expression that can return a zero or a one. I asked about stdbool.h because I wouldn't write anything like this:

(x > 0) + (y < 1) + (z <= x)

In any C program I write, each function has one entry point and one exit point. So each C function I write has at most one "return" statement, the function's last statement. If I need to stop a while-loop early, I force the loop condition to be false. I won't use, say, a "return" statement inside a loop. I won't write "if (pointer)" to ask whether a pointer points somewhere . . . My main complaint about C is that it's too permissive.

 

[balamw]

I have what backwards? I know that (x < 1) is an expression that can return a zero or a one. I asked about stdbool.h because I wouldn't write anything like this:

(x > 0) + (y < 1) + (z <= x)

C doesn't implement a boolean type and all stdbool.h does is allow those who would like it to to use "true" and "false" instead of 1 and 0. What I was suggesting was backwards is trying to complicate C's native "int" expression based logic, turning it into "true/false" instead of just accepting that the standard logic functions already return an int for you.

You could easily define your own explicit function

int isabove(int velocity, int range)
{
int result;

result = (velocity > range)?1:0;

return result;
}

(Use if/then else if the ternary isn't to your taste)

condition = isabove(velocity,1) + isabove(velocity,4) + isabove(velocity,28) + isabove(velocity,48) + isabove(velocity,64);

Would be 100% equivalent to the code I produced earlier, but I think the earlier code is easier to understand.

In any C program I write, each function has one entry point and one exit point. So each C function I write has at most one "return" statement, the function's last statement. If I need to stop a while-loop early, I force the loop condition to be false. I won't use, say, a "return" statement inside a loop. I won't write "if (pointer)" to ask whether a pointer points somewhere . . . My main complaint about C is that it's too permissive.

Me too, believe it or not.

I was just complaining about deliberate terseness in a different thread and how this kept me away from C for many years. However, in this case, I don't think the meaning of my earlier code is difficult to suss out.

B

 

[Bill McEnaney]

C doesn't implement a boolean type and all stdbool.h does is allow those who would like it to to use "true" and "false" instead of 1 and 0. What I was suggesting was backwards is trying to complicate C's native "int" expression based logic, turning it into "true/false" instead of just accepting that the standard logic functions already return an int for you.

Good points, B. I'm a huge fan of simple code. That's partly why I adore Haskell and Python's list comprehensions. It's also partly why I hate Perl, the most eclectic, syntactically ugly language I've ever read. Perl can be needlessly terse, too. A buddy of mine loves Perl. So he might convert me.

You could easily define your own explicit function

int isabove(int velocity, int range)
{
int result;

result = (velocity > range)?1:0;

return result;
}

(Use if/then else if the ternary isn't to your taste)

condition = isabove(velocity,1) + isabove(velocity,4) + isabove(velocity,28) + isabove(velocity,48) + isabove(velocity,64);

Would be 100% equivalent to the code I produced earlier, but I think the earlier code is easier to understand.

Your isablove is very readable. But the functional programmer in me wouldn't mind shortening it a little. Maybe I should have one, but I don't have a problem with deleting the "result" variable to write "return velocity > range;".

Me too, believe it or not.

I was just complaining about deliberate terseness in a different thread and how this kept me away from C for many years. However, in this case, I don't think the meaning of my earlier code is difficult to suss out.

Your code was easy to understand. I just didn't expect to see anything like it.

It's great to know there's another purist in the world.

Oh, since you're thinking about terseness, guess what this slow Prolog program does.

smallest(Element, List) :-
   sort(List, [Element|_]).