Forwarded from &'a ::rynco::UntitledChannel (Rynco Maekawa)
Twitter
LemonHX 柠檬浣熊
@vonhyou swift咆哮体： user.login()!?!?.on_exit{ doexit() }!?!?
duangsuse::Echo
#algorithm #learn 关于这两个算法说一句，它们其实还是能秽土转生的🤪。 AlgorBFS 只要把它的 FIFO Queue 改成 LIFO Stack 就活了，但是原来在 Iterator.next 维护的路径就要改成在 poll() 后的头部撤销失败尝试，换句话说也就是没有灵魂了（灵魂是只靠改迭代器就能实现单 item 多 links 路径回溯的解决。 当然，也可以选择 Yuuta 式的记录 path 的 copy ，但那样 BFS 内容就是 [int, String] 二元组了（而且后面还要…
本来说做个绘制工具可以研究下这个的（当然不是那种泛向的框架 只支持一个队列式算法），最后勉强是用毅力实现了一下，妄想的不用递归也能实现最后成了泡泡，太烧脑了最后选择了 Dijkstra 式 Map+backtrace... 😭 不过好在安排的特性都完成了
关于为什么不能做成框架，是因为我的动画方式是 await/async... 本身 setTimeout fillRect 已经够简洁了，而且我不会其它的算法。 如果说是递归算法又不方便移植到这个示例来，栈深有限。
https://duangsuse-valid-projects.github.io/Share/HTMLs/lrud.html
『广度优先的染色，是从侧面看还是从下面看更好？』
「BFS 是圆的也好，是扁的也好，关键在和哪门语言一起看。
和你喜欢的语言一起看吧。」🥰
——
不断重复的，春日的某一天。
寒假，某个平原的城镇。
OI 大会近在眼前，班上的同学兴奋地谈论“从深度优先搜索的话，路径是长的呢还是短的呢？”
此时，源所暗恋的治，由于栈决定溢出而将要被忘记。
“我们，私奔吧”
源如此劝诱治，并打算逃离递归栈，
却被 stackguard 带了回去。
仅仅是在一旁看着，没能帮上忙的治。
“如果，那个时候我……”
没能拯救源的治，由于焦躁不安而扔出了源在海边捡到的不可思议、广度优先的列与表。
之后，不知何时，时间回转到了栈被挤爆之前……。
在不断重复仿佛死循环的这一天的尽头，算法所抵达的命运会是？
烟花飞上天空之际，拓扑图上的奇迹便会发生——
题外话：
据说，图像连通区域检测
可以用2个Mask来会扫描
然后标记记录发现的连通信息
可以在 对相对于 角线长度 的线性时间完成 #algorithm
关于为什么不能做成框架，是因为我的动画方式是 await/async... 本身 setTimeout fillRect 已经够简洁了，而且我不会其它的算法。 如果说是递归算法又不方便移植到这个示例来，栈深有限。
https://duangsuse-valid-projects.github.io/Share/HTMLs/lrud.html
『广度优先的染色，是从侧面看还是从下面看更好？』
「BFS 是圆的也好，是扁的也好，关键在和哪门语言一起看。
和你喜欢的语言一起看吧。」🥰
——
不断重复的，春日的某一天。
寒假，某个平原的城镇。
OI 大会近在眼前，班上的同学兴奋地谈论“从深度优先搜索的话，路径是长的呢还是短的呢？”
此时，源所暗恋的治，由于栈决定溢出而将要被忘记。
“我们，私奔吧”
源如此劝诱治，并打算逃离递归栈，
却被 stackguard 带了回去。
仅仅是在一旁看着，没能帮上忙的治。
“如果，那个时候我……”
没能拯救源的治，由于焦躁不安而扔出了源在海边捡到的不可思议、广度优先的列与表。
之后，不知何时，时间回转到了栈被挤爆之前……。
在不断重复仿佛死循环的这一天的尽头，算法所抵达的命运会是？
烟花飞上天空之际，拓扑图上的奇迹便会发生——
题外话：
据说，图像连通区域检测
可以用2个Mask来会扫描
然后标记记录发现的连通信息
可以在 对相对于 角线长度 的线性时间完成 #algorithm
duangsuse-valid-projects.github.io
广度优先的染色，是从侧面看还是从下面看？
选择 LRUD,RDLR 等搜索次序，查看寻径着色过程动画！
Forwarded from RiNG (Xeonacid | SIGFAIL)
Forwarded from &'a ::rynco::UntitledChannel (Rynco Maekawa)
Twitter
𝚋𝟷𝚏𝟼𝚌𝟷𝚌𝟺
为啥 GCC 编译一个文件能比 clang 慢 500 倍。。。🤔🤔🤔🤔🤔 https://t.co/JMii3nP1aO
Forwarded from Solidot
商业国际象棋软件被发现是基于开源软件 Stockfish
2021-02-19 21:28 #开源
制作和销售国际象棋软件的 ChessBase 刚刚发布了 Fat Fritz 2，该公司称它是排名抵御的国际象棋引擎，使用了新的神经网络，由 Albert Silver 训练。但事实上，Fat Fritz 2 事实上是拷贝了开源国际象棋引擎 Stockfish，使用了不同的神经网络，变化很小。开源国际象棋组织对这一做法 表达了谴责。
2021-02-19 21:28 #开源
制作和销售国际象棋软件的 ChessBase 刚刚发布了 Fat Fritz 2，该公司称它是排名抵御的国际象棋引擎，使用了新的神经网络，由 Albert Silver 训练。但事实上，Fat Fritz 2 事实上是拷贝了开源国际象棋引擎 Stockfish，使用了不同的神经网络，变化很小。开源国际象棋组织对这一做法 表达了谴责。
duangsuse::Echo
我 DIO 败了😂，明明没好气的说自己用的是鬼画符，看来还是比不上各类前端大佬鬼画符。 要是我，可能选择把自体判断和 父妻=$母 这种东西给移到另一个“绝对准确”的模块里，而且数据要压缩就会选择脚本预处理，字符串内存优化就会选择加一层恒等替换字典，总之绝不会另外搞一套 notation... 😒 另外动苏非常清楚这个东西绝对不可能有批处理的应用场景，权衡利耗后我觉得完全没有压缩数据包或内存的价值，性能也绝对不重要(不能再快就是了) 断舍离就是这么干脆😋 毕竟写的东西多了，也明白性能这个东西是不可臆测或不可企及的…
#日常精神分裂 #relation #functional
A: 那个亲戚关系计算器，你还说人家做的不好，这不，你不也没做成了么
B: 是鸽后面了啦，今天又有一些新想法，可以改进特性而且保持程序接口一致
B: 首先是关系的，如果认为「父父子」（大爷的儿子）也是「父父」的话（兄弟的孩子也是一家的孩子），「姑姑」这样的称呼就跨单个的亲子关系了
A: 这还真是难以理解
B: 这个不重要，关键是反向称呼的本质其实应该要自动处理才对： 「父父」是爷爷，而「子子」就是反向「!父父」，「孙子」才对；对「我子」来说，「我子子」就是「子」这样。（有点 relative path 的意思了
B: 我还发现 notation 可以有更多变换， 父^5 和 长=哥|姐 外，还可以引入「姊」「娣」自动加「长幼」的前缀（不过，这样就要预处理过程 flatMap 展开缩写了
A: 最后这个被否决了，理由是「亲孩长幼」四个字组成的也不过几十条，复杂化算法不值得？毕竟代码是给人看的。
B: 我觉得可以考虑一下在查询语句里支持 姐|妹的儿子 这种……
A: 那子程序的返回类型就有点麻烦了，用途也小，还是不要麻烦了（孤立支持一下
B: 反向关系很重要，规则是
A: 那么具体怎么操作呢？这种自动从数据构造反向关系的方法？
B: 我觉得应该定义
A: 首先，这么做是对反向称呼的扩展，因为数据里只有
A: 把反向称呼的数据填一下， 孩(子女)/亲(父母) 为相反关系，查询
B: 你可真是个小天才 :P 那就这么愉快的决定了。
A: 对了，那你之前说的那个人是怎么实现的
B: 噢，看了一下，那个是同时定义了
我们之所以这么麻烦翻来翻去的就是因为数据结构格式不同(同时有正反向称谓 就避免重复定义关系链条了)，其实目前的模式也就是它的模式，没做「对方称呼我」而已
B: 总结的说，就是一个先支持反向关系再支持反向查询，一个先支持反向查询后才能实现反向关系。
A: 这么看你的在方法思想上也没有什么更高的地方啊😒
B: 是呢，不过我的数据集比较简单，单字符切分(js的之所以必须留逗号就是因为作者没法支持不定长的并列单项，不会写 tokenizer)，后期也可以加预处理替换来压缩什么的 功能能做到一样 可以试试🌝
A: 那个亲戚关系计算器，你还说人家做的不好，这不，你不也没做成了么
B: 是鸽后面了啦，今天又有一些新想法，可以改进特性而且保持程序接口一致
B: 首先是关系的，如果认为「父父子」（大爷的儿子）也是「父父」的话（兄弟的孩子也是一家的孩子），「姑姑」这样的称呼就跨单个的亲子关系了
A: 这还真是难以理解
B: 这个不重要，关键是反向称呼的本质其实应该要自动处理才对： 「父父」是爷爷，而「子子」就是反向「!父父」，「孙子」才对；对「我子」来说，「我子子」就是「子」这样。（有点 relative path 的意思了
B: 我还发现 notation 可以有更多变换， 父^5 和 长=哥|姐 外，还可以引入「姊」「娣」自动加「长幼」的前缀（不过，这样就要预处理过程 flatMap 展开缩写了
A: 最后这个被否决了，理由是「亲孩长幼」四个字组成的也不过几十条，复杂化算法不值得？毕竟代码是给人看的。
B: 我觉得可以考虑一下在查询语句里支持 姐|妹的儿子 这种……
A: 那子程序的返回类型就有点麻烦了，用途也小，还是不要麻烦了（孤立支持一下
父&母 这种并称算了），支持 父^n 这样的缩写就够了吧。B: 反向关系很重要，规则是
(父父 爷爷 !孙子) ，如果我用 !父父 能查到反向称谓，为什么更合理的 子子 就查不到了呢？其实反向不应该做在 妻父子 (=岳父的儿子) !_=(爸爸的女婿) 这样的称谓里，而应该做在 妻父子 !_=(父女夫) = (爸爸的女婿) 这种A: 那么具体怎么操作呢？这种自动从数据构造反向关系的方法？
B: 我觉得应该定义
(反向 妻父) = (女夫) 这样的关系字典？A: 首先，这么做是对反向称呼的扩展，因为数据里只有
(妻父=岳父) 的对应关系，当然可以利用别名系统增加反向称呼 (岳父 !女婿) ，问题是你要知道「如果以岳父视角看，我和他是什么关系」，答案是 (反向 妻父) = (女夫)
B: 那我给你「女夫」，如何答我「女婿」？A: 把反向称呼的数据填一下， 孩(子女)/亲(父母) 为相反关系，查询
(反向 女夫) = (!妻父) 就成了。B: 你可真是个小天才 :P 那就这么愉快的决定了。
A: 对了，那你之前说的那个人是怎么实现的
B: 噢，看了一下，那个是同时定义了
(d,h=女婿) 和 (w,f=岳父) ，对他们来说 ! 这个运算符反而是特别做的(不像现在 的安排应该是直接查询)。我们之所以这么麻烦翻来翻去的就是因为数据结构格式不同(同时有正反向称谓 就避免重复定义关系链条了)，其实目前的模式也就是它的模式，没做「对方称呼我」而已
B: 总结的说，就是一个先支持反向关系再支持反向查询，一个先支持反向查询后才能实现反向关系。
A: 这么看你的在方法思想上也没有什么更高的地方啊😒
B: 是呢，不过我的数据集比较简单，单字符切分(js的之所以必须留逗号就是因为作者没法支持不定长的并列单项，不会写 tokenizer)，后期也可以加预处理替换来压缩什么的 功能能做到一样 可以试试🌝
Forwarded from Ray Tracing (RSSBot)
Ray Eldath's Blog
企划：一本有关程序的词典——《编程语言词典》
企划：一本有关程序的词典——《编程语言词典》
Forwarded from 高蜀黍 HerbertGao #还差18kg
电脑内存不够了怎么办，下载一点吧
downloadmoreram.com
downloadmoreram.com
#project #drawing #web 这个大概更新了一次，支持配置参数（调时序和事件入口弄了好久😅
现在实质算法与动画、位图坐标系套板完全分离了。
看看这个
此外旧版我也留了
https://duangsuse-valid-projects.github.io/Share/HTMLs/lrud/old.html
#js bookmarklet 半成品见下方。
现在实质算法与动画、位图坐标系套板完全分离了。
看看这个
此外旧版我也留了
https://duangsuse-valid-projects.github.io/Share/HTMLs/lrud/old.html
#js bookmarklet 半成品见下方。
Telegram
duangsuse::Echo
本来说做个绘制工具可以研究下这个的（当然不是那种泛向的框架 只支持一个队列式算法），最后勉强是用毅力实现了一下，妄想的不用递归也能实现最后成了泡泡，太烧脑了最后选择了 Dijkstra 式 Map+backtrace... 😭 不过好在安排的特性都完成了
关于为什么不能做成框架，是因为我的动画方式是 await/async... 本身 setTimeout fillRect 已经够简洁了，而且我不会其它的算法。 如果说是递归算法又不方便移植到这个示例来，栈深有限。
https://duangsuse…
关于为什么不能做成框架，是因为我的动画方式是 await/async... 本身 setTimeout fillRect 已经够简洁了，而且我不会其它的算法。 如果说是递归算法又不方便移植到这个示例来，栈深有限。
https://duangsuse…
Forwarded from See you at @fishing_daily ! | (Archived) YuutaW 的版聊频道 (铝箔！@NaAlOH4)
darkeet 的编程技术真的很好呢（黑脸