【不要合入】以 Conv1D 为例给出一个成对 API 的减少冗余的写法

[BrilliantYuKaimin]

在 paddle 的 nn 目录下，有很多成对的 API，比如 nn.Conv1D 和 nn.functional.conv1d。目前飞桨 API 文档中对这些成对 API 的描述存在大量冗余（在两个文档中存在几乎同样的内容）。在 PyTorch 的文档中，函数的文档会请读者从类的文档中获取更多细节。但我更建议在类的文档中请读者从函数的文档中获取更多细节，因为类的实例其实是对应函数的一个特例（调用类的实例的 forward 方法时只需要给出输入，而不需要再指出其他参数）。

这个 PR 以 nn.Conv1D 为例，给出一个减少重复内容的写法。调整的方面有：

• 对类的描述只说这个类的实例是对应函数的特殊情形。
• 简化与对应函数同名的参数的描述。
• 删去“形状”，因为形状应当是一个算法的前置条件（precondition）和后置条件（postcondition）的一部分，所以应该在对应函数中给出。
• 将“属性”更名为“可学习参数”。
• 删除“返回”（Conv1D 本身没有写返回，但其它的类会有）。类的返回当然是类的实例，没必要多说一句。

[paddle-bot[bot]]

感谢你贡献飞桨文档，文档预览构建中，Docs-New 跑完后即可预览，预览链接：http://preview-pr-5112.paddle-docs-preview.paddlepaddle.org.cn/documentation/docs/zh/api/index_cn.html 预览工具的更多说明，请参考：[Beta]飞桨文档预览工具

[SigureMo]

在 PyTorch 的文档中，函数的文档会请读者从类的文档中获取更多细节。

其实我认为这样是有道理的，因为对于使用深度学习框架组网的人来说，会大量使用 class 的 API 而不是 functional 的 API，如果说把主要内容放到 functional 的话，那么必然会使用户在大多数情况下先访问 class API 文档，之后再访问 functional 的，用户在阅读体验上并不是很好。

当然，从内容排布的逻辑上来说，确实 class API 作为一个 wrapper 直接引用 functional 是更合理的，但我觉得也应当考虑下两者使用频率的问题。

[Ligoml]

很好的建议，飞桨团队未来将会发起一次评审，具体定义这类成对出现的API文档写作规范，并发起大规模的修改~ 具体包括：

• class类与function类API文档的区别
• forward等方法的写作规则
• 如何在避免冗余的情况下讲清楚两个API的使用
• 未成对的API写作方案
• 存量修改与增量控制

后续进度会持续同步给大家，一起让paddle的API文档更易读易用呀