I have found quite a lot of answer about rounding decimals, however I need to sort out a simple formula for LibreOffice Calc that allows me to draw up estimates ending to the nearest 7 so for example if the quote is 1372 it should be rounded down to 1367 while if it is 1375 becomes 1377 what would be a really simply formula that does not involve coding or macros?
As for now the solution I found is this one:
=(ROUND(I25/10)+0,7)*10
The problem with this is that does not round to the nearest 7 but to 7 so for example 362,00 becomes 367,00 and not 357,00 as intended.
Edit: this resolve the issue above, hope this helps:
=(ROUND((I25-10)/10)+0,7)*10
Removing 10 from the total I25 due to the ROUND function will correct the result, so for example 362 becomes 35,2 rounded to 35 + 0.7 we get 35.7 and finally 357 as intended. While for upper values, say 365 rounding 35.5 gives us 36 + 0.7 we get 367,00 again to nearest 7 units as intended!
You could use the default ROUND() function while "shifting" the values by 3:
=ROUND(A1+3;-1)-3
This gives the following results:
In other words: add your offset "3" to the initial value, ROUND() it to the nearest multiple of ten, and subtract the offset again.
But this will round 1372 to 1377, since it's a "shifted" 1375 which will round up to 1380 (see Matthew Strawbridge's comment to the question).
Related
In the code below, snapshot should be 0 if TrimCY = TrimBYS.
df <- df %>%
mutate(snapshot = case_when(Trend_direction != 2 ~ (TrimCY-TrimBYS)*sign(Trend_direction)*10/abs(Target_Snap-TrimBYS),
TRUE ~ 10-((abs(TrimCY-Target_Snap)*10)/abs(Target_Snap-TrimBYS))))
When I execute this code on the data displayed below, this is not always the case. See snapshot values.
Trend_direction Target_Snap TrimCY TrimBYS snapshot
1 56 53 53 0.000000e+00
1 56 54 54 -3.552714e-14
1 56 55 55 -7.105427e-14
Does anyone know why I am getting these very small non-zero results? When I copy the arithmetic function into the console and execute using the values above, it always comes out to 0.
These are floating point errors. To get the basic idea of what's going on, work out 1 - 1/3 - 1/3 - 1/3 = ? on a piece of paper, but only work to 3 decimal places. The equation looks like 1 - 0.333 - 0.333 - 0.333 = 0.001. Even though it should be zero, it's not. The computer is basically doing this, but to lots more decimal places and in binary.
For a more detailed explanation there are lots of resources around: for example: https://floating-point-gui.de/
You can get around it by rounding the answer, or (as akrun suggests) setting your options so these numbers display as zero.
This is why it's good practice to never test for x == 0 when x has been subject to these sorts of floating point calculations, and always do something like abs(x) < 1e-10 instead.
I have, let's say, 60 empirical realizations of PPR. My goal is to create PPR vector with average values of empirical PPR. This average values depend on what upper and lower limit of TTM i take - so I can take TTM from 60 to 1 and calculate average and in PPR vector put this one average number from row 1 to 60 or I can calculate average value of PPR from TTT >= 60 and TTM <= 30 and TTM > 30 and TTM <= 1 and these two calculated numbers put in my vector accordingly to TTM values. Finaly I want to obtain something like this on chart (x-axis is TTM, green line is my empirical PPR and black line is average based on significant changes during TTM). I want to write an algorithm which will help me find the best TTM thresholds to fit the best black line to green line.
TTM PPR
60 0,20%
59 0,16%
58 0,33%
57 0,58%
56 0,41%
...
10 1,15%
9 0,96%
8 0,88%
7 0,32%
6 0,16%
Can you please help me if you know any statistical method which might be applicable in this case or base idea for an algorithm which I could implement in VBA/R ?
I have used Solver and GRG Nonlinear** to deal with it but I believe that there is something more proper to be utilized.
** with Solver I had the problem that it found optimal solution - ok, but I re-run Solver and it found me new solution (with a little bit different values of TTM) and value of target function was lower that on first time (so, was the first solution really optimal ?)
I think this is what you want. The next step would be including a method that can recognize the break points. I am sure you need to define two new parameters, one as the sensitivity and one as the minimum number of points in a sample to be accepted to be categorized as a section (between two break points including start and end point)
Please hit the checkmark next to this answer if you are happy with it.
You can download the Excel file from here:
http://www.filedropper.com/statisticspatternchange
This question already has answers here:
Round up from .5
(7 answers)
Closed 6 years ago.
It seems there is an error in round function. Below I would expect it to return 6, but it returns 5.
round(5.5)
# 5
Other then 5.5, such as 6.5, 4.5 returns 7, 5 as we expect.
Any explanation?
This behaviour is explained in the help file of the ?round function:
Note that for rounding off a 5, the IEC 60559 standard is expected to
be used, ‘go to the even digit’. Therefore round(0.5) is 0 and
round(-1.5) is -2. However, this is dependent on OS services and on
representation error (since e.g. 0.15 is not represented exactly, the
rounding rule applies to the represented number and not to the printed
number, and so round(0.15, 1) could be either 0.1 or 0.2).
round( .5 + 0:10 )
#### [1] 0 2 2 4 4 6 6 8 8 10 10
Another relevant email exchange by Greg Snow: R: round(1.5) = round(2.5) = 2?:
The logic behind the round to even rule is that we are trying to
represent an underlying continuous value and if x comes from a truly
continuous distribution, then the probability that x==2.5 is 0 and the
2.5 was probably already rounded once from any values between 2.45 and 2.54999999999999..., if we use the round up on 0.5 rule that we learned in grade school, then the double rounding means that values
between 2.45 and 2.50 will all round to 3 (having been rounded first
to 2.5). This will tend to bias estimates upwards. To remove the
bias we need to either go back to before the rounding to 2.5 (which is
often impossible to impractical), or just round up half the time and
round down half the time (or better would be to round proportional to
how likely we are to see values below or above 2.5 rounded to 2.5, but
that will be close to 50/50 for most underlying distributions). The
stochastic approach would be to have the round function randomly
choose which way to round, but deterministic types are not
comforatable with that, so "round to even" was chosen (round to odd
should work about the same) as a consistent rule that rounds up and
down about 50/50.
If you are dealing with data where 2.5 is likely to represent an exact
value (money for example), then you may do better by multiplying all
values by 10 or 100 and working in integers, then converting back only
for the final printing. Note that 2.50000001 rounds to 3, so if you
keep more digits of accuracy until the final printing, then rounding
will go in the expected direction, or you can add 0.000000001 (or
other small number) to your values just before rounding, but that can
bias your estimates upwards.
When I was in college, a professor of Numerical Analysis told us that the way you describe for rounding numbers is the correct one. You shouldn't always round up the number (integer).5, because it is equally distant from the (integer) and the (integer + 1). In order to minimize the error of the sum (or the error of the average, or whatever), half of those situations should be rounded up and the other half should be rounded down. The R programmers seem to share the same opinion as my professor of Numerical Analysis...
I'm trying to add up two 8 bit numbers which one is negative and second one is positive. Here it is what I do:
92-113
so I represent each number as binary
92 - 01011100
113 - 01110001
after changing 0 to 1 and 1 to 0 I get :
10001110 and after adding 1 I have 1000111 which is -113
then I'm adding them up and I get :
11101011
what totally makes no sense, what I probably do wrongly ? Would really love to know where I make mistake as it's really basic knowledge ;/
You're not missing anything - 11101011 is the binary equivalent of -21 (92-113) in 8-bit signed binary.
For singed integer types, the left=most bit determine if the number is positive or negative. To get the additive inverse, you flip all bits but the rightmost. It;s the same process you used to convert 113 to -113.
Doing that yields 00010101 which is 21. So 11101011 is -21.
I need to do this assignment. I just don't know how it works. The question is.
Modify the function roll() from the lecture in a way that it simulates a single n-sided die where the side with the highest number shows up twice as often as all other sides. Functions you may find useful are ?, c(), min(), max(), length(), sort() and rep().
And the function goes.
roll <- function( num = 1:6, rolls = 1) {
dice <- sample(num, size = rolls, replace = TRUE)
return(dice)
}
I'm pretty sure that i have to use the 'prob'-parameters in the sample-Function but i don't know how.
You can do it without the prob argument by thinking about what kind of fairly-weighted (all faces equally probable) die would give the results you want.
sample(1:6, 1) gives you a single sample from an unbiased six-sided die. What you seem to want in this instance is equivalent to a seven-sided die with two sixes. Which would be...
sample(c(1:6,6),1)
That's an equal change of 1 to 5, and double the chance of a 6.
> table(sample(c(1:6,6),7000,replace=TRUE))
1 2 3 4 5 6
972 1018 1016 980 1018 1996
Its not clear to me whether "the highest number shows up twice as often as all other sides" means "all the other sides put together". In which case you want to sample from a 10-sided die with 1 to 5 plus 5 sixes:
sample(c(1:5, rep(6,5)),1)
That's an equal chance of either getting 1 to 5 OR 6.
> table(sample(c(1:5, rep(6,5)),10000,replace=TRUE))
1 2 3 4 5 6
1012 961 943 1018 1026 5040
Generalise to N and write your function.
You are right, the prob-Parameter is useful here (eventhough you could do without).
Here are the steps you have to complete:
Find out which of the entries in num is largest (dont assume that it is the last)
You need the index (="position") of that entry.
Calculate which probability each entry except the largest one would have. Example: If n=6 then each prob is 1/7 with the exception of the last which has 2/7.
Make a vector containing these probabilities in the right positions. You already know the position of the largest, so you would put the doubled prob in that position.
Give the prob to sample().
Test! Run it many times to find out if the largest is really approx. double as often.