I finally got the formula for the distance from a curve to a point running:
approx = 2 * (b * (Math.Log(a) * (Math.Log(k) * Math.Pow(k, (b * cycleX))) * Math.Pow(a, (Math.Pow(k, (b * cycleX)))) * (Math.Pow(a, (Math.Pow(k, (b * cycleX))))) - points[i].Y) + cycleX - points[i].X);
So, as approx goes closer to 0, the cycleX gives me the right coordinate from which to calculate the distance to the point.
The only issue here is defining a way to modify cycleX. I tried using a series of if's, but with them sometimes approx ends up jumping on to positive numbers (coming from negatives). What should I do to get the right modification to the value of cycleX?
Note: It usually needs to come down to 0.0001 to get something within the range of -1 to 1.
For this kind of problem, it's often useful to know about Newton's method:
Of course, the forumula for that is
Of course, besides the fact that for some functions this quite unstable (I don't expect yours to be, though), implemented purely for your case, it would mean you would need to calculate yet another derivative (of your derivative)! However, I think for your case, you might be able to just approximate the derivative.
You didn't mention the language your implementation would eventually be in, so I'll just use javascript for convenience.
To estimate your derivative, simply choose a deltaX that would be convenient.
So if you have a function
var df = function (cycleX) {
return 2 * (b * (Math.log(a) * (Math.log(k) * Math.pow(k, (b * cycleX))) * Math.pow(a, (Math.pow(k, (b * cycleX)))) * (Math.pow(a, (Math.pow(k, (b * cycleX))))) - Y) + cycleX - X);
};
you can estimate it's derivative via
y = df(cycleX);
y1 = (df(cycleX + deltaX) - y) / deltaX;
And then proceed via.
cycleXnew = cycleX - y / y1;
And then it's just a matter of looping until it converges (or not).
See example jsFiddle: http://jsfiddle.net/jfcox/3wRtj/
Edit: I give no guarantees as to how fast it might converge or even how well an estimated derivative would work with respect to Newton's method. For the parameters I've tried given your function f(x) = a^(k^(bx)), it seems to work well, but I haven't tried much.
Edit II. Of course, the above jsFiddle also assumes only a single solution that we'd need to search for.
Related
println(log(it.toDouble(), 10.0).toInt()+1) // n1
println(log10(it.toDouble()).toInt() + 1) // n2
I had to count the "length" of the number in n-base for non-related to the question needs and stumbled upon a bug (or rather unexpected behavior) that for it == 1000 these two functions give different results.
n1(1000) = 3,
n2(1000) = 4.
Checking values before conversion to int resulted in:
n1_double(1000) = 3.9999999999999996,
n2_double(1000) = 4.0
I understand that some floating point arithmetics magic is involved, but what is especially weird to me is that for 100, 10000 and other inputs that I checked n1 == n2.
What is special about it == 1000? How I ensure that log gives me the intended result (4, not 3.99..), because right now I can't even figure out what cases I need to double-check, since it is not just powers of 10, it is 1000 (and probably some other numbers) specifically.
I looked into implementation of log() and log10() and log is implemented as
if (base <= 0.0 || base == 1.0) return Double.NaN
return nativeMath.log(x) / nativeMath.log(base) //log() here is a natural logarithm
while log10 is implemented as
return nativeMath.log10(x)
I suspect this division in the first case is the reason of an error, but I can't figure out why it causes an error only in specific cases.
I also found this question:
Python math.log and math.log10 giving different results
But I already know that one is more precise than another. However there is no analogy for log10 for some base n, so I'm curious of reason WHY it is specifically 1000 that goes wrong.
PS: I understand there are methods of calculating length of a number without fp arithmetics and log of n-base, but at this point it is a scientific curiosity.
but I can't figure out why it causes an error only in specific cases.
return nativeMath.log(x) / nativeMath.log(base)
//log() here is a natural logarithm
Consider x = 1000 and nativeMath.log(x). The natural logarithm is not exactly representable. It is near
6.90775527898213_681... (Double answer)
6.90775527898213_705... (closer answer)
Consider base = 10 and nativeMath.log(base). The natural logarithm is not exactly representable. It is near
2.302585092994045_901... (Double)
2.302585092994045_684... (closer answer)
The only exactly correct nativeMath.log(x) for a finite x is when x == 1.0.
The quotient of the division of 6.90775527898213681... / 2.302585092994045901... is not exactly representable. It is near 2.9999999999999995559...
The conversion of the quotient to text is not exact.
So we have 4 computation errors with the system giving us a close (rounded) result instead at each step.
Sometimes these rounding errors cancel out in a way we find acceptable and the value of "3.0" is reported. Sometimes not.
Performed with higher precision math, it is easy to see log(1000) was less than a higher precision answer and that log(10) was more. These 2 round-off errors in the opposite direction for a / contributed to the quotient being extra off (low) - by 1 ULP than hoped.
When log(x, 10) is computed for other x = power-of-10, and the log(x) is slightly more than than a higher precision answer, I'd expect the quotient to less often result in a 1 ULP error. Perhaps it will be 50/50 for all powers-of-10.
log10(x) is designed to compute the logarithm in a different fashion, exploiting that the base is 10.0 and certainly exact for powers-of-10.
I am working on developing an efficient iterative code to compute mn. After some thinking and googling I found this code;
public static int power(int n, int m)
// Efficiently calculates m to the power of n iteratively
{
int pow=m, acc=1, count=n;
while(count!=0)
{
if(count%2==1)
acc=acc*pow;
pow=pow*pow;
count=count/2;
}
return acc;
}
This logic makes sense to me except the fact that why are we squaring value of pow towards the end each time. I am familiar with similar recursive approach, but this squaring is not looking very intuitive to me. Can I kindly get some help her? An example with explanation will be really helpful.
The accumulator is being squared each iteration because count (which is the inverse cumulative power) is being halved each iteration.
If the count is odd, the accumulator is multiplied by the number. This algorithm relies on integer arithmetic, which discards the fractional part of a division, effectively further decrementing by 1 when the count is odd.
This is a very tricky solution to understand. I am solving this problem in leetcode and have found the iterative solution. I have spent a whole day to understand this beautiful iterative solution. The main problem is this iterative solution does not work as like its recursive solution.
Let's pick an example to demonstrate. But first I have to re-write your code by replacing some variable name as the name in your given code is very confusing.
// Find m^n
public static int power(int n, int m)
{
int pow=n, result=1, base=m;
while(pow > 0)
{
if(pow%2 == 1) result = result * base;
base = base * base;
pow = pow/2;
}
return result;
}
Let's understand the beauty step by step.
Let say, base = 2 and power = 10.
Calculation
Description
2^10= (2*2)^5 = 4^5
even
We have changed the base to 4 and power to 5. So it is now enough to find 4^5. [base multiplied with itself and power is half
4^5= 4*(4)^4 = 4^5
odd
We separate single 4 which is the base for current iteration. We store the base to result variable. We will now find the value of 4^4 and then multiply with the result variable.
4^4= (4*4)^2 = 16^2
even
We change the base to 16 and power to 2. It is now enough to find 16^2
16^2= (16*16)^1 = 256^1
even
We change the base to 256 and power to 1. It is now enough to find 256^1
256^1 = 256 * 256^0
odd
We separate single 256 which is the base for current iteration. This value comes from evaluation of 4^4.So, we have to multiply it with our previous result variable. And continue evaluating the rest value of 256^0.
256^0
zero
Power 0. So stop the iteration.
So, after translating the process in pseudo code it will be similar to this,
If power is even:
base = base * base
power /= 2
If power is odd:
result = result * base
power -= 1
Now, let have another observation. It is observed that floor(5 / 2) and (5-1) / 2 is same.
So, for odd power, we can directly set power / 2 instead of power -= 1. So, the pseudo code will be like the below,
if power is both odd or even:
base = base * base
power /= 2
If power is odd:
result = result * base
I hope you got the behind the scene.
I've been doing research on trying to understand the way sounds and sine waves work, particularly with chords. So far, my understanding is as follows:
b(t) = sin(Api(t)) is the base note of the chord at frequency A.
T(t) = sin(5/4piA(t)) is the major third of the base b(t).
D(t) = sin(3/2piA(t)) is the dominant (fifth) of the base b(t).
A(t) = sin(2Api(t)) is the octave.
Each one alone is a separate frequency which is easy for a computer generator to sound. However, the major chord of the note with frequency A is as follows:
Major Chord = b+T+D+A
I was wondering if anyone has a way to make a computer synthesizer play this function so I can hear the result; most programs I have found only take Hz as an input, an while this function has a wavelength, it's different from the simple sine wave with the same wavelength.
Note: will post this in the physics and computer sections as well - just wondering if you musicians know something about this.
It's a bit unclear to me what you're trying to do, so I'm explaining a few things, and giving you a few options to investigate further, depending on what your purpose is.
The de facto means of synthesizing music on computers uses MIDI (Musical Instrument Digital Interface). Because musicians rarely think directly in terms of frequencies or wavelengths (they count steps or half-steps along a scale), MIDI represents each pitch with an integer, that represents a number of half-steps. By default, MIDI assumes these pitches are tuned using a standard called "12-Tone Equal Temperament" (12TET), and, unfortunately, it isn't particularly easy to make it use other tunings.
What does this mean? And why is it a problem? (I'm not sure how much of this you know already, so I apologize if I'm repeating what you know)
In theory what you say about tuning being based on frequency ratios is 100% absolutely correct -- this is a system called Just Tuning. The major third is a 5/4 ratio and the perfect fifth is a 3/2 ratio. However instruments with fixed-pitches (keyboards, fretted instruments, etc...) are rarely tuned that way in practice. Instead, they compromise, by rounding each note in a chromatic scale to the nearest 12th of an octave. Since an adding octave is equivalent to multiplying the initial frequency by 2, adding a 12th of an octave is the equivalent of multiplying the initial frequency by 2^(1/12). This is how all the half steps on a piano are usually tuned.
So instead of the pure ratios, you would actually have:
sin(A pi t)
sin(2^(4/12) A pi t)
sin(2^(7/12) A pi t)
sin(2^(12/12) A pi t)
Note: Compare 2^(4/12) ~ 1.26, with 5/4 = 1.25. Also compare 2^(7/12) ~ 1.498, with 3/2 = 1.5.
These are exactly the frequencies that any MIDI synthesizer will play, given the MIDI notes numbered n, n+4, n+7, and n+12. So, if you are only looking to play a chord, and don't care about the frequency ratios being pure (just), you can just use MIDI.
However, if you are looking for something that will play the actual just ratios, it will be a bit trickier. You might start with looking at some of the things here: https://music.stackexchange.com/questions/351/software-that-allows-playing-in-different-temperaments
If you just want to see what they sound like, you can check out this youtube video:
https://www.youtube.com/watch?v=6NlI4No3s0M
If you can write software, you might try writing your own, but I don't want to go into how to do that if that's not going to be helpful.
I'm not sure what kinds of programs you're describing that "only takes Hz as input". Is this a software library (like an API call?) or something different? There are (obviously) API calls that can send more complex data to the soundcard than a single-frequency wave.
EDIT: I've not used it, but it looks like perhaps this software is capable of doing what you want: https://www.youtube.com/watch?v=z0NZQMiDdNU
I think you are going at the problem from a wrong direction. You are using sinoid signals as the basis of your "chords" and pure intervals.
The output of that is strictly periodic, with a period that is the least common multiple of the individual periods. So basically you have not as much a "chord" but rather a "tone".
Organs use that technique: you can combine an 8" pipe with a 5⅓" pipe in order to arrive at a tone sounding like it came from some funny 16" pipe. That's not a "chord", that's registration. Classical composition theory does not allow quint parallels to avoid that effect: quints must only occur transitorily and more often than not moving in a different direction or out of synch with the base note.
"chords" play with aural ambiguities between tone colors and voices: they excite the same region in your inner ear. However, real "chords" and choral effects also have beatings and interferences from non-ideal frequency ratios, and the tones they are made of have harmonics of their own, making it possible to discern them as independent entities.
The experienced music listener perceives all that as an independent phenomenon. However, if you start with pure sinoids or highly frequency-locked comparatively pure sources like snare-less organ pipes, this becomes hard to do.
So I'm not sure you are doing yourself a favor by looking at sinoids. It's like trying to understand a painting based on primary color components. It's more of a reproduction toolkit than anything tied to higher-level perception.
A very low-barrier way to play is to use wavepot
The code to do what you ask in your question is
var A = 440
export function dsp(t) {
var b = Math.sin(t * Math.PI * 2 * A);
var T = Math.sin(t * Math.PI * 2 * 5/4 * A);
var D = Math.sin(t * Math.PI * 2 * 3/2 * A);
var O = Math.sin(t * Math.PI * 2 * 2 * A);
return (b + T + D+ O) * 1/4
}
which is at this link.
Note that this might not sound much like a chord to you due to the fact that sine waves have no harmonics. Here is the same example, but using a saw-tooth waveform, which has many harmonics.
var A = 440
//function f(x){return Math.sin(x) }
function f(x){return 2 * ( (x/(2*Math.PI) % 1) -.5) } //sawtooth
export function dsp(t) {
var b = f(t * Math.PI * 2 * A);
var T = f(t * Math.PI * 2 * 5/4 * A);
var D = f(t * Math.PI * 2 * 3/2 * A);
var O = f(t * Math.PI * 2 * 2 * A);
return (b + T + D+ O) * 1/4
}
For a program I'm writing, I need to be able to trace a virtual line (that is not straight) that an object must travel along. I was thinking to use NSBezierPath to draw the line, but I cannot find a way to get any point along the line, which I must do so I can move the object along it.
Can anyone suggest a way to find a point along an NSBezierPath? If thats not possible, can anyone suggest a method to do the above?
EDIT: The below code is still accurate, but there are much faster ways to calculate it. See Introduction to Fast Bezier and Even Faster Bezier.
There are two ways to approach this. If you just need to move something along the line, use a CAKeyframeAnimation. This is pretty straightforward and you never need to calculate the points.
If on the other hand you actually need to know the point for some reason, you have to calculate the Bézier yourself. For an example, you can pull the sample code for Chapter 18 from iOS 5 Programming Pushing the Limits. (It is written for iOS, but it applies equally to Mac.) Look in CurvyTextView.m.
Given control points P0_ through P3_, and an offset between 0 and 1 (see below), pointForOffset: will give you the point along the path:
static double Bezier(double t, double P0, double P1, double P2,
double P3) {
return
pow(1-t, 3) * P0
+ 3 * pow(1-t, 2) * t * P1
+ 3 * (1-t) * pow(t, 2) * P2
+ pow(t, 3) * P3;
}
- (CGPoint)pointForOffset:(double)t {
double x = Bezier(t, P0_.x, P1_.x, P2_.x, P3_.x);
double y = Bezier(t, P0_.y, P1_.y, P2_.y, P3_.y);
return CGPointMake(x, y);
}
NOTE: This code violates one of my cardinal rules of always using accessors rather than accessing ivars directly. It's because in it's called many thousands of times, and eliminating the method call has a significant performance impact.
"Offset" is not a trivial thing to work out. It does not proceed linearly along the curve. If you need evenly spaced points along the curve, you'll need to calculate the correct offset for each point. This is done with this routine:
// Simplistic routine to find the offset along Bezier that is
// aDistance away from aPoint. anOffset is the offset used to
// generate aPoint, and saves us the trouble of recalculating it
// This routine just walks forward until it finds a point at least
// aDistance away. Good optimizations here would reduce the number
// of guesses, but this is tricky since if we go too far out, the
// curve might loop back on leading to incorrect results. Tuning
// kStep is good start.
- (double)offsetAtDistance:(double)aDistance
fromPoint:(CGPoint)aPoint
offset:(double)anOffset {
const double kStep = 0.001; // 0.0001 - 0.001 work well
double newDistance = 0;
double newOffset = anOffset + kStep;
while (newDistance <= aDistance && newOffset < 1.0) {
newOffset += kStep;
newDistance = Distance(aPoint,
[self pointForOffset:newOffset]);
}
return newOffset;
}
I leave Distance() as an exercise for the reader, but it's in the example code of course.
The referenced code also provides BezierPrime() and angleForOffset: if you need those. Chapter 18 of iOS:PTL covers this in more detail as part of a discussion on how to draw text along an arbitrary path.
In optimising some code recently, we ended up performing what I think is a "type" of memoisation but I'm not sure we should be calling it that. The pseudo-code below is not the actual algorithm (since we have little need for factorials in our application, and posting said code is a firing offence) but it should be adequate for explaining my question. This was the original:
def factorial (n):
if n == 1 return 1
return n * factorial (n-1)
Simple enough, but we added fixed points so that large numbers of calculations could be avoided for larger numbers, something like:
def factorial (n):
if n == 1 return 1
if n == 10 return 3628800
if n == 20 return 2432902008176640000
if n == 30 return 265252859812191058636308480000000
if n == 40 return 815915283247897734345611269596115894272000000000
# And so on.
return n * factorial (n-1)
This, of course, meant that 12! was calculated as 12 * 11 * 3628800 rather than the less efficient 12 * 11 * 10 * 9 * 8 * 7 * 6 * 5 * 4 * 3 * 2 * 1.
But I'm wondering whether we should be calling this memoisation since that seems to be defined as remembering past results of calculations and using them. This is more about hard-coding calculations (not remembering) and using that information.
Is there a proper name for this process or can we claim that memoisation extends back not just to calculations done at run-time but also those done at compile-time and even back to those done in my head before I even start writing the code?
I'd call it pre-calculation rather than memoization. You're not really remembering any of the calculations you've done in the process of calculating a final answer for a given input, rather you're pre-calculating some fixed number of answers for specific inputs. Memoization as I understand it is really more akin to "caching" a set of results as you calculate them for later reuse. If you were to store each value calculated so that you didn't need to recalculate it again later, that would be memoization. Your solution differs in that you never store any "calculated" results from your program, only the fixed points that have been pre-calculated. With memoization if you reran the function with an input different than one of the pre-calculated ones it would not have to recalculate the result, it would simply reuse it.
Whether or not you are hard coding the results in, this is still memoization because you have already calculated results that you are expecting to calculate again. Now this may come in the form of run-time, or compile time.. but either way, it's memoization.
Memoization is done at run-time. You are optimizing at compile time. So, it is not.
See for example ... Wikipedia
Or ...
Memoization
The term memoization was coined by Donald Michie (1968) to refer to the process by which a function is made to automatically remember the results of previous computations. The idea has become more popular in recent years with the rise of functional languages; Field and Harrison (1988) devote a whole chapter to it. The basic idea is just to keep a table of previously computed input/result pairs.
Peter Norvig
University of California
(the bold is mine)
Link
def memoisation(f):
dct = {}
def myfunction(x):
if x not in dct:
dct[x] = f(x)
return dct[x]
return myfunction
#memoisation
def fibonacci(n):
if n == 0:
return 0
elif n == 1:
return 1
else:
return fibonacci(n-1) + fibonacci(n-2)
def nb_appels(n):
if n==0 or n==1:
return 0
else:
return 1 + nb_appels(n-1) + 1 + nb_appels(n-2)
print(fibonacci(13))
print ('nbappel',nb_appels(13))