开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 人工智能 -> 我的研究生论文的小总结 (以多标签方向为例) -> 正文阅读

[人工智能]我的研究生论文的小总结 (以多标签方向为例)

前言

9月份投了自己第一篇文章, 但是很大程度是老板带着完成. 这篇文章主要就把当时老板给出一些论文写作的要求和提示稍微总结了一下, 以便后续论文的产出~

主要结构回顾

Abstract
Introduction
Related work
The proposed approach
Experiment
Conclusion and further works

(下面给出的写作顺序是不一定的, 可根据自己的实际情况做出临时改进)

1.先写代码和搞伪代码

作为工科生, 在论文在打磨出来之前, 我们还是主要采用代码来完成一些基本的测试和想法.
往往会在代码跑出来的结果还比较可观的时候着手开始论文.
以我的第一篇的尝试来看, 可以先试着将算法关键部分的伪代码写出来.

\begin{algorithm}[tbh!]
	%\textsl{}\setstretch{1.8}
	\renewcommand{\algorithmicrequire}{\textbf{Input:}}
	\renewcommand{\algorithmicensure}{\textbf{Output:}}
	\caption{the name of algorithm}
	\label{algorithm: the label of algorithm}
	\begin{algorithmic}[1]
		\REQUIRE
			Input content.
		\ENSURE
			Output content.
        \STATE ...;
        \FOR {$1 \leq i  \leq n$}
    		\STATE ...;
            \STATE ...;
        \ENDFOR
		\STATE ...;
	\end{algorithmic}
\end{algorithm}

伪代码位于The proposed approach部分的相关算法的某个分支的位置.

当然, 写伪代码之前需要先搞清楚自己的算法的什么部分要用伪代码体现. 先要确定好自己的算法大体流程, 比如说某些可能采用神经网络的算法可能会先特征提取, 之后再输入到网络中训练. 这个过程中的特征提取就可以用伪代码体现出来.
伪代码并不是一个能完全代替所有算法部分的东西, 有时候我们为了说明好一个算法的流程可能还会使用多个伪代码.
网络训练是难以用伪代码描述的, 这部分不用写伪代码
机器学习有关的研究很多是逃不开训练 (training)与测试 (testing)的, 无论是在写算法的文字流程还是写算法的伪代码部分, 永远都不要将训练与测试的内容混合在一起写 ! (除了直推式学习: 预测样本事先已知)
伪代码中的公式最好是在论文中提前声明表示出来的, 在伪代码中不要独立地表现一个全新的公式.

2.通过伪代码, 慢慢完成The proposed approach

计算机方向的The proposed approach主要是对算法过程的描述.
之前先完成伪代码相当于是整理自己代码的一些关键地方的思绪. 之后根据这些思绪, 试着把算法的几个核心流程整理出来, 即algorithm decomposition.
举个例子, 对于一个数据集, 我们首先进行预处理, 这可能是一些特征提取或者特征分解. 然后将特征丢到一个特殊设计的网络中进行训练, 训练出一个完善的模型. 最后将我们的测试数据再丢到这个模型中, 完成测试.
上述这个过程可以分解为典型的三个过程: 特征提取->网络训练->模型测试
它们会构成The proposed approach的三个分支, 这些分支中又可以延伸出更多分支. 当然这只是一个例子, 具体还得看你的算法是什么.

在写The proposed approach的过程, 不要放过任何一个可能的创新点, 也许你只是在论文中提到了某种距离公式, 或者一种特殊的选点方案. 在文章中你都可以试着展开说, 从逻辑层面分析它的意义 (灌水). 如果这个方案有明显的效果, 后续在实现部分也可以基于这个小idea做个消融. (~~太好了, 论文又变长了~~)

在The proposed approach中的某些能拔高的地方, 即关注于某个算法设计的 “Why” 问题的时候, 我们不要沉溺于描述一些简单的事实, 也就是这种方案的表相, 而更应该体现the idea behind. 简单来说, 写出更多设计的理念.
没必要写出审稿人一眼看过去就能了解的东西, 要写出我们会用这个方案而不是其他的方案的够硬的idea.

3.随时更新的符号系统

从伪代码开始, 我们就可以时刻维护自己论文的符号系统了.
符号系统往往可以用一个表格来表示, 没必要用文字逐字逐句去描述它.
下面是一个常规的多标签系统的描述:
在这里插入图片描述

上下文的符号系统必须保持严格的统一, 若在上文出现了 $F(\boldsymbol{x}_i)$ , 后面不能理所应当出现 $F(\mathbf{X}_i)$ , 必须有必要的解释. 不能说: 上方是一个 $\mathbf{P}^{(k)}$ , 然后下面就变成了 $\mathbf{P}_{k}$ , 统一性非常重要.
符号系统的话, 最好可以采用向量+矩阵的形式, 向量尽量不要和集合混搭.
表明单个标签的取值二值性可以采用 $y_{ik}\in \{-1,+1\}^{n \times q}$

4.完成实验部分

实验的写法有很多, 但主旋律还是比较. 一个算法的可行性与高效性总是在与其他算法的外部比较中得到的. 使用评价指标的表格比较是一个常用的方案:

诸位作者们应当找到一些与自己算法目标与场景相同的算法 (场景: 主动学习还or监督学习? 目标: 有无处理缺值的技巧?), 然后在自己的机器上实现这些代码.
确定一些评价指标, 并写出这些相关评价指标API, 方便后续在不同的算法输出中套入这些函数; 同时, 找到一些领域内的数据集, 并按照这些数据集的特征来进行分类\管理. 实际上, 一个算法在不同数据集上的表现效果差异可能会反映算法的一些适应性, 因此这种分类是有必要的.
分别将 $n$ 个不同评价指标, $m$ 个不同数据集应用在我们的算法和 $q$ 个比对算法上.
最终我们可以得到 $n$ 个大小为 $\times q$ 个对比表格.
对这 $n$ 个结果表格进行最初步的数值分析, 可以直接用Mean Rank, 或者采用一些显著性办法例如Bonferroni-Dunn test (画CD Diagram图). 更多方法可以通过读相关论文来积累经验.

此外, 除了验证算法的可行性与高效性, 还有一个工作就验证算法中各个组件的有效性. 这个时候我们就要做内部比较, 常见的有消融实验 (Ablation studies). 消融实验就是把算法中那些很具有创新点的想法换成很简单的原始方法, 然后在不同的评价指标和数据集环境下去跑一遍, 并对比分析结果.

算法的复杂度分析也可以在这部分来做实验.
算法的复杂度分析是一个跨章的任务, 准确来说, 应该先在The proposed approach部分专门留一个章节来从算法设计细节上逐步分析复杂度.
而实验部分是用数据集的实际时间开销变化曲线图来验证在The proposed approach中分析的正确性.
(何为验证? 例如, 分析的复杂度是 $O(m^2n)$ ; 那么实验部分的图像表示的 $n$ 相关曲线是线性的, $m$ 相关曲线是二次的, 那么分析就正确)

关于实验部分若干实验的排列顺序, 主要遵循的原则是 : 重要的实验放在后面, 且先有内部比较, 再有外部比较. 因此上述实验方案的排列应该是: 复杂度分析实验->消融实验->评价指标比对.

最后, 实验部分的limitation和discussion.

limitation是通过实验效果来分析我们算法存在的缺陷. 有时候存在缺陷并不麻烦, 说出来就好了; 但是麻烦的是: 不知道算法的缺陷是啥; ~~而更麻烦的是, 你没发现的缺陷被审稿人发现了.~~
limitation当然也不局限于说我们的算法为什么不好, 还可以说说别人为什么好.
discussion就是对于实验结果的综合和分析. 所以一定要记住! 当你通过实验结果发现了一些特点, 一定不要立马就在表格或者图片下面评论, 要憋着! 全部留下来并整合到discussion中做个集中评价.
那么在给出实验结果的时候可以干什么呢? 可以说下我们的评价指标的优点\特点; 或者解释我们使用的数据集是什么, 从哪来的; 或者简单介绍对比的算法的特点, 以及它们的参数是如何设置的.

最后总结一句, 实验部分是个长跑, 非常耗人! 以我第一次的经验来看. 当你做完了一次完整的实验, 做出了一个excel表格之后. 你永远都不要幻想当前的实验结果一定就是最终结果了, 你不会知道你下一次你推翻这个结果再重做是什么时候.

5.完成摘要

偷个懒:
老板的这个写得挺好的!
https://blog.csdn.net/minfanphd/article/details/121404902
摘要的目的在于精炼, 每句都写得尽可能简单些 (当你不断暗示自己要写简单句的时候, 你的内容自然不弯弯绕绕了)
当然部分核心的句子还是要尽可能详尽, 至少要把我们的创新表达出来

6.搞定Introduction

如果论文已经做到这个部分了, 那么恭喜, 你已经可以不用去做太多技术向的事情了, 不用担心算法的效果的问题了.
但是很不幸的是, 大量的文笔和查论文的工作摆在你的面前了.

Introduction是你论文的缩略, 读者或者审稿人在看完你的Introduction后基本对你的文章就有一个大概的方向了. 因此这个部分一定要不遗余力地把文章中最核心的东西拿出来.
思路就是采用与摘要类似的节奏, 即摘要中的每一句都是我们Introduction中的一段的主题句.
句子长度来看, 每段不能太长, 每段应该是有5~10句, 100左右的的单词. (最多150)
计算机专业要学会在introduction中放出一张能大概囊括整个算法的一张图, 好的图一方面能抓人眼球, 另一方面可以诠释算法的大概过程, 或者解释算法的特征. 例如说下面这张图用非常强烈的色彩感一下抓住了人们的眼球, 紧接着人们的注意力从图中的色彩框挪到了右边的彩色字体, 在引导下阅读了图中文字, 从而了解到了本篇算法的目的是处理有噪声情况下的多标签问题.

图来自多标签算法PML-NI
Xie, M.-K., & Huang, S.-J. (2022). Partial multi-label learning with noisy label identification. IEEE Transactions on Pattern Analysis and Machine Intelligence, (pp. 1–12).

在这里插入图片描述
下面以某篇论文的Introduction的流程为例来看下Introduction的特点 (注意, 写法是灵活, 下面仅供参考):

第一段: 说明研究方向在实际领域的应用 (7句).
首句是概述性句子. 之后采用两句式, 即一句提到一个应用方向 (附上这个方向的论文)并做基本描述, 然而第二句进一步解释我们的技术在这个方向上的应用特点/or方式/or共享 (可由引用的论文中的内容来描述这部分). 大概举例三个例子, 也就是使用三次两句式.
第二段: 说明研究方向面对的一些领域的有特点的难题 (6~9句).
首句是概述性句子. 之后采用单句式, 即一句话用逗号分割, 前面用"For XX" 来引出面对的问题, 后面提出: “XX算法 (给出引用)可以通过 XX 技术或方法来解决这个问题”
领域内的难题可以多提一点, 这就是为什么相比第一段的两句式, 这里我们用的一句式. 当然如果你实在想不到那么多难题, 你也可以在单句式之后再想一个能解决上一句问题的算法. “Meanwhile, XX and XX \cite{…} also use XX to deal with this issue”.
第三段:列出我们要解决的问题. 如果你的论文是在某一个算法的基础上改进得到的话, 这里就可以写出这个基准算法的优点与缺点. 第一句大致介绍这个算法, 后面五句可以三句优秀两句不足
若是自己设计的一个无参考的算法, 那么可以简单介绍下算法面对的问题是什么, 业界关于这方面的现状.
算法的基本方法论先不急着在这里说.
第四段: 写出算法方法论 (How). 核心要把自己算法的方法论说清楚, 摘要中我们用少量的句子说明了方法论, 现在就是把其详细地说出来, 一句一点全盘拖出但又不拖泥带水. 这一段可能是整个Introduction中最长的一段, 也是最重要的一部分.
我们的开局一张图 就可以放在第四段的前面, 先以图的形式给读者展示算法的大概结构 (或特征), 并且用一两句来简单完成图的基础介绍.
解释完图后, 直接一句 “The contribution of this algorithm is XXX-fold.” 来引出一个大枚举 (\begin{enumerate}[$\bullet$] ... \end{enumerate}), 枚举的每点都是一段, 且每段都关联论文中算法方法论的一个分支. 最省脑子的做法就是: 每个分支都与The proposed approach中的分支一一对应.
- 在写每段的方法论时不能一股脑紧扣How来写, 必要之时要写出背后的思想, "how"是其次, "why"才是更高级的东西!
- 别人不是想看你是怎么做的, 而是想知道你的方案有什么特色, 不同. 希望在写引言的这部分方法论的时候, 能着体现我的这种idea感~
第五段: 给出实验的大体内容
这段可能是Introduction中第二简单的一段. 第一句说明实验部分用的了多少个数据集, 几个评价指标就好了.
后续内容用一句" Results show that: "引出, show的内容中放几个在实验部分的discussion中列出的比较重磅的, 引人注目的, 体现算法特点的结论就好了 (稍微改动改动, 不要用原句).
第六段: 给出后续论文的基本结构.
这段可能是Introduction中最简单的一段, 用几个经典句子衔接一下就好了.
Section \ref{section: …} introduces…
Section \ref{section: …} presents…
Section \ref{section: …} presents
Finally, Section \ref{section: …} draws out …

7.搞定Related Work

在有些论文中, Related Work第一部分可能是Data model, 关于这个详见第3点.
Related Work中的重头戏是对于前人算法的集中描述, 要写好这部分需要事先确定自己论文研究方向中的那些已有的流派, 然后选择其中那些与我们论文的方向交集最多的流派, 将这些流派展开描述, 一个流派用一段去写.
每段第一句是总述这个流派的重要性, 特征, 方法, 然后后续每句都引用一篇论文的算法来论述这个流派的实际成果, 每句的论述着重用简练的语言去描述算法的主要技巧. (可以视为对这个算法的评述)
尽可能地, 一个算法只用一个句子. 以及, 段内多个算法的枚举按照一定的逻辑顺序, 可以是时间, 也可以算法本身的某个特征点的发展顺序.

某些流派可能还会继续细分, 这个时候请在段中活用:“first”, "second"等词去划分流派内论文, 并且在部分节点处做小总结来实现起承转合, 确保段内文字描述逻辑是严密的.
每个流派写150个单词, 至少两个流派.
流派中的算法尽可能些新的算法.

8.总结与展望

总结与展望中说说我们算法的优点, 同时也说说算法的不足与还未解决的问题. 后者将是主要要写的.
还未解决的问题可以通过分点枚举的方式表明出来, 对于每个还为解决的内容, 我们需要承认其复杂性, 同时我们也得表明我们今后直面他们的勇气.
可以说 “这都是我们下一步即将研究的问题” , “Hence we are also planning to enter this challenging and promising field.”

9.文献引用问题

在文内引用时, 使用\cite{}. 具体细节上请注意:

文中单句的多个引用, 不能使用多个中括号, 还是得使用单个中括号. 例: [1][2][3]是错误, [1, 2, 3]是正确的.
单句的多个引用时, 中括号内部的引用必须有一定的顺序, [2, 3, 1]是错误的, [1, 2, 3]是正确的.
在编写参考文献列表, 建议使用bib文件.
在你的tex文件中需要引入引用表的地方写下如下代码:

\bibliographystyle{model5-names}
\bibliography{XXXX}

这里的model5-names是一个风格文件的名称, 它对应于.tex所在根目录下的model5-names.bst
不同期刊会议可能会给出自己的bst文件.
而XXXX是具体的bib文件, 它对应于.tex所在根目录下的XXXX.bib
.bib是我们实际应用论文需要修改的文件
其中关于文章期刊的引用类似于:

@article{Shu-2022-IS-IMCC,
	title     = {Incorporating multiple cluster centers for multi-label learning},
	author    = {Senlin Shu and Fengmao Lv and Yan Yan and Li Li and Shuo He and Jun He},
	journal   = {Information Sciences},
	volume    = {590},
	pages     = {60--73},
	year 	  = {2022}
}

关于会议的引用类似于

@inproceedings{Liu-2017-SIGIR-Deep,
	title	  = {Deep learning for extreme multi-label text classification},
	author	  = {Jingzhou Liu and Wei-Cheng Chang and Yuexin Wu and Yiming Yang},
	booktitle = {SIGIR},
	pages     = {115--124},
	year	  = {2017}
}

关于bib文件中的错误引用问题可以参考下面连接:
https://blog.csdn.net/minfanphd/article/details/121952396
我这里主要强调下我踩过的坑:

有很多会议的名称都喜欢用缩写, 例如IEEE International Conferenceon Data Mining --> ICDM
IEEE International Conference on Systems, Man and Cybernetics --> “IEEE SMC”
Proceedings of the 40th international ACM SIGIR conference on research and development in information retrieval --> SIGIR
(似乎? 基本上是个会议好像都要缩写)
文章和期刊千万不要缩写.
国人作者的姓名先写姓, 再写名. (实在不知道怎么写, 打开论文看作者名称就好了)

要注意, 有些国人的名有两个字的时候喜欢加"-": Xing-Yi Zhang, 有的则喜欢Xingyi Zhang. 因此在引用时不要搞错了.
bib文件中的}后不要忘记打逗号哟
期刊文字和会议中的.bib文件中只有year中能加年份, 其余在期刊文字和会议名称中不能加年份. (不然就重复了)
不要轻信一些论文检索网站的bib引用按钮, 当然, 用是可以用, 但是最多是一个参考. 最好的引用方式就是下载原文然后按照原文的格式改.

杂记 (可随时更新)

符号系统方面, 若要表示某个标签 $k$ , $l_k$ 可能并不是很好看, 用 “The label $k$ is …” 就好了
向量之间进行连接请用双竖线表示: $\mathbf{Y} = \{\boldsymbol{y}_1|\boldsymbol{y}_2|\boldsymbol{y}_3\}$
用词上注意不要用口语, 例如"To put it simply这种"
常规句子尽可能不要用祈使句, 老老实实写上主语, 主谓宾or主系表才是王道.
工科 (更具体来说, 计算机)的论文更多注重说清楚一件事情, 因此我们在描述一个idea, 说明一个流程的时候不应当弯弯绕绕. 尽可能不要写长难句, 有想法的话一个句子一个句子去写, 单个句子的用词不要太长. 用几个小句子讲一个清晰的故事
(~~之前因为考研英语的原因, 感觉论文不该是句句长难句吗? 实际来看好像说清楚更好~~ )
latex写论文注意一个点号回个车
公式也是句子中的一部分, 若公式是句子的结束, 那么在末尾就要加点号. 如果公式写出来后我们还要用where去介绍这个公式, 那么就在公式后加逗号. 若公式是个分段函数的表达, 第一个条件之后还需要加一个分号

此外某些成对的公式其实也可以分开写出来, 这样也利于描述:

什么时候需要加逗号, 点号? 你只要把公式当做句子的一部分, 然后你自然就知道了.
论文中的图片引用描述是: Figure \ref{figure: xxx}, 在你需要引用的原图片附近加\label{figure xxx}
论文中的公式引用描述是: Eq. \eqref{equation: xx}, 在你需要引用的公式附近加\label{equation: xx}
论文中的伪代码描述是: Algorithm \ref{algorithm: x}, 在你需要引用的伪代码附近加\label{algorithm: x}
若有公式并列要以用: Eqs. \eqref{…}, \eqref{…} and \eqref{…}, 表格与伪代码类似.
枚举的latex:
带序号枚举如下, 若改为[a)]为字母枚举, 若改为[$\bullet$]为 $\bullet$ 枚举

\begin{enumerate}[1)]
	\item ...
	\item ...
\end{enumerate}

句子! 一定要有! 主! 语!
若要在一个句子的后面加括号, 句子和括号之间一定要有空格

Instance	right or wrong
This is a sentence (for example)	√
This is a sentence(for example)	×

论文中没必要专门用个 “Note: XXX” 这个句子来表示需要注意的内容, 之间用一个常规的句子说明就好了!
无论是在使用图片还是表格, 其\begin{figure}[]后方都有一个中括号表达式, 其内部的相关描述能影响图片或表格的固定与浮动位置. 我的老板建议我用[tbh], [tbh]可以让图片基于全局灵活调整, 这样文章中不会出现一大段一大段的白色空白.
若在一个算法的片段中我们需要引入一个核心图片来介绍这一段, 我不应该藏着掖着在最后放出这个图片. 相反地, 我们应当在片段的开始就开门见山地引出这个图片, 并且在文章的开始就对这段进行描述. (导师: 这些核心图片有关的描述就是骨头, 其他的都是肉或膘~~灌水的~~ )
从一个新的章节 $X$ 开始, 每节应当有个简单的介绍, 避免新的 $X$ 章开始后立马开始 $X .1$
一些重要的, 有原创性概念, 例如一些评价指标, label specific feature… 我们要找出第一个提出的论文; 一些常规的研究方向内的特征性的东西, 比如极限多标签中的标签和数据稀疏性, 要印证这些内容需要引用那些最新的, 顶刊顶会的论文.
公式不能单独从一个句子中冒出来, 他和句子之间必须有详解, 常见的衔接有"i.e."
latex论文的版本管理是一个非常关键的问题, 建议一天的任务完成后, 第二天直接把第一天的文件夹拷贝个新的, 更新版本号然后继续做. (可以用个专门的txt文档来记录每天添加的内容, 相当于一个更新日志log, 这样我们在出现错误时更快更准确回推到旧版本) (~~当然如果你用git当我没说~~ )
在给出一个表格或者图片, 后续要对这个图片或者表格做介绍的时候, 直接用Table \ref{table: XX}或者Figure \ref{figure: XX}做主语就好了. 直接明了, 不拖泥带水. 这样的文字更硬, 能方便读者直接找到图片的位置与解释.
写文章更重要是突出内容, 包装方面尽可能标准化
在说明一个内容点或者公式的时候, 若整体内容很少. 我们可以使用倒序的方式, 直接摆出公式或者内容核心, 然后用 “where” 来说明内容, 从总到分. 但是若内容很多, 必须从头到尾去叙述, 从分到总.
实验部分涉及一些评价指标, 对于期刊论文, 讲究complete, 即我们不需要看另外的论文就能读懂. 因此需要对于一些评价指标, 我们的论文必须做出必要的解释! (这个解释必须用自己的话去描述)
为保证tex的通用性, 不要用些奇奇怪怪的包, 因为期刊系统不一定支持. 图表控制尽可能简单.
初稿挤一点没有关系, 因为真正的版面字体要小些. (交稿后, 编辑会帮你完成了期刊的适应性编辑)
tex首部的\documentclass[preprint]{elsarticle}替换为\documentclass[5p]{elsarticle}就可以将单排的论文变为双排的排版. 其中, 表格\begin{table}改为\begin{table*}就可以将让表格在双排的排版中占据两排.
表格中的一些常规的提示字可以在多个类似的表格标题中重复写, 比如说: “Bold indicates best performance, italics indicates second best.”
\vspace与\hspace要尽可能少用, 因为之后编辑在调整你的论文时, 这些部分会让他们发疯.
当表格没有居中的时候, 其实没必要用\centering. 可以通过调整表格的宽度实现居中的调整.
在论文中如果要论述多个内容时, 分点永远要比不分点看着让人清晰明了. (关于这个, 实际上并不局限于论文)
甚至有时候, 必要的表格梳理也是能利于流程的理解:
在开始一个多分支的大章节时(X.1, X.2 …), 可以在X与X.1交界的地方用多个分点的形式详细阐述本章我们大概会讲的内容, 相当于先读者一个预告. 这种方式在The proposed approach中的算法分解部分是非常重要的.
为了说清楚一个东西, 宁愿去多写一些分支! 假如: 你在写算法分解中的某一部分时内容过多且有明显的分阶段的语言, 那么试着再去把这部分细化为更小的分支.
“分支这种东西能更好地说清楚结构”.
论文中语言描述在层次上可以分为Why, What, How. 在精神上, 这三者之间的关系是 Why > What > How. 也许我们能很自然想到一个算法的处理流程, 但是说清楚这些算法的本质是什么, 乃至于为什么要在用这个算法才是真正困难的东西. 说好Why和What需要作者在设计算法时有足够的motivation, 而motivation需要阅读一定的论文和算法来积累.
(待补)

术语积累 (可随时更新)

My 老板 said that:
如果一个单词在别的论文中没用过, 就别用它 !

uniform 往往在论文中很少有 “共同的” 含义, 往往来说它的含义是均匀的, 例如 uniform distribution
标签矩阵中, 一个标签中的+1与-1的分布是非常不均匀的 (负的个数远大于正的). 这种问题在单标签的多分类中被描述为class-imbalance居多, 但是多标签, 称之为label sparsity更恰当.
某物 象征着/体现着 XX --> symbolize XX不是很好. 而使用 “被认为是” --> known as XX 会更好. (或者embody似乎也行).
control ratio parameter 是较为冗余的, 实际上ratio就有参数的含义, 因此用control ratio就可以
“确定一个提取了特征的矩阵…” 并翻译为"confirm"是不恰当的. 论文中更喜欢用 “构造了一个提取了特征的矩阵…”, 译为 “construct”
永远! 不要! 在! 句首写 And.
欧式距离首字母用大写: "Euclidean distance "
在介绍自己算法的时候, 很多确定的板上钉钉的操作, 少用possible这种不确定的词. “an possible example”–>“an example”
自己写的句子如果不太确定, 就在翻译软件中倒一下, 多次翻转几下. (不要对自己写的句子太自信)
在写神经网络的时候, 不要说 " 网络的维度可以用 $n$ 个结点代表 " – “input dimension of the network will be represented by n nodes.” 这太弯弯绕绕了, 应当直接了断说: " 网络有n个输入结点 " – “Network has n input nodes.”
“A describe B” --> “A is determined B” 是主动变被动. 英语文章总的来说是喜欢后者.
“A represent B” --> “A correspond to B” 代表着可改为对应于.
“highlight” --> “embody” 关于强调, 后者也许会更好.
XX参数是由下述公式给出常用 “XX is given by \begin{equation} … \end{equation}”.
公式的连接, Let …(贴个公式)…, then …(公式描述或者贴个新公式)…
(待补)

附录

我的头文件部分:

便于之后直接copy

\documentclass[preprint]{elsarticle}
%\documentclass[final,5p,times,twocolumn]{elsarticle}
\usepackage{rotating}
\usepackage{natbib}
\usepackage{multirow}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{latexsym}
\usepackage{threeparttable}
\usepackage{algorithm}
\usepackage{algorithmic}
\usepackage{array}
\usepackage{graphicx}
\usepackage{epstopdf}
\usepackage{subfigure}
\usepackage{url}
%\usepackage{stmaryrd}
\usepackage{bm}
\usepackage{color}
\usepackage{xcolor}
\usepackage{comment}
\usepackage{tikz} % 用于latex画图整花活
\usetikzlibrary{decorations.pathreplacing} % 用于latex画图整花活
\usepackage{float}
\usepackage{caption}
\usepackage{tabularx}
\usepackage{subfigure}
%\usepackage{subcaption}

\usepackage{chngpage}

\usepackage{array}

\DeclareMathOperator*{\sign}{sign}

\newtheorem{property}{Property}
\newtheorem{example}{Example}
\newtheorem{proposition}{Proposition}
\newtheorem{lem}{Lemma}
\newtheorem{rem}{Remark}
\newtheorem{corollary}{Corollary}
\newtheorem{problem}{Problem}
\newproof{proof}{Proof}
\newtheorem{theorem}{Theorem}
\newdefinition{definition}{Definition}
\newtheorem{assumption}{Assumption}
\newtheorem{conj}{Conjection}
\DeclareMathOperator*{\argmax}{argmax}
\DeclareMathOperator*{\argmin}{argmin}
\newcommand{\tabincell}[2]{\begin{tabular}{{}#1@{}}#2\end{tabular}}

\hyphenation{classifi-cation cha-llenge costs correla-tions discrimi-nant}