R Incorrectly Returning Infinity - r

In R I am trying to convert some values to the power -0.5. Some of my values are 0, and they return Inf when I do this. Why is that the case? Unless I'm having some obvious lapse in math knowledge, 0 to the power of anything is still 0, which is what I'm expecting.
My values are in the 1000's range, and they return proper results (i.e. 1000^(-0.5) = 0.031)
Am I doing something obviously wrong? Is there something special I need to do in R? Here's a sample of my code:
DF[grep(".SUFFIX", names(henn))] <- DF[grep(".SUFFIX", names(DF))]^(-0.5)
The code works fine btw for other functions, like if I did + 10
Thanks in advance!

You're getting Infinity because raising 0 to a negative power results in dividing by 0:
0 ^ (-0.5) =
1 / (0^(0.5)) =
1 / 0 = Infinity

I figured out the answer. 0 to any positive power is 0, 0 to any negative power is undefined (dividing by 0). It makes sense.

Related

Does runif() really have a range: 0<= runif(n) <= 1, as stated in the documentation?

I'm new to R, but the documentation surprised me by stating that runif(n) returns a number in the range 0 to 1 inclusive.
I would expect 0 <= runif(n) < 1 -- including 0 and not including 1.
I tested it with n = 100,000,000, and found that it never produced 0 or 1. I realize that the probability of actually hitting specific values in floating point is really small, but still... (There are something like 2^53 values between 0 and 1 in double precision).
So I looked into the source code for R and found in r-source-trunk\src\nmath\runif.c
do
{
u = unif_rand();
} while (u <= 0 || u >= 1);
return a + (b - a) * u;
So by design, despite the documentation, it will never ever return a 0 or 1.
Isn't this a bug?
Or at least a problem with the documentation?
The underlying uniform random number function is defined here and the final outputs use this function:
static double fixup(double x)
{
/* ensure 0 and 1 are never returned */
if(x <= 0.0) return 0.5*i2_32m1;
if((1.0 - x) <= 0.0) return 1.0 - 0.5*i2_32m1;
return x;
}
Despite this, there are comments of the form /* in [0,1) */ for each of the generator's return functions, which I assume is a mistake given the above.
And of course, the code you noticed in runif.c is preceded by:
/* This is true of all builtin generators, but protect against
user-supplied ones */
So the min or max will never be returned except in the cases mentioned by #JesseTweedle, which is not the case when just calling runif().
For reference, the magic value i2_32m1 is 1/(2^32-1) so the minimum value you can get from the default generators is 1/(2^33-2) which is approximately 1.16e-10. The maximum value is this amount short of 1.
The documentation says:
runif will not generate either of the extreme values unless max = min
or max-min is small compared to min, and in particular not for the
default arguments.
With default arguments, the documentation is consistent with the behaviour you see.

Simple subtraction in Verilog

I've been working on a hex calculator for a while, but seem to be stuck on the subtraction portion, particularly when B>A. I'm trying to simply subtract two positive integers and display the result. It works fine for A>B and A=B. So far I'm able use two 7-segment displays to show the integers to be subtracted and I get the proper difference as long as A>=B
When B>A I see a pattern that I'm not able to debug because of my limited knowledge in Verilog case/if-else statements. Forgive me if I'm not explaining the best way but what I'm observing is that once the first number, A, "reaches" 0 (after being subtracted from) it loops back to F. The remainder of B is then subtracted from F rather than 0.
For example: If A=1, B=3
A - B =
1 - 1 = 0
0 - 1 = F
F - 1 = E
Another example could be 4-8=C
Below are the important snippets of code I've put together thus far.
First, my subtraction statement
always#*
begin
begin
Cout1 = 7'b1000000; //0
end
case(PrintDifference[3:0])
4'b0000 : Cout0 = 7'b1000000; //0
4'b0001 : Cout0 = 7'b1111001; //1
...
4'b1110 : Cout0 = 7'b0000110; //E
4'b1111 : Cout0 = 7'b0001110; //F
endcase
end
My subtraction is pretty straightforward
output [4:0]Difference;
output [4:0] PrintDifference;
assign PrintDifference = A-B;
I was thinking I could just do something like
if A>=B, Difference = B-A
else, Difference = A-B
Thank you everyone in advance!
This is expected behaviour of twos complement addition / subtraction which I would recommend reading up on since it is so essential.
The result obtained can be changed back into an unsigned form by inverting all the bits and adding one. Checking the most significant bit will tell you if the number is negative or not.

Number of Zero-crossings - Equation

I have written an algorithm that calculates the number of zero-crossings within a signal. By this, I mean the number of times a value changes from + to - and vice-versa.
The algorithm is explained like this:
If there are the following elements:
v1 = {90, -4, -3, 1, 3}
Then you multiply the value by the value next to it. (i * i+1)
Then taking the sign value sign(val) determine if this is positive or negative. Example:
e1 = {90 * -4} = -360 -> sigum(e1) = -1
e2 = {-4 * -3} = 12 -> signum(e2) = 1
e3 = {-3 * 1} = -3 -> signum(e3) = -1
e4 = {1 * 3} = 3 -> signum(e4) = 1
Therefore the total number of values changed from negative to positive is = 2 ..
Now I want to put this forumular, algorithm into an equation so that I can present it.
I have asked a simular question, but got really confused so went away and thought about it and came up with (what I think the equation should look like).. It's probably wrong, well, laughably wrong. But here it is:
Now the logic behind it:
I pass in a V (val)
I get the absolute value of the summation of the signum from calculating (Vi * Vi+1) .. The signum(Vi * Vi+1) should produce -1, 1, ..., values
If and only if the value is -1 (Because I'm only interested in the number of times zero is crossed, therefore, the zero values.
Does this look correct, if not, can anyone suggest improvements?
Thank you :)!
EDIT:
Is this correct now?
You are doing the right thing here but your equation is wrong simply because you only want to count the sign of the product of adjacent elements when it is negative. Dont sum the sign of products since positive sign products should be neglected. For this reason, an explicit mathematical formula is tricky as positive products between adjacent elements should be ignored. What you want is a function that takes 2 arguments and evaluates to 1 when their product is negative and zero when non-negative
f(x,y) = 1 if xy < 0
= 0 otherwise
then your number of crossing points is simply given by
sum(f(v1[i],v1[i+1])) for i = 0 to i = n-1
where n is the length of your vector/array v1 (using C style array access notation based on zero indexing). You also have to consider edge conditions such as 4 consecutive points {-1,0,0,1} - do you want to consider this as simply one zero crossing or 2??? Only you can answer this based on the specifics of your problem, but whatever your answer adjust your algorithm accordingly.

Why is 0 divided by 0 an error?

I have come across this problem in a calculation I do in my code, where the divisor is 0 if the divident is 0 too. In my code I return 0 for that case. I am wondering, while division by zero is generally undefined, why not make an exception for this case? My understanding why division by zero is undefined is basically that it cannot be reversed. However, I do not see this problem in the case 0/0.
EDIT OK, so this question spawned a lot of discussion. I made the mistake of over-eagerly accepting an answer based on the fact that it received a lot of votes. I now accepted AakashM's answer, because it provides an idea on how to analyze the problem.
Let's say:
0/0 = x
Now, rearranging the equation (multiplying both sides by 0) gives:
x * 0 = 0
Now do you see the problem? There are an infinite number of values for x as anything multiplied by 0 is 0.
This is maths rather than programming, but briefly:
It's in some sense justifiable to assign a 'value' of positive-infinity to some-strictly-positive-quantity / 0, because the limit is well-defined
However, the limit of x / y as x and y both tend to zero depends on the path they take. For example, lim (x -> 0) 2x / x is clearly 2, whereas lim (x -> 0) x / 5x is clearly 1/5. The mathematical definition of a limit requires that it is the same whatever path is followed to the limit.
(Was inspired by Tony Breyal's rather good answer to post one of my own)
Zero is a tricky and subtle beast - it does not conform to the usual laws of algebra as we know them.
Zero divided by any number (except zero itself) is zero. Put more mathematically:
0/n = 0 for all non-zero numbers n.
You get into the tricky realms when you try to divide by zero itself. It's not true that a number divided by 0 is always undefined. It depends on the problem. I'm going to give you an example from calculus where the number 0/0 is defined.
Say we have two functions, f(x) and g(x). If you take their quotient, f(x)/g(x), you get another function. Let's call this h(x).
You can also take limits of functions. For example, the limit of a function f(x) as x goes to 2 is the value that the function gets closest to as it takes on x's that approach 2. We would write this limit as:
lim{x->2} f(x)
This is a pretty intuitive notion. Just draw a graph of your function, and move your pencil along it. As the x values approach 2, see where the function goes.
Now for our example. Let:
f(x) = 2x - 2
g(x) = x - 1
and consider their quotient:
h(x) = f(x)/g(x)
What if we want the lim{x->1} h(x)? There are theorems that say that
lim{x->1} h(x) = lim{x->1} f(x) / g(x)
= (lim{x->1} f(x)) / (lim{x->1} g(x))
= (lim{x->1} 2x-2) / (lim{x->1} x-1)
=~ [2*(1) - 2] / [(1) - 1] # informally speaking...
= 0 / 0
(!!!)
So we now have:
lim{x->1} h(x) = 0/0
But I can employ another theorem, called l'Hopital's rule, that tells me that this limit is also equal to 2. So in this case, 0/0 = 2 (didn't I tell you it was a strange beast?)
Here's another bit of weirdness with 0. Let's say that 0/0 followed that old algebraic rule that anything divided by itself is 1. Then you can do the following proof:
We're given that:
0/0 = 1
Now multiply both sides by any number n.
n * (0/0) = n * 1
Simplify both sides:
(n*0)/0 = n
(0/0) = n
Again, use the assumption that 0/0 = 1:
1 = n
So we just proved that all other numbers n are equal to 1! So 0/0 can't be equal to 1.
walks on back to her home over at mathoverflow.com
Here's a full explanation:
http://en.wikipedia.org/wiki/Division_by_zero
( Including the proof that 1 = 2 :-) )
You normally deal with this in programming by using an if statement to get the desired behaviour for your application.
The problem is with the denominator. The numerator is effectively irrelevant.
10 / n
10 / 1 = 10
10 / 0.1 = 100
10 / 0.001 = 1,000
10 / 0.0001 = 10,000
Therefore: 10 / 0 = infinity (in the limit as n reaches 0)
The Pattern is that as n gets smaller, the results gets bigger. At n = 0, the result is infinity, which is a unstable or non-fixed point. You can't write infinity down as a number, because it isn't, it's a concept of an ever increasing number.
Otherwise, you could think of it mathematically using the laws on logarithms and thus take division out of the equation altogther:
log(0/0) = log(0) - log(0)
BUT
log(0) = -infinity
Again, the problem is the the result is undefined because it's a concept and not a numerical number you can input.
Having said all this, if you're interested in how to turn an indeterminate form into a determinate form, look up l'Hopital's rule, which effectively says:
f(x) / g(x) = f'(x) / g'(x)
assuming the limit exists, and therefore you can get a result which is a fixed point instead of a unstable point.
Hope that helps a little,
Tony Breyal
P.S. using the rules of logs is often a good computational way to get around the problems of performing operations which result in numbers which are so infinitesimal small that given the precision of a machine’s floating point values, is indistinguishable from zero. Practical programming example is 'maximum likelihood' which generally has to make use of logs in order to keep solutions stable
Look at division in reverse: if a/b = c then c*b = a. Now, if you substitute a=b=0, you end up with c*0 = 0. But ANYTHING multiplied by zero equals zero, so the result can be anything at all. You would like 0/0 to be 0, someone else might like it to be 1 (for example, the limiting value of sin(x)/x is 1 when x approaches 0). So the best solution is to leave it undefined and report an error.
You may want to look at Dr. James Anderson's work on Transarithmetic. It isn't widely accepted.
Transarithmetic introduces the term/number 'Nullity' to take the value of 0/0, which James likens to the introduction 'i' and 'j'.
The structure of modern math is set by mathematicians who think in terms of axioms.
Having additional axioms that aren't productive and don't really allow one to do more stuff is against the ideal of having clear math.
How many times does 0 go into 0? 5. Yes - 5 * 0 = 0, 11. Yes - 11 * 0 = 0, 43. Yes - 43 * 0 = 0. Perhaps you can see why it's undefined now? :)
Since x/y=z should be equivalent to x=yz, and any z would satisfy 0=0z, how useful would such an 'exception' be?
Another explanation of why 0/0 is undefined is that you could write:
0/0 = (4 - 4)/0 = 4/0 - 4/0
And 4/0 is undefined.
If a/b = c, then a = b * c.
In the case of a=0 and b=0, c can be anything because 0 * c = 0 will be true for all possible values of c. Therefore, 0/0 is undefined.
This is only a Logical answer not a mathamatical one,
imagine Zero as empty how can you Divide an empty by an empty this is the case in division by zero also how can you divide by something which is empty.
0 means nothing, so if you have nothing, it does not imply towards anything to distribute to anything. Some Transit Facilities when they list out the number of trips of a particular line, trip number 0 is usually the special route that is routed in a different way. Typically, a good example would be in the Torrance Transit Systems where Line 2 has a trip before the first trip known as trip number 0 that operates on weekdays only, that trip in particular is trip number 0 because it is a specialized route that is routed differently from all the other routes.
See the following web pages for details:
http://transit.torrnet.com/PDF/Line-2_MAP.pdf
http://transit.torrnet.com/PDF/Line-2_Time_PDF.pdf
On the map, trip number 0 is the trip that is mapped in dotted line, the solid line maps the regular routing.
Sometimes 0 can be used on numbering the trips a route takes where it is considered the "Express Service" route.
why not make an exception for this
case?
Because:
as others said, it's not that easy;)
there's no application for defining 0/0 - adding exception would complicate mathematics for no gains.
This is what I'd do:
function div(a, b) {
if(b === 0 && a !== 0) {
return undefined;
}
if(b === 0 && a === 0) {
return Math.random;
}
return a/b;
}
When you type in zero divided by zero, there's an error because whatever you multiply zero from will be zero so it could be any number.
As Andrzej Doyle said:
Anything dived by zero is infinity. 0/0 is also infinity. You can't get 0/0 = 1. That's the basic principle of maths. That's how the whole world goes round. But you can sure edit a program to say "0/0 is not possible" or "Cannot divide by zero" as they say in cell phones.

get number between 0 and 1 from number between 0 and n

How can I calculate values between 0 and 1 from values between 0 and n. E.g. I have items with "click count" and want to get "importance" (a float between 0 and 1) from that.
My attempt: importance = 1-1/count
gives bad results, since the values don't distribute well…
I'm not sure what you mean by "don't distribute well". If you want to normalize a value between 0 and n to between 0 and 1, just divide by n.
Also not sure what you mean...
If you are looking for a linear distribution between 0 and 1, you need to know the maximum value of n. This will be transformed to 1.
importance = thisCount / maxCount;
just divide by n
How about count/n?

Resources