|
Boost Users : |
From: Erik Thiele (erik.thiele_at_[hidden])
Date: 2019-05-23 05:37:46
Am Thu, 23 May 2019 11:18:43 +1200
schrieb Gavin Lambert via Boost-users <boost-users_at_[hidden]>:
> On 23/05/2019 00:30, Erik Thiele wrote:
> > if the time_duration datatype is a complete partial order which is
> > for example needed for it to be able to be sorted, then the above
> > output is partly illegal:
> >
> > if not a<b and not b<a then must be a=b. but this is not the case.
> >
> > if a<=b and b<=a then must be a=b. but this is not the case.
>
> not_a_date_time is like a NaN. NaNs are weird like that.
i don't think we should mix floating point issues with the date_time
library.
> Returning true for the <= and >= operations is probably actually a
> bug; it's a side effect of using less_than_comparable when it should
> be using partially_ordered instead. You should raise an issue about
> that on GitHub or submit a PR to fix it.
I will raise an issue.
> > so as expected the two vectors v0 and v1 are not equal after being
> > sorted even though they certainly should be!
>
> A default constructed time_duration is equal to zero duration. A
> not_a_date_time time_duration is not a zero duration. Why would you
> expect them to be equal?
I do not expect time_duration(not_a_date_time) and
time_duration(hours(0)) to be equal. instead i expect them to be not
equal. actually they are not equal, which is correctly reported by
operator==. but i expect v0 and v1 to be equal because after sorting two
vectors with the same contents must be equal. watch closely, v0 and v1
have the same elements. they are just push_backed in a different order.
so after sorting v0 and v1, they need to be equal, but aren't. this is
because operator< is not a complete partial order here.
> > i do not understand why time_duration is behaving in such a strange
> > way here.
> >
> > I am using time_duration(not_a_date_time) as a SQL-NULL value just
> > like i am using date(not_a_date_time) and ptime(not_a_date_time) as
> > SQL-NULL values.
>
> SQL NULLs are weird, just like NaNs, so this should not be surprising
> to you.
I do not share the opinion that anything is weird :-) I was just
looking for a reason for the asymmetry here. anyway i think it is not
possible anymore to change this since there is too much code using the
library out there and everybody is now used to this asymmetry.
but the operator< issue can hopefully be fixed. i make a report.
cu
erik
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net