Thing to consider - structure of output lists

[szymekdr]

When using metaDigitise on a fresh plot (with settings summary = F) each plot data gets stored in a ..$FigX element of a resulting list. However, when retrieving data from an old digitalisation stored in caldat the structure is different - now it contains one additional level of plot type (e.g. ..$scatterplot$FigX). It is very detrimental to reproducibility (code written with fresh digitalisations in mind stops working when trying to re-run it with existing extracton data - the $ pointers no longer correctrly indicate the data elements in question).

A potential solution is to make the list hierarchy uniform (using one or the other convention for both fresh and reloaded extractions).

I'm using package version 1.0.1.

[joelpick]

What function are you using to retrieve the data from a previously extracted figure? Unfortunately, the problem with changing it now is that we may break the code of anyone who has previously used it, so I’m not sure how much of an option that is...

…

On 24 Oct 2024, at 08:11, Szymek Drobniak ***@***.***> wrote: When using metaDigitise on a fresh plot (with settings summary = F) each plot data gets stored in a ..$FigX element of a resulting list. However, when retrieving data from an old digitalisation stored in caldat the structure is different - now it contains one additional level of plot type (e.g. ..$scatterplot$FigX). It is very detrimental to reproducibility (code written with fresh digitalisations in mind stops working when trying to re-run it with existing extracton data - the $ pointers no longer correctrly indicate the data elements in question). A potential solution is to make the list hierarchy uniform (using one or the other convention for both fresh and reloaded extractions). I'm using package version 1.0.1. — Reply to this email directly, view it on GitHub <#68>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEEEI4FMR4TWGW3HLGIN5Q3Z5CMTPAVCNFSM6AAAAABQQMPS3OVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYYTANRZGAZTCNA>. You are receiving this because you are subscribed to this thread.

[szymekdr]

Basically: when running metaDigitise(folder) and picking "1" - extract new images - the resulting object has one nesting level (plot names). But when calling it again in the same way on a folder already with past extraction results, it gives the option to load existing data. Then, the resulting object has 2 levels of nesting: plot type and then figure name. So if someone writes his code doing extractions for the first time, and then shares the analysis via GitHub - a person trying to rerun the code will not be able to do it without adding the $scatterplot (etc.) before the $fig_name in any downstream code that uses the extractions data.

I realize it may be difficult so just leaving it here, maybe it becomes fixable later with some major update ;)

[joelpick]

Thanks for pointing this out. I've found the issue in the code - very annoying that we didn't notice this when we wrote it! One way around this problem is to use the getExtracted() function. You can run this on the folder after extractions, regardless of whether you have just done these or working on previous extractions. You then get the $plot_type$figure_name structure.

…

On 24 Oct 2024, at 15:59, Szymek Drobniak ***@***.***> wrote: Basically: when running metaDigitise(folder) and picking "1" - extract new images - the resulting object has one nesting level (plot names). But when calling it again in the same way on a folder already with past extraction results, it gives the option to load existing data. Then, the resulting object has 2 levels of nesting: plot type and then figure name. So if someone writes his code doing extractions for the first time, and then shares the analysis via GitHub - a person trying to rerun the code will not be able to do it without adding the $scatterplot (etc.) before the $fig_name in any downstream code that uses the extractions data. I realize it may be difficult so just leaving it here, maybe it becomes fixable later with some major update ;) — Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEEEI4B5NBGWFUZ5D6DOWYDZ5EDL5AVCNFSM6AAAAABQQMPS3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZVGUZTQNBSG4>. You are receiving this because you commented.