Comments (8)
hope you didn't already try to find the problem. It's the following :)
diff --git a/R/Deriv.R b/R/Deriv.R
index a9b0edc..2ee6dcf 100644
--- a/R/Deriv.R
+++ b/R/Deriv.R
@@ -164,7 +164,7 @@ Deriv <- function(f, x=if (is.function(f)) names(formals(f)) else all.vars(if (i
f <- substitute(f)
}
# clean dsym env
- rm(list=ls(dsym), envir=dsym)
+ rm(list=ls(dsym, all.names=T), envir=dsym)
if (is.null(env))
env <- .GlobalEnv
if (is.null(x)) {
from deriv.
Thanks for the bug and fix. Unfortunately, the proposed solution fixes only the above example. There would still be issues with more complicated nested calls.
It is fixed in the version 3.5
from deriv.
Hi,
I don't know if you have received automatic notifications from github,
so may be this message is superfluous.
Both of your issues are fixed now (cf v3.5 on github).
If no new problem appears meanwhile, I'll submit this version to CRAN
in two weeks.
Thanks for your interest and inputs.
Best,
Serguei.
Le 25/05/2015 13:39, notEvil a écrit :
hope you didn't already try to find the problem. It's the following :)
|diff --git a/R/Deriv.R b/R/Deriv.R
index a9b0edc..2ee6dcf 100644
--- a/R/Deriv.R
+++ b/R/Deriv.R
@@ -164,7 +164,7 @@ Deriv <- function(f, x=if (is.function(f)) names(formals(f)) else all.vars(if (i
f <- substitute(f)
}
# clean dsym env
- rm(list=ls(dsym), envir=dsym)
- rm(list=ls(dsym, all.names=T), envir=dsym)
if (is.null(env))
env <- .GlobalEnv
if (is.null(x)) {
|—
Reply to this email directly or view it on GitHub #2 (comment).
from deriv.
I have, thank you.
I can't promise to find any further bugs soon, so go ahead :)
In the near future I plan to release an R package which benefits a lot
from your package!
As for the issue: might Deriv still return a wrong but valid expression
due to variable naming?
Best, Andreas
On 05/26/2015 05:38 PM, Serguei Sokol wrote:
Hi,
I don't know if you have received automatic notifications from github,
so may be this message is superfluous.Both of your issues are fixed now (cf v3.5 on github).
If no new problem appears meanwhile, I'll submit this version to CRAN
in two weeks.Thanks for your interest and inputs.
Best,
Serguei.Le 25/05/2015 13:39, notEvil a écrit :
hope you didn't already try to find the problem. It's the following :)
|diff --git a/R/Deriv.R b/R/Deriv.R
index a9b0edc..2ee6dcf 100644
--- a/R/Deriv.R
+++ b/R/Deriv.R
@@ -164,7 +164,7 @@ Deriv <- function(f, x=if (is.function(f))
names(formals(f)) else all.vars(if (i
f <- substitute(f)
}clean dsym env
- rm(list=ls(dsym), envir=dsym)
- rm(list=ls(dsym, all.names=T), envir=dsym)
if (is.null(env))
env <- .GlobalEnv
if (is.null(x)) {
|—
Reply to this email directly or view it on GitHub
#2 (comment).—
Reply to this email directly or view it on GitHub
#2 (comment).
from deriv.
Le 26/05/2015 20:43, notEvil a écrit :
I have, thank you.
I can't promise to find any further bugs soon, so go ahead :)
In the near future I plan to release an R package which benefits a lot
from your package!
To my knowledge, it will be premiere :)As for the issue: might Deriv still return a wrong but valid expression
due to variable naming?
I am afraid, I don't understand the question. Do you have an example
of such situation?
Btw, there is v3.5.1 now with a small fix in Cache() function.
Best,
Sergueï.
from deriv.
I was refering to your statement
"Unfortunately, the proposed solution fixes only the above example.
There would still be issues with more complicated nested calls."
I didn't know whether you meant that the fix is incomplete (as in there
exists a general fix) or that it's just a fix for this particular
sequence and it's still unsafe if there are nested calls, even with the
new version.
Imagine the expression consists of .eXYZ and Deriv (or better Simplify)
decides to create a cached expression with the same name, this would
result in an expression which would still evaluate but is simply wrong.
Hope it clears things up.
Best, Andreas
On 05/27/2015 03:55 PM, Serguei Sokol wrote:
Le 26/05/2015 20:43, notEvil a écrit :
I have, thank you.
I can't promise to find any further bugs soon, so go ahead :)
In the near future I plan to release an R package which benefits a lot
from your package!
To my knowledge, it will be premiere :)As for the issue: might Deriv still return a wrong but valid expression
due to variable naming?
I am afraid, I don't understand the question. Do you have an example
of such situation?Btw, there is v3.5.1 now with a small fix in Cache() function.
Best,
Sergueï.—
Reply to this email directly or view it on GitHub
#2 (comment).
from deriv.
Le 27/05/2015 17:51, notEvil a écrit :
I was refering to your statement
"Unfortunately, the proposed solution fixes only the above example.
There would still be issues with more complicated nested calls."I didn't know whether you meant that the fix is incomplete (as in there
exists a general fix) or that it's just a fix for this particular
sequence and it's still unsafe if there are nested calls, even with the
new version.Imagine the expression consists of .eXYZ and Deriv (or better Simplify)
decides to create a cached expression with the same name, this would
result in an expression which would still evaluate but is simply wrong.Hope it clears things up.
Yes, it is clear now.
Your example of nested call is particular in a sens that the innermost
call to Deriv() is made before than the outermost one has something to do.
Imagine a different call structure like this:
Deriv
some operations modifying dsym
Deriv (here the fact that dsym is erased can interfer this the precedent call to Deriv)
some other operations needing original dsym
That's why, a general case of nested calls to Deriv requires a local dsym
(and scache by the same occasion).
Hope it helps.
Serguei.
Best, Andreas
On 05/27/2015 03:55 PM, Serguei Sokol wrote:
Le 26/05/2015 20:43, notEvil a écrit :
I have, thank you.
I can't promise to find any further bugs soon, so go ahead :)
In the near future I plan to release an R package which benefits a lot
from your package!
To my knowledge, it will be premiere :)As for the issue: might Deriv still return a wrong but valid expression
due to variable naming?
I am afraid, I don't understand the question. Do you have an example
of such situation?Btw, there is v3.5.1 now with a small fix in Cache() function.
Best,
Sergueï.—
Reply to this email directly or view it on GitHub
#2 (comment).—
Reply to this email directly or view it on GitHub #2 (comment).
Serguei Sokol
Ingenieur de recherche INRA
Metabolisme Integre et Dynamique des Systemes Metaboliques (MetaSys)
LISBP, INSA/INRA UMR 792, INSA/CNRS UMR 5504
135 Avenue de Rangueil
31077 Toulouse Cedex 04
tel: +33 5 6155 9276
fax: +33 5 6704 8825
email: [email protected]
http://metasys.insa-toulouse.fr
http://www.lisbp.fr
from deriv.
Now everything is clear to me. Thank you for your time to explain.
On 05/28/2015 01:28 PM, Serguei Sokol wrote:
Le 27/05/2015 17:51, notEvil a écrit :
I was refering to your statement
"Unfortunately, the proposed solution fixes only the above example.
There would still be issues with more complicated nested calls."I didn't know whether you meant that the fix is incomplete (as in there
exists a general fix) or that it's just a fix for this particular
sequence and it's still unsafe if there are nested calls, even with the
new version.Imagine the expression consists of .eXYZ and Deriv (or better Simplify)
decides to create a cached expression with the same name, this would
result in an expression which would still evaluate but is simply wrong.Hope it clears things up.
Yes, it is clear now.
Your example of nested call is particular in a sens that the innermost
call to Deriv() is made before than the outermost one has something to do.
Imagine a different call structure like this:
Deriv
some operations modifying dsym
Deriv (here the fact that dsym is erased can interfer this the precedent
call to Deriv)
some other operations needing original dsymThat's why, a general case of nested calls to Deriv requires a local dsym
(and scache by the same occasion).Hope it helps.
Serguei.Best, Andreas
On 05/27/2015 03:55 PM, Serguei Sokol wrote:
Le 26/05/2015 20:43, notEvil a écrit :
I have, thank you.
I can't promise to find any further bugs soon, so go ahead :)
In the near future I plan to release an R package which benefits
a lot
from your package!
To my knowledge, it will be premiere :)As for the issue: might Deriv still return a wrong but valid
expression
due to variable naming?
I am afraid, I don't understand the question. Do you have an example
of such situation?Btw, there is v3.5.1 now with a small fix in Cache() function.
Best,
Sergueï.—
Reply to this email directly or view it on GitHub
#2 (comment).—
Reply to this email directly or view it on GitHub
#2 (comment).Serguei Sokol
Ingenieur de recherche INRA
Metabolisme Integre et Dynamique des Systemes Metaboliques (MetaSys)LISBP, INSA/INRA UMR 792, INSA/CNRS UMR 5504
135 Avenue de Rangueil
31077 Toulouse Cedex 04tel: +33 5 6155 9276
fax: +33 5 6704 8825
email: [email protected]
http://metasys.insa-toulouse.fr
http://www.lisbp.fr—
Reply to this email directly or view it on GitHub
#2 (comment).
from deriv.
Related Issues (20)
- Issue with non-standard evaluation HOT 2
- problem with string formatting HOT 2
- Incorrect derivatives? HOT 5
- incorporating custom drules in a downstream package HOT 2
- Part of results gets into function arguments? HOT 1
- Things like c(x, y) ^ 2 are not supported HOT 3
- feature request: make it possible to extend Deriv by defining primitives HOT 3
- Does not work for list of functions (?) HOT 3
- Can't simplify `y + c(1, 2)` HOT 1
- Simplify `y + c(0, 1)` fails HOT 2
- Matrix calculus HOT 12
- support for genetic functions? HOT 6
- browser() HOT 2
- Error about the derivative for product HOT 2
- Problems with applying Deriv() to dbinom(). HOT 12
- Bug using long expressions in Deriv() related to deparse() HOT 1
- Error in missing(FALSE) : invalid use of 'missing' HOT 4
- problem with composite function HOT 3
- Error in FUN(X[[i]], ...) : Could not retrieve body of '[()' HOT 14
- Issues in Simplify.log HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from deriv.