Unexpected rounding of numbers by matlab??? Why it is happening?

Dear Community,

can anyone explain me why Matlab rounding my data during assigning of the value(s) to a variable(s)????

Description:

My code started rounding values by himself during the data analysis, nevertheless that it was working nicely for months before. During execution the code I am extracting the data y_lim and ybin:

h=binscatter(x,y,250,'FaceAlpha',1);
h.ShowEmptyBins = 'off';
ax = gca;
ax.YScale="log";
ax.XLim=([-2 20]);
y_lim=h.YLimits
ybin=h.YBinEdges

the results presented in the WORKSPACE are obviously wrong: y_lim = [0, 1.005]

if in COMMAND Window i look on h handler properties, i see the correct data:

YLimits: [1.002305238077898e-06 1.002305238077898e+00]

ok... then I tried to access to my handler h in the command window and i got a correct result:

>> h.YLimits

ans = 1.002305238077898e-06 1.002305238077898e+00

Next step made me crazy. I assign the variable y lim using the same command like i used in the code and got CORRECT value:

>> y_lim=h.YLimits

y_lim =

1.002305238077898e-06 1.002305238077898e+00

CAN anyone help me with this issue??? Is this a matlab bug or i don't understand something.

[KSSV]

Read about format.

[Sergii Snegir]

Thanks for suggestion. It does not lead to a better result. In the commant line I see the result when chaging the format, but not in the workspace!

[dpb]

MATLAB isn't rounding anything; you're just expecting an output formatted display that, as far as I can tell, MATLAB doesn't give you control over.

I never use the workspace (had to go find it to look at it for a refresher) but it's just a shorthand glimpse into the the variables you have defined currently -- if it used long g or similar instead as the format, then it would take up the whole screen and lose the compact overview and whatever utility it does have.

As you can see at the command window or will see if/when you print or write date to files, the values are still held in memory in full precision.

What are you trying to accomplish that you can't do, specifically, other than wish for what isn't there?

There does not seem to be (at least thru R2020b that I have installed) a way to set a display format in the preferences for the workspace.

You could always submit an enhancement request if you think this is important and can justify why the present view isn't adequate.

[Cris LaPierre]

Save your x and y data to a mat file and attach it to your post using the paperclip icon.

[Sergii Snegir]

to save the data to file is the FINAL problem ! As soon as i save my data to fig file all data values are "rounded"

[Cris LaPierre]

Don't save to a fig file. Save your workspace variables to a mat file.

[Bjorn Gustavsson]

Save your data to a .mat-file.

[Steven Lord]

Let's say that I have a vector with the net worths of two people. One is my nephew, who has a bit of spending money from his allowance and his birthday.

nephewNW = 50;

The second is Bill Gates's net worth.

gatesNW = 126.2e9;

What happens if I put them in a vector?

netWorths = [nephewNW, gatesNW]

netWorths = 1×2

1.0e+11 * 0.0000 1.2620

Compared to Bill Gates's net worth, my nephew has no money. Does the way that it is displayed in the netWorths variable affect how it is stored?

x = netWorths(1)

x = 50

No. You're in a similar situation. Don't confuse how the numbers are displayed and how they are stored. The numbers are not stored rounded.

[Sergii Snegir]

Below, is the link with Raw matlabdata file and the script itself:

https://cloud.uni-konstanz.de/index.php/s/arB92eABi6izNEW

[Sergii Snegir]

Dear Steven Lord,

thank you very much that you showed one more time like "this" thing works. Somehow, my code used to work for a month nicely, and now I am asking for the solution!

Oposit to your statement "The numbers are not stored rounded." - they can be stored in a separate file *.mat only like a rounded

The data set saved some month ago:

The same data set as above saved today:

[dpb]

Don't use external links, attach the code itself.

Whatever you did, your script/function changed; MATLAB will NOT round data without being explicitly told to do so; you are misunderstanding what it is you're looking at and/or from whence and how you got the two datasets to compare.

We need an actual example of what you did that can be run to illustrate all posted here as text and/or downloadable files and not on some external site.

[Sergii Snegir]

Sorry, but I can not attach 450mb of my initial data file. I was trying to save only X,y data sets before plotting them, but observed, that saved mat files contain already rounded values.... Any ideas how to deal with the file saving???

[dpb]

You can certainly save a small(ish) example dataset and attach the code here...it doesn't take 450MB of data to illustrate a problem.

Others have already told you what to do -- save data variables in .mat files, not as figures for ease of use and speed.

Even though it's inefficient to do so, a .fig file does still contain all the data in the X|YData variables as is also easily demonstrated -- it so happens have another dataset downloaded from a previous Q? that has variables that illustrate the similar issue of disparate magnitudes -- so will use it for illustration--

>> format long, format compact
>> [[min(data(:,1)) max(data(:,1))];[min(data(:,2)) max(data(:,2))]]
ans =
   1.0e+12 *
   1.587081600000000   1.587168000000000
   0.000000000000762   0.000000000836381
>> format short, format compact
>> [[min(data(:,1)) max(data(:,1))];[min(data(:,2)) max(data(:,2))]]
ans =
   1.0e+12 *
    1.5871    1.5872
    0.0000    0.0000
>> [min(data(:,2)) max(data(:,2))]
ans =
    0.7615  836.3806
>> format long, format compact
>> [min(data(:,2)) max(data(:,2))]
ans =
   1.0e+02 *
   0.007615482200000   8.363806400000000
>> 

which shows the apparent "rounding" in the displayed values at various levels depending on the display format chosen and which variables are tried to be displayed together such that MATLAB has to scale to get them shown together.

Now we'll plot one and look at figure...

>> isOK=isfinite(data(:,2));                % there happen to be a bunch of NaN; we'll skip them
>> hL=plot(data(isOK,1),data(isOK,2));      % plot
>> all(hL.YData.'==data(isOK,2))            % compare to the input data the fig copies
ans =
  logical
   1
>> all(hL.XData.'==data(isOK,1))
ans =
  logical
   1
>> 

shows that all the values in the figure data properties are the same as the in-memory data to full precision; no rounding has taken place.

Now

>> savefig('Data.fig')                      % write out a .fig file
>> close all                                % close that figure completely
>> hF=openfig('Data.fig');                  % load the saved figure
>> clear hL                                 % get rid of old line handle completely, too
>> hAx=gca;hL=hAx.Children;                 % retrieve the line handle from loaded fig
>> all(hL.XData.'==data(isOK,1))            % and compare again to the original data array
ans =
  logical
   1
>> all(hL.YData.'==data(isOK,2))
ans =
  logical
   1
>> 

MATLAB has NOT done any rounding at all...while it's an inefficient storage mechanism, nothing is lost and if one were to need to regenerate the figures anyway, then it might save some time if they had been extensively customized before saving.

>> !dir data.fig
 Volume in drive C is OS 
 Volume Serial Number is 3260-4552 
 
 Directory of C:\Users\Duane\Documents\MATLAB\Work 
 
06/18/2021  10:30 AM            35,193 Data.fig 
               1 File(s)         35,193 bytes 
               0 Dir(s)  803,652,620,288 bytes free 
>> XY=data(isOK,1:2);
>> whos XY
  Name        Size            Bytes  Class     Attributes

  XY        342x2              5472  double              

>> save dataXY XY
>> !dir dataXY.mat
 Volume in drive C is OS 
 Volume Serial Number is 3260-4552 
 
 Directory of C:\Users\Duane\Documents\MATLAB\Work 
 
06/18/2021  10:40 AM             3,643 dataXY.mat 
               1 File(s)          3,643 bytes 
               0 Dir(s)  803,652,603,904 bytes free 
>> 

shows about a 10X overhead in the .fig file as compared to just saving the data itself in a .mat file

The moral is -- you've done something different than you think you have done -- we can't diagnose what that might be without the full details but you'll need to attach stuff here to illustrate just what you have done to expect somebody to fully diagnose the root cause.

Answer 1

[Sergii Snegir]

Dear dpb and all users,

enclosed are two files. MLX file is the original code that I am using for processing the data (up to the line 83). After the line 83 I plot the x, y data using the histogram function. This x, y, data you may find in another mat file (enclosed).

I need to save into mat file: x_lim=h.XLimits; y_lim=h.YLimits, counts=h.Values; xbin=h.XBinEdges; ybin=h.YBinEdges

After saving them, I have "rounded" data . Instead of YLimits: [1.0023e-06 1.0023] (i see in handler h), I have all the time exported

>> h.YLimits

ans =

0.0000 1.0023

[Steven Lord]

Please run these three commands and show us exactly what the first and third display.

h.YLimits
format longg
h.YLimits

[Sergii Snegir]

this is the result obtained in the command window:

I have also immediately tried to place "format long" into my code... it does not improve/change the data unfortunately

h=binscatter(x,y,250,'FaceAlpha',1);
h.ShowEmptyBins = 'off';
ax = gca;
ax.YScale="log";
ax.XLim=([-2 20]);
% ax.YLim=(cond_lim);
% format short e
% format compact

x_lim=h.XLimits;
% format short e
% format compact
format longg
y_lim=h.YLimits
counts=h.Values;
xbin=h.XBinEdges;
ybin=h.YBinEdges


xy=[xbin',ybin'];
exportPath2_cont=sprintf('figures\\contours\\%s_from_2D-histo_X_Y',timestamps(1,1));
save(sprintf('%s_counts.mat',exportPath2_cont), 'xbin','ybin','x_lim','y_lim');
writematrix(xy, sprintf('%s_counts.csv',exportPath2_cont));

[John D'Errico]

Please don't use an answer just to make a comment or response to other comments.

Answer 2

[Walter Roberson]

Go into Preferences -> MATLAB -> Variables -> Format

and set "long g"

Go into Preferences -> MATLAB -> Command WIndow -> Text Display -> Numeric format:

and set "long g"

Then OK to save the changes of preferences.

Now quit and re-enter MATLAB.

Once you have done this, then the Variable Browser that you are relying on will default to showing your data in "long g" format, and the command window will default to displaying in "long g" format as well. MATLAB will reset to these two "long g" preferences each time you start MATLAB.

You are being fooled by the fact that the Variable Browser is not affected by the "format" command.

[Sergii Snegir]

Dear Walter,

many thanks. But your proposition is not working also!! After executing the code h.Ylimits has, as expected, long g format .But when I call this value from the variable (figure below), which storse this value y_lim=h.YLimits, the value is "rounded". The same problem I see when I export this value to the mat file

Interesting observation I just saw. When after the code execution in the command window i assign one more time y_lim=h.YLimits, the CORRECT values are appearing in the workspace!!!!

[dpb]

h.Ylimits and y_lim above are NOT the same variable.

[Walter Roberson]

What is size(h) ?

[Sergii Snegir]

>> size(h)

ans =

     1  

[Walter Roberson]

Ummm... then what is

class(h)

Whatever h is, it is no longer the binscatter object that you assigned in the code. When you apply size() to a binscatter object, the result will always have a minimum of two values, never one.

Or perhaps I should ask what shows up for

which size(h)

as perhaps you have replaced the size function with something else.

[Sergii Snegir]

>> class(h)
ans =
    'matlab.graphics.chart.primitive.Binscatter'
>> which size(h)
built-in (C:\Program Files\MATLAB\R2020b\toolbox\matlab\elmat\size)

In the workspace h is presented as 1x1 Biscatter

[Walter Roberson]

It makes no sense to me at the moment why size(h) would show up as

ans =
     1  

for you, instead of as

ans =

     1     1

I think you should open a technical support case on to resolve that. If your MATLAB has gotten corrupt, we cannot know how else it might misbehave.

[Sergii Snegir]

Doy you think it is better to re-instal this version of Matlab???

[Walter Roberson]

I recommend that you re-check whether size(h) is still showing

ans =
     1 

instead of

ans =
     1     1

If it is still showing the single 1 instead of the pair of 1 then Yes, you should reinstall MATLAB.

[Sergii Snegir]

Dear Walter,

as you mentioned i changed the version of Matlab from 2020a to 2020b.

At least now size(h) looks correct:

>> size(h)

ans =

     1     1

>> 

I will continue to verify all your previous propositions and from others to fix the main problem

[Sergii Snegir]

Unfortunately, after some tries, and after changing the way to acces the data (including cnahging the format), the export *.mat still contain a short format of the data. Below is the last version of my code:

Please, any ideas more!

format shortg
%format longEng
format compact

h=binscatter(x,y,250);
h.ShowEmptyBins = 'off';
set(gca, 'YScale', 'log');
ax = gca;
ax.XLim=([-2 20]);



x_lim= get(h,'XLimits')
y_lim= get(h,'YLimits')
counts=get(h,'Values');
xbin=  get(h,'XBinEdges');
ybin=  get(h,'YBinEdges');



xy=cat(2,x,y);
exportPath2_cont=sprintf('figures\\contours\\%s_from_2D-histo_X_Y',timestamps(1,1));
save(sprintf('%s_counts.mat',exportPath2_cont), 'xbin','ybin','x_lim','y_lim');

[Bjorn Gustavsson]

When you explicitly tell matlab:

format shortg

Short-format is what you will have displayed for all numbers. That is a setting for displaying set in that script.

[Sergii Snegir]

Dear Bjorn,

your proposition was tested and after saving the data to mat file the values are shorterned...but why, no one can tell me!!! I tried fromat shortg, did not help

format shortg
format compact

h=binscatter(x,y,250);
h.ShowEmptyBins = 'off';

ax = gca;
ax.XLim=([-2 20]);



x_lim= get(h,'XLimits')
y_lim= get(h,'YLimits')
counts=get(h,'Values');
xbin=  get(h,'XBinEdges');
ybin=  get(h,'YBinEdges');



xy=cat(2,x,y);
exportPath2_cont=sprintf('figures\\contours\\%s_from_2D-histo_X_Y',timestamps(1,1));
save(sprintf('%s_counts.mat',exportPath2_cont), 'xy');
% writematrix(xy, sprintf('%s_counts.csv',exportPath2_cont));

[dpb]

>> load 20210503130530_from_2D-histo_X_Y_counts.mat
Error using load
Unable to read MAT-file C:\Users\Duane\Documents\MATLAB\Work\20210503130530_from_2D-histo_X_Y_counts.mat. Not a binary MAT-file. Try load -ASCII to read as text. 
>> 
>> !dir 20210503130530_from_2D-histo_X_Y_counts.mat
 Volume in drive C is OS 
 Volume Serial Number is 3260-4552 
 
 Directory of C:\Users\...\Documents\MATLAB\Work 
 
06/25/2021  07:36 AM                 0 20210503130530_from_2D-histo_X_Y_counts.mat 
               1 File(s)              0 bytes 
               0 Dir(s)  805,391,179,776 bytes free 
>> 

The attached data file is empty so can't duplicate your results but still haven't shown us anything that proves that save of a binary .mat file rounds anything at all -- but certainly if you write an ASCII file instead values will be 8 digits of precision unless also specify the "-double" switch. The above code doesn't contain either, so should be a binary file which will have full machine precision as I demonstrated very early in the conversation with example.

But if you continue just looking at the results in the command window or through echoing values in a script, as Bjorn says, if you set the format as shortg then that's what anything you see is going to reflect. What that display shows then has no bearing on the full precision of the data in memory, only in what is displayed to the command window.

Without the file itself to compare, we can't but believe that MATLAB behaves as it should -- the binary-form .mat file will contain the data to the full precision of the variable type that is saved and the values displayed in command window or as formatted strings will reflect what the current FORMAT setting is or the specific format string used to convert them from internal to character representation.

[Bjorn Gustavsson]

@Sergii Snegir, no it is no "proposition" of mine. I directly quoted your script. There you instructed matlab to display numerical values in shortg compact format. That is then the format matlab will display values in. See the help and documentation for format. Try to replace the two format-calls to:

format long

or

format longe

or

format longg

[dpb]

@Sergii Snegir -- Also Nota Bene that the "g" format whether short or long will always pick the format that is "most compact" between a fixed-decimal or scientific notation format on its own volition so you can't control precisely how the data are going to be displayed; it's dependent upon the actual value.

If you want to see the full precision of the data visually as it is stored internally, then use the

format longE

form.

But again, it can't be emphasized too much that you appear to still be completely ignoring/oblivious to the difference between what is displayed on the screen and what the value of a variable in memory is -- and that one is simply a representation of the other in a particular format -- and that changing that format has no bearing at all on the actual value in memory that MATLAB uses.

[ytzhak goussha]

if the problem is with display, try multimpling the number the appears as zero by a big number 1e10, if it is zero the result will be zero, and if it is a small number like 1e-6 it will display a non-zero result