how to un-truncate a warning message?

[klg-2016]

The updated detection history function seems to be running just fine: it doesn't throw any errors and it produces what I think it should. However, it does throw this warning message: In merge.data.frame(DetHist_16_17_18, DetHist_19, by = 0, all = TRUE) : column names ‘detection_history.o1.x’, ‘detection_history.o2.x’, ‘detection_history.o3.x’, ‘detection_history.o4.x’, ‘detection_history.o5.x’, ‘detection_history.o6.x’, ‘detection_history.o7.x’, ‘detection_history.o8.x’, ‘detection_history.o9.x’, ‘detection_history.o10.x’, ‘detection_history.o11.x’, ‘detection_history.o12.x’, ‘detection_history.o13.x’, ‘detection_history.o14.x’, ‘detection_history.o15.x’, ‘detection_history.o16.x’, ‘detection_history.o17.x’, ‘detection_history.o18.x’, ‘detection_history.o19.x’, ‘detection_history.o20.x’, ‘detection_history.o21.x’, ‘detection_history.o22.x’, ‘detection_history.o23.x’, ‘detection_history.o24.x’, ‘detection_history.o25.x’, ‘detection_history.o26.x’, ‘detection_history.o27.x’, ‘detection_history.o28.x’, ‘detection_history.o29.x’, ‘detection_history.o30.x’, ‘detection_history.o31.x’, ‘detection_history.o32.x’, ‘detection_history.o33.x’, ‘detection_history.o34.x’, ‘detection_history.o35.x’, ‘detection_history.o36.x’, ‘detection_history.o37.x [... truncated]

Do you know how to un-truncate a warning message? I'm not sure if this can just be ignored or not because I don't know what it's actually saying. I googled my question and either found stuff that I had trouble following or stuff that talks about how to add a truncate feature to warning messages when you're writing a function.

[kaitlyngaynor]

If it's doing what you think it should, it's probably fine.

Re: truncated messages, I just figured out that getOption("warning.length") will tell you the length at which it will be truncated and options(warning.length = 2000L) will extend the warning length to 2000 characters (you need the "L" at the end). Weirdly, it seems like 8172 is the max warning length that you can set (see here)

Not sure if that will help but I think it may have to do with the all = TRUE if the column is not present in both data frames?

[kaitlyngaynor]

But again, if you are confident in the output, the warning probably doesn't matter

[klg-2016]

OK extending the warning message includes a ton more column names and ends with "are duplicated in the result". I'm going to double check that the resulting spreadsheet has the expected number of rows and columns and then not worry about this message

[klg-2016]

yep, resulting .csv file has the correct number of rows (60) and columns (440), so I think we're good. Thank you for helping me figure out how to extend the warning message! Also 8172 seems so random

I think "duplicated" is because there's a day 1 column from each of the four seasons (for example), which is exactly what we want but R is thinking it might be a mistake? One of the things I was working on last with this was confirming that each of the first day columns looked roughly how it was supposed to (how I found the issues that you then fixed), so I think we're good.

[kaitlyngaynor]

I'm not totally clear on what you are trying to do, but I tend to use bind_rows/bind_cols, or join ( https://dplyr.tidyverse.org/reference/join.html) from dplyr rather than merge, since I've found that merge does weird/unexpected things. So just something else to try/consider? But if you feel confident that the output is correct, then go with it!

On Mon, Mar 15, 2021 at 1:56 PM klg-2016 @.***> wrote:

yep, resulting .csv file has the correct number of rows (60) and columns (440), so I think we're good. Thank you for helping me figure out how to extend the warning message! Also 8172 seems so random

I think "duplicated" is because there's a day 1 column from each of the four seasons (for example), which is exactly what we want but R is thinking it might be a mistake? One of the things I was working on last with this was confirming that each of the first day columns looked roughly how it was supposed to (how I found the issues that you then fixed), so I think we're good.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kaitlyngaynor/gorongosa-mesocarnivores/issues/116#issuecomment-799746375, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHA7WTZXRC5JZCNXVKDMUCLTDZYBFANCNFSM4ZHHD7IQ .

[kaitlyngaynor]

Oh and here is the documentation for bind: https://dplyr.tidyverse.org/reference/bind.html

On Mon, Mar 15, 2021 at 1:58 PM Kaitlyn Gaynor @.***> wrote:

I'm not totally clear on what you are trying to do, but I tend to use bind_rows/bind_cols, or join ( https://dplyr.tidyverse.org/reference/join.html) from dplyr rather than merge, since I've found that merge does weird/unexpected things. So just something else to try/consider? But if you feel confident that the output is correct, then go with it!

On Mon, Mar 15, 2021 at 1:56 PM klg-2016 @.***> wrote:

yep, resulting .csv file has the correct number of rows (60) and columns (440), so I think we're good. Thank you for helping me figure out how to extend the warning message! Also 8172 seems so random

I think "duplicated" is because there's a day 1 column from each of the four seasons (for example), which is exactly what we want but R is thinking it might be a mistake? One of the things I was working on last with this was confirming that each of the first day columns looked roughly how it was supposed to (how I found the issues that you then fixed), so I think we're good.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kaitlyngaynor/gorongosa-mesocarnivores/issues/116#issuecomment-799746375, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHA7WTZXRC5JZCNXVKDMUCLTDZYBFANCNFSM4ZHHD7IQ .

[klg-2016]

Thank you! I feel confident enough for this chunk that it's doing what I want it to do--I'll keep bind/join in mind moving forward!