@noudcorten @arsen-sheverdin @cozeybozey
Okay, this is not the way how github issues should be used, but I think at the moment this is the best place to collect this kind of feedback. Thank you @deZakelijke for this comprehensive feedback!
Here is my feedback for your draft. We can discuss it tomorrow:
Wouldn't use the word 'agile' in the introduction. It is a bit too much associated with the development paradigm to use in computer science papers in another way, in my opinion.
The 'year' as reference is a bit uncommon. I would suggest to use the number setting, but it isn up to you.
In the last paragraph you talk about the protection required for a key to be useful, but I don't think the point of the paper is to provide better security than other encryption schemes. The point is that the processing unit is equivariant to the 'encryption' i.e. the complex rotation.
In the first sentence of section 2 you don't use 'their paper' even though you said in the introduction that you would. I would remove that alias from the introduction.
Be consistent with your citations. I would suggest using \textcite{} when the (authros of) paper is a subject in the sentence.
The second to last sentence of section 2 seems to imply that the complex networks themselves gain a higher loss, but I assume that you mean the attacker networks?
It is uncommon to cite the repository of the paper you are writing in that same paper, a footnote with a link is more common.
You explained the structure of how the models were split into the encoder, processer and decoder in the introduction, but I would (also) do that at the start of the methodology a bit more rigorously. Definately give the equation for the complex rotation at least once. It is mentioned in the WGAN section, but that section seems to imply that it is only part of the generator. Adding equations also makes it clearer what *a means later on
The part in the WGAN section about the gradient clipping can be shortened. Mention that you use a gradient penalty, with a reference to the paper that proposed it
I would move the critique on the choice for U-net to the discussion section, unless you deviate from the U-net setup
You can add the image size to Table 1
Briefly mention what you are showing in the equations in 3.4. Also number the equations
I would remove Figure 1. It takes a bit too much space and doesn't add much, besides the fact that the model trained nicely. For the accuracy I would just have a table with the final accuracies.
Figure 2 is also a bit spacious, but relevant. Consider moving it to the appendix if you run out of space. In that case you just state that the reconstructions are pretty good and that they can be seen in the appendix.
Section 5.2. Be wary with a word such as impossible. It implies you have proven that it can't be done, which is a big claim. On the other hand, emphasize that the training of the GAN is what makes the model have some privacy protection, so not being able to train the GAN negates the whole use of the paper.
In the rest of 5.2 you use smbols like theta^, but I'm note sure if those were introduced earlier.
The fact that they didn't mention that they used a cross-entropy loss is not such a big issue. Focus on large issues with the paper and try to refrain from critiquing everything. It's not needed to argue that the paper is flawed.
@noudcorten @arsen-sheverdin @cozeybozey Okay, this is not the way how github issues should be used, but I think at the moment this is the best place to collect this kind of feedback. Thank you @deZakelijke for this comprehensive feedback!
Here is my feedback for your draft. We can discuss it tomorrow: