2008/5/22, James Porter <porterj@alum.rit.edu>:
On Thu, May 22, 2008 at 3:56 PM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
Incrementability seems also more fundamental to me than Addability. Which is to say that a concept or algebra that offers Addability almost certainly also has a Incrementability, but not the other way round. Take for instance the Peano Axioms of natural numbers, where Incrementability is given in the form of the fundamental successor function.
Not necessarily true. Strings under concatenation (a monoid) are Addable, but incrementing makes little sense.
only syntactically an Addability, semantically rather Concatenatablity (strange word ;-) But you are right. I focused too much on integral numerical types.
Further, incrementing on even the real numbers doesn't necessarily make sense,
therefor my interval containers provide a different implementation for continuous types that does not require incrementation.
at least not when defined in terms of the successor function (which maps integers to integers). Complications also arise in, well, complex numbers. ;)
Dates/times are a more unusual case because their underlying representation is integral, but as a physical concept they are continuous (as far as we know). Questions arise especially when considering the granularity of the date/time you are dealing with. Is foo_date+1 24 hours from now, or one second from now? Or perhaps one millisecond... What I've learned is that in boost::date_time, this is handled via different duration types
time_type operator+=(const date_duration_type& dd); time_type operator+=(const time_duration_type& td); which is nice. Yet as for date/time parameters for my interval and interval containers templates my implementation relies on the existence of incrementation on the least available time unit in order to decide things like [1704, 4712) == [1704, 4711]
I don't think incrementability is as simple as incrementing the private member of the date_time object.
The date and time implementations that I've seen so far are all based on integral numeric types including boost::date_time. Implicit in this implementation is the property of a least incrementable unit. Based on this property incrementation and decrementation can always be implemented. To me this seems to be a rather universal property and not only detail of the implementing private member. cheers Joachim