avr-gcc floating point problems
in [Design]
|
Prev: NET tips to expand your biz
Next: IR is insane
From: Jamie on 20 Mar 2010 11:25 Cesar Rabak wrote: > Em 18/3/2010 17:39, linnix escreveu: > >> On Mar 18, 11:21 am, Habib Bouaziz-Viallet<h.bouazizvial...(a)free.fr> >> wrote: >> >>> Le Thu, 18 Mar 2010 10:47:44 -0700, linnix a �crit : >>> >>>> unsigned char u; >>>> float f; >>> >>> >>>> u = (unsigned char) f; >>> >>> >>> In what kind of situation you need to cast a float to that unsigned >>> char ??? >>> If you want to extract the integer part of the float, let me tell you >>> that this way is a bit silly. >>> >>> Question yourself before asking to C. >>> >>> Habib >> >> >> f is result of k1 * sine x + k2 * cosine y. >> >> How would you extract the integer part without casting? > > > I would use round(), trunc(), ceil() or floor() as each could better fit. > Every C compiler I've seen does not require a cast to get the integer part of a float. The compile just generates magical code in the background for it myinteger = myfloat; Or course, this implies that the C compiler is loading it's default RTL so that it knows how to handle floats, since AVR's to my knowledge, do not have float operations in the cpu..(FPU) etc..
From: Grant Edwards on 20 Mar 2010 11:55 On 2010-03-20, Habib Bouaziz-Viallet <h.bouazizviallet(a)free.fr> wrote: >>> I said that extracting the integer part of the float is ok when >>> casting a float to an int. >> >> That's what the OP was doing: casting the float to an 8-bit unsigned >> integer. >> >>> When you make a cast from a float to an unsigned int it would result >>> a zero if the float is negative (not quite sure either ... just >>> conjecture) >> >> No, that's not how it works. > > No ? > > Please compile this (gcc -o test -c test -lm) and tell me what you > see. You said that negative float values convert to an unsigned value of 0. Here's what your sample programs shows: -5.627771 251 -9.410577 247 -9.602361 247 -6.129940 250 Negative float values do not convert to unsigned values of 0. IOW, it doesn't work the way you said it did, and the example program you posted proves it. > I knew this was not a related compiler issue or what else (on this i > agree with David), finally i give up because this thread is a serie > of non-sense. I agree that the OP's problem had nothing to do with float/int conversion. The OP's problem is that he ran out of code space. -- Grant
From: Hans-Bernhard Bröker on 23 Mar 2010 16:35 Albert van der Horst wrote: > In article <4ba32898$0$22919$e4fe514c(a)news.xs4all.nl>, > Meindert Sprang <ms(a)NOJUNKcustomORSPAMware.nl> wrote: >> Apart from that, as others have said, u = f should have worked too >> when the integer part of f is in the range of 0-255. > It works on any integer. No, it doesn't. That's been clarified days ago in this thread. > Unsigned char's are supposed to work modulo > their range. Yes, but that only applies once you _have_ an unsigned char. The problem under consideration doesn't have one --- it's trying to build one. > Now I think > u = (unsigned char) f; > is brain damaged. You think incorrectly, there. > This tells the compiler to convert the float converted to an integer, > then take it modulo 256. No, it doesn't. It instructs the compiler to generate code that does exactly what the code says: convert the float to an unsigned char. That's another thing that has been clarified days ago.
From: linnix on 23 Mar 2010 17:05 On Mar 23, 12:35 pm, Hans-Bernhard Bröker <HBBroe...(a)t-online.de> wrote: > Albert van der Horst wrote: > > > In article <4ba32898$0$22919$e4fe5...(a)news.xs4all.nl>, > > Meindert Sprang <m...(a)NOJUNKcustomORSPAMware.nl> wrote: > >> Apart from that, as others have said, u = f should have worked too > >> when the integer part of f is in the range of 0-255. Yes, and we will scale f to fit within 255 first. We are only interested in relative magnitude of an array. > > It works on any integer. > > No, it doesn't. That's been clarified days ago in this thread. > > > Unsigned char's are supposed to work modulo > > their range. > > Yes, but that only applies once you _have_ an unsigned char. The > problem under consideration doesn't have one --- it's trying to build one.. > > > Now I think > > u = (unsigned char) f; > > is brain damaged. > > You think incorrectly, there. The compiler is smart enough to understand "u = f or i = f" as well. The casting is for human reading the code. It may be unnecessary, but not brain damaged. > > > This tells the compiler to convert the float converted to an integer, > > then take it modulo 256. > > No, it doesn't. It instructs the compiler to generate code that does > exactly what the code says: convert the float to an unsigned char. > That's another thing that has been clarified days ago. It is mainly for storage. Unsigned char (8 bits) takes less space than float (16 bits) or double (32 bits). We don't really care how the compiler does it, but storage is important for a 1K SRAM chip.
From: Jamie on 23 Mar 2010 22:09
linnix wrote: > On Mar 23, 12:35 pm, Hans-Bernhard Br�ker <HBBroe...(a)t-online.de> > wrote: > >>Albert van der Horst wrote: >> >> >>>In article <4ba32898$0$22919$e4fe5...(a)news.xs4all.nl>, >>>Meindert Sprang <m...(a)NOJUNKcustomORSPAMware.nl> wrote: >>> >>>>Apart from that, as others have said, u = f should have worked too >>>>when the integer part of f is in the range of 0-255. > > > Yes, and we will scale f to fit within 255 first. We are only > interested in relative magnitude of an array. > > >>>It works on any integer. >> >>No, it doesn't. That's been clarified days ago in this thread. >> >> >>>Unsigned char's are supposed to work modulo >>>their range. >> >>Yes, but that only applies once you _have_ an unsigned char. The >>problem under consideration doesn't have one --- it's trying to build one. >> >> >>>Now I think >>>u = (unsigned char) f; >>>is brain damaged. >> >>You think incorrectly, there. > > > The compiler is smart enough to understand "u = f or i = f" as well. > The casting is for human reading the code. It may be unnecessary, but > not brain damaged. > > >>>This tells the compiler to convert the float converted to an integer, >>>then take it modulo 256. >> >>No, it doesn't. It instructs the compiler to generate code that does >>exactly what the code says: convert the float to an unsigned char. >>That's another thing that has been clarified days ago. > > > It is mainly for storage. Unsigned char (8 bits) takes less space than > float (16 bits) or double (32 bits). We don't really care how the > compiler does it, but storage is important for a 1K SRAM chip. > Last time I knew, that just cast the object into what you want, but it's not going to magically convert a FLOAT to a unsigned char.. Its only going to instruct the compiler that the contents of memory the "F" occupies is a unsigned char and simply moves the data from that from ever it is in memory to "u" simply speaking.. u = f; isn't the same as u = (unsigned char) f; where I come from.. And the last time I knew, AVR's do not have native support for floating point math. UNless I've been out of the loop here? Instead, the compiler should be loading a default RTL that contains low level code to give you that results.. This of course is compiler linked and thus, makes it look natural to you, the coder. And if the C compiler is standardized like most other compilers.. u = (unsigned char) f; simply tells the compiler to treat the object of "F" as if it was a char instead. No conversion is taking place here. As far as how the floats are implemented for the binary format of this compiler will dictate what value of data will be returned.. I can only assume it may support the Mantissa and other elements of a floating point number, in which case, the above will not work as you may think.. But who am I, I don't know anything.. stick with the "u = f;" and the compiler should be happy with that and call one of it's floattointeger conversion TRL functions.. But If you want to know how the float if constructed to represent a floating point number, I guess you could hack it with the cast. I think only the authors of the compiler would understand it's meanings.. |