其他

1.將字元型資料轉換成日期型：（用stata的內建help datetime可查具體操作） 例如將字元型2010-01-05 14:04:31.890 (variant1)轉換成數值型的05Jan2010: gen double eventtime=clock(variant,"YMDhms") gen eventdate=dofc(eventtime) format eventdate=%td 2.提取字元型日期的資料：2010-01-05 14:04:31.890

一、變數批量重新命名：     比如將一批變數的 a_2  b_2  c_2 d_2 e_2的尾碼改為w    ren (*_2) (*w) 二、檢查重複資料常用命令：    duplicates report x         //報告x變數有無重複   duplicates

Keras提供眾多常見的已編寫好的層對象，例如常見的卷積層、池化層等，我們可以直接通過以下代碼調用： # 調用一個Conv2D層from keras import layersconv2D = keras.layers.convolutional.Conv2D(filters,\kernel_size, \strides=(1, 1), \padding='valid', \...) 但是在實際應用中，我們經常需要自己構建一些層對象，已滿足某些自訂網路的特殊需求。

       R語言中，常見的圖有長條圖、盒狀圖、橫條圖、點陣圖、餅圖、QQ圖。 1.長條圖          長條圖是直觀瞭解資料分布的常用圖形，它將連續型資料分為等間距的組，並以矩形的高低來顯示相應組中所含資料的頻數或頻率大小，有時可以顯示資料的密度曲線作為輔助。這是一種簡單快捷的探索資料分布的方式。 2.盒狀圖          

二維餅圖 代碼如下： #繪製2維餅圖x=read.delim("C:/Users/a/Desktop/sample.txt",header=FALSE) #讀入文本資料names(x)=c("word","count") #加表頭x=transform(x, pct=round(x$count/sum(x$count)*100)) #資料框增加百分比列y=x[order(x[,2],decreasing=T),]#排序z=head(y,n=1

bias, variance and Model Complexity 預測值與真實值得算是函數一般用兩種： 檢驗誤差或者泛化誤差，是在獨立的預測樣本上的預測誤差： 對於模型的評估和選擇有兩個目標： 模型評估：比較多個模型的performance從中選取最優 模型評價：估計它在測試集合的泛化誤差 資料集一般劃分為：訓練集，驗證集，檢驗集 bias variance decomposition 對於k-neareast 有一下簡要形式：

參考書目: 《R的極客理想——工具篇 》 xts介紹 xts是對時間序列資料(zoo)的一種擴充實現，目標是為了統一時間序列的操作介面。實際上，xts類型繼承了zoo類型，豐富了時間序列資料處理的函數，API定義更貼近使用者，更實用. xts資料結構 xts擴充zoo的基礎結構，由3部分組成，如圖2-7所示。 索引部分：時間類型向量。 資料部分：以矩陣為基礎類型，支援可以與矩陣相互轉換的任何類型。 屬性部分：附件資訊，包括時區和索引時間類型的格式等。 xtsAPI介紹

1、在CentOS7中安裝最新版本的Chrome瀏覽器 yum installhttps://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm 完成後在Applications中的Internet中可以找到Google瀏覽器 2、chromedriver的下載 下載

library(xlsx) myield<-read.xlsx("myield.xlsx",header=T,sheetIndex=1) head(myield)     time     X3m     X6m     X1y     X2y     X3y

1） par()函數的使用 par(mfcol=c(2,3)) 是將介面分為2*3 個繪圖區域即是 2行3列 而 mfcol 中的col是按照列優先的順序進行填充。 那麼mfrow就是以行優先的順序進行映像填充。 以下是測試的代碼集合圖片

由於將會要組織一個全新的研發團隊，而且可能團隊中講會以年輕人為主，應屆畢業生尤其巨多。   我覺得這是一個嘗試全新的開發模式的好時機，但是當然需要平穩過渡。首先，我們都沒有敏捷開發的經驗，其次，敏捷開發所有的概念也未必完全適合團隊，需要動態來尋找結合點。   1. 簡單設計及重構 首先需要較為嚴格的確立工程的概念，我比較欣賞“簡單設計”這個原則，但是不完全贊同。  

最近一直專註於忙研發管理，談一點小體會吧。 1. 要將壓力下發到小組成員，同時要敢於放權 2. 壓力下發的同時必須界定每個人的責任範圍 3. 邊界交界處必須指定牽頭人，避免互相推諉的情況 4. 必須學會批評，且要嚴厲 5. 文檔一定要時刻與開發同步，否則將導致項目失敗。產品化進程中的重點 6. 越早參與評審，越能對品質把控得好。 7. 管理者必須敢於邁出關鍵步伐，推進項目進程 8. 必須制定研發計劃，計劃必須嚴格的執行（說的容易做的難） 9.

在使用開原始碼的時候，也需要注意其對應的開源協議，特別是在商業級應用中。下面就我個人針對各個常見的開源協議做個簡單的匯總和理解。   假設我們使用的開原始碼為 A，我們自己開發的為 B，其中使用到了A   BSD協議 1。若B開源，B中帶有A的代碼，則B在發布時必須帶有A的BSD協議聲明。 2。若B閉源，B中帶有A的代碼，則B在發布時必須在文檔/著作權聲明中帶有A的BSD協議聲明。 3。不允許用A的作者或者任何其他資訊作為B的市場推廣。 總結：

1. 對於很抽象的底層性項目，測試應該由研發引導測試人員。（特別應該是架構設計師驅動），如果嘗試讓測試徹底理解項目，可能會消耗更多時間且效果不理想。甚至可以由研發人員定用例，測試人員完成實際的測試指令碼編寫和測試實施。   2. 資料驅動的項目，可以在產品介面需求定製之前開始研發DAO層。而純功能性驅動的項目，可以先開發產品原型。   3.

寫了一堆代碼發現有點問題，又怕刪了以後要找很麻煩。。 我們的辦法一般都是先將它注釋掉，等確定不需要有時再將它徹底DELETE。   但是經常會碰到需刪的代碼裡有注釋資訊的情況。。   那麼就不能注釋了。   以前總是束手無策，今天看到個好方法。就是用條件編譯將它KO掉：   比如    #ifdef deleted   .....   #endif &

ffmpeg/avconv 廣電用mpeg2相關轉碼參數 avconv -i source.ts -r 25 -aspect 4:3 -s 720*576 -muxrate 3800k -c:v mpeg2video -flags ildct+ilme -top 0 -b:v 3500k -minrate:v 3500k -maxrate:v 3500k -bufsize 1000k -streamid 0:512 -c:a mp2 -b:a 192k -streamid 1:5

silverlight的MediaElement可以做到幀精確播放，但是在不同瀏覽器、不同視頻格式封裝格式下有較大差別。（甚至有很多BUG，特別是downloadprogress這個函數） 經過反覆實驗，發現一種方法，可以實現progressive download並且幀精確的定位，並且經過簡單的測試，在IE和chrome下都準系統正常。 使用h.264+AAC編碼，mp4封裝。moov放在視頻頭部，faststart模式 附ffmpeg轉碼參數:

目前ffmpeg針對超大型視頻編碼，可以實現多thread，但無法分享多個電腦資源。 主要痛點在於無法將計算拆分到各個機器，並高效的處理編碼。由於視頻資料存在前後連續性，並且不同的編碼格式，對於線程層級的任務拆分各有不同。 其實應該可以在視頻層級進行拆分、編碼和合并，其實現思想無外乎map/reduce 比如對於MPEG2格式的視頻，我們能將原視頻斷在closedgop處，同時分離音頻，將音頻斷在某音頻包處。這樣可以實現map的功能。

電腦CPU體系架構的設計RISC最終戰勝了CISC，產生如今PC機的主流。   軟體架構設計也一樣，在完成同樣事情的情況下，力爭越簡單。   今天晚上和原公司首席科學家及老總促膝長談到2點鐘才回家， 將我自認為比較滿意簡潔的設計砍得七零八落，最終得出一個極為精簡優雅的架構， 得出設計理念收穫如下：   1. 流水作業級調度基於檔案系統/共用檔案系統最為簡單，可移植度也最高（語言/平台）； 2.

1. 基本模型盡量符合通用（不一定是簡單）的原則，這樣才能建築起強大的上層建築。如果基於該模型構建上層建築過程很複雜，考慮設計中介層。   所以在設計底層的時候應該是想一個盡量簡單的規則，能夠衍生出各種複雜的上層。就像數學裡，公理盡量簡單明了，可以嚴謹的用於論證複雜的上層情況，如果上層應用很複雜，再歸納出定理。   2. 在訪問臨界區不是特別頻繁的情況下，進程間互斥鎖可以只用規範一個命名。   使用一個鎖來鎖住整個臨界區，實現上很簡單。