<p>Actually, it isn't quite so clear. If I run this in Java:</p>



<pre class="lang-java prettyprint-override"><code>// Simple computation with float and double
// Increment by a third three times is not the same as incrementing by one
// Float can actually be more accurate than Double in limited cases
public static void main(String[] args) {
    float oneThirdF = 1.0f/3.0f;
    float wholeF = 0.0f;
    float countF = wholeF; //initially equal
    while(countF == wholeF){
        wholeF = wholeF + oneThirdF + oneThirdF + oneThirdF;
        countF = countF + 1.0f;
    }
    System.out.println("Float: " + countF + " != " + wholeF);

    double oneThirdD = 1.0d/3.0d;
    double wholeD = 0.0d;
    double countD = wholeD; //initially equal
    while(countD == wholeD){
        wholeD = wholeD + oneThirdD + oneThirdD + oneThirdD;
        countD = countD + 1.0d;
    }
    System.out.println("Double: " + countD + " != " + wholeD);

}
</code></pre>

<p>I get: </p>

<pre class="lang-java prettyprint-override"><code>Float: 3.0 != 2.9999998
Double: 2.0 != 1.9999999999999998
</code></pre>

<p>So, while doubles are certainly more precise than floats, the place in a "floating point" computation at which things go <em>wrong</em> depends on a lot more than which form you use. Here Float was a bit more "accurate" initially, since Double failed earlier. </p>

<p><strong>Lessons:</strong> Don't use such things for counting. If you need to do computation use the form with more precision. Beware of the results. And testing for equality is pointless (it's why Zeus created Epsilon). </p>

<p>Finally, though this code doesn't illustrate it, there are situations in which the errors are larger than the answers, so saying x ± ε might be entirely meaningless if x is small and ε is large. </p>

<p><strong>However</strong>, if your use is to take a physical reading from some sort of equipment (say temperature) and report it, with little computation, the shorter (float) type is almost certainly sufficient and likely has more precision than necessary. When there is a lot of computation, use double along with sophisticated error control techniques. </p>

<hr>

<p>For a (long) explanation of floating point errors see: <a href="https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html" rel="nofollow noreferrer">https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html</a>. This is valid for any language using the IEEE 754 standard (most modern languages and processors). </p>

CC BY-SA 3.0
2018-02-15T15:38:08.663Z
... and never use floating point to represent money.  At 11 million dollars plus or minus you start losing the pennies, and your company's accountant will feed you to the alligators slowly.
pojo-guy
CC BY-SA 3.0
2018-02-15T15:45:27.390Z
@pojo-guy Actually money is one of the most complex data types. It has both place and time dimensions. It means something different today than in 6 months and it means something different in the US and the EU.  An early chapter in https://martinfowler.com/books/ap.html explains the complexity.
Buffy
CC BY-SA 4.0
2018-02-14T00:05:15.233Z
2018-08-30T17:35:36.523Z
2018-08-30T17:35:36.523Z
Buffy
<p>Simple demonstration of "precision" using handheld calculators. </p>

<p>Get a pair of calculators. One cheap model that has a limited number of digits in its display. Models can be found built in to clipboards and other "office" things. One decent model, not necessarily a <em>good</em> model, that has double the digits of the other calculator. If it has exactly double the display size of the first, so much the better.</p>

<p><em>One point to be aware of is that many calculators, even the cheap disposable ones, will have at least one significant digit beyond the display to help hide/correct rounding errors.</em> The demonstration will have to be tested on the specific models you use before class.</p>

<p>Develop some short, and simple, formulas that will develop rounding errors quickly. Thirds, and harmonics thereof, usually are corrected by the hidden digit(s), but higher factors tend to do better. It can be helpful to also avoid returns that go into scientific notation value range - six or seven digits left or right of the decimal place is probably the best range to stick with. Something involving 3 or 4 digit primes as numerators and denominators should do the trick.</p>

<p>Having the two calculators in hand, and your pre-tested formulas, have the students work out by hand, or follow you as you do, the formulas, so that they will know what the <em>real</em> answers are. Run the same formulas on the cheap calculator, showing where it starts to go wrong, and how fast it gets worse. Run the same formulas on the better calculator, showing how much farther into the formulas it gets before it starts to drift, and how much, less, it gets it wrong. If the demonstration has one formula that actually finishes correctly on the better calculator, but not the cheap one, so much the better.</p>

<p>Having the other formulas <em>not</em> come out completely correct, even on the better calculator, leaves room for you to explain why/how rounding errors in float/double can affect programs. Adding in a formula or two that can then be run on the computer (language of choice) that shows the error delta can help drive the point home. If it's also one where they might be tempted to opt for float that is even better.</p>

CC BY-SA 3.0
2018-02-19T20:49:16.190Z
2018-02-19T20:49:16.190Z
Gypsy Spellweaver
<p>Many compilers will promote floats to doubles, do the calculation, and cast back.  I see little or no reason to use floats unless one is dealing with huge matrices of floating-point numbers.  I encourage my students to use doubles for most purposes.  </p>

CC BY-SA 4.0
2018-09-13T15:35:11.473Z
In many resource-constrained settings, like GPGPU work (or just GPU work in general), using floats is necessary. We're using 16-bit floats and 16-bit ints in a lot of circumstances to reduce memory pressure and increase execution speed. If you're writing a website, go ahead and use doubles. If you're writing a game, simulator / numerical modeling, etc., or anything heavy on GPU usage, use the smallest data type that meets the needs of the application.
3Dave
CC BY-SA 3.0
2018-02-17T21:38:30.640Z
2018-02-17T21:38:30.640Z
ncmathsadist
<p>I would highly recommend this <a href="https://stackoverflow.com/a/2386882/2362024">Answer</a> to question what the "Difference between float and double" is. </p>

<p>If not already done in introduction, i would show the math behind floating point representation on a computer (exponent, mantissa, ...). That shall clearly state the difference between those data types and explain why in physics it is not a good idea to CUT precision. If necessary and for fun reason use 64bit datatypes and calculation.</p>

<p>There is one thing where I have trouble with some answers. For good reason never ever teach the comparison of two floating point numbers or in loop counts, etc. The Reason for that can be found in the CERT C Guides <a href="https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152181" rel="nofollow noreferrer">Link</a>!</p>

CC BY-SA 3.0
2018-02-14T07:50:30.040Z
My question is specifically about avoiding showing the mantissa. They wouldn't understand that.
ItamarG3
CC BY-SA 3.0
2018-02-14T17:50:51.257Z
@ItamarG3, If your students really are incapable of understanding what floating point numbers are, then IMO you might as well just say, "Because I _told_ you to," and leave it at that.
Solomon Slow
CC BY-SA 3.0
2018-02-14T17:53:41.060Z
P.S., as other answers have pointed out, you don't have to explain _binary_ floating point.  Decimal is easier to understand, and if you talk about decimal, then "exponent" just means, "move the decimal point this many places to the right or left."
Solomon Slow
CC BY-SA 3.0
2018-02-14T07:47:41.033Z
2018-02-14T07:47:41.033Z
chris.stckhmr
<blockquote>
  <p>Better yet, is there any way I can show the students such an explanation? (Perhaps an online, interactive demonstration of floating point precision etc. - I couldn't find one)</p>
</blockquote>

<p>Show them these bits of code:</p>

<pre><code>float one = 16777291;
float two = one + 1;
System.out.println(one == two);
</code></pre>

<hr>

<pre><code>float one = 1.00000001f;
float two = one + .00000001f;
System.out.println(one == two);
</code></pre>

<hr>

<p>Ask them what they expect these to print. They should print <code>false</code>, right? But when you run them, they print <code>true</code>!</p>

<p>Then explain that this is because <code>float</code> values can only hold a relatively small number of significant digits. Change the <code>float</code> values to be <code>double</code> values and run the code again, and you'll see that <code>false</code> is printed like we'd expect. </p>

<p>Explain that for many purposes <code>float</code> is enough precision, but not for this class. Explain that <code>double</code> has the same problem, but with much more precision. Explain that <code>double</code> precision is enough for this class, but if they need more precision in the future to use <code>BigDecimal</code> or something.</p>

CC BY-SA 3.0
2018-02-13T18:05:02.390Z
2018-02-13T18:13:52.630Z
2018-02-13T18:13:52.630Z
Kevin Workman
<p>Tell the students they have seven decimal digits of precision in a float, and that the decimal point is placed "somewhere" within those seven digits, depending on the magnitude of the number.</p>

<p>Ask them to add 0.01 to 9,999,999 and express the result to seven digits.  Ask what the answer would be if they performed the addition a thousand times.</p>

<p>Now ask them to do the same calculation using 15 digits of precision.</p>

CC BY-SA 3.0
2018-02-23T12:42:57.160Z
As ctrl-alt-delor commented much earlier, the key to understanding float vs. double is the number of significant digits.  More specifically, students should learn that computer arithmetic is *finite-precision* arithmetic.
Bob Brown
CC BY-SA 3.0
2018-02-23T00:01:16.263Z
2018-02-23T00:01:16.263Z
Bob Brown
<p>Luckily this is quite simple to make clear, even if you are steering clear of the IEEE standard.  Honestly, even binary is not needed here.</p>

<p>I would start by borrowing a page from Scheme, and say that we can't make blanket guarantees about the exactness of decimal numbers.  For instance, when we try to express $2/3$ in decimal, and it doesn't work!</p>

<p>All the more so when we are restricted to 10 digits.  We write $0.666666667$.  Why?  It's not that 2/3 is $0.66666667$, it's just that we can't precisely represent $2/3$ in decimal, and at the 10th digit, we just round to get as close as we can.</p>

<p>This is really a problem with any number that has a decimal place.  There are infinite numbers that we can't represent!</p>

<p>The computer has the same problem with decimal numbers as we do.  This isn't a fault of the computer, it's just a feature of floating point numbers, and the computer has to work around it, just like we do. </p>

<p>Now, we do have a way of increasing that precision: we can increase the number of digits allowed.  It doesn't <em>solve</em> the problem, exactly, but it does get us closer to the true numbers.</p>

<p>That's the difference between a <code>float</code> and a <code>double</code>.  A <code>double</code> allows more digits.  And that's why it's usually a better idea to use a <code>double</code>.</p>

CC BY-SA 3.0
2018-02-13T17:57:02.143Z
Add to this, floating point processors since at least the '90s have always converted float to double, easily costing any efficiency they may think to have gained by using the smaller float.
pojo-guy
CC BY-SA 3.0
2018-02-15T14:03:12.833Z
@pojo-guy, Can you provide a reference for that (floating point processors since at least the '90s have always converted float to double). Or, do you just mean up-conversion in mixed-type operations? aFloat + aDouble, for example.
Buffy
CC BY-SA 3.0
2018-02-15T15:31:32.853Z
I'll have to dig up the specs on the 80387 and 68881 math co-processors.  It's been a few decades.
pojo-guy
CC BY-SA 3.0
2018-02-15T16:38:23.107Z
Chapter 2.1 of the 80387 programmers manual - "Eight individually-addressable 80-bit numeric registers, organized as a register stack", and MC68881 reference manual "8 general purpose floating point registers, each supporting a full 80 bit extended precision real data format" . The processors had no facilities for handling "float", apart from converting to and from extended precision.
pojo-guy
CC BY-SA 3.0
2018-02-21T17:46:34.280Z
Modern processor architectures usually have dedicated facilities for single-precision and double-precision computation (x86: see multiple variants of SSE and AVX). Single-precision computation typically provides significant performance advantages (in particular on GPUs) via higher throughput of functional units, lowered bandwidth requirements, and also provides energy savings. Now: Significant research into computing with mixed precision, where most computation is done in single precision and only final refinements in double precision, e.g. work by Stan Tomov and Jack Dongarra.
njuffa
CC BY-SA 3.0
2018-02-21T17:50:45.057Z
So the reason one could state for defaulting to double precision is: It is a convenient way to side-step various fairly difficult to understand (and possibly distracting) issues with numerical analysis in a *teaching* environment. Once the students get to the university level, it will be important to understand these issues.
njuffa
CC BY-SA 3.0
2018-02-21T20:22:34.743Z
@njuffa It sounds like you're hinting at a frame-challenging answer to the question.  If so, have you considered creating an answer?
Ben I.
CC BY-SA 3.0
2018-02-13T17:35:52.577Z
2018-02-14T12:00:57.680Z
2018-02-14T12:00:57.680Z
Ben I.
<p>I keep seeing students use <code>float</code> in lab lessons:</p>

<p>For example, a simple physics calculation of kinematics. Many, many students use <code>float</code> to hold the variables:</p>

<pre><code>float y,g,t,v
</code></pre>

<p>etc.</p>

<p>In this specific lab, they idea is for them to see:</p>

<p>$$y(t_{n+1})=y(t_n)+\frac{\Delta y}{\Delta t}\Delta t\approx y(t_n)+v(t_n)\,(t_{n+1}-t_n)$$
with
$$v(t_{n+1})\approx v(t_n)+g*(t_{n+1}-t_n)$$</p>

<p>and then run over times $\{t_i\}_{i=1}^n$ and see that the $y$ values they get are the same as:</p>

<p>$$y(t_n)\approx y(t_1)+v(t_1)\,t_n+\frac{1}{2}g\,t_n^2$$</p>

<p>However, because they use <code>float</code>, they get rounding errors when dealing with small time differences ($\Delta t$). I don't want to get into the whole floating point arithmetics field, because they won't understand that (the word "exponent" would frighten them, to say the least). </p>

<p>On the other hand, if they use <code>double</code>, then the rounding errors wouldn't be significant (because they aren't dealing with $\Delta t \le 10^{-5}$ of a second). So I try to explain that they should use <code>double</code>, but just stating it as a "rule of thumb" isn't a good idea (because there <strong>are</strong> cases where one would prefer <code>float</code>)</p>

<p>So, what explanation, as to why they should use <code>double</code> for these things, would be compelling? </p>

<p>Better yet, is there any way I can <strong>show</strong> the students such an explanation? (Perhaps an online, interactive demonstration of floating point precision etc. - I couldn't find one)</p>

CC BY-SA 3.0
2018-02-13T17:23:33.883Z
They should have done significant digits in maths class. e.g. “Write your answer to 3 significant digits” They spend a significant time on this.
ctrl-alt-delor
CC BY-SA 3.0
2018-02-13T18:29:15.490Z
If they're doing this level of math, a little exponentiation won't hurt them. If memory serves correctly, this is 10th grade physics. Exponents are introduced in 5th to 6th grade, and polynomial functions occupy most of 7th through 9th grades.
pojo-guy
<data-types><secondary-education><floating-point>
Explaining to students why to use double instead of float (unless there's a very good reason)
# Explaining to students why to use double instead of float (unless there's a very good reason)

(Asked by: username_0 on 2018-02-13)

I keep seeing students use float in lab lessons:
For example, a simple physics calculation of kinematics. Many, many students use float to hold the variables:
float y,g,t,v

etc.
In this specific lab, they idea is for them to see:
$$y(t_{n+1})=y(t_n)+\frac{\Delta y}{\Delta t}\Delta t\approx y(t_n)+v(t_n)\,(t_{n+1}-t_n)$$
with
$$v(t_{n+1})\approx v(t_n)+g*(t_{n+1}-t_n)$$
and then run over times $\{t_i\}_{i=1}^n$ and see that the $y$ values they get are the same as:
$$y(t_n)\approx y(t_1)+v(t_1)\,t_n+\frac{1}{2}g\,t_n^2$$
However, because they use float, they get rounding errors when dealing with small time differences ($\Delta t$). I don't want to get into the whole floating point arithmetics field, because they won't understand that (the word "exponent" would frighten them, to say the least). 
On the other hand, if they use double, then the rounding errors wouldn't be significant (because they aren't dealing with $\Delta t \le 10^{-5}$ of a second). So I try to explain that they should use double, but just stating it as a "rule of thumb" isn't a good idea (because there are cases where one would prefer float)
So, what explanation, as to why they should use double for these things, would be compelling? 
Better yet, is there any way I can show the students such an explanation? (Perhaps an online, interactive demonstration of floating point precision etc. - I couldn't find one)

**Tags:** data-types, secondary-education, floating-point

> **Comments:**
> **username_1**: They should have done significant digits in maths class. e.g. “Write your answer to 3 significant digits” They spend a significant time on this.  
> **username_2**: If they're doing this level of math, a little exponentiation won't hurt them. If memory serves correctly, this is 10th grade physics. Exponents are introduced in 5th to 6th grade, and polynomial functions occupy most of 7th through 9th grades.  

---

## 7 answers

### Answer by username_9 on 2018-02-13. Score: 6 | Accepted answer

Better yet, is there any way I can show the students such an explanation? (Perhaps an online, interactive demonstration of floating point precision etc. - I couldn't find one)

Show them these bits of code:
float one = 16777291;
float two = one + 1;
System.out.println(one == two);


float one = 1.00000001f;
float two = one + .00000001f;
System.out.println(one == two);


Ask them what they expect these to print. They should print false, right? But when you run them, they print true!
Then explain that this is because float values can only hold a relatively small number of significant digits. Change the float values to be double values and run the code again, and you'll see that false is printed like we'd expect. 
Explain that for many purposes float is enough precision, but not for this class. Explain that double has the same problem, but with much more precision. Explain that double precision is enough for this class, but if they need more precision in the future to use BigDecimal or something.


---

### Answer by username_11 on 2018-02-13. Score: 8

Luckily this is quite simple to make clear, even if you are steering clear of the IEEE standard. Honestly, even binary is not needed here.

I would start by borrowing a page from Scheme, and say that we can't make blanket guarantees about the exactness of decimal numbers. For instance, when we try to express $2/3$ in decimal, and it doesn't work!

All the more so when we are restricted to 10 digits. We write $0.666666667$. Why? It's not that 2/3 is $0.66666667$, it's just that we can't precisely represent $2/3$ in decimal, and at the 10th digit, we just round to get as close as we can.

This is really a problem with any number that has a decimal place. There are infinite numbers that we can't represent!

The computer has the same problem with decimal numbers as we do. This isn't a fault of the computer, it's just a feature of floating point numbers, and the computer has to work around it, just like we do.

Now, we do have a way of increasing that precision: we can increase the number of digits allowed. It doesn't *solve* the problem, exactly, but it does get us closer to the true numbers.

That's the difference between a `float` and a `double`. A `double` allows more digits. And that's why it's usually a better idea to use a `double`.

> **Comments:**
> **username_2**: Add to this, floating point processors since at least the '90s have always converted float to double, easily costing any efficiency they may think to have gained by using the smaller float.  
> **username_3**: @username_2, Can you provide a reference for that (floating point processors since at least the '90s have always converted float to double). Or, do you just mean up-conversion in mixed-type operations? aFloat + aDouble, for example.  
> **username_2**: I'll have to dig up the specs on the 80387 and 68881 math co-processors.  It's been a few decades.  
> **username_2**: Chapter 2.1 of the 80387 programmers manual - "Eight individually-addressable 80-bit numeric registers, organized as a register stack", and MC68881 reference manual "8 general purpose floating point registers, each supporting a full 80 bit extended precision real data format" . The processors had no facilities for handling "float", apart from converting to and from extended precision.  
> **username_12**: Modern processor architectures usually have dedicated facilities for single-precision and double-precision computation (x86: see multiple variants of SSE and AVX). Single-precision computation typically provides significant performance advantages (in particular on GPUs) via higher throughput of functional units, lowered bandwidth requirements, and also provides energy savings. Now: Significant research into computing with mixed precision, where most computation is done in single precision and only final refinements in double precision, e.g. work by Stan Tomov and Jack Dongarra.  
> **username_12**: So the reason one could state for defaulting to double precision is: It is a convenient way to side-step various fairly difficult to understand (and possibly distracting) issues with numerical analysis in a *teaching* environment. Once the students get to the university level, it will be important to understand these issues.  
> **username_11**: @username_12 It sounds like you're hinting at a frame-challenging answer to the question.  If so, have you considered creating an answer?  

---

### Answer by username_10 on 2018-02-23. Score: 5

Tell the students they have seven decimal digits of precision in a float, and that the decimal point is placed "somewhere" within those seven digits, depending on the magnitude of the number.

Ask them to add 0.01 to 9,999,999 and express the result to seven digits. Ask what the answer would be if they performed the addition a thousand times.

Now ask them to do the same calculation using 15 digits of precision.

> **Comments:**
> **username_10**: As username_1 commented much earlier, the key to understanding float vs. double is the number of significant digits.  More specifically, students should learn that computer arithmetic is *finite-precision* arithmetic.  

---

### Answer by username_3 on 2018-02-14. Score: 2

Actually, it isn't quite so clear. If I run this in Java:
// Simple computation with float and double
// Increment by a third three times is not the same as incrementing by one
// Float can actually be more accurate than Double in limited cases
public static void main(String[] args) {
    float oneThirdF = 1.0f/3.0f;
    float wholeF = 0.0f;
    float countF = wholeF; //initially equal
    while(countF == wholeF){
        wholeF = wholeF + oneThirdF + oneThirdF + oneThirdF;
        countF = countF + 1.0f;
    }
    System.out.println("Float: " + countF + " != " + wholeF);

    double oneThirdD = 1.0d/3.0d;
    double wholeD = 0.0d;
    double countD = wholeD; //initially equal
    while(countD == wholeD){
        wholeD = wholeD + oneThirdD + oneThirdD + oneThirdD;
        countD = countD + 1.0d;
    }
    System.out.println("Double: " + countD + " != " + wholeD);

}

I get: 
Float: 3.0 != 2.9999998
Double: 2.0 != 1.9999999999999998

So, while doubles are certainly more precise than floats, the place in a "floating point" computation at which things go wrong depends on a lot more than which form you use. Here Float was a bit more "accurate" initially, since Double failed earlier. 
Lessons: Don't use such things for counting. If you need to do computation use the form with more precision. Beware of the results. And testing for equality is pointless (it's why Zeus created Epsilon). 
Finally, though this code doesn't illustrate it, there are situations in which the errors are larger than the answers, so saying x ± ε might be entirely meaningless if x is small and ε is large. 
However, if your use is to take a physical reading from some sort of equipment (say temperature) and report it, with little computation, the shorter (float) type is almost certainly sufficient and likely has more precision than necessary. When there is a lot of computation, use double along with sophisticated error control techniques. 

For a (long) explanation of floating point errors see: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html. This is valid for any language using the IEEE 754 standard (most modern languages and processors).

> **Comments:**
> **username_2**: ... and never use floating point to represent money.  At 11 million dollars plus or minus you start losing the pennies, and your company's accountant will feed you to the alligators slowly.  
> **username_3**: @username_2 Actually money is one of the most complex data types. It has both place and time dimensions. It means something different today than in 6 months and it means something different in the US and the EU.  An early chapter in https://martinfowler.com/books/ap.html explains the complexity.  

---

### Answer by username_4 on 2018-02-19. Score: 1

Simple demonstration of "precision" using handheld calculators.

Get a pair of calculators. One cheap model that has a limited number of digits in its display. Models can be found built in to clipboards and other "office" things. One decent model, not necessarily a *good* model, that has double the digits of the other calculator. If it has exactly double the display size of the first, so much the better.

*One point to be aware of is that many calculators, even the cheap disposable ones, will have at least one significant digit beyond the display to help hide/correct rounding errors.* The demonstration will have to be tested on the specific models you use before class.

Develop some short, and simple, formulas that will develop rounding errors quickly. Thirds, and harmonics thereof, usually are corrected by the hidden digit(s), but higher factors tend to do better. It can be helpful to also avoid returns that go into scientific notation value range - six or seven digits left or right of the decimal place is probably the best range to stick with. Something involving 3 or 4 digit primes as numerators and denominators should do the trick.

Having the two calculators in hand, and your pre-tested formulas, have the students work out by hand, or follow you as you do, the formulas, so that they will know what the *real* answers are. Run the same formulas on the cheap calculator, showing where it starts to go wrong, and how fast it gets worse. Run the same formulas on the better calculator, showing how much farther into the formulas it gets before it starts to drift, and how much, less, it gets it wrong. If the demonstration has one formula that actually finishes correctly on the better calculator, but not the cheap one, so much the better.

Having the other formulas *not* come out completely correct, even on the better calculator, leaves room for you to explain why/how rounding errors in float/double can affect programs. Adding in a formula or two that can then be run on the computer (language of choice) that shows the error delta can help drive the point home. If it's also one where they might be tempted to opt for float that is even better.


---

### Answer by username_5 on 2018-02-17. Score: 1

Many compilers will promote floats to doubles, do the calculation, and cast back. I see little or no reason to use floats unless one is dealing with huge matrices of floating-point numbers. I encourage my students to use doubles for most purposes.

> **Comments:**
> **username_6**: In many resource-constrained settings, like GPGPU work (or just GPU work in general), using floats is necessary. We're using 16-bit floats and 16-bit ints in a lot of circumstances to reduce memory pressure and increase execution speed. If you're writing a website, go ahead and use doubles. If you're writing a game, simulator / numerical modeling, etc., or anything heavy on GPU usage, use the smallest data type that meets the needs of the application.  

---

### Answer by username_7 on 2018-02-14. Score: 0

I would highly recommend this [Answer](https://stackoverflow.com/a/2386882/2362024) to question what the "Difference between float and double" is.

If not already done in introduction, i would show the math behind floating point representation on a computer (exponent, mantissa, ...). That shall clearly state the difference between those data types and explain why in physics it is not a good idea to CUT precision. If necessary and for fun reason use 64bit datatypes and calculation.

There is one thing where I have trouble with some answers. For good reason never ever teach the comparison of two floating point numbers or in loop counts, etc. The Reason for that can be found in the CERT C Guides [Link](https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152181)!

> **Comments:**
> **username_0**: My question is specifically about avoiding showing the mantissa. They wouldn't understand that.  
> **username_8**: @username_0, If your students really are incapable of understanding what floating point numbers are, then IMO you might as well just say, "Because I _told_ you to," and leave it at that.  
> **username_8**: P.S., as other answers have pointed out, you don't have to explain _binary_ floating point.  Decimal is easier to understand, and if you talk about decimal, then "exponent" just means, "move the decimal point this many places to the right or left."  

---

