x/2^4 ~ x >> 4?

what is a mantissa (im going to be told to go to hell, I mean google)? I read somewhere that computers don't actually subtract numbers, rather they add negated numbers. Does negating just mean for every 1 you make it 0 and vice versa? Likewise multiplication doesn't really exist, because its really just looping through and adding numbers x amount of times (this is all internal bs that humans never see)

EDIT:

Shifting isn't guaranteed to be equivalent to division by powers of two. Your code is only guaranteed to be portable if you use division. You're best off relying on your compiler for that particular optimization, as it may not work on other compilers.

Why is that so? I mean, a byte is always going to be 8 bits...right?

EDIT1: I found it! good old www.dictionary.com

The decimal part of a logarithm. In the logarithm 2.95424, the mantissa is 0.95424

EDIT2: omg it just clicked, I don't know why but I didn't understand WHY in the hell
126.5 == 01111110.1, but it's just like what any base would be, whenever you move to the right whatever value that place holds is equal to the last one divided by that base
so 126.25 is 01111110.01 ?

Originally posted by Silvercord
what is a mantissa (im going to be told to go to hell, I mean google)?

The mantissa is the actual values of the digits that will be stored

example -- in decimal

3.54 x 10 ^ 4

3.54 is the mantissa.

However, the mantissa doesn't explicitly store a binary point. Your mantissa is always going to be greater than or equal to 0 and less than (exclusive) 2

Originally posted by Silvercord
I read somewhere that computers don't actually subtract numbers, rather they add negated numbers. Does negating just mean for every 1 you make it 0 and vice versa?

Negating is implementation dependant. In the 2's compliment system (the most common system for storing signed integers), negating is equal to switching all of the digits and then adding 1. If you didn't add 1, then you'd have a positive and a negative 0. This is why most implementations allow you to store values -128 to 127 (even though the standard only requires -127 to 127)

Originally posted by Silvercord
Likewise multiplication doesn't really exist, because its really just looping through and adding numbers x amount of times (this is all internal bs that humans never see)

No, not exactly. In the 2's compliment system, multiplication can always be done with a maximum of the number of binary digits in the value minus 1. Do long hand multiplication with binary numbers and you'll understand. Use the same idea as you would with base 10 numbers only now you're just dealing with 1's and 0's.

Originally posted by Silvercord
Why is that so? I mean, a byte is always going to be 8 bits...right?

Actually no, but that's not the reason. I explained the reason earlier in this thread. Check it again.

Originally posted by Silvercord
so 126.25 is 01111110.01 ?

Yup

Most of the times I divide anything it's a floating point number, so I rarely use shifting.

But, why would x >>= 1 work on one compiler and not on the other? What I mean is, what results would x >>= 1 produce on an integer other than dividing by 2 (roughly) that would be sporadic?

Originally posted by rmullen3
Most of the times I divide anything it's a floating point number, so I rarely use shifting.

But, why would x >>= 1 work on one compiler and not on the other? What I mean is, what results would x >>= 1 produce on an integer other than dividing by 2 (roughly) that would be sporadic?

In the 2's complimentary system, padding with 0's or 1's on negitive numbers won't result in the same thing as division. Padding with 0's would completely mess with the number and padding with 1's would result in rounding away from 0 rather than towards it. Example:

-3 / 2 as defined by the standard should round towards 0 to the value -1

Now, let's look at right shifting by 1.

11111100

That is the 2's complimentary system representation of -3.

Shifting it by 1 to the right and padding with 1's will result in

11111110

Which is actually -2

Right there you see there are 2 different results between shifting and dividing.

Try it out on MSVC++. It uses 2's complimentary system (just like pretty much all compilers).

You'll get the answers I provided.

Negating is implementation dependant. In the 2's compliment system (the most common system for storing signed integers), negating is equal to switching all of the digits and then adding 1. If you didn't add 1, then you'd have a positive and a negative 0. This is why most implementations allow you to store values -128 to 127 (even though the standard only requires -127 to 127)

Could you show an example so I can clearly see what you mean?
What exactly does '2's compliment system' mean?

Shifting isn't guaranteed to be equivalent to division by powers of two. Your code is only guaranteed to be portable if you use division. You're best off relying on your compiler for that particular optimization, as it may not work on other compilers.

Was that your explanation? If so, why would shifting not be guaranteed on other compilers/operating systems? If that wasn't your explanation then ill look harder

Yup

WOOHOO! I GOT SOMETHING RIGHT! OMG!

EDIT:

-3 / 2 as defined by the standard should round towards 0 to the value -1

Now, let's look at right shifting by 1.

11111100

That is the 2's complimentary system representation of -3.

Shifting it by 1 to the right and padding with 1's will result in

11111110

Which is actually -2

Right there you see there are 2 different results between shifting and dividing.

Try it out on MSVC++. It uses 2's complimentary system (just like pretty much all compilers).

You'll get the answers I provided.

I got -1...errr....

EDIT1: I might be less in the dark if someone explains to me how the 2's complimentary system gets -3 out of 11111110
thanks

Originally posted by Silvercord
Could you show an example so I can clearly see what you mean?
What exactly does '2's compliment system' mean?

binary representation of positive 1 using the 2's compliment system with the least significant bit on the right

00000001

making it negative -- first, you flip all the digits

11111110

and then you add 1

11111111

The above is the 2's compliment representation of -1.

Now try 0

00000000

Flip the digits

11111111

add 1

00000000

Notice, it's also 0.

If you didn't add 1 then you'd have both a positive and negative 0 which would cause a lot of complications (IE what happens when you compare positive and negative 0, your code would have to check both positive and negative 0 because they are the same).

Originally posted by Silvercord
Was that your explanation? If so, why would shifting not be guaranteed on other compilers/operating systems? If that wasn't your explanation then ill look harder

No, that wasn't it. Anyways, I just gave an example in my previous post. That should clear things up for you.

Ok thank you, I am going to read that last post and take a break (I haven't learned this much at once in my entire life so I'm going to go committ suicide now)

seriously though thanks for this conversation I had fun

Originally posted by Silvercord
I got -1...errr....

For both? That's pretty unlikely, but not impossible. Try this:

Code:

#include<iostream>

int main()
{
    std::cout << "Division: " << -3 / 2 << std::endl;
    std::cout << "Shifting: " << ( -3 >> 1 ) << std::endl;
    return 0;
}

I get the results:

Division: -1
Shifting: -2

Though the point is that the results are not going to be the same from compiler to compiler for shifting.

Ah, I see. I guess that never really occured to me because whenver I used shifting I was working either with unsigned values or values I knew were not going to go < 0.

Does shifting create any cross-compiler anomalies on unsigned values, or is it only with negative values?

The odd's are much less likely for unsigned values, but still possible. One example where it wouldn't work is when the most significat bit is the rightmost bit rather than the leftmost. In that case left shifting would be division and right shifting would be multiplication.