收集一些喜欢的歌曲的歌词中翻。作者在内文尽量注明。
16/4/3: Wake Up My Music りさ・えいみ(等) 翻译x2
别笑。
我不知道有少人像我一样思考过这个问题:“为什么‘当且仅当’不能被‘仅当’”替代?至少我知道不止我一个人,因为随便上网上搜索,哪怕是英文的“if and only if”,都能搜到一大篇同样的疑问。
绝大部分人的回答都是:当表示充分,仅当表示必要,当时仅当表示充要blabla……
这个回答有错吗?没有错。我们都知道、或者可以很容易地搜索出“当且仅当”的逻辑定义,可是并没有解决我们的疑问:为什么当且仅当依然听上去那么别扭?为什么直觉告诉我它可以被仅当替代?
在我们开始之前,我们先复习一下逻辑上此词语的定义。
当:if,表示充分条件。例句:当A<2,A<3
仅当:if only,表示必要条件。例句:仅当A<4,A<3
当且仅当:iff,表示充要条件。当且仅当A<3,A<3
是不是很清晰明了?可惜的是,语言本身并没有这么精确。让我们回到日常生活中的语境之中,来分析仅当的意味。
首先要说明的是,其实在普通语境中尤其是口语中,仅当这词实在是用的太少。一个更常见的替代词是:只有。举个例子吧,
只有冬天下雪。
姑且不论这话是否正确(六月飞雪?!),这个论断表明了下雪只能发生在冬天,而冬天不一定下雪。似乎完全符合逻辑上的“仅当”的定义?
那么我们换一个语境。此问题来自于知乎某位用户,由于我实在找不到更合适的,直接照抄如下:
员工问老板:“何时放假”?
老板答:“只有周末放假”。
那么问题来了,有多少人会把这句话理解成“放假一定在周末,但是周末不一定放假”呢?如果在辩论大赛上,估计稍微眼尖一点的人能读出这层意思。但是日常中?我想大部分人会简单地把这句话解读成“周末放假”——一个充分必要条件。
这就是问题所在——在很多时候我们说仅当或者说只有的时候,可能恰恰表达了当且仅当的意思。我无法解释为何之前那个冬天下雪的例子为何听上去那么顺耳,大概是因为我们的常识所然?一般而言,如果我们要明确表达逻辑上的“仅当”的概念,我们会用一些诸如“能”、”会“的助词来消除歧义,譬如
只有冬天能下雪。
只有冬天会下雪。
这一下“必要但不充分”的感觉就出来了。甚至更强烈地,直接上“可能”:
只有冬天可能下雪。
谁再说有歧义我不打死他!
话又说回来了,“只有”并不是只有(……)“仅当”的意思。还有一个挺常见的意思是表示拥有权的,类似
我只有四个苹果。
我不知道在学名上这种命题和之前一直谈到的那种有什么不同,但至少它不是“if…then”类型的条件判断语句。而且我们可以看出,在这种表拥有权的使用场合下,“只有”的意思就是“有且仅有”。没有人会得出“我可能并没有三个苹果”之类的结论。我可以大言不惭地说“有且仅有”就是多余的,意思和“仅有”完全一致。这和之前“当且仅当”的情况就有巨大差别了。可以说这两种情况的不一致性加剧了“当且仅当”这一短语的反直觉性。
不得不承认,因为我不是语言学上的专家,我依然无法给出肯定的结论。但是至少,下次再有人为这个问题而感到迷惑,好歹他能搜出一些除了逻辑定义之外的东西。
……其实只是突然蛋疼地又在整理书签而已。标记为“download”的书签有30个,又挂了不少,而这离我上次清理甚至还不到1年。像上次一样,记录一下以示缅怀。
搜快传资源用的(其实某种程度上可以相当于迅雷离线搜索了),现在快传本身都很少有人用了。快传大概是第一个自己不(特别)作死但是逐渐消亡的网盘,主要是后来者百度网盘太过便利的缘故。
之前一个整理的非常好的美剧下载站点。不过后来都去人人影视了也就很少上了。看了下现在需要用户名密码才能登录,我猜八成里面也死了。
域名还在换成了别的东西……看名字也该知道原来是下电子书的。
电子书之家——已经嗝屁。提示“Shared IP”…
http://imm.io/
http://imagesi.com/
图床
—-存活成功的分割线—-
章鱼搜索——这货居然还没死。其实就是一个高级版p2psearcher。这俩软件我都从未用过就是了…
TSearch,和上面那玩意差不多的东西我猜。
这俩搜美剧电影的。不过有yyetes,这些备胎基本没有用到的机会。
目前最好的(英文)电子书(教科书为主)网站几乎没有之一。
另一个电子书网站。
原来叫逛大街的,后来大概是觉得不够直观,现在就叫逛电驴了。
现在下片儿/剧集都靠人人乐
下MSDN镜像的。主要是MSDN我告诉你的排版不够友好,所以备用一下。
↑写文章的时候还活着的,现在居然也嗝屁了orz
原名资源海(ziyuanhai.com),也是个迅雷快传/种子索引站,来源不明。华点是“排行榜”功能。但是我看了下…现在排行榜好正常啊,只有一般的AV和非18X资源!原来都是各种xx门之类的偷拍视频……
看起来特山寨的一个中文bt站但是居然至今都没有死……
1年内换过一次顶级域名(sx->se)。海盗湾本身不用介绍了吧
这些常见的bt站就不介绍了。
iTunes一直是个很好地下载高清CD封面的地方,几乎涵盖所有主流歌曲(尤其是ACG音乐),而且乃是数字原档,质量有保证(虽然偶尔也会有几张明显色域转换有问题的,八成出版方一开始给的源就是错的,毕竟日本IT…)。
举个例子,广场舞OP
复制其中图像的地址,即
http://a2.mzstatic.com/jp/r30/Music5/v4/56/94/1f/56941fcf-ee47-d474-7e3e-f0bea7f8da0c/cover170x170.jpeg
将170×170替换成600×600或者1200×1200即可分别可以得到相应大小的封面,看你的需求了,我一般下载600px的就足够。不过最近我突然发现iTunes莫名其妙地将封面质量缩水,使用了极高的jpeg压缩率。Apple此举的目的不明,也许是为了防止别人通过iTunes扒图,毕竟封面图也是有版权的。而且不仅限于jp区,至少美区也有同样的问题。
不过稍加搜索,我就找到这个第三方网站可以自动提取iTunes的封面图。虽然UI有点麻烦(每次都得选区域、类型),不过他提取到的图正是之前iTunes默认显示的高质量封面图,可见iTunes并非完全改用低质量封面图,而是搞了两套不同质量的,一套用来显示在网站上,另外一套我猜依然在给正版用户下载的数字音乐中使用。对比这两张:
我相信即使对于不是很敏感的人来说应该也能看出区别。
当然了,一般大多数专辑(尤其是新专辑)的封面用Google image搜索即可找到不错cover图,只是各种来源的图混杂在一起,对于强迫症患者来说总是感觉有些难受。顺便一提,Last.fm也经常会有很棒质量的封面,一般都是PNG。
2017/10/9更新:现在iTunes网站上默认的地址已经修改,变成了诸如:
https://is4-ssl.mzstatic.com/image/thumb/Music3/v4/8e/1d/5f/8e1d5f93-917c-6c49-c331-a62830fdf0c9/AVCA-74538.jpg/268x0w.jpg
这样的地址,JPEG质量似乎和API获取的一样了,之需要改最后部分的“268”为9999即可获得最大的尺寸。(但是我总感觉这个质量似乎比当年API获取的差是怎样……)
大概几个月前起,我就一直遇到Youtube视频无法正常快速加载的问题。详细说来,就是打开一个Youtube视频(包括站外内嵌视频)时,有很大概率(>20%)视频无法立刻加载,而是要间隔10几秒甚至更长时间之后才会开始播放,甚至直接显示“遇到错误”。如果F5,一般可以解决。一开始我没把这当回事,以为只是临时性的网络不畅。但是随着时间的流逝,我发现此问题不但没有自行解决反而越来越严重了。尤其是在站外引用的情况下,F5整个页面也不现实(比如在feedly里,reddit中)。
图中可见莫名10秒的load间隔。
今天我终于下决心要解决这个问题。我一直以来都以为这是由youtube center这个脚本导致的——原因很明显,因为只有他专门对youtube进行修改嘛。在其github上搜了一圈,发现没人提过类似的问题,这让我稍显疑惑——毕竟youtube center的用户还是很多的。在新profile上安装了youtube center并且加载我的设置之后,发现果然无法重现这个问题。看来这次的毛病不是那么简单了。
关于排查Firefox的问题,主要应该分为以下几个步骤。
1. 排除是否是Firefox独有问题——否则如果是因为网站本身写的屎导致的,你调试一万年也没解。解决方法自然就是用Chrome和IE测试咯。当然有些问题,比如baidu的v.gif问题——即使你知道是Firefox独有你也没办法。如果是Firefox独有问题:
2. 排除是否是当前profile的问题——新建Profile。在这里强烈推荐一个神级扩展——Profilist。可以在不关闭当年Firefox的情况下重开一个使用其他profile的Firefox,而且完美契合29+的新UI。如果是当前profile独有问题:
3. 排除是否是Cookie或者扩展的问题——分别用隐私窗口以及安全模式(-safe-mode)测试。一般而言,和cookie有关的概率比较低,如果发生了就清理一下cookie就好。如果是扩展的问题,那么进一步用2分法找出问题扩展。记住,很多扩展自带的的“停用”功能并不能彻底消除其造成的BUG,保险起见请使用Firefox插件管理本身的“禁用”。如果问题依然可以重现:
5. 备份后逐步删除profile中的文件,看何时问题会修复。一般而言先从pref.js下手。如果确定问题是pref.js,再打开这文件一项项地扣罢…
顺便一提,对于这种无法“必然”重现的问题,最好设定一种方案来检测。比如我是自行设定“连开15个视频,看是否出现无法立刻读取”的方法来代表“能否复现”。
经过前4个步骤,我发现我的问题出现在我的profile中——但是和任何扩展都没有关系——因为安全模式也能重现。另外一个我怀疑的重点——adblock plus,也成功在新profile证明无关。因此,在接下来的测试中我都保持仅使用adblock plus的状态,因为如果不用adp每次开视频前面的广告太tm烦了。
删掉pref.js之后问题消失,那么来源就很明显了。打开pref.js之后虽然有高达几百项,但是其中extensions相关的可以忽略。我很快就发现和这个问题可能有关的几条——network:
user_pref(“network.cookie.prefsMigrated”, true);
user_pref(“network.dns.disablePrefetch”, true);
user_pref(“network.http.pipelining”, true);
user_pref(“network.http.pipelining.ssl”, true);
user_pref(“network.http.proxy.pipelining”, true);
user_pref(“network.proxy.autoconfig_url”, “resource://jid1-zv8ehywtdnutwq-at-jetpack/unblock-youku/data/proxy.pac”);
user_pref(“network.proxy.socks_version”, 4);
其中重点是pipelining那几条。我猛然想起,大概半年前根据卡饭的一个“优化”帖,曾经修改过这几个参数。删掉之后,问题立刻解决。
这已经不是我第一次在这种问题上吃亏了。我自认不算是“不求甚解”的人,但是这种模糊的“会提升性能”的说法总是非常有吸引力。而且我也曾在英文网站中搜索过一番,关于pipelining的说法基本也是以正面为主——虽然事实上我开启pipelining之后并没有感觉到什么区别——也没有变快,也没有变慢。如果没有这次的事情发生,我可能一直就这么保持他开着了。不过看来,default is default for a reason.. 身为一个“默认设置”强迫症,此刻感觉头顶青天!
外一则
之前我的Firefox一直有附加组件管理界面顿卡、每次禁用组件后UI不会立刻变化等各种BUG。前一段病症加重,直接变成了无法禁用组件(每次禁用组件后,Firefox.exe进程无法正常退出)。把所有的组件重装一遍之后虽然解决了,但是UI顿卡和刷新不及时依然存在。最后把同步功能关闭之后就好了……firefox sync你(依然)好嘢!看来果然不该对29的新同步系统抱有任何期待(顺便一提,我用新Profile测试同步,扩展根本同步不过来好吗!)。