Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

general fields

5 views
Skip to first unread message

Alexis EidelMan

unread,
May 13, 2013, 10:18:09 AM5/13/13
to liam...@googlegroups.com
It is definitely not priority, and I don't know if it's a good idea.
I just write it as that group can be a place to brainstorm.

I think about fields.
A few of them won't change during the simulation. I think about sexe, father's id, mother's id, birthdate, etc.

To copy them at each period is not a big deal at all but is a little bit redundant in calculus time (or hardly) and on space on disk.

Obviously, it would make the program more complex. For example an entity should be the sum of the actual table for each individual x period and an individual table.
On that table, methods could be implemented to check easily if the individual is present at a given period.

I think about it because it would solve my issue about two or more step links.

Once again, Liam2 runs well without that feature. It's second order issue.



Gaëtan de Menten

unread,
May 14, 2013, 3:32:35 AM5/14/13
to liam...@googlegroups.com

On 13/05/2013 16:18, Alexis EidelMan wrote:

> It is definitely not priority, and I don't know if it's a good idea.
> I just write it as that group can be a place to brainstorm.
>
> I think about fields.
> A few of them won't change during the simulation. I think about sexe,
> father's id, mother's id, birthdate, etc.

Yes, it seems like a good idea in theory, but in practice I now think it
would be better to simply let the user decide which fields to write to
the hdf5 file (so that he could simply not write them).

> To copy them at each period is not a big deal at all but is a little bit
> redundant in calculus time (or hardly)

If they are not changed, no calculus time is spent on them.

> and on space on disk.

Indeed, and that could be a problem in some situations.

> Obviously, it would make the program more complex. For example an entity
> should be the sum of the actual table for each individual x period and
> an individual table.
> On that table, methods could be implemented to check easily if the
> individual is present at a given period.
>
> I think about it because it would solve my issue about two or more step
> links
> <https://groups.google.com/d/msg/liam2-users/KpQFD1OqUtU/_gDVSc2SYNQJ>.

I don't think so, because even if we did implement a two-distinct-tables
approach like you suggest, we would need to keep them synchronized, so
you still would not be able to link to/through dead people.

Gaetan


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

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

Please consider your environmental responsibility before printing this email

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

Alexis EidelMan

unread,
May 14, 2013, 11:49:22 AM5/14/13
to liam...@googlegroups.com, g...@plan.be


Le mardi 14 mai 2013 08:32:35 UTC+1, Gaëtan de Menten a écrit :

On 13/05/2013 16:18, Alexis EidelMan wrote:

> It is definitely not priority, and I don't know if it's a good idea.
> I just write it as that group can be a place to brainstorm.
>
> I think about fields.
> A few of them won't change during the simulation. I think about sexe,
> father's id, mother's id, birthdate, etc.

Yes, it seems like a good idea in theory, but in practice I now think it
would be better to simply let the user decide which fields to write to
the hdf5 file (so that he could simply not write them).

That's a good idea. A more general one.
I think about my duration variables for example. In general, i keep some fields only to cast information from a period to an other one, but the information in itself is not a very important output.  


> To copy them at each period is not a big deal at all but is a little bit
> redundant in calculus time (or hardly)

If they are not changed, no calculus time is spent on them.

> and on space on disk.

Indeed, and that could be a problem in some situations.

In that case ( quite extreme, I presume), a user could not to write these fields but dump them once in csv.
 
> Obviously, it would make the program more complex. For example an entity
> should be the sum of the actual table for each individual x period and
> an individual table.
> On that table, methods could be implemented to check easily if the
> individual is present at a given period.
>
> I think about it because it would solve my issue about two or more step
> links
> <https://groups.google.com/d/msg/liam2-users/KpQFD1OqUtU/_gDVSc2SYNQJ>.

I don't think so, because even if we did implement a two-distinct-tables
approach like you suggest, we would need to keep them synchronized, so
you still would not be able to link to/through dead people.

Yes. What i mean was precisely to refer that table using a function which, by default, select "living people".
I keep on thinking on it, I keep you informed.

Alexis
Reply all
Reply to author
Forward
0 new messages