By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,120 Members | 1,799 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,120 IT Pros & Developers. It's quick & easy.

comparing mantissa

P: n/a
Hi!
is there a better/faster way to compare mantissas of to real number then
in following code?

#include <stdio.h>
#include <stdlib.h>

int main(void) {
float a,b;
int test;

a=1.4234;
b=3.34;
test=((a-(int)a)>(b-(int)b));
printf("a=%f b=%f\n mantisa is bigger in a %d", a,b,test);

return EXIT_SUCCESS;
}

Thank you in advance
Jul 12 '07 #1
Share this Question
Share on Google+
18 Replies


P: n/a
Carramba wrote:
Hi!
is there a better/faster way to compare mantissas of to real number then
in following code?

#include <stdio.h>
#include <stdlib.h>

int main(void) {
float a,b;
int test;

a=1.4234;
b=3.34;
test=((a-(int)a)>(b-(int)b));
printf("a=%f b=%f\n mantisa is bigger in a %d", a,b,test);

return EXIT_SUCCESS;
}
Do you mean <math.hmodf()? It doesn't look like you mean mantissa in
the numerical analysis sense.
Jul 12 '07 #2

P: n/a
Well, if you don't care about the exponenet and only care about the size
of the fraction, in all but the special cases (NaN, +/- infinity) you can
get a pointer to int and point it to the memory location that sores the number.
Shift the data that the pointer to int (really a float) points to left by
nine bits. Do the same for the other number and then compare the results.

But your "solution: still maintains the sign portion of the number. So,
-.222 < .111, by your specification -.222 should be greater than .111.
---Matthew Hicks

Hi!
is there a better/faster way to compare mantissas of to real number
then
in following code?
#include <stdio.h>
#include <stdlib.h>
int main(void) {
float a,b;
int test;
a=1.4234;
b=3.34;
test=((a-(int)a)>(b-(int)b));
printf("a=%f b=%f\n mantisa is bigger in a %d", a,b,test);
return EXIT_SUCCESS;
}
Thank you in advance

Jul 12 '07 #3

P: n/a

"Carramba" <ca******@example.comwrote in message
news:f7**********@aioe.org...
Hi!
is there a better/faster way to compare mantissas of to real number then
in following code?

#include <stdio.h>
#include <stdlib.h>

int main(void) {
float a,b;
int test;

a=1.4234;
b=3.34;
test=((a-(int)a)>(b-(int)b));
printf("a=%f b=%f\n mantisa is bigger in a %d", a,b,test);

return EXIT_SUCCESS;
}

Thank you in advance
Yes, there is a better way, since the above will fail to give the correct
answer for negative numbers.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Aero Stability and Controls Computing
Jul 12 '07 #4

P: n/a
In article <b6*************************@news.ks.uiuc.edu>,
Matthew Hicks <md******@uiuc.eduwrote:
>Well, if you don't care about the exponenet and only care about the size
of the fraction, in all but the special cases (NaN, +/- infinity) you can
get a pointer to int and point it to the memory location that sores the number.
Shift the data that the pointer to int (really a float) points to left by
nine bits. Do the same for the other number and then compare the results.
You are assuming a specific floating point representation that might
be wildly completely wrong. For example on some (very real) systems,
float and double have the same representation, and if that representation
is IEEE 754 64 bit binary radix, then 9 bits of shift would not be
enough.

Shifting bits would get an answer in line with the IEEE 754 definition
of "mantissa", but the answer would be very different than the OP's
b - (int)b answer. For example, 2 and 8192 (and a number of other
numbers) have the same binary mantissa [with different binary exponents],
but 2.1 and 8192.1 have quite different binary mantissas.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
Jul 12 '07 #5

P: n/a
Fred Kleinschmidt skrev:
"Carramba" <ca******@example.comwrote in message
news:f7**********@aioe.org...
>Hi!
is there a better/faster way to compare mantissas of to real number then
in following code?

#include <stdio.h>
#include <stdlib.h>

int main(void) {
float a,b;
int test;

a=1.4234;
b=3.34;
test=((a-(int)a)>(b-(int)b));
printf("a=%f b=%f\n mantisa is bigger in a %d", a,b,test);

return EXIT_SUCCESS;
}

Thank you in advance

Yes, there is a better way,
Thank you for pointing out me to the right direction...
>since the above will fail to give the correct
answer for negative numbers.
Jul 12 '07 #6

P: n/a
In article <b6*************************@news.ks.uiuc.edu>, Matthew
Hicks <md******@uiuc.eduwrote:
>Well, if you don't care about the exponenet and only care about the
size of the fraction, in all but the special cases (NaN, +/-
infinity) you can get a pointer to int and point it to the memory
location that sores the number. Shift the data that the pointer to
int (really a float) points to left by nine bits. Do the same for
the other number and then compare the results.
You are assuming a specific floating point representation that might
be wildly completely wrong. For example on some (very real) systems,
float and double have the same representation, and if that
representation
is IEEE 754 64 bit binary radix, then 9 bits of shift would not be
enough.
Yes, sorry I was in Java land where float means IEEE 754 single precision.
I was going to point out my assumptions but I thought that would have been
redundant. But, not in C.
Shifting bits would get an answer in line with the IEEE 754 definition
of "mantissa", but the answer would be very different than the OP's
b - (int)b answer. For example, 2 and 8192 (and a number of other
numbers) have the same binary mantissa [with different binary
exponents],
but 2.1 and 8192.1 have quite different binary mantissas.
Apparently you didn't bother reading the second part of my post, or the first
part even. I mentioned that my technique was only valid if he cared about
the mantissa. I also pointed out as others have, that his code is wrong
when dealing with negative numbers if he goes by his definition of what he
was trying to do. I think you are trying to ASSUME that he wanted something,
but that isn't what the OP asked for.
---Matthew Hicks
Jul 12 '07 #7

P: n/a
In article <b6*************************@news.ks.uiuc.edu>,
Matthew Hicks <md******@uiuc.eduwrote:
>In article <b6*************************@news.ks.uiuc.edu>, Matthew
Hicks <md******@uiuc.eduwrote:
>>Well, if you don't care about the exponenet and only care about the
size of the fraction,
>Shifting bits would get an answer in line with the IEEE 754 definition
of "mantissa", but the answer would be very different than the OP's
b - (int)b answer.
>Apparently you didn't bother reading the second part of my post, or the first
part even. I mentioned that my technique was only valid if he cared about
the mantissa.
What you actually -wrote- is quoted above. "[...] and only care about
the size of the fraction". "size of the fraction" is NOT the same
as the IEEE 754 definition of "mantissa". The OP's example
dealt with the decimal fractions, and you used the word "fraction"
yourself rather than clarifying that your shift proposal would deal
with the mantissa rather than the fraction. When you are dealing,
for example, with numbers in the 8192 range, the left-most bit of
the mantissa is nominating values in the 4096 range rather than
nominating a value in the range [0,1) as would be the case when
you use the word "fraction".

For very specific implementations, your algorithm could work for
comparing mantissas. But unless the OP has very specific precision
requirements, it would likely make more sense to use the standard C
function frexp() to extract the "normalized fraction and an integral
power of 2"; the drawback of that is that it works with double
rather than float and the mantissa of a double is -potentially-
completely different than the mantissa of a float representing
the same number. Historically, this did happen with more than
one major vendor, in the days before IEEE single precision
numbers became standardized (if I recall correctly, double
precision was standardized first and there was a noticable
lag before single precision was standardized.)
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer
Jul 12 '07 #8

P: n/a
Matthew Hicks skrev:
Well, if you don't care about the exponenet and only care about the size
of the fraction, in all but the special cases (NaN, +/- infinity) you
can get a pointer to int and point it to the memory location that sores
the number. Shift the data that the pointer to int (really a float)
points to left by nine bits. Do the same for the other number and then
compare the results.

But your "solution: still maintains the sign portion of the number. So,
-.222 < .111, by your specification -.222 should be greater than .111.
I should have mentions that all number are >0; in any case this is a good
point to make shore it's covered for the future use.
>
---Matthew Hicks

>Hi!
is there a better/faster way to compare mantissas of to real number
then
in following code?
#include <stdio.h>
#include <stdlib.h>
int main(void) {
float a,b;
int test;
a=1.4234;
b=3.34;
test=((a-(int)a)>(b-(int)b));
printf("a=%f b=%f\n mantisa is bigger in a %d", a,b,test);
return EXIT_SUCCESS;
}
Thank you in advance

Jul 12 '07 #9

P: n/a
In article <f7**********@aioe.org>, Carramba <ca******@example.comwrote:
>I should have mentions that all number are >0; in any case this is a good
point to make shore it's covered for the future use.
Okay, so now how about clarifying whether you mean "mantissa" in the
IEEE 754 binary floating point representation sense (if so,
use frexp()), or whether you mean "decimal fraction" as suggested
by your code (in which case, use modf()).
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers
Jul 12 '07 #10

P: n/a
Walter Roberson skrev:
In article <b6*************************@news.ks.uiuc.edu>,
Matthew Hicks <md******@uiuc.eduwrote:
>>In article <b6*************************@news.ks.uiuc.edu>, Matthew
Hicks <md******@uiuc.eduwrote:
>>>Well, if you don't care about the exponenet and only care about the
size of the fraction,
>>Shifting bits would get an answer in line with the IEEE 754 definition
of "mantissa", but the answer would be very different than the OP's
b - (int)b answer.
>Apparently you didn't bother reading the second part of my post, or the first
part even. I mentioned that my technique was only valid if he cared about
the mantissa.

What you actually -wrote- is quoted above. "[...] and only care about
the size of the fraction". "size of the fraction" is NOT the same
as the IEEE 754 definition of "mantissa". The OP's example
dealt with the decimal fractions, and you used the word "fraction"
yourself rather than clarifying that your shift proposal would deal
with the mantissa rather than the fraction.
why is it different comparing two mantissas or two fraction?
if fraction of a b then mantissa for a should be bigger then b's ?
since mantissa (significand) is considered to by integer or a fractions,
witch in comparison are the same?

When you are dealing,
for example, with numbers in the 8192 range, the left-most bit of
the mantissa is nominating values in the 4096 range rather than
nominating a value in the range [0,1) as would be the case when
you use the word "fraction".

For very specific implementations, your algorithm could work for
comparing mantissas. But unless the OP has very specific precision
requirements, it would likely make more sense to use the standard C
function frexp() to extract the "normalized fraction and an integral
power of 2";
wouldn't the call to the function frexp() be more resource costly for my
purpose? since (for know) comparison is only for real number 0? and
even if it would some lines would easy fix cases there number is < 0.

the drawback of that is that it works with double
rather than float and the mantissa of a double is -potentially-
completely different than the mantissa of a float representing
the same number.
do you mean that the length of the mantissa would differ? and the last
significant number may by different?

Historically, this did happen with more than
one major vendor, in the days before IEEE single precision
numbers became standardized (if I recall correctly, double
precision was standardized first and there was a noticable
lag before single precision was standardized.)
Jul 12 '07 #11

P: n/a
On Jul 12, 6:30 am, Carramba <carra...@example.comwrote:
Hi!
is there a better/faster way to compare mantissas of to real number then
in following code?

#include <stdio.h>
#include <stdlib.h>

int main(void) {
float a,b;
int test;

a=1.4234;
b=3.34;
test=((a-(int)a)>(b-(int)b));
printf("a=%f b=%f\n mantisa is bigger in a %d", a,b,test);

return EXIT_SUCCESS;

}
Your are not comparing mantissas, but I guess that is not what you
want to do anyway.
If you really did want to compare mantissas, the right way to separate
mantissa and exponent is frexp():
http://www.opengroup.org/onlinepubs/...xsh/frexp.html

What are you really trying to accomplish?

Jul 12 '07 #12

P: n/a
On Thu, 12 Jul 2007 12:46:13 -0700, user923005 wrote:
On Jul 12, 6:30 am, Carramba <carra...@example.comwrote:
>Hi!
is there a better/faster way to compare mantissas of to real number then
in following code?

#include <stdio.h>
#include <stdlib.h>

int main(void) {
float a,b;
int test;

a=1.4234;
b=3.34;
test=((a-(int)a)>(b-(int)b));
printf("a=%f b=%f\n mantisa is bigger in a %d", a,b,test);

return EXIT_SUCCESS;

}

Your are not comparing mantissas, but I guess that is not what you
want to do anyway.
Maybe "mantissa" has more meanings than you believe.
If you really did want to compare mantissas, the right way to separate
mantissa and exponent is frexp():
http://www.opengroup.org/onlinepubs/...xsh/frexp.html

What are you really trying to accomplish?
He's trying to compare fractional parts, which I would do with
a - floor(a). Yes, "mantissa" is antiquate with this meaning, but
so it is with the meaning you're thinking about (for which
nowadays "significand" is used).

--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)

Jul 12 '07 #13

P: n/a
On Jul 12, 4:06 pm, Army1987 <army1...@NOSPAM.itwrote:
On Thu, 12 Jul 2007 12:46:13 -0700, user923005 wrote:
On Jul 12, 6:30 am, Carramba <carra...@example.comwrote:
Hi!
is there a better/faster way to compare mantissas of to real number then
in following code?
#include <stdio.h>
#include <stdlib.h>
int main(void) {
float a,b;
int test;
a=1.4234;
b=3.34;
test=((a-(int)a)>(b-(int)b));
printf("a=%f b=%f\n mantisa is bigger in a %d", a,b,test);
return EXIT_SUCCESS;
}
Your are not comparing mantissas, but I guess that is not what you
want to do anyway.

Maybe "mantissa" has more meanings than you believe.
If you really did want to compare mantissas, the right way to separate
mantissa and exponent is frexp():
http://www.opengroup.org/onlinepubs/...xsh/frexp.html
What are you really trying to accomplish?

He's trying to compare fractional parts, which I would do with
a - floor(a). Yes, "mantissa" is antiquate with this meaning, but
so it is with the meaning you're thinking about (for which
nowadays "significand" is used).
In the C language, there is exactly one meaning for mantissa, the one
that I used.

Jul 12 '07 #14

P: n/a
user923005 <dc*****@connx.comwrites:
[...]
In the C language, there is exactly one meaning for mantissa, the one
that I used.
Citation, please? I find no occurrence of the word "mantissa" in the
C99 standard.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 12 '07 #15

P: n/a
Keith Thompson skrev:
user923005 <dc*****@connx.comwrites:
[...]
>In the C language, there is exactly one meaning for mantissa, the one
that I used.

Citation, please? I find no occurrence of the word "mantissa" in the
C99 standard.
isn't mantissa just another (old) word for significand? anyway it's
stated so in wikipedia.
but off course one should use correct terms witch are relevant now.
Jul 13 '07 #16

P: n/a
On Fri, 13 Jul 2007 10:42:36 +0200, Carramba wrote:
Keith Thompson skrev:
>user923005 <dc*****@connx.comwrites:
[...]
>>In the C language, there is exactly one meaning for mantissa, the one
that I used.

Citation, please? I find no occurrence of the word "mantissa" in the
C99 standard.
isn't mantissa just another (old) word for significand? anyway it's
stated so in wikipedia.
but off course one should use correct terms witch are relevant now.
If with your original post you were trying to compare
significands, you were almost as misguided as you could possibly
have ever been.
--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)

Jul 13 '07 #17

P: n/a
Carramba <ca******@example.comwrites:
Keith Thompson skrev:
>user923005 <dc*****@connx.comwrites:
[...]
>>In the C language, there is exactly one meaning for mantissa, the one
that I used.
Citation, please? I find no occurrence of the word "mantissa" in the
C99 standard.
isn't mantissa just another (old) word for significand? anyway it's
stated so in wikipedia.
but off course one should use correct terms witch are relevant now.
There are several meanings of the word "mantissa", and the OP didn't
clearly state which one he was using.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 13 '07 #18

P: n/a
On Fri, 13 Jul 2007 13:16:16 -0700, Keith Thompson wrote:
There are several meanings of the word "mantissa", and the OP didn't
clearly state which one he was using.
But the expressions he wrote (a - (int)a) make somewhat clear
which meaning he intended.

--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)

Jul 14 '07 #19

This discussion thread is closed

Replies have been disabled for this discussion.