Regarding reporting services 2005:
I want to sum the field of a measure. If I sum 0.234 + 0.441 and format the sum to 2 digits after the point it will give 0.7. Because I format in the same way the field itself it shows 0.2+0.4=0.7.
It says I have to do the sum by adding the rounded field each time.
The only way I found to round a number to a few digits after the number is by format/FormatNumber and the reporting services doesn't accept format(sum(format(number))-is there another function?
The Math.Round function should do what you need, give it the number to round and no of decimal places you want (2 here I think), and returns a double (or decimal etc depending on what was passed in).
Then sum the rounded values.
Related
I have a double value (9999999999999.99) and trying to store the same into elastic search document (type double and tried scaled_float as well). But, on the Elasticsearch document the same value being shown as 9.99999999999999E12.
Could some one please educate me to resolve this issue
It seems that you don't actually have a problem, let me explain:
9999999999999.99 is a normal representation of a floating point value (float, double etc.)
9.99999999999999E12 is another representation of the same value. E meaning Exponent.
Exponent is the same as multiplying by 10 to the power of the exponent value, in this case 12 so 10**12 == 1000000000000.
9.99999999999999 * 1000000000000 == 9999999999999.99
Further explanation:
If you move the decimal point twelve digits to the right, you'll get the same number 9999999999999.99, and that's what the exponent is used for.
Also the exponent can be negative, in which case you'd move the decimal point to the left.
I'm having difficulty storing and displaying numbers greater than 32767 in LC-3 since a register can only hold values from -32768 to 32767. My apology for not being able to come up with any idea for the algorithm. Please give me some suggestion. Thanks!
You'll need a representation to store the larger number in a pair or more of words.
There are several approaches to how big integers are stored: in a fixed number of words, and in a variable number of words or bytes. The critical part is being able to detect the presence and amount of overflow/carry on mathematical operations like *10.
For that reason, one simple approach is to use a variable number of words/bytes (for a single number), and store only one decimal digit in each of the words/bytes. That way multiplication by 10, means simply adding a digit on the end (which has the effect of moving each existing digit to the next higher power of ten position). Adding numbers of this form numbers is fairly easy as well, we need to line up the digits and then, we add them up and detect when the sum is >= 10, then there is a carry (of 1) to be added to the next higher order digit of the sum. (If adding two such (variable length) numbers is desired, I would store the decimal digits in reverse order, because then the low order numbers are already lined up for addition.) See also https://en.wikipedia.org/wiki/Binary-coded_decimal . (In some sense, this is like storing numbers in a form like string, but using binary values instead of ascii characters.)
To simplify this approach for your needs, you can fix the number of words to use, e.g. at 7, for 7 digits.
A variation on (unpacked) Binary-coded Decimal to pack them two decimal digits per byte. Its a bit more complicated but saves some storage.
Another approach is to store as many decimal digits as will fit full in a word, minus 1. Which is to say if we can store 65536 in 16-bits that's only 4 full decimal digits, which means putting 3 digits at a time into a word. You'd need 3 words for 9 digits. Multiplication by 10 means multiplying each word by 10 numerically, and then checking for larger than 999, and if larger, then carry the 1 to the next higher order word while also subtracting 10,000 from the overflowing word.
This approach will require actual multiplication and division by 10 on each of the individual words.
There are other approaches, such as using all 16-bits in a word as magnitude, but the difficulty there is determining the amount of overflow/carry on *10 operations. It is not a monumental task but will require work. See https://stackoverflow.com/a/1815371/471129, for example.
(If you also want to store negative numbers, that is also an issue for representation. We can either store the sign as separately known as sign-magnitude form (as in stored its own word/byte or packed into the highest byte) or store the number in a compliment form. The former is better for variable length implementations and the latter can be made to work for fixed length implementations.)
Is there a way to force RATIO_TO_REPORT for generating rounded ratios to two cents? Sometimes if you manually round cents you will not receive the exact number of the sum of the records you based the ratio to report column and this is causing me a big issue in accounting reports in my company.
Please advice.
There's nothing that works out of the box, no. You're going to have to build your own procedure to allocate any differences in pennies.
The way my company does it is by the following algorithm:
Round values using your rounding method of choice, and compute the difference between the original value and the rounded value (this will always be less than a penny)
Sum the rounded values. Find the difference between the new sum and the "goal" sum. If the difference is positive (the new sum is higher), you need to remove pennies. If the difference is negative, you need to add pennies.
Since you (presumably) want to minimize differences between the unrounded and rounded values, depending on whether the difference between the new sum and the goal sum is positive or negative:
a. Give whole pennies to the rounded values with the largest difference between unrounded and rounded values, until your sum matches the goal sum
b. Take away whole pennies from the rounded values with the smallest difference between unrounded and rounded values, until your sum matches the goal sum
I'm trying to make this algorithm which inputs a lower and upper limit for two numbers (the two numbers may have different lower and upper limits) and outputs two random numbers within that range
The catch is however that when the two numbers are added, no "carry" should be there. This means the sum of the digits in each place should be no more than 9.
How can I make sure that the numbers are truly random and that no carrying occurs when adding the two numbers
Thanks a lot!
Edit: The ranges can vary, the widest range can be 0 to 999. Also, I'm using VBA (Excel)
An easy and distributionally correct way of doing this is to use Rejection Sampling, a.k.a. "Acceptance/Rejection". Generate the values independently, and if the carry constraint is violated repeat. In pseudocode
do {
generate x, y
} while (x + y > threshold)
The number of times the loop will iterate has a geometric distribution with an expected value of (proportion of sums below the threshold)-1. For example, if you're below the threshold 90% of the time then the long term number of iterations will average out to 10/9, 1.11... iterations per pair generated. For lower likelihoods of acceptance, it will take more attempts on average.
I have to generate two random sets of matrices
Each containing 3 digit numbers ranging from 2 - 10
like that
matrix 1: 994,878,129,121
matrix 2: 272,794,378,212
the numbers in both matrices have to be greater then 100 and less then 999
BUT
the mean for both matrices has to be in the ratio of 1:2 or 2:3 what ever constraint the user inputs
my math skills are kind of limited so any ideas how do i make this happen?
In order to do this, you have to know how many numbers are in each list. I'm assuming from your example that there are four numbers in each.
Fill the first list with four random numbers.
Calculate the mean of the first list.
Multiply the mean by 2 or by 3/2, whichever the user input. This is the required mean of the second list.
Multiply by 4. This is the required total of the second list.
Generate 3 random numbers.
Subtract the total of the three numbers in step 5 from the total in step 4. This is the fourth number for the second list.
If the number in step 6 is not in the correct range, start over from step 5.
Note that the last number in the second list is not truly random, since it's based on the other values in the list.
You have a set of random numbers, s1.
s1= [ random.randint(100,999) for i in range(n) ]
For some other set, s2, to have a different mean it's simply got to have a different range. Either you select values randomly from a different range, or you filter random values to get a different range.
No matter how many random numbers you select from the range 100 to 999, the mean is always just about 550. The odds of being a different value are exactly the normal distribution probabilities on either side of the mean.
You can't have a radically different mean with values selected from the same range.