In Julia one can use NLopt to solve various problems. NLopt has many algorithms and here we can find an example that utilises MMA using LD_MMA symbol.
My question is this: is there any complete list of all symbols incorporated in NLopt?
All the codes are listed in the NLopt.jl source, they are exactly like those described in that wiki page but without the NLOPT_ prefix.
Related
I'm writing some R functions that employ some useful functions in other packages like stringr and base64enc. Is it good not to call library(...) or require(...) to load these packages first but to use :: to directly refer to the function I need, like stringr::str_match(...)?
Is it a good practice in general case? Or what problem might it induce?
It all depends on context.
:: is primarily necessary if there are namespace collisions, functions from different packages with the same name. When I load the dplyr package, it provides a function filter, which collides with (and masks) the filter function loaded by default in the stats package. So if I want to use the stats version of the function after loading dplyr, I'll need to call it with stats::filter.
This also gives motivation for not loading lots of packages. If you really only want one function from a package, it can be better to use :: than load the whole package, especially if you know the package will mask other functions you want to use.
Not in code, but in text, I do find :: very useful. It's much more concise to type stats::filter than "the filter function from the stats package".
From a performance perspective, there is a (very) small price for using ::. Long-time R-Core development team member Martin Maechler wrote (on the r-devel mailing list (Sept 2017))
Many people seem to forget that every use of :: is an R
function call and using it is inefficient compared to just using
the already imported name.
The performance penalty is very small, on the order of a few microseconds, so it's only a concern when you need highly optimized code. Running a line of code that uses :: one million times will take a second or two longer than code that doesn't use ::.
As far as portability goes, it's nice to explicitly load packages at the top of a script because it makes it easy to glance at the first few lines and see what packages are needed, installing them if necessary before getting too deep in anything else, i.e., getting halfway through a long process that now can't be completed without starting over.
Aside: a similar argument can be made to prefer library() over require(). Library will cause an error and stop if the package isn't there, whereas require will warn but continue. If your code has a contingency plan in case the package isn't there, then by all means use if (require(package)) ..., but if your code will fail without a package you should use library(package) at the top so it fails early and clearly.
Within your own package
The general solution is to make your own package that imports the other packages you need to use in the DESCRIPTION file. Those packages will be automatically installed when your package is installed, so you can use pkg::fun internally. Or, by also importing them in the NAMESPACE file, you can import an entire package or selectively importFrom specific functions and not need ::. Opinions differ on this. Martin Maechler (same r-devel source as above) says:
Personally I've got the impression that :: is
much "overused" nowadays, notably in packages where I'd strongly
advocate using importFrom() in NAMESPACE, so all this happens
at package load time, and then not using :: in the package
sources itself.
On the other hand, RStudio Chief Scientist Hadley Wickham says in his R Packages book:
It's common for packages to be listed in Imports in DESCRIPTION, but not in NAMESPACE. In fact, this is what I recommend: list the package in DESCRIPTION so that it’s installed, then always refer to it explicitly with pkg::fun(). Unless there is a strong reason not to, it's better to be explicit.
With two esteemed R experts giving opposite recommendations, I think it's fair to say that you should pick whichever style suits you best and meets your needs for clarity, efficiency, and maintainability.
If you frequently find yourself using just one function from another package, you can copy the code and add it to your own package. For example, I have a package for personal use that borrows %nin% from the Hmisc package because I think it's a great function, but I don't often use anything else from Hmisc. With roxygen2, it's easy to add #author and #references to properly attribute the code for a borrowed function. Also make sure the package licenses are compatible when doing this.
I'm a R newbie.
is there a way i can calculate
(x+x^2+x^3)^2
in R?
so i will get the result:
x^6+2 x^5+3 x^4+2 x^3+x^2
I get an Error: object 'x' not found.
Thanks!
R isn't well suited for this. Some interface packages to languages and libraries that are better at this do exist, such as rSymPy, which allows you to access the SymPy Python library for symbolic mathematics (you'll need to install both). In a similar vein, Ryacas links to the yacas algebra system.
Those interfaces are useful if you need symbolic manipulation as part of an R workflow. Otherwise, consider using the original tools. The ones above are open source and freely available, while other free use alternatives also exist, such as the proprietary web based Wolfram Alpha (for limited use).
I use Mathematica for symbolic math calculations. I am planning to switch to another language. Matlab (which I use for standard computation stuff) includes this feature but I am looking at the possibility of using Julia, since it seems to be the future. Yet, there seems to be no symbolic tool available (no mention in official documentation). Apparently the only package available (SymPy) says "Test Failed" in the official website (http://pkg.julialang.org/).
Has anyone been able to do this in Julia?
Now, looking at http://pkg.julialang.org/ one could find more candidates to perform symbolic mathematics in julia:
SymEngine.jl
Julia Wrappers for SymEngine, a fast symbolic manipulation library, written in C++.
Symata.jl
a language for symbolic computations and mathematics, where, for the most part, "mathematics" means what it typically does for a scientist or engineer.
SymPy.jl
Julia interface to SymPy via PyCall
Also:
LinearExpressions.jl
Linear symbolic expressions for the Julia language
SymPy Package works fine, it brings Python's Sympy functionality into Julia via PyCall.
SymPy is a Python library for symbolic mathematics. It aims to
become a full-featured computer algebra system (CAS) while keeping the
code as simple as possible in order to be comprehensible and easily
extensible. SymPy is written entirely in Python and does not require
any external libraries.
Also, consider the Nemo.jl library which they claim is faster than alternatives like SageMath.
I'm in the process of documenting some of my functions for an R package I'm making.
I'm using roxygen markup, though that is largely irrelevant to my question.
I have put equations into my documentation using \deqn{...}. My question is:
Is there a way to cross-reference this equation later on?
For example, in my Rd file:
\deqn{\label{test}
y = mx + b
}
Can I later do something like:
Referring to equation \ref{test}, ...
I've tried \eqref{test}, \ref{test} (which both get "unknown macro" and don't get linked ), and also \link{test} (which complains it can't find function test because it's really just for linking to other functions).
Otherwise I fear I may have to do something hacky and add in the -- (1) and Refer to equation (1) manually within the \deqn etc in the Rd file...
Update
General answer appears to be "no". (awww...)
However, I can write a vignette and use "normal" latex/packages there. In any case, I've just noticed that the matrix equations I spent ages putting into my roxygen/Rd file look awful in the ?myFunction version of the help (they show up as just-about literal latex source). Which is a shame, because they look beautiful in the pdf version of the help.
#Iterator has pointed out the existence of conditional text, so I'll do ASCII maths in the .Rd files, but Latex maths in the pdf manual/vignette.
I'm compiling my comments above into an answer, for the benefit of others.
First, I do not actually know whether or not .Rd supports tagging of equations. However, the .Rd format is such a strict subset of LaTeX, and produces very primitive text output, that shoehorning extensive equations into its format could be a painful undertaking without much benefit to the user.
The alternative is to use package vignettes, or even externally hosted documentation (as is done by Hadley Wickham, for some of his packages). This will allow you to use PDFs or other documentation, to your heart's content. In this way, you can include screenshots, plots, all of the funkiest LaTeX extensions that only you have, and, most significantly, the AMS extensions that we all know and love.
Nonetheless, one can specify different rendering of a given section of documentation (in .Rd) based on the interface, such as text for the console, nice characters for HTML, etc., and conditional text supports that kind of format variation.
It's a good question. I don't know the answer regarding feasibility, but I had similar questions about documenting functions and equations together, and this investigation into what's feasible with .Rd files has convinced me to use PDF vignettes rather than .Rd files.
How do people learn about giving an R package a namespace? I find the documention in "R Extensions" fine, but I don't really get what is happening when a variable is imported or exported - I need a dummy's guide to these directives.
How do you decide what is exported? Is it just everything that really shouldn't required the pkg:::var syntax? What about imports?
Do imports make it easier to ensure that your use of other package functions doesn't get confused when function names overlap?
Are there special considerations for S4 classes?
Packages that I'm familiar with that use namespaces such as sp and rgdal are quite complicated - are there simple examples that could make things clearer?
I have a start on an answer on the devtools wiki: https://r-pkgs.org/Metadata.html
Few years later here....
I consolidated findings from Chambers, other StackOverflow posts, and lots of tinkering in R:
https://blog.thatbuthow.com/how-r-searches-and-finds-stuff/
This is less about implementing NAMESPACE/IMPORTS/DEPENDS and more about the purpose of these structures. Answers some of your questions.
The clearest explanation I've read is in John Chambers' Software for Data Analysis: Programming with R, page 103. I don't know of any free online explanations that are better than what you've already found in the R Extensions manual.
You could also pick an easy, small package and follow it.
I semi-randomly looked at digest which is one of my smaller packages. I loads a (small) dynamic library and exports one symbol, the digest() function. Here is the content of the NAMESPACE file:
## package has dynamic library
useDynLib(digest)
## and one and only one core function
export(digest)
Have a look at the rest of the source files and maybe try to read Writing R Extensions alongside looking at the example, and do some experiments.
http://www.stat.uiowa.edu/~luke/R/namespaces/morenames.pdf