Display precision vs actual precision

Hi everyone We are running some simulations in MATLAB and storing the results afterwards. Yet, we are concerned that the actual precision of the number format used to solve the equations might be huge with respect to what we actually need. For instance, one of the output variables of the program is voltage, which is bound to -120<=V<=40 and we require a max resolution of about 0.01, no more than that....my guess is that the number precision provided by MATLAB is exceeding our needs and this is costing us computing time.....

any comments on this?

thanks!

mario

[Sara]

It's preferable to do all your calculations with higher precision than needed and only round the results. You may use single variables instead of the default (double) but I'm not sure you'll have any speed up. You could build a toy problem and check it out.

[Seth Wagenman]

Do the toy problems below convince you that speed will increase if you use single variables vs. doubles?

Answer 1

[Image Analyst]

Your only choices are to cast your variables to single or double. The calculations will take the same amount of time no matter if you use "format long" or "format short" - the number of decimal places upon output do not have any effect on what's being used in the mathematical operations. Using single will cut your memory usage down by half.

Using single will make the calculations faster. See this demo:

m1 = rand(12345,12345);
m2 = rand(size(m1));
tic;
for expt = 1 : 10
  m3 = m1 .* m2;
end
toc;

m1 = single(m1);
m2 = single(m2);
tic;
for expt = 1 : 10
  m4 = m1 .* m2;
end
toc;

The results:

Elapsed time is 2.756050 seconds.
Elapsed time is 1.518655 seconds.

[Salaheddin Hosseinzadeh]

Wow! Amazing!

[Seth Wagenman]

I do not know what "expt" and the loop was for (and my computer froze when I tried the script above) so I tried this and got similar results:

m1 = rand(999,999);

m2 = rand(size(m1));

tic

m3 = m1 .* m2;

toc

m1 = single(m1);

m2 = single(m2);

tic

m4 = m1 .* m2;

toc

Elapsed time is 0.011342 seconds.

Elapsed time is 0.007512 seconds.

Answer 2

[Andrew Reibold]

To round to the hundredths place

X_rounded_to_hundredth = round(X*100)/100

Matlab still stores '0's after though. Not sure if you can increase computing time.

[Andrew Reibold]

Tested above. Saves no time if any at all. Sorry bub. Maybe another solution exists.

x = 123456789.123456789;
xrounded = round(x*100)/100;
y=0;
z=0;

tic
for i=1:1000000000
y = y + x;
end
toc

tic
for i=1:1000000000
z = z + xrounded ;
end
toc

I also tried a toy of Saras suggested solution of converting to single. To retain the correct amount of decimal points, I multiplied it by 100, stored as single, performed operations, then turned back to double and divided by 100.

This actually took me more time then the original though, and I didn't include the initial conversion time even... :-/

xsingle = single(x*100);
a=single(0);

tic
for i=1:100000000
a = a + xsingle ;
end
x = double(xsingle)/100;
toc

[Andrew Reibold]

Also, I have never really had issues with decimal precision being the culprit when it comes to computing time.

I would check the processes being used for data passing, and see if any prebuilt functions are draining your time.

Make sure to initialize any growing arrays too, that hurts computing alot.

[Salaheddin Hosseinzadeh]

Oh yeah!

single

is also good!

[John D'Errico]

Surprisingly, single computes are often SLOWER than those with doubles. Unless you are pressed for space, there is no reason to use singles.

[Image Analyst]

I've heard that (because modern CPUs are so highly optimized that it doesn't matter), so that's why I wrote my code - to test it. Surprisingly I found, at least for that one example, that the single calculations took about half as long, though perhaps it might be dues to a memory thrashing issue due to larger arrays rather than purely due to the multiplication times. I should test that.

[Seth Wagenman]

One problem with single variables...if they are ever part of any future calculation, all products become single variables as well, even if a double were part of the calculation.