依照期貨價格公式來說:
第T期期貨價格的折現值應當是現貨在第T期期望值的折現值,不同的是期貨用無風險利率來折現,在未來現貨則是股利來折現。
所以我們可以得到
這個公式,在 k = r 時,代表現貨的股利報酬等於無風險利率則無系統風險,而在 k > r ,會有正的系統風險。
這也說明在 k > r 下,期貨價格會低於現貨期望值的價格,讓期貨買方能有額外利潤,這額外利潤是因為他承擔「系統風險」所得到的報酬,所以也稱之為「風險補貼 risk premium」。
一般來說,市場多半是處在正系統風險中,所以期貨價格與現貨價格之間通常存在著逆價差的現象,如下圖:
愈遠期的期貨價格愈便宜。
但大家有沒有注意到 9 月與 6 月之間的差額(約 300 點)遠高於 3 月與 6 月,及 9 月與 12 月的差額(約100點)。這是不是代表我們有一套利機會呢? 就是買 9 月合約,並賣出 6 月合約來鎖定約 200 點的價差。
首先,請各位想想,在新興市場中,雖然市場效率通常不佳,但這樣一個簡單明瞭的原理,有學過「期貨與選撫權」的學生都應該知道的,卻沒有人作套利動作而讓價差收斂,這樣的現象一定不單純。
原因就出在「除息」,國內的上市公司多半都是選擇 7 到 9 月之間作除權息的發放,而除權不會扣大盤點數,但除息會。這 200 點的價差,就代表著法人對今年上市公司的現金配息的預估。以目前 7800 的大盤指數來說,今年上市公司的現金殖利率平均約為 2.56 % 。
延伸閱讀: 元大期貨經理 林士農: 除權息與時間差
在 Android 機器上,螢幕的解析度可以用「螢幕大小」和「螢幕點距」兩個參數來表示。
一般的方法
在 Android 1.6 版以後,可以使用 config.screenLayout 語句來判斷螢幕大小
支援的參數與代碼如下Configuration config = new Configuration();
if((config.screenLayout&Configuration.SCREENLAYOUT_SIZE_MASK) == Configuration.SCREENLAYOUT_SIZE_NORMAL){
}
- Configuration.SCREENLAYOUT_SIZE_UNDEFINED 0
- Configuration.SCREENLAYOUT_SIZE_SMALL 1
- Configuration.SCREENLAYOUT_SIZE_NORMAL 2
- Configuration.SCREENLAYOUT_SIZE_LARGE 3
要檢查點距,可以使用 DisplayMetrics 語句來判斷螢幕點距
支援的參數與代碼如下DisplayMetrics dm = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(dm);
if((dm.densityDpi == dm.DENSITY_HIGH)){
}
- DENSITY_HIGH 240 (dpi)
- DENSITY_MEDIUM 160
- DENSITY_LOW 120
- DENSITY_DEFAULT 160
相容 1.5 以下機型
根據Android 版本使用圖表,2010年1月時 Android 1.5 市佔率還是接近 1/3,但是這1/3的機器上並無法使用上面的API。
在 1.5 版上,其實仍然可以用 density 語句來判斷螢幕點距比率
DisplayMetrics dm = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(dm);
if((dm.density >= 1.5)){
}
density 的值 1 代表一般點距,1.5 代表高點距,0.75代表低點距。要偵測市面上所有的機器是否是高解析度機型,只要運用以上方法,就可以自動偵測出螢幕大小和點距囉。
This is an abstract from Scrambled eggs by Martin Aspeli.
藉由 egg 機制,我們可以更順暢地進行模組軟體的包裝與散佈,但是,遇到 buildout 想要自動昇級某些模組時,為了滿足相依衝突時,egg 也可能帶來許多痛苦,我們會被一堆版本昇級要求資訊淹沒。
由於 Plone 3.0 到 3.1 搭配的 Zope 並沒有包裝成 egg 檔案,導致 setuptools 無從得知 Zope 3 模組的 egg metadata 資訊。舉例來說,如果你安裝一個相依於 zope.component 的模組,但是 setuptools 並不知道你已經有 zope.component 了,因此會試著下載最新版的 zope.component。由於新版 zope.component 的下載動作會引發其他相依關係,很容易造成永無止境的昇級要求。
為了解決上述問題,plone.recipe.zope2install 這個 recipe 預設會安裝一些 fake egg,它的效果,就像是建立一堆指到 parts/zope2/lib/python/* 的 egg。如此一來,setuptools 就能知道系統裡存在 zope.component、zope.interface 等標準模組,不需要再去下載新版檔案。
常見的情況是,我們只知道需要安裝某個檔案,但不清楚所需的明確版本,因此 fake egg 會指定為 0.0 版本,除非你為特定的 recipe 額外指定它的版本號碼。也就是說,如果有個模組的相依關係是 zope.component >= 3.1,setuptools 仍然會以為系統既有的 zope.component 版本過舊,將嘗試下載新的版本。
那麼,模組的相依資訊被記錄於何處? 它的來源大致有兩類,一是在模組檔案的 setup.py 內容裡,二是從 buildout.cfg 檔案的 eggs 設定值尋找。相依資訊的常見形式,又可分成兩類,第一類的例子是「我需要和 zope.component 一起工作」,只指定模組名稱,而不指定模組版本,第二類的例子是「我需要和 zope.component >= 3.4 版本一起工作」,同時指定模組名稱與版本條件。
有時,在 setup.py 裡指定最小版本號碼是必要的,因為某些版本以上的模組,才提供我們需要的功能。當然,在 setup.py 裡明確指定「我需要和 zope.component == 3.4 版本工作」是合法的設定方式,但通常會造成日後的災難,而指定最大版本號碼的方式,例如「我需要和 zope.component >=3.4, <=3.4.999 版本工作」,通常也是很糟的形式。一般而言,除非有必要,永遠不要在 setup.py 裡指定「==」的版本要求,頂多使用「<=」的版本形式。因為,這類不適當的設定值一旦出錯,除錯工作極度困難。
另一方面,目前 setuptools 的運作方式,是找尋最新版本來下載,如果它先下載了某個模組的新版本,就會順著它的相依關係來下載其他模組,即使某個舊版本提供更合適的相依條件,setuptools 並無從得知,這會導致下列問題:
* setuptools 下載過新版本的模組,和稍後模組的最大版本條件相衝突。幸好,這個問題並不難解決。
* 原本 buildout 運作正常,但是有人在 PyPI 上傳新版模組,造成相依關係更新,接著你又執行 buildout 更新動作,下載了新版模組,引發更多新版模組的下載。運氣好的話,系統會通知版本衝突的訊息,運氣不好的話,表面上 build 動作完成,但執行系統時卻失敗。
Debian netinstall光碟安裝KDE LXDE XFCE為預設桌面的方法:在開機時,按tab在開機選項後面加上 desktop={kde|lxde|xfce}之後安裝時就自動會安裝 KDE|LXDE|XFce 為預設桌面囉!
想在 Plone 網站加上 quote portlet 嗎? 利用 collective.portlet.quote 輕鬆就能完成,它還有 Quote Folder 專門來放 Quote Type。不過,並不喜歡預設的方框樣版,想要改個樣子,於是動手修改兩個檔案。
修改 randomquote.pt 內容如下:
<dd class="portletItem odd">
<q tal:content="structure view/get_quote">
Body text
</q>
</dd>
<dd class="QuoteSource">
<span class="portletBottomLeft"></span>
<p tal:condition="not:view/has_link">
–
<tal:block replace="view/get_source"/>
</p>
<tal:block condition="view/has_link">
<a tal:attributes="href view/get_link">
–
<tal:block replace="view/get_source"/>
</a>
</tal:block>
<span class="portletBottomRight"></span>
</dd>
新增 ploneCustom.css 內容如下:
.QuoteSource有圖有真相。
{
border-color: #8CACBB;
border-width: 1px;
border-style: none solid none;
margin: 0;
text-align: right;
padding: 0.25em 1em;
}
![]() |
一篇經驗分享文章,分享 Android 上使用 AdMob 廣告營利的經驗與注意事項
2010世界杯,我的Android之旅 蠻不錯的
另一篇移动应用排名与开发者的机会亦有可觀
這篇故事中,人物很多,稍微記錄一下:
並木俊介:主角吧
他老婆:美菜子
他老婆跟前夫的小孩:章太
他情婦:高階英里子
藤間:醫院院長
他老婆:一枝
他兒子:直人
關谷孝史
他老婆:靖子
他兒子:晴樹
坂崎洋太郎
他老婆:君子
他兒子:拓也
津久里:學校老師

Annecy.France
看了點文件,想說就來寫寫東西吧,從最簡單的開始。
= = =
另外,沒想到有人替eblib包了個python wrapper!!
Link: http://code.google.com/p/pyeb/
A rough play, just for fun.
pylons code:
class HelloController(BaseController):
def index(self):
return 'Hello World'
Configuration of prod.ini:
set debug = false
run with:
paster serve prod.ini
node.js code:
http = require('http');
http.createServer(function (req, res) {
res.writeHeader(200, {'Content-Type': 'text/plain'});
res.write('Hello World');
res.close();
}).listen(8000);
sys.puts('Server running at http://0.0.0.0:8000/');
node serv.js
Result of Pylons:
% ab -kc 10 -t 10 http://192.168.7.77:8000/
Benchmarking 192.168.7.77 (be patient)
Completed 5000 requests
Finished 6325 requests
Server Software: PasteWSGIServer/0.5
Server Hostname: 192.168.7.77
Server Port: 8000
Document Path: /
Document Length: 11 bytes
Concurrency Level: 10
Time taken for tests: 10.094 seconds
Complete requests: 6325
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 1341099 bytes
HTML transferred: 69575 bytes
Requests per second: 632.49 [#/sec] (mean)
Time per request: 15.810 [ms] (mean)
Time per request: 1.581 [ms] (mean, across all concurrent requests)
Transfer rate: 130.90 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 84.2 0 2997
Processing: 2 12 22.1 10 644
Waiting: 1 10 22.0 8 640
Total: 2 15 90.4 10 3639
Percentage of the requests served within a certain time (ms)
50% 10
66% 12
75% 12
80% 13
90% 15
95% 17
98% 22
99% 47
100% 3639 (longest request)
Resulf of node.js:
Benchmarking 192.168.7.77 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Finished 50000 requests
Server Software:
Server Hostname: 192.168.7.77
Server Port: 8000
Document Path: /
Document Length: 11 bytes
Concurrency Level: 10
Time taken for tests: 6.185093 seconds
Complete requests: 50000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 3750000 bytes
HTML transferred: 550000 bytes
Requests per second: 8083.95 [#/sec] (mean)
Time per request: 1.237 [ms] (mean)
Time per request: 0.124 [ms] (mean, across all concurrent requests)
Transfer rate: 592.07 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 0 0 3.5 0 81
Waiting: 0 0 3.5 0 80
Total: 0 0 3.5 0 81
Percentage of the requests served within a certain time (ms)
50% 0
66% 1
75% 1
80% 1
90% 1
95% 1
98% 1
99% 2
100% 81 (longest request)



















