太艹了，居然这都不会写…… 🤪
def combinations(items: set):
return [[item] + combinations(items - set([item])) for item in items]
[[1, [2, [3]], [3, [2]]], [2, [1, [3]], [3, [1]]], [3, [1, [2]], [2, [1]]]] 也不对…… a*b 吗……
def combinations(xs):
return [ [x]+combinations(xs[1:]) for x in xs ] if len(xs) != 0 else []
还是不对…… 其实这个是要 flatMap 的

from itertools import chain

def flatMap(f, xs):
return f(xs[0]) if len(xs) == 1 else chain(f(xs[0]), flatMap(f, xs[1:]))

list(flatMap(lambda c: [c, c.upper()], "abc")) == ['a', 'A', 'b', 'B', 'c', 'C']
好了，我终于记起来最开始是咋组织的程序了……
啊……不对，我想起来了，之前处理的数据结构是 [a, [b1, b2], [c1, c2]] …… 这次的有点区别，不过实际上可以一样处理

def combinations(xs);
return flatMap(lambda x0: [x0+], xs)

def subtractSet(set, item):
newSet = set.copy(); newSet.remove(item)
return newSet

def flatMap(f, xs: iter):
try: return chain(f(next(xs)), flatMap(f, xs))
except StopIteration: return []
list(flatMap(lambda a: [a,a+1], iter([1,2,3]))) == [1, 2, 2, 3, 3, 4]

def combinations(items: set):
return flatMap(lambda item: [item, combinations( subtractSet(items, item) )], items)

……我真是服了，list set 都不是 iter、iter 又没有 copy，算了就此为止吧

今天早上起来我又想到了一种方法，好像解决问题了，给大家讲一下。

解：问A「如果我问B，他会说你的是真话，异或(logical xor) 左边的路是生路」
若真，左边的路是死路；否则右边的路是死路。

“他会说你的是真话” 和 “他会说你的是假话” 都一样，结果也无二 （不，应该是正好相反），我不讲这个了。

基本思路就两个：
1. 两个人，一个真话一个假话；任何的 logical negation 和反套命题到另一边都是没有意义的，做不到区分
我不知道这和 (&&) (||) (!) 以及 (=) 有什么关系，但看起来没法直接靠单层提问分出真假

比如，问「你是诚实的？」， map(A(it) neg B(it), cases)，事实上没法挑出撒谎的人，问「你说的是谎话？」也一样。

除非断言某个条件是真的，但这需要以第一个子问题是假的为代价提问

variable A, B : Predicate
variable way : Bool
given {
  A(p) => not B(p)
  B(p) => not A(p) //至少有一个是“真话”
}

然后思考一下怎么让 A 变成 truth(p), B 变成 falsely(p) 🤔
“如果我问另一人，他会说你的是真话”
A(B(way))
A(not B(way)) 不对，我的表达思路有点问题…… 算了不设计符号表达方式了，太菜

如果你问诚实者，“撒谎者会说你在说谎”，肯定
如果你问撒谎者，“诚实者会说你在说谎”，否定 🤔（WIP：错的？那好像依然不可判定啊……）（不对，撒谎者会把诚实者的断言再 negate 一遍，所以逻辑正确）
关于这个“撒谎”与否的问题，可以在保证两者定义（一个断言恒成立、一个断言恒为假）的同时，达到区分二者的目的
仅仅问关于 way 的断言，是不行的。

2. 等我们知道了谁是诚实的人，再利用子问题同时把关于路的判断“编码”进第一个提问，取回来
当然我们问的问题只能是「是否问题」，所以信息量比较有限，我们来看看：

需要注意的是，这里的等号 (=) 是一个双向关系(commutative relation)，你可以从左边推到右边，也可以倒着推回来。
（或者说，下面等号的语义实际是数学上的 <=> ）

有 p (这是谎话)、q (左边的路是生路)，

logical and:
T && T = T
T && F = F
F && T = F
F && F = F

若答案为F，无法分辨出 q=F 时是不是真话。
(T && F) 真相是 (neg way)，与 (F && F) 的真相 (way) 在确定上是冲突的

logical or:
T && T = T
T && F = T
F && T = T
F && F = F

若答案为T，结论同上无法分辨。
(T && T) ; (neg way) 和 (F && T) ; (way) 是冲突的

logical not:
!T = F
!F = T

刚才咱已经说了，不可能仅靠一元关系解决

logical xor:
T ^ T = F
T ^ F = T
F ^ T = T
F ^ F = F

这个就比较有意思了，因为最后的结论不会冲突，我们来看看。

F = 假话&生路 | 真话&死路

T 的情况是重点，因为它看起来像和 and/or 的情况差不多，但 T/F 和 F/T 实际上是一样的！
T = 假话&死路 | 真话&生路

所以得到否定答案可以确定那不是生路，肯定答案可以确定那是生路！

这个文，感觉什么「肯定」「断言」「确定」「消极」「T/F」用得比较没规范…… 请海涵。

这个答案感觉应该也是对的，所以这个问题实际上很简单

关于生路在左边“是真的”，
B撒谎、A诚实，生路在右边
B诚实、A撒谎，生路在右边

所以“串联”在表述上是对的，只不过后面的文字看起来不太严谨
……不对啊

关于生路在右边“是真的”，
B撒谎、A诚实，生路在左边
B诚实、A撒谎，生路在左边

依然没法区分啊！不对…… 可以区分 🙈

def honest(p: bool): return p
def cheat(p: bool): return not p

def wayProblem(is_right: bool, a=honest, b=cheat):
return (a(is_right), b(is_right))

bools = [True, False]
[wayProblem(p) for p in bools] == [(True, False), (False, True)]
def compose(f, g): return lambda x: f(g(x))
[wayProblem(p, a=compose(honest, cheat), b=compose(cheat, honest)) for p in bools] == [(False, False), (True, True)]
🤔 这算是区分开了？……！ 要不然你想怎么区分

秒打脸 气死我了 #Learn #Python #logics #Algorithm
太丢人了

#life 建议从电脑桌上下来休息的人 采取下蹲 / 把小腿压在不太高的桌子上 的方式 舒展身体
个人感觉效果还可以，从别人分享的 PDF 上看到的。

https://www.barretlee.com/blog/2019/12/17/the-value-of-expression/ #dev #tech

作者: Barret李靖 2019-12-17 13:25:00 本文发布时间为2019年12月17日13时25分00秒 分类: 随笔 标签: 领英行家 下面是正文内容 评论数: 0 热度: 280

领英中国近期推出了一个年度行家的榜单，关注我的朋友可能知道，我有幸入了榜。
领英对行家的定义是，在自己的领域中，根据自身经验和知识，为他人答疑解惑，分享行业洞察，提供经验干货。简单来说，所谓的行家，就是善于思考，乐于发声的人。

http://mouto.org/ #blog #frontend #dalao

#ParserKt 关于这个可选的 LayoutPattern，也的确是一个保留问题 🤔
不过现在可以设计一个关系式求解器了？

最后评论区提到 Vol. 75 把『hash function』说成是『加密函数』，而不是一般的准确度底线：散列，有点牛逼了

https://blog.skk.moe/post/paperclip-in-my-eyes/
#Blog #回形针PaperClip

我已经决定了，给 ParserKt v3 的解决方案模型上做一些变通

我会引入 Either<A, B> 数据，LayoutPattern 里现在就是 item, tail, layout 了
其中 tail 如果 parse 为 left，则视为 optional layout 的 no-layout 形式保存
否则以 optional layout 的 layout 形式保存，notParsed 语义不变
layout 还是一样。

这样就可以实现 if : 按空格后是否换行来判断 tail 了
Deep<T, L> 上保持原有的 Root, Nest, Term，Nest 的 children 为空列表则表示无 layout 的形式
Deep<T, L> 添加一个 ShortNest 只包含 item 和 tail 不包含 children

#Python #math 怎么用python解一元二次方程？ - Coldwings的回答 - 知乎
https://www.zhihu.com/question/34987285/answer/82449982

Parser Combinator 在语法解析的当中处于怎样的位置? - 知乎 #zhihu #parsing
https://www.zhihu.com/question/35778359/answer/64834591

后来有人发现用Memoization方法可以完美解决左递归的问题，怎么个解决方法呢？它的方法大概就是：变相Bottom Up！我之前比喻成「不断重试」引起了一些误解，然后我发现把它说成「变相的Bottom Up」似乎更易于理解，……

🤔 想想我第一次试图解决 leftrec 也是利用这种方法
“它检查到第一个分支有左递归，就直接尝试下一个分支Int并且记住这次匹配，然后再把这次匹配的结果当作Expr匹配到的东西，代进包含左递归的分支中再次重试匹配，直到失败为止”

我当初引入的是 LeftOr 和 leftrec {} (那时候 ParserKt 还不叫 ParserKt，也没有 Decide 这么精确的名称)

遇到有 leftrec 的情况，LeftOr 会直接跳过、匹配余下项目并保存到 LeftOr 的状态里，然后再回来匹配 leftrec 里的情况。
不过现在 ParserKt 强制性要求不允许 left recursive 文法，而且将 operator chain 的 parsing approach 改成了 InfixPattern 的递归栈模式。

我觉得对 parserc 来说，没有“变相”这么一说，反而是那些字符串匹配算法该被视为是 parserc 的变相，因为它是最贴近程序设计语言本身的结构的解析方法

“ParserCombinator本质上就是一个递归下降算法，只不过那些状态迁移在它这里变成了函数调用而已。
Memoization本质就是查表法，通过记忆避免左递归和部分回溯。左递归可以完美解决，但只能支持局部回溯，解决之后的也许就不该叫Parsec了。参见Packrat算法还有OMeta，另外Packrat算法中有一部分跟计算First/Follow set有点类似。
ParserCombinator最大的优点是：优雅。”

这几点基本是刚接触到的人也都明白并认同的。

https://github.com/thautwarm/EBNFParser #GitHub #zhihu #cs #PLT #TT 啊，原来红姐是这个人啊！

有什么代码会让你产生“这种代码我一辈子都写不出来”的想法？ - AnxQ的回答 - 知乎
https://www.zhihu.com/question/357618826/answer/913362196

才发现最后一条

#+quick-lambda
#+pipeline
from functools import reduce
reduce(_0 + _1, [1,2,3]) | print([_0_]*3)

看来我之前觉得红姐以往的命名方式有点语义不准确，是真的了