Re: [boost] date_time request for addition

From: Pavol Droba (droba_at_[hidden])
Date: 2004-11-22 16:33:58

On Mon, Nov 22, 2004 at 01:39:27PM -0700, Jeff Garland wrote:
> On Mon, 22 Nov 2004 19:09:38 +0100, Pavol Droba wrote
> > Oh, sorry, I did mean time_duration. I will give an example.
> > Imagine, that you have time_duration that spans over multiple years. 
> > Internal ticks_ value is quite large number.
> > 
> > Now lets's say it is 1000000 ... I'd like to multily it by 0.55. It 
> > will be nice integer after the operation. But there is no other 
> > reasonable way to do if otherwise.
> > 
> > Just in case you wondering what can be use case for such an 
> > operation, imagine a graph where x-axis represents a timeline 
> > between two timestamps. If you want to draw a grid, you will need to 
> > multiply the time difference by 0.1 0.2 0.3 and etc.
> 
> Actually, I think there is an easier way.  I'd calculate the difference 
> between the 2 timestamps (divided by the number of divisions) to get the 
> the 'step' of the grid.  Then I'd create time_iterator with the calculated 
> step to generate the values of the grid.  If you haven't used the 
> time_iterator you might have a look at:
> 
> http://www.boost.org/doc/html/date_time/posix_time.html#date_time.posix_time.
> time_iterators
> 

I see, that I haven't gave the best example. I was just trying to point out
the problem, unfortunately, you have provide me with solution to another one.

So here is another example. 

Imagine a statistical system. Now the input can be arbitrary type of date. If would 
be very hard to make the algorithm that works for any particular type or combination of types. 
Therefor, data is normalized. i.e. converted to a real number from interval <0,1>.
Algorithm process these normalize values and at the end results are expanded
to the original types.

This is a common practice when multitype data must be handled and they are intermixed.

Now it is clear, that for the expansion, one need to multiply a time_duration
by a real number factor.

Regards,

Pavol