date:20231217

Re: [Rd] [External] Re: zapsmall(x) for scalar x

2023-12-17 Thread Steve Martin

Sorry for being unclear. I was commenting on the edge case that
Gregory brought up when calling zapsmall() with a vector of small
values. I thought Gregory was asking for thoughts on that as well, but
maybe I misunderstood. IMO it would be weird for zapsmall() to make a
small scalar zero but not a vector of the identical values.

The example with summary() was meant to show that zapping a vector of
small values to 0 could change the current printing behavior for
certain objects. Ducan is right that zapping only a scalar to zero
wouldn't do anything.

>>> Isn’t that the correct outcome?  The user can change the number of digits 
>>> if they want to see small values…

I'm not sure a user would be able to change the digits without
updating other functions. If xx[finite] <- zapsmall(x[finite]) in
print.summaryDefault() makes a vector of 0s (e.g., zapsmall(x) works
like round(x, digits = getOption("digits")) and getOptions("digits")
is 7) then calling print(summary(2.220446e-16), digits = 16) would
still print a vector of 0s. The digits argument to print() wouldn't do
anything.

In any case, I just wanted to point out that changes to zapsmall() in
the corner case Gregory brought up could affect the way certain
objects are printed, both changing the current behavior and perhaps
requiring changes to some other functions.

Steve

On Sun, 17 Dec 2023 at 12:26, Barry Rowlingson
 wrote:
>
> I think what's been missed is that zapsmall works relative to the absolute 
> largest value in the vector. Hence if there's only one
> item in the vector, it is the largest, so its not zapped. The function's 
> raison d'etre isn't to replace absolutely small values,
> but small values relative to the largest. Hence a vector of similar tiny 
> values doesn't get zapped.
>
> Maybe the line in the docs:
>
> " (compared with the maximal absolute value)"
>
> needs to read:
>
> " (compared with the maximal absolute value in the vector)"
>
> Barry
>
>
>
>
>
> On Sun, Dec 17, 2023 at 2:17 PM Duncan Murdoch  
> wrote:
>>
>> This email originated outside the University. Check before clicking links or 
>> attachments.
>>
>> I'm really confused.  Steve's example wasn't a scalar x, it was a
>> vector.  Your zapsmall() proposal wouldn't zap it to zero, and I don't
>> see why summary() would if it was using your proposal.
>>
>> Duncan Murdoch
>>
>> On 17/12/2023 8:43 a.m., Gregory R. Warnes wrote:
>> > Isn’t that the correct outcome?  The user can change the number of digits 
>> > if they want to see small values…
>> >
>> >
>> > --
>> > Change your thoughts and you change the world.
>> > --Dr. Norman Vincent Peale
>> >
>> >> On Dec 17, 2023, at 12:11 AM, Steve Martin  
>> >> wrote:
>> >>
>> >> Zapping a vector of small numbers to zero would cause problems when
>> >> printing the results of summary(). For example, if
>> >> zapsmall(c(2.220446e-16, ..., 2.220446e-16)) == c(0, ..., 0) then
>> >> print(summary(2.220446e-16), digits = 7) would print
>> >>Min. 1st Qu.  MedianMean 3rd Qu.Max.
>> >> 0  00   0   0  0
>> >>
>> >> The same problem can also appear when printing the results of
>> >> summary.glm() with show.residuals = TRUE if there's little dispersion
>> >> in the residuals.
>> >>
>> >> Steve
>> >>
>> >>> On Sat, 16 Dec 2023 at 17:34, Gregory Warnes  wrote:
>> >>>
>> >>> I was quite suprised to discover that applying `zapsmall` to a scalar 
>> >>> value has no apparent effect.  For example:
>> >>>
>>  y <- 2.220446e-16
>>  zapsmall(y,)
>> >>> [1] 2.2204e-16
>> >>>
>> >>> I was expecting zapsmall(x)` to act like
>> >>>
>>  round(y, digits=getOption('digits'))
>> >>> [1] 0
>> >>>
>> >>> Looking at the current source code, indicates that `zapsmall` is 
>> >>> expecting a vector:
>> >>>
>> >>> zapsmall <-
>> >>> function (x, digits = getOption("digits"))
>> >>> {
>> >>> if (length(digits) == 0L)
>> >>> stop("invalid 'digits'")
>> >>> if (all(ina <- is.na(x)))
>> >>> return(x)
>> >>> mx <- max(abs(x[!ina]))
>> >>> round(x, digits = if (mx > 0) max(0L, digits - 
>> >>> as.numeric(log10(mx))) else digits)
>> >>> }
>> >>>
>> >>> If `x` is a non-zero scalar, zapsmall will never perform rounding.
>> >>>
>> >>> The man page simply states:
>> >>> zapsmall determines a digits argument dr for calling round(x, digits = 
>> >>> dr) such that values close to zero (compared with the maximal absolute 
>> >>> value) are ‘zapped’, i.e., replaced by 0.
>> >>>
>> >>> and doesn’t provide any details about how ‘close to zero’ is defined.
>> >>>
>> >>> Perhaps handling the special when `x` is a scalar (or only contains a 
>> >>> single non-NA value)  would make sense:
>> >>>
>> >>> zapsmall <-
>> >>> function (x, digits = getOption("digits"))
>> >>> {
>> >>> if (length(digits) == 0L)
>> >>> stop("invalid 'digits'")
>> >>> if (all(ina <- is.na(x)))
>> >>> return(x)
>> >>> mx <- max(abs(x[!ina]))
>> >>> round(x, digits = if (mx >

Re: [R-pkg-devel] CRAN submission struggle

2023-12-17 Thread Christiaan Pieterse

Hi Ivan

I have decided to clean up the existing package using a branch, as you
suggested. The branch I've created is available at:
https://github.com/WoutersResearchGroup/R-IO-PS/tree/CRAN-prep.

I've cleaned, built and checked this branch package but I get one error and
2 notes (one is the new submission note).
The error is related to the example I'm running. I suspect it might be due
to the way I am trying to import the ExampleTradeData. Here is the error
and note:

* checking examples ... ERROR
Running examples in ‘iopspackage-Ex.R’ failed
The error most likely occurred in:

> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: IOPS
> ### Title: IOPS
> ### Aliases: IOPS
>
> ### ** Examples
>
> # Load the example data
> ExampleTradeData <-
read.csv(system.file("extdata","ExampleTradeData.csv",package="iopspackage"))
>
> # Create a temporary directory
> temp_dir <- tempfile()
> dir.create(temp_dir)
>
> # Set the working directory to the temporary directory
> old_dir <- setwd(temp_dir)
>
> # Then use it in your function
> IOPS(
+   CountryCode = 710,
+   tradeData = ExampleTradeData,
+   ComplexMethod = "reflections",
+   iterCompl = 5,
+   GVCMapping = NULL,
+   tradedigit = 6
+ )
Selected country: ZAF
Export data 6-digit summation complete
Trade data successfully imported
M-matrices calculated
RCA calculated
Starting calculation of complexity measures using the 'reflections' method
Warning in complexity_measures(Mbin, method = "reflections", iterations =
iterCompl) :
  'iterations' was changed to 'iterations + 1' to work with an even number
of iterations
Killed

* checking HTML version of manual ... NOTE
Skipping checking HTML validation: no command 'tidy' found

Note that I also updated the iopspackage2.0.R as you suggested, and I did
re-run roxygen before building and checking (using roxygen2::roxygenize()).
All the updated folders are in the "CRAN-prep" branch (link provided above).

Regards
Christiaan

On Sun, 17 Dec 2023 at 16:06, Ivan Krylov  wrote:

> On Sun, 17 Dec 2023 15:29:34 +0200
> Christiaan Pieterse  wrote:
>
> > But, I've uploaded the newly created package as discussed in my first
> > email, available at:
> > https://github.com/ChristiaanPieterse/iopspackage2.1.0
>
> Are you sure it wouldn't be better to clean up the existing package
> instead of creating unrelated forks? If you're afraid of breaking
> something that works, do the work on a separate branch
> 
> until it both works as well as your current repo currently does *and*
> passes R CMD check --as-cran.
>
> > * checking CRAN incoming feasibility ... [25s] NOTE
> > Maintainer: 'C.J Pieterse '
> > New submission
>
> "New submission" is to be expected.
>
> > Unknown, possibly misspelled, fields in DESCRIPTION:
> >   'Exports'
>
> "Writing R Extensions" doesn't define a field named "Exports". The
> exports are declared in the NAMESPACE file. Since you're using
> roxygen2, use its @export tag to export your functions and remove the
> Exports: field.
>
> > * checking whether package 'iopspackage' can be installed ... [27s]
> > WARNING Found the following significant warnings:
> >   Warning: package 'Rcpp' was built under R version 4.3.2
>
> This is probably not a problem with your package (but may be a problem
> with the way the machine running R CMD check is set up).
>
> > * checking dependencies in R code ... NOTE
> > Namespaces in Imports field not imported from:
> >   'openxlsx' 'roxygen2' 'tibble'
> >   All declared Imports should be used.
>
> > * checking R code for possible problems ... [12s] NOTE
> > IOPS: no visible global function definition for 'createWorkbook'
> > IOPS: no visible global function definition for 'addWorksheet'
> > IOPS: no visible global function definition for 'writeData'
> > IOPS: no visible global function definition for 'saveWorkbook'
> > Undefined global functions or variables:
> >   addWorksheet createWorkbook saveWorkbook writeData
>
> Are you sure you should be importing roxygen2? You only run
> roxygenise() before running R CMD build in order to generate
> man/*.Rd and NAMESPACE; I don't think it's used after that.
>
> If you don't use functions from tibble, there's no need to import it
> or depend on it either. I also don't see you directly using Rcpp, but
> there's no warning about it for some reason.
>
> Use the @importFrom tags to import individual functions that you
> actually use (i.e. createWorkbook and friends). See
> 
> for more information on importing.
>
> Also, remove all library() calls from R/iopspackage2.R. Packages live
> in namespaces, not in the global environment; your package should rely
> upon the dependency information in DESCRIPTION and NAMESPACE (the
> latter generated by roxygen2) for its dependencies.
>
> > > data(ExampleTradeData)
> > Warning in data(ExampleTradeData) :
> >   data set 'ExampleTradeData' not found
>
>

Re: [Rd] [External] Re: zapsmall(x) for scalar x

2023-12-17 Thread Barry Rowlingson

I think what's been missed is that zapsmall works relative to the absolute
largest value in the vector. Hence if there's only one
item in the vector, it is the largest, so its not zapped. The function's
raison d'etre isn't to replace absolutely small values,
but small values relative to the largest. Hence a vector of similar tiny
values doesn't get zapped.

Maybe the line in the docs:

" (compared with the maximal absolute value)"

needs to read:

" (compared with the maximal absolute value in the vector)"

Barry





On Sun, Dec 17, 2023 at 2:17 PM Duncan Murdoch 
wrote:

> This email originated outside the University. Check before clicking links
> or attachments.
>
> I'm really confused.  Steve's example wasn't a scalar x, it was a
> vector.  Your zapsmall() proposal wouldn't zap it to zero, and I don't
> see why summary() would if it was using your proposal.
>
> Duncan Murdoch
>
> On 17/12/2023 8:43 a.m., Gregory R. Warnes wrote:
> > Isn’t that the correct outcome?  The user can change the number of
> digits if they want to see small values…
> >
> >
> > --
> > Change your thoughts and you change the world.
> > --Dr. Norman Vincent Peale
> >
> >> On Dec 17, 2023, at 12:11 AM, Steve Martin 
> wrote:
> >>
> >> Zapping a vector of small numbers to zero would cause problems when
> >> printing the results of summary(). For example, if
> >> zapsmall(c(2.220446e-16, ..., 2.220446e-16)) == c(0, ..., 0) then
> >> print(summary(2.220446e-16), digits = 7) would print
> >>Min. 1st Qu.  MedianMean 3rd Qu.Max.
> >> 0  00   0   0  0
> >>
> >> The same problem can also appear when printing the results of
> >> summary.glm() with show.residuals = TRUE if there's little dispersion
> >> in the residuals.
> >>
> >> Steve
> >>
> >>> On Sat, 16 Dec 2023 at 17:34, Gregory Warnes  wrote:
> >>>
> >>> I was quite suprised to discover that applying `zapsmall` to a scalar
> value has no apparent effect.  For example:
> >>>
>  y <- 2.220446e-16
>  zapsmall(y,)
> >>> [1] 2.2204e-16
> >>>
> >>> I was expecting zapsmall(x)` to act like
> >>>
>  round(y, digits=getOption('digits'))
> >>> [1] 0
> >>>
> >>> Looking at the current source code, indicates that `zapsmall` is
> expecting a vector:
> >>>
> >>> zapsmall <-
> >>> function (x, digits = getOption("digits"))
> >>> {
> >>> if (length(digits) == 0L)
> >>> stop("invalid 'digits'")
> >>> if (all(ina <- is.na(x)))
> >>> return(x)
> >>> mx <- max(abs(x[!ina]))
> >>> round(x, digits = if (mx > 0) max(0L, digits -
> as.numeric(log10(mx))) else digits)
> >>> }
> >>>
> >>> If `x` is a non-zero scalar, zapsmall will never perform rounding.
> >>>
> >>> The man page simply states:
> >>> zapsmall determines a digits argument dr for calling round(x, digits =
> dr) such that values close to zero (compared with the maximal absolute
> value) are ‘zapped’, i.e., replaced by 0.
> >>>
> >>> and doesn’t provide any details about how ‘close to zero’ is defined.
> >>>
> >>> Perhaps handling the special when `x` is a scalar (or only contains a
> single non-NA value)  would make sense:
> >>>
> >>> zapsmall <-
> >>> function (x, digits = getOption("digits"))
> >>> {
> >>> if (length(digits) == 0L)
> >>> stop("invalid 'digits'")
> >>> if (all(ina <- is.na(x)))
> >>> return(x)
> >>> mx <- max(abs(x[!ina]))
> >>> round(x, digits = if (mx > 0 && (length(x)-sum(ina))>1 ) max(0L,
> digits - as.numeric(log10(mx))) else digits)
> >>> }
> >>>
> >>> Yielding:
> >>>
>  y <- 2.220446e-16
>  zapsmall(y)
> >>> [1] 0
> >>>
> >>> Another edge case would be when all of the non-na values are the same:
> >>>
>  y <- 2.220446e-16
>  zapsmall(c(y,y))
> >>> [1] 2.220446e-16 2.220446e-16
> >>>
> >>> Thoughts?
> >>>
> >>>
> >>> Gregory R. Warnes, Ph.D.
> >>> g...@warnes.net
> >>> Eternity is a long time, take a friend!
> >>>
> >>>
> >>>
> >>> [[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] zapsmall(x) for scalar x

2023-12-17 Thread Duncan Murdoch

I'm really confused.  Steve's example wasn't a scalar x, it was a 
vector.  Your zapsmall() proposal wouldn't zap it to zero, and I don't 
see why summary() would if it was using your proposal.


Duncan Murdoch

On 17/12/2023 8:43 a.m., Gregory R. Warnes wrote:

Isn’t that the correct outcome?  The user can change the number of digits if 
they want to see small values…


--
Change your thoughts and you change the world.
--Dr. Norman Vincent Peale


On Dec 17, 2023, at 12:11 AM, Steve Martin  wrote:

Zapping a vector of small numbers to zero would cause problems when
printing the results of summary(). For example, if
zapsmall(c(2.220446e-16, ..., 2.220446e-16)) == c(0, ..., 0) then
print(summary(2.220446e-16), digits = 7) would print
   Min. 1st Qu.  MedianMean 3rd Qu.Max.
0  00   0   0  0

The same problem can also appear when printing the results of
summary.glm() with show.residuals = TRUE if there's little dispersion
in the residuals.

Steve


On Sat, 16 Dec 2023 at 17:34, Gregory Warnes  wrote:

I was quite suprised to discover that applying `zapsmall` to a scalar value has 
no apparent effect.  For example:


y <- 2.220446e-16
zapsmall(y,)

[1] 2.2204e-16

I was expecting zapsmall(x)` to act like


round(y, digits=getOption('digits'))

[1] 0

Looking at the current source code, indicates that `zapsmall` is expecting a 
vector:

zapsmall <-
function (x, digits = getOption("digits"))
{
if (length(digits) == 0L)
stop("invalid 'digits'")
if (all(ina <- is.na(x)))
return(x)
mx <- max(abs(x[!ina]))
round(x, digits = if (mx > 0) max(0L, digits - as.numeric(log10(mx))) else 
digits)
}

If `x` is a non-zero scalar, zapsmall will never perform rounding.

The man page simply states:
zapsmall determines a digits argument dr for calling round(x, digits = dr) such 
that values close to zero (compared with the maximal absolute value) are 
‘zapped’, i.e., replaced by 0.

and doesn’t provide any details about how ‘close to zero’ is defined.

Perhaps handling the special when `x` is a scalar (or only contains a single 
non-NA value)  would make sense:

zapsmall <-
function (x, digits = getOption("digits"))
{
if (length(digits) == 0L)
stop("invalid 'digits'")
if (all(ina <- is.na(x)))
return(x)
mx <- max(abs(x[!ina]))
round(x, digits = if (mx > 0 && (length(x)-sum(ina))>1 ) max(0L, digits - 
as.numeric(log10(mx))) else digits)
}

Yielding:


y <- 2.220446e-16
zapsmall(y)

[1] 0

Another edge case would be when all of the non-na values are the same:


y <- 2.220446e-16
zapsmall(c(y,y))

[1] 2.220446e-16 2.220446e-16

Thoughts?


Gregory R. Warnes, Ph.D.
g...@warnes.net
Eternity is a long time, take a friend!



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] CRAN submission struggle

2023-12-17 Thread Ivan Krylov

On Sun, 17 Dec 2023 15:29:34 +0200
Christiaan Pieterse  wrote:

> But, I've uploaded the newly created package as discussed in my first
> email, available at:
> https://github.com/ChristiaanPieterse/iopspackage2.1.0

Are you sure it wouldn't be better to clean up the existing package
instead of creating unrelated forks? If you're afraid of breaking
something that works, do the work on a separate branch

until it both works as well as your current repo currently does *and*
passes R CMD check --as-cran.

> * checking CRAN incoming feasibility ... [25s] NOTE
> Maintainer: 'C.J Pieterse '
> New submission

"New submission" is to be expected.

> Unknown, possibly misspelled, fields in DESCRIPTION:
>   'Exports'

"Writing R Extensions" doesn't define a field named "Exports". The
exports are declared in the NAMESPACE file. Since you're using
roxygen2, use its @export tag to export your functions and remove the
Exports: field.

> * checking whether package 'iopspackage' can be installed ... [27s]
> WARNING Found the following significant warnings:
>   Warning: package 'Rcpp' was built under R version 4.3.2

This is probably not a problem with your package (but may be a problem
with the way the machine running R CMD check is set up).

> * checking dependencies in R code ... NOTE
> Namespaces in Imports field not imported from:
>   'openxlsx' 'roxygen2' 'tibble'
>   All declared Imports should be used.

> * checking R code for possible problems ... [12s] NOTE
> IOPS: no visible global function definition for 'createWorkbook'
> IOPS: no visible global function definition for 'addWorksheet'
> IOPS: no visible global function definition for 'writeData'
> IOPS: no visible global function definition for 'saveWorkbook'
> Undefined global functions or variables:
>   addWorksheet createWorkbook saveWorkbook writeData

Are you sure you should be importing roxygen2? You only run
roxygenise() before running R CMD build in order to generate
man/*.Rd and NAMESPACE; I don't think it's used after that.

If you don't use functions from tibble, there's no need to import it
or depend on it either. I also don't see you directly using Rcpp, but
there's no warning about it for some reason.

Use the @importFrom tags to import individual functions that you
actually use (i.e. createWorkbook and friends). See

for more information on importing.

Also, remove all library() calls from R/iopspackage2.R. Packages live
in namespaces, not in the global environment; your package should rely
upon the dependency information in DESCRIPTION and NAMESPACE (the
latter generated by roxygen2) for its dependencies.

> > data(ExampleTradeData)  
> Warning in data(ExampleTradeData) :
>   data set 'ExampleTradeData' not found

There's no 'data' directory and no file named ExampleTradeData.* in it.
Data for use by the function data() should be prepared as described in
.
If you want to use files under inst/extdata, you have to read them
manually:

ETD <- read.csv(system.file(
 file.path('extdata','ExampleTradeData.csv'),
 package = 'iopspackage'
))

> * checking for detritus in the temp directory ... NOTE
> Found the following files/directories:
>   'lastMiKTeXException'

Is this on R-hub? This usually happens on R-hub and doesn't indicate a
problem with your package.

> #' temp_dir <- tempdir()
> #' 
> #' # Set the working directory to a temporary directory
> #' setwd(temp_dir)
<...>
> #' # Clean up the temporary directory
> #' unlink(temp_dir, recursive = TRUE)

Please make it a subdirectory of the session temporary directory:

temp_dir <- tempfile()
dir.create(temp_dir)
...

Removing the session temporary directory is not as bad as directly
overwriting user data (it's all going away after the process is shut
down), but quite a lot of parts of R and other packages rely on
tempdir() being a directory that exists, not to mention that there
could be other temporary files in use by other packages.

-- 
Best regards,
Ivan

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] zapsmall(x) for scalar x

2023-12-17 Thread Gregory R. Warnes

Isn’t that the correct outcome?  The user can change the number of digits if 
they want to see small values…


--  
Change your thoughts and you change the world.
--Dr. Norman Vincent Peale

> On Dec 17, 2023, at 12:11 AM, Steve Martin  wrote:
> 
> Zapping a vector of small numbers to zero would cause problems when
> printing the results of summary(). For example, if
> zapsmall(c(2.220446e-16, ..., 2.220446e-16)) == c(0, ..., 0) then
> print(summary(2.220446e-16), digits = 7) would print
>   Min. 1st Qu.  MedianMean 3rd Qu.Max.
>0  00   0   0  0
> 
> The same problem can also appear when printing the results of
> summary.glm() with show.residuals = TRUE if there's little dispersion
> in the residuals.
> 
> Steve
> 
>> On Sat, 16 Dec 2023 at 17:34, Gregory Warnes  wrote:
>> 
>> I was quite suprised to discover that applying `zapsmall` to a scalar value 
>> has no apparent effect.  For example:
>> 
>>> y <- 2.220446e-16
>>> zapsmall(y,)
>> [1] 2.2204e-16
>> 
>> I was expecting zapsmall(x)` to act like
>> 
>>> round(y, digits=getOption('digits'))
>> [1] 0
>> 
>> Looking at the current source code, indicates that `zapsmall` is expecting a 
>> vector:
>> 
>> zapsmall <-
>> function (x, digits = getOption("digits"))
>> {
>>if (length(digits) == 0L)
>>stop("invalid 'digits'")
>>if (all(ina <- is.na(x)))
>>return(x)
>>mx <- max(abs(x[!ina]))
>>round(x, digits = if (mx > 0) max(0L, digits - as.numeric(log10(mx))) 
>> else digits)
>> }
>> 
>> If `x` is a non-zero scalar, zapsmall will never perform rounding.
>> 
>> The man page simply states:
>> zapsmall determines a digits argument dr for calling round(x, digits = dr) 
>> such that values close to zero (compared with the maximal absolute value) 
>> are ‘zapped’, i.e., replaced by 0.
>> 
>> and doesn’t provide any details about how ‘close to zero’ is defined.
>> 
>> Perhaps handling the special when `x` is a scalar (or only contains a single 
>> non-NA value)  would make sense:
>> 
>> zapsmall <-
>> function (x, digits = getOption("digits"))
>> {
>>if (length(digits) == 0L)
>>stop("invalid 'digits'")
>>if (all(ina <- is.na(x)))
>>return(x)
>>mx <- max(abs(x[!ina]))
>>round(x, digits = if (mx > 0 && (length(x)-sum(ina))>1 ) max(0L, digits - 
>> as.numeric(log10(mx))) else digits)
>> }
>> 
>> Yielding:
>> 
>>> y <- 2.220446e-16
>>> zapsmall(y)
>> [1] 0
>> 
>> Another edge case would be when all of the non-na values are the same:
>> 
>>> y <- 2.220446e-16
>>> zapsmall(c(y,y))
>> [1] 2.220446e-16 2.220446e-16
>> 
>> Thoughts?
>> 
>> 
>> Gregory R. Warnes, Ph.D.
>> g...@warnes.net
>> Eternity is a long time, take a friend!
>> 
>> 
>> 
>>[[alternative HTML version deleted]]
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] CRAN submission struggle

2023-12-17 Thread Christiaan Pieterse

Hi, thank you for all the responses.

I have uploaded the previous package to GitHub, available at:
https://github.com/WoutersResearchGroup/R-IO-PS . Note that this works when
installed via GitHub using devtools, but is a bit messy. Hence I decided to
start over for CRAN release. If you can help me to get this uploaded to
cran it would be awesome!

But, I've uploaded the newly created package as discussed in my first
email, available at: https://github.com/ChristiaanPieterse/iopspackage2.1.0
This doesn't have a readme. See the readme at the first link above.

Here are the Errors, Warnings and Notes from the check:

* checking CRAN incoming feasibility ... [25s] NOTE
Maintainer: 'C.J Pieterse '
New submission
Unknown, possibly misspelled, fields in DESCRIPTION:
  'Exports'

* checking whether package 'iopspackage' can be installed ... [27s] WARNING
Found the following significant warnings:
  Warning: package 'Rcpp' was built under R version 4.3.2

* checking dependencies in R code ... NOTE
Namespaces in Imports field not imported from:
  'openxlsx' 'roxygen2' 'tibble'
  All declared Imports should be used.

* checking R code for possible problems ... [12s] NOTE
IOPS: no visible global function definition for 'createWorkbook'
IOPS: no visible global function definition for 'addWorksheet'
IOPS: no visible global function definition for 'writeData'
IOPS: no visible global function definition for 'saveWorkbook'
Undefined global functions or variables:
  addWorksheet createWorkbook saveWorkbook writeData

* checking examples ... ERROR
Running examples in 'iopspackage-Ex.R' failed
The error most likely occurred in:
> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: IOPS
> ### Title: IOPS
> ### Aliases: IOPS
>
> ### ** Examples
>
>
> # Load the example data
> data(ExampleTradeData)
Warning in data(ExampleTradeData) :
  data set 'ExampleTradeData' not found
>
> oldwd <- getwd()
> temp_dir <- tempdir()
>
> # Set the working directory to a temporary directory
> setwd(temp_dir)
>
> # Then use it in your function
> IOPS(
+   CountryCode = 710,
+   tradeData = ExampleTradeData,
+   ComplexMethod = "reflections",
+   iterCompl = 5,
+   GVCMapping = NULL,
+   tradedigit = 6
+ )
Selected country: ZAF
Error: object 'ExampleTradeData' not found
Execution halted

* checking for detritus in the temp directory ... NOTE
Found the following files/directories:
  'lastMiKTeXException'

I've struggled for a while with the error on my example that doesn't want
to run. I'd like to know if I've uploaded the ExampleTradeDate correctly as
seen in the inst/extdata file. I was also told previously to create a
temporary directory for the function output and delete the temporary
directory after the example, but I'm unsure if I did it correctly.

Thank you for the assistance
Christiaan

On Sat, 16 Dec 2023 at 20:07, Ivan Krylov  wrote:

> On Sat, 16 Dec 2023 19:41:16 +0200
> Christiaan Pieterse  wrote:
>
> > This .R file contained the Roxygen2 comments. (I was very unsure what
> > comments to include in this so it might be wrong, I'm unsure)
>
> If you like roxygen2 and would like to keep using it, you're welcome to
> keep the roxygen2 comments in your R files. Just don't forget to re-run
> roxygenise() every time you update them.
>
> >3. Included a DESCRIPTION file is the 'iopspackage' folder. (Once
> > again I was very unsure what to include in this file so it might be
> > wrong).
>
> Does it help to follow the guide at
> ?
> Start with the mandatory fields Package, Version, License,
> Description, Title and Authors@R (to generate Author: and Maintainer:
> from).
>
> >8. I checked the tar file using *R CMD check --as-cran
> >"iopspackage_2.1.0.tar.gz". *This yielded errors, warnings and
> > notes which I don't know how to solve and suspect are due to me
> > setting the file up wrong.
>
> Can you show us the log from the check? It should be fine to copy &
> paste the entries that don't say OK (i.e. NOTEs, WARNINGs, and ERRORs).
>
> Most of what you'll need to fix is described in "Writing R Extensions"
> (link above) and the CRAN policy at
> .
>
> > I've been told before not to include my package as an attachment, so
> > can someone please help me with the submission process?
>
> Can you publish the code anywhere? Ideally, this place should provide
> instant access to the latest version of every source code file inside
> your package. The most popular option nowadays is GitHub, but it does
> not have to be GitHub. Two GDPR-friendly alternatives are Codeberg and
> SourceHut. If you don't like Git (which does take effort to learn),
> there's R-Forge and Chiselapp.com. If you don't want to learn software
> version control right now, any free web/file hosting will suffice as
> long as you keep the files updated and accessible.
>
> > It is a 10mb file
>
> I think we've discussed this

Re: [Rd] [External] Re: zapsmall(x) for scalar x

Re: [R-pkg-devel] CRAN submission struggle

Re: [Rd] [External] Re: zapsmall(x) for scalar x

Re: [Rd] zapsmall(x) for scalar x

Re: [R-pkg-devel] CRAN submission struggle

Re: [Rd] zapsmall(x) for scalar x

Re: [R-pkg-devel] CRAN submission struggle

7 matches

Site Navigation

Mail list logo

Footer information