<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="bbPress/1.0.2" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>LeafLabs Garden &#187; Topic: Computation with floats</title>
		<link>http://forums.leaflabs.com/topic.php?id=852</link>
		<description>A place to share, learn, and grow...</description>
		<language>en-US</language>
		<pubDate>Fri, 22 Jan 2016 00:12:52 +0000</pubDate>
		<generator>http://bbpress.org/?v=1.0.2</generator>
		<textInput>
			<title><![CDATA[Search]]></title>
			<description><![CDATA[Search all topics from these forums.]]></description>
			<name>q</name>
			<link>http://forums.leaflabs.com/search.php</link>
		</textInput>
		<atom:link href="http://forums.leaflabs.com/rss.php?topic=852" rel="self" type="application/rss+xml" />

		<item>
			<title>gbulmer on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852&amp;page=2#post-5370</link>
			<pubDate>Tue, 21 Jun 2011 17:49:13 +0000</pubDate>
			<dc:creator>gbulmer</dc:creator>
			<guid isPermaLink="false">5370@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;cromda - good test. I can't explain 10x. &#60;/p&#62;
&#60;p&#62;I am willing to believe 2x difference, maybe even 3x, for similar code on PIC32 vs STM32F, but 10x has me flummoxed. For a difference that big, I assume the algorithms are different.&#60;/p&#62;
&#60;p&#62;I did read that the PIC32 UNO tool chain contains a proprietary part 'for performance reasons' but I have no idea what that may mean.&#60;/p&#62;
&#60;p&#62;Maybe I need to get one of those PIC32 UNO's.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>cromda on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5368</link>
			<pubDate>Tue, 21 Jun 2011 16:25:48 +0000</pubDate>
			<dc:creator>cromda</dc:creator>
			<guid isPermaLink="false">5368@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;Hi crenn&#60;/p&#62;
&#60;p&#62;I've a Sparkfun Razor 9DOF (old version) wich work fine with the Python viewer.&#60;/p&#62;
&#60;p&#62;But the SF9DOF_AHRS_1_0 soft does'nt complie on UNO32 (The bottom window if full of red garbage).&#60;/p&#62;
&#60;p&#62;The code does'nt compile too on Maple32 (white garbage).&#60;/p&#62;
&#60;p&#62;What to do with the oscilloscope ?
&#60;/p&#62;</description>
		</item>
		<item>
			<title>crenn on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5361</link>
			<pubDate>Mon, 20 Jun 2011 16:10:57 +0000</pubDate>
			<dc:creator>crenn</dc:creator>
			<guid isPermaLink="false">5361@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;cromda, do you have access to an oscilloscope and a sparkfun Razer 9DOF? It could be using a look up table to implement those functions, but I'm now curious as to what happens when you run the Razer's IMU code on the Uno32.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>cromda on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5359</link>
			<pubDate>Mon, 20 Jun 2011 15:28:34 +0000</pubDate>
			<dc:creator>cromda</dc:creator>
			<guid isPermaLink="false">5359@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;gbulmer,&#60;/p&#62;
&#60;p&#62;In order to check your theory, I modified the code runing on the UNO32 in such a way that the computed value is used and should not be &#34;optimised out&#34; :&#60;/p&#62;
&#60;p&#62;/*&#60;br /&#62;
Vitesse de calcul flottant&#60;br /&#62;
*/&#60;/p&#62;
&#60;p&#62;float y=0;&#60;br /&#62;
float tv=0;&#60;br /&#62;
float tb=0;&#60;br /&#62;
float a=0;&#60;br /&#62;
float p=0;&#60;br /&#62;
float pi=3.14159265359;&#60;br /&#62;
int N=10000;&#60;br /&#62;
unsigned long t1=0;&#60;br /&#62;
unsigned long t2=0;&#60;/p&#62;
&#60;p&#62;void setup() {&#60;br /&#62;
Serial.begin(9600);&#60;br /&#62;
}&#60;/p&#62;
&#60;p&#62;void loop() {&#60;br /&#62;
  p=100*2*pi/N;&#60;br /&#62;
// time for base loop&#60;br /&#62;
  a=-p;&#60;br /&#62;
  t1=micros();&#60;br /&#62;
  for (int i=0; i &#38;lt;= N; i++) {&#60;br /&#62;
    a=a+p;&#60;br /&#62;
    y=a;&#60;br /&#62;
    }&#60;br /&#62;
  t1=micros()-t1;&#60;br /&#62;
  tv=float(t1)/float(N+1);&#60;/p&#62;
&#60;p&#62;// time for loop with function to check&#60;br /&#62;
  a=-p;&#60;br /&#62;
  t2=micros();&#60;br /&#62;
  for (int i=0; i &#38;lt;= N; i++) {&#60;br /&#62;
    a=a+p;&#60;br /&#62;
    y=tan(a); // function to check&#60;br /&#62;
    }&#60;br /&#62;
  t2=micros()-t2;&#60;br /&#62;
  tb=float(t2)/float(N+1);  &#60;/p&#62;
&#60;p&#62;    // print the results to the serial monitor:&#60;br /&#62;
    Serial.print(&#34;empty loop = &#34; );&#60;br /&#62;
    Serial.print(tv);&#60;br /&#62;
    Serial.print(&#34; us&#34;);&#60;br /&#62;
    Serial.print(&#34;\t computation = &#34;);&#60;br /&#62;
    Serial.print(tb-tv);&#60;br /&#62;
    Serial.print(&#34; us&#34;);&#60;br /&#62;
    Serial.print(&#34;\t last x = &#34;);&#60;br /&#62;
    Serial.print(a);&#60;br /&#62;
    Serial.print(&#34;\t last function value = &#34;);&#60;br /&#62;
    Serial.print(y);&#60;br /&#62;
    Serial.println();&#60;br /&#62;
}&#60;/p&#62;
&#60;p&#62;The average time to compute a tangent is 5.58 µs (a little smaller than before ; 6.59 µs) : the quick and dirty code I first used before is not &#34;optimised out&#34; by UNO32.&#60;/p&#62;
&#60;p&#62;(in addition if some code was &#34;optimised ou&#34;, as crenn already mentioned, the computation time should not increase with complexity + - / sqrt sin tan)&#60;/p&#62;
&#60;p&#62;So I think that UNO32 is definitly realy up to 10 time faster than Maple 32 with floats computations.&#60;/p&#62;
&#60;p&#62;May be that UNO32 code uses pre-computed tables and interpolations instead of iterative routines ?&#60;/p&#62;
&#60;p&#62;It would be interesting to compare UNO32 and Maple32 accuracy when computing with floats.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>gbulmer on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5331</link>
			<pubDate>Fri, 17 Jun 2011 18:18:49 +0000</pubDate>
			<dc:creator>gbulmer</dc:creator>
			<guid isPermaLink="false">5331@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;cromda - The code doesn't use any results from float(), sqrt(), or tan(), so if the compiler were capable of spotting those functions have no side effect, it could eliminate them. &#60;/p&#62;
&#60;p&#62;I had a quick look at gcc 4.5 release notes and, as zoofdxp wrote, it talks about some improvements.&#60;br /&#62;
Several may matter, for example:&#60;br /&#62;
&#34;A new link-time optimizer has been added (-flto). When this option is used, GCC generates a bytecode representation of each input file and writes it to special ELF sections in each object file. When the object files are linked together, all the function bodies are read from these ELF sections and instantiated as if they had been part of the same translation unit. This enables interprocedural optimizations to work across different files (and even different languages), potentially improving the performance of the generated code.&#34;&#60;br /&#62;
If PIC32 uses ELF object files, this might be enough for gcc to spot that some of those functions have no side effect and can be eliminated, which might account for the significant (~10x) improvement shown on the UNO32.&#60;/p&#62;
&#60;p&#62;Maybe worth investigating.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>poslathian on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5274</link>
			<pubDate>Thu, 16 Jun 2011 16:48:59 +0000</pubDate>
			<dc:creator>poslathian</dc:creator>
			<guid isPermaLink="false">5274@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;An eventual flavor of Maple in the pipeline - not anytime soon but in the pipeline - will be armed with a Cortex M4 - with a floating point unit.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>cromda on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5271</link>
			<pubDate>Thu, 16 Jun 2011 16:08:28 +0000</pubDate>
			<dc:creator>cromda</dc:creator>
			<guid isPermaLink="false">5271@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;crenn : yes the loop runs 10001 intead of 10000 times.&#60;/p&#62;
&#60;p&#62;The computation time increase with complexity of the function tested (+ - * / sqrt, sin tan), is it compatible with optimising out ?&#60;/p&#62;
&#60;p&#62;Snigelen : I test with sqrtf, sinf and tanf instead of sqrt, sin and tan and the times are a little smaller : 8,14 µs, 32,89 *s and 57,93 µs instead of 25,43 µs, 55,08 µs and 92,48 µs. Its better, but UNO32 remain faster.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>robodude666 on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5180</link>
			<pubDate>Mon, 13 Jun 2011 21:00:06 +0000</pubDate>
			<dc:creator>robodude666</dc:creator>
			<guid isPermaLink="false">5180@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;I suppose if you need high-precision, it's worth the extra time. It might be worth looking at the &#60;a href=&#34;http://en.wikipedia.org/wiki/Texas_Instruments_TMS320&#34;&#62;TI TMS320&#60;/a&#62; then. For me, I'd be happy to loose 2.3% accuracy on a sin calculation if it means 4x faster performance.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>crenn on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5176</link>
			<pubDate>Mon, 13 Jun 2011 20:24:48 +0000</pubDate>
			<dc:creator>crenn</dc:creator>
			<guid isPermaLink="false">5176@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;cromda, just a note, your code is running 10001 passes, not 10000 as you intended.&#60;/p&#62;
&#60;p&#62;I'm also wondering if the PIC compiler is optimising out the tan calculations as the data is never used.&#60;/p&#62;
&#60;p&#62;snigelen, good point. I'm not sure about the PIC, but I know that 'doubles' on the Arduino have been recast as floats. This probably has been done on the PIC as well to make it 'directly' compatible.&#60;/p&#62;
&#60;p&#62;robodude666, With fixed point maths, it's possible to lose some of the precision in calculations. It depends on your application on whether it's better to use fixed point or floating point maths.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>robodude666 on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5166</link>
			<pubDate>Mon, 13 Jun 2011 16:42:19 +0000</pubDate>
			<dc:creator>robodude666</dc:creator>
			<guid isPermaLink="false">5166@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;Keep in mind that the STM32 is running at 72MHz @ 1.25 DMIPS/MHz. The &#34;UNO32&#34; uses a PIC32MX320F128H which runs at 80MHz @ 1.56 DMIPS/MHz. While these are only theoretical numbers, the difference between them is quite large.&#60;/p&#62;
&#60;p&#62;Regardless, neither of these microcontrollers has a fully dedicated floating-point unit, so why bother using floating-point calculations? I've experienced myself what kind of performance fixed-point mathematics can yield and don't see any reason to use floating-point math.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>snigelen on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5159</link>
			<pubDate>Mon, 13 Jun 2011 14:15:41 +0000</pubDate>
			<dc:creator>snigelen</dc:creator>
			<guid isPermaLink="false">5159@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;sin, tan, sqrt etc do the computation with doubles. sinf, tanf, sqrtf etc. is for float. They will probably be a little faster.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>cromda on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5158</link>
			<pubDate>Mon, 13 Jun 2011 13:27:05 +0000</pubDate>
			<dc:creator>cromda</dc:creator>
			<guid isPermaLink="false">5158@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;here is the (quick and dirty) code I wrote to measure computation speed :&#60;br /&#62;
/*&#60;br /&#62;
computation time&#60;br /&#62;
r. cormier&#60;br /&#62;
2011-06-11&#60;br /&#62;
*/&#60;/p&#62;
&#60;p&#62;float x=0;&#60;br /&#62;
float y=0;&#60;br /&#62;
float z=0;&#60;br /&#62;
float tv=0;&#60;br /&#62;
float tb=0;&#60;br /&#62;
int N=10000;&#60;br /&#62;
uint32 t1=0;&#60;br /&#62;
uint32 t2=0;&#60;/p&#62;
&#60;p&#62;void setup() {&#60;/p&#62;
&#60;p&#62;}&#60;/p&#62;
&#60;p&#62;void loop() {&#60;br /&#62;
// time for base loop&#60;br /&#62;
  x=0;&#60;br /&#62;
  t1=micros();&#60;br /&#62;
  for (int i=0; i &#38;lt;= N; i++) {&#60;br /&#62;
    x=float(i);&#60;br /&#62;
    y=sqrt(x);&#60;br /&#62;
    z=x;&#60;br /&#62;
    }&#60;br /&#62;
  t1=micros()-t1;&#60;br /&#62;
  tv=float(t1)/float(N);&#60;/p&#62;
&#60;p&#62;// time for tan&#60;br /&#62;
  x=0;&#60;br /&#62;
  t2=micros();&#60;br /&#62;
  for (int i=0; i &#38;lt;= N; i++) {&#60;br /&#62;
    x=float(i);&#60;br /&#62;
    y=sqrt(x);&#60;br /&#62;
    z=tan(y);&#60;br /&#62;
    }&#60;br /&#62;
  t2=micros()-t2;&#60;br /&#62;
  tb=float(t2)/float(N)-tv;  &#60;/p&#62;
&#60;p&#62;// print the results to the serial monitor:&#60;br /&#62;
    SerialUSB.print(&#34;t base loop : &#34; );&#60;br /&#62;
    SerialUSB.print(tv);&#60;br /&#62;
    SerialUSB.print(&#34; us&#34; );&#60;br /&#62;
    SerialUSB.print(&#34;\t tan computation : &#34;);&#60;br /&#62;
    SerialUSB.print(tb);&#60;br /&#62;
    SerialUSB.print(&#34; us&#34; );&#60;br /&#62;
    SerialUSB.println();&#60;br /&#62;
}&#60;/p&#62;
&#60;p&#62;_______________________________________&#60;/p&#62;
&#60;p&#62;I used that code to check the Mapple computation with double instead of float : the computation times with doubles are a little smaller.&#60;/p&#62;
&#60;p&#62;So I think that there is only double computation with Mapple. When performing float computation, floats are converted to double and the result is converted from double to float. This is the reason why float computation is a little slower that double computation and why computation speed is much smaller with Maple32 than with UNO32.&#60;/p&#62;
&#60;p&#62;When there Mapple will have a dedicated float library, float computation will compare good with UNO32.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>crenn on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5151</link>
			<pubDate>Mon, 13 Jun 2011 11:26:32 +0000</pubDate>
			<dc:creator>crenn</dc:creator>
			<guid isPermaLink="false">5151@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;Can we see the code used for testing the 3 platforms?
&#60;/p&#62;</description>
		</item>
		<item>
			<title>zoofdxp on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5147</link>
			<pubDate>Sun, 12 Jun 2011 19:54:30 +0000</pubDate>
			<dc:creator>zoofdxp</dc:creator>
			<guid isPermaLink="false">5147@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;The maple ide 0.0.11 package is using codesourcery's 2010q1 compiler.  There have been two releases/updates, the latest is 2011.03-42.  In the interest of code stability I can understand not mucking with the compiler and introduce possible errors..but I was wondering if anyone has tried the latest compiler to see if it works well and possibly provides more optimized code.  Their site states &#34;Significant optimization improvements in GCC&#34;...these optimizations could just be compile performance but maybe there are processor performance improvements as well.  Microchips FP library must be incredibly hand tuned, the disparity in performance is far beyond the 72Mhz to 80Mhz clock speeds, either that or MIPS architecture as they have implemented compared to ST's ARM is embarrasingly superior.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>robodude666 on "Computation with floats"</title>
			<link>http://forums.leaflabs.com/topic.php?id=852#post-5146</link>
			<pubDate>Sun, 12 Jun 2011 13:25:19 +0000</pubDate>
			<dc:creator>robodude666</dc:creator>
			<guid isPermaLink="false">5146@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;Unlikely =].&#60;/p&#62;
&#60;p&#62;The STM32 used in the Maple, and just about every other MCU beyond DSP-specific chips like TI's TMS320, do not have floating-point units on them. Doing floating point calculations is like grinding teeth. If you're using the built-in functions via the math.h header you'll get rather poor results, as you've seen for yourself. However, the STM32F103xxx does have a 72MHz clock as you mentioned and regular fixed-point mathematics is blazing fast!&#60;/p&#62;
&#60;p&#62;If you will be doing a lot of computation, try out the &#60;a href=&#34;http://code.google.com/p/libfixmath/&#34;&#62;libfixmath&#60;/a&#62; library. It provides fix-point variants to trig, sqrt, exp, etc. as well as basic operations such as addition, subtraction, multiplications and addition. I've seen an average of 2-4x increase in performance from switching to this library vs the &#34;built in math.h&#34;. It takes up very little FLASH/RAM and is rather simple to use once you get it setup.&#60;/p&#62;
&#60;p&#62;-robodude666
&#60;/p&#62;</description>
		</item>

	</channel>
</rss>
