Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SPARK-15938]Adding "support" property to MLlib Association Rule #13656

Closed
wants to merge 4 commits into from

Conversation

hhbyyh
Copy link
Contributor

@hhbyyh hhbyyh commented Jun 14, 2016

What changes were proposed in this pull request?

jira: https://issues.apache.org/jira/browse/SPARK-15938

Support is an indication of how frequently the item-set appears in the database. Besides confidence, "Support" is another critical property for Association rule.
References:
https://en.wikipedia.org/wiki/Association_rule_learning
http://www.philippe-fournier-viger.com/spmf/index.php?link=documentation.php#allassociationrules
https://www-users.cs.umn.edu/~kumar/dmbook/ch6.pdf

Support can be either the count of appearances or the fraction within the dataset. I choose to use the count as:

  1. API compatibility: Currently both FPGrowthModel and Association Rule does not have the information about size of the dataset. I'd try to avoid breaking a list of public APIs.
  2. This also refers to the API of SPMF. http://www.philippe-fournier-viger.com/spmf/index.php?link=documentation.php#allassociationrules.

In the next steps, we could add constraint like minSupport as in other libraries. FPGrowthModel should also contains the size of the dataset.

How was this patch tested?

existing ut.

*/
@Since("2.1.0")
def support: Double = freqUnion.toDouble

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is intentionally typed as Double. In the future, it could be fraction value ( < 1.0).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the meaning of this should ever be overloaded. Support is a count.

Copy link
Contributor Author

@hhbyyh hhbyyh Jun 14, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two major considerations:

  1. In most definition and text books, support is a fraction value in [0.0, 1.0]. It's possible for us to align with it in the future.
  2. Current implementation of Association rule actually allows both
    freqUnion: Double, and
    freqAntecedent: Double
    to be fraction value [0.0, 1.0] although they are both counts now. I don't want to destroy the flexibility and break API in the future.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right, we use support as a fraction. Well, then best to be consistent and return it as a fraction of the data set size. I can't imagine having a method sometimes return a value with one type of semantics and sometimes another. Just make two methods.

freqUnion however appears to be a count only, and is even explicitly called a 'frequency'.

Copy link
Contributor Author

@hhbyyh hhbyyh Jun 14, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose freqUnion is made as a Double on purpose for the same reason. (flexibility for the future)

Making support a fraction now requires that we must keep the dataset size info in FPGrowthModel and AssociationRule. Yet that would introduce API change in the constructor. I thought we should avoid breaking API between 2.0 and 2.1.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dunno, that seems like a mistake to me. It should be a Long if it's a count, and should expose alternative factory methods to accept input of different types if needed. Overloading one argument seems like a hack and I'd prefer not to extend it (or fix it).

See SPARK-15930 which concerns adding the input size just for this reason, I assume. We haven't released 2.0, and so could in theory still put in a change to the constructor. I agree, we might however have to deprecate the existing one, add a new one, and still deal with calls to the old constructor, which would mean it's not possible to compute values that are a fraction of the whole data set. This in turn may argue for clearly separating inputs/outputs that are counts vs percentages.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it hard to just deprecating the old constructor and still keep support as a fraction if no dataset size is passed in.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's not possible to implement in that case. There's an argument for just adding the parameter and removing the old constructor for 2.0 in order to support this without the convolutions. I'd love to get a thumbs up from @jkbradley or @mengxr though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

support should be a fraction to be consistent with the semantic of minSupport in FPGrowth and PrefixSpan. There should be a compatible way to add support. Rule is not a case class and its constructor is package private. So this should be easy to add. Another approach is to add total number of records in the model, so people can calculate the support easily.

@hhbyyh
Copy link
Contributor Author

hhbyyh commented Jun 14, 2016

Thanks for the review @srowen

@SparkQA
Copy link

SparkQA commented Jun 14, 2016

Test build #60475 has finished for PR 13656 at commit 60efd05.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@srowen
Copy link
Member

srowen commented Jun 14, 2016

Hm, I suppose the problem is that you're returning a count here though. See also SPARK-15930 which is related, and concerns tracking the total size of the input.

@hhbyyh
Copy link
Contributor Author

hhbyyh commented Jun 14, 2016

Yes, I've linked the two issues and provided some illustration about the fraction/count choice in the description.

@hhbyyh
Copy link
Contributor Author

hhbyyh commented Jun 14, 2016

@srowen I'm also working on the ml.fpm, in which it's easier to include more information in the model and rules. I would suggest:

  1. Use support as count, and avoid any API break;
  2. Let's just keep mllib.fpm unchanged, I'll close the PR.

@SparkQA
Copy link

SparkQA commented Jun 23, 2016

Test build #61130 has finished for PR 13656 at commit 8b16676.

  • This patch fails MiMa tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@hhbyyh
Copy link
Contributor Author

hhbyyh commented Jun 23, 2016

I made a quick change to demo what's it like if we pass the data size along FPGrowthModel and AssociationRules.

@SparkQA
Copy link

SparkQA commented Jun 23, 2016

Test build #61131 has finished for PR 13656 at commit ed384c7.

  • This patch fails MiMa tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@holdenk
Copy link
Contributor

holdenk commented Oct 7, 2016

I'm not sure if this is something that would still be considered since we aren't doing new development for MLlib anymore. It might make more sense to work on https://issues.apache.org/jira/browse/SPARK-14503 and then implement this after.

@hhbyyh
Copy link
Contributor Author

hhbyyh commented Mar 14, 2017

Close this and add the support to ml.fpm. #17280

@hhbyyh hhbyyh closed this Mar 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants