-
Notifications
You must be signed in to change notification settings - Fork 0
2023 05 16 TA Meeting Notes
The notes are based on the corresponding agenda.
- Location: EEMCS
- Date: Tue May 16
- Time: 13:15
- Attendees:
- Team 11D
- Sven van der Voort
- Each team member reports on their progress since the last meeting, including any completed tasks and any obstacles encountered.
- Guiding questions:
- What did you do since the last meeting / last week?
- What are you planning to do next, until the next meeting / next week?
- Are there any obstacles in your way?
SB & IM worked on multi-class support.
IM focused on the practical part, delved into debugging. SB focused on the theoretical part -- no MR or deliverable, but plenty of papers (in a Drive zip and links)
MA & IA: Worked design section of the report
MA & AC: Worked on Autodifferentiation, localized and understood the root of the issue. However not much in deliverables / MRs. Will work on subnet laplace support.
IM: Core of the issue: Jacobians computed incorrectly, in multiple places the transpose was not used (where it should have been). Values in H are negligibly small. Values in P_0 represent the prior precision.
Prior uncertainty is infinite on P_0=0.
Feedback on the project plan:
In the final report, a broader analysis comparing Python and Julia packages, their context and use.
SB proposes we can benchmark and compare the two solutions. SV says this is best done in the Evaluation section.
One thing is to consider to step our game up, to aim for a higher grade: As of now our requirements are mostly based on the fine-grained descriptions our client has given us.
We are doing great so far, however we should come up with additional requirements or features in addition to those provided to us, [for a higher grade].
Propose some original features (most probably referencing the original Laplace Redux paper).
IA: We already have some could-haves like this. IM: Extra features come up unpredictably. For instance last sprints issue (discovering the bug) actually results in 3:
- Verifying incorrectness of multi-class support.
- Finding the faulty function
- Fixing the function
- Adding tests to verify correctness
Sven says these additions do not of course need to come up right away
IA asks a question: seems odd to describe design without yet having done the due-diligence research design opportunities not yet explored.
SV: Only the final report will be evaluated.
IM asked a question on the distinction between Requirements, Problem Analysis, Design.
SV: would be fine if we copied a list of requirements. 5 sentences per requirement is fine. Be careful not to put the solution in the requirements. We can literally copy-paste from the project plan.
- Ambiguity of content requirements for "Design", "Requirements" and "Problem Analysis" sections in the report
- Sprint retrospective format (tabular, list, etc.)
Either Sprint retrospective format is fine.
TA fixes the meeting at 9:30--10:30. We should contact the coach to make sure this time is OK.
- Discuss any additional items not covered by the above agenda.
- Reiterate possible afore-set action points to be done by the attendees, in who-what-when format
META: This time it was hard for the chair to manage the meeting because of bad connectivity, next time actually hold the line, timing, and reiterate the action items.