Date: Mar 5, 2013 4:52 PM
Author: Derek Goring
Subject: Re: Ismember/intersect not possible with serial date numbers?
On Wednesday, March 6, 2013 10:35:10 AM UTC+13, Vegard wrote:

> TideMan <mulgor@gmail.com> wrote in message <196edca6-cae0-4abb-8519-

>

> >

>

> > The answer is in this FAQ:

>

> > http://matlab.wikia.com/wiki/FAQ#Why_is_0.3_-_0.2_-_0.1_.28or_similar.29_not_equal_to_zero.3F

>

> >

>

> > The way I'd do it is, instead of finding the intersection of floating point numbers which is problematical, convert them to strings using datestr, then intersect will work OK.

>

>

>

> Hi TideMan,

>

>

>

> thanks for your input. I understand that intersecting floating point numbers may be risky, so I will probably go back to using date vectors instead - I suppose they work just as well as strings? Generating date strings seems to be slow...

>

>

>

> I still find it a bit strange, though, that year_serial1 and year_serial2 below produce different results (year_serial2 gives the correct results) when used in the intersection command:

>

>

>

> startendyear_vec = [1968 1 1 0 0 0; 1968 12 31 23 59 00];

>

> startendyear_serial = datenum(startendyear_vec);

>

> year_serial1 = (startendyear_serial(1):1/24/60:startendyear_serial(2))';

>

> year_vec = datevec(year_serial1);

>

> year_serial2 = datenum(year_vec); % But remove this comment and it works!

>

>

>

> I suppose the datevec command in the fourth line can take serial date numbers with some roundoff error and still understand which date/time was intended to be there? And then the datenum command in the last line produces as precise serial date numbers as possible? While the intersect/ismember commands works with strict == comparisons and cannot tackle any roundoff error at all?

>

>

>

> Anyway, thank you both for your help!

If you're finding that "strange", then you don't understand/haven't read the FAQ.

Look at this:

>> format long

>> 1/24/60

ans =

6.944444444444444e-004

This is the increment you are using in generating year_serial1.

Clearly, there will be round-off error because of all those digits.