Hi /prog/
I need to do this exact thing, but only using logical operators
it prints "OP is a faggot" when one of the numbers is negative and the other is 0 or positive
-----------------------------------------
#include <stdio.h>
int main ()
{
int a;
int b;
puts("Ingrese un valor.\n");
scanf("%d", a)
puts("Ingrese otro valor.\n");
scanf("%d", b)
if (a<0)
{
if (b>=0)
{
puts "OP is a faggot"
}
} else {
if (b<0)
{
puts "OP is a faggot"
}
}
}
-----------------------------------------
>>4 negating a variable and testing the complement of what you would test on the un-negated variable 0/10
Name:
Anonymous2009-04-24 3:00
#include <limits.h>
/* Assumes twos-complement representation like on every sane processor */
int isNegative(int i)
{
return i & INT_MIN;
}
int isGEZero(int i)
{
return !isNegative(i);
}
HTH, HAND.
Name:
Anonymous2009-04-24 3:04
#include <limits.h>
/* Assumes twos-complement representation like on every sane processor */
int isNegative(int i)
{
return i & INT_MIN;
}
int isGEZero(int i)
{
return !isNegative(i);
}
HTH, HAND.
Name:
Anonymous2009-04-24 4:13
>>7
Taking the bitwise and of a number and then checking whether it is zero is faster than comparing the initial number to zero? I don't think so. If this is faster, please explain.
Name:
Anonymous2009-04-24 4:36
>>8
It's slower, but only because of the extra function calls. l2eeflags.
Name:
Anonymous2009-04-24 4:36
>>8
Something tells me that the relative speed of these methods would be different on different architectures.
Name:
Anonymous2009-04-24 5:01
>>10
Don't be silly. There's only one architecture.
Name:
Anonymous2009-04-24 5:38
>>1
Hello, Roberto, you might consider using the code tags.
Name:
Anonymous2009-04-24 5:39
>>11
yeah, no one uses anything except plan 9 on ARM anymore.
Name:
Anonymous2009-04-24 5:45
>>13
What are you talking about? Most people are either using IA-32 or x64 with the Microsoft Windows OS.
Name:
Anonymous2009-04-24 15:37
>>8
original didn't specify performance goals, only the operators to use.
On the x86 comparison with 0 tends to be optimized as a test eax,eax followed by a jnz/jz (which just checks the zero flag). Alternatively, you can check the upper bit of your dword to find out if it's negative or not, such as : test num,80000000h
then je/jne. A smart compiler can optimize such comparisons better than you anyway, why would you bother, and at the digital logic level implementation of some of these instructions may be as efficient as that test if not even better.
>>41
In Sepples, the bitwise exact or operator returns an integer, which can be implicitly converted to a boolean, but it is not good form to do so. In fact, you've made 3 implicit conversions. bool to int and bool to int and the resulting int to bool.
>>44
Yes there is. When you convert a float to another type the bits will get changed and shifted around to match the destination format specification, read: converted. No such thing happens for boolean->int or int->boolean, it simply remains as is.
Name:
Anonymous2009-04-26 7:34
>>46
int i = 42;
0041138E mov dword ptr [i],2Ah
bool f = i;
00411395 cmp dword ptr [i],0
00411399 setne al
0041139C mov byte ptr [f],al
The bits of int i (eax) are changed to be either 0 or 1, before being copied to the bool f.
Heck, you could even say the integer is "converted" into a boolean.