>>>
listOf(1,2,3).zipWith(listOf(4,5,6)) { a,b->println("$a $b") }.take(2)
1 4
2 5
3 6
[kotlin.Unit, kotlin.Unit]
好像正常，为什么刚才测试的时候 addMany 好像不正确？RingBuffer.kt
3.5 KB
我修改了一下代码，比如移除了不适合的类型抽象、改进了
until （新模型），现在看起来代码更好看了>>> r.addAll(listOf(1,2,3))好。
>>> r.viewport()
[1, 2, 3]
>>> r.pop()
1
>>> r.add(2)
>>> r.viewport()
[2, 3, 2]
>>> r
Ring[[2, 2, 3]; ^1, _1, 3]
RingBuffer.kt
4 KB
#Kotlin 『用四种方法写 RingBuffer……』
DiffAlgorithm.kt
5.6 KB
最终版本的 diff 算法，到底是没有什么…… 都是实现细节
Forwarded from dnaugsuz
就是 diff 算法啦，规定输出是一个序列
diff 操作符不考虑其对称性等性质，只作为子程序看待
举例：
这样。
sealed class Change<out T>像是这样，[] 里面的东西代表 Inserted, () 里面的东西代表 Deleted，主语是第一个输入序列
data class Same(part: List<T>)
data class Inserted(added: List<T>)
data class Deleted(removed: List<T>)
diff 操作符不考虑其对称性等性质，只作为子程序看待
举例：
diff("abc", "aebc").toString() // a [e] bc
diff("abc", "ac").toString() // a (b) c
diff("abc", "aec").toString() // a (b) [e] c
diff("abcd", "a0c1").toString() // a (b) [0] c (d) [1] 这样。
Forwarded from dnaugsuz
>>> Diff.diff("Hello beautiful world".split(' '), "Goodbye cruel world".split(' '))
(Hello,beautiful) [Goodbye,cruel] world>>> Diff.diff("Good morning".split(' '), "Good bye".split(' '))
Good (morning) [bye]>>> Diff.diff("a b c".split(' '), "a b c".split(' '))
a,b,c>>> Diff.diff("a b c".split(' '), "a c".split(' '))
a (b) c>>> Diff.diff("a b c".split(' '), "a e b c".split(' '))
a [e] b,c>>> Diff.diff("a b c".split(' '), "a e c".split(' '))
a (b) [e] c>>> Diff.diff("a b c d".split(' '), "a 0 c 1".split(' '))
a (b) [0] c (d) [1]Forwarded from duangsues.is_a? SaltedFish
duangsuse::Echo
两个文件均可在 GitHub Share 里访问到。 [1] 随时欢迎大家加入讨论和使用（暂时没有附加任何许可证）。
我马上要把它们移植到 Kotlin Common（因为它们本来就对 Java 特性没啥依赖）
然后我会写 TypeEqualizer，写完我最后修复、更新一下我的《抓周》
然后我会写 TypeEqualizer，写完我最后修复、更新一下我的《抓周》
[master 78af361] Kotlin: three files因为是自己的抽象，完美兼容 KotlinJS/JVM，除了 java.io.Closeable 和 Kotlin @Throws, assert 不能用外都可以，其中前两个接口都可以直接在 Common 里静态链接实现
3 files changed, 283 insertions(+)
create mode 100644 Others/three-kt-files/DiffAlgorithm.kt
create mode 100644 Others/three-kt-files/RingBuffer.kt
create mode 100644 Others/three-kt-files/common.kt
我想写的 TypeEqualizer 还没动笔，一个有点麻烦的算法（numpreety.hanShow）现在基本上是没心情写的……
我应该把困难一点的东西留到以后做，比如把
理论不困难，但是实现真的不容易
我应该把困难一点的东西留到以后做，比如把
26 格式化成 二十六 的算法……理论不困难，但是实现真的不容易
duangsuse::Echo
我更新了 IDEA，可是我还是觉得原来的版本好用；我想写一个 Parser.kt 框架，可是我觉得现在弄一个解释器就好了；我工作效率很低；我这个下午只是重构了这个项目，我只学会提出函数是 Ctrl+Alt+M、找引用是 Shift+Alt+7 （好像）；我累死了
你们不要喷我的代码复杂，你自己来写一个试试？这个是 Kotlin Mulitplatform(JVM/JS) 的
写的算法是 diff 算法，我也尽可能的在简化代码了，可这毕竟本身就有点多分支…… 也容易把人弄糊涂…… 比如说我就不是很理解 isEnd 都有哪些含义
现在想起来了，刚才的想法，是原来想让 Parser.kt 变成有一个
可是看起来好像不能立刻考虑 toString() 的漂亮程度这种不重要的东西了…… 慢慢来，太多会要我的命
Feeder 已经是很方便的东西了，虽然它不是很优雅，比如每次 EndStream: Error 总是会得到 max - position == 2 的结果，因为首先我用的是 xs[position++] 所以最后一项被读取后 position=4，然后是有一次 FinalConsume（为了保证 peek 的确指示了 consume() 的一项这个性质）
不对，好像有个 bug，不管怎么样都不应该是 3(> 5) 这个结果啊
写的算法是 diff 算法，我也尽可能的在简化代码了，可这毕竟本身就有点多分支…… 也容易把人弄糊涂…… 比如说我就不是很理解 isEnd 都有哪些含义
现在想起来了，刚才的想法，是原来想让 Parser.kt 变成有一个
Describle 接口和 Document （就是 Haskell 的 Text.PP）模型而方便 REPL 什么使用的风格，不过就是有点麻烦（只要区间模型不滑坡，肯定是容易写出来的，关键就是有些时序逻辑，比如 Feeder 的那个 Iterator 就容易有问题）可是看起来好像不能立刻考虑 toString() 的漂亮程度这种不重要的东西了…… 慢慢来，太多会要我的命
Feeder 已经是很方便的东西了，虽然它不是很优雅，比如每次 EndStream: Error 总是会得到 max - position == 2 的结果，因为首先我用的是 xs[position++] 所以最后一项被读取后 position=4，然后是有一次 FinalConsume（为了保证 peek 的确指示了 consume() 的一项这个性质）
不对，好像有个 bug，不管怎么样都不应该是 3(> 5) 这个结果啊