Some tips about the paper editing. 一些自己在editing的时候容易犯的小错误。
有的时候换位思考，如果自己作为reviewer或者给别人提供一些guidance的时候，有没有那种confidence就确定这个事情应该是如何而不应该是如何。是不是能讲清楚一些事情，最基本的就是editing时候的一些常见错误了，这里记录一下，希望遇到类似的问题能够达到讲得清楚的效果。
Recent notes about the paper rejected reasons
Hope this section does not be replaced frequently. I try to consider it from two aspects, make it get to the basic level (borderline) firstly, 避免硬伤 (the reason that can be rejected directly), then trying to make the work more fancy or novel (pursue better performance etc.)
From reviewer’s perspective, they just quickly looks at these red flag, if they find one red flag, they have confidence to give a reject to the paper, then it will save their energy to read paper in detail. It is really hard for other people to understand the paper one hundrerd percent in limited time. It is not the reviewer’s job, it is the authord responsibility to make sure the approach is correct.
There is one rejected EGPGV workshop, there are following rejected reasons:
method lacks novelty
The paper is kind of A+B case, and provide a different implementaion, the reviewer think this is more like an engineering task. For example, the previous work present an approach and implemented on GPU by library A, if you implememt it again by library B, or even integrated as a plugin or other softwares, it is more like an engineering task instead of the research task.
method is not clear
If the method itself is a contribution, at least you need to list a flow chart for the workflow or approch, or using an algorithm list to details your algorithm clearly. If you include these pieces, the reviewer will not say the method is not clear enough
evaluation is not sufficient
We submit EGPGV which focuses on large parallel in graphics domain, but we only evaluate on multi-threaded cases without showing the scalability experiments across multiple nodes. These evaluation might not be novel enough, but at least it shows some evidence that how your approach can scale.
The ISAV rejected paper
No comparision with the SOTA approach
This is a simple one, but most of paper does not take care of it carefully. This can be a straightforward reason for reviewer to give a reject.
建议书与项目书Tips
有的时候需要在很短的时间内提交一个proposal，中文有各种不同的叫法，比如建议书(相对比较短，只有标题1-2页那种)，或者项目申请书等等。这种文档和论文不太一样，需要写的东西通常都是没有做出来的，这就很让人为难，因为又不能瞎说，也不能说的太简单，显示不出创新的地方。而且还要写上需要实现的考核指标，这个时候就很纠结，担心给自己挖坑，就会担心要是做不出来考核不通过怎么办。
常见的套路就是先想清楚要做一个什么事情，整个项目中各个模块的关系是什么样的，比如被分配到的可能是一个大课题，之后就开始想清楚不同课题之间的关系，这个时候就可以开始准备几页简单的ppt帮助梳理思想，而不是马上开始在文档里填充内容，即使时间比较紧张。或者再ppt里同时把流程图也画出来，比如数据流和控制流，之后和相关的负责人讨论，多迭代几次，等整体的方案确定下来再划分小的课题，之后把小的课题分配给不同的人来书写填充内容，这样就能在比较短的时间内完成一个质量还可以的proposal了，同时领导也比较满意。这样的话这些ppt的内容也可以保留下来，后期迭代更新以及做proposal的时候都比较方便。对于项目书的话，一般要准备三个图，一个是项目中各个课题的关系图，比如哪个是入口哪个是出口，哪个起到了支撑作用等等，另一个是项目中的课题的主要研究内容的图，这个图一般就是框线风格就好，列出模块以及具体研究的细节点，因为有时候会打印出来，如果方框加了背景的话可能不方便打印。最后一个是技术路线图，这个有点类似论文里的那种流程图，把所有的关键模块和技术细节关联起来，数据如何流动等等。这几个图都具备了在准备文字材料就方便多了。
写项目书的时候最重要的是研究内容和技术路线两个部分，这里就需要两个图了，研究内容的图可以就是普通的框线图，技术路线的图要比较突显路线两个字，就是有一些流程的感觉，相当于是研究内容的图的细化。技术路线图似乎不能完全用数据流或者调用流的那种形式表示，更突出的是不同模块之间的关联关系，比如这里的箭头可能是一个具体的动作，类似于支撑xx，集成xx，调用xx，提供xx之类的文字。更像是数据流图和调用流图的结合体。最基本的就是用大框画出不同的模块，小块标记出模块的特性，然后箭头连接体现出模块之间的关系。
比较不好的方式就是一个人闷头干，然后即使最后提交了一个版本，大部分情况下领导也不太满意，因为领导没有参与决策的过程，可能有一些细节自己没有考虑到位，也没有对领导有充分的尊重，要是这个建议书是比较重要的，最终按照建议书的内容来执行的话，写的目标太高，出了问题还得领导帮着承担，给整个部门造成负担。所以一定要让领导也参与到整个项目书的书写过程中来。同时记得多听取不同同事的意见。
下面是两个具体的例子，写之前先要在脑子里现有一个理解逻辑，这个逻辑思想体现出来就是图，文字描述的时候尽量使得每句话都有针对性，每句话描述了一个图上的关键信息，可以是图的链接部分，也可以是关键模块的部分。
这个是建议书的书写风格，就是开头一句写需求，然后写写研究什么，最后一句话总结意义:
A实验过程复杂，涉及多种实验变量。利用基于试验过程中产生的B（包括C、D），研究E实验过程的全流程可视化技术；研究数字试验三维场景重建、从而对实验过程进行多视角、多模式可视化交互；研究基于光线追踪的真实感渲染技术再现复杂体的分离过程，实现试验过程的全角度可观察；研究…;通过可视化技术对实验结果进行复现将有助于科学家分析实验过程，探索关键变量，有助于研究人员优化试验设计与试验流程。
如果放在项目申请书中，阐述具体技术路线的时候，就需要加上更多的连接词，让内容更连贯，用各种动词把技术路线中的连线给表达出来
基于试验A模型及试验过程中产生的B数据集，研究C实验过程的关键流程可视化技术，解析D、E、F等数据，通过数字三维场景重建技术，模拟G和H的动态立体场景，采用多视角、多模式可视化交互布局优化技术，实现对试验过程的关键流程的全角度可观察，结合基于xx渲染技术，细致地再现I，形成J试验的可视化系统，对K试验验证提供有效支撑。
其他常常用到表示逻辑关系的词或者政策类的词还包括，构建，面向，
政策类的词包括：新形势，科研范式变革，支撑抢占xxx，支撑xxx任务等等
投标书书写tips
择优材料书写tips
最近有幸学习了单位里的一个老师的择优材料书写，当然根本上还是做出的内容，表述方式是锦上添花的方面，大致列一下相关的提纲，具体如下，可以用作以后的参考：
个人总述段落关键信息
申请人发表论文xx，其中ccfA xx, 专利 xx 草案 xx , 围绕上述工作，重点研发计划xx，科研项目xx，承担经费xx，企业落地 xx，合作项目xx，获得xx 奖，具体代表性科研项目如下 ：
代表性项目1 （每个项目两段，第一段具体介绍细节，第二段介绍这个项目的成果）
第一段：
(背景) … 然而… 有…关键挑战。申请人针对上述问题….利用…算法，实现…效果，性能…
第二段：
基于以上成果，发表CCF A… 申请了… 项目，发表了…论文
代表性项目2 。。。
代表性项目3。。。
中文类型的材料其他tips
一个句子中最好仅使用一个“的”
题目的命名套路相对固定一些，就是“基于abc的def方法”，这里的def是abc方法的拓展，或者是“面向abc的def的方法”，这里的abc是def方法的场景或者目的。
在写意义或者立项必要性的部分，要突出一些政策或者规划，来突显这个领域比较重要，一般是整个领域或者世界层面-》国家层面-》单位层面，这三个层次，每个层析列一两句话说一下相关的政策或者规划，然后说当前的这个研究是符合政策规划的方向，等等。
发paper的时候就不能用这个套路了，应该先说大的或者根本性的challenge，比如in situ之类的论文的challenge就是 gap between computation and communication。这里要注意区别不同场景下的材料的撰写套路。
Attitude and patience
The attitude and patience is important, we might need to polish the paper again and again to make it readable. 很容易就有这样的想法，觉得心烦了或者这个paper这个样子交了就算了，这些都是不好的态度。用一些定量的指标来看的话就是在paper的整个框架基本上成型之后，还要从头到尾，完完整整地仔细阅读并且修改至少5次，而且至少要有2次是把paper打印在纸上然后从头到尾地通读一遍，并且标记出来错误和需要修改的地方，然后再统一改正，这算是一遍。这种从头到尾的梳理很关键，刚开始一般仔细梳理一遍都至少需要大半天的时间，然后这种梳理就会变得越来越快，直到比如一两个小时就完成一遍梳理，这个时候论文内容就比较好了。
有时候读自己的paper是需要勇气的，需要克服一些内心的烦躁，因为知道自己写的内容不是太好，有的地方甚至还漏洞百出甚至有很多stupid question。总之在paper的editing上要谦虚一点，多读一遍，多过一遍，静下心来，总是能发现一些额外的错误，把paper润色的更好一些再给别人看也不迟。用通俗的话说就是要在恶心别人之前先恶心自己，这算是对待paper比较负责人的态度吧。同时也要多参考别人的意见，要有个心里准备，不管写的再好，别人也是会提出一些意见的，正常的情况就是自己找问题和修改别人的意见同时进行，这样有个至少3次itertaion之后可能会好一些。不要指望发了邮件给别人之后别人都说好，这是不显示的，心态上要做好迎接别人的批评的准备。
长paper的整理流程
对于 8-10页的长paper，由于内容的数量多，editing起来比较费事儿。在行程能够发给co-author的版本之后，还要至少整体再过3遍，这样提交才能基本保证没有什么editing的error。一天可能是看不完的，之前自己用的一个套路就是把每个section都标记出来，然后每次过完一个section可能就打一个勾，这样每天分配一些时间过一点，要是一下某一天看得太多也容易比较烦，这样可以保证整体进度，然后每天也不至于太累。
第二遍的时候就可以倒着开始看，因为一般都比较容易虎头蛇尾，所以evaluation的部分的editing可能不是很到位，第二次从exp开始往前看的话可能更能发现一下evaluation部分的问题。
the, a
关于 the a 的使用似乎一直没有摸到关键的法门，总结出来以下一些思路
本身这个词是不是certain的，如果本身是certain的就不用the 或者 a 比如论文中的Table 1, Figure 1 或者Equation 1 或者 section 1，这些都像是名字一样，能直接定位到独一无二的个体也不会引起歧义，就不需要在前面加上冠词。
集合的名字或者是抽象的名词前面也不用加上the 这可能还与受众有关，具体可以参考这个关于share knowledge的解释，如果大家心知肚明的概念或者学科名词或者是事物 The table,The char,The room,The tiger，就像公理一样的，就用the，如果是一个新的概念要不断去具体解释就不用the,算是一个抽象的概念。
这里还介绍了几种不使用article的情况，有些在论文写作中不怎么能用得到，但是也应该注意一下，直接引用过来:
1. to talk about plural and uncountable nouns or when talking about things in general: |
比较有针对性地要特别注意的地方就是 plural and uncontable nouns. 和当前的research topic比较相关的一个就是 in situ processing。这里的 processing 属于uncountable nouns 而且是general形式，就不需要再前面使用the。
这个资料 说了一些不可数名词和可数名字的复数使用定冠词和不定冠词的情况。可数名词复数在表示一个特定的group的时候也需要用the，如果是general的case就不需要用the。
剩下的情况就是按照用 the 与 用 a 来二分，这个总容易分清楚，如果是前面已经提到的第二次提到，就用the，如果是第一次提到也没有特指的就用a，可以是any of it 当然是单数的情况. 最高级这些就用the，还有The country where I born 这种后面有限定的情况也用the.
singular plural
有一些特殊情况的 singular 和 plural 要稍微注意一下
Third person
Check this one to get more details. When using the modal verbs. Do not use this thirs person sigular.
有一些既可以作为单数也可以作为复数的词汇
比如data，比如表示传递数据的时候一般作为复数比较make sense. 最好整个文章保持统一，或者为了避免歧义就用data blocks来描述也比较好。
A and B 并列的时候，单复数的使用
http://www.gaosan.com/gaokao/332134.html
需要从语义的角度来看，看看所说的事情是不是一个概念。
有一些特殊词，比如data，似乎当做singular或者plural都是可以的，这种时候最好全文统一起来。一般情况下指data blocks的时候，还是当成plural的形式比较好。
关于公式后面的标点符号
https://blog.csdn.net/weixin_46309254/article/details/122541026
注意公式也是段落的一部分，要合理地加上句号或者逗号。除了as follows要加上冒号引出公式外，其他的一般expressed as，described as 这些就不需要加上冒号。
Tense
关于时态就按照如下思路
默认都是一般现在时
在related work中描述别人已经完成的工作用过去时态
然后在最后的summary一段使用过去时或者完成时。
更多的例子可以参考reference中的 天文物理类英文科技论文写作的常见问题 一文
Logic
对于自己而言常容易弄混的是总分和因果的logic。Typical的总分就是section开始的时候用处比较多，比如这个section介绍design，之后 in particular, we discuss sub case 1, sub case 2 and sub case 3. These subcase describe a particular aspects of the design. 因果的logic 就是有明显的conclusion和reason，比如这个现象是什么，为什么是这样，然后得出什么结论。
一些误用的地方就是容易过早地给出conclusion，造成不够convincing的表述。这里要特别注意，对于描述为什么这样做而不是那样做的时候，要做好铺垫。即使是类似 “we can continue discuss how a is influenced by b” 这样的话也是有效的铺垫，尽量避免直接表述 “a is larger than b” 这样的结论。就算和别人说话时候也是，要找点那种娓娓道来的感觉。
Shrink the paper
paper似乎就像是一个含着水的海绵，只要想办法挤，总是能使它越来越dry并且越来越tight. 常用的方式有以下一些：
\setlength{\textfloatsep}{0pt} 这个会减少一些图片与文字之间的距离，要是还有的距离比较大，就使用\vspace{-10pt} 一般是图片的caption部分和图片之间，总有一些可以缩小的空隙。
然后看看段落的末尾，是否有那种dangling sentences或者是dangling words, 这样的词改掉之后可以得到一些额外的空隙。
再一个就是看related work，有些没必要用的就可以省去，有些references会夹带一些没用的内容，比如像notes什么的，这些也可以删去。
通常这各种操作时候，就基本上能够满足页面的要求了，一般也就是超过个半页的样子。如果还是没有满足，就说明实在是有一些冗余的内容，这个时候就需要在review一下整个文章，合并一下段落，然后对于一些可说可不说的信息就直接省去就好。
Indent
一般thesis的edit常常在title或者subsection的第一行不采用indent，这就比较奇怪，有的template是默认每段开始都使用indent有的是首段不用。看到这个讨论之后有一些恍然大悟的感觉。indent的目的就是为了在段落和段落之间进行区分，既然第一段直接紧连着标题，那就不用做什么区分了。而且这样看起来也整洁一些。
Remove the “there be” or “it is”
这样的句型一方面是冗余，一方面是指代不清楚(有的时候自己都不确定是指代的什么，更容易给读者造成confusion)，在论文写作中，最好强制地让自己少用一些代词，比如this之类的，这样句式上可以更加简洁一些，要特别有那种主语的意识，尤其是there be 句型，似乎是最先容易想到的，这个时候就再仔细想想相关的动词和主语到底是什么，看看是否能把there be给替换掉。
Here are several examples:
it is necessary to use A to do sth -> using A to do sth is necessary
when there is a fixed number of processes -> when the number of processes is fixed
when there are arbitrary combinations of A and B -> When the combination of A and B is arbitrary.
Online vs Real time
很多时候自己把这两个词等同起来用了，实际上强调的是不同方面的事情，这个answer解答的比较好。
online是一种更broad的修饰，最简单的理解就是打电话，对方正在接听或者正在线上就是online。所以一般说的online service就是这个服务一直有respond，比如发了一个request，然后得到了respond，这个就是online service，如果没有respond，这个就是offline service，这里的online更是强调一个interactive的过程。
real time 更强调的是data processing 的 delay。这个文章解释的比较好。这些相关的term更多的是强调不同的delay， 一般比较常见的用法就是real time processing 这种。
所以在使用real time或者online的时候要特别注意context，看看是说一个service是否有交互还是在强调data processing的pipeline。这两个词实际上是在强调事情的不同方面。
Another scenario is the model learning or parameter prediction, we use the online prediction or offline prediction to emphasize the approach, refer to this to get more ideas
https://www.mathworks.com/help/ident/ug/what-is-online-estimation.html
and this
https://www.mathworks.com/help/ident/ug/how-online-estimation-differs-from-offline-estimation.html
Tools
Grammaly professional version can reduce most of the typos or the general expression.
https://ludwig.guru/ Can help to find how a particular pharase is adopted in other related articles.
If you do not sure how to translate a particular meaning in an accurate way, just use the the google translate. Or if you not sure if a particular english paragraph can express things in an accurate manner, just use google translate to translate the english version into the native language to see if everything is correct. Sometimes, I translate english into the Chinese by google translate, and find that the meaning is not what I want to expressed.
Other concrete examples and tips
logic flow
There is one paper to discuss the elasticity, we did not provide enough information at the beginning to discuss details of the elasticity, the reviewer provides a good logic flow to reorganize it.
Write one sentence explaining what elasticity is, then one sentence with the fact that it was identified as a key research challenge, and finally one sentence to explain what the present work focuses on.
Originally, we start with the sentence such as our works focuse on A, B, C and then use several sentences to explain the A B C in detail.
When listing the structure of the framework, we tend to use the overarching method and then the specific point. But when we try to argue sth, do not hurry to give out a specific conclusion quickly and directly. We need to get to that point step by step. Explain the reason clearly and then move to the results, instead of explaining that in a inverse way, other people might not catch the main point in this way.
the position of adv
Try to put the adv after the verb as much as possible. 习惯上adv是放在verb的后面的，尤其是only further之类的，这个和中文的顺序有些相反。
fianlly vs at last
在描述一个section的时候常常使用first, second, third类似的表述，之前自己认为at last 与 finally 是可以互相替换的，后来被别人指出来，这个at last 更多的是有一些negative的语义在里面(有一种discomfort的情绪在里面，比如after waiting for several hours, we buy the ticket at last)，所以使用finally在比较正式的论文中更合适一些。Finally与lastely是可以互相替换的，这个文章中说的比较细致。
from vs in
There is a expression such like “Z is a PhD student from CS department”, 之后被老师改成了 “Z is a PhD student in CS department”. 这里到底是in还是from自己之前也弄的比较模糊，这个文章 列了几个常见的from的用法，后面加表示具体地方的名词才是那种来自哪里的表述。一般都是一个地名，而CS department是机构的名称，这里使用in表示自己在这个机构里面，这样更合适一些。
其他的一些容易混淆的地方，比如on in at的区别，这个视频说的比较好。主要是粒度上的一些问题，还有一些管用的地方。
number of process vs process number
The process number is more souds like the process rank, if we want to express how many process in total, maybe the number of process is a more suitable word
left side figure
It is good to use figure on the left or figure on the right. Or just use the left figure or right figure.
others
一些比较好的替换的词，比如main research area is 可以润色成 primary research area is. 比如is suppoed to do sth 可以润色成 is expected to do sth 这个expected to do的口气更柔和一些，希望去做成什么事情，但是这个supposed to do某种程度上有一些should do sth的口气在里面，表示应该要去完成什么的样的事情，应该要如何如何。
show things make sense
It is common that one paper can have multi rounds iteration, when show other people about the wip work, remember to show them things that make sense, if the contents come from old data or sth that does not make sense, just comment the contents out and do not show it. This can save you a lot of energy for explaining things.
Terminology of insitu
在正式出版的书中 in situ 这里是不加hyphen的。而且相关的这个词出现的地方也用斜体进行了标注。类似的还有in prior。这些在实际的editing中经常用到，要特别留意一下。而且网上的文章里面把in-situ误写成in situ的例子还是比较多的，这里要特别留意一下。
Online vs Offline
For the parameter estimation of the model, there are online approach and the offline approach. This article explains a lot of details. From the paper’s perspective, do not too persist into the online method. Since from the research perspective, the accuracy of the model is more important and have more research value. You could always try to update the model and use it into an online scenarios which can recursively update the model parameters.
If there are some certainties of the system or the source data, you can always start with the offline model estimation approach (which is easier for most cases). Just collect a bounch of input data and the output results, and then train the model based on these data. That’s how it works in general.
The online approach might be only suitable for the reinforcement learning scenarios or the case that you can not store the large amounut of data.
This is also a good insight for the in-situ or post-processing approach. In most of the cases, the real-time manner (in-situ processing) is not the necessary one. It is just a way to do the things, but it is not the necessary one. So if you focuse too much on this specific way to do things, you may lose some key points. For instance of ML, the key point is develop the model that works as expected instead of doing the parameter in an online or offline manner.
Reply to reviewer’s feedback
The reviewer prefers to reply the feedback in a point by point manner. By this way, they can make sure the issue provided by them are fixed properly. Instead of using your logic to organize the revision letter and then add a (to R1 to R2), it is better to list clearly, this modification is targeted on which issue provided by which reviewer.
Some tools to do the revision
The grammaly can help us to check the naive typos.
The https://ludwig.guru/ can help us to check how the specific expression are used in all kinds of online documents, if you are not sure about specifc phrase, it is always good to check it here.
Another important thing is the google translate, try to let the google tranlator to tranlate the english paragraph into your native language, if everything looks correct and it is what you want express, your paragraph looks good. This is a really helpful tool.
Important principles
I took the writting lectures whole day from Professor George Gopen, it gave me different feelings about writting scientific articles. Taking down some important keyword and these key ideas should be used as a habbits to revise the code. Just like reviewing the merge request, when you read or write the article with these ideas in mind, the reading or writing process can become really different (Trying to cultivate this habbit during reviewing articles). These key word includeing:
“reader’s expectation (convention)”,
“topic sentences (context)”,
“stress position”,
“avoid backword link”,
“subject and verb need to be placed next to each others” (I have a bad writting habits sometimes, I like to write sentences such as: “For sth, it is … “ This is redoundant form, just jumping to the subject verb form direactly and writting can become more compact). By forcing your self consiering how to put subject and verb together, we may decrease the abuse for some verb such as “have”, “is” and the “there be” form.
“flow natually” etc.
One good article that summarizes these whole ideas can be founud here (this one is really good, expecially about the topic posision and stress position, five star).
Some really good point for my case is that, I tend to put the conclusion at the first and then explain the reason and say this is because… Which is not good habits, since it breaks the rule that we start with the context or topic and then put important thing at last. At least we should start from general to details.
There are all kinds of avalible videos from Professor George Gopen online. I will not go through details. Just trying to list several examples here and see how these concepts and principles are adopted here.
Exapmle 1:
It may need pay attention to know the different between topic sentences and stress sentences in scientific writting. For exmaple, “we can explain the results by two ways” this is topic sentences which is good to start at the paragraph “The A is less possible than B, because …”, this is the stress point and should be put at the end of the paragraph as the conclusion.
TOOD, list the example in the lecture tutorial
Reference
This is a really good one for Chinese students
https://arxiv.org/pdf/1011.5973.pdf
Some writting style references
https://www.computer.org/publications/author-resources/peer-review/magazines#writing
