Laterally, as we have analyzed the performance of our Java model on implementing stock predictions using LSTM, we have realized that there are various limitations and restrictions for using the LSTM libraries associated with dl4j. Thus, to create a more fulfilling and meaningful experience for our users, I would be creating a separate model and server hosted on a Python backend instead.
Design Schema
Ideas for implementation
The LSTM could be implemented with ideas inherited/inspired from the Python project. Would be a good opportunity to practice how the different design patterns in OOP works, such as factory and builder.
Schedule Plan
Monday
[ ] Plan out the project, create the initial commit to the repository
Tuesday
[ ] Start programming the LSTM
[ ] Create data gathering and formatting system
Wednesday
[ ] Finish programming the LSTM
[ ] Debug any errors or problems with loading data
Thursday
[ ] Integration day
[ ] Start deploying the Python backend onto the AWS and sync up with other individuals on the project
Friday
[ ] Ensure everything works as expected for N@TM.
Demonstration
The core idea behind this final project is to show the difference in performance between our two models. The existing Java model is built based on deprecated libraries and data which leads to a growing gap in accuracy between our predicted and training data. Additionally, this current implementation works based on a regression model, and the overall accuracy of the model drastically decreases when we attempt to train data from beyond the 3 year scope of data that we already have existing in our model.
Our new implementation in Python would serve to be a better model for prediction, as it would have a much smaller margin of error as compared to the actual values at the time. This model would then give us greater confidence that the information we are feeding to the user is as accurate as possible.
We could show this comparison on the final project via just a switching of the API endpoints to demonstrate the difference between the two models. The implementation of the two models are still largely the same (being based on the LSTM model), however, our project can show the importance of an actively maintained codebase in a production environment. Without being properly maintained or updated, models can quickly fall of after a couple years and become irrelevant to us.
Alexander Lu's Advise Sharing of work
Laterally, as we have analyzed the performance of our Java model on implementing stock predictions using LSTM, we have realized that there are various limitations and restrictions for using the LSTM libraries associated with dl4j. Thus, to create a more fulfilling and meaningful experience for our users, I would be creating a separate model and server hosted on a Python backend instead.
Design Schema
Ideas for implementation
The LSTM could be implemented with ideas inherited/inspired from the Python project. Would be a good opportunity to practice how the different design patterns in OOP works, such as factory and builder.
Schedule Plan
Monday
Tuesday
Wednesday
Thursday
Friday
Demonstration
The core idea behind this final project is to show the difference in performance between our two models. The existing Java model is built based on deprecated libraries and data which leads to a growing gap in accuracy between our predicted and training data. Additionally, this current implementation works based on a regression model, and the overall accuracy of the model drastically decreases when we attempt to train data from beyond the 3 year scope of data that we already have existing in our model.
Our new implementation in Python would serve to be a better model for prediction, as it would have a much smaller margin of error as compared to the actual values at the time. This model would then give us greater confidence that the information we are feeding to the user is as accurate as possible.
We could show this comparison on the final project via just a switching of the API endpoints to demonstrate the difference between the two models. The implementation of the two models are still largely the same (being based on the LSTM model), however, our project can show the importance of an actively maintained codebase in a production environment. Without being properly maintained or updated, models can quickly fall of after a couple years and become irrelevant to us.