Skip to content
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

improve documentation for column names #25

Open
rBatt opened this issue May 29, 2014 · 4 comments
Open

improve documentation for column names #25

rBatt opened this issue May 29, 2014 · 4 comments

Comments

@rBatt
Copy link
Contributor

rBatt commented May 29, 2014

As an example: ?k.cole says the argument is wind. Need to describe what arguments k.cole() takes when passed a data.frame, as for the data.frame S3 method. Specifically, the header name. But also the format of the datetimes (I think "datetime" is the desired header, as per my interpretation of the $ index at https://github.com/GLEON/LakeMetabolizer/blob/master/R/k.cole.R#L14).

I realize things are in flux, which is why this isn't yet documented. But I think Luke's data.frame/ default methods make sense, and we'll probably use them. Thus, we should start organizing the documentation around this framework.

@rBatt
Copy link
Contributor Author

rBatt commented May 29, 2014

Maybe the real point here is that the help files for those functions need to reflect that they can accept either data.frames or just the wnd (e.g.) vector. Right now it's not clear to a user that k.cole() (etc.) has this hugely convenient functionality.

@lawinslow
Copy link
Member

I didn't update the documentation yet because I wasn't sure I wanted to keep it. What do you think, is it a mode of operating that we should keep around? If yes, then I'll start working on documentation.

@rBatt
Copy link
Contributor Author

rBatt commented May 30, 2014

I've been plugging away at some old metabolism stuff from scratch (pain in the $%@). I'll have a fuller opinion soon. I think your "ts" approach is absolutely essential. That's my current perspective.

@lawinslow
Copy link
Member

Ok, that's enough for me. When trying to use it, I also found that some way to handle the diversity of inputs was absolutely essential. Let's go with this for now and see what people think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants