Time period

[Alexis EidelMan]

I'd like to open a topic about time period.

In example and probably in many first uses of liam2, the period is an annual period.
I was been told that the period is just an integer, so we can see it differently like a month or a quarter.

But I can see some points which are an handicap to properly work with month.
    1 - period is an integer.
With year it's easy to have a link between an integer and a year as 2010 can be seen in both way.
It's no more the case with a month the month 32 or 2015 doesn't really mean anything. A solution might be 12* year + month, even if it's not so explicit but it has some virtue. It could be great to have 2010-02 for example or 201002 if we want to keep integer. In these case, an issue is that period = period + 1 must be upgraded in
month = month +1;
 if (month == 13) then {month = 1; year = year +1}
Having two fields year and month, with month unavoidable if time_scale < year is also an option to consider.

    2 - alignment
An alignment using a csv file requires period being the same as in the simulation.
Once again, how a month period should be called ?
To not depends on the initial period, a month period should be 12* year + month.
But the specific point to alignment is that we probably don't want to have two different csv file on per month an one per year. It could be nice if with a timescale given as parameter, in case of year alignment, automatically, 12 month are agregated.
In the reverse side, if we have only years in the csv file and running a month scale simulation is wanted, we would want to get the value for the years divide by 12.#

    3 - globals
I don't use globals so far but the previous point can be true here also. We would want globals to be either month value or year value.


And finally, my main point, which you can possibly guess reading above, is that I'd like to run different time scales with same yaml file and just adding a parmeter time_scale. With this parameter and why not adding a type duration (age: int -> age: time) we could translate automatically equations. I mean age < 60 is obvious with time scale = year but should be translated in int(age/12) < 60 with time_scale = month and int(age/4) < 60 with time_scale = quarter


Alexis

[Gaëtan de Menten]

On 24/06/2013 14:22, Alexis EidelMan wrote:
> I'd like to open a topic about time period.
>
> In example and probably in many first uses of liam2, the period is an
> annual period.
> I was been told that the period is just an integer, so we can see it
> differently like a month or a quarter.
>
> But I can see some points which are an handicap to properly work with month.
> 1 - period is an integer.
> With year it's easy to have a link between an integer and a year as 2010
> can be seen in both way.
> It's no more the case with a month the month 32 or 2015 doesn't really
> mean anything. A solution might be 12* year + month, even if it's not so
> explicit but it has some virtue. It could be great to have 2010-02 for
> example or 201002 if we want to keep integer. In these case, an issue is
> that period = period + 1 must be upgraded in
> month = month +1;
> if (month == 13) then {month = 1; year = year +1}
> Having two fields year and month, with month unavoidable if time_scale <
> year is also an option to consider.

Currently, the situation is clearly not ideal, but you can transform the
period in any way you like. For example, and assuming you have a period
going from 0 (= january 2010) to 23 (=december 2011), you could do:

- year_idx: trunc(period / 12)
- month_idx: period - year_idx
# you would probably initialize base_year to 2010
- year: base_year + year_idx
# transform to the "201002" format you mentioned above (
- month_label: year * 100 + month + 1

You should then be able to align on month_label instead of period.

Note however that, on the current version, this will be slower (by how
much really depends on your case) than using "period" which is
hard-coded as a special case. You could try to uncomment the code in
alignment.py which "kills" any axes with constant values (instead of
just "period"). I do not remember why I commented it in the first place.

> 2 - alignment
> An alignment using a csv file requires period being the same as in the
> simulation.
> Once again, how a month period should be called ?
> To not depends on the initial period, a month period should be 12* year
> + month.
> But the specific point to alignment is that we probably don't want to
> have two different csv file on per month an one per year.

I don't understand. Your alignment data is either yearly or monthly. If
you have both, using two separate files seem like the most sensible
thing to do anyway.

> It could be
> nice if with a timescale given as parameter, in case of year alignment,
> automatically, 12 month are agregated.
> In the reverse side, if we have only years in the csv file and running a
> month scale simulation is wanted, we would want to get the value for the
> years divide by 12.#

Right now, this seems too "magical" to me to do this automatically.
Note that you can do that partly already. For example if you want to
align yearly but have monthly data (and do not want to edit your
alignment files for whatever reason), you could load the alignment data
as a global table, compute the yearly total in the models and align to that.

> 3 - globals
> I don't use globals so far but the previous point can be true here also.
> We would want globals to be either month value or year value.
>
>
> And finally, my main point, which you can possibly guess reading above,
> is that I'd like to run different time scales with same yaml file and
> just adding a parmeter time_scale.

This looks unrealistic to me. Shouldn't all your state transition
probabilities be different depending on the time_scale?

> With this parameter and why not
> adding a type duration (age: int -> age: time) we could translate
> automatically equations. I mean age < 60 is obvious with time scale =
> year but should be translated in int(age/12) < 60 with time_scale =
> month and int(age/4) < 60 with time_scale = quarter

This should be done by integrating a proper "date" and "time" types,
either providing the support ourselves (via pytables time32 and time64
types) or by integrating with pandas.

Gaetan


----------------------------------------------------------------------------

Disclaimer: please see "www.plan.be/disclaimer.html"

Please consider your environmental responsibility before printing this email

----------------------------------------------------------------------------

[Alexis EidelMan]

Thank your for your answer.

I'll try that. I think it's possible to use 201002 as the period value, in simulation.py, if I change
periods = range(self.start_period, self.start_period + self.periods)
by something more complex that give me the right list :
[...,201011, 201012, 201101, 201102, ...]
problem is solved, isn't it?

Note however that, on the current version, this will be slower (by how
much really depends on your case) than using "period" which is
hard-coded as a special case. You could try to uncomment the code in
alignment.py which "kills" any axes with constant values (instead of
just "period"). I do not remember why I commented it in the first place.

I just try a guess but maybe you commented it because sometime the score given to align is itself a constant value (e.g. 0.0 or 0.5).

>      2 - alignment
> An alignment using a csv file requires period being the same as in the
> simulation.
> Once again, how a month period should be called ?
> To not depends on the initial period, a month period should be 12* year
> + month.
> But the specific point to alignment is that we probably don't want to
> have two different csv file on per month an one per year.

I don't understand. Your alignment data is either yearly or monthly. If
you have both, using two separate files seem like the most sensible
thing to do anyway.

What I meant is that I'd like to have only one file with the best precision I can have.
I think that two files with the same informations but one is aggregated is source of possible errors.
But I'll see what I can do thank to your following suggestion.

> It could be
> nice if with a timescale given as parameter, in case of year alignment,
> automatically, 12 month are agregated.
> In the reverse side, if we have only years in the csv file and running a
> month scale simulation is wanted, we would want to get the value for the
> years divide by 12.#

Right now, this seems too "magical" to me to do this automatically.
Note that you can do that partly already. For example if you want to
align yearly but have monthly data (and do not want to edit your
alignment files for whatever reason), you could load the alignment data
as a global table, compute the yearly total in the models and align to that.

>      3 - globals
> I don't use globals so far but the previous point can be true here also.
> We would want globals to be either month value or year value.
>
>
> And finally, my main point, which you can possibly guess reading above,
> is that I'd like to run different time scales with same yaml file and
> just adding a parmeter time_scale.

This looks unrealistic to me. Shouldn't all your state transition
probabilities be different depending on the time_scale?

As every transition is aligned, it can work.

> With this parameter and why not
> adding a type duration (age: int -> age: time) we could translate
> automatically equations. I mean age < 60 is obvious with time scale =
> year but should be translated in int(age/12) < 60 with time_scale =
> month and int(age/4) < 60 with time_scale = quarter

This should be done by integrating a proper "date" and "time" types,
either providing the support ourselves (via pytables time32 and time64
types) or by integrating with pandas.

I tried that a little, but that's not a piece of cake for me.

[Gaëtan de Menten]

On 25/06/2013 14:05, Alexis EidelMan wrote:
>
> Le lundi 24 juin 2013 14:48:55 UTC+1, Ga�tan de Menten a �crit :

Yes, but I would use that option as a last resort, because in that case
your version of LIAM2 is not generic any more and is tied to your model.

> Note however that, on the current version, this will be slower (by how
> much really depends on your case) than using "period" which is
> hard-coded as a special case. You could try to uncomment the code in
> alignment.py which "kills" any axes with constant values (instead of
> just "period"). I do not remember why I commented it in the first
> place.
>
>
> I just try a guess but maybe you commented it because sometime the score
> given to align is itself a constant value (e.g. 0.0 or 0.5).

I think it was rather simply because it was slowing down the usual case.

> > With this parameter and why not
> > adding a type duration (age: int -> age: time) we could translate
> > automatically equations. I mean age < 60 is obvious with time
> scale =
> > year but should be translated in int(age/12) < 60 with time_scale =
> > month and int(age/4) < 60 with time_scale = quarter
>
> This should be done by integrating a proper "date" and "time" types,
> either providing the support ourselves (via pytables time32 and time64
> types) or by integrating with pandas.
>
>
> I tried that a little, but that's not a piece of cake for me.

Using the pytables types should not be hard (but it is of limited use).
Integrating with Pandas would be much better, but is also a very large
undertaking.