Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device

[Paul Murrell]

Hi

Yes, you can set up your own font and TeX installations are a good 
source of Type 1 fonts.  Here is an example (paths obviously specific to 
my [Ubuntu 20.04] OS and TeX installation) ...



cmlgc <- Type1Font("cmlgc",

rep("/usr/share/texlive/texmf-dist/fonts/afm/public/cm-lgc/fcmr6z.afm", 4),
   encoding="Cyrillic")
pdfFonts(cmlgc=cmlgc)

x <- '\u410\u411\u412'
pdf("cmlgc.pdf", family="cmlgc", encoding="Cyrillic")
plot(1:10, main = x)
dev.off()

embedFonts("cmlgc.pdf", out="cmlgc-embed.pdf",

fontpaths="/usr/share/texlive/texmf-dist/fonts/type1/public/cm-lgc/")


Final result attached.

Thanks for the patch for the unrelated memory problem;  I will take a 
look at that.


Paul

On 24/09/23 09:43, Ivan Krylov wrote:

On Wed, 20 Sep 2023 12:39:50 +0200
Martin Maechler  wrote:

 > The problem is that some pdf *viewers*,
 > notably `evince` on Fedora Linux, for several years now,
 > do *not* show *some* of the UTF-8 glyphs because they do not use
 > the correct fonts

One more problem that makes it nontrivial to use Unicode with pdf() is
the graphics device not knowing some of the font metrics:

x <- '\u410\u411\u412'
pdf()
plot(1:10, main = x)
# Warning messages:
# 1: In title(...) : font width unknown for character 0xb0
# 2: In title(...) : font width unknown for character 0xe4
# 3: In title(...) : font width unknown for character 0xfc
# 4: In title(...) : font width unknown for character 0x7f
dev.off()

In the resulting PDF file, the three letters are visible, at least in
Evince 3.38.2, but they are all positioned in the same space.

I understand that this is strictly speaking not pdf()'s fault
(grDevices contains the font metrics for all standard Adobe fonts and a
few more), but I'm not sure what to do as a user. Should I call
pdfFonts(...), declaring a font with all symbols I need? Where does one
even get Type-1 Cyrillic Helvetica (or any other font) with separate
font metrics files for use with pdf()?

Actually, the wrong number of sometimes random character codes reminds
me of stack garbage. In src/library/grDevices/src/devPS.c, function
static double PostScriptStringWidth, there's this bit of code:

if(!strIsASCII((char *) str) &&
/*
* Every fifth font is a symbol font:
* see postscriptFonts()
*/
(face % 5) != 0) {
R_CheckStack2(strlen((char *)str)+1);
char buff[strlen((char *)str)+1];
/* Output string cannot be longer */
mbcsToSbcs((char *)str, buff, encoding, enc);
str1 = (unsigned char *)buff;
}

Later the characters in str1 are iterated over in order to calculate
the total width of the string. I didn't notice this myself until I saw
in the debugger that after a few iterations of the loop, the contents
of str1 are completely different from the result of mbcsToSbcs((char
*)str, buff, encoding, enc), and went to investigate. Only after the
debugger told me that there's no variable called "buff" I realised that
the VLA pointed to by str1 no longer exists.

--- src/library/grDevices/src/devPS.c (revision 85214)
+++ src/library/grDevices/src/devPS.c (working copy)
@@ -721,6 +721,8 @@
unsigned char p1, p2;

int status;
+ /* May be about to allocate */
+ void *alloc = vmaxget();
if(!metrics && (face % 5) != 0) {
/* This is the CID font case, and should only happen for
non-symbol fonts. So we assume monospaced with multipliers.
@@ -755,9 +757,8 @@
* Every fifth font is a symbol font:
* see postscriptFonts()
*/
- (face % 5) != 0) {
- R_CheckStack2(strlen((char *)str)+1);
- char buff[strlen((char *)str)+1];
+ (face % 5) != 0 && metrics) {
+ char *buff = R_alloc(strlen((char *)str)+1, 1);
/* Output string cannot be longer */
mbcsToSbcs((char *)str, buff, encoding, enc);
str1 = (unsigned char *)buff;
@@ -792,6 +793,7 @@
}
}
}
+ vmaxset(alloc);
return 0.001 * sum;
}



After this patch, I'm consistently getting the right character codes in
the warnings, but I still don't know how to set up the font metrics.

--
Best regards,
Ivan

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



--
Dr Paul Murrell
Te Kura Tatauranga | Department of Statistics
Waipapa Taumata Rau | The University of Auckland
Private Bag 92019, Auckland 1142, New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
www.stat.auckland.ac.nz/~paul/


cmlgc-embed.pdf
Description: Adobe PDF document
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Tight bounding box around text in graphics?

[Paul Murrell]

Hi

strheight(), which is based GEStrHeight(), is pretty crude, not only 
ignoring descenders, but also only considering the ascent of the overall 
font (capital "M").


There is a GEStrMetric(), which returns character-specific ascent and 
descent, but that is only currently exposed via grid::stringAscent() and 
grid::stringDescent().  There is also grid::stringHeight(), which is as 
unsubtle as strheight().


For example, these are all the same (just font ascent) ...

> strheight("y", "in")
[1] 0.1248031
> strheight("x", "in")
[1] 0.1248031
> strheight("M", "in")
[1] 0.1248031

... and these are all the same ...

> convertHeight(stringHeight("y"), "in")
[1] 0.124803149606299inches
> convertHeight(stringHeight("x"), "in")
[1] 0.124803149606299inches
> convertHeight(stringAscent("M"), "in")
[1] 0.124803149606299inches

... but these have more detail ...

> convertHeight(stringAscent("y"), "in")
[1] 0.0936023622047244inches
> convertHeight(stringDescent("y"), "in")
[1] 0.0416010498687664inches
> convertHeight(stringAscent("x"), "in")
[1] 0.0936023622047244inches
> convertHeight(stringDescent("x"), "in")
[1] 0inches
> convertHeight(stringHeight("M"), "in")
[1] 0.124803149606299inches
> convertHeight(stringDescent("M"), "in")
[1] 0inches

In theory, it should not be difficult to add a graphics::strascent() and 
graphics::strdescent() if that would help.


Paul

On 26/09/23 08:06, Duncan Murdoch wrote:

I've mentioned in previous messages that I'm trying to redo rgl text.

Part of what I need is to measure the size of strings in pixels when
they are drawn by base graphics.

It appears that

strwidth(texts, "user", cex = cex, font = font, family = family)

gives accurate measurements of the width in user coordinates. I've got
those set up to match pixels, so I'm fine here.

However, the equivalent call for strheight() only measures height above
the baseline according to the docs, and indeed the number is smaller
than the size of what's displayed. Descenders (e.g. the tail of "y")
aren't counted.

Is there a way to measure how far a character might descend? Is it
valid to assume it won't descend more than a line height below the top
of the char?

I have a partial solution -- textshaping::shape_text gives a "height"
value that includes lots of space below the character, and a
"top_border" value that measures from the top of the textbox to the
baseline. So I think `height - top_border` would give me what I'm
asking for. But this only works with graphics devices in the ragg
package. Is there a general solution?

Duncan Murdoch

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



--
Dr Paul Murrell
Te Kura Tatauranga | Department of Statistics
Waipapa Taumata Rau | The University of Auckland
Private Bag 92019, Auckland 1142, New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
www.stat.auckland.ac.nz/~paul/

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

[Rd] Tight bounding box around text in graphics?

[Duncan Murdoch]

I've mentioned in previous messages that I'm trying to redo rgl text.

Part of what I need is to measure the size of strings in pixels when 
they are drawn by base graphics.


It appears that

  strwidth(texts, "user", cex = cex, font = font, family = family)

gives accurate measurements of the width in user coordinates.  I've got 
those set up to match pixels, so I'm fine here.


However, the equivalent call for strheight() only measures height above 
the baseline according to the docs, and indeed the number is smaller 
than the size of what's displayed.  Descenders (e.g. the tail of "y") 
aren't counted.


Is there a way to measure how far a character might descend?  Is it 
valid to assume it won't descend more than a line height below the top 
of the char?


I have a partial solution -- textshaping::shape_text gives a "height" 
value that includes lots of space below the character, and a 
"top_border" value that measures from the top of the textbox to the 
baseline.  So I think `height - top_border` would give me what I'm 
asking for.  But this only works with graphics devices in the ragg 
package.  Is there a general solution?


Duncan Murdoch

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

Re: [R-pkg-devel] help with revdep_check

[William Revelle]

Thanks.  Although I have had Xtools for quite a while, it had not been 
activated.  Installing a new copy made all the difference

Bill


> On Sep 25, 2023, at 12:24 PM, Gábor Csárdi  wrote:
> 
> Seems like you are on macOS. You need to install XCode or the Command
> Line Tools to be able to compile packages with C/C++/Fortran code.
> 
> Gabor
> 
> On Mon, Sep 25, 2023 at 7:02 PM William Revelle  wrote:
>> 
>> Dear friends,
>> I am trying to release a new update to psych and psychTools and am having 
>> problems with revdep_check
>> 
>> The error message from revdep_check is less than helpful:’
>> 
>> fn is
>> 
>> fn  <-  "/Users/WR/Library/CloudStorage/Dropbox/psychTools/"
>> 
>> revdep_check(fn,num_workers=8)
>> ── CHECK 
>> ──
>>  15 packages ──
>> [0/15] 00:00:15 | ETA:  ?s | (8) afex [I], bootnet [I], modnets [I], psych 
>> [I], alphaci [D], C...Error: Could not find tools necessary to compile a 
>> package
>> Call `pkgbuild::check_build_tools(debug = TRUE)` to diagnose the problem.
>>> check_build_tools(debug=TRUE)
>> Trying to compile a simple C file
>> Error: Could not find tools necessary to compile a package
>> Call `pkgbuild::check_build_tools(debug = TRUE)` to diagnose the problem.
>> rror: Could not find tools necessary to compile a package
>> 
>> Any suggestions would be appreciated.
>> 
>> William Revellepersonality-project.org/revelle.html
>> Professor  personality-project.org
>> Department of Psychology www.wcas.northwestern.edu/psych/
>> Northwestern Universitywww.northwestern.edu/
>> Use R for psychology personality-project.org/r
>> It is 90 seconds to midnight   www.thebulletin.org
>> 
>> 
>>[[alternative HTML version deleted]]
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

William Revellepersonality-project.org/revelle.html
Professorpersonality-project.org
Department of Psychology www.wcas.northwestern.edu/psych/
Northwestern Universitywww.northwestern.edu/
Use R for psychology personality-project.org/r
It is 90 seconds to midnightwww.thebulletin.org

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

Re: [Bioc-devel] KEGGREST is broken and has a long reverse-dependency chain.

[Ramos Perez, Marcel via Bioc-devel]

Thank you for the fix.
I have updated the package.

Best,

Marcel

On 9/21/23 7:12 PM, Ali Sajid Imami wrote:

I'll take a look. I rely on KEGGREST a lot.


Regards,
Dr. Ali Sajid Imami
LinkedIn 



On Thu, Sep 21, 2023 at 7:02 PM Charles Plessy 

wrote:



Dear all,

yesterday I reported on GitHub that the regression tests of KEGGREST
fail because the KEGGREST:::.get.tmp.url function can not parse
www.kegg.jp pages anymore.

https://github.com/Bioconductor/KEGGREST/issues/21

This is a problem in Debian because 1) we do not allow the Bioconductor
packages that we redistribute to fail their tests and 2) the
reverse-dependency chain of KEGGREST is heavy.

KEGGREST <- AnnotationDbi <- GenomicFeatures <- lots of other packages

I am not familiar with KEGG enough to grasp what KEGGREST:::.get.tmp.url
was looking for.  But I was wondering if this bug would be a low-hanging
fruit for somebody else in this list?

Have a nice day,

Charles Plessy

--
Charles Plessy - - ~ ~ ~ ~ ~  ~ ~ ~ ~ ~ - - 
charles.ple...@oist.jp
Okinawa  Institute  of  Science  and  Technology  Graduate  University
Senior staff scientist ~~ Luscombe Unit ~~ https://groups.oist.jp/grsu
Toots from work - ~~  ~~ - https://fediscience.org/@charles_plessy

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel




[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


---
Marcel Ramos
Bioconductor Core Team
Roswell Park Comprehensive Cancer Center
Dept. of Biostatistics & Bioinformatics
Elm St. & Carlton St.
Buffalo, New York 14263


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] help with revdep_check

[Gábor Csárdi]

Seems like you are on macOS. You need to install XCode or the Command
Line Tools to be able to compile packages with C/C++/Fortran code.

Gabor

On Mon, Sep 25, 2023 at 7:02 PM William Revelle  wrote:
>
> Dear friends,
> I am trying to release a new update to psych and psychTools and am having 
> problems with revdep_check
>
> The error message from revdep_check is less than helpful:’
>
> fn is
>
> fn  <-  "/Users/WR/Library/CloudStorage/Dropbox/psychTools/"
>
> revdep_check(fn,num_workers=8)
> ── CHECK 
> ──
>  15 packages ──
> [0/15] 00:00:15 | ETA:  ?s | (8) afex [I], bootnet [I], modnets [I], psych 
> [I], alphaci [D], C...Error: Could not find tools necessary to compile a 
> package
> Call `pkgbuild::check_build_tools(debug = TRUE)` to diagnose the problem.
> > check_build_tools(debug=TRUE)
> Trying to compile a simple C file
> Error: Could not find tools necessary to compile a package
> Call `pkgbuild::check_build_tools(debug = TRUE)` to diagnose the problem.
> rror: Could not find tools necessary to compile a package
>
> Any suggestions would be appreciated.
>
> William Revellepersonality-project.org/revelle.html
> Professor  personality-project.org
> Department of Psychology www.wcas.northwestern.edu/psych/
> Northwestern Universitywww.northwestern.edu/
> Use R for psychology personality-project.org/r
> It is 90 seconds to midnight   www.thebulletin.org
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [Rd] Recent changes to as.complex(NA_real_)

[Hervé Pagès]

On 9/25/23 07:05, Martin Maechler wrote:
>> Hervé Pagès
>>  on Sat, 23 Sep 2023 16:52:21 -0700 writes:
>  > Hi Martin,
>  > On 9/23/23 06:43, Martin Maechler wrote:
>  >>> Hervé Pagès
>  >>> on Fri, 22 Sep 2023 16:55:05 -0700 writes:
>  >> > The problem is that you have things that are
>  >> > **semantically** different but look exactly the same:
>  >>
>  >> > They look the same:
>  >>
>  >> >> x
>  >> > [1] NA
>  >> >> y
>  >> > [1] NA
>  >> >> z
>  >> > [1] NA
>  >>
>  >> >> is.na(x)
>  >> > [1] TRUE
>  >> >> is.na(y)
>  >> > [1] TRUE
>  >> >> is.na(z)
>  >> > [1] TRUE
>  >>
>  >> >> str(x)
>  >> >   cplx NA
>  >> >> str(y)
>  >> >   num NA
>  >> >> str(z)
>  >> >   cplx NA
>  >>
>  >> > but they are semantically different e.g.
>  >>
>  >> >> Re(x)
>  >> > [1] NA
>  >> >> Re(y)
>  >> > [1] -0.5  # surprise!
>  >>
>  >> >> Im(x)  # surprise!
>  >> > [1] 2
>  >> >> Im(z)
>  >> > [1] NA
>  >>
>  >> > so any expression involving Re() or Im() will produce
>  >> > different results on input that look the same on the
>  >> > surface.
>  >>
>  >> > You can address this either by normalizing the internal
>  >> > representation of complex NA to always be complex(r=NaN,
>  >> > i=NA_real_), like for NA_complex_, or by allowing the
>  >> > infinite variations that are currently allowed and at the
>  >> > same time making sure that both Re() and Im()  always
>  >> > return NA_real_ on a complex NA.
>  >>
>  >> > My point is that the behavior of complex NA should be
>  >> > predictable. Right now it's not. Once it's predictable
>  >> > (with Re() and Im() both returning NA_real_ regardless of
>  >> > internal representation), then it no longer matters what
>  >> > kind of complex NA is returned by as.complex(NA_real_),
>  >> > because they are no onger distinguishable.
>  >>
>  >> > H.
>  >>
>  >> > On 9/22/23 13:43, Duncan Murdoch wrote:
>  >> >> Since the result of is.na(x) is the same on each of
>  >> >> those, I don't see a problem.  As long as that is
>  >> >> consistent, I don't see a problem. You shouldn't be using
>  >> >> any other test for NA-ness.  You should never be
>  >> >> expecting identical() to treat different types as the
>  >> >> same (e.g.  identical(NA, NA_real_) is FALSE, as it
>  >> >> should be).  If you are using a different test, that's
>  >> >> user error.
>  >> >>
>  >> >> Duncan Murdoch
>  >> >>
>  >> >> On 22/09/2023 2:41 p.m., Hervé Pagès wrote:
>  >> >>> We could also question the value of having an infinite
>  >> >>> number of NA representations in the complex space. For
>  >> >>> example all these complex values are displayed the same
>  >> >>> way (as NA), are considered NAs by is.na(), but are not
>  >> >>> identical or semantically equivalent (from an Re() or
>  >> >>> Im() point of view):
>  >> >>>
>  >> >>>       NA_real_ + 0i
>  >> >>>
>  >> >>>       complex(r=NA_real_, i=Inf)
>  >> >>>
>  >> >>>       complex(r=2, i=NA_real_)
>  >> >>>
>  >> >>>       complex(r=NaN, i=NA_real_)
>  >> >>>
>  >> >>> In other words, using a single representation for
>  >> >>> complex NA (i.e.  complex(r=NA_real_, i=NA_real_)) would
>  >> >>> avoid a lot of unnecessary complications and surprises.
>  >> >>>
>  >> >>> Once you do that, whether as.complex(NA_real_) should
>  >> >>> return complex(r=NA_real_, i=0) or complex(r=NA_real_,
>  >> >>> i=NA_real_) becomes a moot point.
>  >> >>>
>  >> >>> Best,
>  >> >>>
>  >> >>> H.
>  >>
>  >> Thank you, Hervé.
>  >> Your proposition is yet another one,
>  >> to declare that all complex NA's should be treated as identical
>  >> (almost/fully?) everywhere.
>  >>
>  >> This would be a possibility, but I think a drastic one.
>  >>
>  >> I think there are too many cases, where I want to keep the
>  >> information of the real part independent of the values of the
>  >> imaginary part (e.g. think of the Riemann hypothesis), and
>  >> typically vice versa.
>  > Use NaN for that, not NA.
>
> Aa..h, *that* is your point.
>
> Well, I was on exactly this line till a few years ago.
>
> However, very *sadly* to me, note howexample(complex)
> nowadays ends :
>
> ##
>   showC <- function(z) noquote(sprintf("(R = %g, I = %g)", Re(z), Im(z)))
>   
>   ## The exact result of this *depends* on the platform, compiler, 
> math-library:
>   (NpNA <- NaN + NA_complex_) ; str(NpNA) # *behaves* as 'cplx NA' ..
>   stopifnot(is.na(NpNA), is.na(NA_complex_), is.na(Re(NA_complex_)), 
> is.na(Im(NA_complex_)))
>   showC(NpNA)# but 

[R-pkg-devel] help with revdep_check

[William Revelle]

Dear friends,
I am trying to release a new update to psych and psychTools and am having 
problems with revdep_check

The error message from revdep_check is less than helpful:’

fn is 

fn  <-  "/Users/WR/Library/CloudStorage/Dropbox/psychTools/"

revdep_check(fn,num_workers=8)
── CHECK 
── 
15 packages ──
[0/15] 00:00:15 | ETA:  ?s | (8) afex [I], bootnet [I], modnets [I], psych [I], 
alphaci [D], C...Error: Could not find tools necessary to compile a package
Call `pkgbuild::check_build_tools(debug = TRUE)` to diagnose the problem.
> check_build_tools(debug=TRUE)
Trying to compile a simple C file
Error: Could not find tools necessary to compile a package
Call `pkgbuild::check_build_tools(debug = TRUE)` to diagnose the problem.
rror: Could not find tools necessary to compile a package

Any suggestions would be appreciated. 

William Revellepersonality-project.org/revelle.html
Professor  personality-project.org
Department of Psychology www.wcas.northwestern.edu/psych/
Northwestern Universitywww.northwestern.edu/
Use R for psychology personality-project.org/r
It is 90 seconds to midnight   www.thebulletin.org


[[alternative HTML version deleted]]

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

[Rd] is.atomic(NULL) will become FALSE

[Martin Maechler]

Some of you may remember posts and/or e-mails about this topic
many months ago..

"Atomic vector" is a very well defined term for somewhat advanced
R users.  E.g., from 'The R Language Manual' (in the development
version; i.e. made from latest R source code):
   https://cran.r-project.org/doc/manuals/r-devel/R-lang.html 

Here
  https://cran.r-project.org/doc/manuals/r-devel/R-lang.html#Vector-objects
says

--
2.1.1 Vectors

Vectors can be thought of as contiguous cells containing
data. Cells are accessed through indexing operations such as
x[5]. More details are given in Indexing.

R has six basic (‘atomic’) vector types: logical, integer, real,
complex, character (in C aka ‘string’) and raw. The modes and
storage modes for the different vector types are listed in the
following table.

typeof  mode  storage.mode

logical logical   logical
integer numeric   integer
double  numeric   double
complex complex   complex
character   character character
raw raw   raw

Single numbers, such as 4.2, and strings, such as "four point
two" are still vectors, of length 1; there are no more basic
types. Vectors with length zero are possible (and useful).

A single element of a character vector is often referred to as a
character string or short string.
--

The "Writing R Extensions" Manual, even considerably more
important notably to package writers, mentions atomic vectors
also, e.g., here (again the 6 "R storage mode"s for "basic"
vectors in the  .C() interface

  
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Interface-functions-_002eC-and-_002eFortran

and then for the more advanced, talking about the C API and
mentioning some of the C-level atomic vector functions, 
first  "for all the atomic vector types" and then notably
IsVectorAtomic() under "some convenience functions"

  
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Some-convenience-functions

Similarly, Hadley Wickham's book,  "Advanced R", has treated the
topic of  "atomic vectors", currently in
  https://adv-r.hadley.nz/vectors-chap.html#atomic-vectors

-

For historical reasons, R being created (~1993 ff) to be mostly S-compatible,
the  is.atomic() function has also been made compatible
which meant that it gave not only  TRUE  for the 6 atomic vector
types but also for NULL.
At the times, much of the S code (and originally quite a bit
more of the R code than now) treated   NULL
to mean "any vector of size 0"  and probably for that reason, it
was used as preliminary / expressive shortcut of  numeric(0),
logical(0), etc, it was convenient if   is.atomic(NULL)  gave TRUE
the same as it did for all numeric(), integer(), logical(),
 atomic vectors.

But many time has passed and we had contemplated for many months
if not several years that we'd try to make  is.atomic()  behave
according to the language definition of an atomic-vector.

For this reason, we plan that next year's release of R will have

  > is.atomic(NULL)
  [1] FALSE

instead of  TRUE  as now and historically.

Some package maintainers have been alerted, some as early as 19
months ago  (Feb. 2022), and others a few hours ago that the
above will happen.

Our current plan means it will happen already within the next
few days *if* you are working with the very latest development
versions of R, often called  "R-devel" (as this mailing list).

This will also mean that package maintainers who check their
packages with R-devel  (Automated CRAN jobs do this on an
almost daily schedule; Bioconductor will do this very soon if
they have not already started, and the same could happen if you
use R Hub, CI tools or docker versions of "R-devel".

In all cases where code starts working differently than
previously you could replace

is.atomic()
by (is.atomic() || is.null())

which will have the R code working equivalently in older and
very new / future versions of R.

Often times however such a change is unnecessary (and even
"wrong" in principle) namely  whenever "you" (or the person who
wrote the code you are working with) really *meant* to check for
atomic vectors which indeed do *not* include NULL.

In other cases, it may be more readable and also better code to
replace code of the form

  if( is.atomic() ) {
  deal with both NULL and truly-atomic cases ...
  deal with both NULL and truly-atomic cases ...
  deal with both NULL and truly-atomic cases ...
  } 

by

  if( is.null() ) {
  deal with NULL case 
  } else if( is.atomic() ) {
  deal with truly-atomic case ...
  deal with truly-atomic case ...
  }
  
Again, such re-writing makes sense and may improve the quality
and even efficiency of your code, already for current versions
of R and will 

Re: [Rd] Recent changes to as.complex(NA_real_)

[Martin Maechler]

> Hervé Pagès 
> on Sat, 23 Sep 2023 16:52:21 -0700 writes:

> Hi Martin,
> On 9/23/23 06:43, Martin Maechler wrote:
>>> Hervé Pagès
>>> on Fri, 22 Sep 2023 16:55:05 -0700 writes:
>> > The problem is that you have things that are
>> > **semantically** different but look exactly the same:
>> 
>> > They look the same:
>> 
>> >> x
>> > [1] NA
>> >> y
>> > [1] NA
>> >> z
>> > [1] NA
>> 
>> >> is.na(x)
>> > [1] TRUE
>> >> is.na(y)
>> > [1] TRUE
>> >> is.na(z)
>> > [1] TRUE
>> 
>> >> str(x)
>> >   cplx NA
>> >> str(y)
>> >   num NA
>> >> str(z)
>> >   cplx NA
>> 
>> > but they are semantically different e.g.
>> 
>> >> Re(x)
>> > [1] NA
>> >> Re(y)
>> > [1] -0.5  # surprise!
>> 
>> >> Im(x)  # surprise!
>> > [1] 2
>> >> Im(z)
>> > [1] NA
>> 
>> > so any expression involving Re() or Im() will produce
>> > different results on input that look the same on the
>> > surface.
>> 
>> > You can address this either by normalizing the internal
>> > representation of complex NA to always be complex(r=NaN,
>> > i=NA_real_), like for NA_complex_, or by allowing the
>> > infinite variations that are currently allowed and at the
>> > same time making sure that both Re() and Im()  always
>> > return NA_real_ on a complex NA.
>> 
>> > My point is that the behavior of complex NA should be
>> > predictable. Right now it's not. Once it's predictable
>> > (with Re() and Im() both returning NA_real_ regardless of
>> > internal representation), then it no longer matters what
>> > kind of complex NA is returned by as.complex(NA_real_),
>> > because they are no onger distinguishable.
>> 
>> > H.
>> 
>> > On 9/22/23 13:43, Duncan Murdoch wrote:
>> >> Since the result of is.na(x) is the same on each of
>> >> those, I don't see a problem.  As long as that is
>> >> consistent, I don't see a problem. You shouldn't be using
>> >> any other test for NA-ness.  You should never be
>> >> expecting identical() to treat different types as the
>> >> same (e.g.  identical(NA, NA_real_) is FALSE, as it
>> >> should be).  If you are using a different test, that's
>> >> user error.
>> >>
>> >> Duncan Murdoch
>> >>
>> >> On 22/09/2023 2:41 p.m., Hervé Pagès wrote:
>> >>> We could also question the value of having an infinite
>> >>> number of NA representations in the complex space. For
>> >>> example all these complex values are displayed the same
>> >>> way (as NA), are considered NAs by is.na(), but are not
>> >>> identical or semantically equivalent (from an Re() or
>> >>> Im() point of view):
>> >>>
>> >>>       NA_real_ + 0i
>> >>>
>> >>>       complex(r=NA_real_, i=Inf)
>> >>>
>> >>>       complex(r=2, i=NA_real_)
>> >>>
>> >>>       complex(r=NaN, i=NA_real_)
>> >>>
>> >>> In other words, using a single representation for
>> >>> complex NA (i.e.  complex(r=NA_real_, i=NA_real_)) would
>> >>> avoid a lot of unnecessary complications and surprises.
>> >>>
>> >>> Once you do that, whether as.complex(NA_real_) should
>> >>> return complex(r=NA_real_, i=0) or complex(r=NA_real_,
>> >>> i=NA_real_) becomes a moot point.
>> >>>
>> >>> Best,
>> >>>
>> >>> H.
>> 
>> Thank you, Hervé.
>> Your proposition is yet another one,
>> to declare that all complex NA's should be treated as identical
>> (almost/fully?) everywhere.
>> 
>> This would be a possibility, but I think a drastic one.
>> 
>> I think there are too many cases, where I want to keep the
>> information of the real part independent of the values of the
>> imaginary part (e.g. think of the Riemann hypothesis), and
>> typically vice versa.
> Use NaN for that, not NA.

Aa..h, *that* is your point.

Well, I was on exactly this line till a few years ago.

However, very *sadly* to me, note howexample(complex)
nowadays ends :

##
 showC <- function(z) noquote(sprintf("(R = %g, I = %g)", Re(z), Im(z)))
 
 ## The exact result of this *depends* on the platform, compiler, math-library:
 (NpNA <- NaN + NA_complex_) ; str(NpNA) # *behaves* as 'cplx NA' ..
 stopifnot(is.na(NpNA), is.na(NA_complex_), is.na(Re(NA_complex_)), 
is.na(Im(NA_complex_)))
 showC(NpNA)# but does not always show '(R = NaN, I = NA)'
 ## and this is not TRUE everywhere:
 identical(NpNA, NA_complex_)
 showC(NA_complex_) # always == (R = NA, I = NA)
##

Unfortunately --- notably by the appearance of the new (M1, M1 pro, M2, ...)
processors, but not only ---
I (and others, but the real experts) have wrongly assumed  that
NA 

Re: [Bioc-devel] magpie package failing unit test

[Daoyu Duan]

Hi Martin and Lori,

Thank you for helping test it! I will check the version of R and packages,
and try to fix it !

Thank you,

Daoyu

On Mon, Sep 25, 2023 at 7:52 AM Kern, Lori 
wrote:

> For What it's worth,  I can also reproduce this locally.  Please make sure
> you are using the correct version of R (4.3.1 Patched) and that all your
> packages are up-to-date with BiocManager::install and BiocManager::valid.
>
> Lori Shepherd - Kern
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Bioc-devel  on behalf of Martin
> Grigorov 
> *Sent:* Monday, September 25, 2023 6:48 AM
> *To:* Daoyu Duan 
> *Cc:* bioc-devel@r-project.org 
> *Subject:* Re: [Bioc-devel] magpie package failing unit test
>
> Dear Daoyu,
>
> I can reproduce the test failure at kunpeng2 build runner!
> I'd be happy to test any suggestions you might have!
>
> Regards,
> Martin
>
> On Fri, Sep 22, 2023 at 6:34 PM Daoyu Duan  wrote:
>
> > Dear Bioconductor team,
> >
> > I have received emails that my package "magpie" is failing the unit test
> > in devel, but I have not made any changes after the last release where
> the
> > unit test passed. I tried to investigate this issue but the unit test
> > passed on my local machines (MacOS and Windows) and was not able to
> > replicate the error. Are there any possible reasons for this to happen?
> > Thank you so much for any suggestions!
> >
> > Best regards,
> >
> > Daoyu
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> >
> https://secure-web.cisco.com/1DI3X5mPa4-97d7g5-ZbYnB2O_J802PlUWd-7TwtVWJo0eoekPmh3Z2eWVFU4OiUqm6e0zlLCK7VasPasuWqmlduH4CJUCWvAVno4LCg9id8Gl0Lo02HiFpa2V7177JcUn1U8rcOChMNCvJTB6SRQmIDLW1WDc4S_U6yHOJsTYJRcNve_9T7wO-dGiwHWzHGoGQ1QCa6tohNz50fLfMBtTV_CDVREd7ZyA2vyvXF8akaJQ0vEJejG8jU9E3G2ddJw9SfklwH5CdXCFtV94QskDigycBCL-c4oe_Sym7a9Pwe7JKvH-xZ4x-a1Y3envuAA/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/1DI3X5mPa4-97d7g5-ZbYnB2O_J802PlUWd-7TwtVWJo0eoekPmh3Z2eWVFU4OiUqm6e0zlLCK7VasPasuWqmlduH4CJUCWvAVno4LCg9id8Gl0Lo02HiFpa2V7177JcUn1U8rcOChMNCvJTB6SRQmIDLW1WDc4S_U6yHOJsTYJRcNve_9T7wO-dGiwHWzHGoGQ1QCa6tohNz50fLfMBtTV_CDVREd7ZyA2vyvXF8akaJQ0vEJejG8jU9E3G2ddJw9SfklwH5CdXCFtV94QskDigycBCL-c4oe_Sym7a9Pwe7JKvH-xZ4x-a1Y3envuAA/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
>
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Lost access to my email

[Kern, Lori via Bioc-devel]

I will be in touch off list about resetting your BiocCredentials account so you 
can manage your ssh keys for access to the packages.


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Kern, Lori 
Sent: Monday, September 25, 2023 8:02 AM
To: Stefan Graw ; bioc-devel@r-project.org 

Subject: Re: [Bioc-devel] Lost access to my email

Just to confirm you no longer have access to shg...@uams.edu?


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Stefan Graw 

Sent: Sunday, September 24, 2023 3:07 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Lost access to my email

Dear Bioconductor team,

During grad school, I submitted the package pwrEWAS to Bioconductor (
https://secure-web.cisco.com/1a1P0Sfg0V2lZ3iwLEUb14u_G5COUw7XFJgjGy1NLY5UKpBIqIUBKzk8wnn2I3cLRmXbPRfwc0EK0G4XzXMwhgH73O3P613m8rJuRl4MdiEIztjNSjdmbL9BsC-58b0NYj3y54gQndz_SNhM7vE6_sGri9C-b78cPU0Z61rNhg-Hnh3wmpCG_m7RSes-vNCTV1uEIUh0Xf8AQaiDVmbu1spL2sr0bGugw9ff_y7VJK3MDyug_Le_owApKQiFYIH3eVwyhUzBKHzPRgkvyPzAvNBXYPm41mnX6jH_gqGiQeikSUom0VG5cj1A-u6aHQpah/https%3A%2F%2Fbioconductor.org%2Fpackages%2Frelease%2Fbioc%2Fhtml%2FpwrEWAS.html).
 However,
I don't have access to the email account (shg...@uams.edu) associated with
the packages anymore, and I was made aware by my former mentor that there
are some updates required.

Is there a way for me to change my email associated with the package? I am
currently unable to login.

Thank you,
Stefan Graw

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1ON08ywcC13rESsP050UVnxtJlzZl4DtZtxG_NPiHYjMb3JOXIlilrUiLRbDSBYdzTpj2qGbom9PCJvsXHSxMy-qNH0qwgRuzIqNQw6XVg1hg_OQDUkSRYBoEsqGMqsvYpuzMVP2oPFsCrl4bag9Kb_PG3lRYNay4l4-M7IpXmQKN4LRi5DgYhUlcisCXZnXaMFX75_TSr4bLiLCy_vGRblUhhpsvVybz4NfwgpBByTfSzUh4bQ9eHAJvqGjNNHIV5WvNEFwqKCb0CogSzP3QRVga4l0xBstL6q5n38caPPqCfLCuqmNbo5mvV43F8q5c/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Lost access to my email

[Kern, Lori via Bioc-devel]

Just to confirm you no longer have access to shg...@uams.edu?


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Stefan Graw 

Sent: Sunday, September 24, 2023 3:07 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Lost access to my email

Dear Bioconductor team,

During grad school, I submitted the package pwrEWAS to Bioconductor (
https://secure-web.cisco.com/1a1P0Sfg0V2lZ3iwLEUb14u_G5COUw7XFJgjGy1NLY5UKpBIqIUBKzk8wnn2I3cLRmXbPRfwc0EK0G4XzXMwhgH73O3P613m8rJuRl4MdiEIztjNSjdmbL9BsC-58b0NYj3y54gQndz_SNhM7vE6_sGri9C-b78cPU0Z61rNhg-Hnh3wmpCG_m7RSes-vNCTV1uEIUh0Xf8AQaiDVmbu1spL2sr0bGugw9ff_y7VJK3MDyug_Le_owApKQiFYIH3eVwyhUzBKHzPRgkvyPzAvNBXYPm41mnX6jH_gqGiQeikSUom0VG5cj1A-u6aHQpah/https%3A%2F%2Fbioconductor.org%2Fpackages%2Frelease%2Fbioc%2Fhtml%2FpwrEWAS.html).
 However,
I don't have access to the email account (shg...@uams.edu) associated with
the packages anymore, and I was made aware by my former mentor that there
are some updates required.

Is there a way for me to change my email associated with the package? I am
currently unable to login.

Thank you,
Stefan Graw

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1ON08ywcC13rESsP050UVnxtJlzZl4DtZtxG_NPiHYjMb3JOXIlilrUiLRbDSBYdzTpj2qGbom9PCJvsXHSxMy-qNH0qwgRuzIqNQw6XVg1hg_OQDUkSRYBoEsqGMqsvYpuzMVP2oPFsCrl4bag9Kb_PG3lRYNay4l4-M7IpXmQKN4LRi5DgYhUlcisCXZnXaMFX75_TSr4bLiLCy_vGRblUhhpsvVybz4NfwgpBByTfSzUh4bQ9eHAJvqGjNNHIV5WvNEFwqKCb0CogSzP3QRVga4l0xBstL6q5n38caPPqCfLCuqmNbo5mvV43F8q5c/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] magpie package failing unit test

[Kern, Lori via Bioc-devel]

For What it's worth,  I can also reproduce this locally.  Please make sure you 
are using the correct version of R (4.3.1 Patched) and that all your packages 
are up-to-date with BiocManager::install and BiocManager::valid.


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Martin 
Grigorov 
Sent: Monday, September 25, 2023 6:48 AM
To: Daoyu Duan 
Cc: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] magpie package failing unit test

Dear Daoyu,

I can reproduce the test failure at kunpeng2 build runner!
I'd be happy to test any suggestions you might have!

Regards,
Martin

On Fri, Sep 22, 2023 at 6:34 PM Daoyu Duan  wrote:

> Dear Bioconductor team,
>
> I have received emails that my package "magpie" is failing the unit test
> in devel, but I have not made any changes after the last release where the
> unit test passed. I tried to investigate this issue but the unit test
> passed on my local machines (MacOS and Windows) and was not able to
> replicate the error. Are there any possible reasons for this to happen?
> Thank you so much for any suggestions!
>
> Best regards,
>
> Daoyu
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://secure-web.cisco.com/1DI3X5mPa4-97d7g5-ZbYnB2O_J802PlUWd-7TwtVWJo0eoekPmh3Z2eWVFU4OiUqm6e0zlLCK7VasPasuWqmlduH4CJUCWvAVno4LCg9id8Gl0Lo02HiFpa2V7177JcUn1U8rcOChMNCvJTB6SRQmIDLW1WDc4S_U6yHOJsTYJRcNve_9T7wO-dGiwHWzHGoGQ1QCa6tohNz50fLfMBtTV_CDVREd7ZyA2vyvXF8akaJQ0vEJejG8jU9E3G2ddJw9SfklwH5CdXCFtV94QskDigycBCL-c4oe_Sym7a9Pwe7JKvH-xZ4x-a1Y3envuAA/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1DI3X5mPa4-97d7g5-ZbYnB2O_J802PlUWd-7TwtVWJo0eoekPmh3Z2eWVFU4OiUqm6e0zlLCK7VasPasuWqmlduH4CJUCWvAVno4LCg9id8Gl0Lo02HiFpa2V7177JcUn1U8rcOChMNCvJTB6SRQmIDLW1WDc4S_U6yHOJsTYJRcNve_9T7wO-dGiwHWzHGoGQ1QCa6tohNz50fLfMBtTV_CDVREd7ZyA2vyvXF8akaJQ0vEJejG8jU9E3G2ddJw9SfklwH5CdXCFtV94QskDigycBCL-c4oe_Sym7a9Pwe7JKvH-xZ4x-a1Y3envuAA/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Lost access to my email

[Stefan Graw]

Dear Bioconductor team,

During grad school, I submitted the package pwrEWAS to Bioconductor (
https://bioconductor.org/packages/release/bioc/html/pwrEWAS.html). However,
I don't have access to the email account (shg...@uams.edu) associated with
the packages anymore, and I was made aware by my former mentor that there
are some updates required.

Is there a way for me to change my email associated with the package? I am
currently unable to login.

Thank you,
Stefan Graw

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] magpie package failing unit test

[Martin Grigorov]

Dear Daoyu,

I can reproduce the test failure at kunpeng2 build runner!
I'd be happy to test any suggestions you might have!

Regards,
Martin

On Fri, Sep 22, 2023 at 6:34 PM Daoyu Duan  wrote:

> Dear Bioconductor team,
>
> I have received emails that my package "magpie" is failing the unit test
> in devel, but I have not made any changes after the last release where the
> unit test passed. I tried to investigate this issue but the unit test
> passed on my local machines (MacOS and Windows) and was not able to
> replicate the error. Are there any possible reasons for this to happen?
> Thank you so much for any suggestions!
>
> Best regards,
>
> Daoyu
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] NROW and NCOL on NULL

[Martin Maechler]

> Simone Giannerini 
> on Sun, 24 Sep 2023 16:57:00 +0200 writes:

> Thank you for your comment, On Sat, Sep 23, 2023 at
> 9:51 PM Ben Bolker  wrote:
>> 
>> This is certainly worth discussing, but there's always a
>> heavy burden of back-compatibility; how much better would
>> it be for NCOL and NROW to both return zero, vs. the
>> amount of old code that would be broken?

> I do not have an answer to this question but it seems to
> me that code that relies upon NCOL(NULL) being 1 is not
> extremely good (and portable).

Well, it remains *very* portable,  as long as we keep the behavior.
It has worked as it does for more than twenty years, and if you
finally remain convinced that we won't change, it will remain portable
between all versions of R from the very old past to the remote
future  ... ;-)

Martin


>> Furthermore, the reason for this behaviour is justified
>> as consistency with the behaviour of as.matrix() and
>> cbind() for zero-length vectors, from ?NCOL:
>> 
>> ## as.matrix() produces 1-column matrices from 0-length
>> vectors, ## and so does cbind() :
>> 
>> (of course you could argue that this behaviour should be
>> changed as well ...)
>> 
>> 

> Yes, it is documented and somehow clashes with the more
> intuitive behaviour of subsetting matrices

>> a <- matrix(1:4,2,2) a
>  [,1] [,2] [1,] 1 3 [2,] 2 4
>> a2 <- a[,-(1:2)] a2

> [1,] [2,]
>> dim(a2)
> [1] 2 0

> NULL is often used to declare an undefined value for the
> argument of a function. If such an argument is potentially
> a matrix, then using NULL as the default requires
> additional code to check for the number of columns and use
> it in the code.  The same holds to a lesser extent for
> functions that are expected to return a matrix and return
> NULL instead.

> Kind regards,

> Simone

>> On 2023-09-23 3:41 p.m., Simone Giannerini wrote: > I
>> know it's documented and I know there are other ways to
>> guard > against this behaviour, once you know about this.
>> > The point is whether it might be worth it to make NCOL
>> and NROW return > the same value on NULL and make R more
>> consistent/intuitive and > possibly less error prone.
>> >
>> > Regards,
>> >
>> > Simone
>> >
>> > On Sat, Sep 23, 2023 at 7:50 PM Duncan Murdoch
>>  wrote:
>> >>
>> >> It's been documented for a long time that NCOL(NULL)
>> is 1.  What >> particular problems did you have in mind?
>> There might be other ways to >> guard against them.
>> >>
>> >> Duncan Murdoch
>> >>
>> >> On 23/09/2023 1:43 p.m., Simone Giannerini wrote: >>>
>> Dear list,
>> >>>
>> >>> I do not know what would be the 'correct' answer to
>> the following but >>> I think that they should return the
>> same value to avoid potential >>> problems and hard to
>> debug errors.
>> >>>
>> >>> Regards,
>> >>>
>> >>> Simone
>> >>> ---
>> >>>
>>  NCOL(NULL) >>> [1] 1
>> >>>
>>  NROW(NULL) >>> [1] 0
>> >>>
>>  sessionInfo() >>> R version 4.3.1 RC (2023-06-08
>> r84523 ucrt) >>> Platform: x86_64-w64-mingw32/x64
>> (64-bit) >>> Running under: Windows 11 x64 (build 22621)
>> >>>
>> >>> Matrix products: default
>> >>>
>> >>>
>> >>> locale: >>> [1] LC_COLLATE=Italian_Italy.utf8
>> LC_CTYPE=Italian_Italy.utf8 >>> [3]
>> LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C >>> [5]
>> LC_TIME=Italian_Italy.utf8
>> >>>
>> >>> time zone: Europe/Rome >>> tzcode source: internal
>> >>>
>> >>> attached base packages: >>> [1] stats graphics
>> grDevices utils datasets methods base
>> >>>
>> >>> loaded via a namespace (and not attached): >>> [1]
>> compiler_4.3.1
>> >>>
>> >>
>> >
>> >
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel



> -- 
> ___

> Simone Giannerini Dipartimento di Scienze Statistiche
> "Paolo Fortunati" Universita' di Bologna Via delle belle
> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax:
> +39 051 232153 https://simonegiannerini.net/

> __
> 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] R_orderVector1 - algo: radix, shell, or another?

[Ivan Krylov]

В Sun, 24 Sep 2023 10:38:41 +0200
Jan Gorecki  пишет:

> https://github.com/wch/r-source/blob/ed51d34ec195b89462a8531b9ef30b7b72e47204/src/main/sort.c#L1133

> could anyone describe which one R_orderVector1 uses,

The body of the sorting algorithm is defined in the sort2_with_index
macro. This is shell sort. (I don't actually recognise sorting
algorithms on sight, but the "sincs" array gave it away:
.)

> and if there is easy API to use different ones from C?

No easy ones, I think. You could construct a call to order(..., method
= 'radix') from R or bundle a sort implementation of your own.

These are all undocumented implementation details. They could change in
a new version of R (although quite a lot of it hasn't changed in 11-22
years). Why are you looking for specific sorting algorithms? Could
there be a better way to solve your problem?

-- 
Best regards,
Ivan

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