#China #dev #net #freedom #statement 当你觉得你翻墙是「小众」「与国家达成默契」时，应该想想那些为民众自由访问真正意义的『互联网』而努力，甚至被维稳的人。

你能翻墙不是因为你「高人一等」，更不会因为翻墙就让你高人一等，而是有社区的帮助，是因为不在乎有没有小白跪舔的一大群工程师里每个人的帮助。你能「建立国际“信道”」是因为同一个社会的其他人，不是因为政府的默许。
如果技术上可能，政府会真的屏蔽一切它不承认的东西，可惜现实做不到不误伤。

也正是因为对开源社区和自由软件的感激，对同样无私奉献知识的人的赞同，我才一直努力保证自己所有代码和文档的开放性呢。

建议发到推特让粉蛆们看看

投稿By:Mark 🕯🕯🕯
#翻墙

#math https://t.me/c/1270345254/147519 《关于我在 iseki 私群获得数学大佬的一次帮助并写出了正常的图形计算器这件事》

#dev #math 日常精神分裂
但凡稍微有点数学直觉也不需要靠人问出答案了

A: 医生您好，我的项目用到了xy函数图，可我不明白怎么把x映射到屏幕宽、把y映射到屏幕高，并且可以移动和缩放
B: 你现在的做法是怎么样的？
A: x轴是 for(ix=0, x=vx; ix<w; ix++, vx+=x_step) y(x) 的情况
B: 看来误解比较严重啊，首先绘制的 vx 就过界了，我怀疑你绘制算法的其他部分也有问题
A: 假设不用绘制 ix 个，而是直接 for(x=vx; x<w; x+=x_step) ，绘制出的图像就会扭曲；后来试修了一下 ys[ix] 的存储效果也不好
B:
首先来说 x 和 hor (横向) xaxis 数轴，默认初始值是 for(x in 0..w) x/w
首先你迭代 vx 值的做法就不对，据我所知 let [vx,vy] = vp_xy ，也就是说它的值是直接和你 WheelEvent.deltaY 关联的对吧
测试时 deltaY= +-3 ，按这个差量 sin 等周期函数可能不会乱，其它函数不保证，但你的思维绝对会乱

所以说 vx 觉对要先和 w 相关下，再说。式子一定要简单，只有这样才容易是对的。

A: 这样会影响第二象限(x<0) 的绘制吗？
B: 你说的太远了，象限轴的屏幕位置是拿 coerceAtLeast 这类函数计算的，本质类似 x(y)=0 这样的函数，计算上不会影响
A: 那么 x 和 vx 到底该怎么关联？
B:
先试试 y(x/w+vx) ，刚才说了不行(vx 没系数)
y((x+vx)/w) 看起来可以，但如果 vx 为负呢？这时式子的值如果 abs(vx)>x ，会得到第二象限的值。实际上 x 在迭代中是 in 0..w 的，是可以。
y(x/w+(w/vx)) 呢？ deltaY 是 px (像素)单位，第二项是从 px 算出 shift 比率，是正确的做法，但 n/0==NaN 所以必须检查 (w/vx)||0

A: 那么第二条到底是对是错？
B: 其实是对的。 x 实际迭代于 0..w ，x 和 vx 的单位都是 px ，没问题
A: 那我们谈谈 y 轴吧，我画的 y 轴似乎是随着函数值扭曲的
B: 从 y 函数画 (x, y) 不是很简单的事情吗？为什么会扭曲？
A: 应该是公式的问题，整体是 h-h*y(x+vx)/(yceil-yfloor)
B: h-h*k 应该是 vert (纵向) 翻转吧？那为什么要 y/yBounds 呢？
A: 画 sin, x, x*x 什么的都有不同的 xrange 映射吧， sin(x) 始终 in 0..+-1 ，而 x 的值就是 0..w 了，所以……
B: 看来还是 x 轴建模失当的缘故， yBounds/1 可以用于 ky 的自动缩放，但不能作为 pY 的系数
A: 大概避免 y/yBounds 就好了，那么怎么缩放 y ？
B:
放大y轴就是增大x采样量， x*delta
缩小y轴就是减小x采样量， x/delta
当然，这会引入更大的 xrange

初中应该学过，连续函数的缩放和移动，还有x的内容
左移(y轴)就是 x-delta (前觑数据)，右移就是 +
缩放、移动就是正反相关、正负号的问题。
A: (试验了一下) 你说的很多都是错的，但帮我找出了正确的心智模型，我最终还是做出来了
B: x（
A: from/into 和屏幕/func 二座标系的关系果然还是很重要，你的式子是正确的，我原来以为写好 fromPx(px) 就万事大吉了，没想到 intoPx 也得对称才行
为此我手动穷举各项正反比、正负号，试了二十分钟，才发现最开始的没写对仗
B: 是数学，不要想当然。

#cs #math #ce #dev #statement
duangsuse:
Maxima 还是 Wolfram 🤔
我之前没听说过 mma
刚刚看那个 prompt 我还以为是 IPython (想想并不

MĐĦĐ:
wolfram alpha 也好用，还带解题步骤。mma 里面可以直接调用

duangsuse:
（数学软件果然是闭源的多呢
那就是 Wolfram 了，看看支不支持 Linux
我们大专的数学书也教这个

duangsuse:
感觉开源界编译原理的和符号代数的一 vs 瞬间就比不过了
类型推导也就那点基础，符号化执行
不像关系式，各种等式变形多的要死，看看现在 IDE 支持多少种重构了

看来还是数学好啊，懂数学的软件工程师写的东西最吼玩，不会弄一大堆没用的名词和设计模式
当然开源的也有很牛逼的人，但数学软件其实还是闭源的多（诡异的是这些软件基本免费可扩展，而且无障碍功能比许多开源软件都强）

#Security #game 🌚👍

#ai #ml #Web 厉害
#Learn 做交互性文档的人也很有创意

不容易啊…大概用了五十多分钟来调试神经网络模型（
交互视频各方面都特别优秀，性价比超高，创造神经网络的过程也很有成就感，可惜我数学实在拉胯 pic.twitter.com/DxadeVyD5H— Rachel 呱 (@Rachel030219) February 8, 2021

我又自己推导出一个，大致步骤是后序树遍历，构造新树，天哪，已知量(实际是子表达式形式)还不能逆序……

看哪个公式速度快用哪个
Python 一下子就跑出来了

w,h,vy,ky=200,300,0,1
%timeit sum(-(ky*(h*vy-h*w+py*w)/(h*w)) for py in range(10000))
%timeit sum((-(py-h)/h)*ky/ky-vy/w for py in range(10000))

2.85 ms ± 58.4 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
2.19 ms ± 38.7 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

结论手推的更快（那就用手推的

后来发现 -(py-h)/h-vy/w 更快，结果意识到手推错了， ky 没用到（草
再后来 (-(py-h)/h)*ky-vy/w 又对了（ 1.83 ms

#performance #js #drawing

重头戏来了，每个象限的 label 都要 coerceInBounds ，而且 (x,y) axis 标记的方向在第一象限是 right,top ，其他象限正负号、textAnchor 什么的全部不一样，我该如何复用代码，最小行数实现任意象限都能看值的数轴？

真的挺累的，数学的问题好不容易解决了，又来在我最擅长的地方打击我的自信心…… 其实我就想一招鲜，直接抄代码弄完了了事

我去 Desmos 那看了一下，他们好像是直接不做了，分别绘制 xy 轴和标签 数轴

不做了睡大觉这种事情我可办不到，可对这种情况优化就意味着 coerceIn(first,last, n) 的优雅方式要移除了…… 唉 😥 明明那么优雅

功能是正确了。 可是真的很头疼啊... 这种逻辑抽提，即便成功了也会让人看不懂吧

#js #code 看来的确意义不大，没有更好的写法了。 😟 为了多返回值创建数组或者使用 C 的模式，我做不到。