I'm trying to calculate an unweighted average given a data for averages and counts, and I can't figure out why my Total calculation is throwing #Error.
Preliminary aggregation for this report (aggregation by color) is done within the dataset's query, but drilldown functionality has been requested for this report, and as far as I know that requires totaling to be done on the Report Builder side. That requires calculating the total aggregate from a list of subtotal aggregates.
=Sum(Fields!weightedAveragePercent.Value * Fields!weight.Value) / Sum(Fields!weight.Value) gets me what I need for the total row, which is the aggregate weighted average percent for the category. In light of that, I'd expect that =Sum(Fields!averagePercent.Value * Fields!count.Value) / Sum(Fields!count.Value) would behave similarly. However, when the averagePercent field is blank (representing a NULL value passed over from the SQL query underlying the report) the calculation for the total averagePercent returns #Error.
Color
count
weight
weightedAveragePercent
averagePercent
Red
14
$10.10
3.702%
2.500%
Blue
25
$5.38
5.016%
7.181%
Brown
0
$0.00
Total
39
$15.48
4.544%
#Error
Things I've checked:
=Sum(Fields!averagePercent.Value) and =Sum(Fields!count.Value) both return the expected values. =Sum(Fields!averagePercent.Value * Fields!count.Value) returns #Error.
=Sum(Iif(IsNumeric(Fields!averagePercent.Value), 1, 0)) returns the expected value (2, in this case) but =Sum(Iif(IsNumeric(Fields!averagePercent.Value), Fields!averagePercent.Value, 0)) returns #Error. This is not resolved by changing 0 to 0.000, or by wrapping IsNumeric() in Not().
Pushing =Fields!averagePercent.Value * Fields!count.Value into a calculated column still throws #Error.
Data Types:
count: int
weight: float
weightedAveragePercent: float
averagePercent: float
Related
I am trying to create a measure that would count the instances when another measure is between given values.
The first is a measure of forecast accuracy, which is calculated over products and customers with a target value of 1. Then I would like to make a monthly report which shows for how many products the forecast accuracy is less than .85, between 0.85 and 1.15 and over 1.15.
The measure I tried for the middle category, which does not give the desired result:
var tab = SUMMARIZE(data, data[ComponentNumber], "Accuracy", [Forecast accuracy])
return SUMX(tab, IF([Accuracy] > 0.85 && [Accuracy] < 1.15, 1, 0))
The data table has also a customer number, which is why I tried first evaluating the measure [Forecast accuracy] only over components, disregarding the customers.
One source of the problem may lie in the fact that the measure [Forecast accuracy] is calculated as a division of two measures [Ordered Quantity] and [Forecast Quantity], of which the former is in another table. Does this affect the evaluation of my attempted measure?
I have transactions in a variety of currencies in a Transaction table (columns TransactionAmount and TransactionCurrency), and also a related Currency table:
Using the column RateToEuro I have been able to convert all my transaction amounts, using a calculate column, into euros:
An example of what I would like: I want to select in my report filter 'Dollar' and then the Transaction amount should convert all original transaction amounts to dollars. So in my example above, the $2052 original trx amount will be 2052 also in the 'Transaction amount ($)' column.
[EDIT:]
Currently I have created measure that gets the filter value:
CurrencyFilter = IF(LASTNONBLANK('CurrencyFormat'[Name], 1) = "USD", "USD", "EUR")
And a calculated column that for each transaction calculates the converted transaction amount (depending on the report filter chosen):
TransactionAmountConverted = CALCULATE(VALUES(Transactions[TransactionAmount]) * (IF([CurrencyFilter] = "EUR", VALUES('Currency'[RateToEuro]), VALUES('Currency'[RateToDollar]))))
But for some reason the IF statement always returns TRUE (i.e. always uses the RateToEuro column).
Any hint or tip to point me in the right direction would be much appreciated!
Currently this is not possible in Power BI: it is not supported that a calculated column uses a slicer value.
A measure can be used to get the slicer value, but in this particular case (if one value for each row is required to be calculated), there is no solution possible unfortunately.
I have a bar chart with X axis as discrete date value and Y axis as number of records.
eg: x axis (Filtered Date)- 1st Oct, 2nd Oct, 3rd Oct etc
y axis (Number of Records)- 30, 4, 3 etc
Now, I have to create a table to get Max, Min and Avg. Value of the 'Number of Record'.
I have written a Calculated Field as MAX([Number of Records]) to get the maximum of Number of Records in this case 30 but I always get a value of 1.
How do I define the values to get max, min and avg. ?
Thanks,
Number of Records is an automatically calculated field that tableau generates when importing a datasource. You can right click on it and see the definition of the calculation: 1.
As you currently have your field defined, tableau will look for the maximum value of the column. It will always be 1 because that is the only value in that field for every record.
It sounds like you are actually trying to calculate the maxiuum of the sum of the number of records for your aggregation level (in your case date). You should be able to easily accomplish this using Level of Detail (LOD) expressions, or table calculations. Something like the following:
WINDOW_MAX(SUM([Number of Records]))
I have database where i am calculating the shipping cost. The logic of shipping cost is such way that it is calculated every 500gm. I have price list according to different weight but when i am using calculation taking the weight from user for example 1.4 i am unable to get it to next calculative weight of 1.5 , .7 to 1.0 , 1.7 to 2.0 how to achieve this?
Try this (substitute myNumber to get a different result):
Let (
[
myNumber=2.6;
myNumberInt = INT(myNumber);
myNumberFr = myNumber - myNumberInt;
myNumberFr = Case ( myNumberFr =0;0;myNumberFr >0.5 ; 1;0.5 );
result = myNumberInt + myNumberFr
]
;
result
)
You can wrap it in a custom function, in case you need to change it later throughout the system.
I am sure there is a better mathematical formula, but this should get you started
The Problem is fixed.
I have price list according to weight slab in different table.
I used the Country code with Zone id to track prices for particular weight slab prices provided by the courier company.
The price list for e.g. is in such way :-
Zone 1 .5Kg 100Yuan 1.0Kg 120 yuan etc etc , there goes till 20Kg in some case at max.
so when i input the weight in weight field for e.g. 13.5kg i use this weight / .5 which gives me a value 27 , the reason i use to divide the weight with .5 is for example if i input the weight to 13.8 kg i get 27.6 there upon i embed this in ceiling function in calculation field which gives me value of 28 which i can use to calculate the next price slab in the price list which is for every 500Gms +- .
Once i get this done i use this in script which does the job of going to particular layout to search the zone and the prices and retrieving those data to original layout to show the desired result.
Regards,
Soni
Here's my problem: a user searches for products by size. The result should show all products of the desired size (if any) plus products progressively larger and smaller until there are at least 50 undersized and 50 oversized products displayed in addition to the correctly-sized products.
The result should always show all products of a certain size; in other words, if moving to the next size up or down will result in more than 50 products, show them all - don't stop at 50.
Example: Imagine there are 25 distinct sizes with 20 products of each size. The user asks for size 12. We need to go three sizes down and three sizes up to get at least 50 in each direction. The query should return all size-12 products, plus the size 9, 10, 11, 13, 14, and 15 products. The query would return 140 products total (the 20 size-12 plus 60 above and 60 below.)
Unfortunately the sizes are not nice integers like my example. They are arbitrary decimal values.
A Linq to SQL query to do this would be really cool, but plain SQL or C# is welcome, too.
(My environment is C#, SQL Server 2005)
Thanks
Here's a sample SQL statement (for mysql) that should do what you want. But depending on what else your procedure is doing, you may find it faster to do some of the processing in the C# code:
SELECT
*
FROM
products
WHERE
size = [[desired_size]] OR
size IN (
SELECT DISTINCT
size
FROM
products
WHERE
size > [[desired_size]]
ORDER BY
size
LIMIT 50
)
OR
size IN (
SELECT DISTINCT
size
FROM
products
WHERE
size < [[desired_size]]
ORDER BY
size DESC
LIMIT 50
)
I'll explain by starting at the beginning (and use your example for the values)...
Firstly we need to generate a list of the next 50 larger (or smaller) items. The following query should do this:
SELECT * FROM products WHERE size > 12 ORDER BY size LIMIT 50
So, right now, we're grabbing everything from the products table that's larger than the desired size. We order it by size, then limit it to only the first 50.
So, in this case, it should return (in this order) 20 products of size 13, 20 products of size 14 and 10 products of size 15.
You can try this in the Visual Studio SQL editor, and see which rows it returns.
But for our purposes, we only want a list of sizes, so we can limit the query further by changing the SELECT clause to:
SELECT DISTINCT size...
so, now we're only looking at the "size" column, and we use the DISTINCT keyword to avoid duplicate values
so now, the query returns just the list: (13, 14, 15)
We make a similar query to get the next 50 smaller items:
SELECT DISTINCT size FROM products WHERE size < 12 ORDER BY size DESC LIMIT 50
this is just the same as the above query, but we limit to only sizes that are smaller, and we reverse the ordering, so we get the 50 biggest items that are smaller than the desired size.
in this case this query will return the list (11, 10, 9)
If we put it all together in the outer query using these two lists, we get:
SELECT
*
FROM
products
WHERE
size = 12 OR
size IN (13, 14, 15) OR
size IN (11, 10, 9)
So we pull all the products that have a size of 9 to 15
I hope this makes sense :-)
A little late so you may have already solved this...
It seems the problem you're hitting is that you can't easily define the boundary conditions for your result set.
You can obviously easily do:
Get me everything of size X
Get me 50 of size >X
Get me 50 of size <X
However, since size is linear not discrete and we can't predict how many of each size exist, we can't group/count sizes which makes it difficult to determine which size will be at the outside of the +/-50 records - hence we need to read those values before we can get a final recordset. It may be possible to roll this into one with sub-queries but it wouldn't surprise me if LINQ executed in multiple requests,,,,
Something like:
Dim ExactSize = 1.1
Dim MaxSizeRecord = MyRepository.Get(function(x) x.Size > ExactSize).OrderBy(function(y) y.Size).Skip(50).First
Dim MinSizeRecord = MyRepository.Get(function(x) x.Size < ExactSize).OrderByDescending(function(y) y.Size).Skip(50).First
Dim FinalResults = MyRepository.Get(function(x) x.Size >= MinSizeRecord.Size and X.Size <= MaxSizeRecord.Size)
I haven't played around with the guts of LINQ enough to know if ...
Dim MaxSize = MyRepository.Get(function(x) x.Size > ExactSize).OrderBy(function(y) y.Size).Skip(50).First.Size
Dim MinSize = MyRepository.Get(function(x) x.Size < ExactSize).OrderByDescending(function(y) y.Size).Skip(50).First.Size
Dim FinalResults = MyRepository.Get(function(x) x.Size >= MinSize and X.Size <= MaxSize)
(ie getting the exact size of the boundaries rather than a record whose size happens to be at the boundary)
...would generate the same SQL - It's certainly more readable but LINQ may potentially execute the Min/Max queries immediately as the value is being stored in a Double - It's possible that by defining the type of MinSize/MaxSize implicitly it would treat it as an IQueryable(of double).
Using records instead of doubles whilst being slightly less readable should guarantee it's treated as a query not a value.