Open gparmer opened 4 years ago
Thanks for the feedback. I see the problem you are pointing out. I will try and disambiguate the plan ASAP. But for now, the weights are controls to tweak. The priorities come in terms that compose
is highest priority, read home timeline
is middle priority and read an user's timeline
is lowest priority. So, p_{compose} = 3
, p_{read_home} = 2
and p_{read_user} = 1
OK, so the priorities are not part of the training/clustering, they are static. Then you can avoid discussing them for now.
BTW, I hope you like the name I chose as it has a few different meanings that all seem appropriate, but do feel free to change it.
I guess you are talking about the project name. I love word puns.
The main inquiry I have is how this will relate to the Internet of Things. Is there a way to use this scheduling approach in an embedded system? Is this the type of system that requires a lot of memory?
You don't define what a state is, so quite a bit of this is still meaningless to me. The definition of the scheduler is pretty vague. You say that each task type for a server has separate weights, and that there are priorities. Given the formalism, I don't see priorities. These types of ambiguities make this document very difficult to parse and cause me to feel like I'm guessing and inferring most of your intention.
The way you've formalized this, the weights are part of the system state, and presumably the "controls to tweak" are weights. I am quite skeptical that that RL will do well in this scenario, but I could be wrong. (If the controls to tweak are the weights, say "tweak the weights"; if they aren't be specific. This loose wording means that I'm 100% guessing what you mean for this key aspect.)
This seems to be cool, and might be successful. I'm OK with it as a project. But right now I cannot guarantee it will work, or that you can complete it by the end of the semester. You're adding a huge amount of personal risk here by not conveying what you want to do succinctly. I think that you have work to do on the specificity of the setup and goal. If you think it is fine as is, then we can chat, but I'm not confident that will be more productive than writing this with a focus on removing ambiguity.