Saving the wrong datenum value, but the original variable contains the correct one

Hello everyone,

I'm facing an odd problem. I'm temporally colocating data from different instruments in a range of ± 12h, to do so I convert date and time in datenum and use 'Find', it works perfectly. However, I just realize an oddity, when a colocation is found I save the datenum of both instruments in a new variable together with other data and the datenum of one of the two instruments is not saved correctly. I attach an image to show that values get saved differently and the lines I use to save the value in the final variable.

If I run seprately the 'datenum_RO(:,y').*ones(600,1)' part only, it gives me the right datenum value, however it saves it wrong in prof_ro. It looks like is not keeping the decimals. What should I say to let it keep them? It's doing it only for the datenum, and not for the other values.

y correspond to colum #10

prof_ro(var,1:600,1:14)= [j.*ones(600,1) datenum_RO(:,y').*ones(600,1) Lat_RO(:,y') Lon_RO(:,y')...
                                    bangle(:,y') temp(:,y') pres(:,y') refr(:,y') density(:,y') spc_hum(:,y') ...
                                    datenum_iasi(b,1).*ones(600,1) Lat_iasi(b,1).*ones(600,1) Lon_iasi(b,1).*ones(600,1) ...
                                    SO2_iasi(b,1).*ones(600,1)];

[Peter Perkins]

Are you certain this is not just a display issue?

[Valeria Cigala]

I am certain this is not a display issue. If I run a datestr on prof_ro(1,2) the date is different than in datenum_RO(1,10).

[Guillaume]

Well, you're doing something wrong. Without seeing your code we can't say what. However, this is troubling: I'm temporally colocating data from different instruments in a range of ± 12h, to do so I convert date and time in datenum. That task is so much easier to do with datetime.

[Valeria Cigala]

I haven't found the use of datetime easier honestly. Datenum works just fine, because the comparison is working very well, what is wrong is what it saves on the prof_ro variable at the end.

If I run the code for this colocation and just check what is the following datenum_RO(:,y').*ones(600,1) with y being the index of the value colocated, the value that gets printed is the right one. However, in the prof_ro variable is saved sort of rounded and thus wrong.

[Peter Perkins]

As stated, that seems impossible unless you are either assigning into an integer array (but that apparently can't be the case, because you're showing a screen shot of a double matrix in the variable editor), or you've left something out. If it's really happening, you should be able to set a breakpoint and demnonstrate what's happening with command window output.

Guillaume's advice is worth considering. If you are doing calendar arithmetic and time conversions, you will be much happier with datetime.

Answer 1

[Valeria Cigala]

Problem solved, some of the variables that were saved in prof_ro were double others single and it seems that single ruled, but only the datnum columns were actually affected and lost the decimals.

Can anyone tell me if this is common? Is some sort of unwritten rule I should have been aware of?

Anyway thanks for the suggestions provided.

[Guillaume]

A conversion from double to single wouldn't lose the decimals. A conversion to integer would and that was one of the potential reason suggested by Peter. We discarded it because you show a screenshot that clearly indicates that your variable is double. But perhaps you're temporarily copying the data into an integer array. As I initialy said, show us your code.

If you concatenate arrays of different types, then the resulting array is usually of the narrowest type. e.g. combining double and single result in an array of single. combining integer and double, result in an array of integer. See valid combination of unlike classes.

I don't like that behaviour but that is what it is, and yes, if you're used to C type languages, it's the opposite behaviour.

[Valeria Cigala]

Concatenation of arrays of different type was my mistake indeed. Thanks, I'll definitely remember that now! :)