I'm trying to rewrite a legacy Visual Basic app into a web app, and I've been going through the math of it and I've come across an oddity that I can't quite figure out:
return (x) * 1 / y
Now, from what I'm reading, the way this should execute is (x * 1) / y or rather x / y but that 1 is confusing me. If I were putting that 1 there I'd only do so if I was implying:
return x * (1 / y)
So, am I reading into this too much and assuming the 1 is there unnecessarily or is it actually an important part of the function?
Related
Is there a betther way to do this condition:
if ( x > 3 || y > 3 || z > 3 ) {
...
}
I was thinking of some bitwise operation but could'nt find anything.
I searched over Google but it is hard to find something related to that kind of basic question.
Thanks!
Edit
I was thinkg in general programming. Would it be different according to a specific language? Such as C/C++, Java...
What you have is good. Assuming C/C++ or Java:
Intent is clear
Short circuit optimisation means the expression will be true as soon as any one part is true.
Looking at that 2nd point- if any of x, y or z is more likely to be >3, then put them to the left of the expression so they are evaluated first which means the others may not need to be evaluated at all.
For argument's sake, if you must have a bitwise check x|y|z > 3 works, but it normally won't be reduced, so it's (probably*) always 2 bitwise ops and a compare, where the other way could be as fast as 1 compare.
(* This is where the language lawyers arrive an add comments why this edit is wrong and the bitwise version can be optimised;-)
There was a comment here (now deleted) along the lines of "new programmer shouldn't worry about this level of optimisation" - and it was 100% correct. Write easy to follow, working code and THEN try to squeeze performance out of it AFTER you know it is "too slow".
While using Xcode, I accidentally auto completed to the macro howmany(x,y) and traced it to types.h. The entire line reads as follows:
#define howmany(x, y) __DARWIN_howmany(x, y) /* # y's == x bits? */
This didn't really make much sense, so I followed the path a little more and found __DARWIN_howmany(x, y) in _fd_def.h. The entire line reads as follows:
#define __DARWIN_howmany(x, y) ((((x) % (y)) == 0) ? ((x) / (y)) : (((x) / (y)) + 1)) /* # y's == x bits? */
I have no idea what __DARWIN_howmany(x, y) does. Does the comment at the end of the line shed any light on the intended function of this macro? Could someone please explain what this macro does, how it is used, and its relevance in _fd_def.h
This is a fairly commonly used macro to help programmers quickly answer the question, if I have some number of things, and my containers can each hold y of them, how many containers do I need to hold x things?
So if your containers can hold five things each, and you have 18 of them:
n = howmany(18, 5);
will tell you that you will need four containers. Or, if my buffers are allocated in words, but I need to put n characters into them, and words are 8 characters long, then:
n = howmanu(n, 8);
returns the number of words needed. This sort of computation is ubiquitous in buffer allocation code.
This is frequently computed:
#define howmany(x, y) (((x)+(y)-1)/(y))
Also related is roundup(x, y), which rounds x up to the next multiple of y:
#define roundup(x, y) (howmany(x, y)*(y))
Based on what you've posted, the macro seems to be intended to answer a question like, "How many chars does it take to hold 18 bits?" That question could be answered with this line of code
int count = howmany( 18, CHAR_BIT );
which will set count to 3.
The macro works by first checking if y divides evenly into x. If so, it returns x/y, otherwise it divides x by y and rounds up.
I am trying to solve the following equation in my program:
7.7^2 x 0.012^2/(0.2145 x 1.67^(16/3))
That should equal : 0.002582 (this is verified w/ google & scientific calculator)
This is the code that I am using
CGFloat eX1 = pow(7.7, 2) * pow(0.012, 2)/(0.2145 * pow(1.67, (16/3)));
NSLog(#"%f",eX1);
And even though, I believe my code should give me the same results, it's actually giving me:0.002679
What am I doing wrong? What can I do to obtain the correct answer?
Change (16/3) to (16.0/3.0). Otherwise 16/3 results in 5, not 5.33333349.
And you have 7.2 instead of 7.7 at the start.
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.
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))