parameters2natural and natural2parameters

[rho62]

The two functions takes an argument of class "trunc_XXXX"

IF this should be maintained, this should be stated in the help file.
BUT I'm not sure that the function should be restricted to this class.
Perhaps there should be a class that distinguish beween the "natural" and "original" parameters!? (Btw "original" is not the best name) So that parameter2natural can only convert from the orignal to the natural scale and vice versa for natural2parameters.
For example: The example in the help file for natural2parameter:
samp <- rtrunc(n = 100, lambda = 2, family = "Poisson")

natural2parameters(init.parms(samp))
[1] 7.170676

This converts a parameter, which is on the "original" scale as if it was on the natural scale - makes no sense.

Perhaps we should just have more flexible functions (less class restrictive) that takes ordinary numeric vectors and converts between the two scales. Similarly to the dtrunc, rtrunc ... we could have a "family" parameter with a default "gaussian".

[wleoncio]

I agree that the example for natural2parameters() is rather non-sensical, maybe it should be something like the following?

samp <- rtrunc(n = 100, lambda = 2, family = "Poisson")
eta <- parameters2natural(samp)
natural2parameters(eta)

Then we'd show that the last line above is basically the same as samp.

[rho62]

In essence the two functions should just take a two vectors (of appropriate dimension) and transform to another vector of the same dimension. In the example below the parameters2natural takes a sample an transform a “feature” of this sample (the empirical parameters). The point is that the functions should not depend on the sample. The question is if there should be some class checking etc /René Fra: Waldir Leoncio ***@***.***> Svar til: ocbe-uio/TruncExpFam ***@***.***> Dato: onsdag 2. mars 2022 kl. 07:32 Til: ocbe-uio/TruncExpFam ***@***.***> Kopi: Rene Holst ***@***.***>, Author ***@***.***> Emne: Re: [ocbe-uio/TruncExpFam] parameters2natural and natural2parameters (Issue #88) I agree that the example for natural2parameters() is rather non-sensical, maybe it should be something like the following? samp <- rtrunc(n = 100, lambda = 2, family = "Poisson") eta <- parameters2natural(samp) natural2parameters(eta) Then we'd show that the last line above is basically the same as samp. — Reply to this email directly, view it on GitHub<#88 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFPRUPRUBCVYEXTIOBV7GSLU54DRLANCNFSM5PMYZFGA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[wleoncio]

I get it now. Sounds simple enough to add a family argument to those two functions so they also accept common numeric vectors.

[wleoncio]

To help solve this, commit 5ff8560 adds a function called extractParameters(), which takes in a numeric vector and, depending on the values passed to the family and natural arguments, will return an estimate for the parameters based on the data. I still need to write tests for all supported distributions to make sure this is working as expected, but I hope this is on the right track. A user can check example(extractParameters) to see an example of usage.

What I am imagining right now is that, from a user-level, extractParameters() will replace parameters2natural() and natural2parameters(). The latter two functions would still exist in the package, since they are indirectly called by the former.

[rho62]

Hi Waldir, I’m back next week. We can talk then. /René Fra: Waldir Leoncio ***@***.***> Svar til: ocbe-uio/TruncExpFam ***@***.***> Dato: onsdag 21. september 2022 kl. 14:42 Til: ocbe-uio/TruncExpFam ***@***.***> Kopi: Rene Holst ***@***.***>, Author ***@***.***> Emne: Re: [ocbe-uio/TruncExpFam] parameters2natural and natural2parameters (Issue #88) To help solve this, commit 5ff8560<5ff8560> adds a function called extractParameters(), which takes in a numeric vector and, depending on the values passed to the family and natural arguments, will return an estimate for the parameters based on the data. I still need to write tests for all supported distributions to make sure this is working as expected, but I hope this is on the right track. A user can check example(extractParameters) to see an example of usage. What I am imagining right now is that, from a user-level, extractParameters() will replace parameters2natural() and natural2parameters(). The latter two functions would still exist in the package, since they are indirectly called by the former. — Reply to this email directly, view it on GitHub<#88 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFPRUPUZGLJ6ZDZNQSYPZ33V7L7EHANCNFSM5PMYZFGA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[wleoncio]

• Create a "distribution" class with some attributes (parms values, is_natural boolean, family?)
• Have that class initiation do the conversion of parameters
• Create a print method that prints the parameters (including natural)

[wleoncio]

Hi René,

I have finished the implementation outlined in our previous meeting. The idea is that the user calls the function probdist() with a named set of parameters and family and the function does the conversion to natural (or back, if the latter is provided). See the example below for reproducibility:

# Installing and loading the package ===========================================

remotes::install_github("ocbe-uio/TruncExpFam")
#> Using github PAT from envvar GITHUB_PAT
#> Skipping install of 'TruncExpFam' from a github remote, the SHA1 (46fa8b24) has not changed since last install.
#>   Use `force = TRUE` to force installation
library("TruncExpFam")
#> Welcome to TruncExpFam 1.0.0.9025.
#> Please read the documentation on ?TruncExpFam to learn more about the package.

# Examples ====================================================================

probdist(mean = 5, sd = .1, family = "normal")
#> Family:             Normal
#> Parameters:         mean = 5   sd   = 0.1 
#> Natural parameters: eta1 = 500 eta2 = -50
probdist(eta1 = 1, eta2 = -1, family = "normal")
#> Family:             Normal
#> Parameters:         mean = 0.5               sd   = 0.7071            
#> Natural parameters: eta1 = 1                 eta2 = -1

Please let me know how this looks. If approved, I'll close the issue.

[rho62]

Hi Waldir Thanks for your effort. In principle it does what it is supposed to do, but I’d like it slightly different, if possible: * Why is it called “probdist”? The intuition is not clear to me. The function should just swap between the two scales. How about “swapscale” or “convertscale”? Any other suggestions? * Instead of having the parameters (both input and output) as two scalars, I’d prefer them as two vectors (which for some distribution will be of length 1 and for others of length 2 and might potentially be of other lengths). Look at the 2nd and third column of the table at the https://en.wikipedia.org/wiki/Exponential_family . The 2nd is just called “parameter” and the 3rd “Natural parameters” . We need another name instead of just “parameter”. I suggest “ordinary” and the other will be kept as “natural”. So either two functions “ordinary2natural” and “natural2ordinary”, each taking a vector and returning a vector, and having a distribution (familily) variable that detects which specific conversion to use or a single function taking and returning vector and having a distribution variable (family) and a direction variable taking values ‘natural2ordinary’ and ‘ordinary2natural’. There might be some vaidity checking (eg. the Poisson rate lambda cannot be negative and alike) * I’d prefer a more simple output: No need for info on the family info or info about the input variable. How does this sound? Cheers René Fra: Waldir Leoncio ***@***.***> Svar til: ocbe-uio/TruncExpFam ***@***.***> Dato: torsdag 30. mars 2023 kl. 13:02 Til: ocbe-uio/TruncExpFam ***@***.***> Kopi: Rene Holst ***@***.***>, Author ***@***.***> Emne: Re: [ocbe-uio/TruncExpFam] parameters2natural and natural2parameters (Issue #88) Hi René, I have finished the implementation outlined in our previous meeting. The idea is that the user calls the function probdist() with a named set of parameters and family and the function does the conversion to natural (or back, if the latter is provided). See the example below for reproducibility: # Installing and loading the package =========================================== remotes::install_github("ocbe-uio/TruncExpFam") #> Using github PAT from envvar GITHUB_PAT #> Skipping install of 'TruncExpFam' from a github remote, the SHA1 (46fa8b2) has not changed since last install. #> Use `force = TRUE` to force installation library("TruncExpFam") #> Welcome to TruncExpFam 1.0.0.9025. #> Please read the documentation on ?TruncExpFam to learn more about the package. # Examples ==================================================================== probdist(mean = 5, sd = .1, family = "normal") #> Family: Normal #> Parameters: mean = 5 sd = 0.1 #> Natural parameters: eta1 = 500 eta2 = -50 probdist(eta1 = 1, eta2 = -1, family = "normal") #> Family: Normal #> Parameters: mean = 0.5 sd = 0.7071 #> Natural parameters: eta1 = 1 eta2 = -1 Please let me know how this looks. If approved, I'll close the issue. — Reply to this email directly, view it on GitHub<#88 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFPRUPSI6DRHHNNYYI3YTY3W6VR23ANCNFSM5PMYZFGA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[rho62]

Not quite sure I understand this /René Fra: Waldir Leoncio ***@***.***> Svar til: ocbe-uio/TruncExpFam ***@***.***> Dato: tirsdag 28. mars 2023 kl. 14:18 Til: ocbe-uio/TruncExpFam ***@***.***> Kopi: Rene Holst ***@***.***>, Author ***@***.***> Emne: Re: [ocbe-uio/TruncExpFam] parameters2natural and natural2parameters (Issue #88) * Create a "distribution" class with some attributes (parms values, is_natural boolean, family?) * Have that class initiation do the conversion of parameters * Create a print method that prints the parameters (including natural) — Reply to this email directly, view it on GitHub<#88 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFPRUPXMSOXN4FS74HUFSRLW6LJJ7ANCNFSM5PMYZFGA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[wleoncio]

Hi Rene, thanks for your feedback. To address your questions:

Why is it called “probdist”? The intuition is not clear to me. The function should just swap between the two scales. How about “swapscale” or “convertscale”? Any other suggestions?

The implementation was such that probdist() creates an object of class "probdist" (stands for "probability distribution") which contains its own attributes (family, parameters) and methods (initialize, print, convert...). We could definitely change the implementation so it's a simple function called swapscale().

Instead of having the parameters (both input and output) as two scalars, I’d prefer them as two vectors (which for some distribution will be of length 1 and for others of length 2 and might potentially be of other lengths). Look at the 2nd and third column of the table at the https://en.wikipedia.org/wiki/Exponential_family . The 2nd is just called “parameter” and the 3rd “Natural parameters” . We need another name instead of just “parameter”. I suggest “ordinary” and the other will be kept as “natural”. So either two functions “ordinary2natural” and “natural2ordinary”, each taking a vector and returning a vector, and having a distribution (familily) variable that detects which specific conversion to use or a single function taking and returning vector and having a distribution variable (family) and a direction variable taking values ‘natural2ordinary’ and ‘ordinary2natural’. There might be some vaidity checking (eg. the Poisson rate lambda cannot be negative and alike)

We already have two generic functions, parameters2natural() and natural2parameters() that do this, except they take only one argument each (parms and eta, respectively). I could simply edit the generic so it also takes a family parameter and calls the correct method depending on its value. Here's an example of how it currently works (needs some polishing, since the conversion functions are currently internal):

I’d prefer a more simple output: No need for info on the family info or info about the input variable.

Can do, though if we're simply going to use the functions from the point above, we're probably better off just scrapping probdist() altogether.

[wleoncio]

Hi, René! Please take a look at this new implementation, version 1.0.0.9027, which can be installed by

remotes::install_github("ocbe-uio/TruncExpFam", "issue-88")

Usage now is simpler and hopefully closer to how you imagined it. Basically, the user just supplies a named vector of parameters and a family, and the function (parameters2natural() or natural2parameters()) does the proper conversion. Here are a couple of examples: