Skip to content

Commit 90beef0

Browse files
danieltoaderdanieltoader
committed
Initial commit
0 parents  commit 90beef0

File tree

11 files changed

+881
-0
lines changed

11 files changed

+881
-0
lines changed

‎.gitignore

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
# Binaries for programs and plugins
2+
*.exe
3+
*.exe~
4+
*.dll
5+
*.so
6+
*.dylib
7+
8+
# Test binary, built with `go test -c`
9+
*.test
10+
11+
# Output of the go coverage tool, specifically when used with LiteIDE
12+
*.out
13+
14+
# Dependency directories (remove the comment below to include it)
15+
# vendor/
16+
17+
.idea

‎CODE_OF_CONDUCT.md

Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
# Contributor Covenant Code of Conduct
2+
3+
## Our Pledge
4+
5+
In the interest of fostering an open and welcoming environment, we as
6+
contributors and maintainers pledge to making participation in our project and
7+
our community a harassment-free experience for everyone, regardless of age, body
8+
size, disability, ethnicity, gender identity and expression, level of
9+
experience, nationality, personal appearance, race, religion, or sexual identity
10+
and orientation.
11+
12+
## Our Standards
13+
14+
Examples of behavior that contributes to creating a positive environment
15+
include:
16+
17+
* Using welcoming and inclusive language
18+
* Being respectful of differing viewpoints and experiences
19+
* Gracefully accepting constructive criticism
20+
* Focusing on what is best for the community
21+
* Showing empathy towards other community members
22+
23+
Examples of unacceptable behavior by participants include:
24+
25+
* The use of sexualized language or imagery and unwelcome sexual attention or
26+
advances
27+
* Trolling, insulting/derogatory comments, and personal or political attacks
28+
* Public or private harassment
29+
* Publishing others' private information, such as a physical or electronic
30+
address, without explicit permission
31+
* Other conduct which could reasonably be considered inappropriate in a
32+
professional setting
33+
34+
## Our Responsibilities
35+
36+
Project maintainers are responsible for clarifying the standards of acceptable
37+
behavior and are expected to take appropriate and fair corrective action in
38+
response to any instances of unacceptable behavior.
39+
40+
Project maintainers have the right and responsibility to remove, edit, or reject
41+
comments, commits, code, wiki edits, issues, and other contributions that are
42+
not aligned to this Code of Conduct, or to ban temporarily or permanently any
43+
contributor for other behaviors that they deem inappropriate, threatening,
44+
offensive, or harmful.
45+
46+
## Scope
47+
48+
This Code of Conduct applies both within project spaces and in public spaces
49+
when an individual is representing the project or its community. Examples of
50+
representing a project or community include using an official project e-mail
51+
address, posting via an official social media account, or acting as an appointed
52+
representative at an online or offline event. Representation of a project may be
53+
further defined and clarified by project maintainers.
54+
55+
## Enforcement
56+
57+
Instances of abusive, harassing, or otherwise unacceptable behavior may be
58+
reported by contacting the project team. All complaints
59+
will be reviewed and investigated and will result in a response that is deemed
60+
necessary and appropriate to the circumstances. The project team is obligated to
61+
maintain confidentiality with regard to the reporter of an incident. Further
62+
details of specific enforcement policies may be posted separately.
63+
64+
Project maintainers who do not follow or enforce the Code of Conduct in good
65+
faith may face temporary or permanent repercussions as determined by other
66+
members of the project's leadership.
67+
68+
## Attribution
69+
70+
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
71+
version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
72+
73+
[homepage]: http://contributor-covenant.org
74+
[version]: http://contributor-covenant.org/version/1/4/

‎CONTRIBUTING.md

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
# Contributing
2+
We greatly appreciate your input! We want to make contributing to this project as easy and transparent as possible,
3+
whether it is to:
4+
5+
- Report a bug
6+
- Discuss the current state of the code
7+
- Submit a fix
8+
- Propose new features
9+
- Become a maintainer
10+
11+
We have a simple to follow [code of conduct](CODE_OF_CONDUCT.md), and we kindly ask you to follow it in all your
12+
interactions with the project.
13+
14+
## We develop with Github
15+
We use github to host code, to track issues and feature requests, as well as accept pull requests.
16+
17+
### We use [Github Flow](https://guides.github.com/introduction/flow/index.html)
18+
All code changes Happen Through Pull Requests. Pull requests are the best way to propose changes to the codebase (we use
19+
[Github Flow](https://guides.github.com/introduction/flow/index.html)). We actively welcome your pull requests:
20+
21+
1. Fork the repo and create your branch from `master`.
22+
2. If you've added code that should be tested, add tests.
23+
3. If you've changed APIs, update the documentation.
24+
4. Ensure the test suite passes.
25+
5. Make sure your code lints.
26+
6. Issue that pull request!
27+
28+
#### Pull request process
29+
30+
1. Ensure any build dependencies are removed before creating the the Pull Request.
31+
2. Update the README.md with details regarding the change.
32+
3. Increase the version numbers in any examples files and the README.md to the new version that this Pull Request would
33+
represent. The versioning scheme we use is [SemVer](http://semver.org/).
34+
4. The Pull Request will be merged in once you have the sign-off of at least one of the maintainer developers.
35+
36+
## Any contributions you make will be under the MIT Software License
37+
In short, when you submit code changes, your submissions are understood to be under the same [MIT License](LICENSE) that
38+
covers the project. Feel free to contact the maintainers if that's a concern.
39+
40+
## Report bugs using Github's [issues](https://github.com/eMAGTechLabs/go-apriori/issues)
41+
We use GitHub issues to track public bugs. Report a bug by [opening a new issue](); it's that easy!
42+
43+
## Write bug reports with detail, background, and sample code
44+
**Great Bug Reports** tend to have:
45+
46+
- A quick summary and/or background
47+
- Steps to reproduce
48+
- Be specific!
49+
- Give sample code if you can.
50+
- What you expected would happen
51+
- What actually happens
52+
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
53+
54+
People *love* thorough bug reports. I'm not even kidding.
55+
56+
## License
57+
By contributing, you agree that your contributions will be licensed under its MIT License.

‎LICENSE

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
MIT License
2+
3+
Copyright (c) 2019 eMAG IT Research
4+
5+
Permission is hereby granted, free of charge, to any person obtaining a copy
6+
of this software and associated documentation files (the "Software"), to deal
7+
in the Software without restriction, including without limitation the rights
8+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9+
copies of the Software, and to permit persons to whom the Software is
10+
furnished to do so, subject to the following conditions:
11+
12+
The above copyright notice and this permission notice shall be included in all
13+
copies or substantial portions of the Software.
14+
15+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21+
SOFTWARE.

‎MAINTAINERS.md

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
# MAINTAINERS
2+
3+
This project is maintained by eMAG Targeting Team.
4+
5+
Some of the maintainers for this project are:
6+
7+
- Daniel Toader ([@DanielToader](https://github.com/danieltoader))
8+
- Dan Belibov ([@Belibov](https://github.com/belibov))
9+
- Gigi Cornea ([@CorneaGigi](https://github.com/corneagigi))
10+
- Teodor Muraru([@TeMuraru](https://github.com/temuraru))

‎MAINTAINERS_GUIDE.md

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
# Maintainers Guide
2+
3+
This guide is intended for maintainers - anybody with commit access to one or
4+
more repositories.
5+
6+
## Methodology
7+
8+
This repository does not have a traditional release management cycle, but
9+
should instead be maintained as a useful, working, and polished reference at
10+
all times. While all work can therefore be focused on the master branch, the
11+
quality of this branch should never be compromised.
12+
13+
The remainder of this document details how to merge pull requests to the
14+
repositories.
15+
16+
## Merge approval
17+
18+
The project maintainers use LGTM (Looks Good To Me) in comments on the pull
19+
request to indicate acceptance prior to merging. A change requires LGTMs from
20+
two project maintainers. If the code is written by a maintainer, the change
21+
only requires one additional LGTM.
22+
23+
## Reviewing Pull Requests
24+
25+
We recommend reviewing pull requests directly within GitHub. This allows a
26+
public commentary on changes, providing transparency for all users. When
27+
providing feedback be civil, courteous, and kind. Disagreement is fine, so long
28+
as the discourse is carried out politely. If we see a record of uncivil or
29+
abusive comments, we will revoke your commit privileges and invite you to leave
30+
the project.
31+
32+
During your review, consider the following points:
33+
34+
### Does the change have positive impact?
35+
36+
Some proposed changes may not represent a positive impact to the project. Ask
37+
whether or not the change will make understanding the code easier, or if it
38+
could simply be a personal preference on the part of the author (see
39+
[bikeshedding](https://en.wiktionary.org/wiki/bikeshedding)).
40+
41+
Pull requests that do not have a clear positive impact should be closed without
42+
merging.
43+
44+
### Do the changes make sense?
45+
46+
If you do not understand what the changes are or what they accomplish, ask the
47+
author for clarification. Ask the author to add comments and/or clarify test
48+
case names to make the intentions clear.
49+
50+
At times, such clarification will reveal that the author may not be using the
51+
code correctly, or is unaware of features that accommodate their needs. If you
52+
feel this is the case, work up a code sample that would address the pull
53+
request for them, and feel free to close the pull request once they confirm.
54+
55+
### Does the change introduce a new feature?
56+
57+
For any given pull request, ask yourself "is this a new feature?" If so, does
58+
the pull request (or associated issue) contain narrative indicating the need
59+
for the feature? If not, ask them to provide that information.
60+
61+
Are new unit tests in place that test all new behaviors introduced? If not, do
62+
not merge the feature until they are! Is documentation in place for the new
63+
feature? (See the documentation guidelines). If not do not merge the feature
64+
until it is! Is the feature necessary for general use cases? Try and keep the
65+
scope of any given component narrow. If a proposed feature does not fit that
66+
scope, recommend to the user that they maintain the feature on their own, and
67+
close the request. You may also recommend that they see if the feature gains
68+
traction among other users, and suggest they re-submit when they can show such
69+
support.

‎README.md

Lines changed: 100 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
1+
# Go-Apriori
2+
Go-Apriori is a simple go implementation of the Apriori algorithm for finding frequent sets and association rules
3+
4+
## Short Apriori Algorithm description
5+
Apriori is a classic algorithm for learning association rules. Apriori is designed to operate on databases / data sets
6+
containing transactions (for example, collections of items bought by customers)
7+
8+
The algorithm extracts useful information from large amounts of data. For example, the information that a customer who
9+
purchases 'butter' also tends to buy 'jam' at the same time is acquired from the association rule below:
10+
- Support: The percentage of task-relevant data transactions for which the pattern is true.
11+
```
12+
Support (Butter->Jam) = ( No of transactions containing both 'butter' and 'jam' ) / ( Total no of transactions )
13+
```
14+
- Confidence: The measure of certainty or trustworthiness associated with each discovered pattern.
15+
```
16+
Confidence (Butter->Jam) = ( No of transactions containing both 'butter' and 'jam' ) / ( No of transactions containing 'butter' )
17+
```
18+
- Lift: This measure of how likely item 'jam' is purchased when item 'butter' is purchased, while controlling for how
19+
popular item 'butter' is
20+
```.
21+
Lift (Butter->Jam) = ( No of transactions containing both 'butter' and 'jam' ) / ( No of transactions containing 'butter' ) * ( No of transactions containing 'jam' )
22+
```
23+
24+
The algorithm aims to find the rules which satisfy both a minimum support threshold and a minimum confidence threshold.
25+
- Item: article in the basket.
26+
- Itemset: a group of items purchased together in a single transaction.
27+
28+
### How it works
29+
- Find all frequent itemsets:
30+
- Get frequent items:
31+
- Items whose occurrence is greater than or equal to the minimum support threshold.
32+
- Get frequent itemsets:
33+
- Generate candidates from frequent items.
34+
- Prune the results to find the frequent itemsets.
35+
- Generate association rules from frequent itemsets:
36+
- Rules which satisfy the minimum support, minimum confidence and minimum lift thresholds.
37+
38+
## Usage
39+
40+
### How to get
41+
```
42+
go get github.com/eMAGTechLabs/go-apriori
43+
```
44+
45+
### Options
46+
```go
47+
type Options struct {
48+
minSupport float64 // The minimum support of relations (float).
49+
minConfidence float64 // The minimum confidence of relations (float).
50+
minLift float64 // The minimum lift of relations (float).
51+
maxLength int // The maximum length of the relation (integer).
52+
}
53+
```
54+
**Note:** If maxLength is set to 0, no max length will be taken into consideration
55+
56+
### How to use
57+
```go
58+
import "github.com/eMAGTechLabs/go-apriori"
59+
60+
transactions := [][]string{
61+
{"beer", "nuts", "cheese"},
62+
{"beer", "nuts", "jam"},
63+
{"beer", "butter"},
64+
{"nuts", "cheese"},
65+
{"beer", "nuts", "cheese", "jam"},
66+
{"butter"},
67+
{"beer", "nuts", "jam", "butter"},
68+
{"jam"},
69+
}
70+
apriori := NewApriori(transactions)
71+
results := apriori.Calculate(NewOptions(0.1, 0.5, 0.0, 0))
72+
```
73+
74+
### Sample Output
75+
```
76+
[
77+
...
78+
{
79+
supportRecord: {items: [beer cheese jam nuts] support:0.125 }
80+
orderedStatistic: [
81+
{ base: [beer cheese jam] add: [nuts] confidence: 1 lift: 1.6 }
82+
{ base: [beer cheese nuts] add: [jam] confidence: 0.5 lift: 1 }
83+
{ base: [cheese jam nuts] add: [beer] confidence: 1 lift: 1.6 }
84+
]
85+
}
86+
...
87+
]
88+
```
89+
90+
## Inspiration
91+
- [Association Rules and the Apriori Algorithm](https://www.kdnuggets.com/2016/04/association-rules-apriori-algorithm-tutorial.html)
92+
- [Apyori](https://github.com/ymoch/apyori) - Apriori python implementation
93+
- [Apriori-Algorithm](https://github.com/Omar-Salem/Apriori-Algorithm) - Apriori C# implementation
94+
95+
## Contributing
96+
Thanks for your interest in contributing! There are many ways to contribute to this project. Get started [here](CONTRIBUTING.md).
97+
98+
#### Tags
99+
100+
\#apriori-algorithm \#go

0 commit comments

Comments
 (0)