Added percent functions.

[Nic-Chr]

Added percent function and related methods as discussed.

I'm unsure about what the default digits should be set as so I just set them to 2. Maybe we could create an option the user could set for all formatting methods.

[Nic-Chr]

We can also replace paste() with stringr::str_c() which naturally handles NA values and zero-length vectors.

[codecov[bot]]

Codecov Report

:x: Patch coverage is 86.91589% with 14 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
R/percent.R	86.9%	14 Missing :warning:

:loudspeaker: Thoughts on this report? Let us know!

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Nic-Chr]

I also noticed a small bug where sign(x) returns a percent vector. Should fix this in the Math group generic.

[Nic-Chr]

I also like the idea of users being able to create percent vectors using numbers representing literal percentages. We could have for example a function called percent or create_percent that converts for example percent(50) into 50%. The same as doing as_percent(0.5).

[Moohan]

I also like the idea of users being able to create percent vectors using numbers representing literal percentages. We could have for example a function called percent or create_percent that converts for example percent(50) into 50%. The same as doing as_percent(0.5).

I like this idea too. Also prompted the thought that we should have a check (maybe producing a warning), so if someone provides 'numbers that look like percentages' e.g. c(10, 20, 30) to as_percent() it warns them they probably did it wrong. The reverse check and warning could be used on create_percent() (format_percent(), make_percent()?)

[Nic-Chr]

I also like the idea of users being able to create percent vectors using numbers representing literal percentages. We could have for example a function called percent or create_percent that converts for example percent(50) into 50%. The same as doing as_percent(0.5).

I like this idea too. Also prompted the thought that we should have a check (maybe producing a warning), so if someone provides 'numbers that look like percentages' e.g. c(10, 20, 30) to as_percent() it warns them they probably did it wrong. The reverse check and warning could be used on create_percent() (format_percent(), make_percent()?)

I'm a bit apprehensive about this because in general percentages above 100% are completely acceptable depending on the context. For example, in finance, percentage increases above 100% are very normal.

[Moohan]

I also like the idea of users being able to create percent vectors using numbers representing literal percentages. We could have for example a function called percent or create_percent that converts for example percent(50) into 50%. The same as doing as_percent(0.5).

I like this idea too. Also prompted the thought that we should have a check (maybe producing a warning), so if someone provides 'numbers that look like percentages' e.g. c(10, 20, 30) to as_percent() it warns them they probably did it wrong. The reverse check and warning could be used on create_percent() (format_percent(), make_percent()?)

I'm a bit apprehensive about this because in general percentages above 100% are completely acceptable depending on the context. For example, in finance, percentage increases above 100% are very normal.

Light touch checks 😄

[Nic-Chr]

I agree in principle that you can certainly have 'incorrect' percentages though I think the need to check for those is probably quite niche and maybe needs a bit of justification.

I would be inclined to go with a 'less-is-more' approach and see how users interact with this new percent object before including checks and warnings that might make things confusing.

In practice we could let the user decide that the function checks for percentages greater than a specified cut-off where the default value is say NULL or 0.

[Nic-Chr]

I have an idea for how to deal with formatting digits greater than the default 2 decimal places without having to go through format() every single time. We could add the digits as an attribute to the percent object itself via attr(x) <- This way the user can specify their preferred digits when creating the object via as_percent.

For example let's say the user wants their percent vector to be formatted to 4 decimal places. They simply use as_percent(x, digits = 4). An attribute is added to the percent vector, say .digits = 4. All the printing/formatting functions will then use the information from this attribute to format to 4 decimal places.

Furthermore, we can code it so that if a user later decides they want a different number of decimal places, they can use format as usual to overwrite the attribute instructions for that particular call.

[Moohan]

I have an idea for how to deal with formatting digits greater than the default 2 decimal places without having to go through format() every single time. We could add the digits as an attribute to the percent object itself via attr(x) <- This way the user can specify their preferred digits when creating the object via as_percent.

For example let's say the user wants their percent vector to be formatted to 4 decimal places. They simply use as_percent(x, digits = 4). An attribute is added to the percent vector, say .digits = 4. All the printing/formatting functions will then use the information from this attribute to format to 4 decimal places.

Furthermore, we can code it so that if a user later decides they want a different number of decimal places, they can use format as usual to overwrite the attribute instructions for that particular call.

Good idea.

The add here is to allow the user to set a 'default' at the moment it's 2 (per the style guide). You can print different digits with format(x, digits = n) but this will allow setting the default when the percent is created.

[Nic-Chr]

I've combined your tests and my tests into this branch as discussed @Moohan. I think everything is in a good state now so feel free to review when you can.

[Nic-Chr]

I also like the idea of users being able to create percent vectors using numbers representing literal percentages. We could have for example a function called percent or create_percent that converts for example percent(50) into 50%. The same as doing as_percent(0.5).

I like this idea too. Also prompted the thought that we should have a check (maybe producing a warning), so if someone provides 'numbers that look like percentages' e.g. c(10, 20, 30) to as_percent() it warns them they probably did it wrong. The reverse check and warning could be used on create_percent() (format_percent(), make_percent()?)

Did we decide on this? I still think it's a nice-to-have to be able to create percentages directly as well as converting proportions.

[Nic-Chr]

There is a conflict preventing the merge because "phsmethods.R" has been renamed to "phsmethods-package.R". I think it should be called "phsmethods.R" to follow with standard tidyverse naming practices, see: https://github.com/tidyverse/dplyr/blob/main/R/dplyr.R

The "packagename-package.R" convention is typically reserved for registering DLL files for e.g. C/C++ source code. See: https://github.com/NicChr/timeplyr/blob/main/R/timeplyr-package.R

Probably best to rename it back to "phsmethods.R" as this I believe is best practice.

EDIT: Nevermind, apparently this is not the case anymore! Looks like "package-package.R" is now the canonical naming convention..

[Moohan]

EDIT: Nevermind, apparently this is not the case anymore! Looks like "package-package.R" is now the canonical naming convention.. :D yep. We made changes in #128 using usethis::use_package_doc().

See also https://r-pkgs.org/man.html#sec-man-package-doc (if you didn't already find that one).

[Nic-Chr]

I have now added a c() method for combining percent vectors.