⚛👋 Hello there! Welcome. Please follow the steps below to tell us about your contribution.
Copy the correct template for your contribution (see below)
Replace this text with the contents of the template
Fill in all sections of the template
Click "Create pull request"
🐛 Are you fixing a bug?
Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must only fix an existing bug. To contribute other changes, you must use a different template.
The pull request must update the test suite to demonstrate the changed functionality.
After you create the pull request, all status checks must be pass before a maintainer reviews your contribution.
Identify the Bug
Link to the issue describing the bug that you're fixing.
If there is not yet an issue for your bug, please open a new issue and then link to that issue in your pull request.
Note: In some cases, one person's "bug" is another person's "feature." If the pull request does not address an existing issue with the "bug" label, the maintainers have the final say on whether the current behavior is a bug.
Description of the Change
We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
Alternate Designs
Explain what other alternates were considered and why the proposed version was selected
Possible Drawbacks
What are the possible side-effects or negative impacts of the code change?
Verification Process
What process did you follow to verify that the change has not introduced any regressions? Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
Release Notes
Please describe the changes in a single line that explains this improvement in
terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes
you may use the strings "Not applicable" or "N/A" here.
Examples:
The GitHub package now allows you to add co-authors to commits.
Fixed an issue where multiple cursors did not work in a file with a single line.
Increased the performance of searching and replacing across a whole project.
📈 Are you improving performances?
Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must only affect performance of existing functionality. To contribute other changes, you must use a different template.
After you create the pull request, all status checks must be pass before a maintainer reviews your contribution.
Description of the Change
We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
Quantitative Performance Benefits
Describe the exact performance improvement observed (for example, reduced time to complete an operation, reduced memory use, etc.). Describe how you measured this change. Bonus points for including graphs that demonstrate the improvement or attached dumps from the built-in profiling tools.
Possible Drawbacks
What are the possible side-effects or negative impacts of the code change?
Verification Process
What process did you follow to verify that the change has not introduced any regressions? Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
Applicable Issues
Enter any applicable Issues here
Release Notes
Please describe the changes in a single line that explains this improvement in
terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes
you may use the strings "Not applicable" or "N/A" here.
Examples:
The GitHub package now allows you to add co-authors to commits.
Fixed an issue where multiple cursors did not work in a file with a single line.
Increased the performance of searching and replacing across a whole project.
📝 Are you updating documentation?
Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must only contribute documentation (for example, markdown files or API docs). To contribute other changes, you must use a different template.
Description of the Change
We must be able to understand the purpose of your change from this description. If we can't get a good idea of the benefits of the change from the description here, the pull request may be closed at the maintainers' discretion.
Release Notes
Please describe the changes in a single line that explains this improvement in
terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes
you may use the strings "Not applicable" or "N/A" here.
Examples:
The GitHub package now allows you to add co-authors to commits.
Fixed an issue where multiple cursors did not work in a file with a single line.
Increased the performance of searching and replacing across a whole project.
💻 Are you changing functionalities?
Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must contribute a change that has been endorsed by the maintainer team. See details in the template below.
The pull request must update the test suite to exercise the updated functionality.
After you create the pull request, all status checks must be pass before a maintainer reviews your contribution.
Issue or RFC Endorsed by NDlib's Maintainers
Link to the issue or RFC that your change relates to. This must be one of the following:
An open issue with the help-wanted label
An open issue with the triaged label
An RFC with "accepted" status
To contribute other changes, you must use a different template.
Description of the Change
We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
Alternate Designs
Explain what other alternates were considered and why the proposed version was selected
Possible Drawbacks
What are the possible side-effects or negative impacts of the code change?
Verification Process
What process did you follow to verify that your change has the desired effects?
How did you verify that all new functionality works as expected?
How did you verify that all changed functionality works as expected?
How did you verify that the change has not introduced any regressions?
Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
Release Notes
Please describe the changes in a single line that explains this improvement in
terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes
you may use the strings "Not applicable" or "N/A" here.
Examples:# Pull Request Template(s)
⚛👋 Hello there! Welcome. Please follow the steps below to tell us about your contribution.
Copy the correct template for your contribution (see below)
Replace this text with the contents of the template
Fill in all sections of the template
Click "Create pull request"
🐛 Are you fixing a bug?
Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must only fix an existing bug. To contribute other changes, you must use a different template.
The pull request must update the test suite to demonstrate the changed functionality.
After you create the pull request, all status checks must be pass before a maintainer reviews your contribution.
Identify the Bug
Link to the issue describing the bug that you're fixing.
If there is not yet an issue for your bug, please open a new issue and then link to that issue in your pull request.
Note: In some cases, one person's "bug" is another person's "feature." If the pull request does not address an existing issue with the "bug" label, the maintainers have the final say on whether the current behavior is a bug.
Description of the Change
We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
Alternate Designs
Explain what other alternates were considered and why the proposed version was selected
Possible Drawbacks
What are the possible side-effects or negative impacts of the code change?
Verification Process
What process did you follow to verify that the change has not introduced any regressions? Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
Release Notes
Please describe the changes in a single line that explains this improvement in
terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes
you may use the strings "Not applicable" or "N/A" here.
Examples:
The GitHub package now allows you to add co-authors to commits.
Fixed an issue where multiple cursors did not work in a file with a single line.
Increased the performance of searching and replacing across a whole project.
📈 Are you improving performances?
Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must only affect performance of existing functionality. To contribute other changes, you must use a different template.
After you create the pull request, all status checks must be pass before a maintainer reviews your contribution.
Description of the Change
We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
Quantitative Performance Benefits
Describe the exact performance improvement observed (for example, reduced time to complete an operation, reduced memory use, etc.). Describe how you measured this change. Bonus points for including graphs that demonstrate the improvement or attached dumps from the built-in profiling tools.
Possible Drawbacks
What are the possible side-effects or negative impacts of the code change?
Verification Process
What process did you follow to verify that the change has not introduced any regressions? Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
Applicable Issues
Enter any applicable Issues here
Release Notes
Please describe the changes in a single line that explains this improvement in
terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes
you may use the strings "Not applicable" or "N/A" here.
Examples:
The GitHub package now allows you to add co-authors to commits.
Fixed an issue where multiple cursors did not work in a file with a single line.
Increased the performance of searching and replacing across a whole project.
📝 Are you updating documentation?
Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must only contribute documentation (for example, markdown files or API docs). To contribute other changes, you must use a different template.
Description of the Change
We must be able to understand the purpose of your change from this description. If we can't get a good idea of the benefits of the change from the description here, the pull request may be closed at the maintainers' discretion.
Release Notes
Please describe the changes in a single line that explains this improvement in
terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes
you may use the strings "Not applicable" or "N/A" here.
Examples:
The GitHub package now allows you to add co-authors to commits.
Fixed an issue where multiple cursors did not work in a file with a single line.
Increased the performance of searching and replacing across a whole project.
💻 Are you changing functionalities?
Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must contribute a change that has been endorsed by the maintainer team. See details in the template below.
The pull request must update the test suite to exercise the updated functionality.
After you create the pull request, all status checks must be pass before a maintainer reviews your contribution.
Issue or RFC Endorsed by NDlib's Maintainers
Link to the issue or RFC that your change relates to. This must be one of the following:
An open issue with the help-wanted label
An open issue with the triaged label
An RFC with "accepted" status
To contribute other changes, you must use a different template.
Description of the Change
We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
Alternate Designs
Explain what other alternates were considered and why the proposed version was selected
Possible Drawbacks
What are the possible side-effects or negative impacts of the code change?
Verification Process
What process did you follow to verify that your change has the desired effects?
How did you verify that all new functionality works as expected?
How did you verify that all changed functionality works as expected?
How did you verify that the change has not introduced any regressions?
Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
Release Notes
Please describe the changes in a single line that explains this improvement in
terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes
you may use the strings "Not applicable" or "N/A" here.
Examples:
The GitHub package now allows you to add co-authors to commits.
Fixed an issue where multiple cursors did not work in a file with a single line.
Increased the performance of searching and replacing across a whole project.
The GitHub package now allows you to add co-authors to commits.
Fixed an issue where multiple cursors did not work in a file with a single line.
Increased the performance of searching and replacing across a whole project.
Line 89 and 90 don't work like this, there is a bug in the code:
c1 = na.NodeNumericalAttribute("Age", value=18, op="==", probability=0.6) c2 = na.NodeNumericalAttribute("Age", value=[20, 25], op="IN", probability=0.6, triggering_status="Susceptible")
this gives the following error: " AttributeError: type object 'NodeNumericalAttribute' has no attribute 'NodeNumericalAttribute' "
It should be changed like this to work properly:
c1 = na("Age", value=18, op="==", probability=0.6) c2 = na("Age", value=[20, 25], op="IN", probability=0.6, triggering_status="Susceptible")
Pull Request Template(s)
⚛👋 Hello there! Welcome. Please follow the steps below to tell us about your contribution.
🐛 Are you fixing a bug?
Identify the Bug
Link to the issue describing the bug that you're fixing.
If there is not yet an issue for your bug, please open a new issue and then link to that issue in your pull request. Note: In some cases, one person's "bug" is another person's "feature." If the pull request does not address an existing issue with the "bug" label, the maintainers have the final say on whether the current behavior is a bug.
Description of the Change
We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
Alternate Designs
Explain what other alternates were considered and why the proposed version was selected
Possible Drawbacks
What are the possible side-effects or negative impacts of the code change?
Verification Process
What process did you follow to verify that the change has not introduced any regressions? Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
Release Notes
Please describe the changes in a single line that explains this improvement in terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes you may use the strings "Not applicable" or "N/A" here.
Examples:
📈 Are you improving performances?
Description of the Change
We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
Quantitative Performance Benefits
Describe the exact performance improvement observed (for example, reduced time to complete an operation, reduced memory use, etc.). Describe how you measured this change. Bonus points for including graphs that demonstrate the improvement or attached dumps from the built-in profiling tools.
Possible Drawbacks
What are the possible side-effects or negative impacts of the code change?
Verification Process
What process did you follow to verify that the change has not introduced any regressions? Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
Applicable Issues
Enter any applicable Issues here
Release Notes
Please describe the changes in a single line that explains this improvement in terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes you may use the strings "Not applicable" or "N/A" here.
Examples:
📝 Are you updating documentation?
Description of the Change
We must be able to understand the purpose of your change from this description. If we can't get a good idea of the benefits of the change from the description here, the pull request may be closed at the maintainers' discretion.
Release Notes
Please describe the changes in a single line that explains this improvement in terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes you may use the strings "Not applicable" or "N/A" here.
Examples:
💻 Are you changing functionalities?
Issue or RFC Endorsed by NDlib's Maintainers
Link to the issue or RFC that your change relates to. This must be one of the following:
help-wantedlabeltriagedlabelTo contribute other changes, you must use a different template.
Description of the Change
We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
Alternate Designs
Explain what other alternates were considered and why the proposed version was selected
Possible Drawbacks
What are the possible side-effects or negative impacts of the code change?
Verification Process
What process did you follow to verify that your change has the desired effects?
Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
Release Notes
Please describe the changes in a single line that explains this improvement in terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes you may use the strings "Not applicable" or "N/A" here.
Examples:# Pull Request Template(s) ⚛👋 Hello there! Welcome. Please follow the steps below to tell us about your contribution.
🐛 Are you fixing a bug?
Identify the Bug
Link to the issue describing the bug that you're fixing.
If there is not yet an issue for your bug, please open a new issue and then link to that issue in your pull request. Note: In some cases, one person's "bug" is another person's "feature." If the pull request does not address an existing issue with the "bug" label, the maintainers have the final say on whether the current behavior is a bug.
Description of the Change
We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
Alternate Designs
Explain what other alternates were considered and why the proposed version was selected
Possible Drawbacks
What are the possible side-effects or negative impacts of the code change?
Verification Process
What process did you follow to verify that the change has not introduced any regressions? Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
Release Notes
Please describe the changes in a single line that explains this improvement in terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes you may use the strings "Not applicable" or "N/A" here.
Examples:
📈 Are you improving performances?
Description of the Change
We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
Quantitative Performance Benefits
Describe the exact performance improvement observed (for example, reduced time to complete an operation, reduced memory use, etc.). Describe how you measured this change. Bonus points for including graphs that demonstrate the improvement or attached dumps from the built-in profiling tools.
Possible Drawbacks
What are the possible side-effects or negative impacts of the code change?
Verification Process
What process did you follow to verify that the change has not introduced any regressions? Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
Applicable Issues
Enter any applicable Issues here
Release Notes
Please describe the changes in a single line that explains this improvement in terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes you may use the strings "Not applicable" or "N/A" here.
Examples:
📝 Are you updating documentation?
Description of the Change
We must be able to understand the purpose of your change from this description. If we can't get a good idea of the benefits of the change from the description here, the pull request may be closed at the maintainers' discretion.
Release Notes
Please describe the changes in a single line that explains this improvement in terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes you may use the strings "Not applicable" or "N/A" here.
Examples:
💻 Are you changing functionalities?
Issue or RFC Endorsed by NDlib's Maintainers
Link to the issue or RFC that your change relates to. This must be one of the following:
help-wantedlabeltriagedlabelTo contribute other changes, you must use a different template.
Description of the Change
We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
Alternate Designs
Explain what other alternates were considered and why the proposed version was selected
Possible Drawbacks
What are the possible side-effects or negative impacts of the code change?
Verification Process
What process did you follow to verify that your change has the desired effects?
Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
Release Notes
Please describe the changes in a single line that explains this improvement in terms that a user can understand. This text will be used in NDlib's release notes.
If this change is not user-facing or notable enough to be included in release notes you may use the strings "Not applicable" or "N/A" here.
Examples:
The GitHub package now allows you to add co-authors to commits.
Fixed an issue where multiple cursors did not work in a file with a single line.
Increased the performance of searching and replacing across a whole project.
The GitHub package now allows you to add co-authors to commits.
Fixed an issue where multiple cursors did not work in a file with a single line.
Increased the performance of searching and replacing across a whole project.