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
----------------------------------------------------------------------------