category: 外文翻译

本文翻译自： 《Take advantage of the overloaded operators》， 如有侵权请联系删除， 仅限于学术交流， 请勿商用。 如有谬误， 请联系指出。 和 Numpy 一样， 为了使代码可读性更强， 更容易绘制一个计算图， TensorFlow 重载了很多 python 中的运算符。 **切片（slice）**操作是众多重载运算符中的一个， 它可以使得索引张量变得很容易： z = x[begin:end] # z = tf.slice(x, [begin], [end-begin]) 但是在使用的时候还是需要注意。 切片操作的效率非常低， 因此最好避免使用， 特别是在切片的数量很大的时候。 为了更好地理解这个操作符有多么地低效， 我们先观察一个例子。 我们想要人工实现一个对矩阵的行进行 reduce 操作的代码： import tensorflow as tf import time x = tf.random_uniform([500, 10]) z = tf.zeros([10]) for i in range(500): z += x[i] sess = tf.Session() start = time.time() sess.run(z) print("Took %f seconds." % (time.time() - start)) 在我的 MacBook Pro 上， 这段代码执行了 2.67 秒！ 如此耗时的原因是我们调用了切片操作 500 次， 这个操作非常缓慢！ 一个更好的选择是使用 tf.unstack() 操作去将一个矩阵切成一个向量的列表， 而这只需要一次就行！ z = tf.zeros([10]) for x_i in tf.unstack(x): z += x_i 这个操作花费了 0.18 秒， 当然， 最正确的方式去实现这个需求是使用 tf.reduce_sum() 操作： ...

本文翻译自： 《Feeding data to TensorFlow》， 如有侵权请联系删除， 仅限于学术交流， 请勿商用。 如有谬误， 请联系指出。 TensorFlow 被设计用于高效地处理大量数据。 所以你需要记住的是， 千万不要“饿着”你的 TF 模型， 这样才能得到最好的表现。 一般来说， 有三种方法可以给你的模型“喂”数据。 常量方式（Constants） 最简单的方式莫过于直接将数据当成常量嵌入你的计算图中， 如： import tensorflow as tf import numpy as np actual_data = np.random.normal(size=[100]) data = tf.constant(actual_data)12345 这个方式非常高效， 但并不灵活。 一个很大的问题就是为了在其他数据集上复用你的模型， 你必须要重写你的计算图， 而且你必须同时加载所有数据， 并且一直保存在内存里， 这意味着这个方式仅仅适用于小数剧集的情况。 占位符方式（Placeholders） 可以通过占位符(placeholder)的方式解决刚才常数喂养网络的问题， 如： import tensorflow as tf import numpy as np data = tf.placeholder(tf.float32) prediction = tf.square(data) + 1 actual_data = np.random.normal(size=[100]) tf.Session().run(prediction, feed_dict={data: actual_data})1234567 占位符操作符返回一个张量， 他的值在会话中通过人工指定的 feed_dict 参数得到(fetch)。 也就是说占位符其实只是占据了数据喂养的位置而已， 而不是真正的数据， 所以在训练过程中， 如果真正需要使用这个数据， 就必须要指定合法的 feed_dict， 否则将会报错。 通过 python 操作（Python ops） 还可以通过利用 python ops 喂养数据： def py_input_fn(): actual_data = np.random.normal(size=[100]) return actual_data data = tf.py_func(py_input_fn, [], (tf.float32))12345 python ops 允许你将一个常规的 python 函数转换成一个 TF 的操作。 ...

本文翻译自： 《Scopes and when to use them》， 如有侵权请联系删除， 仅限于学术交流， 请勿商用。 如有谬误， 请联系指出。 在 TensorFlow 中， 变量(Variables)和张量(tensors)有一个名字（name）属性， 用于在符号图中标识它们。 如果在创建变量或张量时未指定名称， TensorFlow 会自动为您指定名称： a = tf.constant(1) print(a.name) # prints "Const:0" b = tf.Variable(1) print(b.name) # prints "Variable:0" 您可以通过显式指定来覆盖默认名称： a = tf.constant(1, name = "a") print(a.name)# prints "a:0" b = tf.Variable(1, name = "b") print(b.name)# prints "b:0" ...

本文翻译自： 《Understanding static and dynamic shapes》， 如有侵权请联系删除， 仅限于学术交流， 请勿商用。 如有谬误， 请联系指出。 TensorFlow中的张量具有静态形状属性， 该属性在图形构造期间确定。 静态形状可能未指定。 例如， 我们可以定义一个形状张量[None， 128]： import tensorflow as tf a = tf.placeholder(tf.float32, [None, 128]) 这意味着第一个维度可以是任何大小， 并将在 Session.run() 期间动态确定。 您可以按如下方式查询Tensor的静态形状： static_shape = a.shape.as_list() # returns [None, 128] 要获得张量的动态形状， 可以调用 tf.shape 方法， 它返回一个给定张量代表的形状： dynamic_shape = tf.shape(a) ...

本文翻译自： 《Broadcasting the good and the ugly》， 如有侵权请联系删除， 仅限于学术交流， 请勿商用。 如有谬误， 请联系指出。 TensorFlow 支持广播元素操作。 通常， 当你想做加法或乘法的运算时， 你需要确保操作数的形状(shape)是匹配的， 例如： 你不能将一个形状为[3, 2]的张量和一个形状为[3, 4]的张量相加。 但是， 这里有一个特殊情况， 那就是当你的其中一个操作数是一个具有单独维度(singular dimension)的张量的时候， TF 会隐式地在它的单独维度方向填满(tile)， 以确保和另一个操作数的形状相匹配。 所以， 对一个[3, 2]的张量和一个[3, 1]的张量相加在 TF 中是合法的。 import tensorflow as tf a = tf.constant([ [1., 2.], [3., 4.] ]) b = tf.constant([ [1.], [2.] ])# c = a + tf.tile(b, [1, 2]) c = a + b 广播机制允许我们在隐式情况下进行填充（tile）， 这种操作可以使得我们的代码更加简洁， 并且更有效率地利用内存， 因为我们不需要储存填充操作的结果。 一个可以表现这个优势的应用场景就是在结合具有不同长度的特征向量的时候。 为了拼接具有不同长度的特征向量， 我们一般都先填充输入向量， 拼接这个结果然后进行之后的一系列非线性操作等。 这是各种神经网络架构的常见模式： ： a = tf.random_uniform([5, 3, 5]) b = tf.random_uniform([5, 1, 6]) # concat a and b and apply nonlinearity tiled_b = tf.tile(b, [1, 3, 1]) c = tf.concat([a, tiled_b], 2) d = tf.layers.dense(c, 10, activation = tf.nn.relu) 但如果利用了广播机制， 这种操作就可以更有效地完成。 举个例子， 因为我们知道$f(m(x+y))=f(mx+my)$的事实， 所以我们可以分别进行线性操作， 并使用广播进行隐式连接： ...

本文翻译自： 《TensorFlow Basics》， 如有侵权请联系删除， 仅限于学术交流， 请勿商用。 如有谬误， 请联系指出。 TensorFlow 和其他数值计算库（如 NumPy）之间最显著的区别在于 TensorFlow 中的操作是基于符号运算的。 这是一个强大的概念， 它允许 TensorFlow 执行命令式库（如 NumPy）所不能做的所有事情（例如， 自动区分）。 但这也要付出更大的代价。 在我我试图揭秘 TensorFlow， 并提供一些指导方针和最佳实践， 以便更有效地使用 TensorFlow。 让我们从一个简单的例子开始， 我们要乘以两个随机矩阵。 首先， 我们看一个在 NumPy 完成的实施： import numpy as np x = np.random.normal(size=[10, 10]) y = np.random.normal(size=[10, 10]) z = np.dot(x, y) print(z) 现在我们在 TensorFlow 中执行完全相同的计算： ...

这篇是导师给的论文，因为有随手删文件的习惯，所以把这篇文章发布到掘金社区留作备份，原文地址为：Automatic Inference of Code Transforms for Patch Generation.，本人目前翻译功底较差，如果有小伙伴觉得翻译的有问题，希望在评论区指出，大家共同进步 😊 论文：Fan Long, Peter Amidon, and Martin Rinard. 2017. Automatic Inference of Code Transforms for Patch Generation. In Proceedings of 2017 11th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering, Paderborn,Germany, September 4-8, 2017 (ESEC/FSE’17), 13 pages. https://doi.org/10.1145/3106237.3106253 摘要 我们提出了一个新的系统 Genesis，该系统能够处理人工的补丁来自动化推理代码转换，用于自动化补丁生成。我们呈现的结果描述了 Genesis 推理算法和完整的 Genesis 补丁生成系统在来自 372 个真实的 Java 项目的补丁和缺陷上工作的有效性。据我们所知，Genesis 是第一个用于自动推理补丁生成转换或从先前成功的补丁空间中搜索候选补丁的系统。 ...

原文地址：13 Reasons Why you should choose/ consider to move to Flutter 13 个你应该转向 Dart 并且选择或者学习利用 Flutter 去开发你的下一个 app 的理由。 如今的企业需要在选择移动技术时做出关键选择。他们不断的测试和评估技术，以求不论用户使用什么移动设备或操作系统都能有强大的数字体验。企业如果不能提供易于使用的产品和服务，那么无论使用何种渠道或设备，都有可能落后于竞争对手。 目前面临的挑战便是跨平台应用的开发存在问题。在某些情况下，尽管开发人员尽了最大努力，其用户体验仍然落后于原生 app 。近年来，我们看到了各种移动框架的出现，如 React Native、Xamarin 和 AngularJS ，它们帮助我们更容易地产生较好地数字体验。最近我们看到一个新玩家加入了这场游戏——谷歌的 Flutter。 从内部来看，Flutter 看起来像是谷歌各种技术和概念的大杂烩，然而却产生一个不可思议的强大的移动框架。它是基于 Dart (谷歌的内部编程语言)开发的，它可以让 Flutter 访问 Skia 图形库，而这正是 Chrome 浏览器所使用的。除此之外，Flutter 与谷歌的 Material Design 规范紧密结合；其中最著名的便是 Android 用户已经熟知的“卡片图案”。 让我们看看 13 个选择 Flutter 作为你的开发环境甚至可以选择它开始你的职业生涯的理由， 1. Flutter 克服了传统跨平台的限制 长期以来，创建真正的跨平台方法一直是技术顾问的苦恼所在，他们厌倦了为同一产品制作多个版本。但是，实际上，跨平台应用的用户体验通常落后于原生 app，因为你经常需要即时编译 JavaScript 来构建 UI 体验。 使用 Flutter，你不仅可以拥有“一次编写”的优势，还可以创建高性能的“原生”体验，因为 Flutter 应用程序是提前编译出机器可执行的二进制文件。它克服了其他跨平台方法中的一些常见问题。 2. 开发人员的生产力提高了十倍 ...

本文翻译自： 《The Machine Learning Race Is Really a Data Race》， 如有侵权请联系删除， 仅限于学术交流， 请勿商用。 如有谬误， 请联系指出。 那些想让 AI 成为差异化因素的企业需要从可选数据集中抽取——这些数据集可能是他们自己创建的. 如果你愿意这么说的话， 机器学习或人工智能已经成为一种商品。 那些急于定义和实现机器学习的企业惊讶的发现， 实现用于使机器智能的处理数据集或问题的算法是比较容易的部分。 从谷歌的开源机器学习框架 TensorFlow 到微软的 Azure 和亚马逊的 SageMaker， 有一大批强大的即插即用解决方案， 可以轻松地完成繁重的编程工作。 不过， 数据不但没有被商品化， 反而正在成为机器学习竞赛中的关键差异化因素。 这是因为好的数据并不常见。 ...

“微服务架构是一种将单体应用程序开发为一套小型服务的方法。”——马丁 · 福勒。 首先，我们需要明白什么是单体架构。因此，我将向你展示如何修改它的域,，以便为微服务架构做好准备。最后，我将会简要地告诉你微服务架构的基础知识，并讨论其优缺点。 单体架构 每一种非垂直拆分的架构都是单体架构。软件设计中的垂直拆分意味着将应用程序划分为更多可部署的单元。这并不意味着单体架构不能水平划分。 单体这个词指的是软件的体系结构是由一个后端单元组成。我之所以说后端，是因为我认为单体架构可以在具有多个 UI（如 Web 和移动设备）的同时，仍然可以被看作为一个整体。 组件之间的通信主要通过方法的调用。 如果你的前端和后端是在物理上隔离的，但是它们仍然是一个整体，例如 API 和 Web 客户端。 除非你将后端划分为更多部署单元，否则在我看来你依旧是在使用单体架构。 单域模型 “域是计算机程序的目标主题领域。 形式上，它代表特定编程项目的目标主题。”—— 维基百科 用我的话说，域就是软件存在的原因和目的。我在 3 Domain-Centric Architectures Every Software Developer should Know 这篇文章中写了有关域的几个观点。 下图是一个将在线商城域可视化的结果。 Sales 和 Catalog 子域包含单个的 Product 实体。这种做法是不可取的，因为这将导致一个地方出现更多的问题。这违反了关注点分离原则。 强迫一个实体承担更多的责任，显然是不合理的。实体在这两种上下文中都包含未使用的属性。Sales 不需要知道产品的类别，并且对于 Catalog 来说，知道 Product 是如何将信息传递给客户并没有任何用处。 为了避免这个问题，我们需要找到 Sales 和 Catalog 上下文的边界来将它们分开。这就引出接下来要说的限界上下文。 限界上下文 限界上下文是上下文的边界，参考 [Idapwiki.com](https://ldapwiki.com/wiki/Bounded Context) 要指定限界上下文，我们需要识别出一个模型仍然有效的上下文范围。 我们可以通过对域中的每个实体问一个简单的问题来验证模型，即：这个实体对于哪个上下文有效？ 当一个实体对多个上下文有效时，那么它应该被划分到多个上下文中。每个实体都具有与上下文相对应的属性。这一步结束后，你的应用就准备好迁移到微服务架构了。 ...