onwall and such

[ApothiX]

Originally Posted by jake13jake

if (function() == false)

CASE 1:
function() returns true
true == false
true is not equivalent to false, therefore the statement is false.

CASE 2:
function() returns false
false == false
false is equivalent to false, therefore the statement is true.

Tell me, what's the contrapositive to p->q?

Seriously, take a course in logic or something.

I lied, one more post.

Good job for proving that both are the exact same amount of steps, and the same amount of work required by the applications.

[jake13jake]

Originally Posted by ApothiX

I lied, one more post.

Good job for proving that both are the exact same amount of steps, and the same amount of work required by the applications.

Uh, no.
function() returns true
that's one step
true is equivalent to true
that's two steps

function returns true
that's one step

When you do
function() returns false
false is equivalent to false
that's two steps too

also
function() returns false
the ! operator negates false to true.
there's two steps

However, you wouldn't know if the ! operator is faster than the == operator in gscript. But for true values there's more steps in comparison by ==true.

[ApothiX]

Originally Posted by jake13jake

Uh, no.
function() returns true
that's one step
true is equivalent to true
that's two steps

function returns true
that's one step

Actually, both are comparing to true. I now know your theory behind this, and that you're a ***** because of it.

(Last post here, seriously)

[Skyld]

Originally Posted by jake13jake

if (function() == false)

if (!function())

[jake13jake]

Originally Posted by Skyld

if (!function())

Originally Posted by jake13jake

also
function() returns false
the ! operator negates false to true.
there's two steps

moo.

Originally Posted by ApothiX

Actually, both are comparing to true. I now know your theory behind this, and that you're a ***** because of it.

(Last post here, seriously)

The computer doesn't compare to true if it has already interpreted true.

[ApothiX]

Alright well, you're just getting annoying so I will have to present some cold hard facts.

PHP Code:

bool Ret(bool b) {
    return b;
}

int main(int argc, char *argv[]) {
    int a;

    if(Ret(true)) {
        a = 10;
    }

    return 0;
} 


This code (which is C), when compiled (without optimizations) and dissassembled, produces the EXACT same assembly as this code:

PHP Code:

bool Ret(bool b) {
    return b;
}

int main(int argc, char *argv[]) {
    int a;

    if(Ret(true) == true) {
        a = 10;
    }

    return 0;
} 


There is no redundant checking going on. Stop posting here.

[Loriel]

Originally Posted by ApothiX

This code (which is C),

It is actually C++. C does not have a bool type unless it is C99 and you include stdbool.h or something.

when compiled (without optimizations) and dissassembled, produces the EXACT same assembly as this code

Does not!

PHP Code:

ben@oreichalkon ~ $ cat foo.cpp
#include <cstdlib>
#include <cstdio>

bool random_bool() {
        return std::rand() % 2;
}

int main() {
        if (random_bool()
        #ifdef REDUNDANT_CHECK
          == true
        #endif
        )
                std::puts("true!");
}
ben@oreichalkon ~ $ gcc -O0 -S -o foo.s foo.cpp; gcc -O0 -S -o foo_.s -DREDUNDANT_CHECK foo.cpp
ben@oreichalkon ~ $ diff foo_.s foo.s                                           41,43c41,42
<       movzbl  %al, %eax
<       cmpl    $1, %eax
<       jne     .L3
---
>       testb   %al, %al
>       je      .L3 


[ApothiX]

Originally Posted by Loriel

Does not!

Different compilers produce different results. It seems like Visual C was probably optimizing the == true check even when I turned optimizations off. Which is probably what the Graal Engine does aswell.

[jake13jake]

Originally Posted by ApothiX

Different compilers produce different results. It seems like Visual C was probably optimizing the == true check even when I turned optimizations off. Which is probably what the Graal Engine does aswell.

Yes, but you don't know whether or not the Graal engine does that, you can only guess. Isn't that what I was initially saying? It's certainly redundant in script, but the compiler may or may not interpret it with a redundancy check. When optimizing, your compiler removes the == true comparison. How kind of it.

[ApothiX]

Originally Posted by jake13jake

Yes, but you don't know whether or not the Graal engine does that, you can only guess. Isn't that what I was initially saying? It's certainly redundant in script, but the compiler may or may not interpret it with a redundancy check. When optimizing, your compiler removes the == true comparison. How kind of it.

It may be a redundancy in the script for you, but for some people it improves readability. Also, I am quite aware that the Graal Engine does have optimizations done on scripts, which means that both cases would work out to the same thing (exactly what I have been saying all along.)

[Tyrial]

ApothiX:

Listen man, I don't care if it's wrong or right, if it works or not.

IT IS STUPID!


if (onwall() == true) is exactly the same thing as if (true == true).

If that is correct, why don't you continue to do:

if ((((((onwall() == true) == true) == true) == true) == true) == true)

It's the exact same thing.

Silence.

[Skyld]

Originally Posted by Tyrial

if (onwall() == true) is exactly the same thing as if (true == true).

Not if onwall() is returning false.

Originally Posted by Tyrial

If that is correct, why don't you continue to do:

if ((((((onwall() == true) == true) == true) == true) == true) == true)

It's the exact same thing.

Why the hell would you continue to do that?

That is called wasting time, space and energy. Besides, it is not exactly the same since you are making the engine evaluate the statement six times. I do not think it will fold that down.

[xXziroXx]

This thread is getting stupid :x

[ApothiX]

Originally Posted by Tyrial

ApothiX:

Listen man, I don't care if it's wrong or right, if it works or not.

IT IS STUPID!


if (onwall() == true) is exactly the same thing as if (true == true).

If that is correct, why don't you continue to do:

if ((((((onwall() == true) == true) == true) == true) == true) == true)

It's the exact same thing.

Silence.

Then stop bumping it, you dip****.

[Tyrial]

Originally Posted by Skyld

Not if onwall() is returning false.

Yeah well I ment if it's returning true, but you knew that allready didn't you? You just wanted to act all smart. Bravo, you get a cookie.

Originally Posted by Skyld

Why the hell would you continue to do that?

That is called wasting time, space and energy.

No ****! That's like exactly what I mean.

If you think that ((((true == true) == true) == true) == true) is a waste, then you must think the same about (onwall() == true) because that is like (true == true).

In other words, he did:
if (true == true) //Waste.
instead of:
if (true) //Not waste.

Besides, it is not exactly the same since you are making the engine evaluate the statement six times. I do not think it will fold that down.

So? It's only needed to get a value from the boolean ONCE, after that it's a waste, whether it's twice or more, it's the same crappy code.

[Skyld]

Originally Posted by Tyrial

Yeah well I ment if it's returning true, but you knew that allready didn't you? You just wanted to act all smart. Bravo, you get a cookie.



No ****! That's like exactly what I mean.

If you think that ((((true == true) == true) == true) == true) is a waste, then you must think the same about (onwall() == true) because that is like (true == true).

In other words, he did:
if (true == true) //Waste.
instead of:
if (true) //Not waste.




So? It's only needed to get a value from the boolean ONCE, after that it's a waste, whether it's twice or more, it's the same crappy code.

Please tone down when posting in my forum, okay?

[ApothiX]

Originally Posted by Tyrial

In other words, he did:
if (true == true) //Waste.
instead of:
if (true) //Not waste.

You're forgetting three crucial words: IN YOUR OPINION. As I have stated before, some people prefer onwall() == true because it helps them to read it better. Christ. Skyld can you please close this thread because honestly these people are replying without even reading it.

[Skyld]

Topic is causing problems.

Closed.