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: Select all

```
>> 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: Select all

```
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.