library gplots中有一个很实用的热图工具,就是heatmap.2
提交的数据为矩阵,行列name可作为聚类后的标签
其中有很实用的参数
1.  行、列聚类树状图,热图,以及colorkey的位置排布
    可以用参数lmat,其中1代表热图,2代表行聚类树状图,3代表列聚类树状图,4代表colorkey,0代表空
    默认情况下lmat=rbind(c(4,3),c(2,1))  ,即colorkey在左上角
    根据lmat,画布被分为两行、两列,相应的你可以设置每行每列的宽和高,这就是参数lwid以及lhei。所以lwid向量的长度要与lmat中列的数目相等,lhei向量的长度要与lmat中行的数目相等
   例如 你 想把colorkey放在图的下方,可设置 lmat=rbind(c(0,3),c(2,1),c(0,4)) ,lhei=c(1,4,2),lwid=c(1,2) 。其中的长和宽其实就是代 表画布上你分配给各部分的量,例如此处lhei=c(1,4,2),则大约整个画布高度的1/7给第一行,4/7给第二行,2/7 给第三行  
2.  行、列标签字体大小
    可以使用参数cexCol、cexRow设置
  颜色设置使用col
    可以自己定义颜色向量,颜色代码可参考http://canghai2381.blog.163.com/blog/static/3400332420082192317234/ 
    相应的可以用breaks参数界定颜色分割的阈值
colorkey的显示
   key=FALSE可不显示colorkey,而density.info可以确定要不要在colorkey上显示直方图 
行、列标签的分类颜色
   RowSideColors、 ColSideColors参数可以为每一行/列定义对应分类的颜色,使用该颜色标记每一行或者列数据所属的类型
   例如有六列数据,分为两种类型,分别用红绿标记 ColSideColors=c(‘green’,’green’,’green’,’red’,’red’,’red’)
6 聚类图颜色范围
  做聚类图颜色很重要,一般采用greenred或者redgreen,但是有时可能需要其他渐变的颜色,就可以使用colorRampPalette参数,例如想要绿白蓝渐变,就可以设置col=colorRampPalette(c(“green”,”white”,”red”))
7 颜色分割点
  你设置的颜色可以选择是不是以0为对称,如果想对称,就可以令symkey=TRUE
  另外,就是你可能需要设置某一数值范围为一个颜色,这就可以使用breaks参数,例如你的颜色有八种
          定义函数colorsChoice<- colorRampPalette(c(“green”,”white”,”red”))
          产生8个渐变col=colorsChoice(8)
          8种颜色对应的数值区间breaks=c(-3,-2,-1,0,1,2,3,4,5)

#画带行列分类color的heatmap
library(gplots)
library(RColorBrewer)
mydata<-center.exp
hclustfunc <- function(x) hclust(x, method=”complete”)
distfunc <- function(x) dist(x, method=”euclidean”)

# perform clustering on rows and columns
cl.row <- hclustfunc(distfunc(mydata))
cl.col <- hclustfunc(distfunc(t(mydata)))

# extract cluster assignments; i.e. k=8 (rows) k=5 (columns)
gr.row <- cutree(cl.row, k=8)
gr.col <- cutree(cl.col, k=5)
# require(RColorBrewer)
col1 <- brewer.pal(8, “Set1”)
col2 <- brewer.pal(5, “Pastel1”)

# require(gplots)   
heatmap.2(as.matrix(mydata), hclustfun=hclustfunc, distfun=distfunc,  
         RowSideColors=col1[gr.row], ColSideColors=col2[gr.col])
        

#extract cluster based on dist
gr.row <- cutree(cl.row,h=2 )
gr.col <- cutree(cl.col, h=2)

# require(RColorBrewer)
col1 <- colorRampPalette(brewer.pal(0, “Set1”))(length(unique(gr.row)))
col2 <- colorRampPalette(brewer.pal(5, “Pastel1”))(length(unique(gr.col)))

# require(gplots)   
heatmap.2(as.matrix(mydata), hclustfun=hclustfunc, distfun=distfunc,  
         RowSideColors= col1[gr.row] , trace=”none”,col=greenred,Colv=FALSE)

问题:

使用ionic 2框架开发的app,在使用geolocation插件时,弹出了would like to use your current location的提示。

解决方法:

Geolocation.getCurrentPosition().
then((result: Geoposition) => {
    this.geoPosition = result;
}).
catch((error: any) => {
    console.error(error);
});

Geolocation.watchPosition().
subscribe((result: Geoposition) => {
    this.geoPosition = result;
});
初始化添加到
platform.ready().then(()=> {
});
里。
即,必须要在platform的ready之后。

You probably already know about HTML5‘s <input type="number">. Which if supported by a browser displays a form input optimized for inputting numbers. Whether that means an up/down spinner or an optimized keyboard.

However iOS’ standard behavior for the number input isn’t that ideal. By default iOS will display a standard keyboard slightly modified with a row of numbers at the  top. This isn’t ideal as you don’t need the alphabetic keys and iOS already has a full numeric keypad it could use for the input instead. For reference, other mobile OS such as Android already display their numeric keypad when focusing a number input.

A html5doctor article article went over this, pointed out a trick by Chris Coyier using <input type="text" pattern="[0-9]*"> in which the pattern forces iOS to use it’s numeric keypad, and also mentioned HTML5’s inputmode.

The unfortunate issue with Chris’ technique as-is is the number input is no longer a number input. And the practice of depending on raw string matches to specific regexps in pattern="" to trigger UI changes is non-standard. So while the trick nicely displays a numeric keypad on iOS the input no longer has the spinner interface on desktop browsers and other mobile devices such as Android no longer use their numeric keyboards.

Wondering if this technique could be applied in a meaningful way to a number input without ruining the experience for users with other devices I started experimenting and came up with another technique.

<input type="number" min="0" inputmode="numeric" pattern="[0-9]*" 
title="Non-negative integral number">

I found out that the technique of adding pattern="[0-9]*" to an input to trigger the keypad in iOS works even when the input is type="number" so both type="number" and pattern are used. inputmode="numeric" was added for forward compatibility as unlike pattern="[0-9]*" is is the standard way to declare that a numeric mode of user input should be used for a form field.

I also realized that the use of pattern triggers the browser’s native form validation. Which in the case of browsers – like Firefox – which have implemented form validation but not type="number" results in the browser displaying a cryptic “Please match the requested format.” message when the user attempts to submit the form and the number input contains some non-numeric characters. So a title was added which is the standard way to note what type of input is expected within the form field and causes that text to be used inside the error message to describe what the format is.

pattern is ignored by most browsers that implement type="number" but is used by browsers that implement form validation but not the number input type such as Firefox. The pattern [0-9]* which is the only one that iOS will accept to trigger the keypad only permits the input of non-negative integral numbers. So I added min="0" to force browsers implementing type="number" from accepting negative numbers which other browsers would reject.

This technique works in all browsers; Displaying numeric keypads on iOS as well as Android and any other mobile device that’s implemented type="number" or inputmode="numeric" handling. Displaying the numeric spinner on browsers where it’s implemented such as Chrome and Opera. And displaying user friendly form validation on browsers like Firefox that have validation but no number input.

If you have an iOS device you can try out the demo which is depicted by figure 1 and figure 2.

This technique technically does not validate. As the spec defines inputmode and pattern as attributes on textual inputs but not on type="number". However the semantic meaning of these attributes is known and matches the semantic meaning of type="number". So while it is technically invalid the technique is safe to use and the better user experience is worth any error messages in a validator.

         

 

link: http://danielfriesen.name/blog/2013/09/19/input-type-number-and-ios-numeric-keypad/