I need to integrate a signal from accelerometer, in order to get speed and position over time.
I'm trying the code on some code-generated acceleration data:
1)squarewave
2)sawtooth
3)sin
The speed function obtained is ok, the problem is with the position function obtained integrating speed. IN each case (squarewave, sawtooth, sin) the doubly discrete-integrated funtion shows a linear term superposed to the expected oscillating one.
I've perfomed this discrete-integration with both diffinv() function and with this custom function I've written:
#function that, given a function sampled at some time values, calculates its primitive
calculatePrimitive<-function(f_t, time, initialValue){
F_t<-0
F_t[1]<-initialValue
for (i in 2:length(f_t)) {
F_t[i] <- F_t[i-1] + (( (f_t[i]+f_t[i-1])/2 )*(time[i]-time[i-1]) )
}
F_t
}
The result is the same, no matter which function i use to performe the discrete integration, and it is shown in the attached graphs for cases 1) to 3).
I don't understand why this happen when, no matter what is the acceleration data, the discrete integration is applied to data that have been obtained by descrete integration themselves.
Related
I am solving a complicated system of nonlinear ODE using R as part of my current project. In a testing phase, I implemented solution using lsoda method by two ways (a) Using event function (b) without event function. Both solution produces slightly different results. I don't understand why it is happening or how to minimize error?
I tried Lotka–Volterra equations by these two methods and still wondering why there is a difference in solution (see attached plot). Although the difference is very small, I want to minimize error which might be big for my project. As you can see, event function is not changing dependent variables but still producing some errors.
rm(list=ls())
library(deSolve);
#############################################################
predpreyLV<-function(t,y,p){
N<-y[1]
P<-y[2]
with(as.list(p),{
dNdt<- r*N*(1-(N/1000))-a*P*N
dPdt<- -b*P+f*P*N
return(list(c(dNdt,dPdt)))
})
}
#############################################################
eventFun<-function(t,y,p){
return (y)
}
#############################################################
r<-0.5; a<-0.01; f<-0.01; b<-0.2;
# Simulation without using event function
p<-c(r=r,a=a, b=b, f=f)
y0<-c(N=25, P=5)
times<-seq(0,1000,0.1)
out1<-ode(y=y0,times,predpreyLV, p,method="lsoda", atol=1e-6, rtol=1e-6)
# Simulation using event function
p<-c(r=r,a=a, b=b, f=f)
y0<-c(N=25, P=5)
times<-seq(0,1000,0.1)
out2<-ode(y=y0,times,predpreyLV, p,method="lsoda",
events=list(func=eventFun, time=times), atol=1e-6, rtol=1e-6)
plot(out1[,1],abs(out1[,2]-out2[,2]), type="l", ylab="Difference in size")
You have to take into account that if not specifically indicated, all solvers have adaptive step size. This means that the solver uses internal steps that are usually not visible to the user, and uses specific polynomial interpolations between the internal nodes to produce the user-requested values.
However, as events can change the state, the solver can not proceed from the next internal node, it has to restart the solution process from the event time with the new state returned from the event function as initial state.
This has several effects. The last step before the event is cut short. The restart process likely uses smaller, non-optimal step sizes. The initialization of a multi-step method as used in lsoda uses a different method, probably also with non-typical step sizes. lsoda also adapts the order of the multi-step method. This also has to be determined empirically, advancing the solver with below-optimal steps sizes in the process.
This all, while not changing the accuracy of the solution much, still leads to a different integration path in terms of step sizes and methods/orders. If the system has stiff regions, as can be the case for polynomial non-linear right sides, these small changes can be magnified to the observed scale.
Still, relative to the maximum size 1000 of N, an error of 0.3 has a relative size of 3e-5, well within the expectation for the given tolerances.
To simulate the effect of different integration control processes I ran the given system (with python-scipy's solve_ivp with method "LSODA") for different tolerance inputs tol in 1e-6, 1e-8, 1e-10 using absolute and relative tolerance parameters atol=1e-2*tol, rtol=tol. These were then compared to a "gold" solution produced with tolerance tol=1e-14. This gives the overlayed solution paths
where there are no visible differences in the curves. For the components themselves and their error, divided by the tolerance value, I get the plots
Again there are no visible differences in the overlay of the three solutions in the first plot. The scaled error plot shows large oscillations corresponding to rapid changes in the solutions.
I would like to use optim() to optimize a cost function (fn argument), and I will be providing a gradient (gr argument). I can write separate functions for fn and gr. However, they have a lot of code in common and I don't want the optimizer to waste time repeating those calculations. So is it possible to provide one function that computes both the cost and the gradient? If so, what would be the calling syntax to optim()?
As an example, suppose the function I want to minimize is
cost <- function(x) {
x*exp(x)
}
Obviously, this is not the function I'm trying to minimize. That's too complicated to list here, but the example serves to illustrate the issue. Now, the gradient would be
grad <- function(x) {
(x+1)*exp(x)
}
So as you can see, the two functions, if called separately, would repeat some of the work (in this case, the exponential function). However, since optim() takes two separate arguments (fn and gr), it appears there is no way to avoid this inefficiency, unless there is a way to define a function like
costAndGrad <- function(x) {
ex <- exp(x)
list(cost=x*ex, grad=(x+1)*ex)
}
and then pass that function to optim(), which would need to know how to extract the cost and gradient.
Hope that explains the problem. Like I said my function is much more complicated, but the idea is the same: there is considerable code that goes into both calculations (cost and gradient), which I don't want to repeat unnecessarily.
By the way, I am an R novice, so there might be something simple that I'm missing!
Thanks very much
The nlm function does optimization and it expects the gradient information to be returned as an attribute to the value returned as the original function value. That is similar to what you show above. See the examples in the help for nlm.
I have a sound function I am trying to break up into sines/cosines. So I resorted to Fast Fourier Transformation. By using the fft(y,inverse=FALSE) function I was able to convert the time domain of the sound into the frequency doman. The output is complex. I read that in order to convert this output which is in imaginary form and weed out the necessary information, which are the amplitude and the phase of A(v)cos(2*pi*v+P), one must use the abs() of the output to get the amplitude; however I am having difficulty finding the R function that gets us the phase. In MATLAB, the angle() function returns the phases of the FFT. What is the respective function in R to find the phase??
Update
Thank you for the suggestions guys; still expericieng an issue. I am running FFT on a simple function to test to see if it works. My function is y=cos(2*pi*(seq(0,10,by=.01)*(1/5)+7.5).
So the frequency is 1/5 with a phase shift of 7.5.
y=cos(2*pi*(seq(0,10,by=.01)*(1/5)+7.5)
fty=(y,inverse=F)
plot(abs(fty),xlim=c(0,10),type="l")
angle=atan2(Im(fty), Re(fty))
> angle[3]
[1] 1.222766
When I plot the series, the amplitude is peaking at a frequency value of 3 and the angle function (which should give me my phase at the frequency at which amplitude peaks at) is giving me a phase of 1.2. What am I doing wrong?
You might find that the atan2 function does what you want. You would give it the imaginary and real parts of the value, since the prototype is atan2(y, x). So you could do:
angle = atan2(Im(value), Re(value));
I'm trying to find the best number of nearest neighbor to use in mahalanobis method in yai function offered by yaImpute package (1.0-19). I tried to run the yai function with 'mal' method with different number of k:
mal<-yai(x=x,y=y,method="mahalanobis", k=5, noTrgs= FALSE, nVec=NULL, pVal=.05, ann=F)
mal<-yai(x=x,y=y,method="mahalanobis", k=20, noTrgs= FALSE, nVec=NULL, pVal=.05, ann=F)
But, when I'm looking the rmsd (root mean square distance) of each, there are exactly the same. The process found effectively the number of k that I asked (when I print the 'mal' object), but it seems like it does not use them.
My aim is to use AsciiGridImpute function to impute values on my entire map. But I don't understand what is the utility of the k number in my yai object. How the AscciGridImpute use them?
Thank you
Sorry for my bad english!!
I finally found why the RMSD was the same whatever the number of k used in the yai object.
The function rmsd.yai called automatically an other function call impute.yai. That function is supposed to allow methods as mean or dstWeighted to compute the imputed values for continuous variables. The use of these methods changed effectively the rmsd values depending on the number of k.
But the automatically call of this function (impute.yai) compute imputed values with the default method:closest. So only one k is used.
I think it's the same thing that happen with the function AsciiGridImpute.
Hey there,
I have a mathematical function (multidimensional which means that there's an index which I pass to the C++-function on which single mathematical function I want to return. E.g. let's say I have a mathematical function like that:
f = Vector(x^2*y^2 / y^2 / x^2*z^2)
I would implement it like that:
double myFunc(int function_index)
{
switch(function_index)
{
case 1:
return PNT[0]*PNT[0]*PNT[1]*PNT[1];
case 2:
return PNT[1]*PNT[1];
case 3:
return PNT[2]*PNT[2]*PNT[1]*PNT[1];
}
}
whereas PNT is defined globally like that: double PNT[ NUM_COORDINATES ]. Now I want to implement the derivatives of each function for each coordinate thus generating the derivative matrix (columns = coordinates; rows = single functions). I wrote my kernel already which works so far and which call's myFunc().
The Problem is: For calculating the derivative of the mathematical sub-function i concerning coordinate j, I would use in sequential mode (on CPUs e.g.) the following code (whereas this is simplified because usually you would decrease h until you reach a certain precision of your derivative):
f0 = myFunc(i);
PNT[ j ] += h;
derivative = (myFunc(j)-f0)/h;
PNT[ j ] -= h;
now as I want to do this on the GPU in parallel, the problem is coming up: What to do with PNT? As I have to increase certain coordinates by h, calculate the value and than decrease it again, there's a problem coming up: How to do it without 'disturbing' the other threads? I can't modify PNT because other threads need the 'original' point to modify their own coordinate.
The second idea I had was to save one modified point for each thread but I discarded this idea quite fast because when using some thousand threads in parallel, this is a quite bad and probably slow (perhaps not realizable at all because of memory limits) idea.
'FINAL' SOLUTION
So how I do it currently is the following, which adds the value 'add' on runtime (without storing it somewhere) via preprocessor macro to the coordinate identified by coord_index.
#define X(n) ((coordinate_index == n) ? (PNT[n]+add) : PNT[n])
__device__ double myFunc(int function_index, int coordinate_index, double add)
{
//*// Example: f[i] = x[i]^3
return (X(function_index)*X(function_index)*X(function_index));
// */
}
That works quite nicely and fast. When using a derivative matrix with 10000 functions and 10000 coordinates, it just takes like 0.5seks. PNT is defined either globally or as constant memory like __constant__ double PNT[ NUM_COORDINATES ];, depending on the preprocessor variable USE_CONST.
The line return (X(function_index)*X(function_index)*X(function_index)); is just an example where every sub-function looks the same scheme, mathematically spoken:
f = Vector(x0^3 / x1^3 / ... / xN^3)
NOW THE BIG PROBLEM ARISES:
myFunc is a mathematical function which the user should be able to implement as he likes to. E.g. he could also implement the following mathematical function:
f = Vector(x0^2*x1^2*...*xN^2 / x0^2*x1^2*...*xN^2 / ... / x0^2*x1^2*...*xN^2)
thus every function looking the same. You as a programmer should only code once and not depending on the implemented mathematical function. So when the above function is being implemented in C++, it looks like the following:
__device__ double myFunc(int function_index, int coordinate_index, double add)
{
double ret = 1.0;
for(int i = 0; i < NUM_COORDINATES; i++)
ret *= X(i)*X(i);
return ret;
}
And now the memory accesses are very 'weird' and bad for performance issues because each thread needs access to each element of PNT twice. Surely, in such a case where each function looks the same, I could rewrite the complete algorithm which surrounds the calls to myFunc, but as I stated already: I don't want to code depending on the user-implemented function myFunc...
Could anybody come up with an idea how to solve this problem??
Thanks!
Rewinding back to the beginning and starting with a clean sheet, it seems you want to be able to do two things
compute an arbitrary scalar valued
function over an input array
approximate the partial derivative of an arbitrary scalar
valued function over the input array
using first order accurate finite differencing
While the function is scalar valued and arbitrary, it seems that there are, in fact, two clear forms which this function can take:
A scalar valued function with scalar arguments
A scalar valued function with vector arguments
You appeared to have started with the first type of function and have put together code to deal with computing both the function and the approximate derivative, and are now wrestling with the problem of how to deal with the second case using the same code.
If this is a reasonable summary of the problem, then please indicate so in a comment and I will continue to expand it with some code samples and concepts. If it isn't, I will delete it in a few days.
In comments, I have been trying to suggest that conflating the first type of function with the second is not a good approach. The requirements for correctness in parallel execution, and the best way of extracting parallelism and performance on the GPU are very different. You would be better served by treating both types of functions separately in two different code frameworks with different usage models. When a given mathematical expression needs to be implemented, the "user" should make a basic classification as to whether that expression is like the model of the first type of function, or the second. The act of classification is what drives algorithmic selection in your code. This type of "classification by algorithm" is almost universal in well designed libraries - you can find it in C++ template libraries like Boost and the STL, and you can find it in legacy Fortran codes like the BLAS.