Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Topic: Ismember/intersect not possible with serial date numbers?
Replies: 5   Last Post: Mar 6, 2013 4:03 PM

 Messages: [ Previous | Next ]
 Derek Goring Posts: 3,922 Registered: 12/7/04
Re: Ismember/intersect not possible with serial date numbers?
Posted: Mar 5, 2013 4:52 PM

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.

Date Subject Author
3/5/13 Derek Goring
3/5/13 dpb
3/6/13 Steven Lord
3/6/13 dpb