Thank you for the comment. I will be revisiting this soon when I add the nesting calls to
main2d and
main3d. I will take your suggestion into account. You are right about the issue of dealing with large numbers
Yes, the round-off in Matlab is very delicate. I struggled with this about a month ago. Just try this simple statement and you will be surprised about the result:
Code:
>> format long eng
>> double(single(1.0d+12))
ans = 999.999995904000e+009
>> eps(1.0d+12)
ans = 122.070312500000e-006
In the script to read NetCDF data that we distribute,
matlab/utility/nc_read.m, I have to put the following logic to process
_FillValue and
missing_value attributes:
Code:
if (got.FillValue || got.missing_value),
if (iscellstr(f) || ischar(f)),
ind=find(f == spval);
f(ind)=spval;
else
ind=find(abs(f-spval) < 4*eps(double(spval)));
end
end
Notice that to find the special values correctly, I need to have
abs(f-spval) < 4*eps(double(spval)) to get the correct solution that accounts for Matlab round-off. They have made a lot of decisions to accelerate computations that compromise precision. There is nothing like IEEE floating-point arithmetic in Matlab. Here
f is the data read from the NetCDF file and
spval is the attribute value in its native file precision.
In Fortran, we need a function with similar capabilities as
eps to do this comparisons according to the computer round-off.
I was completely surprised that all the Matlab interfaces out there and scripts to read NetCDF data are not taken into account the round-off inherent to Matlab. This gives surprising results sometimes. See the following
ticket for details about processing NetCDF data.