• [量子计算]相位估计算法

    本文出自:【InTheWorld的博客】 (欢迎留言、交流)

    量子相位估计算法

    量子相位估计算法(Quantom Phase Estimation)也称作量子特征值估计算法,是一个比较基本的算法。它的作用直观说来就是来估计一个酉变换的特征值。由于酉矩阵拥有一个性质:酉矩阵的特征值都是模为1的复数。所以对酉矩阵而言,其特征值和相位基本是对等的(因为模长已经确定了)。

    量子傅里叶变换

    在量子相位估计算法中,需要使用到量子傅里叶反变换。因此,我们简单了解一下量子傅里叶变换的相关知识。经典的离散傅里叶变换作用于一个复向量(x_{0}, x_{1},\cdots,x_{N-1}),并把它映射到另一个向量(y_{0}, y_{1},\cdots,y_{N-1}),其映射关系如下:

    y_{k}=\frac{1}{\sqrt{N}} \sum_{j=0}^{N-1} {x_{j}e^{-2\pi ijk/N}}【查看更多】

  • 简单分析ARCore和SceneForm

    本文出自:【InTheWorld的博客】 (欢迎留言、交流)

    arcore-hero-800x498

    从ARCore去年下半年发布到现在已经半年有余了。之前其实一直有点手痒,想玩玩AR应用开发。之前有参考一本书,玩过一个简单的基于OpenCV和OpenGL的AR应用,但的确太简陋了。然而之前ARCore只支持Pixel之类的亲儿子手机,所以一直没有机会把玩一下。前两周偶然发现mix2s已经支持ARCore了,所以就乘放假的机会玩玩demo,分析一下ARCore的应用开发。

    ARCore支持Java, C, Unity以及Unreal这几种开发方式。在最近的Java SDK中新增了SceneForm api来支持渲染。这确实是一个比较大的进步,毕竟裸写OpenGL还是有点麻烦的。本人没弄过Unity和Unreal这些渲染引擎,所以就从Java SceneForm的SDK入手了,毕竟比较熟悉(其实就是懒)。

    虽然前文废话已经说了不少,… 【查看更多】

  • 关于Fuchsia OS的一些思考

    fuchsia

    去年年中的时候,就听说了Fuchsia。不过当时也没特别关注,毕竟Google对OS的执念很重,一不开心就启动一个新的OS项目。这几天官方公布了Fuchsia的一部分文档,这个文档目前还不太全面,不过也能粗略了解一下Fuchsia吧!限于个人水平有限,博文不免会有错误,还望多多指教。

    一、“瞎掰向”分析

    对于顶级IT公司来说,“操作系统”一直是一个独特的东西。从正面看,操作系统意味着生态系统、用户粘性。所以OS成就了很多公司,Solaris之于Sun,Windows之于微软。然而成功背后总有很多失败,而做OS的风险非常之大,强如微软和Facebook,都在移动操作系统领域一败涂地。

    Google作为一个后来者,Andriod目前在移动市场的份额已经非常成功了。即使在美国,iOS【查看更多】

  • 线程同步技术之RCU

    本文出自:【InTheWorld的博客】

    多核程序设计其实挺困难的,就拿RCU(Read-Copy-Update)技术来说,我现在已经不知道自己看《深入理解并行编程》的RCU多少次了。到现在为止,还是有一些东西没有完全理解。这篇blog算是对我所领会到的RCU知识的暂时性总结。

    • RCU背景

    从个人的理解来讲,RCU其实是对rwLock的一种优化。从不区分读写的粗粒度锁到读写锁,然后到RCU机制,这就体现着并行程序设计的不断演进。rwLock的思路是,多线程读取不存在同步问题,所以放宽了读取锁,提高了并发读取的效率。而RCU的思路是,维持临界区多个版本(完整的非中间版本),同时取消读取锁,这种优化将会进一步的提高读取效率。事实上,在多数的多线程应用场景上,读取频率都是远远大于改写频率的。特别是在Linux内核中,很多全局数据结构会被同时读取,其次数远高于写入次数。

    image

    Figure… 【查看更多】

  • 基本线程同步总结(C与Java)

    本文出自:【InTheWorld的博客】

       《Posix多线程程序设计》是我读的第一本关于多线程程序设计的书籍。这本书生动且深刻地讲解了多线程程序设计的难点与Pthread库的使用方式,我从中收获颇丰。Pthread作为操作系统接口标准,直接用于应用层开发难免会让人感觉到有些单薄。Java对多线程程序设计模式进行了一定的封装,以方便大家的使用。然而在基础功能上,Java的多线程程序与Pthread其实非常相似,这也是这篇blog是使用这个标题的原因。

    • Mutex(Pthread) vs Lock/synchronized(Java)

        Mutex是Pthread提供的最基本的线程同步工具,Mutex的功能突出一个简单粗暴,类似于操作系统中的自旋锁(当然,Mutex会【查看更多】

  • RxJava设计原理与解析<2>

    本文出自:【InTheWorld的博客】

    在上一篇blog中,我们通过一个简单的例子探索了RxJava的设计原理。而这篇博客的主要内容是研究RxJava的高阶算子。然而,RxJava中的高阶算子非常之多,每一个分析是不太现实的。所以,这篇文章的内容主要以map和flatMap为例,分析一下RxJava中算子的实现方式。

    • map算子的原理

    image

    有过函数式编程语言学习经验的同学大概对map算子都不会感到陌生。即使没有学习过functional programming,也大概听过MapReduce。map算子的功能是把一个值作为输入,对应地输出一个值,实现了
    “一一映射”的功能。在RxJava中,map的简单用法如下:

     Observable simple = Observable.just( 2, 3, 5, 8);
        Observable duplicate = simple.map(v -2*v);
        duplicate.subscribe(
    【查看更多】
  • Qt on Windows实现解析

    就窗口系统而言,我对C/S架构的更为熟悉一些。以前看过基于X window的一些实现,比如qtopia以及其他一些嵌入式窗口系统。C/S架构的GUI系统的结构比较清晰。其中,窗口服务器负责监听输入时间、屏幕绘制以及窗口状态维护,应用程序负责接收服务器的消息并进行处理、并把状态改变反馈给窗口服务器等。

    但是,Windows窗口系统使用的却是基于共享库的实现方式。共享库中保存着所用图形客户端的窗口信息,共享库和每一个客户端程序都运行在同一个进程中。基于共享库的图形系统具有响应速度快、资源开销小的优点,这也是Windows窗口系统表现非常优秀的原因。这种窗口系统带来的问题就是对共享信息访问的安全性。

    在虚拟内存管理的前提下,对这些共享信息的访问无疑要借助内核态的帮助。Windows下的图形应用之所以需要提供回调函数,是因为这个… 【查看更多】

  • Android图形系统之Activity构成原理

    Android_View

    Activity是Android图形系统中非常重要的组成部分。图形系统客户端——Android应用程序的多数功能都是通过Activity实现的。上图展示了Activity类的构成,Activity主要由Window(phoneWindow的抽象基类)和WindowManager两部分构成。Window主要负责Activity的窗口视图,而WindowManager则主要负责与WmS交互。

    在这篇博客中,我不打算详细深入窗口视图的实现或者WmS的细节,而是比较宏观的梳理一下Activity的脉络。

    DecorView

    DecorView是Activity的根视图,从上图可以看出DecorView继承与ViewGroup。而ViewGroup的结构是大家都比较熟悉的,如下图所示。这… 【查看更多】

  • 多线程程序之线程私有数据

    在C/C++的多线程程序中,所有的线程共享相同的地址空间。所以数据段和进程堆的数据,都可以被所有线程读写。在极端情况下,线程的栈空间也可以被共享。只有线程的寄存器上下文算是真正私有的。对于某些变量,我们希望它在不同的线程中具有不同的值,这就是线程私有数据的用途。

    对于普通的全局变量,或者通过指针或引用实现的共享,其实在内存中只存在一个备份。而进程私有数据则相当于一种Map型的变量,根据线程的id,线程私有变量对应于不同的值。

    /*
     * tsd_once.c
     *
     * Demonstrate use of pthread_once to initialize something
     * exactly once within a multithreaded program.
     *
     * Note that it is often easier to use a statically initialized
     * mutex to accomplish 
    【查看更多】
  • 解析Google Analytics机制

    前几天准备在这个博客上装一个Google Analytics插件,虽然我知道这里其实没有人访问的(人艰不拆)。然后我就非常好奇GA的原理,因为WebSocket才出来没多久,以前的异步信息到底是怎么传递的呢?按照我一贯的小猫钓鱼风格,我决定来一探究竟。
    首先还是去找了Google Urchin的代码看,对Javascript的语法不太习惯,看得有点云里雾里。不过还是看出来一点端倪,就是Image。简单来说,在客户端JavaScript中new一个Image对象,然后指定它的src属性,可以引起浏览器对图片的动态加载。聪明的工程师们就是利用了这样一个特性(URL中包含的信息)最终实现的客户端信息的动态传递。听起来也是挺简单的,何不尝试做一个demo呢?
    前面学过一点三脚猫水平的node.js,这里就选择用它了,毕竟几行代码就可以搞定。首先还是要做一个web页面,代码如下:

    <!DOCTYPE
    【查看更多】