161221
John:

?? in nlsr and Deriv, does a new derivative rule replace existing one? Warning?

I haven't checked yet, but I agree that a warning should appear. So if you agree to the procedure, I'll document what happens and add a warning if we don't already have one.

?? Change name of Deriv and fnDeriv in nlsr to Drv, fnDrv to avoid conflict and allow
simultaneous load. Simplify -> Smplfy etc. Any others?

In this case I agree a renaming is desirable, but I don't like your choice.  I'd prefer nlsDeriv, nlsFnDeriv, nlsSimplify.   So according to the procedure above, I'd just add my own
note to your note, and we can discuss later about the names. (But you also have the suggestion to delegate all of this to Deriv, so it might make more sense just to drop these functions.)

Duncan



Working slowly through nlsr-derivs.Rmd.  The problems you found in iterated 
derivatives are fundamental, and come down to the choice to accept things like

Deriv(firstdn, "x")

as a request to ask to get the derivative of the expression "firstdn", rather than the derivative of the expression contained in the variable firstdn.  You can do the latter by calling

Deriv(firstdn, "x", do_substitute = FALSE)

and it would be trivial to set FALSE as the default, but then

Deriv(x^2, "x")

would fail.

It would be easy to get

Deriv(~ x^2, "x")

to work in the latter case, but I'm not sure what we'd want the result to be:  a formula again?  What should

Deriv(y ~ x^2, "x")

give?
%%JN: prob want this to fail and do it in parts (L and R).

Duncan

On 21/12/2016 10:19 AM, John Nash wrote:
> All that you suggest seems reasonable, and process suggested is efficient.
>
> Your naming suggestion is fine. My main concern is conflicts. I rather dislike it when one package element masks
> another. If that is interactive, you may notice. If it's in a script, then things can go pear shaped if there is
> anything unintended.
>
> I think we do need to consider if we want to delegate to Deriv package, and that choice isn't obvious because on one
> hand we get the benefit of others' work, but the cost is they may do something to clobber our efforts.
>
> Cheers, JN
>
> PS. I think the two things that seemed to elude me particularly were how/when to use fnDeriv and how to get dotargs to
> work as per nls() to provide data.
>
>
161221

I've just committed a bunch of changes:

- Rename Deriv and Simplify to nlsDeriv and nlsSimplify respectively.
- Issue warning if derivative is changed
- fix bug in fnDeriv
- Add handling of formulas using ~ in nlsDeriv and fnDeriv
- Edits (mainly related to the above) to nlsr-derivs.Rmd vignette

All of these are reversible if you have objections.

Duncan

%%JN 161223 OK

I think I'd rather leave the derivative calculations in nlsr.  I really don't trust the Deriv package to work reliably.  You mentioned the spelling and grammar errors; they worry me.  But the design itself is bad.  For example,

> library(Deriv)
> Deriv(x, "x")
[1] 1
> x <- quote(x^2)
> Deriv(x, "x")
2 * x

Function results should depend on the arguments, not what else happens to be defined or not.

%%JN 161223 -- pointed out nlsDeriv makes same mistake.

You mention that it has slightly more coverage.  I think it would be easier to add functions than to work with their design.

%%JN I think this is for Bessel functions. Not likely great demand, but nice if we can do it, and we can possibly crib from Deriv package. There may be others. An open question is how to gracefully either inform user there is no available derivative or substitute (if option set) an approximation. But that may be down the road a bit.

>
> 2) Appendix A of nlsr-devdoc vignette and inst/devfiles/nlsdata.R test
> different ways to provide exogenous data to nonlinear least squares
> solvers. I call the modes "quiet" to indicate data is in the calling
> environment, "dots" to say it is in dotargs and "frame" if in dataframe.
> My old nlmrt packages only does "frame", nls() does all, and nlsr (currently)
> and minpack.lm::nlsLM do "frame" and "quiet" but not "dots". Is there an
> easy way to make nlsr do the "dots" too?

I haven't looked into this one yet, but it's probably not too hard.
>
> 3) I can't seem to get a handle on fnDeriv. Do we need it?

I've added some examples of usage to nls-derivs.Rmd.  I don't know if we need it.

%%JN The examples are useful. And I think I can possibly generate a use-case, but
perhaps for optimr/optimrx rather than nlsr. So "we" (i.e., nlsr) probably don't
need it, but it will be more generally helpful.

>
> 4) How soon should we aim to put on CRAN to reserve the name?

%%JN Good. I agree with this, probably sooner rather than later would fit my timing best. I'll be going to Florida as of Dec 28, but once there (after Jan 4) aim to do a bit of work on things each day. I've also some ongoing tasks with a couple of "example" vignettes, one on timing optimization using the Rayleigh Quotient minimization, another on related sumscale problems where objective function has a sum constraint on the parameters. Also a package for testing optimization and nonlinear least squares methods. There are loads of tests, all inconsistent or incompatible. So I've plenty on my plate -- like you!
But nlsr deserves to be available soon.

It has enough in it now to be useful.  We can't get it onto CRAN until it passes checks cleanly, and we shouldn't put it on until we've settled on the user interface choices (function names, argument defaults, etc.).  So I'd say the first thing is to settle those choices, then I can do the cleanup pretty quickly.

I have no teaching next term.  I'm doing a few other things, but I can spend a fair bit of time on this in January through March.  (I'm offline for a couple of weeks in April, but things should be done well before that.)

Duncan

%%JN Attempts to clean up some aspects of package.

- Do we need dot args in model2rjfun etc?


- Do we need/want rjfun()?


