diff works with polynomials but diff(sin(x),x) gives out the error message.
When I removed "from math import *" from the code, diff(sin(x),x) worked. Why is it? What of "math" crashes with symbolic differentiation of trig function?
SymPy functions only work with SymPy functions.
The functions in the math module are numeric functions. They only know how to work with numeric arguments (floats or ints). If you give them a symbolic expression like x they won't know what to do. This is because only SymPy functions know how to stay unevaluated.
It is recommend to not use import * unless you are working interactively, and even then, do it from at most one module. SymPy functions and expressions do not mix with numeric functions from modules like math or numpy.
Instead, you can run
import sympy as sym
and use sym.sin and so on.
Also, in general, it should not be necessary to use the math module at all when using SymPy, as everything implemented in the math module is also in implemented in SymPy.
Related
I want to solve primitive functions algebraic for math class. I have been looking around and have found a lot of websites that have this function, but not any open source code!
The basic functionality is to have a function, and the be able to calculate it's primitive function and get the result back as an algebraic expression.
eg.
input: f(x) = cos(x)
output: F(x) = sin(x)
Are there code out there to solve this problem? I just need a template for my own code. And so the language isn't really of any concern.
Thanks for any help!
I have looked around on github and googled but haven't found anything!
I am making an R-Package and I'm struggling with the import of infix functions like %>%, := or %dopar%.
In the DESCRIPTION-file I use the Imports: <otherPackage> (e.g. Imports: doParallel) notion. Within the code I use the package::function() (e.g. dplyr::mutate()) notion, which seems to work (R CMD check is pleased) but how do I import infix functions?
The #importFrom (e.g #' #importFrom magrittr %>%) roxygen way seems to work for %>%, := and %dopar%. But since it is copied over into the NAMSEPACE-file, adding the #importFrom to one function solves the problem package-wide, which seems rather "hacky".
What is the best practice to import such functions into my package?
I'm not sure if there's a single best practice in this case.
Using #importFrom to update the NAMESPACE file is indeed to be a package-wide directive,
but I've never come across a package that had problems with that,
or reasons to avoid it.
You can annotate several functions with the same #importFrom directive if you like,
denoting which functions use which imports,
and it won't cause any conflicts;
it's entirely up to you though,
a single one would suffice.
Using #import might be frowned upon,
but I think it really depends on which package you import.
From your question I gather you use :: explicitly
(which I would personally say is good practice),
and then you don't even need to alter the NAMESPACE.
For most cases that would be just fine,
though there can be very special cases that usually need to be considered individually.
These special cases, at least in my experience, are usually related with S4 generics.
Take for instance the base::rowSums function:
it is not a generic function in base,
but if the Matrix package is attached,
rowSums is "transformed" into an S4 generic,
but the generic is not in the base package.
Why that's the case is beyond the scope of this answer
(see ?Methods_for_Nongenerics for more information),
but it means that if your package uses the notation base::rowSums,
it would not dispatch to methods from Matrix.
The only way to support both cases
(i.e. when Matrix is not used by the user and when it is)
would be to use rowSums without base::.
Now, regarding infix operators,
if you wanted to use ::,
you'd need something like base::`%in%`("a", c("a", "b")),
which essentially entails using it as a function and losing the infix syntax,
something you probably don't want.
So unless you have very specific reasons to avoid one or the other,
just use whatever notation you prefer.
I'd personally stick to :: as much as possible,
but would never use it for infix operators.
In Python we have chance to import a certain function from a library with a command "import function from library as smth. Do we have something similar in R?
I know that we can call the function like "library::function()", my question mostly refers to the "as" part.
It is not common and not necessary to do this in R. The assignment operator <- can be used to give a new name to an existing function. For example, one could define a function that does exactly the same as lubridate's, year() function with:
asYear <- lubridate::year
One could argue that, by doing so, the year() function has been "imported" from the lubridate package and that it is now called asYear(). In fact, the new function does just the same (which is no surprise, simply because it is the same):
asYear(Sys.Date())
#[1] 2016
So it is possible to construct an analogy to "from package import as", but it is not a good idea to do this. Here are a few reasons I can think of:
Debugging a code where library functions have been renamed will be
much more difficult.
The documentation is not available for the renamed function. In this example, ?asYear won't work, in contrast to ?lubridate::year or library(lubridate); help(year).
The function is not only renamed but it is copied, which clutters the environment and is inefficient in terms of memory usage.
The maintenance of the code becomes unnecessarily difficult. If another programmer (or the original programmer a few years later) looks at a code containing such a redefinition of a function, it will be harder for her or him to understand what this function is doing.
There are probably more reasons, but I hope that this is sufficient to discourage the use of such a construction. Different programming languages have different peculiarities, and as a programmer it is necessary to adapt to them. What is common in Python can be awkward in R, and vice versa.
A simple and commonly used way to handle such a standard situation in R is to use library() to load the entire namespace of the package containing the requested function:
library (lubridate)
year(Sys.Date())
However, one should be aware of possible namespace clashes, especially if many libraries are loaded simultaneously. Different functions could be defined with the same name in different packages. A well-known example thereof are the contrasting implementations of the lag() function in the dplyr and stats package.
In such cases one can use the double colon operator :: to resolve the namespace that should be addressed. This would be similar to the use of "from" in the case of "import", but such a specification would be needed each time the function is called.
lubridate::year(Sys.Date())
#[1] 2016
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 often use Rcpp code to incorporate C++ code into R. Through the BH-package I am also able to use the Boost-library. However, the Boost library lacks a function that I would like to use (to be precise, it only has Bessel function but I would like to get Log-Bessel immediately because of overflow). I know that Alglib does have this feature.
Would it be possible to use Alglib with Rcpp, that is, use the log-bessel function from Alglib somehow?
I do not see a clear difference in functionality between the
AlgLib documentation on Bessel functions, and
Boost documentation on Bessel functions.
As such, I think you can just use the BH package giving you all of Boost Math and then some.
Last but not least there is a package bessel on CRAN written by the R Core member focusing on special functions so you could start from there too.