#日常精神分裂 #cplusplus #plt
A: 宏或者模板有没有办法把 identifier 变成 const char* 啊，不想写多余东西真是的
A: template 递归实现的 vararg 好草啊，很多人都喜欢用
B: 感觉 C++ 模板像预处理宏系统的扩充一样，这样就有两个“模板”系统了……
A: 话说 C++ 为什么不使用惯常的子类型检查方法实现类型参数？非要自动填模板
B: 大概是 C++ 和 Go 一样是单态不支持子类型所以只能用模板？而且模板应该会暴露 sizeof 这样的元数据，对闭源库可能是必须的，能做元编程编译期计算也是好扩充
A: C++ 的 class 和数值都有兼容或自动转换吧…… 模板大概就是把型参让编译器一填，然后自己再去检查合规性，省得 in out 约束的，直接最大兼容化了
B: 也是，毕竟 Java,TS 这些类型参数基本都是编译期的，运行时全是 Object
这么看 C# 的真泛型也有点像 C++ 的模板， IL 层面存储类型信息
A: 说说 abeat 项目， glClearColor(rgba) 的参数化你打算怎么实现？
B: 只能是删了改到 shader 代码里，反正花了好大力气弄的动态加载。本来这个频谱图理想状态就是 C++ 只负责绑定频谱数组，全部绘制 OGL 执行的
A: 那么函数图相对上一版的改进应该怎么办
B: 支持选择光标模式为可以看到光标点轴和 raw vp,scale 的模式， xy range 的放设置面板里，必须的。上一版显示 raw 的信息(xrange 还是错的)以及把设置和公式列表放在一起根本是错的，你怎么还不明白

#haha #tech #meme You're hired? 😂

Applicable for conditions: 1. When a variable and a function has same name. 2. When you want only output regardless of input. 3. When you are the programmer and also the tester. 4. When you literally change your name to get hired!
https://redd.it/llzd01

by @programmer_humor

#recommend #security #reveng #java #tools

顺便也是通过这个视频发现了一个好东西，IDA Pro 的开源代替

#recommend #cg #drawing #js https://avikdas.com/2020/07/08/barebones-webgl-in-75-lines-of-code.html
https://www.codeproject.com/questions/226294/draw-a-filled-rectangle

结果发现最好的安排大概还是设置 buffer clear color ... shader 根本不适合画这种图形

#haha #math #inm 🌝

把 Mivik 的重写又重写了一遍，加了更新参数和 GLSL 的功能；感觉最近越来越接触到自己不会的东西了，太菜了啊。

嗯就是这个项目，看来停止的不彻底…… 其实我讨厌在一件事上浪费太多时间（但看起来也有两天了
对了，还发现一个 #cplusplus
https://blog.csdn.net/linjiasen/article/details/103630940c
https://stackoverflow.com/questions/1358400/what-is-external-linkage-and-internal-linkage
https://en.cppreference.com/w/cpp/string/basic_string/npos 不愧是优雅的 C++ STL ，连 -1 都用 size_t 限制了必须用 string::npos 👌

https://t.me/personal_trash_can/19556
社会公民安全的问题还是要重视，而不能抠字眼。 🌚
真是受害者的话三秒几十秒有什么区别，搞不好还是真能死人的，「合法」渠道实在是堪忧(本身不合法哪来的合法渠道 草)，必须严加管束。

另外相关博主还给了一个小提示，如果真有遭到歹徒袭击，可以装晕再找机会逃跑。但是 谁也不会用这种药物助眠吧，那么为什么不表示立刻全面查处呢？ 🌝

http://passer-by.com/relationship/ 丈母娘=老婆的妈妈 #relation #functonal 对！要的就是这个 🌚
下次关系式实践就一定要弄这个，可以算过去可以推出来，非常实际，还能支持 ABCD 变量是最好的了

要是只支持一个方向多无聊， 父母儿女 兄弟姐妹 拿 Map fold 一下就解决了，可是关系式求解才有意思 🌝
好吧，为了证明这个问题（单向查称呼以及单层回溯）没意思我就举个 #Python #code

族谱关系只分长幼男女两种，究其根本也就是「亲孩 长幼(指同辈关系的)」四个字

relationCode = """
父 爸.; 母 妈.
儿 儿子; 女 女儿
兄 哥.; 弟 弟.
姐 姐.; 妹 妹.
妻 老婆; 夫 老公
妻父 岳父; 妻母 岳母
夫父 公.; 夫母 婆.
母母 姥姥; 母父 姥爷
父母 奶奶; 父父 爷爷
母姐 大姨; 母妹 小姨
母兄 大舅; 母弟 小舅
父兄 叔叔; 父弟 小叔叔
"""
def relativeData(code, sep=' '): op=lambda s:s.split(sep,maxsplit=1); return {kv[0]:re.sub('(.)\\.', "\\1\\1", kv[1]) for kv in map(op, re.split('''\s*[;\n]\s*''', code)) if len(kv)==2}

def mktrie(d, k_end=None):
  def br(dd,kk): v=dd.get(kk); vd = v if isinstance(v,dict) else ({k_end:v} if v else {}); dd[kk]=vd; return vd
  for kkz in (iter(k_:=k) for k in d if len(k) > 1):
    v = d[k_]; d0 = d
    for kk in kkz: d0 = br(d0, kk)
    d0[k_end] = v

class bidir_map(dict):
  def __init__(*arg): dict.__init__(*arg); o=arg[0];o._rev = {o[k]:k for k in o}
  def keyOf(self, v): return self._rev.get(v)
def relDesc(s, use_short): # 父父=爸爸的爸爸(=爷爷)
  if use_short: return sep.join(rels[k] for k in s)
  path = rels; res = []
  for i, ch in enumerate(s):
    if ch not in path: raise ValueError(f"unknow {ch} in {repr(s[:i+1])} at {path}")
    if (v:=path[ch][None]): res.append(v); path = rels
def rrelDesc(ss): return [rels.keyOf(s) or s for s in ss]
# ~女儿的妈=女母 (要检测自相等关系和有效性就必须明白性别什么的 很麻烦，但是机械执行就不需要算法

下面的部分是湖北本地的叫法，当然这都是配置文件，能随便切换的。 😋

这个东西稍微推广下，结果 list 化下，就能支持关系别名，或泛性别、泛长幼的查询 ，但是一点意思也没有 要做就做好玩又好学的😒
从一个拓扑图里导出任意两点的关系写出的应用最优雅，可惜我不会，有没有人能教会我…… 可是博文 hello declarative world 的大佬都没能教会我 😢 扶不起

#Python #code 写了也没用…… 还是赶紧睡大觉

https://github.com/mumuy/relationship 的 relation.js (同目录还有个 common.js)写得贼复杂，还有同志去重、逆向ID、逆向关系链什么的 🌝🤔
我也不知道该不该分析，分析吧是功能很杂乱，不分析吧又好像在做自我限制。 不过这个脚本 mktrie 字典树算法写了半天，测试次数远远超出我的预期，可见我是没算法商（

对了，以上 py 代码都是我为压行压字写的(当然我也很克制没滥用)，大家千万不要模仿(实际工程应该切忌省击键 尤其是压行)
用的什么 kk, v1 这种命名都是有次序语义的（所以我才能用这种鬼画符写代码……只是这命名应该就只有我理解了）

明天先去把 Yuuta 的 BFS 写一下，好久没写图算法了 😋(记得上次写 dijkstra.kt 是什么时候

还是上一下贼船吧，毕竟 miui 系统计算器就有模块引用这个代码🌚
//转换类型：'default'算称谓,'chain'算关系(此时reverse无效)
reverse:false //称呼方式：true对方称呼我,false我称呼对方

首先 api 是 calc(options={}) 而不是 calc(text, options) 这接口就有问题，不常规也不吼 😒

既然 reverse 在 type 为 "chain" 时无效（请注意特定配置下未用的配置永远是设计不当 露骨点就是编程者对此语言的分支类型写法或相应设计模式不了解😓老实说在前端界挺普遍），我们认为实际上有三种模式：
default, reverse, chain
前二者分别对应 type=="deft." 时 reverse 的两种情况，我几乎以为这么加个字段是有意义的。噢天哪😩 什么时候大部分人能认真处理界面和后端的分离。

然后 reverse ，我们竟然已经知道了一个 bidir_map 的对应关系，反向其实只需把既有单称谓改成正反向的称谓列表， rev 时得出结果翻转列表，再用反向称谓即可。

比如 妻父父=岳父的父亲
反过来就是 r(父亲) r(岳父) ，即 =儿子的女婿
超级简单而且与之前的数据复用设计，照应了🌝（但我还是觉得关系式一致化求解好 还能自动 simplify ，不像序列就只能靠定义相反关系之类的方法🤪

还有就是 自体相等性、弟兄 可能是自己的猜测、禁止同志政治正确性 都做完了基本就没什么了🌚

计算器可以说是最适合跨平台实践的应用种类了😋 IO 类型很单一，几乎不需要外部库，UI 能做的扩展轻松而且选择自由度高，算法种类可自选到简单的，是值得一试的东西。

我 DIO 败了😂，明明没好气的说自己用的是鬼画符，看来还是比不上各类前端大佬鬼画符。

要是我，可能选择把自体判断和 父妻=$母 这种东西给移到另一个“绝对准确”的模块里，而且数据要压缩就会选择脚本预处理，字符串内存优化就会选择加一层恒等替换字典，总之绝不会另外搞一套 notation... 😒

另外动苏非常清楚这个东西绝对不可能有批处理的应用场景，权衡利耗后我觉得完全没有压缩数据包或内存的价值，性能也绝对不重要(不能再快就是了) 断舍离就是这么干脆😋

毕竟写的东西多了，也明白性能这个东西是不可臆测或不可企及的 没有执念了 #statement

https://gist.github.com/duangsuse/54fa58d51e543e9c51fac2793aca82ab #Java #algorihtm #code 又败了。 😢

开始的思路是用 Queue 模拟维护单个 stack 的 backtrace 路径 StringBuilder ，后来为了同时 IO 的子程序写错改了很多次
最后才发现， AlgorBFS 根本不能用非复制的方法构造 backtrace ，必须是每一步都记好路径才行，因为顺序弄岔了…… 单点就得先找 ll, lr, ... 方向，不是四个方向随便先 lrud 记下来再每个去找就可以免 stack 的。 （当然鱼塔的代码也有能改进的地方，可是算法的要点是没法改的）

其实写了半天我的核心思想就是 BFS 能和 backtrace 一起用而且不需要每步都复制路径，这当然是扯淡。 🤪
待会我往上加一个 nullable 递归 DFS 的，BFS 复制的有点慢。

本来打算发给鱼塔的，我看我自己也不会写。 唉

🌚 生草的时光总是过得飞快， DFS 没有寻到最短路径但是的确能用。 一个半小时就过去了
这时候我终于体会到 #OI 生的坚困难苦难艰困，实在是太强自不息息自强了。 😭

记得之前写的文章里也有走迷宫，那个大概也不是最短路径，最短可能要每步选 minBy ，草
我都不能把 LIFO stack 和 recursion 对应起来，只知道用递归程序这样

传 history 大概是为了快一点，避免重分配 List 或者是为了能尾递归(误人子弟) 其实就相当于我的 char+String 实现方式
注意这个 #Haskell 版用的也没有 HashSet... 现在发现 let (x,y) = p in x >= (length m) or (y >= length m!!x) 大概是写反了吧 噢不这个矩阵就是 [y1, [x1,x2]] 的竖向...

#algorithm #learn 关于这两个算法说一句，它们其实还是能秽土转生的🤪。

AlgorBFS 只要把它的 FIFO Queue 改成 LIFO Stack 就活了，但是原来在 Iterator.next 维护的路径就要改成在 poll() 后的头部撤销失败尝试，换句话说也就是没有灵魂了（灵魂是只靠改迭代器就能实现单 item 多 links 路径回溯的解决。
当然，也可以选择 Yuuta 式的记录 path 的 copy ，但那样 BFS 内容就是 [int, String] 二元组了（而且后面还要 filter 掉一切走不通的，效能非常低。

而对于第二个已经正确的 DFS，找到最短路径即便用 UDLR, LURD 的试走顺序也没用，唯一的方法是（应该明白这个算法是拿来走有遮挡块的迷宫的 不是求直角最短径的）

思考一下，以 UDLR 扫描大概是先达到顶边，试过出界点的块试 D 已走过，于是试 L ，再 D 到末尾再 L 就会出现这种非常奇特的填充方式……

之所以找到的路径这么曲折就是因为怎么走都是这个模式，而且因为试步有去重每个子问题也不可能试出更短的结果，所以如果迷宫有大部分空地，找最短路径只能预判两点相对位置，然后采取不同步序(如目标在右下，取步序 DRLU 和 RDLU 两次的最少步结果。

至于为什么我自己不写呢…… 一部分原因是我精力还没有电击小子那么充足🌝 还有 我想让它们死（ #endFork

#java #zhihu #go #typing