On Wednesday, March 6, 2013 10:35:10 AM UTC+13, Vegard wrote: > TideMan <firstname.lastname@example.org> 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
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.