Serguei Sokol
Serguei Sokol
Thanks for the patch and possibility to iterate. This time I have: ``` /usr/local/R-3.4.3_gcc/lib64/R/lib/libRlapack.so: undefined symbol: cla_syrfsx_extended_ ```
Next round ;) ``` /usr/local/R-3.4.3_gcc/lib64/R/lib/libRlapack.so: undefined symbol: do_lio ```
Oups... After some searching it's a problem of libf2c.so. It was not installed on my system (may be `./configure` should test for it?). After installation, I've got a lacking `MAIN__`...
It went well without `-lf2c` neither `-u MAIN__`. Now, in R, I have compared the timing of native lapack and libflame and found it very close, e.g. around 1.09 s...
Thanks for reporting. I confirm both problems that I could reproduce on my side. I will see how it could pass automatic tests which compare with numerical differences.
dbinom's rule is fixed in v4.1.4. Could you confirm that it works correctly on your side, please? ``` devtools::install_github("sgsokol/Deriv") library(Deriv) packageVersion("Deriv") [1] ‘4.1.4’ ```
One thing after another. I did not yet get a look at the problem on a new environment. But it is on my "todo" list. As to your "silly" problem...
Even if Deriv() pretends to work with scalar expressions, you are right, it's better to make it as much compatible as possible with vector expressions. That will require to fix...
> Perhaps the help file for Deriv should warn the user NOT to use variables named ".e1", ";e2", ... etc. when constructing new rules. The situation was revealed to be...
current version fixes both new.env() and compound expressions in drule. Does it work well on your side ?