qiita
qiita copied to clipboard
Rename Command.parameters to Command.default_parameters??
If you select a BIOM artifact from a files network, it shows in the "processing parameters" used and they include a value for "trim-length". However, that value is not incorrect as the trimming is performed upstream. This is misleading.
This is also confusing within the API as incorrect values are reported in multiple places, including in the parent.
In [21]: t = biom.load_table(a.filepaths[0][1])
In [22]: len(t.ids(axis='observation')[0])
Out[22]: 150
In [23]: a.processing_parameters.values['trim-length']
Out[23]: 100
In [24]: a.id
Out[24]: 25483
In [28]: p = a.parents[0]
In [30]: p.processing_parameters.values
Out[30]: {'input_data': u'25331', 'length': 150}
In [32]: p.processing_parameters.command.parameters
Out[32]: {'input_data': ['artifact', None], 'length': ['integer', '100']}
Good point, however, that's a behavior due to the parameters used for debluring, which has (can't remember which) a parameter to ignore the trim-length. Not sure which will be the best behavior? Always check all params (easy, most accurate) for downstream analysis? Inherit the parameters (can lead to inconsistencies)? Other?
I understand the issue with deblur, but I do not understand the issue with the parent artifact reporting the wrong trim length in the code pasted, any idea there? Checking all params doesn't resolve confusion.
As to what to show in the UI, perhaps a clear statement in the artifact network itself of what the actual trim length is?
On Apr 11, 2017 05:30, "Antonio Gonzalez" [email protected] wrote:
Good point, however, that's a behavior due to the parameters used for debluring, which has (can't remember which) a parameter to ignore the trim-length. Not sure which will be the best behavior? Always check all params (easy, most accurate) for downstream analysis? Inherit the parameters (can lead to inconsistencies)? Other?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/biocore/qiita/issues/2105#issuecomment-293245174, or mute the thread https://github.com/notifications/unsubscribe-auth/AAc8svq1lcUGlnG1i8o2cu3HgzjcaaKbks5ru3JZgaJpZM4M5RxI .
Sent (a version of) this via chat but to keep it here for reference: Got it! p.processing_parameters.values
will retrieve the parameters used to generate that artifact, p.processing_parameters.command
will retrieve the parameter that was used to generate that parameter (in other words, the Command object that generated that artifact), and p.processing_parameters.command.parameters
the default parameters of that Command.
Can that last one be denoted as "default_parameters"?
On Apr 11, 2017 07:09, "Antonio Gonzalez" [email protected] wrote:
Sent (a version of) this via chat but to keep it here for reference: Got it! p.processing_parameters.values will retrieve the parameters used to generate that artifact, p.processing_parameters.command will retrieve the parameter that was used to generate that parameter (in other words, the Command object that generated that artifact), and p.processing_parameters. command.parameters the default parameters of that Command.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/biocore/qiita/issues/2105#issuecomment-293275056, or mute the thread https://github.com/notifications/unsubscribe-auth/AAc8skK3pTjW-rKftoAl8ylUFVB0ZjaGks5ru4mQgaJpZM4M5RxI .
I guess, we will just need to change the method name and the tests ... can we rename the issue?
If others think it should be changed as well? No concern on renaming the issue
On Apr 11, 2017 07:51, "Antonio Gonzalez" [email protected] wrote:
I guess, we will just need to change the method name and the tests ... can we rename the issue?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/biocore/qiita/issues/2105#issuecomment-293288191, or mute the thread https://github.com/notifications/unsubscribe-auth/AAc8ssDfZA1A-u36ZqCL5UC5pWvgDBMhks5ru5M5gaJpZM4M5RxI .
Renaming as suggested in the issue title makes sense.