我们知道STEEM体系中,在处理STEEM和SBD之间转换时,使用的价格是median_history_price or feed price
比如说以下场景:
使用这个价格的原因在于,这个价格相对而言比较稳定,不会大起大落,比较适合用于处理以上任务。
(图源:pixabay)
但是,有时候,median_history_price 与内部市场的价格偏差比较大,比如我写作本文时
不难看出,这两个价格偏差极大。
于是我们就有了, 发文时选择Power UP 100% 是否合算的问题?
为了方便自己和他人,我特意给微信公众号加了一个辅助大家判断的小功能。
老生常谈,是否100% Power UP? 公众号新功能!
以100SBD的作者奖励来比较,在当前价格下:
我们据此给出判断:发文建议: Power Up 100%
一切似乎都很正常,直到有一次我测试时发现,偶尔出现了 Market Price: 1.000 或者 Market Price: 2.000这样的数据。
在这两天市场价格一直在1.2 - 1.6之前徘徊的情况下,无论是1.000的极低价格还是2.000的极高价格都是不合理的。莫非是我抓的数据有错?看了一下内部市场的成交历史,竟然发现类似这样的数据:
我不清楚内部市场交易撮合的规则,但是既然这样的交易数据实实在在的存在,那么由此可见并非是我的错。
但是,无论是谁的错,这样毛刺数据,都是不可接受的,一旦出现这样的毛刺数据,我的辅助判断就可能出现极大的错误!
找出问题,不是我们的目的。找出并解决问题,才是我们要做的。
既然毛刺数据会影响我们的判断,那么我们就要想办法消除毛刺,用我做平衡车姿态分析啥的时候常用的术语叫做滤波。
我们之前采取的方法是,get_ticker,从中我们可以获得:
最高买单价格,最低卖单价格,以及最后一笔成交价格等
我们之前辅助判断功能中采取的就是Last price,因为最后一笔交易可能是成交量极小的毛刺交易,所以偶尔会导致这个价格极度失真。
那么都有哪些方式可以解决这个问题呢? 我大致想到如下方法:
对于第一种方式,由于steem内部市场不是很活跃,有时候还好,但有时候Highest bid以及Lowest ask差额巨大,单单取中间值,不是很合理。
对于第二种方式,同样steem内部市场不是很活跃,可能之前一笔成交订单已经过去了好长时间,这样取N比订单,计算参考价格,可能数据会比较陈旧。
第三种方式,相对比较合理,通过当前的买单和卖单来计算出参考价格,无疑是相对比较合理的。
以获取五档order book为例,我们会得到类似如下数据:
我们有几种选择
通过测试,发现在不同场景下,以上几种方案计算出去的数据,差额极大。
以上述数据为例,后三种方案算出的价格分别为:
可见,计算出来的价格更倾向于反应买卖双方的期望价格。当市场价格趋于平稳时,这个三个计算出来的价格均在Highest bid与Lowest ask之间,差异不大。当市场暴涨或者暴跌时,这个三个计算出来的价格会有严重的倾向性,甚至会超出Highest bid与Lowest ask的范围。超出Highest bid与Lowest ask的范围是否代表不合理,也不尽然。但是上述计算出的数据显然不合理。或许我们根据卖单与买单的量,以及历史成交价格,据此判断出上涨或者下跌的趋势,进而对上述结果进行修正,才会得出趋于合理的数据吧。
再回头看,我们不过要一个市场价格的参考价格,用于判断是否适合Power UP 100%, 有必要搞这么复杂吗?心累!
那就随便用一种方式好了,毕竟都差不多嘛。以后请叫我差不多先生。😭
This page is synchronized from the post: 如何计算内部市场当前参考价格
距离Follower突破1000大关已经过去了两个多月,之前庆祝的帖子仿佛就是昨天刚刚发的一样
前两天,偶尔看到Follower人数正好突破3000大关,遂截屏记录一下
这次不搞什么庆祝了,也没啥值得庆祝的。
只是想告诉大家,微信公众号增加了个新功能:显示Followers和Following 数量。
想知道 自己或别人的Followers和Following 数量?
关注微信公众号: steemit
输入@steemid
即可查询
(将steemid
替换成你自己的账户哦,比如oflyhigh
再来看看甜心妹妹的@sweetsssj
好有魅力 😍 ,好羡慕呀 😍
大家或许注意到,我将Followers和Following 数量查询,放在最基本的用户查询里,这样大家就无需记忆以及多输入类似?follow
这样的子命令了。
之后对指令进行规范和整合,是我的一个目标,让公众号更便于大家使用。
3045 个 Follower 大致能排到什么名次呢?
对此我感到很好奇,随手用 steemdata 查询了一下print(db['Accounts'].find({'followers_count': {'$gt': 3045}}).count())
居然还没进入前200名,任重道远啊。
顺便说一下:
furion’s new toy: A full RPC steemd node for SteemData
@furion 为SteemData 专门买了个服务器做Full RPC steemd节点,以后 steemdata 将会更加稳定、快速和可靠。
将followers数量的排名集成到公众号,似乎是个不错的主意。不过有点困难😭
欢迎大家多提宝贵意见啊。
This page is synchronized from the post: Followers 突破3000大关,你想随时查看你的Followers数量吗?公众号增加新的小功能!
之前有一个任务,其中一个步骤是从名单中随机选择部分用户去执行一些操作,而且要保证用户被选中的概率大致相等。
(图源:pixabay)
random.randint()
我对Python不是很熟,所以我首先想到的是用random生成列表长度范围内的随机数,然后再用下标的方式去读取列表。
为了记录操作次数以比较列表元素被选中的概率,我将列表改成字典的形式,以便于记录操作次数。
1 | import time |
random.choice()
上述代码虽然能实现功能,但是总感觉不是很优雅,经过查手册,发现了random.choice()这个函数,来试试这个吧。
1 | import time |
可以看出元素被选中的概率基本相同,但是就性能而言,比random.randint()方法要好很多.
random.sample()
有发现random模块居然还有个sample函数,看起来专门为取样设计的啊
代码如下:
1 | import time |
OMG, 尽管元素被选中的概率基本相同,但这性能哭了。(当然,可能耗费在列表元素读取上,具体是啥,懒得评估了),看来名字好看也不一定中用啦。
random.choices()
咦,又发现一个崭新的函数,之所以说它是崭新的,是因为这是在3.6版本中新增的函数 New in version 3.6
如果你还在运行3.6以下版本,对不起,这个你用不了。
1 | import time |
哇,你看看人家,要结果有结果,要颜值有颜值,要性能有性能,简直完美的不要不要的。
从上边的结果,不能看出,选取结果概率都是均匀分布的,符合我们的要求。
但是选择一个元素的时候, random.choice()
函数性能最好。
那么我们为何还要大力推崇random.choices()
呢?答案有两点:
代码:
1 | import time |
如果想让不同的元素,被选取的概率不同,我之前的做法是这样的
把['a', 'b', 'c', 'd']
改成['a', 'a', 'b', 'c', 'd']
,是不是看起来傻,我觉得也是!
正确是姿势是用random.choices()
并设置权重/weights 的方法
代码:
1 | import time |
听说用cum_weights参数,效率会更高,比如改成这样:choices = random.choices(list, cum_weights=[2, 4, 5, 8], k=2)
试了一下,果然性能提升了不少,不过我决定坚决弃用,为何? 不直观呗!
通过学习,我们知道在Python 中,可以用下列函数随机选取元素
random.randint()
random.choice()
random.sample()
random.choices()
通过测试,我们发现最后一个函数可以用来选取多个元素,并且支持设置权重,性能也是极佳。以后就用它啦。
之所以做这个测试,是因为我的一段程序中原本用的random.sample()
,但是选中的元素明显概率不一样,后来我改写了程序其它部分,并改用random.choices()
,概率分布效果极佳。
但是我觉得random.sample()
不应该存在概率问题啊,于是写了上述几段程序测试了一下,发现并不存在所谓概率的问题。看来我冤枉random.sample()
了,是我其它代码导致的问题, 但是发现random.choices()
果然是最佳选择。
This page is synchronized from the post: Python 随机选取元素的一些方法以及概率问题
我家所在单元楼一楼二号院子里有一颗大枣树,结的枣是又大又甜,现在正是收获的季节。
(图源:pixabay)
偶尔我从楼下经过时,总顺手拽一两颗大枣,边走边吃。先澄清一下,我这可不是偷鸡摸狗、顺手牵羊之类的行为,而是经过枣树主人允许的。枣树的主人,原本是我家楼上的阿姨,去年不小心崴了脚,虽然说休息一两个月以后已经没什么问题了,但是家里儿子孝顺,觉得老人住的楼层高,还是不太方便,恰巧一楼的住户房子亦欲出售,便买了下来。
从楼上邻居,变成楼上和一楼的双重邻居,我们不是一般的熟,那是熟透了。阿姨不止一次和我说,什么枣啊,院子里的水果和蔬菜想吃啥自己随便摘随便挖,千万不要客气。但是我还没无耻到自己带个小铲子去人家院子里挖菜的地步,但是摘几枚大枣,我认为不算啥大问题。
话说有天我从外边回来,有两个30左右的女子正在一楼花园的墙外扯着枣树摘枣吃,吃的好不欢乐。看到我回来,而且明显是这个单元的,她们有些窘迫。其中一个略微年轻的女子有些羞愧的对我说:“我们摘几个枣吃,这枣太甜了”。看到她们窘迫的样子,我觉得很有趣,便和他们开了个玩笑,我说:“摘吧,吃吧,反正枣树也不是我们家的”。两个女子闻言十分诧异,不知是因为她们觉得她们白惭愧了,还是因为对我面对她们摘枣行为无动于衷而感到愤怒,年轻女子沉默几秒后,大声对我喊,“你太过分了,怎么可以这样?!”原来面对摘枣者无动于衷,竟然会被指责,我感到很无语,我对她们说,“好吧,不要摘枣了”。两女子落荒而逃。
前几日从外边归来,恰逢阿姨在院子里忙碌,看到我之后,给我弄了一大堆蔬菜,并且给我找来一个凳子,让我自己多摘一些枣。我和阿姨聊起这个趣事。阿姨和我说,别人愿意摘枣就随便摘吧,她家儿子告诉她,如果自己吃枣就在院子里摘,不要去摘墙外边的。因为枣很多,吃都吃不了,伸到墙外的枝杈上的枣,就让来往的路人吃吧。因为路人们大多不会去院子里摘枣吃,而外边的枝杈上的,顺路拽几个还是很方便的。
(图源:pixabay)
听了阿姨转述的她家儿子的话,我颇有些感慨。
小区里的一些邻居,将院子外物业栽植的观赏果树都视为己有,不许任何人采摘。尽管我不赞成采摘观赏果树上的果子,但是因为一两枚其实并不属于自己的家的果树上的果子而和别人吵架的事情,我也是相当看不惯的。而像阿姨儿子这样的,将本属于自己家的果子让路人随便采摘,又有几人能做到呢?
从其它邻居的口中,我曾得知,阿姨家的儿子是做珠宝生意的,做的规模很大很成功。以前,我总认为,成功有时候仅仅是运气,但从墙外的枣这个事上,我仿佛抓到一些什么,或许成功不仅仅都是运气和偶然吧。
——————
哦,对了,枣树是一楼二号的,不是一楼一号崔奶奶家的。
This page is synchronized from the post: 墙外的枣
之前我写过几篇文章,关于发文时,是否应该选择100% Power UP.
我看了一下日期,分别是4个月前,以及两个月前,现在距离上一篇文章又过了两个月,事情又有何新变化呢?
老实说,别说过两个月,就是过两周,哪怕是过两天,两天前我的想法为什么是这样?我都很难回想起。没办法,上年纪了,很难和年轻时一样记忆力极佳。
至于这个结论咋来的,我就不去回忆了。
但是这个结论对普通用户,甚至对我而言,都有些鸡肋:
很累,是不是?我也觉得是!
于是我就想,能不能在公众号中添加一项新功能,建议用户发文时选择Power Up 100%或者Default(50%/50%),所以公众号的新功能来了。
关注微信公众号: steemit
输入: ?pu 或 ?powerup
例如:
?pu
为了给小伙伴们一个直观的印象,我假设一篇文章 100SBD 作者收入,在当前行情下,不同选择的估算价格以及市场价格。
当市场价格以及中间价(内部核算价格)差额达到5%比重时,我会给出相应的建议。
当前差额实在太小(没有达到5%的阈值),考虑市场价格波动,其实选择啥差异不大啦。
为了看起来更直观,我在程序中做了一下模拟,假设市场价格是1.5 SBD/STEEM, 公众号给出的结论还算靠谱😀
除了,给出发文选项建议以来,你还可以用来查看STEEM的市场价格以及中间价(内部核算价格)。
欢迎大家多提宝贵意见啊。
This page is synchronized from the post: 老生常谈,是否100% Power UP? 公众号新功能!
(图源:pixabay)
从小到大,我都比较喜欢喝饮料。小时候喝的是2毛钱一瓶的老汽水,味道和雪碧类似,玻璃瓶子铁瓶盖。
那时候家附近有个汽水厂,我经常和父亲去汽水厂直接成箱买汽水。一箱24瓶,算批发价,我已然记不清楚是多少钱,但比从小卖铺一瓶一瓶买要便宜很多。我特别喜欢汽水厂车间内空气中香甜的味道,几十年过去,记忆尤深。
记不得什么时候开始,饮料市场渐渐被易拉罐装或者塑料瓶包装的各种饮料所充斥,汽水厂不知何时倒闭了。我时常喝的饮料也渐渐的变成了荔枝味的珍珍、康师傅的冰红茶、冰绿茶、王老吉、咖啡,以及雪碧及可乐。
以前工作的时候,公司有提供免费咖啡,我和几个好友,每到休息的间隙,就必喝一杯咖啡,顺便在从自动售货机中买一点小食品,边吃边聊,好不惬意。后来,大家普遍反应,喝了公司的咖啡之后,哪怕只有一杯,也整宿整宿的睡不着觉,第二天毫无精神,只好靠咖啡提神。这样下去,终不是办法,于是我们变集体戒了咖啡。
但是休息的间隙喝饮料吃零食的习惯却很难一下子戒掉,于是我们每到休息时间就集体光顾公司院内的小超市,基本人手一瓶可乐一根烤肠。虽然喝可乐多了,也会导致晚上失眠,但是不会很严重,所以大家都不以为意。我想或许是那个时候起,我便产生了对可乐的依赖吧。
有时候别人谈到毒瘾、烟瘾,我总是颇不以为然,一个人如果主观上想控制自己,那有什么控制不了的呢?如果控制不了,那一定是自制力不够。结果换到可乐这件事情上,我发现,有时候自己真的很难控制自己。这不,刚刚一瓶可乐灌下去,我才觉得我又有些活力了,否则已经昏昏欲睡了。
相信大家都知道碳酸饮料的危害,作为一个长期饮用可乐一类饮品的人,我更是被无数或专业或业余的人告诫,珍爱生命,远离碳酸饮料。对与碳酸饮料的危害,我更是深有体会,因为长期引用碳酸饮料,已经给身体上造成种种不适和伤害。可是我想说的是,我真的控制不住我自己呀。
每当我拿起可乐瓶,我脑海中总是情不自禁的冒出一个成语: 饮鸩止渴,或许这个成语用在此处,不是很恰当,但是无疑是非常形象的了。我总设想,如果有一天我非常非常渴,一瓶美味又解渴的毒酒放我面前,我是喝还是喝还是喝呢?我没有给出别的选项,我相信,我一定会毫不犹豫去喝的。
那么生活中又有多少这样的情况呢,当诱惑摆在你的面前,你是否会顾及有什么严重的后果呢?
饮鸩止渴、杀鸡取卵、涸泽而渔、急功近利大概是我们每天都在做的事情吧。
This page is synchronized from the post: 饮鸩止渴
Update your browser to view this website correctly. Update my browser now
咋玩呀,哈哈 This page is synchronized from the post: 咋玩? document.querySelectorAll('.not-gallery-item') .forEach(el => { if (!el.dataset.src) { return; } c
十几年前,因为工作的缘故接触Linux系统。 作为Windows盗版系统的“受益者”,除了学校《操作系统》课程接触的ls、cd、dir、pwd等几个有限的命令,实在是想不起再多的内容了。IBM社区上有一些很经典的Linux系统教程,不得不说从中受益匪浅。然而,工作需要,系统的了解和学习依旧迫在眉睫。
Almost all of the articles are illustrated on Steemit.So I try to figure out how to insert pictures in steemit articles? Then I found two ways: (Maybe
当年错失参与比特币的大好时机,时也命也! 往者不可谏,来者犹可追。按照X网几位比特币和区块链技术的布道者,steemit.com有望成为新的一轮革命。 作为一枚懒散的宅男,是拒绝接受新事物的(其实本质是懒)但是眼见着铺天盖地的讨论,各种前景展望,内心无法保持波澜不惊了。 对赚钱的期望有,但不是那么强
作为一个社交媒体平台,内容毫无疑问是最重要的元素。想象如果这个平台充斥着广告、水贴、色情与暴力等垃圾信息,那么想必离死亡非常接近了。 作为去中心化的平台,尽管顶贴(点赞)等机制会尽量筛选出优质内容呈现在我们眼前,但作为参与的每一个个体,都应当尽量去生产有价值的内容。如果参与者不但会从发文、点赞等行为