The mind-boggling warp and transwarp speeds were not very accurate in ST series. It is believed that, when the warp factor w is between 0 and 9, the actual speed can be expressed as s=c*w^(10/3), where c is the speed of light. So at warp 9, a space shuttle can achieve the speed of 1516c, 1516 times as fast as light.
When we'd ever enter warp 9 and warp 10 (if warp 10 exists at all), we will see some vague speeds. The following equation,
s = 1663 * 1.1583 ^ ((- log(10-w) ) ^ (pi/2)),
works relatively well with the warp speeds ever appeared in ST as summarized by this page. Or maybe the warp speeds have been computed at random.
Nobody knows about transwarp. Maybe Q or his son.
While not trying to play down the significance of the long hitting streaks, we can use stochastic process to explain some of these numbers.
For simplicity, let us assume every player has a hitting percentage of 250 or 0.25. Each player hits 3 times in each game. There are 180 games each year and there are 30 teams with 9 regular players. We further assume that the outcome of each batting chance is decided randomly based the hitting percentage and independently, i.i.d..
The chance of a player getting at least a hit in a game is
1 - (1-0.25)^3
The chance of no one player gets into a hitting streak of N games is
P0 = (1-(1-0.25)^3)^(30*9)
where 30*9 represents the total number of hitting record (players).
The chance of having a streak of N game hitting is then 1 minus the above result. And on an average, it takes the following number of years to find such a streak
1/ (1-P0) / 180
where we have assumed 180 games each year.
The following figure shows the number of years it takes to have certain hitting streak, for different hitting percentage:
From this figure, we can see that the hitting streak of 30 should appear quite often. Again, this does not mean that the player getting this streak isn't a great player. The mathematical point of view is that, with so many games played, some streaks are bound to appear.
The real computation should be much more complex because players have different hitting percentage and they react differently when they enter a streak.
If you are like me, you like gmail but not much of mouse-clicking. Keyboard is generally considered 1,000 times faster than mouse (although there are some tasks that have to be performed with mouse, or for general public). That calls for terminal-based email client and the candidates are limited these days. Alpine (or pine) is one of them. Others include sup, Mutt.
So using Alpine to retrieve email from gmail server and read/manage your email locally is not difficult. You just need to set the server to something like "smtp.gmail.com:587/tls/novalidate-cert/user=YOURUSERNAME" for INBOX.
Alpine works fine with a few glitches, not being able to search full text in multiple email among one of them. (Update 07/20/2020, this turned out to be false. A simple ';ta' key sequence will do it, based on this post.) One other headache is its complaint of message size change after retrieving email body from gmail servers. The message of "Message to save shrank! (msg # 1): Continue anyway ?" will be shown to you and even if you respond "Always (ignore)" you will be asked the same question again and again.
After searching Internet for a possible solution for quite some time, I could not find any solution except recompiling from source code. I couldn't recompile because of some other issues. So gdb came to the rescue.
The trick is to edit the binary file itself by skipping the call function. Open the alpine binary file in Emacs (hexl-mode, move to the right column, then Ctrl-Alt-x or Ctrl-Meta-x to insert in hex mode) or any other hex editor. Search for ' e8e3 6803 00' and replace it with ' b861 0000 00'. Save the file into a new name. The prompt will be gone.
While in the hexl-mode, go to line 582E0 and change byte location 582E2:582E6 into "B8:01:00:00:00". This is the machine code of "mov eax, 1" to automatically respond yes to the nasty question of "Preserve password for next login".
Alpine Version 2.00 (built Sun Sep 28 00:59:01 EDT 2008) running on Mac OS X, 10.6.8 Intel-based Mac Book Air 2010, and later macOS Sierra Version 10.12.5 2.2 GHz Intel Core i7 (Mac Book Air 2015).
(Update 12/20/2018) Gdb seems not working anymore, but lldb does. The way to look for this hex string in the binary file is to use lldb in Mac OS X. Run 'lldb alpine' then set a breakpoint with 'breakpoint set -n preserve_prompt'. With 'run' and hopefully it will ask you to type your password for the million-th time, the program will stop. Use 'di' to de-assemble the code and 'x 0x0593a0' to show the segment of memory. Somewhere there is a line like this 'call 0xa15c0 ; want_to' and it should be replaced with 'movl 0x79, eax' (returning with 'y'). The hex code for it is 'B8 79 00 00 00'. The string to search for is 'e8 9282 0400' and it should be replaced as 'b8 7900 0000'
(Update 07/07/2019) The latest alpine 2.21 solved the problem by introducing an option of "Ignore Size Change" that can be turned on. Great!
Happy "alpine" emailing!
Anecdotal evidences show that Google's ChromeCast, the hot gadget that plays online video with smartphone control, may do crazy things to (or ruin) your older HDTV due to unknown reasons. A TOSHIBA 40" HDTV went black after a couple weeks of being used in combination with ChromeCast. It could be the extra current draw (although the device was given USB-based power) or incompatible issue between ChromeCast and the older HDMI input port.
The three-year-old TOSHIBA HDTV had no issues before. And a couple weeks after yanking away ChromeCast, it seemed the TV came back normal again.
(Noted September 2013) Just wanted to put it out here to see whether anyone else experienced similar issues.