454,503 Members | 1,628 Online Need help? Post your question and get tips & solutions from a community of 454,503 IT Pros & Developers. It's quick & easy.

# What does this function do?

 P: n/a #include float puzzle( float inp ) { const float ths = 1.5F; const long k = 21*76069667; float a, b; int c; a = inp * 0.5F; b = inp; c = *( long *) &b; c = k - ( c >1 ) ; b = *( float *) &c; b = b * ( ths - ( a * b * b ) ) ; return 1/b; } Nov 17 '08 #1
3 Replies

 P: n/a On Nov 17, 6:55*am, "c.lang.mys...@gmail.com" float puzzle( float inp ) { * const float ths = 1.5F; * const long k = 21*76069667; * float a, b; * int c; * a = inp * 0.5F; * b = inp; * c = *( long *) &b; * c = k - ( c >1 ) ; * b = *( float *) &c; * b = b * ( ths - ( a * b * b ) ) ; * return 1/b; }- Hide quoted text - - Show quoted text - A very inaccurate square root that won't work on a 64-bit platform. -- Fred Nov 17 '08 #2

 P: n/a c.***********@gmail.com wrote: #include float puzzle( float inp ) { const float ths = 1.5F; const long k = 21*76069667; float a, b; int c; a = inp * 0.5F; b = inp; c = *( long *) &b; The conversion has behavior that is undefined if b doesn't happen to be aligned correctly to store a long integer; this is unlikely, but entirely possible. The only thing that the standard guarantees about the resulting pointer is that if it is converted back to float*, it will compare equal to &b (6.3.2.3p7). For an object of type float, "long" is not one of the types listed in section 6.5p7; therefore, trying to access an object of type float using an lvalue of type "long" violates a "shall" occuring outside of a Constraints section - the behavior of this code is undefined. Even if right hand side of that expression had precisely the behavior that the author expected it to have, there would be no guarantee that the resulting value is within the range of an 'int'. Therefore, when that value is implicitly converted to 'int' before assigning it to c, "... either the result is implementation-defined or an implementation- defined signal is raised." (6.3.1.3p3). c = k - ( c >1 ) ; Even on a system where the value of c is precisely what the author of this code probably expected it to be, there's no guarantee that c is positive. That being the case, the result of the shift operation is implementation-defined (6.5.7p5). b = *( float *) &c; This statement has all of the same problems as the calculation of 'c', except that section 6.3.1.3p3 will not be an issue unless INT_MAX > FLT_MAX; this is extremely unlikely, but is technically a possibility. Therefore, the correct answer to your question is "this function could do anything". Even if the undefined behavior could be avoided, the correct answer would still depend upon which implementation was used to translate and execute this code. You haven't identified the implementation, so the question could not be answered, even in that case. Nov 17 '08 #3

 P: n/a On Nov 17, 2:55*pm, "c.lang.mys...@gmail.com" float puzzle( float inp ) { * const float ths = 1.5F; * const long k = 21*76069667; * float a, b; * int c; * a = inp * 0.5F; * b = inp; * c = *( long *) &b; * c = k - ( c >1 ) ; * b = *( float *) &c; * b = b * ( ths - ( a * b * b ) ) ; * return 1/b; } The return statement shows that the author of the posted code is trying to be clever, but fails. The code will on some C implementations set b to a rather imprecise approximation to sqrt (1 / inp).in rather short execution time. It is fast by avoiding divisions which tend to be rather slow. And what is the last thing it does? It returns 1/b to return a bad approximation to sqrt (inp), using a division and destroying all the speed advantage. Instead one should return inp * b. Nov 17 '08 #4

### This discussion thread is closed

Replies have been disabled for this discussion. 