From @pencer@gr@ve@ @end|ng |rom prod@y@e@com  Tue Nov 10 15:36:43 2020
From: @pencer@gr@ve@ @end|ng |rom prod@y@e@com (Spencer Graves)
Date: Tue, 10 Nov 2020 08:36:43 -0600
Subject: [Rd] one thing to check
In-Reply-To: <f90e075a-80e0-42ea-e9aa-47099512465c@effectivedefense.org>
References: <6F12BE7A-447F-48C2-BD8B-373EA350B5F1@mcgill.ca>
 <f90e075a-80e0-42ea-e9aa-47099512465c@effectivedefense.org>
Message-ID: <198cd211-5a6b-c920-a0c6-fd32fcba5798@prodsyse.com>

	  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 <r-devel at r-project.org>, 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
>>
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] one thing to check
Spencer Graves