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.

[Moohan]

Suggested change

	#' printing of proportions as percentages. \cr
	#' printing of proportions as percentages.

[Nic-Chr]

Is it the entire description you want as just that 1 line? Not sure it fully reflects why users might want to use percents.
Edit: Nvm I think it's just line 6.

[Moohan]

Sorry, my 'suggestion' was just to remove the \cr at the end of line 6 which I assume is a typo?

[Nic-Chr]

Ah, no I typically use it to add a new line, but maybe there's better syntax for that.

[Nic-Chr]

I've checked and can't find an alternative that works surprisingly.

[Moohan]

The \cr appears verbatim in the .Rd file (

phsmethods/man/percent.Rd

Line 17 in b9a9151

printing of proportions as percentages. \cr

). I would just put a new line in, no special characters needed.

[Nic-Chr]

Maybe an obvious one but how do I get the documentation to display that line on a new line right below the previous text? If I insert a new line using Enter on my keyboard it places it 2 lines below.

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