Re: one thing to check

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: one thing to check

Spencer Graves-4
Hi, Jim:


          Could you please look at svd2.Rd and see what it says?  It may give
an example, where it gave a better answer than svd -- i.e., a marginal
case, where svd2 honestly gave a better answer than svd.


          If we find -- either in svd2.Rd or in one of the revdepchecks -- an
example where svd2 gives a demonstrably different answer, we need to
consider what to do about that.


                    1.  Is the different answer demonstrably better?  If yes, can we
fix it without LINPACK?  If yes, do that.  If no, we document those
concerns, send them to R-Devel <[hidden email]>, and retain svd2
in fda and keep its use as it was.  Then R-Devel can deal with the
problem however they want, and it won't affect fda -- at least not right
now.


                    2.  Does the different answer break something in revdepcheck
because of a cosmetic problem?  If yes, try to communicate that issue
with the maintainer(s) of the package(s) that would be affected by such
a change.  I suggest you send them tell then that svd2 is now deprecated
-- AND mark svd2.Rd with such a message -- while also sending them code
for the function(s) they call that give them an error message, and tell
them that you plan to remove svd2 from the next release, and ask them to
fix that so a revdepcheck with that new code won't be flagged as an
error.  AND ask them to notify you when they have a version on CRAN that
works with your new code.


                    3.  If the new code gives a different answer that doesn't seem
better in at least one example AND deleting svd2 doesn't break anything
in revdepcheck, then delete it.


                    4.  If you still need to retain svd2 because of a revdepcheck
problem, I'd also document that in "cran-comments.md".


          What do you think?
          spencer


On 2020-11-10 07:10, James Ramsay wrote:

> Hi Spencer,
>
> One thing I’d like check with you:
>
> I removed svd2 because CRAN indicated that LINPACK had been deprecated.  I replaced calls to svd2 with svd in geigen and CSTRfn.
>
> This could be the issue with the two broken codes … or not.  But what is your view about using svd instead of svd2, and do you have an idea of what to do about the LINPACK calls?
>
> Best,
>
> Jim
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: one thing to check

Spencer Graves-3
          Please excuse:  I did NOT intend to send this to R-Devel at this
time.  I was suggesting to Jim Ramsay a question we MIGHT want to pose
to R-Devel.  (I've since decided we probably won't need to.)


          Spencer


On 2020-11-10 07:58, Spencer Graves wrote:

> Hi, Jim:
>
>
>        Could you please look at svd2.Rd and see what it says?  It may
> give an example, where it gave a better answer than svd -- i.e., a
> marginal case, where svd2 honestly gave a better answer than svd.
>
>
>        If we find -- either in svd2.Rd or in one of the revdepchecks --
> an example where svd2 gives a demonstrably different answer, we need to
> consider what to do about that.
>
>
>              1.  Is the different answer demonstrably better?  If yes,
> can we fix it without LINPACK?  If yes, do that.  If no, we document
> those concerns, send them to R-Devel <[hidden email]>, and retain
> svd2 in fda and keep its use as it was.  Then R-Devel can deal with the
> problem however they want, and it won't affect fda -- at least not right
> now.
>
>
>              2.  Does the different answer break something in
> revdepcheck because of a cosmetic problem?  If yes, try to communicate
> that issue with the maintainer(s) of the package(s) that would be
> affected by such a change.  I suggest you send them tell then that svd2
> is now deprecated -- AND mark svd2.Rd with such a message -- while also
> sending them code for the function(s) they call that give them an error
> message, and tell them that you plan to remove svd2 from the next
> release, and ask them to fix that so a revdepcheck with that new code
> won't be flagged as an error.  AND ask them to notify you when they have
> a version on CRAN that works with your new code.
>
>
>              3.  If the new code gives a different answer that doesn't
> seem better in at least one example AND deleting svd2 doesn't break
> anything in revdepcheck, then delete it.
>
>
>              4.  If you still need to retain svd2 because of a
> revdepcheck problem, I'd also document that in "cran-comments.md".
>
>
>        What do you think?
>        spencer
>
>
> On 2020-11-10 07:10, James Ramsay wrote:
>> Hi Spencer,
>>
>> One thing I’d like check with you:
>>
>> I removed svd2 because CRAN indicated that LINPACK had been
>> deprecated.  I replaced calls to svd2 with svd in geigen and CSTRfn.
>>
>> This could be the issue with the two broken codes … or not.  But what
>> is your view about using svd instead of svd2, and do you have an idea
>> of what to do about the LINPACK calls?
>>
>> Best,
>>
>> Jim
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel