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.

[Moohan]

What does this do?

[Nic-Chr]

It just ensures that the next appropriate method for subsetting is used (in this case numeric vector subsetting) and adds the appropriate class back. That means x[] will always return a percent vector, given that x here is a percent vector.
You can see a pretty similar method used in zoo::[.yearmon.

[Nic-Chr]

We can maybe get rid of NextMethod() entirely as it can be easily written without it.

[Nic-Chr]

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

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 83 lines in your changes missing coverage. Please review.

Project coverage is 81.45%. Comparing base (d737fcb) to head (322f848).
Report is 2 commits behind head on master.

Files	Patch %	Lines
R/percent.R	0.00%	83 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           master     #130       +/-   ##
===========================================
- Coverage   97.40%   81.45%   -15.95%     
===========================================
  Files          13       14        +1     
  Lines         424      507       +83     
===========================================
  Hits          413      413               
- Misses         11       94       +83     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[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.