Patient model (from bacherlor thesis)

[hpistudent72]

Closes #335
Closes #402

[ClFeSc]

I haven't tested it out yet.

[ClFeSc]

Use a dropdown here.

[hpistudent72]

That would mean writing code, just to end up with a self implemented select input.

[ClFeSc]

@Dassderdie What do you think?

[ClFeSc]

I still haven't tried it out, but the code looks much better now.

[ClFeSc]

Please fix these visual bugs (especially the one with the colors), then I can review this further.

[ClFeSc]

Maybe throw something here? Or use as 'blau' | 'gelb' | 'grün' | 'rot' | 'schwarz' in the switch (color[0]) line?
But don't have an empty default and then just return something you know will never match. Probably as is the better solution. @Dassderdie Any thoughts on this?

[Dassderdie]

Instead of a switch statement you should use an object literal as a map.
This should then result in something like:

colorTranslationMap[color[0]]!;

[ClFeSc]

Something about the generation of the condition parameters seems to be wrong, only two of the templates of the CSV actually have conditions. For this reason, the patients don't change their state.

[anonym-HPI]

@hpistudent72 Are you planning to finish this or should someone else continue this PR?

[anonym-HPI]

@Dassderdie @ClFeSc One of you interested in continuing this? I could also try to get this done.

[ClFeSc]

I could try to do it.

[anonym-HPI]

I could try to do it.

Ok, if you need help, just write.

[lukasrad02]

@ClFeSc are you still working on this? This feature would be interesting for our future development.

We could also try to support you on this, this way we could also get familiar with the new features quickly.

[Dassderdie]

This is probably a big performance problem as this means that for every tick for every patient, a new array with 60 items is created (immutability via the immer.js proxy).

Here is a proposal for a better solution:

This value probably doesn't change very often. Therefore, one could compress intervals with the same treatment status.

interface Interval {
    /**
     * Corresponds to the exerciseTime
     */
    startTime: number,
    value: { gf: number, .... }
}

class TreatmentHistory {
    // in seconds
    static readonly maxLength = 60;

    // If the newTreatment is different to the treatment in the last interval, add it (with the current exerciseTime) 
    // and remove all intervals that are older than (exerciseTime - maxLength)
    // else do nothing
    static addTreatment(intervalls: Intervall[], newTreatment: {gf: number, ...}, exerciseTime)

    static getAverageTreatment(...)
}

A Patient would then have treatmentHistory: Intervall[] or something like this.

This would reduce write time (expensive due to immutability) and slightly increase read time (not done very often).

One could also either remove the PatientUpdates from the Tick action or at least only send those for patients that changed their treatment. This would reduce the state-history size by a lot and could either slightly reduce or increase the performance (more calculation on the client vs. less parsing, reduced usage of the WebSocket connection, and less overhead on the server). This would also have big repercussions on the migrations.

Guidelines: "Premature optimization is the root of all evil.", Use the benchmark script.

[ClFeSc]

@ClFeSc are you still working on this? This feature would be interesting for our future development.

We could also try to support you on this, this way we could also get familiar with the new features quickly.

Generally, yes. However, currently, I'm a bit short of time. But I'll look into resolving the merge conflicts this weekend, and we can see where we'll go from there.

[ClFeSc]

There is now #614 that further tracks the progress of this. Note that the remarks and comments made here are currently still relevant. Any further remarks and comments are added to #614, please.