跳到主内容

角膜的折射率

如果在眼科书或者眼科设备的说明书上查找, 会发现有两种角膜折射率

  • n = 1.3375
  • n = 1.376

真实的角膜折射率是1.376, 而1.3375是一个测量角膜K值时使用的人为设定的测量用折射率.

下面听我解释:

阅读更多…

以电视剧的方式工业化生产MOOC

在2013年的时候, 我写过《以电视剧的方式工业化生产MOOC》, 提出

网络课程可以『电视剧化』的。 完!全!可!以!雇!佣!演!员! 来!表!演!讲!课!

昨天发现一个Socratica做的抽象代数课程(Youtube链接, 国内Bilibili搬运 ), 课程浅显易懂, 而且老师非常漂亮, 甚至有一点魅惑(参考第5节习题课), 一口气就看了20多节课, 把以前在看《组合数学》时留下的群论补充了不少.

21-Simple Groups - Abstract Algebra-0001

今天经@goophile 提示, 原来讲课老师是Liliana Castro 一位巴西女演员, 演过不少电影和电视剧.

真是表演与公开课结合的典范. 想到其实是一位女演员在讲解李群, 有一种中文屋 的实验戏剧之感.

阅读更多…

角膜屈光手术后IOL计算

角膜屈光手术, 包括但不限于Lasik, Lasek, PRK, 半飞秒, 全飞秒……, 做完之后多年, 如果出现了白内障, 要换人工晶体. 这时直接代入常规的人工晶体公式是不行的. 要使用新的计算方法.

好在发明新的人工晶体计算公式是名利双收的好事, 于是过去15年, 至少出现有30种以上的公式. 然后还有更多的临床研究, 对比各种公式的优劣. (医学领域的“什么值得买”)

最近读了一篇这样的对比综述, Intraocular lens power calculation in eyes with previous corneal refractive surgery

python实现

于是把其中的各种公式重新用python写了一遍. 代码放在github上: https://github.com/goldengrape/IOL_calculate_with_post_corneal_refractive_surgery

阅读更多…

如何快速进入工作学习状态

工作日前的准备:

  1. 前一天晚上睡前确保在微信“发现页”中已经关闭了朋友圈.
  2. 前一天晚上或之前, 订阅好“无忧公主的数学时间”, 微信号是 wuyoushuxue .
  3. 前一天晚上或之前, 将“无忧公主的数学时间” “添加到桌面”.

工作日当日早上:

  1. 工作日当天早起, 不要打开微信, 先点击桌面上的“无忧公主的数学时间”快捷方式.
  2. 看一道数学题, 如果一眼就能看出答案, 另外找一道.
  3. 开始日常的洗漱、吃早饭、通勤……, 开始工作.
  4. 注意, 通勤时不要看朋友圈以及其他社交网络, 不要看新闻, 可以通过“讯飞有声”听电子书.

工作开始后:

  1. 首先进行输出工作, 至少一个番茄时间段(25分钟). 所谓输出就是自己写东西, 比如写代码、写email、写文章、做ppt等.
  2. 休息时可以拿出一张草稿纸, 试着解决无忧公主出的数学题.
  3. 第一个输出时间段之后才可以摸鱼.
  4. 如果刷微信朋友圈, 可以临时开启“发现页”中的朋友圈, 看完后及时关闭.
  5. 刷其他社交网络类似, 尽快及时关闭.

以上流程的关键是:

  1. 在早起后第一时间, 先往脑子里装一道数学题. 并使之保持悬而未决的状态.
  2. 第一组输出之后才开始允许输入.
  3. 为浏览新闻、社交网络造成一定的困难.

以上流程对我自己有一定的作用.

阅读更多…

金葡流简报术

简报两大困难

根据我多年来做简报,包括但不限于PPT/ Keynote的经验,做简报有两大困难:一不做二不休

所谓“一不做”,是不开始做,严重的拖延症发作,几张PPT可能要做上一个星期。只要打开电脑就不可避免会被其他的网站所影响,即使在查阅与简报相关的资料,也可能在维基百科甚至是在pubmed中迷失方向,看了一大堆不相干的文件,学会了许多不相干的知识,但PPT还是没有动。

另一大困难是“二不休”,可能直到deadline绕颈,被逼不得不动手以后,又在PPT中塞入了太多的内容,写下了太多的文字,加入了太多的动画,在真正演讲的时候排练不足,时间控制不好,讲着讲着发觉时间不够用了,于是不断的“过、过、下一张、下一张”,之前的辛苦制作,给浪费了许多,还给人留下了准备仓促的坏印象。

金葡流简报术

综上,我根据自己平时的工作特点,开发了一种做简报的新流程,被网友@octw 赐名为“金葡流简报术”。

阅读更多…

成人自学的困难

昨天翻译完了15页的python教程,想就成人自学再说说。

现象

python上手应该很容易,如果有老师在身边督促指导,就用这15页的教程,恐怕快则一下午,慢则一周就可以自己写一些简单的应用了。

但学python真的花费了我很长很长时间,我发现我从2003年就开始学习python,一直学到2017年才算学会了基础(因此万幸躲过了python 2)。用时14年,而不是7天。

原因

究其原因,我觉得是因为放弃太容易

成年人有稳定的收入,有常规的工作、生活。要维持这些,以前学会的东西已经够用了。学习新东西在短期内并不会对生活造成什么太大改善,如果放弃学习,短期内也不会产生什么不良后果。

相比起来学生时代就非常不同,别说放弃一门课,就是一门课的成绩稍微下降一些,也会寝食难安。如果挂科了,简直是天塌下来一半。想起来我大一的时候每周40节课上满,必修加选修上了13门课。(没错,我翘了一门必修课在同一时间选了另一门选修课)。

理论上,要把学习压力重新加在自己身上,成人也可以快速学习,大家都是学霸出身,没什么理由学不会。但实际上,虚拟的压力并不是压力,没有实质性的威胁算不上威胁。

解决方案:

  • 尽量平滑学习曲线:放弃的理由常常是一丝一毫的困难,一旦放下就很难再捡起来,或者很久以后才能捡起来。那么,就尽量不要制造额外的一丝一毫的困难吧,比如:
  • 用1500页的书去学python。天呐,1500页的小说我都要犹豫是不是去看,何况1500的教科书。15页的python教程已经都觉得长了。
  • 在本地电脑上用pip安装python库。类似可以推广到在本地电脑上安装开发环境学习某种语言。那绝对是可怕的拦路虎。REPL.it上已经做好了几乎所有语言,打开网页用就行了。或者用各种在线的jupyter

  • 享受过程(process),而不是追求结果(product)。这是从coursera课程“学习如何学习”上学来的一招。

  • 这一部分的视频在此
  • 就是说把学习作为日常消遣的一个选项,既然都是kill time,那么看电视剧和看公开课也是可能互换的。《史记》《资治通鉴》里,随便翻出个故事,不比现在电视剧里的情节狗血多了。
    • 市场环境不好,公司里能干的员工一个接一个辞职。有一天一个基层程序员刚跑,CFO就去追了,追回来以后还让CEO给提升到CTO的职位。CEO看了看简历,该程序员原来在竞争对手那边一直就是个小PM,没做过什么大项目,还曾经被拖库攻击过。但CFO坚持。现在如果你是CEO,该怎么办?剧情狗血吧,哪有这种公司会发生这种事情呢。这个故事又叫做“萧何月下追韩信”。
  • 既然是享受过程,就不要问自己学了多少,学到什么水平了,练习慢慢做,经常做就可以。三天打鱼两天晒网是最佳,不要给自己太大压力,也不要有太大幻想。“无挂碍故,远离颠倒梦想,究竟涅槃”。

比如,这是前一段练字的结果,写到开心就好。 未命名

补充一下:

享受学习的过程本身,享受学到的知识和技能,这种“自由而无用”的事情,只有成人才能体会到乐趣。儿童是很难从练琴、练字、练球、练拳……体会到乐趣的。能够把重复行为作为冥想过程来享受的,只能是衣食无忧的成人。

误解

贴出本文后,eMuyi认为

没有明确 motivation 的学习就是很低效。如果有一个明确目标,比如建立个人网站,学编程就很简单。

有明确需求驱动的学习过程确实是高效的,但是这也是最容易被放弃的。对于成年人的学习,最容易质疑的就是需求本身。比如“建立个人网站”,是自己学成全栈,还是直接找个静态网站生成工具然后写写markdown?甚至找个外包花钱做一个。这样一比较,得出的结论很可能是“我这岁数再学习______实属浪费时间”。

很可能在一定经济实力之后,各种明确的目标都是可以被购买的。而自身的时间价值如果又很高,两者比较就容易选择外包购买而不是自己学习。这和年轻学生又不一样,当学生的时候外包买不起,只好自己学。

欲速则不达。

所以前面我给出的解决方案中,就是要放弃明确的学习目的,转而体会学习过程中的乐趣。这种乐趣才是持久的,可记忆的。

15页python教程翻译

起因是有人把一句戏言当真了。

王佩说开始看:

中文版的《Python学习手册》,厚厚两大本,1500页。

我一看就觉得他学Python的计划要危险了:

别把这事弄复杂了,python就是轻巧的语言,15页的教程满足日常上手即可,然后每用到一个模块再临时去stackoverflow上查。等各个常用模块都用过一遍了,再去看书什么的。 买回来1500页的厚书,高概率是学不下去了。 动手,并且体验写代码的乐趣,才是学语言最重要的事情

两个月以后波澜翻出这条推,问

请教15页的教程有名字吗?谢谢

我其实只是把1500页删掉两个0,随口说出的15页。但我确实觉得网上高概率能有个15页的python教程。于是搜了搜,果然找到一个还不错的。

PartIA-Computing-Michaelmas 是剑桥大学Engineering Tripos的课程。关于python的13节,关于IPython magic command的1节,关于Jupyter notebook使用的1节,一共正好15节课。每课一个jupyter页面,一共15“页”。

我看了看内容,还不错,覆盖的多数科学计算所需要的内容,也就是我说的“满足日常上手”。而且附带有练习题,并且可以直接在azure notebooks上运行。满足我说的:“动手,并且体验写代码的乐趣,才是学语言最重要的事情。”

里面还有不少我以前不知道的知识与八卦,比如阿丽亚娜5号为什么爆炸爱国者导弹为什么工作100小时以后就放过了飞毛腿波音787为什么每284天就要重启……很有意思。

比我自己写的面向眼科医生的python教程要好。考虑到我一直想着有朝一日可以开个工作坊给一群眼科大夫们培训一下午python,让大家学会写基本的程序,以后也方便交流。所以我就把这15页的教程给翻译成中文了。

15页python教程的中文翻译版 : https://github.com/goldengrape/PartIA-Computing-Michaelmas-zh-CN

目前翻译得比较粗略,可能还有很多需要修改的地方,反正是在github上,随手就可以修正。也欢迎各位读者多多提issue,帮忙改进。

谢谢。学习愉快。

大神面镜维修

今天潜水的时候,发现面镜漏水。仔细观察,发现是胶垫没有很好包裹面镜镜片的边缘。可能是挤压造成了镜片和胶套的变形,导致有一点点松脱。

IMG_20190721_214540 (事后复原出问题的部分)

在水边弄了一会儿没有搞定,反而把镜片整个给拆下来了。这面镜可是我自由潜水老师赠我的宝物,回来后经过一番努力终于修好,

大神面镜,准确的说应该是Aqua Lung Sphera Mask,

IMG_20190721_214303 拆解过程详解如下,不失一般性以右眼为例:

阅读更多…

公理设计笔记(4)

所以“公理设计”,就是基于两个公理:

  • 最大化功能模块的独立性
  • 最小化信息量(~=最大化成功实施的可能性)

这样做的好处:

甲方总是善变的

客户需求就是用来不断改变的,就是用来不断折腾乙方的,因为甲方通常也不知道到底要什么,得折腾几次试试看,才能明确目标。如果把搜索引擎看作是乙方,这跟搜索个信息是一样的,搜索就是个学习的过程,一开始的时候往往我也不知道搜索什么,搜几个词试过以后才能明确到底要找什么。我当过甲方也当过乙方,我知道大家都是地球人,客户需求就是个不断变化的过程。

但deadline是不变的。

如果能够一开始把FRs(功能需求)和DPs(设计参数)独立得很好,那么已经做过的事情就不算完全浪费,还有可重用的可能性。独立性越高,浪费的工作就越少。

而如果各个功能模块一开始就搅合在一起,那需求改了,就只好从头开始了。

MFE 594 An Introduction to Axiomatic Design Part 4-qURM1A1BZJw-0001.png

面向对象与结构化

我最早学计算机语言的时候,还是结构化编程的时代,后来才开始面向对象编程。我其实一直尽量躲避面向对象编程。一部分是因为我只是做些科学计算,多数情况下一个东西算一遍就完了,不需要建立同一个类的多个实体;另一部分原因是因为设定类这事太“艺术”了,我不知道应该怎么设定,比如一个光路追踪的程序,是把光线设一个类,还是把界面设一个类,还是光线和界面都设定成类。

《公理设计》这本书中专门有一章讲面向对象的软件设计,我还要再仔细看看这部分。争取能再深入理解一些。

创新发明的套路

发明是有套路的,作为发明家我知道一些。这里又提供了一组思路。

  • 如果现有技术中有耦合的部分,看看能否解耦合?
  • 现有技术中的FRs(功能需求)是否满足“不重复不漏项”的原则?
  • 重新在不同的域上划分不同层级的FRs(功能需求)
  • 新的技术/其他领域的技术是否可以突破现有的约束条件?

公理设计笔记(3)

前面讲解了目的,要尽量形成FRs(功能需求)与DPs(设计参数)的解耦合对应关系

尽量对角矩阵形成: $$ FRs=\begin{bmatrix} X & 0 & ... & 0 \\ 0 & X & ... & 0 \\ ... \\ 0 & 0 & ... & X \end{bmatrix} DPs $$

或者至少形成三角形矩阵: $$ FRs=\begin{bmatrix} X & 0 & ... & 0 \\ X & X & ... & 0 \\ ... \\ 0 & X & ... & X \end{bmatrix} DPs $$

阅读更多…