Excel provides a function for determining the left-tailed inverse of the Student's t-distribution.
T.INV(probability,deg_freedom)
If I needed the right-tailed inverse, can someone confirm if these are valid statistical operations (both lead to the same answer)
T.INV(1-probability,deg_freedom)
ABS(T.INV(probability,deg_freedom))
Thanks!
Your first formula is valid. The second is not. Consider asking for the right-tailed inverse of p = .75. That should be a negative number, which the second formula can't be because of the ABS.
Related
I am trying to recreate numbers which I easily calculated in excel and now I would like to have calculated in Power BI. To be more precise I would like to have it in power query/M and NOT in DAX due to later calculations.
To be more specific I would like to calculate the coefficients a and b of an exponential equation exponential y=ae^(bx).
In the following picture, you can see the data and also a graph over the data. Furthermore, the graph also displays a trendline using an exponential function and above the equation is shown y=6,5408e^(0,2834x).
These coefficients are calculated in cell b14 and b15 and the calculations are shown in d14 and d15 (my excel is set to Danish, the English version of a is calculated using ex(index(linest(ln( and b by index(linest(ln( ).
As you can see, to calculate the coefficients, a column with index have been created in column c.
To calculate the coefficients I used the LN() function on a list/array in excel, and the only power query/M function I can find is Number.Ln(), however, it does note take a list as input.
Due to the lack of on LN function in power query/M, I have a hard time calculating this, and I really hope someone has an answer to this!
Thank you in advance !
Kind Regards, Louise
Number.Ln()
Returns the natural logarithm of a number, number. If number is null Number.Ln returns null.
https://learn.microsoft.com/en-us/powerquery-m/number-ln
Also check out
https://www.bookkempt.com/2017/10/simple-linear-regression-in-power-query.html
When running the XIRR function "=XIRR(G163:G168,F163:F168)" where the cashflow is in G163:G168 and my dates are in F163:F168, excel is returning a value of .000000298023% which is definitely not correct. Any advise would be greatly appreciated!
9/13/2019 (2,137,500.00)
9/13/2019 (1,710,000.00)
9/13/2019 (35,331,814.80)
9/13/2019 (931,950.00)
9/13/2019 (14,990,988.60)
9/30/2020 45,757,426.80
The technique that Excel uses can return multiple values, depending on the initial assumption of rate. Since you left it unspecified, it assumes 10%.
If you add -10% as the optional guess argument, it will return 16.23%.
There are a couple of ways to come up with a reasonable guess if XIRR is giving a wrong answer, but here's one:
Negative 10% for negative values: 0.1*sign(sum(values))
The answer submitted by Ron Rosenfeld is accurate but there are more, subtle details I think are worth pointing out.
The 0.000000298023 value the asker identified as "definitely not correct" is a well known erroneous value produced by the Excel XIRR function. However, it is more commonly referred to as 2.98023E-09.
With reference to the official documentation, Jon Coleman commented that the first value is treated specially. This is a property of the concept more than Excel's implementation of the XIRR function; the first value usually represents something like a starting balance, which is also why the documentation says that value must be negative.
The last value usually represents a final balance and will have the oppposite sign of the first value. This is also a property of the concept, not the implementation.
Technically, the actual signs used don't matter but they must be used consistently throughout: one sign for inflows, the other sign for outflows. By convention, inflows are negative and outflows are positive.
The XIRR function sometimes has trouble with out-of-order values, though I don't have details on this.
Besides the first and last values, the XIRR function seems to handle multiple cash flows on the same date. Summing by date may still be beneficial for execution time (I don't know) but it will definitely be correct according to the equation.
In this instance, Excel can apparently be pointed in the right direction with a guess value of -10%. However, it follows from point #2 that splitting the "first" cash flow into multiple cash flows on the same day hinder's Excel's XIRR function. Indeed, with the dataset
2019-09-13 -55,102,253.40
2020-09-30 45,757,426.80
Excel's XIRR function determines the expected -16.23% without supplying a manual guess.
See also: Microsoft Community support question.
I am calculating the geometric mean of a row in MS Excel by using the GEOMEAN(...) command.
What is the geometric mean: The row could be A1:A10. A geometric mean with
GEOMEAN(A1:A10)
is the product of all 10 cell values (multiplied together) after which the 10th root is taken (mathematically: nth_root(A_1 x A_2 x ... x A_n) ).
The issue: The command GEOMEAN(A1:A10) works fine as long as no cells contain negative values (actually just as long as the product ends up positive). If one cell has a negative value, then taking the root is mathematically an invalid action and Excel gives an error.
The solution: I can work-around this by adding a large enough number such as +1000000 to each value before doing GEOMEAN(A1:A10) and afterwards subtracting -1000000 from the result. This is a mathematical approximation to the pure geometrical mean.
The question: But how do I add +1000000 to each value in Excel? A solution would be to create a whole new extra row where the number is added, and then doing GEOMEAN on this row and subtracting the number from the result. But I would really like to avoid creating a new row, since I have many long data sets to perform this command on.
Is there a way to add the number inside the command itself? To add it onto each value before it is multiplied? Something along the lines of:
GEOMEAN(A1:A10+1000000)-1000000
Solution to avoid the work-around
Based on the answer from and discussion with #ImaginaryHuman072889
It turns out that a working command that avoids any work-around is:
IFERROR(GEOMEAN(A1:A10);-GEOMEAN(ABS(A1:A10)))
If an error are cought by the IFERROR, then we know that a negative result would have appeared, so this is constructed manually in that case.
BUT: This does not take into account the case mentioned by #ImaginaryHuman072889, though, because Excel seems to forbid any negative numbers involved and not just if the inner product is negative. For example, both GEOMEAN(-2,-2) as well as GEOMEAN(-2,-2,-2) give errors in Excel, even though they both should be mathematically valid, giving the results 2 and -2, respectively. To overcome this Excel-issue, we can simply write out the exact same command line manually:
IFERROR(PRODUCT(A1:A10)^(1/COUNTA(A1:A10));-(PRODUCT(ABS(A1:A10))^(1/COUNTA(A1:A10)))))
I add this solution to aid any by-comers who have the same issue. This mathematically works, but the fact that -2 and -2 have the geometrical mean 2 does seem a bit odd and not at all like any useful value of a "mean". It is still mathematically legal as far as I can find (WolframAlpha has no issue with it and the Wikipedia article never mentions a sign).
Your "workaround" of doing this:
GEOMEAN(A1:A10+1000000)-1000000
Is completely wrong. This is absolutely not equal to GEOMEAN(A1:A10).
Simple counter-example:
GEOMEAN({2,8}) returns the value of 4, which is the geometric mean of 2 and 8.
GEOMEAN({2,8}+1)-1 is equal to GEOMEAN({3,9})-1 which is approximately 4.196.
What is a valid workaround is if you multiply each value inside GEOMEAN by a certain value, then divide the result by that value.
Simple example:
GEOMEAN({2,8}*3)/3 is equal to GEOMEAN({6,24})/3 which is 4.
However, this method of multiplying by a constant does not help your situation, since this won't get rid of negative values.
Mathematically speaking, the geometric mean of a positive number and a negative number is an imaginary number, which is presumably why Excel cannot handle it.
Example:
2*-8 = -16
sqrt(-16) = 4i
Therefore, 4i is the geometric mean of 2 and -8. Notice how it has the same magnitude as GEOMEAN({2,8}), just that it is an imaginary number.
All that said... here is what I recommend you doing:
I suggest you return two results, one result is the magnitude of the geometric mean and the other is the phase of the geometric mean.
Formula for magnitude:
= GEOMEAN(ABS(A1:A10))
(Note, this is an array formula, so you'd have to press Ctrl+Shift+Enter instead of just Enter after typing this formula.) The use of ABS converts all negative numbers to positive before the GEOMEAN calculation, guaranteeing a positive geometric mean.
Formula for phase, I would just do something like this:
= IF(PRODUCT(A1:A10)>=0,"Real","Imaginary")
Which obviously returns Real if the geometric mean is a real number and returns Imaginary if the geometric mean is an imaginary number.
EDIT
Technically speaking, some of what I said wasn't completely precise, although the magnitude formula above still stands.
Some things I want to clarify:
If PRODUCT(data) is positive (or zero), then the geometric mean of data is positive (or zero).
If PRODUCT(data) is negative and if the number of entries in data is odd, then the geometric mean of data is negative (but still real).
If PRODUCT(data) is negative and if the number of entries in data is even, then the geometric mean of data is imaginary.
That said... if you want these formulas to be a bit more technically accurate, I would modify to this:
Adjusted formula for magnitude:
= GEOMEAN(ABS(A1:A10))*IF(AND(PRODUCT(A1:A10)<0,MOD(COUNT(A1:A10),2)=1),-1,1)
Adjusted formula for phase:
= IF(AND(PRODUCT(A1:A10)<0,MOD(COUNT(A1:A10),2)=0),"Imaginary","Real")
If the geometric mean is real, it returns the precise geometric mean (whether it is positive or negative), and if the geometric mean is imaginary, it returns a positive real value with the correct magnitude.
So, I just found the answer - although I have no idea why this works.
Doing GEOMEAN(A1:A10+1000000)-1000000 is actually possible. But by pressing enter and error #VALUE is displayed. You must click control+shift+enter to have the actual result displayed.
According to this: https://www.mrexcel.com/forum/excel-questions/264366-calculating-geometric-mean-some-negative-values.html
If anyone has an explanation for this, I am very interested.
Is it possible to use Microsoft Excel's RAND() or RANDBETWEEN() to obtain specific range of values between say 0.5 and 0.9?
I know RAND() returns random numbers between 0 and 0.999999, but I would like to avoid values under 0.5 and all negative numbers.
I'm guessing it's something obvious but can't put my finger on it.
Do the whole numbers then divide by the number of decimal places
=RANDBETWEEN(5,9)/10
So if you really want .5000 and .9999 then you would use:
=RANDBETWEEN(5000,9999)/10000
Take the result of RAND(), multiply by the range (0.9 - 0.5) and add the lowest number in the range (0.5). Altogether,
=(0.9-0.5)*RAND()+0.5
Comparing this answer to Scott's, this implementation's domain is all the numbers between the ranges out to maximum precision. But Scott's answer allows you to specify the exact precision you want. Either is a good option, choose which one suits your needs best.
How can I generate those numbers in Excel.
I have to generate 8 random numbers whose sum is always 320. I need around 100 sets or so.
http://en.wikipedia.org/wiki/User:Skinnerd/Simplex_Point_Picking. Two methods are explained here.
Or any other way so I can do it in Excel.
You could use the RAND() function to generate N numbers (8 in your case) in column A.
Then, in column B you could use the following formula B1=A1/SUM(A:A)*320, B2=A2/SUM(A:A)*320 and so on (where 320 is the sum that you are interested into).
So you can just enter =RAND() in A1, then drag it down to A8. Then enter =A1/SUM(A:A)*320 in B1 and drag it to B8. B1:B8 now contains 8 random numbers that sum up to 320.
Sample output:
I'm a bit late to the game here - but fyi if only integers required then:
=LET(x_,RANDARRAY(8,1,1,1000000,1),y_,ROUND(x_*320/SUM(x_),0),y_)
is somewhat similar to the favourite soln above, albeit parsimonious (formula in single cell required to produce desired array , no helper column). Also addresses insignificant decimal points, albeit you may need to allocate back the deficit / surplus due to the occasional rounding error which may yield a sum total of 321 or 319. Could do this in a random fashion again using something like index(y_,randbetween(1,8))+320-sum(y_) in formula above - or resort to the infamous helper fn..
Someone commented the favourite soln above (and thus mine, since it stems from a similar concept/approach) is not uniform - I'm not sure this was required; a uniform spread would impede the random nature (and is arguably far simpler as you simply divide a sizeable range into distinct octiles, and follow the same approach already laid out here - not sure where/why the notion that a random spread should be arbitrarily/mechanically 'forced' to adopting some type of non-random spread.. anyways... I obviously haven't read the problem properly (ehem).
I'm a bit late to the game here - but fyi if only integers required then:
=LET(x_,RANDARRAY(8,1,1,1000000,1),y_,ROUND(x_*320/SUM(x_),0),y_)
is somewhat similar to the favourite soln above, albeit parsimonious (formula in single cell required to produce desired array , no helper column). Also addresses insignificant decimal points, albeit you may need to allocate back the deficit / surplus due to the occasional rounding error which may yield a sum total of 321 or 319. Could do this in a random fashion again using something like index(y_,randbetween(1,8))+320-sum(y_) in formula above - or resort to the infamous helper fn..