Glue

R dplyr: rowwise + mutate (+glue) - how to get/refer row content?

由 别等时光非礼了梦想. 提交于 2020-01-25 00:38:08
问题 The simple example of input data: dataset <- data.frame("part1" = c("a", "b", "c"), "part2" = c("x", "y", "z"), "caption" = c("{part1} {part2}", "{part2} {part1}", "{part2} {part1} {part2}"), stringsAsFactors = F) Expected results: # A tibble: 3 x 3 part1 part2 caption <chr> <chr> <chr> 1 a x a x 2 b y y b 3 c z z c z The below code doesn't work, because . refers to the whole dataset , instead of data of the whole row content: dataset %>% rowwise() %>% mutate("caption" = glue::glue_data(.,

Text Summarization Evaluation - BLEU vs ROUGE

由 穿精又带淫゛_ 提交于 2020-01-11 16:37:14
问题 With the results of two different summary systems (sys1 and sys2) and the same reference summaries, I evaluated them with both BLEU and ROUGE. The problem is: All ROUGE scores of sys1 was higher than sys2 (ROUGE-1, ROUGE-2, ROUGE-3, ROUGE-4, ROUGE-L, ROUGE-SU4, ...) but the BLEU score of sys1 was less than the BLEU score of sys2 (quite much). So my question is: Both ROUGE and BLEU are based on n-gram to measure the similar between the summaries of systems and the summaries of human. So why

【细品架构8/100】好代码是架构的根基

由 只谈情不闲聊 提交于 2019-12-21 20:35:23
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文主要是继续研读了资深架构师王概凯Kevin执笔的《架构漫谈》系列的《架构漫谈（八）：从架构的角度看如何写好代码》的心得感受。王概凯Kevin结合自己多年的架构经验，通过不同的视角，重新审视架构的本质，从而产生一力作《架构漫谈》系列，作者希望能够抛出自己从实践中得出的一些观点，并引发大家的一些思考，欢迎大家沟通讨论。 如需要阅读原文，请关注公众号“聊聊架构”，从历史文章中获取《架构漫谈》系列。 本文内容结构图： 当我们有了好的架构，那就需要考虑架构如何落地，而这时候代码就显得无比重要了！千万不要让代码成为架构扩展的瓶颈。 在上篇文章中，我们得出一个结论， 软件架构实际上包括了：代码架构，以及承载代码运行的硬件部署架构 。实际上， 硬件部署架构最终还是由代码的架构来决定 。因为代码架构不合理，是无法把一个运行单元分拆出多个来的，那么硬件架构能分拆的就非常的有限，整个系统最终很难长的更大。 经常会听说，重写代码，推翻原有架构，重新设计等等说法，来说明架构的进化。 这实际上就是当初为了完成任务，没有充分思考所带来的后果。这也并不是架构进化的事情，而是个人对问题领域的逐渐深入理解的过程 。 所以，本文进一步探讨如何把架构的思考进行落地，细化到我们代码的实践当中，尽量不要让代码成为系统长大的瓶颈，降低架构分拆的成本。

【细品架构9/100】技术、业务和架构之间的关系

由 |▌冷眼眸甩不掉的悲伤 提交于 2019-12-21 19:18:32
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文主要是继续研读了资深架构师王概凯Kevin执笔的《架构漫谈》系列的《架构漫谈（九）：你理清技术、业务和架构之间的关系了吗？》的心得感受。王概凯Kevin结合自己多年的架构经验，通过不同的视角，重新审视架构的本质，从而产生一力作《架构漫谈》系列，作者希望能够抛出自己从实践中得出的一些观点，并引发大家的一些思考，欢迎大家沟通讨论。 如需要阅读原文，请关注公众号“聊聊架构”，从历史文章中获取《架构漫谈》系列。 本文内容结构图： 在软件设计开发的过程中经常会看到，很多所谓的架构讨论实际上只是在讨论某种技术。在很多人的概念里面，架构和技术实际上是等同的。学会了几种技术，就认为自己是架构师了，甚至是学习的技术越多，就觉得自己的水平越高。这样实际上是对自己很不负责任的。 要知道任何技术都是为了解决某种问题而存在的，学会了技术，并不代表自己能够解决问题，这一点非常的重要。学会的技术的多少，所带来的差别只是自己解决问题的手段多了罢了 。但是手段多了就一定是好事吗？ 很多时候，学习的技术越多，越不知道采用哪种技术好，所谓“乱花渐欲迷人眼”。 还有另一种很普遍的观点：技术人普遍看不起业务，认为技术更高端，而业务太低端，并且业务往往喜欢给技术挖坑。业务则觉得技术眼光高，但是实际解决不了问题，总是理解有偏差，但是又无可奈何
订阅 Glue