Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Set Analysis : inequivalent sum : sum({A,B}) != sum({A}) + sum({B})

Hi,

ScreenShot001.png

Could you please give me some clarifications concerning this issue above ?

I expected to obtain the same between

sum({<TYPE={1,3}> NETWR_SOC}

and

sum({<TYPE={1}> NETWR_SOC} + sum({<TYPE={3}> NETWR_SOC}

Thank your for your help and for any link

Adrien

1 Solution

Accepted Solutions
swuehl
MVP
MVP

You mean "are almost in the same table" like in "are in different tables"?

So what's the difference in your application then compared to my above sample (having two tables linked by a third-party field)?

I noticed that your field MATNR-ZVEN1 may link to both TYPEs 01 and 03 for some values, which I think explain the difference in your sums (and again looks similar to my above sample).

For example, check production section 008 ...., MATNR-ZVEN1 values  000000000005315694 and 000000000000260519

Have a nice evening,

Stefan

View solution in original post

5 Replies
swuehl
MVP
MVP

Fields TYPE and NETWR_SOC are probably not located in the same table, right?

Look at this example using your sums

LOAD * INLINE [

Type, Value

A, 10

B, 10

];

and compare to this:

LOAD * INLINE [

Type2, ID2

A, 1

B, 1

];

LOAD * INLINE [

ID2, Value2

1, 10

];

Consider where you set your selections in your set expression and what you are summing up.

Does this clarify your issue?

Not applicable
Author

I have tested your example. No it doesn't help. TYPE and NETWR_SOC are almost in the same table (they are joined by a third-part field). Have a look in the .qvw attached. To help the reader :

- Have a look at the intial question : http://community.qlik.com/message/250615

- The TYPE field is in the table ZVEN182

- The NETWR_SOC field is in the table X_CDESAP

Many thanks,

Adrien

swuehl
MVP
MVP

You mean "are almost in the same table" like in "are in different tables"?

So what's the difference in your application then compared to my above sample (having two tables linked by a third-party field)?

I noticed that your field MATNR-ZVEN1 may link to both TYPEs 01 and 03 for some values, which I think explain the difference in your sums (and again looks similar to my above sample).

For example, check production section 008 ...., MATNR-ZVEN1 values  000000000005315694 and 000000000000260519

Have a nice evening,

Stefan

Not applicable
Author

I just solved the problem by myself. You are right, it was because some products (MATNR_ZVEN182) were in both TYPEs (01 & 03) (which is an unexpected behavior ; I will notice this point to my service). I was not able to interpret correctly your first post.

Example :

if a product belongs to TYPE 01 and 03, and his sale value is 10, then

Sales (all TYPEs) = 10

Sales (TYPE 01) = 10

Sales (TYPE 03) = 10

.. one can understand that TOTAL (all TYPEs) is not equal to 10+10 !

In other words, ({} means a selection)

sum({A,B}) != sum({A}) + sum({B}) [Cf. the title of this post]

because some elements belongs both to A and B selections.

Thank you very much for your contribution !

swuehl
MVP
MVP

You're welcome.

Set analysis is different from plain old arithmetic, it's -like the name says- set theory.

For example, think of two intersecting circles. The area that is covered by both is different from the sum of the areas covered by each circle.