TID's Blog

占星与星座计算 morinus house system在系列前三节，已经基本介绍了和占星有关的模型，基本的分宫制的原理和占星以及天文中所出现的术语，这一节将带大家进行一次实际的占星计算。本文仅涉及星盘的计算，不涉及其他。 本文的重点是星盘的计算。本文将采用莫林分宫制morinus house system！至于为什么选择莫林分宫制，是因为莫林分宫制可以找到具体的数学计算公式，便于计算。且莫林分宫制在高纬度地区受到的扭曲小。至于分宫制的基本原理，可以查看上一节分宫制基本原理。 对于“morinus house system”是有专门的计算方法，通过一系列的加减乘除算出一个人出生时的MC、Asc以及每个宫头所在得度数，就可以排出一个近乎完整的星图了。 ASC：东升点是在诞生时刻在诞生地点的东面地平与黄道交接的一点 MC：天顶 我们在计算的时候需要以下参数 当事人的出生位置，需要从具体地点转化成经纬度 出生时间，需要转化为恒星时 黄赤交角，这个是固定值。关于黄赤交角可以看第一节天球部分。23°27′ 以及如下公式 MC = arctan(tan(RAMC) / co...

占星与星座计算 儒略历和恒星时计算在前两节的文章基础之上，我们开始进行真正的计算。在介绍计算星盘之前，我们需要一个预先准备的数据。儒略历和恒星时。网上的现成代码似乎没有说的很清楚，公式不够统一，结果也难以验证，为此参考了很多资料。其中有两个资料确定是对的。 https://zh.wikipedia.org/wiki/恒星时 上面公式中关于儒略历的转化公式是正确的，请注意其中的高斯符号。高斯符号相当于代码中的floor()函数。 后面关于恒星时的计算不确定正确性。 然后参考一份关于天文算法的论文，或者是一本翻译的PDF。感谢“冯剑和他的译友”翻译了这本天文算法，使我得到了确切的公式。 关于什么是恒星时可以也可以参考上面的wiki。 关于结果，分别得到了多项式T，算出来以角度为单位的恒星时，以时间hour为单位的恒星时，以时分秒为单位的恒星时。 现在公历纪元的年表示为Y、月为M、日为D、时为h、分为m、秒为s，1月、2月分别当做上一年的13月、14月。（例：2010年1月1日时Y=2009, M=13, D=1），然后求出儒略日 计算儒略历请注意以上的重点。 代码如下 1234...

占星与星座计算 黄道十二宫与分宫原理在占星与星座计算的第一篇文章中，尽可能详细的介绍了天球的构建过程原理和相关的概念。这一节我来介绍何为黄道12宫以及分工制的基本原理，不涉及具体分宫制。 黄道带上一节的天球示意图中，我们已经标注出来了黄道，就是假定地球不动，太阳绕地球运动所形成的面，就是黄道。因为地球自转和地球公转是有一定角度偏差的。所以黄道和赤道是有一个23.5度的夹角的。 黄道带（或是黄道十二宫）的概念起源于巴比伦占星术，巴比伦人注意到了与太阳同时升起的星星，在黎明之前，可以观察到靠近太阳位置的星星升起，这些星星以一个似乎规则的圆周来回运动。他们将这些星星分为十二组，并给其命名。希腊人从巴比伦人那里继承了这一习惯，才有了黄道十二宫，这个词来源于希腊文zodion，意为“小动物”。 具体的黄道带的概念如下 黄道带（希腊语：ζῳδιακός, zōdiakos），是天文学的名词，指的是在黄道上的星座组成的环带，不仅是太阳每年在天球上所行经的路径，月球和行星的路径也大略都在黄道的附近，因此也全部都在黄道带的星座内。 在占星术，黄道带被人为划分为十二个随中气点移动（与实际星座位...

占星与星座计算 天球最近因为某些原因，有了一段空余的时间。当你空闲便有了一些奇思妙想。因为很多年前特别喜欢一个关于星座的故事，所以利用这一段空余时间写一个系列文章讲占星中的一个小知识。为了不使文章引起争议，特此声明：本人完全相信星座！不解释。文章的前面系列介绍和占星有关的天文基本概念，后面具体根据人的出生时间，地理位置（经纬度）来计算人的星座。可能读了这一系列的文章，大家可以更好的理解为什么星座归类于“占星学”，这样一个听起来非常正式的名字。另外因为不是撰写论文，本文不会详细列出各类依据。太累! 天球概念 以上图片为完整的天球示意图 和地球概念相对，古代天文学家提出了天球的概念。天球是一个想想的球体，他也是旋转的。理论上具有无限大的半径且和地心是同心的。如图所示：和地球有赤道和南北极的概念对应，天球也有对应的天球赤道和天球南北极。 古代天文学家认为我们和星体是等距离的，尽管这并不正确。因为古代缺乏有效的天文观测手段。星球不是靠我们肉眼就可以判断出距离的。古代科学家克服了这种距离上的因素，使用角度来确定星球在天空中的位置。在当时观测条件受限的情况下，不失为一种很有效的天文抽象系统。...

比特币pow难度验证何为POWpow的全称为proof of work，即工作量证明。简单的解释为“做了多少工作”。抛开区块链的背景，pow就是对自己做了多少工作的一种说明：比如做了学习了50个小时的汽车驾驶。而他人很容易验证这个结果：你可能50个小时之后拿到了一本驾照。别人就知道你确实在学习驾驶上使用了50个小时。 Block Header在区块链的世界里，pow的数据可以体现在区块链的区块头中。当然一般来说，讲解POW的难度离不开挖矿问题。本文因为主要讨论方向的问题，不展开讲挖矿，主要从区块头入手。在阅读下面的内容之前，默认读者已经有了如下前置知识 区块链常识 比特币基本概念 挖矿基本概念 抛开前置知识之后，我们来看区块头的数据结构。 https://en.bitcoin.it/wiki/Protocol_documentation#Block_Headers 可以直接参考以上链接，当然可以可以直接查看比特币的源码，我们现在把数据列出来。 12345678struct header_structure { // BYTES NAME uint32_t nVe...

拜占庭将军问题简述拜占庭的简述本文将用于介绍著名的拜占庭将军问题。在介绍拜占庭将军问题之前，先简单说一下拜占庭。拜占庭帝国，在古代西欧也被称之为东罗马帝国。是一个位于欧亚交界处的封建君主制国家，其领土包括现在的欧洲南部，西亚和北非。公元四世纪左右，罗马帝国开始分列为罗马东部和罗马西部，这两个国家都被视为罗马正统，大概到公元十世纪，罗马西部陷落，随着神圣罗马帝国的建立，罗马东部失去了罗马这个单词的独占权，开始被称之为东罗马帝国。大概在16世纪之后，开始出现了拜占庭帝国的说法。值得一提的是，拜占庭帝国的首府君士坦丁堡被第四次十字军东征攻陷，从此一蹶不振。1453年5月29日，君士坦丁堡被强大的奥斯曼帝国攻陷，末代皇帝君士坦丁十一世战死。东罗马帝国就此终结。当然，此文不是介绍东罗马帝国历史的文章，在此仅简述拜占庭帝国的历史。 拜占庭将军问题是什么拜占庭将军问题和拜占庭的历史其实并无关联，拜占庭将军问题也不是历史上真实存在的问题，他是著名计算机大神兰伯特于1982年提出的。拜占庭问题描述的是如下的场景 假设有一座城堡，拜占庭帝国想攻陷这座城堡。所以派出了很多支军队，因为通讯条件很落后，...

之前已经在x86的mac电脑上编译过substrate，按照官方指南上的操作就可以正常编译。但是在新款m1电脑上并没有编译通过，现在重新尝试在m1上编译substrate。 主要的准备过程参考如下文章 https://zhuanlan.zhihu.com/p/337224781 不过参考文章写于2020年12月16日，到现在（2021年3月10日）有部分状况已经发生了变化。针对和文章中不一样的状况稍作说明。 RUSTrust环境现在可以直接支持m1。所以使用rustup脚本可以直接安装rust，不需要额外设置。安装完成之后使用 rustup show 查看toolchain。则会发现是以aarch64开头的，原来的x86下面的tool-chain是 stable-x86_64-apple-darwin (default) 注意差别。 brewmac上的包管理离不开brew，所以一定需要安装brew。brew现在也已经官方支持m1，不再需要像参考文章中的特殊设置，直接使用官方脚本安装即可。brew在mac下有两个目录，我们暂时只关心在m1下的原生文件目录。可以cd到一下目录...

Sqlite自增字段起因：在使用数据库存储从区块链网络上取来的block_header时，block_header本身并不带自身的高度信息。不过取来的数据是经过筛选的，按照数据库存储的顺序就可以代表blockheader的高度。所以在数据库中增加一个id primiry key autoincrement 的自增主键。每次从数据库查询时获取id值来代表区块的高度。但后来重构，id被TEXT类型的逐渐替代，所以这个功能无法正常实现。所以产生以下疑问 在已经有TEXT类型的主键后，sqlite可以拥有别的自增字段吗?不可以！在sqlite的文档FAQ中第一个问题（文末给出参考链接）就是关于如何设置自增字段的。在sqlite中自增约束AUTOINCREMENT只可以跟在PRIMARY KEY后面。把AUTOINCREMENT放在主键以外的地方是不可以的。或者再明确一点，要想在sqlite中拥有一个自增字段必须这样写 1id INTEGER PRIMARY KEY AUTOINCREMENT, 要求id的类型必须是INTEGER。每次插入数据库的时候，不要插入id的数据，数据库会自动为...

多线程原语CondVar多线程下的原语，除了我们常用的锁，还有另外一类用于同步的原语叫做“屏障”，“条件变量”(在rust或者cpp中)。在其他语言中也有类似的概念，叫做栅栏，闭锁，屏障，信号量等。他们具有相同的意义。 在介绍条件变量之前，先介绍屏障（Barrier）。屏障相当于一堵带门的墙，使用wait方法，在某个点阻塞全部进入临界区的线程。条件变量（Condition Variable）和屏障的语义类似，但它不是阻塞全部线程，而是在满足某些特定条件之前阻塞某一个得到互斥锁的线程。 单纯讲条件变量的意义并不直观。换种描述 条件变量可以在我们达到某种条件之前阻塞线程，我们利用此特性可以对线程进行同步。或者说做到按照某种条件，在多个线程中达到按照特定顺序执行的目的。 为此我们设计如下下面流程。为此流程写一段代码，来体会条件变量的作用 我们启动三个线程，t1，t2，t3。分别执行任务T1，T2，T3。现在要求：T2必须等待T1和T3完成之后再执行 12345678910111213141516171819202122232425262728293031323334353637...

Jni符号表本文是之前博客文章 《使用rust写安卓库》 的延续。之前的文章主题是如何利用rust-jni库提供便于java使用的rust jni代码。本文在之前的基础上继续提供后续关于jni符号，或者type的说明。 起因写rust端代码的时候，如果我们想返回一个java端的对象我们的rust代码大概会按照以下写法（仅为示例，不可运行）： 12345678910111213141516#[no_mangle]#[allow(non_snake_case)]pub extern "system" fn Java_JniApi_hello(env: JNIEnv, _: JClass, str: JString) -> jobject { let str = env.get_string(str).unwrap(); let message_class = env.find_class("JniApi$StatusMessage").expect("can't find class JniApi$StatusCode"); let message_ob...