Re: [Bioc-devel] "scry" build report error

2023-09-28 Thread Jennifer Wokaty
We removed resource EH1524 from the cache so it could be redownloaded. scry's 
report does not show errors today: 
https://bioconductor.org/checkResults/devel/bioc-LATEST/scry/.

Jennifer Wokaty (they/them)

Waldron Lab at CUNY SPH
Bioconductor Core Team

From: Bioc-devel  on behalf of Kelly Street 

Sent: Tuesday, September 26, 2023 6:38 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] "scry" build report error

* This email originates from a sender outside of CUNY. Verify the sender before 
replying or clicking on links and attachments. *

Hello all,

We are getting a strange error in the recent build report
 for our
package "scry" and I am wondering if anyone has encountered this issue
before. In the vignette, we use a dataset from the DuoClustering2018
package, which does not seem to have any issues, itself. However, on
palomino4, we get this error:

Error: processing vignette 'scry.Rmd' failed with diagnostics:
failed to load resource
  name: EH1524
  title: sce_full_Zhengmix4eq
  reason: unknown input format

Will Townes and I have been unable to reproduce this error locally (both on
Macs), so I'm wondering if anyone knows how we might diagnose this problem?

Thanks,
Kelly

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel__%3B!!PxiZbSOawA!ODjhdQq9byQk5g8hrf2t2PvaVrxRgb22w8weWOe9X-Pv37m5tDdBPtVvfBU7K4HYOTOcyrD83M1PxhpqXYlAvyHVs6i_WdoX%24=05%7C01%7Cjennifer.wokaty%40sph.cuny.edu%7Cbeea2b9769d5417e966608dbbee183b0%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638313648038042589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=nNSeM2tEA07WAFSKf5RGUueIPDegncuLP%2BKgf5X%2Bz2E%3D=0

[[alternative HTML version deleted]]

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


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

2023-09-28 Thread Martin Maechler
> Martin Maechler 
> on Thu, 28 Sep 2023 12:11:27 +0200 writes:

> Gregory R Warnes 
> on Sat, 23 Sep 2023 13:22:35 -0400 writes:

> > It sounds like we need to add arguments (with sensible
> > defaults) to complex(), Re(), Im(), is.na.complex() etc to
> > allow the user to specify the desired behavior.
> 
> I don't think I'd like such extra flexibility for all these, 
> ... ;-)  and even much less I'd like to be part of the group who
> then has to *maintain* such behavior ;-)
> 
[..]

> Currently, I'm actually tending to *simplify* things
> drastically, also because it means less surprises in the long
> term and much less code reading / debugging in formatting /
> printing and dealing with complex numbers.
> NB: there *is* the re-opened PR#16752,
> https://bugs.r-project.org/show_bug.cgi?id=16752
> where the investigation of the (C-level) R source is a major reason
> for my current thinking ..
> 
> What if we decided to really treat complex numbers much more
> than currently  as pairs of real (i.e. "double") numbers,
> notably also when print()ing them?
> Consequently, Re() and Im() would continue to return what they
> do now (contrary to Hervé's original proposal) also in case of
> non-finite numbers.
> 
> Of course, *no* change in arithmetic or other Ops (such as '==')
> nor  is.na(), is.finite(), is.nan(), etc.
> 
> The current formatting and printing of complex numbers is
> complicated in some cases unnecessarily inaccurate and in other
> cases unnecessarily *ugly*.
> I believe that formatting, we should change to basically format
> the (vector of) real parts and imaginary parts separately.
> E.g., it is really unnecessarily ugly to switch to exponential
> format for both Re and Im, in a situation like this:
> 
> > (-1):2 + 1i*1e99
> [1] 0e+00+1e+99i 0e+00+1e+99i 0e+00+1e+99i 0e+00+1e+99i
> 
> It is very ugly to use  exponential/scientific format for the Re()
> even if we'd fix the confusing and inaccurate *joint* rounding
> of Re and Im.

and then, I end with

> ... and indeed (as discusses here previously:
> While it makes some sense to print  NA
> identically for logical, integer and double,
> it seems often confusing *not* to show   + i
> in the complex case; where that *does* happen for
> Inf and NaN:
> 
>  > complex(, NA, ((-1):2))
>  [1] NA NA NA NA
>  > complex(, NaN, ((-1):2))
>  [1] NaN-1i NaN+0i NaN+1i NaN+2i
>  > complex(, c(-Inf,Inf), ((-1):2))
>  [1] -Inf-1i  Inf+0i -Inf+1i  Inf+2i
>  > 
> 
> where the first of these *does* keep the finite imaginary
> values, but does not show them
> 
> > (cN <- complex(, NA, ((-1):2))); rbind(Re(cN), Im(cN))
> [1] NA NA NA NA
>  [,1] [,2] [,3] [,4]
> [1,]   NA   NA   NA   NA
> [2,]   -1012
> >

where really, I think we should keep that behavior (*), at least
for now: Changing it as well *does* have a relatively large
impact, is not back-compatible with (the long history of) S and
R, *and* it complicates documentation and teaching unnecessarily.

Experts will now how to differentiate the different complex NAs,
e.g. by using a simple utilities such as {"format complex", "print complex"}

  fc <- function(z) paste0("(",Re(z), ",", Im(z),")")
  pc <- function(z) noquote(fc(z))

which I've used now for testing/"visualizing" different scenarios


Martin


---
*) simply printing 'NA' in cases where is.na(.) is true and is.nan(.) is false

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


Re: [Bioc-devel] Not receiving original posts for watched tags at bioconductor support

2023-09-28 Thread Alexey Sergushichev
Lori, thanks! Didn't think about searching on github to check whether this
issue was already reported. Hope it will get resolved.

--
Alexey

On Thu, Sep 28, 2023 at 6:16 AM Kern, Lori 
wrote:

> There was some issue posted here:
> https://github.com/Bioconductor/support.bioconductor.org/issues/78
>
> We are aware of the issue of not being emailed on the first post and are
> actively looking into a fix for it.
>
> Thank you for letting us know.
>
>
> 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 Lluís
> Revilla 
> *Sent:* Wednesday, September 27, 2023 7:39 PM
> *To:* Alexey Sergushichev 
> *Cc:* bioc-devel 
> *Subject:* Re: [Bioc-devel] Not receiving original posts for watched tags
> at bioconductor support
>
> Hi,
>
> While checking this, I realized that
>
> https://secure-web.cisco.com/18IGkeFBtjVa4TYb0Y9OwgM6Bjyw38MHFoitbHayY7UWvGkolpQU6FqGFF6bQMV1qKGNHz9T7Coi1Acxo5UdxtGlPmPdmwBcXMpUK7ykbFcxFSzmWshFATVSNDmSygNRH4X5jNyLyydkorn0_LIEtQLpMv1tavlxcMo8TD-DaFVIar6s2Ih3NC2WNcAoM6OnMdlxYKLXC_Vu6TWKbRuIpJt6gMO1HxPpSJJ1amL9lcMK5VFf4AOQMUIdsLQA49DN73LoFBxPudsGLW6Ni7h_kf-vzO5Hho3GcyBGH5neIlmCts-OR_I07bvhjRQL_opPO/https%3A%2F%2Fsupport.bioconductor.org%2Fmytags%2F
> doesn't show the tags I have in my
> profile as "My Tags" and as "Watched Tags".
> Not sure if it is related.
>
> Best,
>
> Lluís
>
> On Thu, 28 Sept 2023 at 01:00, Alexey Sergushichev 
> wrote:
>
> > Hi,
> >
> > I have a problem that I only receive e-mail notifications from
> > support.bioconductor.org for my watched tags (e.g. "fgsea") with the
> > answers and comments but not for the post itself. So I never learn about
> > the unanswered questions unless I go directly to
> >
> https://secure-web.cisco.com/18IGkeFBtjVa4TYb0Y9OwgM6Bjyw38MHFoitbHayY7UWvGkolpQU6FqGFF6bQMV1qKGNHz9T7Coi1Acxo5UdxtGlPmPdmwBcXMpUK7ykbFcxFSzmWshFATVSNDmSygNRH4X5jNyLyydkorn0_LIEtQLpMv1tavlxcMo8TD-DaFVIar6s2Ih3NC2WNcAoM6OnMdlxYKLXC_Vu6TWKbRuIpJt6gMO1HxPpSJJ1amL9lcMK5VFf4AOQMUIdsLQA49DN73LoFBxPudsGLW6Ni7h_kf-vzO5Hho3GcyBGH5neIlmCts-OR_I07bvhjRQL_opPO/https%3A%2F%2Fsupport.bioconductor.org%2Fmytags%2F
> Does anyone else have this
> > problem?
> >
> > Best,
> > Alexey
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> >
> https://secure-web.cisco.com/1Ap-RD8a1iVYfTbCfhr5SB0o5Fx5eyJN1VRSdkRZATqxLOZlkkQ7FJF6LUj-mRFiuv3xjcSkMD2kg_EPjyHmjBKJ0A3hjNkFPpOnTy16Up5QdY0VgDmnbagv1Tuxb45C6B3eqMnpYh0lsNeyxc34e8Ia9ODKzNVLXw11me8LfLjH-4mOYx0Iu6TFXIQ3YbBsrUwwZLpg34_v8hTUp413AFODzt45l6wf0J-myabLsLoXs_uV1Hp_-mS5vxR2w4u4qcJ8jyZoNOVSP78VPCkEo7oyJ6WRI9CePNpAb320hAlAQX50mCN46BBa6CH7LwFaZ/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/1Ap-RD8a1iVYfTbCfhr5SB0o5Fx5eyJN1VRSdkRZATqxLOZlkkQ7FJF6LUj-mRFiuv3xjcSkMD2kg_EPjyHmjBKJ0A3hjNkFPpOnTy16Up5QdY0VgDmnbagv1Tuxb45C6B3eqMnpYh0lsNeyxc34e8Ia9ODKzNVLXw11me8LfLjH-4mOYx0Iu6TFXIQ3YbBsrUwwZLpg34_v8hTUp413AFODzt45l6wf0J-myabLsLoXs_uV1Hp_-mS5vxR2w4u4qcJ8jyZoNOVSP78VPCkEo7oyJ6WRI9CePNpAb320hAlAQX50mCN46BBa6CH7LwFaZ/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] Not receiving original posts for watched tags at bioconductor support

2023-09-28 Thread Kern, Lori via Bioc-devel
There was some issue posted here:
https://github.com/Bioconductor/support.bioconductor.org/issues/78

We are aware of the issue of not being emailed on the first post and are 
actively looking into a fix for it.

Thank you for letting us know.



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 Llu�s Revilla 

Sent: Wednesday, September 27, 2023 7:39 PM
To: Alexey Sergushichev 
Cc: bioc-devel 
Subject: Re: [Bioc-devel] Not receiving original posts for watched tags at 
bioconductor support

Hi,

While checking this, I realized that
https://secure-web.cisco.com/18IGkeFBtjVa4TYb0Y9OwgM6Bjyw38MHFoitbHayY7UWvGkolpQU6FqGFF6bQMV1qKGNHz9T7Coi1Acxo5UdxtGlPmPdmwBcXMpUK7ykbFcxFSzmWshFATVSNDmSygNRH4X5jNyLyydkorn0_LIEtQLpMv1tavlxcMo8TD-DaFVIar6s2Ih3NC2WNcAoM6OnMdlxYKLXC_Vu6TWKbRuIpJt6gMO1HxPpSJJ1amL9lcMK5VFf4AOQMUIdsLQA49DN73LoFBxPudsGLW6Ni7h_kf-vzO5Hho3GcyBGH5neIlmCts-OR_I07bvhjRQL_opPO/https%3A%2F%2Fsupport.bioconductor.org%2Fmytags%2F
 doesn't show the tags I have in my
profile as "My Tags" and as "Watched Tags".
Not sure if it is related.

Best,

Llu�s

On Thu, 28 Sept 2023 at 01:00, Alexey Sergushichev 
wrote:

> Hi,
>
> I have a problem that I only receive e-mail notifications from
> support.bioconductor.org for my watched tags (e.g. "fgsea") with the
> answers and comments but not for the post itself. So I never learn about
> the unanswered questions unless I go directly to
> https://secure-web.cisco.com/18IGkeFBtjVa4TYb0Y9OwgM6Bjyw38MHFoitbHayY7UWvGkolpQU6FqGFF6bQMV1qKGNHz9T7Coi1Acxo5UdxtGlPmPdmwBcXMpUK7ykbFcxFSzmWshFATVSNDmSygNRH4X5jNyLyydkorn0_LIEtQLpMv1tavlxcMo8TD-DaFVIar6s2Ih3NC2WNcAoM6OnMdlxYKLXC_Vu6TWKbRuIpJt6gMO1HxPpSJJ1amL9lcMK5VFf4AOQMUIdsLQA49DN73LoFBxPudsGLW6Ni7h_kf-vzO5Hho3GcyBGH5neIlmCts-OR_I07bvhjRQL_opPO/https%3A%2F%2Fsupport.bioconductor.org%2Fmytags%2F
>  Does anyone else have this
> problem?
>
> Best,
> Alexey
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://secure-web.cisco.com/1Ap-RD8a1iVYfTbCfhr5SB0o5Fx5eyJN1VRSdkRZATqxLOZlkkQ7FJF6LUj-mRFiuv3xjcSkMD2kg_EPjyHmjBKJ0A3hjNkFPpOnTy16Up5QdY0VgDmnbagv1Tuxb45C6B3eqMnpYh0lsNeyxc34e8Ia9ODKzNVLXw11me8LfLjH-4mOYx0Iu6TFXIQ3YbBsrUwwZLpg34_v8hTUp413AFODzt45l6wf0J-myabLsLoXs_uV1Hp_-mS5vxR2w4u4qcJ8jyZoNOVSP78VPCkEo7oyJ6WRI9CePNpAb320hAlAQX50mCN46BBa6CH7LwFaZ/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/1Ap-RD8a1iVYfTbCfhr5SB0o5Fx5eyJN1VRSdkRZATqxLOZlkkQ7FJF6LUj-mRFiuv3xjcSkMD2kg_EPjyHmjBKJ0A3hjNkFPpOnTy16Up5QdY0VgDmnbagv1Tuxb45C6B3eqMnpYh0lsNeyxc34e8Ia9ODKzNVLXw11me8LfLjH-4mOYx0Iu6TFXIQ3YbBsrUwwZLpg34_v8hTUp413AFODzt45l6wf0J-myabLsLoXs_uV1Hp_-mS5vxR2w4u4qcJ8jyZoNOVSP78VPCkEo7oyJ6WRI9CePNpAb320hAlAQX50mCN46BBa6CH7LwFaZ/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: [Rd] Recent changes to as.complex(NA_real_)

2023-09-28 Thread Martin Maechler
> Gregory R Warnes 
> on Sat, 23 Sep 2023 13:22:35 -0400 writes:

> It sounds like we need to add arguments (with sensible
> defaults) to complex(), Re(), Im(), is.na.complex() etc to
> allow the user to specify the desired behavior.

I don't think I'd like such extra flexibility for all these, 
... ;-)  and even much less I'd like to be part of the group who
then has to *maintain* such behavior ;-)

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

 ( .. *some* hybris from the last century ..)

Currently, I'm actually tending to *simplify* things
drastically, also because it means less surprises in the long
term and much less code reading / debugging in formatting /
printing and dealing with complex numbers.
NB: there *is* the re-opened PR#16752,
https://bugs.r-project.org/show_bug.cgi?id=16752
where the investigation of the (C-level) R source is a major reason
for my current thinking ..

What if we decided to really treat complex numbers much more
than currently  as pairs of real (i.e. "double") numbers,
notably also when print()ing them?
Consequently, Re() and Im() would continue to return what they
do now (contrary to Hervé's original proposal) also in case of
non-finite numbers.

Of course, *no* change in arithmetic or other Ops (such as '==')
nor  is.na(), is.finite(), is.nan(), etc.

The current formatting and printing of complex numbers is
complicated in some cases unnecessarily inaccurate and in other
cases unnecessarily *ugly*.
I believe that formatting, we should change to basically format
the (vector of) real parts and imaginary parts separately.
E.g., it is really unnecessarily ugly to switch to exponential
format for both Re and Im, in a situation like this:

> (-1):2 + 1i*1e99
[1] 0e+00+1e+99i 0e+00+1e+99i 0e+00+1e+99i 0e+00+1e+99i

It is very ugly to use  exponential/scientific format for the Re()
even if we'd fix the confusing and inaccurate *joint* rounding
of Re and Im.

... and indeed (as discusses here previously:
While it makes some sense to print  NA
identically for logical, integer and double,
it seems often confusing *not* to show   + i
in the complex case; where that *does* happen for
Inf and NaN:

 > complex(, NA, ((-1):2))
 [1] NA NA NA NA
 > complex(, NaN, ((-1):2))
 [1] NaN-1i NaN+0i NaN+1i NaN+2i
 > complex(, c(-Inf,Inf), ((-1):2))
 [1] -Inf-1i  Inf+0i -Inf+1i  Inf+2i
 > 

where the first of these *does* keep the finite imaginary
values, but does not show them

> (cN <- complex(, NA, ((-1):2))); rbind(Re(cN), Im(cN))
[1] NA NA NA NA
 [,1] [,2] [,3] [,4]
[1,]   NA   NA   NA   NA
[2,]   -1012
>

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


Re: [Rd] Minor bug with stats::isoreg

2023-09-28 Thread Martin Maechler
> Ivan Krylov 
> on Thu, 28 Sep 2023 00:59:57 +0300 writes:

> В Wed, 27 Sep 2023 13:49:58 -0700 Travers Ching
>  пишет:

>> Calling isoreg with an Inf value causes a segmentation
>> fault, tested on R 4.3.1 and R 4.2. A reproducible
>> example is: `isoreg(c(0,Inf))`

> Indeed, the code in src/library/stats/src/isoreg.c
> contains the following loop:

> do {
>   slope = R_PosInf;
>   for (i = known + 1; i <= n; i++) {
>   tmp = (REAL(yc)[i] - REAL(yc)[known]) / (i - known);
> // if `tmp` becomes +Inf or NaN...
> // or both `tmp` and `slope` become -Inf...
>   if (tmp < slope) { // <-- then this is false
>   slope = tmp;
>   ip = i; // <-- so this assignment never happens
>   }
>   }/* tmp := max{i= kn+1,.., n} slope(p[kn] -> p[i])  and
> *  ip = argmax{...}... */
>   INTEGER(iKnots)[n_ip++] = ip; // <-- heap overflow and crash // ...
> } while ((known = ip) < n); // <-- this loop never terminates

> I'm not quite sure how to fix this. Checking for tmp <= slope would
> have been a one-character patch, but it changes the reference outputs
> and doesn't handle isnan(tmp), so it's probably not correct. The
> INTEGER(iKnots)[n_ip++] = ip; assignment should only be reached in case
> of knots, but since the `ip` index never progresses past the
> +/-infinity, the knot condition is triggered repeatedly.

> Least squares methods don't handle infinities well anyway, so maybe
> it's best to put the check in the R function instead:

> --- src/library/stats/R/isoreg.R  (revision 85226)
> +++ src/library/stats/R/isoreg.R  (working copy)
> @@ -22,8 +22,8 @@
>  {
>  xy <- xy.coords(x,y)
>  x <- xy$x
> -if(anyNA(x) || anyNA(xy$y))
> - stop("missing values not allowed")
> +if(!all(is.finite(x)) || !all(is.finite(xy$y)))
> + stop("missing and infinite values not allowed")
>  isOrd <- ((!is.null(xy$xlab) && xy$xlab == "Index")
>|| !is.unsorted(x, strictly = TRUE))
>  if(!isOrd) {

> -- 
> Best regards,
> Ivan


The above would not even be sufficient: 
It's the sum(y) really, because internally
  yc <- cumsum(c(0,y)) and actually  diff(yc)  is used
where you get to  Inf - Inf ==> NaN

> isoreg(c(5, 9, 1:2, 7e308, 5:8, 3, 8)))

 *** caught segfault ***
address 0x7e48000, cause 'memory not mapped'
/u/maechler/bin/R_arg: Zeile 160: 873336 Speicherzugriffsfehler  (Speicherabzug 
geschrieben) $exe $@

Also, the C code still does not work for long vectors,
so I want to change the C code anyway.


In any case:
  Thank you, Travers, Ben, and Ivan, for reporting and addressing
  the issue!


--

There is an interesting point here though:

For dealing with +/- Inf, we used to follow the following idea
in R quite keenly (and sometimes extremely): 

If 'Inf' leads a computation to "fail" (NB:  1/Inf  |-->  0 does *not* fail)
try to see what the mathematical *or* computational limit
 x --> Inf would be.
If that is easily defined, we use that.

So, often as a first step, look at what happens if you replace
Inf by 1e100  (and then also what happens if you are finite but
*close* to Inf, i.e. the 7e308 above).

Now here, at least in some cases, such a limit cases are clearly
detectable, e.g., when you let  y[2] --->  -Inf here

> n <- length(y0 <- c(5, 9, 1:2, 5:8, 3, 8))
> y2s <- c(10:0, -10, -20, -1000, -1e4, -1e10, -1e100, -1e200, -1e300)
> iSet <- vapply(y2s, function(y2) isoreg({y <- y0; y[2] <- y2; y})$yf, 
> numeric(n))
> t(iSet) # *does* change as function of y2 *but* predictably
  [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
 [1,]   4.5000e+00   4.5000e+00 4.50 4.5056666 8
 [2,]   4.2500e+00   4.2500e+00 4.25 4.2556666 8
 [3,]   4.e+00   4.e+00 4.00 4.0056666 8
 [4,]   3.7500e+00   3.7500e+00 3.75 3.7556666 8
 [5,]   3.5000e+00   3.5000e+00 3.50 3.5056666 8
 [6,]   3.2500e+00   3.2500e+00 3.25 3.2556666 8
 [7,]   3.e+00   3.e+00 3.00 3.0056666 8
 [8,]   2.7500e+00   2.7500e+00 2.75 2.7556666 8
 [9,]   2.5000e+00   2.5000e+00 2.50 2.5056666 8
[10,]   2.2500e+00   2.2500e+00 2.25 2.2556666 8
[11,]   2.e+00   2.e+00 2.00 2.0056666 8
[12,]  -2.5000e+00  -2.5000e+00 1.00 2.0056666 8
[13,]  -7.5000e+00  -7.5000e+00 1.00 2.0056666 8
[14,]  -4.9750e+02  -4.9750e+02 1.00 2.0056666 8
[15,]  -4.9975e+03  -4.9975e+03 1.00 2.0056666 8
[16,]  -5.e+09  -5.e+09 1.00 2.0056666 8
[17,]  -5.e+99  -5.e+99 0.00 0.0000000 0
[18,] -5.e+199 -5.e+199 0.00 0.0000000