欢迎来到 neutronest 的小站。这里记录了一些关于 程式语言应用 以及 机器学习等相关技术的文章(TECH BLOGS)。同时也包括一些生活,感想随笔 (ARTICLES)。如果你对深度学习,机器学习理论,函数式编程,形式语义等内容感兴趣,这里可能会有部分文章会对您有益(并没有

奔跑吧!摩耶花 其二

注:本文为B站文章归档, 原始链接: https://www.bilibili.com/read/cv6406525 我们的传说之书《我们的传说之书》(わたしたちの伝説の一冊)之所以特别,就在于她是一篇罕见的,并未以折木奉太郎为叙述主体的故事。大部分《冰菓》的故事都往往以折木的分析推理导出事实真相为结尾,即便是类似《镜中不得见》这样并未以折木推理为主的故事,折木本身也会作为关键的穿插性线索出现。而在《我们的传说之书》中,折木仅仅在开场时候的读后感讨论片段出现过,之后则彻底是以摩耶花为第一视角的漫研社相关情节,折木本人则再未出现过,也就不会再有传统冰菓叙事里的“折木推理得出事实真相”的桥段。这令我十分不安,因为折木的缺位可能意味着事情的真相被掩盖了。我们依旧先简单看看故事情节: 自“库特利亚芙卡的排序”事件结束后,摩耶花所在的漫研社,阅读派与绘画派的冲突与日俱增。之前阅读派首领河内亚也子的退

奔跑吧!摩耶花 其一

注:本文为B站文章归档, 原始链接: https://www.bilibili.com/read/cv6406525 梅洛斯“呀,梅洛斯先生~!”呻吟似的声音伴随风声传了过来。 “谁?”梅洛斯边跑边问道。 “我是菲洛斯特拉托斯,您朋友赛里努蒂乌斯的弟子。”那个年轻的石匠,也跟在梅洛斯身后边跑边呼喊: “已经不行了,请不要再奔跑了,您已经无法拯救他了。” “不,太阳还没有落下呢。” “就在刚才,他已经被处以了死刑。啊,您来晚了,请允许我抱怨您,要是再能稍微早一点就好了。” “不,太阳还没有落下呢!” 梅洛斯怀着满腔悲愤,凝视空中火红硕大的夕阳,死命先前飞奔。 我虽然对日本相关的文化比较感兴趣,但是纯文学作品看的却很少,至于太宰治就更少了。几年前跟风读了读《人间失格》,读完了也只觉得胸里有些闷,谈不上有什么感想。有一段时间,《人间失格》为人所拥趸,简直成了某种中二病的庇护所,更有人拿他与鲁迅

Windows Azure Storage 论文导读 一种结构化的分析方法 (一)

Introduction阅读分布式论文与其他类型的论文,比如深度学习之类的不同。一篇关于深度学习的论文可能全篇都 focus 在一个新模型以及对应的优化方法和应用场景上,其核心是模型本身的idea, intuition, 以及比较 tough 的算法公式推导。分布式系统的论文则不然,由于分布式本身可讨论的问题很多,除了必说的 balance, consistent, replication, throughput, latency 等内容外,还要讲述整个系统的逻辑架构,以及架构里每一子元素的设计细节,内容繁冗驳杂往往难以抓住重点。如果说读机器学习论文如同解数学题的话,那分布式系统的论文阅读毫无疑问就是文史类的长篇阅读理解。 读分布式的论文还有几个难点。第一是读每个 section 时很难抓住问题的层次,这点对于该领域萌新来说尤为如此。比方说看到一个架构里某一层使用了 entity appe

天空的列车 (暂定)

(一) 这真是一个狭小的世界。 高桥贞一结束了在工厂的工作, 在由整齐排列的墙壁顶端、组成的“壁之路”上轻松地行走着。 就常人看来, 壁之路并不好走, 就好像过一个几百米的独木桥,一般人小心翼翼张开双臂,也许能坚持十几米, 但是能够来去自如地踮过几百米而从不从墙壁上摔下来,大概不是神人, 也至少是个异能人士。 可惜, 在”基域”中,这实在不算啥稀奇的本事。 在基域 是没有“公路”一说的, 甚至连那种童话故事中的羊肠小道都没有。如果能从基域的半空向远处望去,映入眼帘的只有密密麻麻挤在一起的房屋,没有容纳其他任何公共基础设施的空间。只有每隔几百米,时不时出现的高耸入云的 “基柱”,尚且勉强能为贫瘠的景色添上些许异彩。不过,这种形容或许有些不准确,因为在基域是看不见天空的,也就无所谓”高耸入云”。也许因为狭窄闭塞,也许因为缺乏最起码的卫生基础设置,基域常年被各种压抑的灰色烟雾笼罩。运气好的话,

地狱里的Rust (一)struct 设计机巧初步

Introduction本篇文章旨在记录并讨论一下自己在最近 Rust 试水学习中所踩的坑以及 挖掘出的一些用来规避 memory system writing hell 的一些常见套路。 我相信不止我一个人有这样的错觉,即尽管Rust 的文档不可谓不齐全,然而真正开始在生产环境使用的时候就会发现Rust 只有两处不太好用: 这也不好用,那也不好用。 然而你还不能抱怨什么,在你尝试搜索 rust document 以及 stackoverflow 后,你恰好总能找到你问题的解决方案,尽管有些确实不那么漂亮。仿佛 Rust 语言的开发者始终将自己处在万人所指的被告席上,背后有强大的律师团为其背书:“xx你看,你觉得xx在Rust 不好实现并不是因为 Rust 本身的问题,而是你没有使用 / 尝试 Rust 的 xx 功能”。 尽管 Rust 完善的文档能够使她的开发者巧妙地逃脱每一次初学者的

HHHentaiCollection☆!!! —— 一个ML数据集的设想

Introduction机器学习以及应用已经成为了当今最为流行的话题之一。一些重要的探索性项目如AlphaGo, 无人车等都依赖着机器学习模型作为其基础设置做支撑。机器学习光有模型是远远不够的,还需要有足够用于其训练的数据—— 我们称之为数据集。 然而我们知道目前常见的机器学习任务细分数量多而驳杂,即便只是 narrow 到文本与图像方面,也会包括但不限于情感分析,机器翻译,摘要生成,对话生成,上下文对话分类,图像识别,图像生成,看图说话等多个子领域。这其中每一个领域的研究与应用,都需要一一收集相应的数据。这就使得数据的采集和处理工作变得十分冗余和繁琐。目前已公开的知名数据集如 MNIST, IMAGENET 是图像相关的,而诸如 swda 等数据集则 cover 了情感分析等文本方面的数据。但是这些都是零散的,不一体化的。研究者如果需要处理某些交叉性质的任务,比如看图说话,也许就需要自

吹响吧!上第一号第一集分析

前言~~从今天开始我会尝试陆陆续续更新对上低音号第一季的各集分析。伴随着《吹响吧!上低音号》第四周目的旅程,我也终于能够鼓起勇气开始写这个欠坑已久的剧情分析了。 第一次看的时候就发觉了这部番的细节相当丰富,然而具体丰富在什么地方,体现了原作者和京阿尼制作组怎样的用意呢?我无暇去顾及,那大概还是去年6月份的事情。后来在去年八月份有了很好的机会去趟日本,更是恰好有一个非常难得的时机去宇治市体验圣地巡礼。经过了实地考察后再回味此番,很多地方的感觉就非常不一样(典型的案例就在第八集,有一些宇治当地的地理彩蛋和宇治文化的彩蛋,如源氏物语)。现在终于觉得自己有能力去尝试写这样一个系列的分析了。 刚开始看时,我以为这就是一个画面非常精美,音乐绚烂(本来主题就是关于音乐的)的日常番。但是随着第二遍,第三遍的深入,我发觉在该番中隐藏着一些沉甸甸的主题。这种沉重,尽管被隐藏在泼墨般的青春绘里,却也是不逊于《冰

Why say the design of functor in Haskell is terrible for NEWBIE

What is Functor ?The “functor” I want to discuss today is not the concept in category theory, but a core feature and language character in Haskell instead. In fact, the design of functor in Haskell is really dated from the concept in mathematics. First let us review the details of functor definition: 123class Functor f where fmap :: (a -> b) -> f a -> f b In this code, the type signatur

我们并不清楚我们不清楚的是什么—— Haskell 学习小感

我们并不知道我们所不知道的是什么,这话在 Haskell 的学习中体现的十分明显。 最近 Haskell 出了一本 1000+ 页的新书,是一个关于 Haskell 入门的 self-contain 的书。这本书确保 Haskell即便是你接触的第一门语言,你也可以无伤学会她。 这看上去真不错!至少她改变了 Haskell 在 education 领域是 immature 的现状。我一直在用那本书学习,虽然篇幅很长,但确实内容翔实,比 Haskell趣学指南 以及 RealWorldHaskell 要详细很多。但是,这仍然存在一个问题。这个问题是,如果你不把这一本1000+页的书细致地,从头到尾读完,我赌5毛钱你连一个最浅的实际应用都写不来。这不是书本身的问题,是 Haskell 的语法设计不断迭代的过程中,加入了PL界的很多最新研究成果,但是这些成果丝毫不能改变 Haskell 在实际场

Theano 大雾 小记

使用 theano 有一段时间了,以下是我遇到的问题以及困惑,不知道有没有同好遇到过: 1. 捉鸡的 Scan我对 theano 一半以上的纠结都是在 scan 上。 作为在表达式中表示寻循环的方法,scan 我相信大家都用过。我不知道以下问题大家有没有碰到过: a. scan 套 scan 速度感人。 我就默认大家都实现过 RNN 或者 LSTM. 在实现这一类基于序列的神经网络中,你几乎至少要用一层 scan. 这是正常情况。一般在这样的情况下 compile 相关的 function 只需要几分钟时间,最多总不会超过20分钟。 然而大家为了灌水总要在模型上修修改改,有时候难免会遇到 scan 套 scan 的情况。这种时候 compile function 的时候花费时间会彪的飞起,我最长碰上过 compile 1个小时的情况。 b. scan 中糟糕参数的传递限制 比如说你用 sc

Older Posts →