New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bootstrapping a stratified design fails under usual conditions #157
Comments
@erex do you have code to reproduce this example? I tried to reproduce it based on your description but was unsuccessful. I couldn't see code to reproduce it in the other referenced issues either but maybe I missed something. I have also tested when both Region.Label and Sample.Label are either both numeric or both character and it runs fine under both scenarios. Thanks.
|
This situation does cause issues but not the issue described above. When the sampler ID's are not distinct across strata then object ID's are all associated with each occurrence of the sampler ID irrelevant of which strata the object was associated with even if it differs from the sampler ID. |
Initial steps to building testing. I do not know what effects there might be of changing the labelling of transects at this stage. Possibly nothing as replicated are renamed any way.
Add some documentation to bootdht to say that transect ID's need to be unique across all strata (not just within strata) |
When this is fixed remember to remove the additional text from the manual. |
Demonstrating the code failing
|
There appears to be a tacit assumption by
bootdht
regarding naming ofSample.Label
. Based upon question from the list,bootdht
will return a data frame with 0 columns and 0 rows whenSample.Label
names are not unique across strata.Usual numbering for transects in two strata might be 1, ..., 20 in Stratum 1 and 1, ..., 20 in Stratum 2. If this is the nature of the data provided to
bootdht
it will fail with the resul of 0 columns and 0 rows in the returned data frame.Workaround solution is to append the
Region.Label
onto theSample.Label
, as inNevertheless, this behaviour either needs to be changed or documented. I encountered this problem elsewhere and mentioned it in this issue
The text was updated successfully, but these errors were encountered: