typecasting

[C learner]

Which of the statements is correct about the program?

#include<stdio.h>

int main()
{
float a=3.14;
char *j;
j = (char*)&a;
printf("%d\n", *j);
return 0;
}
[A].
It prints ASCII value of the binary number present in the first byte of a float variable a. @
. It prints character equivalent of the binary number present in the first byte of a float variable a.
[C]. It will print 3
[D]. It will print a garbage value

 

[James Kuyper]

With respect to your Subject: header: "typecasting" is something that
happens to actors, it doesn't apply to C programs. The operation you're
talking about is simply called "casting".

Which of the statements is correct about the program?

#include<stdio.h>

int main()
{
float a=3.14;
char *j;
j = (char*)&a;
printf("%d\n", *j);
return 0;
}
[A].
It prints ASCII value of the binary number present in the first byte of a float variable a. @
. It prints character equivalent of the binary number present in the first byte of a float variable a.
[C]. It will print 3
[D]. It will print a garbage value

Answers , [C], and [D] each reflect a different, very serious
misunderstanding of C. Why were you unable to rule them out?
Answer [A] is the one that comes closest to being correct, but it misses
some subtleties. The correct answer is:

[E] it will interpret the contents of the first byte of the 'a' as a
char. That integer value will then be promoted to an int. If that value
is greater than INT_MAX (which would require that CHAR_MAX > INT_MAX,
and therefore CHAR_MIN==0, and that CHAR_BITS>=16, all of which are
permitted to a conforming implementation of C, but very unlikely). then
this promotion will produce an implementation-defined result. In all
other cases it will simply change the type without changing the value
itself.
Because you're printing it with %d, you will simply get the number
represented by that value.

If you had used %c, answer would have been correct. The program
would have printed the corresponding character encoded by that value
using whatever encoding was chosen by the implementation, which need not
be ASCII. Since you didn't use %c, the character encoding (whether or
not it is ASCII) have nothing to do with this.

 

[Geoff]

Which of the statements is correct about the program?

#include<stdio.h>

int main()
{
float a=3.14;
char *j;
j = (char*)&a;
printf("%d\n", *j);
return 0;
}
[A].
It prints ASCII value of the binary number present in the first byte of a float variable a. @
. It prints character equivalent of the binary number present in the first byte of a float variable a.
[C]. It will print 3
[D]. It will print a garbage value

Do your own homework.

 

[BartC]

Which of the statements is correct about the program?

#include<stdio.h>

int main()
{
float a=3.14;
char *j;
j = (char*)&a;
printf("%d\n", *j);
return 0;
}
[A].
It prints ASCII value of the binary number present in the first byte of a
float variable a. @
. It prints character equivalent of the binary number present in the
first byte of a float variable a.
[C]. It will print 3
[D]. It will print a garbage value

How you tried running it?

 

[Bill Cunningham]

With respect to your Subject: header: "typecasting" is something that
happens to actors, it doesn't apply to C programs. The operation
you're talking about is simply called "casting".

Which of the statements is correct about the program?

#include<stdio.h>

int main()
{
float a=3.14;
char *j;
j = (char*)&a;
printf("%d\n", *j);
return 0;
}
[A].
It prints ASCII value of the binary number present in the first byte
of a float variable a. @ . It prints character equivalent of the
binary number present in the first byte of a float variable a. [C].
It will print 3 [D]. It will print a garbage value

Answers , [C], and [D] each reflect a different, very serious
misunderstanding of C. Why were you unable to rule them out?
Answer [A] is the one that comes closest to being correct, but it
misses some subtleties. The correct answer is:

[E] it will interpret the contents of the first byte of the 'a' as a
char. That integer value will then be promoted to an int. If that
value is greater than INT_MAX (which would require that CHAR_MAX >
INT_MAX, and therefore CHAR_MIN==0, and that CHAR_BITS>=16, all of
which are permitted to a conforming implementation of C, but very
unlikely). then this promotion will produce an implementation-defined
result. In all other cases it will simply change the type without
changing the value itself.
Because you're printing it with %d, you will simply get the number
represented by that value.

If you had used %c, answer would have been correct. The program
would have printed the corresponding character encoded by that value
using whatever encoding was chosen by the implementation, which need
not be ASCII. Since you didn't use %c, the character encoding
(whether or not it is ASCII) have nothing to do with this.

Wow. Talk about knowing your stuff! You know I've never used a float.
This post has just made me think. I've always used doubles. Do people even
use the float type anymore? I can't recall ever seeing a C89 or C99 standard
function accepting a float. But then again I don't know much.

Bill

 

[Tim Rentsch]

With respect to your Subject: header: "typecasting" is
something that happens to actors, it doesn't apply to C
programs. The operation you're talking about is simply
called "casting".

Which of the statements is correct about the program?

#include<stdio.h>

int main()
{
float a=3.14;
char *j;
j = (char*)&a;
printf("%d\n", *j);
return 0;
}
[A]. It prints ASCII value of the binary number present in the
first byte of a float variable a.
. It prints character equivalent of the binary number present
in the first byte of a float variable a.
[C]. It will print 3
[D]. It will print a garbage value

Answers , [C], and [D] each reflect a different, very
serious misunderstanding of C. Why were you unable to rule
them out? Answer [A] is the one that comes closest to being
correct, but it misses some subtleties. The correct answer is:

[E] it will interpret the contents of the first byte of the 'a'
as a char. That integer value will then be promoted to an int.
If that value is greater than INT_MAX (which would require that
CHAR_MAX > INT_MAX, and therefore CHAR_MIN==0, and that
CHAR_BITS>=16, all of which are permitted to a conforming
implementation of C, but very unlikely) then this promotion will
produce an implementation-defined result. In all other cases it
will simply change the type without changing the value itself.

The first sentence in the last paragraph is right, but the rest
is messed up. The 'char' value will be promoted to an 'int' if
CHAR_MAX <= INT_MAX, or to an 'unsigned int' otherwise. The
type of the result will be different, but the converted value
will always be the same as the original (char) value. There
is no implementation-defined aspect to the conversion, except
that the type depends on the relative values of CHAR_MAX and
INT_MAX.

Because you're printing it with %d, you will simply get the number
represented by that value.

If the argument value is no greater than INT_MAX it will be
printed, regardless of whether CHAR_MAX > INT_MAX. If the
argument value is greater than INT_MAX (which can happen only if
CHAR_MAX > INT_MAX), then the result is undefined behavior.

 

[blmblm]

James Kuyper wrote:

[ snip ]

Wow. Talk about knowing your stuff! You know I've never used a float.
This post has just made me think. I've always used doubles. Do people even
use the float type anymore? I can't recall ever seeing a C89 or C99 standard
function accepting a float. But then again I don't know much.

Fairly old post, but possibly still worth replying ....

At least some of the math-library functions seem to have a version
that accepts and returns doubles, and another that accepts/returns
floats. Example are fabs/fabsf and sin/sinf. So, yeah, in this
respect you don't know much (though why should you, really).

As for whether people use them ....

I can imagine that there are situations in which single-precision
("float") is good enough and reducing storage requirements by a
factor of two would make a difference, though I don't know of
specific examples.

With "GPGPU" (General-Purpose computing on Graphics Processing
Units), processing on the GPU may be limited to single-precision,
depending on the details of the hardware, and to me that suggests
that the whole computation might as well be single-precision. And
my impression is that this is an active area of R&D these days.

 

[Keith Thompson]

James Kuyper wrote:

[ snip ]

Wow. Talk about knowing your stuff! You know I've never used a
float. This post has just made me think. I've always used
doubles. Do people even use the float type anymore? I can't recall
ever seeing a C89 or C99 standard function accepting a float. But
then again I don't know much.

Fairly old post, but possibly still worth replying ....

At least some of the math-library functions seem to have a version
that accepts and returns doubles, and another that accepts/returns
floats. Example are fabs/fabsf and sin/sinf. So, yeah, in this
respect you don't know much (though why should you, really).

C90's <math.h> only defined functions with arguments and results of type
double. If you wanted a square root of a float, you could use the
double function and convert the argument and result:

float x = 2.0;
float sqrt_x = sqrt(x); /* two implicit conversions */

If you wanted long double, you were out of luck unless you had a
non-standard library.

C99 added float and long double versions of the math functions, so now
we have:

double sqrt(double x);
float sqrtf(float x);
long double sqrtl(long double x);

It also added <tgmath.h>, which defines a number of "type-generic
macros", so that sqrt(x) would invoke either sqrtl(), sqrt(), or
sqrtf(), depending on the type of the argument.

C11 added _Generic, which allows programmers to do the same kind of
thing <tgmath.h> does.

[...]

 

[Malcolm McLean]

I can imagine that there are situations in which single-precision
("float") is good enough and reducing storage requirements by a
factor of two would make a difference, though I don't know of
specific examples.

Graphics typically use floats for object co-ordinates. It rarely matters if
the end result is a pixel out, and you tend to need a lot of geometry.

 

[Lowell Gilbert]

I can imagine that there are situations in which single-precision
("float") is good enough and reducing storage requirements by a
factor of two would make a difference, though I don't know of
specific examples.

I can provide one. Real-time applications employing feedback (or
feed-forward) where the sensors only provide (and the controls only
allow for) sufficiently limited precision that a double wouldn't give
more precise results to the actual application. Storage limitations may
be less important than data-transfer speeds (this is definitely the case
in my experience, but I don't have a sense of how typical that is).

Be well.

 

[88888 Dihedral]

I can provide one. Real-time applications employing feedback (or

feed-forward) where the sensors only provide (and the controls only

allow for) sufficiently limited precision that a double wouldn't give

more precise results to the actual application. Storage limitations may

be less important than data-transfer speeds (this is definitely the case

in my experience, but I don't have a sense of how typical that is).



Be well.

--

Lowell Gilbert, embedded/networking software engineer

http://be-well.ilk.org/~lowell/

Yep, I agree with you in the precision requiredment of those mass-production AV products.

Audio data in 14 to 16 bits and
visual data of RGB in 6 to 8 bits
per color component are quite commen.

It is different in scitific and military computations.

For example, the GPS and RADAR parts of SAM systems require much more expensive fast computations and long precesions to defend the war zone
than the cheap AV propducts.

 

[Stephen Sprunk]

Graphics typically use floats for object co-ordinates. It rarely
matters if the end result is a pixel out, and you tend to need a lot
of geometry.

There is a growing demand for half-precision (16-bit) FP for such uses;
would that be a "short float" in C?

S