duangsuse::Echo
717 subscribers
4.26K photos
130 videos
583 files
6.48K links
import this:
美而不丑、明而不暗、短而不凡、长而不乱,扁平不宽,读而后码,行之天下,勿托地上天国。
异常勿吞,难过勿过,叹一真理。效率是很重要,盲目最是低效。
简明是可靠的先验,不是可靠的祭品。
知其变,守其恒,为天下式;穷其变,知不穷,得地上势。知变守恒却穷变知新,我认真理,我不认真。

技术相干订阅~
另外有 throws 闲杂频道 @dsuset
转载频道 @dsusep
极小可能会有批评zf的消息 如有不适可退出
suse小站(面向运气编程): https://WOJS.org/#/
Download Telegram
Forwarded from mivik::channels::tech
#share #poly #math
把上面这个改了一下编了道题放到了多校联考里面,大概率并不会有参加联考的 OIer 在订阅这个 channel 于是贴份代码...
在 NTT 模域下于 \prod (1-a_i x) 形式的多项式的快速(应该)求根。可以在 20 秒内分解 50000 次的多项式(数据随机的情况下)
https://gist.github.com/Mivik/daf5f1a5705b511b919e23ef3f09e6d4
发现一个好玩的项目 ws-scrcpy ,通过浏览器远程连接废旧安卓手机(需要装有adb的物理机)
云 手 机
#statement 动苏想想,也可以以这种方法描述我技术水平的改变

最初在 #Android 写不了几个东西的人,连数据UI都做不到。
数据:OOP struct
程序:复制粘贴,不能理解 API 和子程序、入口点概念,并不能编织二三层深的程序流程。

写多了 Rust,Ruby,JS 的动苏。
数据:1D、基础组行表、流
程序:自由编织的子程序和流程,能利用外部 API 实现略复杂的功能 甚至编写简易 GUI,但简洁性不够好,也不能结合数据结构进行应用编程

数据:2D、递归栈、队列顺序、链接图
程序:定义式编程,物理命名法,不拘泥于任何冗长的表达形式;自由决定值的 copy 或 assign、子程序输入输出和 OOP 变量作用域/赋值处/可变性;默认双向 from/into 转化数据,为程序和数据的统一及协调服务

但是数学不好 以及想要的项目一直没做,却被别人做了这点很草😥 其它领域无所谓、都可以、择日学, 但明明动苏那么喜欢,却没能快速做到呢
什么时候能再有机会啊,真的不想被比下去呢。
#Python #parsing 还以为是能让我猜不到的写法呢……(嘛 不过 inc(x)->x+1 这种命名写法我还的确没猜到) 开始还以为是 lam: 或 \x. 这种
&'a ::rynco::UntitledChannel
Ray Eldath | 计算机领域的三个重要思想:抽象,分层和高阶 https://ray-eldath.me/programming/three-important-ideas/
咳咳, #ce #PLT #math
前章说了作者最开始的一些见闻和误解,比如抽象代数是PLT必须前置知识什么的。
50% 的篇幅是写作者和 PLT/FP 函数式领域一个学者(他的偶像)的一次来信,皆包含中英文本。总体而言记述性内容多

也谈了 Monad 是不是 operational semantic 的问题,学者的回答好像规避了具体的回答,只是说对高效的程序猿不必看得太重但理论联系也很值得学习。

后面讲了 compile/interpret, currying, partial application 等问题的相关侧面。

我记性比较差就不赘述了,提点关键词 爱看的看吧
动苏是相对较重视实践的,而我目前在这个领域可以说没有什么实质进步,必须先写点什么能用的才好啊。
#日常精神分裂 #沙雕
A: 看完《转生史莱姆》旧集命名一段我突然冒出个问题,如何杀死一只史莱姆?史莱姆有核吗?
B: 史莱姆无限可分,无法杀死
A: 说到物质无限可分…… 我想到了毛泽东的“原子无限可分”了。 其实不论身份的话,这个论断也是一种合情理的猜想吧。
B: 反对的都蹲大牢去了,你觉得怎么样。
A: 毕竟对普通人来说自然界的什么东西有极限就显得很奇怪,就像爱因斯坦的「上帝不可能掷骰子」?那如果不从问题本身讨论,就问怎么「劝」一个持这种常识的人相信「原子不能再分」呢?
B: 我觉得可以这么比喻吧,「人体可以无限拆分,但是拆到一定程度就会分崩离析,失去原有性质,不能再叫人体的子部分」,再为了贴合毛泽东的理解套一下实例,再给他个台阶下(之前的理解部分正确 但有一个微小细节),应该就能被接受了。
A: 不讨论这个了,你觉得 GNOME 的「自然滚动」滚轮视图而非内容,怎么样,怎么实现 Android 等触摸手势上的「末滚动动画」?
B: 反向滚动我觉得就是个 trick,末滚动动画的话需要知道单次滚动的速度,必须有 onTouch Start/End 事件和一个 t0 ,必须能读写 pos 。
A: 触摸滑(滚)动就是一个动画,为什么要有 on start/end?
B: 你可以把它理解为 window 上 drag 的实现,必须有 point0 才能知道 pos 的单次偏移量,至少要记录按下状态,并不是说 onPointerMove 就够了
Forwarded from Yuuta 🎀 | clrd enroute
跟着 apue 实现了个简单的 shell,我寻思跑几个程序测试一下吧.. 然后就跑了 poweroff,想着反正没 sudo,然后.. 就关机了。

我忘记自己有权限了。
#linux #sysadmin wm=窗口管理器 dm=图形化登录管理器
Forwarded from Yuuta 🎀 | clrd enroute
DE 坏,来 i3wm
Forwarded from Yuuta 🎀 | clrd enroute
?sddm 不是 display manager 吗
Forwarded from im� 🍩🍭🍋🐇🏚️☕🍵🥞🦋🌱➕1⃣🤖🔕📳🎶🎧 | LTE🈚latency>1024767ms � via @donnakkabot
<-dm wm 分不清
duangsuse::Echo
再说说 ParserKt 新版解决的 "StickyEnd" 和 LexerFeed 问题。 StickyEnd 是造成 TriePattern—PKT 的 keyword tokenizer 无法应用于整个输入(fullmatchPattern)的元凶 所谓 sticky end ,是 fullmatch 的逻辑是,无论 pat 是否匹配成功(没成功就往 StringBuilder 里填一字继续尝试),必须 match 到输入末尾,但这就有个问题——不能判断当前是否 EOF ,结末的异常会被 pat 视作…
#parser 🤔今天又想了下,解除了一个很傻的误会

假设有 try {} 也有 tryDo {} ,前者是 Try 块而后者是一个函数调用,如果说 keyword 完全是由 Trie 前缀解析的,会把 tryDo 分词为 try Do 从而造成问题

其实关键字本来就是在 Name 的基础上做的,应该弄个 Piped 组合器,来做到 name 和 kw 结构的区分。

其实一个组合解析器框架要走上实用还有些细节吧…… 除了 /* 和除号区分、输入流和输出结构、系统忽略空格、容错等问题

之前说 StickyEnd 导致 Trie 分词不能“greedy”的问题明白了,就是把一段文本分成 plain-关键词-plain-... 的形式

我的方法是 takeWhile{it !in trie.routes} ,如果这么简单的话区分不出结果 isEmpty() 到底是真的没符合呢,还是输入流结末了呢?没办法判断。

如果视为没符合,流结末时就会无限循环(再看 trie 结果 也可能是真不符合任何关键词)。

如果视为流结末,再去看 trie 的结果,也不能分出是怎样

正确做法显然是展开调用,如果流结末就直接返回…… 属于老问题没写好

😒下次我会试着利用 inline 和 -1 的,异常的确该说不至于,因为 Repeat 组合器很多,但只有最上一层会真收 EOF
🤔 gl, audio 之类的节点图效率还不低