控制台中VIM编辑中文时字符鬼影问题的解决
这个问题困扰我好久了,也不记得是什么时候开始的,也许是自从开始使用PowerShell时就出现了这个问题?控制台下使用VIM进行中文编辑,如果当前行有中文,那么这一行的内容编辑、选中,总会在行尾甩出一些鬼影字符。 因为近几年程序写得少、偶尔遇到这个问题就会换用其他编辑器临时救急,所以也就没放在心上。今天实在忍受不了,折腾了一个晚上终于找到了原因并解决了。 在vimrc配置中加入一行 set termguicolors 即可解决: 虽然说加入这行配置之后会导致vim的颜色配置与默认配置有了一些差异,但终归还是“彩色渲染”的代码,修改前后都是“赏心悦目”的状态,因而对于使用也没有什么影响。 这行代码的作用是让vim改用真彩色进行文字渲染,否则vim默认使用的是256色对文本进行渲染。而默认使用256色彩模式时,在显示复杂的 Unicode 字符(如中文字符)时,就有可能导致显示问题——无法正确计算出字符的宽度、从而引起鬼影问题。 上面的解释听起来很牵强,色彩管理和字符宽度能有什么关联呢……但毕竟它真的能解决问题,因而也就不再纠结其中的因果联系了。 奇怪的是用了很多年vim,以前从来没有察觉这个问题,似乎是最近1、2年才出现的问题。毕竟最近很少写代码,偶尔写一写、遇到稀奇古怪的编辑器问题也都是尽量避开,有的时候犯懒甚至就用notepad临时改动几行,所以也没有去深究过。感觉可能是: 1、或者就是自从windows弃用了控制台、启用了powershell之后出现的这个问题; 2、又或者是这个问题一直存在,只不过以前我在windows下一直使用的是neovim所以没有这个问题吧; 不确定,总之,经过上述调整,现在vim又可以正常的对中文内容进行编辑操作了。
使用ε-M极限证明问题一则
为什么? 直观上的感觉是,x趋于无限大,它的导数便趋于0,于是也便趋于0,最终的极限结果就是0了。这似乎很简单。但如果基于数学分析的角度而言,这每一步的理所当然,都需要经过证明,所以对于数学分析而言,这个简单的极限的推导过程,并不轻松,而是要啰里啰唆的说上一大堆,才敢给出结论来的。 它大体上分为两步:1、首先证明;2、然后利用连续函数的复合法则,完成复合函数求极限。以下是每一步的细节: 一、首先使用语言证明: 《普》中并未給出的證明、甚至都沒有提到這一事實,它似乎是默認讀者知道且相信這一極限的結果。這個簡單的極限從直觀上也確實一目瞭然,但是在更嚴謹的數學教材中,其實是會通過語言對它進行證明的。語言和語言相似,都是極限論證語言。使用语言完成证明的过程如下: 1、首先观察原始的题目,并且将原始题目调整一下写法:; 2、这个新的写法不再使用“等号”,从而表达式的意思变成了:当自变量x趋于无限大时,结果(因变量)将趋于0。调整成这样的表达之后,假设这个结论是成立的,那么它将意味着计算的结果与它所趋近于的数值0之间,是存在着一个距离的,而且这个距离可以表达出来,将这个距离表达为:; 3、此时 的含义就是“距离”,并且是 与 之间的距离。我们要证明的是,这个距离 可以任意的小、随意的小,想要多小就多小。换言之,假设 的确可以任意的小能够实现,意味着 与 可以无限接近,便可以将 视为 了; 4、现在直接大胆的提出:当任意指定时,自变量 时,的结果就比还要小。能否找到这个大胆的想法中的M呢?显然是可以的,通过不等式简单的变换,就能确定,也就是说自变量 时的所有x取值,都可以满足 的结果比还要小; 5、至此就可以得出结论:无论怎样小的 指定,都有 M 范围选择点可明确出来。因而可以实现,并且认为。此时的表达式便是:。(这里似乎还缺少对下标 的展开推导)。 二、连续函数的极限连续性:…
再谈昨天的“沃利斯积分“
昨天写的《沃利斯曾经解决过的几道积分问题》还存在一个令我感到“困惑”的问题,今天解决了,很开心。 昨天的文章中提到的积分:,通过换元法可以得到它的三角函数形式、也就是沃利斯积分形式:。而这两个等价的积分式又可以被统称为B积分,进而推导成Gamma计算式,完成求解。 这是昨天的文章中谈到的内容,结论无疑。 但是我的困惑在于:当我对上面诸多计算式,分别通过笔算、SageMath计算、计算器计算对比验证的时候,却发现我使用的计算器无法得到正确的结果,现象如下: 积分 积分式 Gamma结果 SageMath结果 fx-991CN结果 多项式积分 正确 正确 正确 沃利斯积分 正确 正确 1.569…… 问题现象表 可以看出我使用计算器得到的结果并不是正确的,原因在于在这个计算器的设置中有结果表达形式的设置,之前使用的是以数值作为结果表达形式,应该调整成使用弧度作为结果表达形式,通过这个设置的改变,才能得到正确的结果。 之所以要如此繁复的、不厌其烦的做这个验证,主要是心里没底,担心自己理解的不对。现在所有的辅助自动计算结果都与理论吻合、手算结果一致,我就可以放心大胆地说,这个知识点,我算是基本掌握了。 对于计算器,今天在查找它的设置时,额外了解到:计算器在进行积分计算时,使用了很多估算方法,例如辛普森法、梯形法、或者高斯-勒让德积分等。通过这些方法,计算器在给定积分区间内选取若干采样点,以近似计算积分值。 这些数值积分算法对我而言还很陌生、又觉得好奇有趣,只无奈精力实在有限,无法深入学习。
沃利斯曾经解决过的几道积分问题
在斯科特撰写的《数学史》一书中,P148页有一段简单的描述:沃里斯曾仿照卡佛来利的方法解决了纵坐标由的求积问题。 书上给出了如下若干积分及计算结果: 1、 2、 3、 4、 上面这4道题看起来还都是比较容易的,即便是第4题,只是计算量略微繁琐,但只要通过分部积分的方法,依然可以轻松得到答案。下面仅以第3题为例动笔跟着练习一下: 题目:计算 首先将多项式展开,然后利用分部积分法,对每一个简单积分进行求解,最终求和: 之所以使用第3题练笔,原因是后面的第4题如果如上方法推导的话,展开项更多,繁琐、浪费笔墨、且容易出错。但假设问题更复杂一点,例如想计算,恐怕就不再是“有一点繁琐”,而是会非常繁琐、几乎无法完成的事情了。 所以上面一系列相似的问题,还是应该再找一找更为通用、便捷的工具进行计算。自然而然的想到了利用换元法进行计算。以上面第4题为例尝试一下改用换元法完成计算吧: 考虑到积分范围是从0到1,计算式中又明显能够感受到毕达哥拉斯的味道,因而尝试对进行换元:。 换元准备1:重新调整积分上下限: 换元准备2:计算式换元: 换元准备3:微分项还原: 通过以上准备,最终完成换元: 至此问题得到了简化,能够看出最终的换元结果成为了B函数形态,将B函数原形写出来,目的是计算出B函数参数式: 即通过:, 可得到: 指明参数的B函数是: 使用转换: 最终得到Gamma函数: 其中,, 将以上三项计算结果带回Gamma计算式,得到最终结果 附:沃里斯简介 约翰·沃里斯(John Wallis,1616-1703)是17世纪英国著名的数学家、逻辑学家,也是剑桥大学三一学院的毕业生,后来成为牛津大学的萨维尔几何学教授。沃里斯在数学、物理学、密码学等多个领域做出了重要贡献,对微积分的早期发展也产生了深远影响。
两道极限计算的简单题目
两道题目如下: 1、计算: 2、求证: 一、计算: 解法1:极限定理法 当x趋于无穷时:分子是个正弦反复跳跃、极限不存在;分母x趋于无穷、极限也不存在。因而分子和分母都没有明确的极限值的情况下,无法用商的极限运算法则进行计算。 考虑使用乘积的极限运算法则进行计算:。 分解出来的两个因式的结果分别是有界函数和无穷小,他们的乘积等于0。 解法2:三明治法 因为,所以 左边有: 右边有: 不等式两端在x趋于无穷时,同时趋于0,所以中间的极限 二、证明: 这个证明比较难、甚至是非常难。虽然在《高等数学》和《普林斯顿微积分读本》的开始、最基础的章节中就有这个重要极限的介绍、以及证明。但实际上这两本书都故意忽略了一个基础极限:。 在《高等数学》§1.7中,这里几乎是“一笔带过”假装“显而易见”糊弄过去了;在《普林斯顿》§7.1.5中则是给出了上面的结论而也语焉不详的糊弄过去的。 两本书用的证明方法相同、也都忽略了上面提到的基础,我也先忽略、假装是个事实,完成证明:基本思想依然是利用三明治定理,设法找到两边的函数,通过两边的极限,夹近出的结果。 构建如上图形,其中圆为单位圆、半径,可以看出:,这个不等式的左中右分别为: 左侧: 中间: 右侧: 带入不等式,得到:, 将这个不等式各个部分除以并颠倒分子和分母、简单整理之后得到: 左侧:,注意这里是“假装显而易见先糊弄过去”; 右侧:, 通过三明治定理,即可夹近出中间的极限:。 注意上面的三明治极限都是取的,这是因为原式中的分母不能取0点,因而要分别求它的左极限和右极限,上面只是在计算右极限。相应的进行符号斟酌、调整,可以再求出左极限:。…
爱因斯坦的日全食实验
阿尔伯特·爱因斯坦曾在他的相对论中提出了一个著名的日全食实验,后来几经波折,最终被英国天文工作者和科学家们实施、最终证实了爱因斯坦关于光线会受重力场影响的观点及理论的正确性,这一理论和实验,标志着爱因斯坦相对论的正确性,从而轰动世界。 2019年5月16日,葡萄牙发行了一套关于爱因斯坦日全食实验的纪念邮票,包含邮票、首日封、小型张等多款邮品,官方介绍如下: 发行官网:https://www.ctt.pt/邮票技术手册:邮票官方介绍手册 这套纪念品中的邮票由2张票面构成,如果单看票面,只能知道它是纪念爱因斯坦提出的日全食实验,并不能对实验的具体原理详尽了解。在随邮票一同发行的产品手册中,则有着更多的信息介绍,可以清楚的看出实验的设计想法:通过在日全食时观察通过太阳周围临近恒星的位置,观察到光在重力场下会发生偏转、扭曲的事实。 爱因斯坦最初大约是在1905年时提出的狭义相对论,其中提到光线会被重力影响。但是最初的论文中并没有这个理论的设计实验,之后1907年时他对之前的论文进行补充、并在4年之后的1911年形成了一篇关于光线受重力影响的“补充论文”,其中给出了具体的理论公式和实验方案。在其理论计算下得出了光线可受太阳引力影响发生偏移的角度。这篇论文的原文和英文版在网络上可以找到。 上面是英文翻译版,下面是这篇论文的原稿: 然而在1911年提出这个实验时,并没有合适的日食事件可供实施这一实验。爱因斯坦呼吁当时的天文学家可以充分利用这段“等待期”进行筹备,他对这个观测实验十分期待并且投入了大量的精力以极力促成此事。 当时柏林大学天文台有一位年轻的天文学家埃尔文·弗伦德里希(Erwin Freundlich),读到了上面提及的论文和实验方案,他对此十分感兴趣,便与爱因斯坦联系并一同商讨进行此次天文观测。虽然如此,但限于爱因斯坦当时的学术权威和声望并不高,他的构想在当时并未获得更多人的支持,尤其是资金方面的支持。因而爱因斯坦甚至提出可以自己承担一部分费用、他给了弗伦德里希2000马克的资金用于初期准备。 就在前期准备得差不多、距离1914年8月的一次日全食不到20天时,第一次世界大战爆发了(1914年7月28日),德国裔的天文学家弗伦德里希在克里米亚被发现,俄国人认为随身携带着大量“摄影器材”的“天文学家”十分可疑,所以将他拘捕。从而失去了那一年日全食观测的机会。 想再一次盼到日全食,对于人类而言只能期待、别无他法。时间慢慢到达了1919年,是年5月29日将再一次发生日全食现象,好在那时战争已经结束(一战结束于1918年11月11日)。当时英国剑桥天文台的台长、天文学家阿瑟·斯坦利·爱丁顿(Arthur Eddington)决定完成爱因斯坦关于光线的实验——对当年的日全食进行观测和拍照。 整个实验都是由英国天文学家们共同策划、由英国相关部门出资支持的。这在当年很罕见,毕竟爱因斯坦当时身在德国、而英德两国在1919年时的关系并不友好。这一点上看来,科学家们似乎并不关心政治、也不在乎国与国之间的矛盾,他们向往和关注的只有科学和真理。 经过紧罗密补,1919年3月初,爱丁顿等人从利物浦出发,分成两支实验团队分别前往巴西北部的亚马逊丛林和普林西比岛,这两处都有着最佳的日全食观测地点。 之后的事情妇孺皆知、也是这套邮票上体现出来的了:1919年5月29日,由爱丁顿科考队在普林西比岛获得的照片最终被选用为实验结论样本,并通过后期的图像分析和计算,验证了爱因斯坦的光线理论。从而为相对论的底层补充上了重要的、无可动摇的实验依据。
小游戏(2)画一个小球并让它可以在画面中移动
因为之前实现的 Hello, world 程序是基于图形化窗口的,之所以仍然称为“Hello, world”只是一个编程约定俗成,其实更准确一些说应该是“基础运行窗口”,目的是将整个开发环境先搭建起来、跑起来。 既然是图形化的窗口,要做的事情自然不会是枯燥的文字输入输出,而是可以完成图形图像的绘制和显示,这就为完成一个简单的小游戏打下了良好的基础。 在这个“可绘图”的窗口中,通过使用矩形、圆形、矩形等基本的绘图指令,完成一些基本几何图形的绘制,这样就可以比较感性的感受到我们即将完成的游戏的外观样貌。虽然并不精美,也没有真正的游戏那么丰富的图像,但在初期进行“游戏原型”开发时,这是比较常用的方式。 这个视频就是在窗口中画一个圆形,并且每一次画面刷新的时候都调整一下这个圆形的位置,通过频繁的刷新、重绘,最终得到的整体效果就是小球好像在移动。 后面基于这个小球的绘制和移动的方法,将做出更多的几何图形,并且让他们按照规则进行各自的移动,彼此之间也会产生简单的碰撞检测和反弹规则。 需要注意两点: 1、对于真正的游戏,因为画面中存在着大量的图形元素,每一个图形元素都有自己的行动轨迹和运算过程,这将是对系统性能的极大挑战。所以在进行一个更为复杂的游戏开发时,并不能简单粗暴的按照当前的绘图、轨迹计算思路进行开发,而要有更多的考量。 例如对画面中的各个显示出来的图形进行可见性判断,如果它并不可见(被遮挡),那么就可以不进行运算或简化运算;对于某些复杂的碰撞或计算,要视图找出更高效的运算算法,以便确保游戏帧率得到保障;必要的时候,甚至会简化运算算法等等; 2、小球的行进过程、彼此的碰撞过程,实际上是对刚性运动物体进行模拟,我们自己实现整个物理规则,如果想实现的完善、正确,是比较复杂和困难的。如果真的要做游戏,更合理的做法是使用现成的物理引擎或游戏引擎进行游戏的开发。 当然现在这个“小游戏”并不是真的要实现一个成品游戏出来,而是我们计算机课程中的一道练习题,所以不允许使用现成的物理引擎进行开发,它实际上就是要考验我们自己是否有能力重新打造这些基本的方法和底层实现,所以没有偷懒的路径,只有自己一点点的将每一条物理规则实现出来。虽然我们实现的不一定完善、高效,但整体过程,还是要一步步走下来,才能得到一个比较满意的结果的。
小游戏(1)第一步是先写出 Hello,World
写任何程序的第一步,都是先写出 Hello, World。原因在于,能够撰写、编译、运行出最初的一个简单的输出、或者跑通基本的窗口,意味着整个变成环境的框架已经搭建起来并且通顺了。 以当前要做的这个程序为例,我并没有 Java 代码的基础知识、对正在使用的开发环境也不了解,但是我知道无论如何,也要先令开发环境顺利的部署、搭建起来。怎么证明我的开发环境是正确部署起来的呢?就是通过 Hello, world 进行验证。 这在今天对于开发者而言已经是非常友好、简单的了。从 Android Studio 官方下载 IDE 集成开发工具,在自己的电脑上一键安装,然后运行起来,基本就完成了整个开发环境的部署。与其说是“部署”,不如说就是一键傻瓜式安装。 如果放在早些年,仅这一步也许就要花费几天的时间,需要自己将整个编译链上每一个环节都调试通顺,甚至有大量的依赖工具或库,都是需要自己根据自己的电脑和系统环境准备、调整,不断地调整才能彼此配合妥当的。 受益于“包管理器”和“自动依赖检查”等概念和工具,并且受益于开源领域大量的预编译二进制包,今天这个准备过程已经非常简便。当然这是对程序的语言和开发框架而言,如果是新兴语言或行业应用、又或者是比较小众的环境,这个过程还是会令人感到痛苦和繁琐的。 无论如何,我们这次尝试进行的只是一个使用 Java 语言进行 PApplet 应用窗体的开发,所以对于搭建它的开发环境,显然是非常简单,一步操作即可完成。 在 Android Studio 中将初始的程序项目打开,并且点击运行,很快就能够看到一个基本的窗口出现,这意味着 Hello,…
試用Android Studio寫了一個小應用
一、做了個Android APP卻無法上架 大約半個月之前,我完成了對自己電腦的升級操作,新硬件很令人激動,無論是工作還是娛樂都十分順暢。於是我就想用這臺嶄新的電腦做些什麽有趣的事情。 之後大概花了兩天學習了一下Java語言和Android Studio的使用,然後便開始嘗試做一款小的APP出來。我原本預計要用30天的時間、6000行代碼左右,做出一個完成度比較高的應用。結果實際情況遠比自己設想的樂觀,只用了10天、2000行代碼,就實現了一個自我感覺良好的應用程式。 於是昨天又是一個心血來潮,花了25美元在Google Play注冊了一個開發者,想著將自己寫的APP發佈上架。結果在完成開發者的注冊之後才發現,如今的Google Play想上架一款新的應用非常難,門檻很高。 它有至少兩個我無法完成的門檻:真機驗證、封閉内測。 Google Play要求開發者完成真機驗證,雖然說幾乎所有的開發者都會有真實的Android手機,但是我的手機并沒有安裝GMS框架、也沒有Google Play應用、而且無法訪問Google網絡,這就導致我雖然有真機,卻無法完成Google Play要求的真機驗證。 第二點是封閉測試,這是更難以達到的。Google Play如今要求開發者在正式發佈應用之前,要有20人、進行14天的封閉測試。大概是說要有一個内部測試論壇用以討論、測試,連續14天的内測要求是活躍的、每天都有至少20人使用過這款應用。 就算對於一個非常有趣的應用產品,也幾乎沒有可能有人樂意連續20天使用。翻看一下自己的手機,如今除了微信、支付寶這樣的應用之外,還有哪一款應用是可能被用戶連續20天使用的呢?例如就算是每天坐公交車上下班、使用公交刷卡類APP,也不可能達到連續20天、天天使用。 同時我身邊也沒有那麽多的朋友、更沒有那麽多的朋友都能夠訪問Google Play應用商店或開發者社區,這就導致封閉内測對於我而言是肯定無法完成的。 大概看了一下網上的測試團隊,的確有一些專業團隊能夠承接測試工作,但是這些測試團隊幾乎都是按人、按次收費的,如果想完成Google Play的封閉測試,大約需要280人日,就算每一個人日我樂於付出100元的酬勞,這也是只是28000元的支出,才可能完成一次有效的封閉測試。 考慮到其中可能有些人臨時“放鴿子”、估計一次封閉測試支付要在3.5萬;如果一次封閉測試未能達到商家要求,再多做一次,那麽對於我的小應用而言,什麽都沒有做之前,就要先準備出至少7萬元用於完成“測試團隊的招聘”。這對於個人開發者而言,顯然是不可能、也無法接受的。 所以在看到上面真機驗證、封閉測試兩個門檻之後,我便後悔花了25美元開通Google Play的開發者賬號了。現在心情十分沮喪,不僅是因爲花了25美元的冤枉錢,更多的還是覺得對於個人開發者而言,沒有方向。 我現在基本放棄了將APP上架Google Play的計劃,轉而看一看有沒有其他的應用市場,對於個人開發者比較友好、或者索性就將自己做的應用直接打包成APK,裸包放在自己的網站上,供人下載、試用吧。 二、嘗試在Amazon Android…
防火墻設置不當招來SqlServer拒絕服務攻擊
因爲防火墻的端口設置不當,導致SqlServer的服務端口暴露給了外網,從而招來了密碼窮舉猜測攻擊。這次攻擊應該不是有針對性的,只是群掃群攻,但卻持續了好幾天,導致我的服務器宕機了。