[jira] [Updated] (SYSTEMML-1185) SystemML Breast Cancer Project

2017-03-22 Thread Mike Dusenberry (JIRA)

 [ 
https://issues.apache.org/jira/browse/SYSTEMML-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Dusenberry updated SYSTEMML-1185:
--
Description: 
h1. Predicting Breast Cancer Proliferation Scores with Apache Spark and Apache 
SystemML

h3. Overview
The [Tumor Proliferation Assessment Challenge 2016 (TUPAC16) | 
http://tupac.tue-image.nl/] is a "Grand Challenge" that was created for the 
[2016 Medical Image Computing and Computer Assisted Intervention (MICCAI 2016) 
| http://miccai2016.org/en/] conference.  In this challenge, the goal is to 
develop state-of-the-art algorithms for automatic prediction of tumor 
proliferation scores from whole-slide histopathology images of breast tumors.

h3. Background
Breast cancer is the leading cause of cancerous death in women in 
less-developed countries, and is the second leading cause of cancerous deaths 
in developed countries, accounting for 29% of all cancers in women within the 
U.S. \[1]. Survival rates increase as early detection increases, giving 
incentive for pathologists and the medical world at large to develop improved 
methods for even earlier detection \[2].  There are many forms of breast cancer 
including Ductal Carcinoma in Situ (DCIS), Invasive Ductal Carcinoma (IDC), 
Tubular Carcinoma of the Breast, Medullary Carcinoma of the Breast, Invasive 
Lobular Carcinoma, Inflammatory Breast Cancer and several others \[3]. Within 
all of these forms of breast cancer, the rate in which breast cancer cells grow 
(proliferation), is a strong indicator of a patient’s prognosis. Although there 
are many means of determining the presence of breast cancer, tumor 
proliferation speed has been proven to help pathologists determine the 
treatment for the patient. The most common technique for determining the 
proliferation speed is through mitotic count (mitotic index) estimates, in 
which a pathologist counts the dividing cell nuclei in hematoxylin and eosin 
(H) stained slide preparations to determine the number of mitotic bodies.  
Given this, the pathologist produces a proliferation score of either 1, 2, or 
3, ranging from better to worse prognosis \[4]. Unfortunately, this approach is 
known to have reproducibility problems due to the variability in counting, as 
well as the difficulty in distinguishing between different grades.

References:  
\[1] http://emedicine.medscape.com/article/1947145-overview#a3  
\[2] http://emedicine.medscape.com/article/1947145-overview#a7  
\[3] http://emedicine.medscape.com/article/1954658-overview  
\[4] http://emedicine.medscape.com/article/1947145-workup#c12  

h3. Goal & Approach
In an effort to automate the process of classification, this project aims to 
develop a large-scale deep learning approach for predicting tumor scores 
directly from the pixels of whole-slide histopathology images.  Our proposed 
approach is based on a recent research paper from Stanford \[1].  Starting with 
500 extremely high-resolution tumor slide images with accompanying score 
labels, we aim to make use of Apache Spark in a preprocessing step to cut and 
filter the images into smaller square samples, generating 4.7 million samples 
for a total of ~7TB of data \[2].  We then utilize Apache SystemML on top of 
Spark to develop and train a custom, large-scale, deep convolutional neural 
network on these samples, making use of the familiar linear algebra syntax and 
automatically-distributed execution of SystemML \[3].  Our model takes as input 
the pixel values of the individual samples, and is trained to predict the 
correct tumor score classification for each one.  In addition to distributed 
linear algebra, we aim to exploit task-parallelism via parallel for-loops for 
hyperparameter optimization, as well as hardware acceleration for faster 
training via a GPU-backed runtime.  Ultimately, we aim to develop a model that 
is sufficiently stronger than existing approaches for the task of breast cancer 
tumor proliferation score classification.

References:  
\[1] https://web.stanford.edu/group/rubinlab/pubs/2243353.pdf  
\[2] See [{{Preprocessing.ipynb}} | 
https://github.com/apache/incubator-systemml/blob/master/projects/breast_cancer/Preprocessing.ipynb].
  
\[3] See [{{MachineLearning.ipynb}} | 
https://github.com/apache/incubator-systemml/blob/master/projects/breast_cancer/MachineLearning.ipynb],
 [{{softmax_clf.dml}} | 
https://github.com/apache/incubator-systemml/blob/master/projects/breast_cancer/softmax_clf.dml],
 and [{{convnet.dml}} | 
https://github.com/apache/incubator-systemml/blob/master/projects/breast_cancer/convnet.dml].
  

!approach.svg!



h2. Systems Tasks

>From a systems perspective, we aim to support multi-node, multi-GPU 
>distributed SGD training to support large-scale experiments for the specific 
>breast cancer use case.

To achieve this goal, the following steps as necessary:
# Single-node, CPU mini-batch SGD training (1 mini-batch at 

[jira] [Updated] (SYSTEMML-1185) SystemML Breast Cancer Project

2017-03-22 Thread Mike Dusenberry (JIRA)

 [ 
https://issues.apache.org/jira/browse/SYSTEMML-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Dusenberry updated SYSTEMML-1185:
--
Attachment: approach.svg

> SystemML Breast Cancer Project
> --
>
> Key: SYSTEMML-1185
> URL: https://issues.apache.org/jira/browse/SYSTEMML-1185
> Project: SystemML
>  Issue Type: New Feature
>Reporter: Mike Dusenberry
>Assignee: Mike Dusenberry
> Attachments: approach.svg
>
>
> h1. Predicting Breast Cancer Proliferation Scores with Apache Spark and 
> Apache SystemML
> h3. Overview
> The [Tumor Proliferation Assessment Challenge 2016 (TUPAC16) | 
> http://tupac.tue-image.nl/] is a "Grand Challenge" that was created for the 
> [2016 Medical Image Computing and Computer Assisted Intervention (MICCAI 
> 2016) | http://miccai2016.org/en/] conference.  In this challenge, the goal 
> is to develop state-of-the-art algorithms for automatic prediction of tumor 
> proliferation scores from whole-slide histopathology images of breast tumors.
> h3. Background
> Breast cancer is the leading cause of cancerous death in women in 
> less-developed countries, and is the second leading cause of cancerous deaths 
> in developed countries, accounting for 29% of all cancers in women within the 
> U.S. \[1]. Survival rates increase as early detection increases, giving 
> incentive for pathologists and the medical world at large to develop improved 
> methods for even earlier detection \[2].  There are many forms of breast 
> cancer including Ductal Carcinoma in Situ (DCIS), Invasive Ductal Carcinoma 
> (IDC), Tubular Carcinoma of the Breast, Medullary Carcinoma of the Breast, 
> Invasive Lobular Carcinoma, Inflammatory Breast Cancer and several others 
> \[3]. Within all of these forms of breast cancer, the rate in which breast 
> cancer cells grow (proliferation), is a strong indicator of a patient’s 
> prognosis. Although there are many means of determining the presence of 
> breast cancer, tumor proliferation speed has been proven to help pathologists 
> determine the treatment for the patient. The most common technique for 
> determining the proliferation speed is through mitotic count (mitotic index) 
> estimates, in which a pathologist counts the dividing cell nuclei in 
> hematoxylin and eosin (H) stained slide preparations to determine the 
> number of mitotic bodies.  Given this, the pathologist produces a 
> proliferation score of either 1, 2, or 3, ranging from better to worse 
> prognosis \[4]. Unfortunately, this approach is known to have reproducibility 
> problems due to the variability in counting, as well as the difficulty in 
> distinguishing between different grades.
> References:  
> \[1] http://emedicine.medscape.com/article/1947145-overview#a3  
> \[2] http://emedicine.medscape.com/article/1947145-overview#a7  
> \[3] http://emedicine.medscape.com/article/1954658-overview  
> \[4] http://emedicine.medscape.com/article/1947145-workup#c12  
> h3. Goal & Approach
> In an effort to automate the process of classification, this project aims to 
> develop a large-scale deep learning approach for predicting tumor scores 
> directly from the pixels of whole-slide histopathology images.  Our proposed 
> approach is based on a recent research paper from Stanford \[1].  Starting 
> with 500 extremely high-resolution tumor slide images with accompanying score 
> labels, we aim to make use of Apache Spark in a preprocessing step to cut and 
> filter the images into smaller square samples, generating 4.7 million samples 
> for a total of ~7TB of data \[2].  We then utilize Apache SystemML on top of 
> Spark to develop and train a custom, large-scale, deep convolutional neural 
> network on these samples, making use of the familiar linear algebra syntax 
> and automatically-distributed execution of SystemML \[3].  Our model takes as 
> input the pixel values of the individual samples, and is trained to predict 
> the correct tumor score classification for each one.  In addition to 
> distributed linear algebra, we aim to exploit task-parallelism via parallel 
> for-loops for hyperparameter optimization, as well as hardware acceleration 
> for faster training via a GPU-backed runtime.  Ultimately, we aim to develop 
> a model that is sufficiently stronger than existing approaches for the task 
> of breast cancer tumor proliferation score classification.
> References:  
> \[1] https://web.stanford.edu/group/rubinlab/pubs/2243353.pdf  
> \[2] See [{{Preprocessing.ipynb}} | 
> https://github.com/apache/incubator-systemml/blob/master/projects/breast_cancer/Preprocessing.ipynb].
>   
> \[3] See [{{MachineLearning.ipynb}} | 
> https://github.com/apache/incubator-systemml/blob/master/projects/breast_cancer/MachineLearning.ipynb],
>  [{{softmax_clf.dml}} | 
> 

[jira] [Updated] (SYSTEMML-1185) SystemML Breast Cancer Project

2017-03-22 Thread Mike Dusenberry (JIRA)

 [ 
https://issues.apache.org/jira/browse/SYSTEMML-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Dusenberry updated SYSTEMML-1185:
--
Description: 
h1. Predicting Breast Cancer Proliferation Scores with Apache Spark and Apache 
SystemML

h3. Overview
The [Tumor Proliferation Assessment Challenge 2016 (TUPAC16) | 
http://tupac.tue-image.nl/] is a "Grand Challenge" that was created for the 
[2016 Medical Image Computing and Computer Assisted Intervention (MICCAI 2016) 
| http://miccai2016.org/en/] conference.  In this challenge, the goal is to 
develop state-of-the-art algorithms for automatic prediction of tumor 
proliferation scores from whole-slide histopathology images of breast tumors.

h3. Background
Breast cancer is the leading cause of cancerous death in women in 
less-developed countries, and is the second leading cause of cancerous deaths 
in developed countries, accounting for 29% of all cancers in women within the 
U.S. \[1]. Survival rates increase as early detection increases, giving 
incentive for pathologists and the medical world at large to develop improved 
methods for even earlier detection \[2].  There are many forms of breast cancer 
including Ductal Carcinoma in Situ (DCIS), Invasive Ductal Carcinoma (IDC), 
Tubular Carcinoma of the Breast, Medullary Carcinoma of the Breast, Invasive 
Lobular Carcinoma, Inflammatory Breast Cancer and several others \[3]. Within 
all of these forms of breast cancer, the rate in which breast cancer cells grow 
(proliferation), is a strong indicator of a patient’s prognosis. Although there 
are many means of determining the presence of breast cancer, tumor 
proliferation speed has been proven to help pathologists determine the 
treatment for the patient. The most common technique for determining the 
proliferation speed is through mitotic count (mitotic index) estimates, in 
which a pathologist counts the dividing cell nuclei in hematoxylin and eosin 
(H) stained slide preparations to determine the number of mitotic bodies.  
Given this, the pathologist produces a proliferation score of either 1, 2, or 
3, ranging from better to worse prognosis \[4]. Unfortunately, this approach is 
known to have reproducibility problems due to the variability in counting, as 
well as the difficulty in distinguishing between different grades.

References:  
\[1] http://emedicine.medscape.com/article/1947145-overview#a3  
\[2] http://emedicine.medscape.com/article/1947145-overview#a7  
\[3] http://emedicine.medscape.com/article/1954658-overview  
\[4] http://emedicine.medscape.com/article/1947145-workup#c12  

h3. Goal & Approach
In an effort to automate the process of classification, this project aims to 
develop a large-scale deep learning approach for predicting tumor scores 
directly from the pixels of whole-slide histopathology images.  Our proposed 
approach is based on a recent research paper from Stanford \[1].  Starting with 
500 extremely high-resolution tumor slide images with accompanying score 
labels, we aim to make use of Apache Spark in a preprocessing step to cut and 
filter the images into smaller square samples, generating 4.7 million samples 
for a total of ~7TB of data \[2].  We then utilize Apache SystemML on top of 
Spark to develop and train a custom, large-scale, deep convolutional neural 
network on these samples, making use of the familiar linear algebra syntax and 
automatically-distributed execution of SystemML \[3].  Our model takes as input 
the pixel values of the individual samples, and is trained to predict the 
correct tumor score classification for each one.  In addition to distributed 
linear algebra, we aim to exploit task-parallelism via parallel for-loops for 
hyperparameter optimization, as well as hardware acceleration for faster 
training via a GPU-backed runtime.  Ultimately, we aim to develop a model that 
is sufficiently stronger than existing approaches for the task of breast cancer 
tumor proliferation score classification.

References:  
\[1] https://web.stanford.edu/group/rubinlab/pubs/2243353.pdf  
\[2] See [{{Preprocessing.ipynb}} | 
https://github.com/apache/incubator-systemml/blob/master/projects/breast_cancer/Preprocessing.ipynb].
  
\[3] See [{{MachineLearning.ipynb}} | 
https://github.com/apache/incubator-systemml/blob/master/projects/breast_cancer/MachineLearning.ipynb],
 [{{softmax_clf.dml}} | 
https://github.com/apache/incubator-systemml/blob/master/projects/breast_cancer/softmax_clf.dml],
 and [{{convnet.dml}} | 
https://github.com/apache/incubator-systemml/blob/master/projects/breast_cancer/convnet.dml].
  

!approach.svg!



h2. Systems Tasks

>From a systems perspective, we aim to support multi-node, multi-GPU 
>distributed SGD training to support large-scale experiments for the specific 
>breast cancer use case.

To achieve this goal, the following steps as necessary:
# Single-node, CPU mini-batch SGD training (1 mini-batch at 

[jira] [Updated] (SYSTEMML-1185) SystemML Breast Cancer Project

2017-03-22 Thread Mike Dusenberry (JIRA)

 [ 
https://issues.apache.org/jira/browse/SYSTEMML-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Dusenberry updated SYSTEMML-1185:
--
Description: 
This issue tracks the new SystemML breast cancer project!

>From a systems perspective, we aim to support multi-node, multi-GPU 
>distributed SGD training to support large-scale experiments for the specific 
>breast cancer use case.

To achieve this goal, the following steps as necessary:
# Single-node, CPU mini-batch SGD training (1 mini-batch at a time).
# Single-node, single-GPU mini-batch SGD training (1 mini-batch at a time).
# Single-node, multi-GPU data-parallel mini-batch SGD training (`n` parallel 
mini-batches for `n` GPUs at a time).
# Multi-node, CPU data-parallel mini-batch SGD training (`n` parallel 
mini-batches for `n` parallel tasks at a time).
# Multi-node, single-GPU data-parallel mini-batch SGD training (`n` parallel 
mini-batches for `n` total GPUs across the cluster at a time).
# Multi-node, multi-GPU data-parallel mini-batch SGD training (`n` parallel 
mini-batches for `n` total GPUs across the cluster at a time).



Here is a list of past and present JIRA epics and issues that have blocked, or 
are currently blocking progress on the breast cancer project.
 
Overall Deep Learning Epic
  * https://issues.apache.org/jira/browse/SYSTEMML-540
  *This is the overall "Deep Learning" JIRA epic, with all issues either within 
or related to the epic.

Past
* https://issues.apache.org/jira/browse/SYSTEMML-633
* https://issues.apache.org/jira/browse/SYSTEMML-951
  ** Issue that completely blocked mini-batch training approaches.
* https://issues.apache.org/jira/browse/SYSTEMML-914
  ** Epic containing issues related to input DataFrame conversions that blocked 
getting data into the system entirely.  Most of the issues specifically refer 
to existing, internal converters.  993 was a particularly large issue, and 
triggered a large body of work related to internal memory estimates that were 
incorrect.  Also see 919, 946, & 994.
* https://issues.apache.org/jira/browse/SYSTEMML-1076
* https://issues.apache.org/jira/browse/SYSTEMML-1077
* https://issues.apache.org/jira/browse/SYSTEMML-948

Present
* https://issues.apache.org/jira/browse/SYSTEMML-1160
  ** Current open blocker to efficiently using a stochastic gradient descent 
approach.
* https://issues.apache.org/jira/browse/SYSTEMML-1078
  ** Current open blocker to training even an initial deep learning model for 
the project.  This is another example of an internal compiler bug.
* https://issues.apache.org/jira/browse/SYSTEMML-686
  ** We need distributed convolution and max pooling operators.
* https://issues.apache.org/jira/browse/SYSTEMML-1159
  ** This is the main issue that discusses the need for the `parfor` construct 
to support efficient, parallel hyperparameter tuning on a cluster with large 
datasets.  The broken remote parfor in 1129 blocked this issue, which in turned 
blocked any meaningful work on training a deep neural net for the project.
* https://issues.apache.org/jira/browse/SYSTEMML-1142
  ** This was one of the blockers to doing hyperparameter tuning.
* https://issues.apache.org/jira/browse/SYSTEMML-1129
  ** This is an epic for the issue in which the `parfor` construct was broken 
for remote Spark cases, and was one of the blockers for doing hyperparameter 
tuning.

  was:
This issue tracks the new SystemML breast cancer project!

Here is a list of past and present JIRA epics and issues that have blocked, or 
are currently blocking progress on the breast cancer project.
 
Overall Deep Learning Epic
  * https://issues.apache.org/jira/browse/SYSTEMML-540
  *This is the overall "Deep Learning" JIRA epic, with all issues either within 
or related to the epic.

Past
* https://issues.apache.org/jira/browse/SYSTEMML-633
* https://issues.apache.org/jira/browse/SYSTEMML-951
  ** Issue that completely blocked mini-batch training approaches.
* https://issues.apache.org/jira/browse/SYSTEMML-914
  ** Epic containing issues related to input DataFrame conversions that blocked 
getting data into the system entirely.  Most of the issues specifically refer 
to existing, internal converters.  993 was a particularly large issue, and 
triggered a large body of work related to internal memory estimates that were 
incorrect.  Also see 919, 946, & 994.
* https://issues.apache.org/jira/browse/SYSTEMML-1076
* https://issues.apache.org/jira/browse/SYSTEMML-1077
* https://issues.apache.org/jira/browse/SYSTEMML-948

Present
* https://issues.apache.org/jira/browse/SYSTEMML-1160
  ** Current open blocker to efficiently using a stochastic gradient descent 
approach.
* https://issues.apache.org/jira/browse/SYSTEMML-1078
  ** Current open blocker to training even an initial deep learning model for 
the project.  This is another example of an internal compiler bug.
* https://issues.apache.org/jira/browse/SYSTEMML-686
  ** We need 

[jira] [Updated] (SYSTEMML-1185) SystemML Breast Cancer Project

2017-01-20 Thread Mike Dusenberry (JIRA)

 [ 
https://issues.apache.org/jira/browse/SYSTEMML-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Dusenberry updated SYSTEMML-1185:
--
Description: 
This issue tracks the new SystemML breast cancer project!

Here is a list of past and present JIRA epics and issues that have blocked, or 
are currently blocking progress on the breast cancer project.
 
Overall Deep Learning Epic
  * https://issues.apache.org/jira/browse/SYSTEMML-540
  *This is the overall "Deep Learning" JIRA epic, with all issues either within 
or related to the epic.

Past
* https://issues.apache.org/jira/browse/SYSTEMML-633
* https://issues.apache.org/jira/browse/SYSTEMML-951
  ** Issue that completely blocked mini-batch training approaches.
* https://issues.apache.org/jira/browse/SYSTEMML-914
  ** Epic containing issues related to input DataFrame conversions that blocked 
getting data into the system entirely.  Most of the issues specifically refer 
to existing, internal converters.  993 was a particularly large issue, and 
triggered a large body of work related to internal memory estimates that were 
incorrect.  Also see 919, 946, & 994.
* https://issues.apache.org/jira/browse/SYSTEMML-1076
* https://issues.apache.org/jira/browse/SYSTEMML-1077
* https://issues.apache.org/jira/browse/SYSTEMML-948

Present
* https://issues.apache.org/jira/browse/SYSTEMML-1160
  ** Current open blocker to efficiently using a stochastic gradient descent 
approach.
* https://issues.apache.org/jira/browse/SYSTEMML-1078
  ** Current open blocker to training even an initial deep learning model for 
the project.  This is another example of an internal compiler bug.
* https://issues.apache.org/jira/browse/SYSTEMML-686
  ** We need distributed convolution and max pooling operators.
* https://issues.apache.org/jira/browse/SYSTEMML-1159
  ** This is the main issue that discusses the need for the `parfor` construct 
to support efficient, parallel hyperparameter tuning on a cluster with large 
datasets.  The broken remote parfor in 1129 blocked this issue, which in turned 
blocked any meaningful work on training a deep neural net for the project.
* https://issues.apache.org/jira/browse/SYSTEMML-1142
  ** This was one of the blockers to doing hyperparameter tuning.
* https://issues.apache.org/jira/browse/SYSTEMML-1129
  ** This is an epic for the issue in which the `parfor` construct was broken 
for remote Spark cases, and was one of the blockers for doing hyperparameter 
tuning.

  was:
This issue tracks the new SystemML breast cancer project!

Here is a list of past and present JIRA epics and issues that have blocked, or 
are currently blocking progress on the breast cancer project.
 
Overall Deep Learning Epic
  * https://issues.apache.org/jira/browse/SYSTEMML-540
  *This is the overall "Deep Learning" JIRA epic, with all issues either within 
or related to the epic.

Past
* https://issues.apache.org/jira/browse/SYSTEMML-633
  ** Issue that completely blocked mini-batch training approaches.
* https://issues.apache.org/jira/browse/SYSTEMML-914
  ** Epic containing issues related to input DataFrame conversions that blocked 
getting data into the system entirely.  Most of the issues specifically refer 
to existing, internal converters.  993 was a particularly large issue, and 
triggered a large body of work related to internal memory estimates that were 
incorrect.  Also see 919, 946, & 994.
* https://issues.apache.org/jira/browse/SYSTEMML-1076
* https://issues.apache.org/jira/browse/SYSTEMML-1077
* https://issues.apache.org/jira/browse/SYSTEMML-948
* https://issues.apache.org/jira/browse/SYSTEMML-951
  ** Another major blocker to efficient mini-batch training approaches.  There 
is still further improvement that is needed here.

Present
* https://issues.apache.org/jira/browse/SYSTEMML-1160
  ** Current open blocker to efficiently using a stochastic gradient descent 
approach.
* https://issues.apache.org/jira/browse/SYSTEMML-1078
  ** Current open blocker to training even an initial deep learning model for 
the project.  This is another example of an internal compiler bug.
* https://issues.apache.org/jira/browse/SYSTEMML-686
  ** We need distributed convolution and max pooling operators.
* https://issues.apache.org/jira/browse/SYSTEMML-1159
  ** This is the main issue that discusses the need for the `parfor` construct 
to support efficient, parallel hyperparameter tuning on a cluster with large 
datasets.  The broken remote parfor in 1129 blocked this issue, which in turned 
blocked any meaningful work on training a deep neural net for the project.
* https://issues.apache.org/jira/browse/SYSTEMML-1142
  ** This was one of the blockers to doing hyperparameter tuning.
* https://issues.apache.org/jira/browse/SYSTEMML-1129
  ** This is an epic for the issue in which the `parfor` construct was broken 
for remote Spark cases, and was one of the blockers for doing hyperparameter 
tuning.


> 

[jira] [Updated] (SYSTEMML-1185) SystemML Breast Cancer Project

2017-01-20 Thread Mike Dusenberry (JIRA)

 [ 
https://issues.apache.org/jira/browse/SYSTEMML-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Dusenberry updated SYSTEMML-1185:
--
Description: 
This issue tracks the new SystemML breast cancer project!

Here is a list of past and present JIRA epics and issues that have blocked, or 
are currently blocking progress on the breast cancer project.
 
Overall Deep Learning Epic
  * https://issues.apache.org/jira/browse/SYSTEMML-540
  *This is the overall "Deep Learning" JIRA epic, with all issues either within 
or related to the epic.

Past
* https://issues.apache.org/jira/browse/SYSTEMML-633
  * Issue that completely blocked mini-batch training approaches.
* https://issues.apache.org/jira/browse/SYSTEMML-914
  * Epic containing issues related to input DataFrame conversions that blocked 
getting data into the system entirely.  Most of the issues specifically refer 
to existing, internal converters.  993 was a particularly large issue, and 
triggered a large body of work related to internal memory estimates that were 
incorrect.  Also see 919, 946, & 994.
* https://issues.apache.org/jira/browse/SYSTEMML-1076
* https://issues.apache.org/jira/browse/SYSTEMML-1077
* https://issues.apache.org/jira/browse/SYSTEMML-948
* https://issues.apache.org/jira/browse/SYSTEMML-951
  * Another major blocker to efficient mini-batch training approaches.  There 
is still further improvement that is needed here.

Present
* https://issues.apache.org/jira/browse/SYSTEMML-1160
  * Current open blocker to efficiently using a stochastic gradient descent 
approach.
* https://issues.apache.org/jira/browse/SYSTEMML-1078
  * Current open blocker to training even an initial deep learning model for 
the project.  This is another example of an internal compiler bug.
* https://issues.apache.org/jira/browse/SYSTEMML-686
  * We need distributed convolution and max pooling operators.
* https://issues.apache.org/jira/browse/SYSTEMML-1159
  * This is the main issue that discusses the need for the `parfor` construct 
to support efficient, parallel hyperparameter tuning on a cluster with large 
datasets.  The broken remote parfor in 1129 blocked this issue, which in turned 
blocked any meaningful work on training a deep neural net for the project.
* https://issues.apache.org/jira/browse/SYSTEMML-1142
  * This was one of the blockers to doing hyperparameter tuning.
* https://issues.apache.org/jira/browse/SYSTEMML-1129
  * This is an epic for the issue in which the `parfor` construct was broken 
for remote Spark cases, and was one of the blockers for doing hyperparameter 
tuning.

  was:This issue tracks the new SystemML breast cancer project!


> SystemML Breast Cancer Project
> --
>
> Key: SYSTEMML-1185
> URL: https://issues.apache.org/jira/browse/SYSTEMML-1185
> Project: SystemML
>  Issue Type: New Feature
>Reporter: Mike Dusenberry
>Assignee: Mike Dusenberry
>
> This issue tracks the new SystemML breast cancer project!
> Here is a list of past and present JIRA epics and issues that have blocked, 
> or are currently blocking progress on the breast cancer project.
>  
> Overall Deep Learning Epic
>   * https://issues.apache.org/jira/browse/SYSTEMML-540
>   *This is the overall "Deep Learning" JIRA epic, with all issues either 
> within or related to the epic.
> Past
> * https://issues.apache.org/jira/browse/SYSTEMML-633
>   * Issue that completely blocked mini-batch training approaches.
> * https://issues.apache.org/jira/browse/SYSTEMML-914
>   * Epic containing issues related to input DataFrame conversions that 
> blocked getting data into the system entirely.  Most of the issues 
> specifically refer to existing, internal converters.  993 was a particularly 
> large issue, and triggered a large body of work related to internal memory 
> estimates that were incorrect.  Also see 919, 946, & 994.
> * https://issues.apache.org/jira/browse/SYSTEMML-1076
> * https://issues.apache.org/jira/browse/SYSTEMML-1077
> * https://issues.apache.org/jira/browse/SYSTEMML-948
> * https://issues.apache.org/jira/browse/SYSTEMML-951
>   * Another major blocker to efficient mini-batch training approaches.  There 
> is still further improvement that is needed here.
> Present
> * https://issues.apache.org/jira/browse/SYSTEMML-1160
>   * Current open blocker to efficiently using a stochastic gradient descent 
> approach.
> * https://issues.apache.org/jira/browse/SYSTEMML-1078
>   * Current open blocker to training even an initial deep learning model for 
> the project.  This is another example of an internal compiler bug.
> * https://issues.apache.org/jira/browse/SYSTEMML-686
>   * We need distributed convolution and max pooling operators.
> * https://issues.apache.org/jira/browse/SYSTEMML-1159
>   * This is the main issue that discusses the need for the `parfor` construct 
> to support