I am porting a set of spatial computations to an embedded environment that essentially compiles and runs C code.
I have replaced a number of the linear algebra functions that previously used VNL (a templated C++ library that will not work on the new platform) with CBLAS and CLAPACK. Their API (all parameters are pointers, no templates) is perfect for what I am doing.
The catch, however, is I do not see quaternion based functions anywhere in the CLAPACK Users Guide. Am I missing a section and there is quaternion support somewhere? If so, please point me to the functions. Specifically, I'm looking for inverse, multiplication, and conversion to and from euler angles and 3x3 matrices.
If there is not this kind of support in CLAPACK, is there another library with similar design characteristics that does quaternion math?
This PDF seems to indicate that quaternion support was not planned in LAPACK. I suppose it is safe to assume CLAPACK would be the same.
http://www.netlib.org/lapack/lawnspdf/lawn106.pdf
I still have not found a replacement or supplementary library that does support quaternions.
EDIT:
Found CQRLib, an ANSI C quaternion library. It allocates variables to the stack (a problem on my architecture), so I'll have to refactor that. But otherwise it looks like it should work.
http://cqrlib.sourceforge.net/
Related
I got a question from my fellow student friend about why +-/* don't need math.h library to work in C language.
<math.h> contains macro and function definitions for mathematical operations. Some of the functionality in <math.h> is required to be present according to the C Standard, but they still aren't intrinsically part of the grammar of the language, unlike the operators +, -, *, / and %.
Because they are in the standard of C and they are only one instruction in Assembly language. math.h is only the name of the library. That doesn't mean there are no math if you don't include it.
If you look at C Operators, notice they are all fairly simple operations that can be done on numbers and values without the need of a function call (sqrt()). These are part of the C standard and are a basic part of the language, present by default in every program.
The math.h Library contains far more complex mathematical operations, mostly in functions, not small assembly instructions. These do not need to be included in the language because not every program is going to need a square root or a cosine.
Basic operators are part of the grammar of the language. In a lib there are "higher functions" that are composed out of basic operators or other libs. So you can reduce everythink back to the basic constructs of a language ... certainly.
Arithmetic operators are built into the language grammar - they're not separate library calls like sqrt() or abs() or whatever. So, they don't need to have any sort of declaration in scope in order to function.
Primarily, the reason math.h is needed for some operations and not others is that the people who designed C decided to build some things into the core language and to keep some things in separate sets, including a set of things for math, a set of things for strings, a set of things for time, a set of things for input and output, and so on.
It would be possible to build the things in math.h into the core language. For example, sizeof is built into the language, so building sqrt into the language too would not require any change of grammar. Also, it would be theoretically possible to exclude some operations like * from the core language and require you to include math.h before using them. However, the language provides ways for declaring functions like sqrt but does not provide ways for declaring operators like *, so some changes to the grammar would have to be made to support this.
So, since it is possible the core language could include or exclude various things, then the reasons for various things being included or excluded are somewhat a matter of choice. Essentially, the basic arithmetic operations were considered fundamental and very useful, so they were made part of the core language, while other functions were not. There are various factors contributing to this.
One is a desire to avoid cluttering the language. If all of the functions declared in headers were part of the core language, then sqrt could be used only for the sqrt in math.h. A programmer could not use sqrt for their own variable name. This is fine for a few names, but, as the library grows, the chance there will be collisions between a name in a library and a name in regular source code grows.
Additionally, if there is existing source code and somebody has a bright idea for a new routine, adding the new routine name to the language might break existing code that is already using that name for a different purpose.
So, generally, we prefer to implement non-essential routines in separate sets, and then authors can choose to include the ones they want to use and learn, and they can leave out the ones they do not need and avoid problems.
Partitioning the libraries into sets like this also means that library routines not used by a program do not have to be linked into the final program executable, so the executable file can be smaller.
Additionally, it means C can be used in a variety of environments, such as a small machine that is not able to support the full math library. Somebody might want to run simple programs that just work with basic arithmetic on a small processor. If the core language of C is small, they can write such programs. If every C program had to include all of the routines on the libraries, it might not be possible to get C working on very small computers.
I'm working with OpenSSL on a Fedora system, and Fedora defines OPENSSL_NO_EC2M, so functions like EC_POINT_get_affine_coordinates_GF2m aren't available. I have code that was written to use these functions that I would like to compile and run on Fedora. Is EC_POINT_get_affine_coordinates_GFp a drop-in (possibly slower) replacement? In general, are functions with GFp in the name drop in replacements for identically named functions that have GF2m in the name?
If they aren't, what should I do to port code that uses them to OpenSSL installations that don't have them?
GFp functions are intended for curves that use a prime field, while GF2m functions are intended for binary curves (see https://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography for more information). In other words the underlying curve type is different. Any well behaved code that is written to use those GF2m functions should only be calling them in a context where it makes sense to do so, i.e. where it knows that the curve type is a binary curve. Since an OpenSSL library that has been built with OPENSSL_NO_EC2M defined does not have any binary curves available in it, it should never be the case that those codepaths are ever hit.
It also turns out that the need for having those different functions in the API was somewhat spurious anyway. The library itself can figure out for itself what the underlying curve type is and do the right thing and the different implementations of most of the GFp/GF2m functions are identical anyway. For that reason many of these functions were recently scheduled for future deprecation (see https://github.com/openssl/openssl/commit/50db81633ec)
Whether you can port code that supports binary curves to a version of the library that doesn't will depend on whether the code you are porting relies on binary curves as an essential part of its operation. In many cases code will support both prime and binary curves. Therefore you can simply use a prime field curve instead and simply comment out the bits of the code that support binary curves. However if it can only be a binary curve then you are out of luck.
I am writing R code which uses compiled C code.
From "Writing R Extensions" document, I learned there are many R executable/DLL that can be called from C code. The header file ‘Rmath.h’ lists many functions that are available and its source codes are listed on the this website: http://svn.r-project.org/R/trunk/src/nmath/
I need to calculate singular value decomposition of many matrices, however I do not find subroutines which does this on the above website. (So I am assuming that Rmath.h does not contain SVD subroutines) Is there simple way to do eigenvalue calculations in C-within-R code?
Thank you very much.
If you're open to using Rcpp and its related packages, the existing examples for the fastLm() show you how to do this with
Eigen via RcppEigen
Armadillo via RcppArmadillo
the GSL via RcppGSL
where the latter two will use the same BLAS as R, and Eigen has something internal that can often be faster. All the packages implement lm() using the decompositions offered by the language (often using solve or related, but switching to SVD is straightforward once you have the toolchain working for you).
Edit: Here is an explicit example. Use the following C++ code:
#include <RcppArmadillo.h>
// [[Rcpp::depends(RcppArmadillo)]]
// [[Rcpp::export]]
arma::vec getEigen(arma::mat M) {
return arma::eig_sym(M);
}
save in a file "eigenEx.cpp". Then all it takes is this R code:
library(Rcpp) ## recent version for sourceCpp()
sourceCpp("eigenEx.cpp") ## converts source file into getEigen() we can call
so that we can run this:
set.seed(42)
X <- matrix(rnorm(3*3), 3, 3)
Z <- X %*% t(X)
getEigen(Z) ## calls function created above
and I get the exact same eigen vector as from R. It really doesn't get much easier.
It also lets Armadillo chose what method to use for the Eigen decomposition, and as David hinted, this is something quicker than a full-blown SVD (see the Armadillo docs).
You can use one of many available Linear Algebra (lapack) libraries. Here is a link explaining how to get lapack libraries for windows. GOTOBLAS, and ACML are free. MKL is also free for non-commercial use. Once you have the libraries installed, the function you are looking for is sgesvd (for float) or dgesvd (for double).
Here are a couple of examples from Intel on how to use gesvd.
Row Major
Col Major
In case you are using Linux, Check out GNU SL and Eigen. These libraries can usually be installed from the package manager of the distribution.
I need to track down how exactly is double sin(double x) implemented in eglibc-2.13. I downloaded the source code and the only part that made sense was __sin function, that was platform-specific. Is it the heart of what I have in /usr/lib/i386-linux-gnu/libm.a?
How to track down the macrodefinitions that lead from sin() to __sin()? What I really need is the exact code (filename and the line is enough) and a way in which the build process deduces which implementation to use. The architecture's i386.
The (e)glibc build process is black, black magic. You do not want to try to comprehend it. However, glibc adheres to a one-file-per-public-function coding style, so in general, if you have the source tree and you want to find the implementation(s) of some function, the easiest thing to do is
$ find * -name '*function*' -print
from the top level, replacing function with the name of the function, of course.
Talking specifically about sin: the generic implementations of the math functions are in the math directory: however, it appears that there is no generic definition of sin. So the next place to look is sysdeps. Everything that isn't generic is in sysdeps, and in particular, sysdeps/ieee754 is where all the math functions that have some dependence on the IEEE 754 floating point specification, but no other system dependencies, live. This directory is organized by type: sysdeps/ieee754/dbl-64 contains all the math functions for IEEE double. And here you will find sysdeps/ieee754/dbl-64/s_sin.c, which is the code you are looking for. (The e_, s_, k_, etc prefixes on all these files used to mean something but AFAIK no longer do.)
If there were an implementation of sin in assembly language for a particular processor, it would be in a file named sin.S (or possibly s_sin.S) somewhere else in sysdeps. It does not appear that there is one, though.
Not an answer, but just a bit of a background:
When you use sin() or cos() in your C code, it is almost certainly the compiler that provides the implementation, rather than your C library. As an example, look at the list of builtins GCC provides. The linked page also describes the cases where the built-ins are used rather than the versions the C library provides.
I am looking for Singular Value Decomposition (SVD) code in C, would you please help me?
I found many sources but I cannot run them, I am looking for a version of SVD code that provide all 3 matrix of S, V and U for me.
You can use the Numerical recipies code for that
svdcmp.c reference. Actually in my case I found more accurate the openCV one, but both work fine.
Use one of the libraries listed at the Wiki page: comparison of linear algebra libraries. Look under the "SVD" column to make sure algorithm is supported (even vast majority of the libraries do support SVD).
Don't write it yourself, don't deal with trying to build someone else's source. Use a library that provides this function for you. There's probably already one available on your target platform.
Specifically, use the industry-standard LAPACK library or use the GSL or whatever other linear algebra library you want. They all have an SVD implementation.