Author: hev

前面我们提到了图像的缩放变换和旋转变换，可以用矩阵乘法的形式来表达变换后的像素位置映射关系。

那么，对于平移变换呢？平移变换表示的是位置变化的概念。如下图所示，一个图像矩形从中心点[x1,y1]平移到了中心点[x2,y2]处，整体大小和角度都没有变化。在x方向和y方向上分别平移了tx和ty大小。

显然：

   

这对于图像中的每一个点都是成立的。写成矩阵的形式就是：

   

我们再把前面的缩放变换和旋转变换的矩阵形式写出来：
缩放变换：

   

旋转变换：

   

我们注意到，缩放变换和旋转变换都可以表示成矩阵乘法的形式。实际上，图像的几何变换通常不是单一的，也就是说经常性的缩放、旋转、平移一起变换。例如先放大2倍，然后旋转45度，然后再缩小0.5倍。那么就可以表示成矩阵乘法串接的形式：

   

这样，不管有多少次变换，都可以用矩阵乘法来实现。但是平移变换呢？从前面看到，平移变换并不是矩阵乘法的形式，而是矩阵加法的形式！

那能不能把缩放变换、旋转变换、平移变换统一成矩阵乘法的形式呢，这样不管进行多少次变换，都可以表示成矩阵连乘的形式，将极大的方便计算和降低运算量。

这种方法就是“升维”，引入“齐次坐标”，将图像从平面2D坐标变成3D坐标。我们看看平移变换的矩阵形式：

   

将其升维，变成3维，上式就可以表示成：

   

这是个非常优美的地方，学习过矩阵乘法的同学可以算一下右边的式子，是否最终结果与前面是一样的。

这样，平移变换通过升维后的齐次坐标，也变成了矩阵乘法的形式。当然缩放变换和旋转变换的矩阵形式也得改一改，统一变成3维的形式。
缩放变换：

   

旋转变换：

   

终于统一了。以后所有的变换，不管怎样变换，变换多少次，都可以表示成一连串的矩阵相乘了，这是多么的方便。这就是引入齐次坐标的作用，把各种变换都统一了起来。

From：https://blog.csdn.net/saltriver/article/details/79680364

Over!

A very non-intuitive property of the Alpha processor is that it allows the following behavior:

Initially: p = & x, x = 1, y = 0

    Thread 1         Thread 2
--------------------------------
  y = 1         |    
  memoryBarrier |    i = *p
  p = & y       |
--------------------------------
Can result in: i = 0

This behavior means that the reader needs to perform a memory barrier in lazy initialization idioms (e.g., Double-checked locking) and creates issues for synchronization-free immutable objects (e.g., ensuring. that other threads see the correct value for fields of a String object).

Kourosh Gharachorloo wrote a note explaining how it can actually happen on an Alpha multiprocessor:
The anomalous behavior is currently only possible on a 21264-based system. And obviously you have to be using one of our multiprocessor servers. Finally, the chances that you actually see it are very low, yet it is possible.

Here is what has to happen for this behavior to show up. Assume T1 runs on P1 and T2 on P2. P2 has to be caching location y with value 0. P1 does y=1 which causes an “invalidate y” to be sent to P2. This invalidate goes into the incoming “probe queue” of P2; as you will see, the problem arises because this invalidate could theoretically sit in the probe queue without doing an MB on P2. The invalidate is acknowledged right away at this point (i.e., you don’t wait for it to actually invalidate the copy in P2’s cache before sending the acknowledgment). Therefore, P1 can go through its MB. And it proceeds to do the write to p. Now P2 proceeds to read p. The reply for read p is allowed to bypass the probe queue on P2 on its incoming path (this allows replies/data to get back to the 21264 quickly without needing to wait for previous incoming probes to be serviced). Now, P2 can derefence P to read the old value of y that is sitting in its cache (the inval y in P2’s probe queue is still sitting there).

How does an MB on P2 fix this? The 21264 flushes its incoming probe queue (i.e., services any pending messages in there) at every MB. Hence, after the read of P, you do an MB which pulls in the inval to y for sure. And you can no longer see the old cached value for y.

Even though the above scenario is theoretically possible, the chances of observing a problem due to it are extremely minute. The reason is that even if you setup the caching properly, P2 will likely have ample opportunity to service the messages (i.e., inval) in its probe queue before it receives the data reply for “read p”. Nonetheless, if you get into a situation where you have placed many things in P2’s probe queue ahead of the inval to y, then it is possible that the reply to p comes back and bypasses this inval. It would be difficult for you to set up the scenario though and actually observe the anomaly.

The above addresses how current Alpha’s may violate what you have shown. Future Alpha’s can violate it due to other optimizations. One interesting optimization is value prediction.

From: http://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html

Over!