5 Matching Annotations
  1. Jan 2024
    1. 序 前言 數盲,其實普遍存在於生活之中   「數學向來是我最爛的一科。」   「100萬美元、10億美元、1兆美元,隨便。只要我們可以解決這件事,多少錢都不是問題。」   「我和傑瑞不能去歐洲了,都是恐怖分子害的。」   數盲,是指沒有能力自在地應對和數字以及機率有關的基本概念。這項缺點讓太多在其他方面博學多聞的人受了很多苦。這些人會因為別人混用「隱含」和「推斷」而感到苦惱,但看到數字上出現錯誤與矛盾,就算是嚴重失當,回應時也絲毫不見尷尬。我還記得,有一次在派對上聽到一個人侃侃而談「繼續」和「持續」有什麼差別,當晚稍後我們看新聞報導,氣象播報員說星期六的下雨機率是50%,星期天也是50%,結論是那個週末下雨的機率是百分之百。那位自封文法家的先生覺得這話很對,就連我向他解釋錯在哪裡之後,他也沒什麼表示。但如果天氣播報員的語法錯誤,他可能會比較火大。人常會隱藏其他缺點,但數學不好這件事不一樣,多半都是明目張膽表現出來:「我連平衡收支帳都做不到。」「我這個人關心的是人,我不關心數字。」或者「我向來痛恨數學。」   人們會洋洋得意於自己對數學很無知,部分原因是數學不好造成的後果,不像其他缺點這麼明顯。基於這一點,再加上我堅信人對於用具體範例來說明更有反應,對於一般性的描述比較無感。因此,本書會檢視許多真實世界裡的數盲範例,包含股票詐騙、擇偶、報紙專欄上的占卜師、飲食和醫療主張、恐怖主義的風險、占星、運動賽事數據、選舉、性別歧視、幽浮、保險和法律、心理分析、超心理學、樂透以及藥物試驗等等。   我努力避免太自以為是的言論,也不要用哲學家艾倫.布魯姆(Allan Bloom)式的批判,來泛論流行文化或是教育系統,但我還是提出了一些通論式的評論與觀察,但願我舉的例子能支持我的論點。我的看法是,有些人無法游刃有餘地面對數字和機率,是源於對不確定性、巧合或問題呈現方式的自然心理反應。或者是,出於焦慮,或是對數學的本質和意義懷抱不切實際的誤解。   數盲會造成一種罕有人討論的後果:數盲和相信偽科學有關。本書會討論兩者之間的交互關係。在現代這個社會,每天都會出現基因工程、雷射科技、積體電路等新科技,讓我們更進一步理解這個世界。但有很多成人仍相信塔羅牌、通靈和水晶的力量,特別讓人難過。   更不妙的是,科學家對於各種風險的評估,和一般人對於這些風險的認知大不相同,兩者間的落差最後要不就引發沒有根據、但殺傷力極大的焦慮,要不就導致人們要求得到根本做不到、而且會癱瘓經濟的無風險保證。政治人物在這方面幫不上忙,因為他們的工作就是處理公眾的意見,因此不樂於說清楚可能會造成哪些危險,以及有哪些相應的取捨,但這是幾乎所有政策要面對的問題。   本書大部分談的是各種不當,比方說沒有數字觀點、過度重視無意義的巧合、輕信偽科學、無能識別社會中的各項取捨等等,寫來很有破解流言的意味。但我希望我有避開很多人這麼做時,都會露出的過度激昂和譴責語氣。   本書盡量用溫和可讀的方式來談數學,只採用一些基本的機率和統計概念。雖然某種程度上來說有一點深,但只需要具備常識與一些演算能力即可領會。而我也會分享一些概念,是過往很少用淺顯易懂的方式來討論的。我的學生多半很喜歡這些內容,但他們也常會問:「考試時會考這個嗎?」讀這本書不用考試,所以讀者可以好好享受,偶爾一些比較困難的段落,跳過也沒問題。   本書的主張之一,是數盲會基於個人經驗、或因為媒體側重個別性與戲劇性效果,而受到誤導,有強烈的對人不對事傾向。但這句話不代表數學家就不帶個人情感、或是一板一眼,我就不是,這本書也不是。我寫這本書的訴求對象,是受過教育但是數盲的人。或者,至少是對數學還沒有怕到死,不會看到數學兩字就癱軟的人。如果能因此講清楚數盲在我們的公、私生活中有多麼普遍,寫這本書就值得了。

      認真地對照原文看了,沒有發現意思上的問題。雖然試讀文不長,但從經驗看,沒有明顯的誤譯實爲難得。

  2. Mar 2021
    1. we used `backticks` to jump into native Javascript to use moment.js

      In regular Ruby, `` executes in a shell, but obviously there is no shell of that sort in JS, so it makes sense that they could (and should) repurpose that syntax for something that makes sense in context of JS -- like running native JavaScript -- prefect!

  3. Mar 2020
    1. Then there’s markup inside each paragraph, like links and such. You could do it right in the translation strings, but your translator then needs to know how to handle the markup, and you risk duplicating knowledge if you go as far as to hard-code link URLs. What I do is split up the translations, but keep them under the same key: en.yml1 2 3 4 log_in_or_sign_up: text: "%{log_in} or %{sign_up} to do stuff." log_in: "Log in" sign_up: "Sign up" header.erb1 2 3 4 5 <%= t( :'log_in_or_sign_up.text', log_in: link_to(t(:'log_in_or_sign_up.log_in'), login_path), sign_up: link_to(t(:'log_in_or_sign_up.sign_up'), signup_path) ) %> This way, the translator sees no code or markup (except for the i18n interpolation syntax) and there is no duplication.
    1. Translatable strings should be limited to one paragraph; don’t let a single message be longer than ten lines. The reason is that when the translatable string changes, the translator is faced with the task of updating the entire translated string. Maybe only a single word will have changed in the English string, but the translator doesn’t see that (with the current translation tools), therefore she has to proofread the entire message.