<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Some stuff</title>
	<atom:link href="http://blog.yhuang.org/?feed=rss2" rel="self" type="application/rss+xml" />
	<link>https://blog.yhuang.org</link>
	<description>here.</description>
	<lastBuildDate>Wed, 27 Aug 2025 08:50:58 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.1</generator>
		<item>
		<title>entropy of English</title>
		<link>https://blog.yhuang.org/?p=1900</link>
		<comments>https://blog.yhuang.org/?p=1900#comments</comments>
		<pubDate>Sun, 15 Sep 2024 20:26:47 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[bits]]></category>
		<category><![CDATA[English]]></category>
		<category><![CDATA[entropy]]></category>
		<category><![CDATA[LLM]]></category>
		<category><![CDATA[scaling]]></category>
		<category><![CDATA[Shannon]]></category>

		<guid isPermaLink="false">//blog.yhuang.org/?p=1900</guid>
		<description><![CDATA[This video on model scaling highlights an interesting point, which is to use the best models (nowadays LLM&#8217;s) to estimate the entropy rate of the source, in this case, the English language. This isn&#8217;t a new idea at all and empirical entropy measurements have been done in the past. What&#8217;s interesting is that past estimates [...]]]></description>
			<content:encoded><![CDATA[<p>This video on model scaling highlights an interesting point, which is to use the best models (nowadays LLM&#8217;s) to estimate the entropy rate of the source, in this case, the English language. This isn&#8217;t a new idea at all and empirical entropy measurements have been done in the past.</p>
<p><object type="application/x-shockwave-flash" width=560 height=315 data="//www.youtube.com/v/5eqRuVp65eY?start=509"><param name="movie" value="//www.youtube.com/v/5eqRuVp65eY?start=509" /><param name="FlashVars" value="playerMode=embedded" /></object></p>
<p>What&#8217;s interesting is that past estimates of bits per word of English have been way, way higher. Shannon&#8217;s <a href="https://cs.stanford.edu/people/eroberts/courses/soco/projects/1999-00/information-theory/entropy_of_english_9.html#:~:text=One%20possible%20way%20of%20calculating,or%20the%20entropy%20of%20English.">original estimates</a> are <strong>11.82</strong> bits per word, for example, or 2.62 bits per letter.<br />
<span id="more-1900"></span><br />
Some more recent estimates are understandably lower, like referenced in <a href="https://linguistics.stackexchange.com/a/8481/14936">this Stackoverflow answer</a>, which reports <strong>5.7</strong> bits per word. In this video we have the notion that the entropy of English is either undetectably low (which is impossible and suggests model overfit), or quite low, like 1.69 bits <em>per token</em> in <a href="https://arxiv.org/pdf/2203.15556">this DeepMind paper</a>.</p>
<p><img src="wp-content/uploads/images/deepmind_chichilla_entropy.png" width=100% border=0 /></p>
<p>Now, this video plays fast and loose with the units of what&#8217;s reported, so we need to be careful. What&#8217;s a token you say? <a href="https://genai.stackexchange.com/a/35">This Stackoverflow answer</a> says for several models it is &#8220;approximately 4 characters or 3/4 of a word&#8221;. This paper uses a research model called Chinchilla, and doesn&#8217;t say what is a token, but let&#8217;s take it to be the conventional 3/4 of a word. That makes the DeepMind result really <strong>2.25</strong> bits per word.</p>
<p>Then the next plot showing OpenAI&#8217;s GPT-4 performance from their <a href="https://arxiv.org/pdf/2303.08774">Technical Report</a> is even more extreme, showing, so far as I can tell from the graph, between 1.2 and 1.3 bits per word. Let&#8217;s say <strong>1.25</strong> bits per word then. At that entropy rate, each word disambiguates only about 2.4 possibilities on average!</p>
<p><img src="wp-content/uploads/images/openai_gpt4_entropy.png" width=100% border=0 /></p>
<p>That seems very, very low but &#8230; plausible. Perhaps a model of natural language semantic unit (not necessarily a word) tends to distinguish among 2 opposing possibilities, for easy mental processing, you know things like black vs. white, high vs. low, large vs. small. The extra 0.4 possibilities may be grammatical information that attaches as free-rider onto English words. Any lower than 2 possibilities per word seems improbably low and inefficient as a communication mechanism. So if these models are for real, we must be getting very very close to the true lower bound here, and consequently, optimal model performance on English language modeling. It also nicely confirms Shannon&#8217;s thesis (in my attribution) that any source is statistical, and merely by using larger and larger contexts, its generation can be arbitrarily realistic.</p>
]]></content:encoded>
			<wfw:commentRss>https://blog.yhuang.org/?feed=rss2&#038;p=1900</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>hypermiling</title>
		<link>https://blog.yhuang.org/?p=1888</link>
		<comments>https://blog.yhuang.org/?p=1888#comments</comments>
		<pubDate>Fri, 23 Aug 2024 16:03:26 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[car]]></category>
		<category><![CDATA[engine braking]]></category>
		<category><![CDATA[gasoline]]></category>
		<category><![CDATA[hypermiling]]></category>

		<guid isPermaLink="false">//blog.yhuang.org/?p=1888</guid>
		<description><![CDATA[There are many who have asked the question, whether coasting in neutral or engaging engine braking is more fuel efficient in coming to a stop. One such discussion led to the following top comments: Engine braking. It shuts off fuel and lets the cars forwards motion turn the engine. Coasting means you use fuel to [...]]]></description>
			<content:encoded><![CDATA[<p>There are many who have asked the question, whether coasting in neutral or engaging engine braking is more fuel efficient in coming to a stop. One <a href="https://www.reddit.com/r/cars/comments/76jcjg/what_uses_less_gas_coasting_or_engine_braking/">such discussion</a> led to the following top comments:</p>
<blockquote><p>
Engine braking. It shuts off fuel and lets the cars forwards motion turn the engine.<br />
Coasting means you use fuel to keep the engine idling.<br />
Next.
</p></blockquote>
<p>and</p>
<blockquote><p>
That assumes your car has deceleration fuel cut off.<br />
But normally yeah, engine braking would technically use less fuel than idling/coasting.
</p></blockquote>
<p>Now I don&#8217;t know anything about cars but I do have a mental model of a mechanical engine. When no fuel is injected, engine braking <i>should</i> work by having the engine do mechanical work to compress and heat up air (then ejecting it). So RPM matters, as the higher the RPM the higher the energy absorbed per unit time.<br />
<span id="more-1888"></span><br />
Assuming the engine is at idle RPM when coasting in neutral &#8212; that isn&#8217;t always the case, sometimes neutral RPM is lower than the engine braking RPM &#8212; then the energy expended in the engine to do work should be exactly the same whether it is burning gasoline to keep idle or it is being turned by wheels, meaning, the kinetic energy lost when engine braking for <i>n</i> seconds should equal the energy consumed <i>by the engine proper</i> when coasting in neutral for <i>n</i> seconds. We&#8217;ll make one more assumption to idealize &#8212; that heat engines are 100% efficient (they&#8217;re not), but we&#8217;ll get back to this later. With that, we can say that the energy consumed in either case is the same.</p>
<p>Is that it? No. We did not end up in the same state after <i>n</i> seconds: In one case (engine braking) we have a lower speed and less distance traveled than in the other case (coasting in neutral). To properly evaluate which case uses less energy we need to end up in the same state. Now the evaluation becomes choice-dependent.</p>
<p>The typical end state is a complete stop at the same location like at a stoplight. Therefore we&#8217;ll need to match the speed trajectory of these two options. One way to match is to brake when coasting in neutral so that we exactly match the speed trajectory of engine braking, and evaluate energy with a complete stop after <i>n</i> seconds. In that case, clearly more energy has been expended in the case of coasting in neutral, because extra energy is used in friction braking, outside of what happens in the engine. Heat engines being less than 100% efficient makes it worse for coasting in neutral.</p>
<p>But that isn&#8217;t the only fair end state. Another end state is to be at the same speed, without any friction braking. This would be the situation if, for instance, one would engine brake in anticipation of coming to a stop, but while the car would still be moving after <i>n</i> seconds, it became clear that we should cancel the maneuver and recover the original speed. This happens if the stoplight turns green after being red, before the car makes it to the light under either option, so coasting in neutral should maintain the same speed throughout. The distances traveled in the two cases are different, but that&#8217;s okay, we&#8217;ll address that afterwards. It&#8217;s harder to see this but in terms of energy, the choice to engine brake then accelerate back to the original speed at the idle RPM, or coast in neutral at the same speed for the same amount of time, are identical, because you need to input the same amount of energy to recover the kinetic energy lost to engine braking, as it takes to idle the engine with gasoline.</p>
<p>Here&#8217;s the situation in summary: The engine is always running at idle RPM. We use <i>n</i> seconds to reduce speed or coast, then another <i>n</i> seconds to recover speed or coast. When coasting in neutral the car uses idle RPM gasoline for <i>2n</i> seconds to compress and heat air. When engine braking, the car uses no gasoline for <i>n</i> seconds then uses twice the idle RPM gasoline for <i>n</i> seconds to recover speed, one time the idle RPM gasoline to keep the engine running, one more time the idle RPM gasoline to generate extra energy the amount of which was lost during engine braking compressing and heating air at idle RPM. So it&#8217;s exactly the same on both sides of the ledger.</p>
<p>Now finally, does the fact that heat engines do not have 100% efficiency matter here? Perhaps not&#8230; It depends on whether putting in twice the gasoline generates twice the energy at the same RPM. If that&#8217;s true, then even if the engine is not 100% efficient, generating 1x power for 2x the time is the same as generating 2x the power for 1x the time.</p>
<p>But coasting in neutral did cause you to travel farther, so in a flip of the earlier case, it wins slightly. In fact coasting in neutral should always win when there is no friction braking involved, because there is no reduction in speed and so reduces total driving time. If there is no need to slow down, then like intuition says, it&#8217;s most efficient to coast in neutral. The real culprit in the earlier case turns out to be friction braking. It is when the choice is between friction braking vs. engine braking that engine braking is more efficient, because it dissipates the kinetic energy in compressing air only and not in the brakes while also dissipating energy in compressing air.</p>
<p>What about the fact that engine braking typically runs at higher than idle RPM? In the first scenario of coming to a stop, nothing changes. Engine braking still uses no gasoline while friction braking does, so engine braking is more efficient. However, rerunning the second scenario of ending at the original speed, now the amount lost during engine braking compressing and heating air at high RPM is greater than idle RPM expenditure for the same amount of time, e.g. running 2x idle RPM expends 2x the energy of 1x idle RPM in <i>n</i> seconds. That extra 1x idle RPM worth of energy is lost forever and there is no possibility of recovering that vs. coasting in neutral. Coasting in neutral wins even without accounting for farther distance traveled.</p>
<p>All that to say, the best strategy seems to be to modulate engine braking and coasting in neutral to manage the speed trajectory desired. Use engine braking at the lowest possible RPM to slow down, use higher RPM only if it&#8217;s not enough, but if the lowest RPM is still is too much deceleration, go back to coasting in neutral, goal being to avoid any friction braking to manage speed.</p>
]]></content:encoded>
			<wfw:commentRss>https://blog.yhuang.org/?feed=rss2&#038;p=1888</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>once in ten</title>
		<link>https://blog.yhuang.org/?p=1882</link>
		<comments>https://blog.yhuang.org/?p=1882#comments</comments>
		<pubDate>Tue, 30 Apr 2019 09:02:16 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[music]]></category>
		<category><![CDATA[piano]]></category>

		<guid isPermaLink="false">//blog.yhuang.org/?p=1882</guid>
		<description><![CDATA[]]></description>
			<content:encoded><![CDATA[<p><audio controls><source src="wp-content/uploads/fzg-p.mp3" type="audio/mpeg"></audio></p>
]]></content:encoded>
			<wfw:commentRss>https://blog.yhuang.org/?feed=rss2&#038;p=1882</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Windows 10 is still the mess that Windows 8 was</title>
		<link>https://blog.yhuang.org/?p=1816</link>
		<comments>https://blog.yhuang.org/?p=1816#comments</comments>
		<pubDate>Thu, 08 Mar 2018 05:51:57 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[cortana]]></category>
		<category><![CDATA[macOS]]></category>
		<category><![CDATA[windows 10]]></category>
		<category><![CDATA[windows update]]></category>

		<guid isPermaLink="false">http://scripts.mit.edu/~zong/wpress/?p=1816</guid>
		<description><![CDATA[It doesn&#8217;t appear that Windows 10 cleaned up much from Windows 8. After one day of using the former, it is easy to come to the conclusion that Windows 7 is still the last version that anyone should run on its merits. Nobody in their right mind appreciates the mess that is Windows 8/10. (This [...]]]></description>
			<content:encoded><![CDATA[<p>It doesn&#8217;t appear that Windows 10 cleaned up much from Windows 8.</p>
<p>After one day of using the former, it is easy to come to the conclusion that Windows 7 is still the last version that anyone should run on its merits. Nobody in their right mind appreciates the mess that is Windows 8/10. (This is not Microsoft specific either, as Yosemite is also the last version of macOS that seems worth one&#8217;s while. The mobile OS angle has addled the brains of program managers at these companies.)</p>
<p>More egregiously, Windows 10 (Home) is also crippleware. It has disabled a number of features out of the box. No Guest account. No Group Policy Editor*. And hilariously, in what must be an attempt to emulate macOS, it automatically restarts after a system update, but saves no program states, <a href="https://answers.microsoft.com/en-us/windows/forum/windows_10-other_settings-winpc/windows-10-restart-with-update/b7603312-a529-4cf5-ac54-24bf2906b6a6"> with obvious defective results</a>.</p>
<p>* How do I know it&#8217;s crippleware? Because vestiges still remain. You can <a href="https://www.itechtics.com/easily-enable-group-policy-editor-gpedit-msc-in-windows-10-home-edition/">exhume Group Policy Editor</a> from buried .mum files. While you&#8217;re at it <a href="https://www.laptopmag.com/articles/make-windows-10-like-windows-7">turning Windows 10 back into some semblance of Windows 7</a>, wouldn&#8217;t you like to also <a href="https://superuser.com/questions/949569/can-i-completely-disable-cortana-on-windows-10/951895#951895">disable Cortana</a>?</p>
]]></content:encoded>
			<wfw:commentRss>https://blog.yhuang.org/?feed=rss2&#038;p=1816</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>usps insurance rates</title>
		<link>https://blog.yhuang.org/?p=1805</link>
		<comments>https://blog.yhuang.org/?p=1805#comments</comments>
		<pubDate>Mon, 09 Oct 2017 04:04:00 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[arbitrage]]></category>
		<category><![CDATA[express mail]]></category>
		<category><![CDATA[Insurance]]></category>
		<category><![CDATA[usps]]></category>

		<guid isPermaLink="false">http://scripts.mit.edu/~zong/wpress/?p=1805</guid>
		<description><![CDATA[What do USPS insurance rates tell us about its operations? Here is a 2007 document regarding insurance rates for domestic mail: Prices for insurance coverage changed as follows: Value up to $50 is $1.65. $50.01 to $100 is $2.05. $100.01 to $200 is $2.45. $200.01 to $300 is $4.60. The price per additional $100 of [...]]]></description>
			<content:encoded><![CDATA[<p>What do USPS insurance rates tell us about its operations? <a href="https://about.usps.com/postal-bulletin/2007/html/pb22218/kit1_011.html">Here</a> is a 2007 document regarding insurance rates for domestic mail:</p>
<blockquote><p>Prices for insurance coverage changed as follows:<br />
Value up to $50 is $1.65.<br />
$50.01 to $100 is $2.05.<br />
$100.01 to $200 is $2.45.<br />
$200.01 to $300 is $4.60.<br />
The price per additional $100 of insurance, valued over $300 up to $5,000, is $4.60 plus $0.90 per each $100 or fraction thereof.</p></blockquote>
<p>Crudely taking the mid-point of each bracket up to $300, we get implied loss rates of 6.6%, 2.73%, 1.63%, 1.84%, respectively. The rate converges asymptotically to $0.90/$100, or 0.9% implied loss. The numbers have such a wide range that it&#8217;s worth taking a closer look.<br />
<span id="more-1805"></span><br />
On page 1 of this 2011-2012 <a href="https://www.prc.gov/docs/83/83148/USPS-SRT-4%20(N2012-1).pdf">report</a>, it is stated that &#8220;lost mail volume is estimated at 1.79 percent.&#8221; At these 2007 rates (compare gray and orange lines of below figure), paying for insurance is surely uneconomical for anything under ~$100, but has potentially arbitrageable positive expectation for items valued at ~$300 or more. This is surprising.<br />
<img src="wp-content/uploads/images/uspsins07.png" width=600px /></p>
<p>Interestingly, some of these underpricings have been rectified according to this 2017 <a href="https://pe.usps.com/cpim/ftp/manuals/dmm300/Notice123.pdf">document</a>:</p>
<blockquote><p>Amount for Merchandise Insurance Coverage Desired<br />
$0.01 to $50: $2.10<br />
50.01 to 100: 2.65<br />
100.01 to 200: 3.35<br />
200.01 to 300: 4.40<br />
300.01 to 400: 5.55<br />
400.01 to 500: 6.70<br />
500.01 to 600: 9.15<br />
600.01 to 5,000 (maximum liability is $5,000): $9.15 plus $1.25 per $100 or fraction thereof over $600 in declared value.</p></blockquote>
<p>These (again, gray and orange lines of below figure) align much more with actual loss rates; still, there is an asymptotic positive expectation for paying for insurance, and in amounts closer to upper bracket limits. Amounts at the lower bracket limits, though, now hug the actual loss rate line, and that may be a part of the pricing decision after all.<br />
<img src="wp-content/uploads/images/uspsins17.png" width=600px /></p>
<p>What about the high rates on low-value items? That&#8217;s probably the result of an embedded per-incidence fixed cost. We can back this out by assuming $50 is the target insured amount for the $0 to $50 bracket for the purpose of pricing fixed costs. One model is to obtain an implied loss rate at $50 to match the asymptotic rate, i.e. insurance cost at $50 = asymptotic loss rate * $50 + fixed cost <strong>(*)</strong>, though this can be used (as we do later) at any target insured amount.</p>
<p>At 2007 prices, this gives $1.2 per insured item as the fixed cost portion, or $1.2/0.9% = $133.33 per incidence. Similarly, at 2017 prices, this gives $1.475 per insured item or $1.475/1.25% = $118 per incidence. These costs seem plausible. Implied loss rates adjusted for such costs are plotted as the blue lines in previous figures. </p>
<p>The last oddity is that Express Mail insurance rates have built-in insurance up to $100. Let&#8217;s find out how much that is worth. Using the same, older 2007 document that quotes for Express Mail, we have:</p>
<blockquote><p>Prices for Express Mail insurance:<br />
The first $100 of value is still provided. Values above $100 are now priced differently than for regular insurance.<br />
Value over $100 up to $200 is $0.75.<br />
$200.01 to $500 is $2.10.<br />
$500.01 to $5,000 is $2.10 plus $1.35 per each $100 or fraction thereof.</p></blockquote>
<p>The asymptotic loss rate is priced at 1.35% &#8212; interesting that Express Mail should have significantly more implied losses than domestic mail overall. Assuming the same $133.33 per incidence fixed cost as for all domestic mail in 2007, but substituting $100 as the target insured amount into (*), we obtain an insurance cost at $100 of $3.15. So there you go, the &#8220;true&#8221; price table might be:</p>
<blockquote><p>$0-$100: $3.15<br />
$100-$200: $3.90<br />
$200-$500: $5.25<br />
$500-$5000: $5.25 + $1.35 per each additional $100</p></blockquote>
<p>This is rather favorable for insured values just under the $500 mark!</p>
]]></content:encoded>
			<wfw:commentRss>https://blog.yhuang.org/?feed=rss2&#038;p=1805</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>die throwing problem</title>
		<link>https://blog.yhuang.org/?p=1796</link>
		<comments>https://blog.yhuang.org/?p=1796#comments</comments>
		<pubDate>Thu, 14 Sep 2017 03:21:41 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[dice]]></category>
		<category><![CDATA[math]]></category>
		<category><![CDATA[Probability]]></category>
		<category><![CDATA[problem]]></category>

		<guid isPermaLink="false">http://scripts.mit.edu/~zong/wpress/?p=1796</guid>
		<description><![CDATA[Here&#8217;s a link to a subtle probability problem. You throw a die until you get 6. What is the expected number of throws (including the throw giving 6) conditioned on the event that all throws gave even numbers? The &#8220;obvious&#8221; answer is incorrect. The correct answer can be brute-forced by computing probabilities of this sort: [...]]]></description>
			<content:encoded><![CDATA[<p>Here&#8217;s a <a href="https://gilkalai.wordpress.com/2017/09/08/elchanan-mossels-amazing-dice-paradox-answers-to-tyi-30/">link</a> to a subtle probability problem.</p>
<blockquote><p>You throw a die until you get 6. What is the expected number of throws (including the throw giving 6) conditioned on the event that all throws gave even numbers?</p></blockquote>
<p>The &#8220;obvious&#8221; answer is incorrect.<br />
<span id="more-1796"></span><br />
The correct answer can be brute-forced by computing probabilities of this sort:<br />
If \(s\) is a sequence of length \(n\), then<br />
\(P_n\triangleq\) = P(\(s\) ends in 6 and \(s\) all even) = \((2/6)^{n-1} (1/6)\)<br />
(The total probability over all \(n\) is therefore \(Z=(1/6)/(4/6)=1/4\).)<br />
The expected length of \(s\) is \(\sum_{n=1}^\infty n (P_n / Z)\)<br />
\(= \sum_{n=1}^\infty n (2/6)^{n-1} (1/6) / (1/4) = \sum_{n=1}^\infty n (2/6)^{n-1} (2/3) = 3/2\)</p>
<p>This is interesting since premature conditioning on the 3 even sides of a die in every roll produces an (incorrect) expected length of 3.</p>
<p>There is already an elegant and convincing derivation of the correct answer attributed to Paul Cuff if you follow the links from the original article, but here&#8217;s an intuitive explanation for why the <em>incorrect</em> answer overestimates the expected length in such a way &#8211;</p>
<p>Notice that in \(P_n\) the probability \((1/6)\) of obtaining the final 6 has no effect on the expected length. The expected length depends entirely on the shape of \(P_n\) over \(n\). The calculation for the &#8220;incorrect&#8221; reasoning would have made the sum \(\sum_{n=1}^\infty n (2/3)^{n-1} (1/3) = 3\), and the difference is in the \((2/3)^{n-1}\) vs. \((2/6)^{n-1}\) term. So the existence of 1, 3, and 5 matter; they make longer prefixes of 2 and 4 even less likely, as more of the longer sequences that would have been valid ends up containing a 1, 3, or 5 instead and getting thrown away.</p>
<p>Note: There is also a good discussion <a href="https://www.quora.com/What-is-the-expected-number-of-rolls-of-a-fair-six-sided-die-to-get-a-6-given-that-all-rolls-leading-up-to-that-6-are-even-numbered">on Quora</a>.</p>
]]></content:encoded>
			<wfw:commentRss>https://blog.yhuang.org/?feed=rss2&#038;p=1796</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Android Pay and mobile payment</title>
		<link>https://blog.yhuang.org/?p=1772</link>
		<comments>https://blog.yhuang.org/?p=1772#comments</comments>
		<pubDate>Wed, 26 Apr 2017 03:35:13 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[Android Pay]]></category>
		<category><![CDATA[Credit card]]></category>
		<category><![CDATA[LevelUp]]></category>
		<category><![CDATA[mobile payment]]></category>
		<category><![CDATA[Mobile phone]]></category>
		<category><![CDATA[NFC]]></category>
		<category><![CDATA[Samsung Pay]]></category>
		<category><![CDATA[VeriFone]]></category>

		<guid isPermaLink="false">http://scripts.mit.edu/~zong/wpress/?p=1772</guid>
		<description><![CDATA[Where is the NFC antenna? Who the heck knows. I tried to use Android Pay twice today and despite both stores&#8217; VeriFone terminals showing (and processing through the flow as if) they supported it, the success rate was only 50%. Android Pay is NFC-based. The time it succeeded, the phone immediately made contact. The time [...]]]></description>
			<content:encoded><![CDATA[<table align="right" border="0" cellpadding="10" style="margin: 2 2 2 2; border-collapse: collapse; border-style: solid; border-color: #365873;">
<caption align="bottom" style="font-family: sans-serif; font-size:80%;">Where is the NFC antenna?<br />
 Who the heck knows.</caption>
<tr>
<td><img src="wp-content/uploads/images/apple-verifone-6404.jpg" alt="http://pay.band/wp-content/uploads/2015/12/apple-verifone-640.jpg" width=300px border=0 /></td>
</tr>
</table>
<p>I tried to use Android Pay twice today and despite both stores&#8217; VeriFone terminals showing (and processing through the flow as if) they supported it, the success rate was only 50%. Android Pay is NFC-based. The time it succeeded, the phone immediately made contact. The time it failed, there was no semblance of any NFC connection. I know the phone&#8217;s NFC works in other contexts, so it is something in the technology (hardware, software) or workflow itself that makes it so unreliable. That is not even to mention the annoyance of Android Pay&#8217;s particularly patronizing attitude in requiring the phone to be <a href="?p=1748">unrooted</a> and requiring a screenlock (even a perfectly insecure one) to be set. If any of those conditions fail for even five minutes, all the added cards are removed and have to be re-added (some banks require calling in for verification).</p>
<p>My point is nobody is going to use this idiotic piece of technology that makes things harder.</p>
<p>But mobile payment is not new. More than five years ago, a company called <a href="https://www.thelevelup.com/">LevelUp</a> started putting in QR-code based readers around town and having used it, it just works much better.<br />
<span id="more-1772"></span></p>
<table align="left" border="0" cellpadding="10" style="margin: 2 2 2 2; border-collapse: collapse; border-style: solid; border-color: #365873;">
<caption align="bottom" style="font-family: sans-serif; font-size:80%;">This just works. Keep it simple.</caption>
<tr>
<td><img src="wp-content/uploads/images/customer-scan20.jpg" alt="http://developer.thelevelup.com/images/customer-scan.jpg" width=300px border=0 /></td>
</tr>
</table>
<p>Not only was the technology potentially compatible with all devices with a display (that is all phones), it&#8217;s obviously much cheaper to implement. Even the reader hardware is not strictly necessary as the code can be read from another phone&#8217;s camera. In the backend, the charges are aggregated and go to a user-registered card just like any merchant billing. The problem has been practically solved long ago. There was <a href="http://phandroid.com/2016/08/08/cvs-android-pay-nfc-pos-cash-register/">no pressing need</a> to go to an NFC-based solution except for, <em>maybe</em>, accessory devices like watches. Even then&#8230;</p>
<p>In comparison, LevelUp has simply worked every single time without fail, and the app even tells you where you can use it. Their business model is also much more symbiotic with the merchant &#8212; they take a proportion of revenue resulting from repeat visits and promotions made through LevelUp &#8212; rather than middle-manning as a transactional *Pay processor might typically be. It is really incomprehensible to me that LevelUp has not caught on more.</p>
<p>All the while, there is no shortage of other quixotic ideas like <a href="http://blog.onlycoin.com/">Coin</a> and <a href="http://www.samsung.com/us/support/answer/ANS00043865/">Samsung Pay</a> to try to square the circle, in those cases, through magnetic stripe emulation.</p>
]]></content:encoded>
			<wfw:commentRss>https://blog.yhuang.org/?feed=rss2&#038;p=1772</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Passing the Google &#8220;SafetyNet&#8221; test</title>
		<link>https://blog.yhuang.org/?p=1748</link>
		<comments>https://blog.yhuang.org/?p=1748#comments</comments>
		<pubDate>Fri, 16 Dec 2016 04:40:28 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://scripts.mit.edu/~zong/wpress/?p=1748</guid>
		<description><![CDATA[If phone is rooted, follow the below steps: Uninstall Xposed Framework Uninstall Busybox Fully unroot (not only uninstall) Root is required to uninstall the first two.]]></description>
			<content:encoded><![CDATA[<p>If phone is rooted, follow the below steps:</p>
<ol>
<li>Uninstall Xposed Framework</li>
<li>Uninstall Busybox</li>
<li>Fully unroot (not only uninstall)</li>
</ol>
<p>Root is required to uninstall the first two.</p>
]]></content:encoded>
			<wfw:commentRss>https://blog.yhuang.org/?feed=rss2&#038;p=1748</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>valuation of miles and points</title>
		<link>https://blog.yhuang.org/?p=1737</link>
		<comments>https://blog.yhuang.org/?p=1737#comments</comments>
		<pubDate>Thu, 13 Oct 2016 03:42:11 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[airfare]]></category>
		<category><![CDATA[illiquidity]]></category>
		<category><![CDATA[mileage]]></category>
		<category><![CDATA[points]]></category>
		<category><![CDATA[pricing]]></category>
		<category><![CDATA[travel agency]]></category>
		<category><![CDATA[valuation]]></category>

		<guid isPermaLink="false">http://scripts.mit.edu/~zong/wpress/?p=1737</guid>
		<description><![CDATA[As with any currency, the true value of various miles and points is determined by their trade value on a unified, liquid, and open market. Unfortunately such a market does not exist publicly &#8212; there is an underground secondary market with sometimes stale prices, minimum trade requirements, and counterparty risks, but generally speaking there is [...]]]></description>
			<content:encoded><![CDATA[<p>As with any currency, the true value of various miles and points is determined by their trade value on a unified, liquid, and open market. Unfortunately such a market does not exist publicly &#8212; there is an underground secondary market with sometimes stale prices, minimum trade requirements, and counterparty risks, but generally speaking there is no notion of transparent prices. So you often see &#8220;Mileage Blogger&#8221; sites like <a href="http://thepointsguy.com/category/series/mile-and-point-value-series/">this</a> bandying about valuations pulled out of thin air. There should be a much more principled way to determine valuation that helps to make transaction decisions easier.<br />
<span id="more-1737"></span><br />
First, let us assume that redeeming for the primary intended product is liquid for the holder, e.g. if we&#8217;re talking about miles then suppose we do indeed travel a lot; otherwise all sorts of discounts due to time value of money, depreciation, and illiquidity would have to be taken into account. Let us focus on the market of airfare. Let us suppose there is a suitable notion of substitutable fares (e.g. a fairly reasonable one might be: If two flights have the same starting and ending locations, the same number of stops, and are within one hour in total duration, starting, and ending time, then they are substitutable.).</p>
<p>Then suppose Airline A has a fare of $380, which may also be bought with 15800 Airline A points and $5.60 in fees, while Airline B has a substitutable fare of $250, which may be bought with 12500 Airline B points and $20 in fees, and Airline C has a substitutable fare of $227, and these form the entire set of substitutable fares. A naïve so-called &#8220;Mileage Blogger&#8221; may say that</p>
<ul>
<li>Airline A points are worth $380/15800 = 2.41 ¢/pt while</li>
<li>Airline B points are worth $250/12500 = 2.00 ¢/pt.</li>
</ul>
<p>A slightly more astute but no less naïve so-called &#8220;Mileage Blogger&#8221; may say that</p>
<ul>
<li>Airline A points are worth ($380-$5.60)/15800 = 2.37 ¢/pt while</li>
<li>Airline B points are worth ($250-$20)/12500 = 1.84 ¢/pt.</li>
</ul>
<p>But really, the valuation of Airline A points is ($227 &#8211; $5.60)/15800 = 1.40 ¢/pt while the valuation of Airline B points is ($227 &#8211; $20)/12500 = 1.66 ¢/pt. Note here we take the <strong>minimum</strong> of the set of substitutable fares, regardless of which airline it is from, and deduct the point redemption fees to obtain cash value. </p>
<p>This equally applies to the much beloved high-value redemptions for First Class international fare, where claimed valuations of 3 ¢/pt, 5 ¢/pt, and other outrageous numbers are seen. Are these valuations real? Well no. First of all there is often no two-sided market for these fares, as there is either no demand for the cash prices, or there is no supply for the point redemption. It is indicative of a much lower than claimed valuation from simple &#8220;award chart&#8221; calculations. In this case, the lower substitutable fare is often in the travel agency market. The valuation can also be bounded from prices in underground secondary markets, where eventual high value redemptions are the norm. Cash prices for a variety of points range between 1.4 ¢/pt to 1.6 ¢/pt, rarely going much higher. (Some points are inherently doubled of halved in nominal value, adjust accordingly.) Even taking into account the spread by the scalper (ahem, agent), these are likely closer to the upper bound than fanciful imaginations.</p>
<p>If we had actual airfare sales volume data, it would be easy to aggregate all fares into equivalence classes by substitutability, calculate valuations, and apply weighting according to volume. This would give a trade weighted currency value. Without this, one could conduct a survey into the type of &#8220;trades&#8221; that would make up one&#8217;s &#8220;basket&#8221; in any given year and figure out the personal value of all the points out there. After all, the paper value of a trade that would never occur &#8212; viz. a fare that one would or could never obtain &#8212; is completely meaningless.</p>
]]></content:encoded>
			<wfw:commentRss>https://blog.yhuang.org/?feed=rss2&#038;p=1737</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Built-in audio variations</title>
		<link>https://blog.yhuang.org/?p=1733</link>
		<comments>https://blog.yhuang.org/?p=1733#comments</comments>
		<pubDate>Sun, 11 Sep 2016 04:37:16 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[3.5mm]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[Headphones]]></category>
		<category><![CDATA[HP]]></category>
		<category><![CDATA[IDT]]></category>
		<category><![CDATA[Laptop]]></category>
		<category><![CDATA[Macbook]]></category>

		<guid isPermaLink="false">http://scripts.mit.edu/~zong/wpress/?p=1733</guid>
		<description><![CDATA[In light of Apple&#8217;s removal of the 3.5mm jack (for which there is an excellent analysis), I must say that there is something to be said for the inconsistency of analog audio output from built-in audio devices in laptops. Apparently there is quite a bit of variation that I hadn&#8217;t realized. I ran this test [...]]]></description>
			<content:encoded><![CDATA[<p>In light of Apple&#8217;s removal of the 3.5mm jack (for which there is an <a href="http://www.slate.com/articles/technology/future_tense/2016/09/apple_s_airpods_aren_t_just_wireless_earbuds_they_re_the_future_of_computing.html">excellent analysis</a>), I must say that there is something to be said for the inconsistency of analog audio output from built-in audio devices in laptops. Apparently there is quite a bit of variation that I hadn&#8217;t realized.</p>
<p>I ran <a href="http://www.audiocheck.net/soundtests_headphones.php">this test</a> using two sets of fairly wideband headphones and got results that were consistent across headphones but different between an HP laptop and a MacBook. The headphones were rated, respectively: (1) 15 &#8211; 20,000 Hz, 47 Ω input impedance; and (2) 15 &#8211; 24,000 Hz, 35 Ω input impedance. On the HP laptop with <a href="https://www.reddit.com/r/audiophile/comments/2s9b2h/pandora_one_and_a_dac_amplifier/">&#8220;IDT High Definition Audio&#8221; (92HD93 chip)</a>, I could hear a range from 30 Hz to 18 kHz. On the MacBook Pro with <a href="http://apple.stackexchange.com/questions/57186/what-is-the-impedance-of-the-line-headphone-jack-on-macbook-pro-retina">mid-2014 hardware</a>, I could hear a range from 20 Hz to 16 kHz. I was quite surprised at the magnitude of this difference. A headphone amplifier (e.g. one built into the headphones) driven by digital input would eliminate this difference.</p>
]]></content:encoded>
			<wfw:commentRss>https://blog.yhuang.org/?feed=rss2&#038;p=1733</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
