出租些SP 当一回债主 - 怎么样把你多余的SP租出去收点利息?

上回说到:

花了200个STEEM租了1万个SP,为期4周(28天),那么平均每天花费 7.14 个STEEM。租的第三天,@minnowbooster 就涨价了,费用从200涨到266.67,于是我在想,是否能把这1万个SP再租回去,如果可以,立马净赚66.6 个STEEM,有木有?

lease-back.jpg

为了更加理解这个买卖市场,我到了 @minnowbooster 官网: https://www.minnowbooster.net/ 然后点到 Open Requests,

fill-this-offer.jpg

这里列出的就是想借SP的用户,和付的费用,需要注意的是平台收取 10%的费用,所以要看你实际上收益是 Effective Price 那栏的钱数。看上满意了就可以点 Fill this Offer。

我找了一个想租225个SP的,租期为4周,那么一共他需要付的费用是6 个STEEM,平台收取债主10%,债主实际收益是5.4 个 STEEM,分配到每天就是 0.192 个STEEM。

1.jpg

下一步,输入你的用户名,通过 steemconnect 登陆,点击确定,系统就自动把你的STEEM借给了租方,每天会自动将收益转帐给你,比如:

1
Receive 0.193 STEEM from minnowbooster	Your 1 Marketplace delegations got you a daily payout of 0.193 STEEM

2.jpg

这里显示的是从我之前借的1万SP里扣掉225 SP,不是特别的准确,我还以为是原本的SP里扣掉的呢。

225个 SP 大概是 100% 全点一次能有 0.03375,但是出租SP能获得自动的收益,好过你手动点赞。比如你度假或者出差有一段时间访问不了STEEM,你完全可以在这段时间内把SP租了,等同于你每天点赞(收入还稳定)。

所以你觉得这样做划算么?欢迎在下面发表你的看法,谢谢阅读!

Originally published at https://steemit.com Thank you for reading my post, feel free to Follow, Upvote, Reply, ReSteem (repost) @justyy which motivates me to create more quality posts.

原创 https://Steemit.com 首发。感谢阅读,如有可能,欢迎Follow, Upvote, Reply, ReSteem (repost) @justyy 激励我创作更多更好的内容。

// 稍后同步到我的中文博客和英文算法博客

近期热贴 Recent Popular Posts

https://justyy.com/gif/steemit.gif


This page is synchronized from the post: 出租些SP 当一回债主 - 怎么样把你多余的SP租出去收点利息?

The profiler told me I wrote some useless code (An Example of Defensive Programming) 性能评估软件说我写了几行无用的代码

When your code has performance bottlenecks, you can use the profiler software to benchmark your code, which will reveal the potential problems in your code or modules (memory or time consuming)

在代码出现性能瓶颈的时候,我们通常使用性能评估软件也就是Profiler 来查看代码中到底是哪几行,或者哪几个模块比较耗资源(速度慢或者占内存)。

Recently, my Profiler told me that I wrote a few lines of useless code.

最近我就用 Profiler 跑了一下,发现我写了几处无用的代码。具体如下:

aqtime-profiler.jpg

As seen in the screenshot, the leftmost numbers are calling counters, the middle columns are time in milliseconds, and the rightmost columns are also time but with the sub-routines. Those lines are safety checks to prevent the crash due to possibly out-of-range errors.

每行代码左边那个数字是被调用的次数,中间是执行时间(毫秒),右边是子函数的执行时间。我红色标出来的执行次数都是 1498179,而在进入这个函数的前几行都是在判断,如果条件不符合就立马退出函数,避免继续往下执行而导致程序崩溃(数组访问越界等)。

Obviously, the statistics show that these exit conditions are never met. Removing these save 2-3 seconds execution time. The method of adding safety checks (e.g. check object for null), are often seen as a way to handle the exception softly. Some might argue that it is a way to hide the errors. It is always better to throw the exceptions as early as you can instead of hiding them, because they will eventually come back to bite you in the as*.

但是明显来说,这几行代码都没有起作用。删掉这几行代码能省下2-3秒的执行时间。其实这种编程风格是 “Defensive Programming” 也就是处处加些判断(比如判断对像是否为 null)而不让程序崩溃。但实际上并不推荐,因为最好是一遇到错误就立即抛出异常,这样可以让我们更早的知道潜在的问题,而不是隐藏错误。

Originally published at https://steemit.com Thank you for reading my post, feel free to Follow, Upvote, Reply, ReSteem (repost) @justyy which motivates me to create more quality posts.

原创 https://Steemit.com 首发。感谢阅读,如有可能,欢迎Follow, Upvote, Reply, ReSteem (repost) @justyy 激励我创作更多更好的内容。

// 稍后同步到我的中文博客和英文算法博客

近期热贴 Recent Popular Posts

https://justyy.com/gif/steemit.gif


This page is synchronized from the post: The profiler told me I wrote some useless code (An Example of Defensive Programming) 性能评估软件说我写了几行无用的代码

步子迈太大容易扯到蛋

人的一生就和升级一样,不断的提升自己。和比你厉害的人在一起能加快你的升级进度,因为就像STEEM一样,大鱼们时不时鼓励你一下,拉你一把,一下子等级就上去了,这远比你整天和狐朋狗友在一起效果要好得多。

可以简单的理解成人以群分,你整天和混得比你差在一起,很容易固步自封,时不时就很有优越感,没法进步。这是很可怕的。那天朋友说,其实我的情况已经比大多数英国人好了。很多英国人40多岁,项目经理,年薪甚至还不到40K。我很震惊,要是换我,都养不起家了。

当然每人情况不一样。但这却提醒我了:人要是不进步,选择会越来越少。习惯了每天悠闲的日子,每天调调程序,但自己 清楚,不进则退,这样实在是在浪费时间。于是挑灯夜读,每天进步一点点。

微信图片_20170818143339.jpg

这几天有过一些思考,自己慢慢清楚了自己想要啥,大象不能一口吃完,步子迈太大容易扯到蛋。一旦决定了就不要再回头。

来,一起喝完这碗没有肉的鸡汤,共勉。

Originally published at https://steemit.com Thank you for reading my post, feel free to Follow, Upvote, Reply, ReSteem (repost) @justyy which motivates me to create more quality posts.

原创 https://Steemit.com 首发。感谢阅读,如有可能,欢迎Follow, Upvote, Reply, ReSteem (repost) @justyy 激励我创作更多更好的内容。

// 稍后同步到我的中文博客和英文算法博客

近期热贴 Recent Popular Posts

https://justyy.com/gif/steemit.gif


This page is synchronized from the post: 步子迈太大容易扯到蛋

A Better Voting Strategy with Back Tracking Algorithm - 通过回溯算法确定更好的点赞策略

In last post, three voting strategies were presented. But we are not sure if there are better ones. Let’s review this:

  • vote all once you wake up
  • vote all once before you go to bed
  • vote and rest at a specific time interval

上回说到点赞策略,但我们并不确定是否有更好的投票策略,或者说,已经有的几种方法已经是相当好的了。我们来回顾一下,

  • 第一种方法:不管三七二十一,直接最开始一并点完。
  • 第二种方法:在睡觉前点完(等SP能量恢复到最大值)。
  • 第三种方法:每次点赞间隔等时间来点。

By using Javascript simulations, we happen to know that if the P is closer to 100%, we choose the ‘vote and rest’ strategy, otherwise, we can just vote all once right before the timespan ends.

我们通过Javascript程序模拟出收益情况发现:如果起始能量很接近格满,比如大于90%,那么选着第三种方式,否则选第二种。 那么我们这篇帖子需要看看能否搜索出最大收益的点赞方法。

This post, we use the backtracking to search all possible strategy solutions. The search space is huge and that is why we make T and N smaller i.e. N=4 (4 hours) and T=4 (4 upvotes per day). M=270 which is 100% payout in unit of dollars.

由于点赞方式的搜索空间较大,所以我们缩小一下范围。我们假设:一天点4次(T=4),在N=4 小时内点完。M还是270美元(100%能量点赞的收益)

Let’s create an array that contains the minutes offsets (from the start) for each votes.

我们先定义一个点赞方案的数组, 值表示为离时间段开始的分钟偏移:

1
2
3
4
var sol = Array();
for (var i = 0; i < T; ++ i) {
sol[i] = 0;
}

For example,
比如

1
sol = [1, 2, 3, 4, 5, 6, 7, 8];

The sol represents voting every minute from the minute 1. There are 8 votes. We initialize the sol array to zeros meaning voting all once at the begining (with zero minute offset)

表示为每隔1分钟点1次,一共点8次,上面的JS代码初始方案数组为0,也就是说统统在开始点完。

Let’s also declare two variables, one stores the solutions and the other stores the maximum payout.

然后我们需要定义两个变量,一个是找到的最大方案数,另一个是最大收益值:初始化为:

1
2
var bestSol = sol.slice(0);
var bestScore = 0;

We need to print out the solutions once we find the best one.

找到较优值后我们需要打印方案:

1
2
3
4
5
6
7
function print(sol) {
var s = "";
for (var i = 0; i < T; ++ i) {
s += sol[i] + ", ";
}
console.log(s);
}

We need a evaluation function that computes the payout given a solution. Every minute, the SP restores 0.005/36.

然后我们需要评估一种方案的收益情况,这时候按分钟来回能量 (每分钟回 0.005/36 能量):

1
2
3
4
5
6
7
8
9
10
11
12
function eval(sol, P, M, T, N) {
var sp_restored = 0.005 / 36;
P = Math.min(1, P + sp_restored * (sol[0])); // Max = 100% 最大P为1
var x = 0;
sol[T] = sol[T - 1]; // Avoid out of range access for sol[i+1] 哨兵:防止 sol[i + 1] 越界
for (var i = 0; i < T; ++ i) {
x += P * M; // Accumulate Payout 累记收益
P -= 0.02; // 2% loss 点一次耗2%
P += sp_restored * (sol[i + 1] - sol[i]); // SP restores before next vote 加上到下次点赞回血量
}
return x;
}

The best part is: the search algorithm. We enforce a 15-minute interval between intermediate votes unless the votes come to the end. The reason for doing this is that the search space is really huge and you can’ t basically finish the search on standard PC. The backtracking can be seen as a search tree, where we start from the root, go as deep as we can, expand to the sibling nodes, and rewind to the parents.

然后最牛逼的来了,就是搜索。我们这里假设点赞间隔为15分钟(除非到达最后时间点),否则搜索空间很大,效率很低。回溯算法的精髓就是:一棵搜索树,能往下走往下走,走到最底再往树的兄弟结点扩展,扩展完退一步(回溯)到上一层,至到第一层节点访问完。

We don’t have the cut-off techniques here, meaning that when we vote at time t, the next votes could happen at t, t+1, t+2 until the end of timespan. The branch factor for this search tree is 60N (assume that all votes are placed at the same time), the depth of the search tree is T, obviously.

由于这里没有剪枝的优化,也就是说,我在t分钟的时候点了第一次赞,我第二次赞可以在t, t+1, t+2至到时间结束再点第二次。点赞次数T越大,搜索树的深度就越大(搜索树的深度等于T),搜索树的宽度为 N*60,因为如果每次点赞都是一个时间点,而这个时间点按分钟来划分的话一共有N*60种情况。

The search space is around (60N)^T and we certainly do not have time to bruteforce all possible solutions. With backtracking, the runtime complexity can be seen as C_(60N)^T i.e. the total number of different solutions to pick T from 60N.

这样的话,穷举搜索时间复杂度就是 (N60)^T 当 N和T都很大的时候穷举无法快速的计算得到结果。而回溯的搜索空间为:C_(N\60)^T 理解为从 60N中取出T个的组合。

The JS code for the backtracking search is:
回溯算法如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
function search(sol, left, n, T, right) {
if (n == T) { // when we reach the tree leaves 到达搜索树的叶子处
var score = eval(sol, P, M, T, N); // need to evaluate this solution 评估结点
if (score > bestScore) { // found a better solution? 记录更优解
bestScore = score;
bestSol = sol.slice(0);
}
return;
}
for (var i = left; i <= right; ++ i) {
sol[n] = i; // The n-th vote is placed at time i 第 n 次点赞在时间为 i 处
search(sol, Math.min(right, i + 15), n + 1, T, right); // try next vote 尝试下一次点赞
}
}

Windows + sublimit text3 + Node.js, we run and get these numbers:
用Node.Js+sublime text3 跑跑 来看看结果:

When P=0.99
当P=0.99的时候:

1
2
3
4
5
calcPayout0 =  1036.8
calcPayout1 = 1047.6
calcPayout2 = 1054.8
calcPayout3 = 1066.5
72, 240, 240, 240,

The first vote should happen at minute 72 where the rest 3 should be at the end, which has earned 12 SBD more.
能量满的时候 第一次在第72分钟的时候点,剩下3次再最后的时间点,能比第三种方案多挣12美元!

When P=0.8 (80%)
当P=0.8的时候:

1
2
3
4
5
calcPayout0 =  831.5999999999999
calcPayout1 = 867.5999999999999
calcPayout2 = 849.5999999999999
calcPayout3 = 867.5999999999999
240, 240, 240, 240

Use all votes at the end is clearly the optimal.
能量不高的时候,最优的方案就是在最后面的时间一块点完。

When P=1 (100%)
当P=1 全满的时候:

1
2
3
4
5
calcPayout0 =  1047.6
calcPayout1 = 1047.6
calcPayout2 = 1065.6
calcPayout3 = 1074.6000000000001
0, 240, 240, 240,

Use only 1 vote at the begining and the rest at the end.. This problem is NP-hard, where you just have to know that it is VERY HARD problem, in WIKI, it describes as follows:

NP-hardness (non-deterministic polynomial-time hardness), in computational complexity theory, is the defining property of a class of problems that are, informally, “at least as hard as the hardest problems in NP”. More precisely, a problem H is NP-hard when every problem L in NP can be reduced in polynomial time to H, that is: assuming a solution for H takes 1 unit time, we can use H‎’s solution to solve L in polynomial time.[1][2] As a consequence, finding a polynomial algorithm to solve any NP-hard problem would give polynomial algorithms for all the problems in NP, which is unlikely as many of them are considered hard.[3]

起床的时候点一次,剩下3次在睡觉前点。这种问题在计算机领域称为 NP-hard, 也就是目前除了暴力搜索+剪枝+回溯 等优化技巧并没有太有效的算法。在WIKi里这样描述NP-困难:

NP困难(NP-hard,non-deterministic polynomial-time hard)问题是计算复杂性理论中最重要的复杂性类之一。某个问题>被称作NP困难,当所有NP问题可以在多项式时间图灵归约到这个问题。
因为NP困难问题未必可以在多项式的时间内验证一个解的正确性(即不一定是NP问题),因此即使NP完全问题有多项>式时间内的解(若P=NP),NP困难问题依然可能没有多项式时间内的解。因此NP困难问题“至少与NPC问题一样难”。

OK, so the preliminary conclusion is: when P is closer to 100%, you might want to try place your first vote at the begining, and the rest right at the end. However, there might be better solutions, i.e. we enforce a 15-minute voting interval here.

好吧:这篇文章的初步结论就是:当起始能量很靠近满格的时候,不妨可以试着在最开始点第一次, 剩下的在时间最后面点完。至于这是不是最优解,很难说。因为,别忘记了,我们这里外加了一个中间点赞时间间隔15分钟的限制。

Originally published at https://steemit.com Thank you for reading my post, feel free to Follow, Upvote, Reply, ReSteem (repost) @justyy which motivates me to create more quality posts.

原创 https://Steemit.com 首发。感谢阅读,如有可能,欢迎Follow, Upvote, Reply, ReSteem (repost) @justyy 激励我创作更多更好的内容。

// 稍后同步到我的中文博客和英文算法博客

近期热贴 Recent Popular Posts

https://justyy.com/gif/steemit.gif


This page is synchronized from the post: A Better Voting Strategy with Back Tracking Algorithm - 通过回溯算法确定更好的点赞策略

[Code Review] - Reinventing the Wheel 代码审核之 重新造轮子

This is a code change that I observe today. It has been in the codebase for a long time, and I find it interesting to talk about it.

今天在看代码修改记录的时候发现有这么一处改动, 虽然这个改动已经很久了,但是我觉得有必要拿出来大家讨论一下:

The LINQ is out since .NET 3.5, and all above code is just doing one thing: select the specific types e.g. either LayoutAnt or LayoutDevice from a member list layoutList . And one line of LINQ does this exactly: OfType<>

2007年 .NET 3.5 之后推出LINQ,其实整个函数只是在做一件事,就是返回类成员 layoutList 中是 LayoutDevice (后面改成LayoutAnt )的列表。但实际上这通过 C#LINQ只需要用 OfType<LayOutDevice> 或者 OfType<LayOutAnt> 即可(暂且不说改动包括重构类型)

The left version is OK, but it is just old-school considering the developer who did not get familiar with LINQ. But the right version is worse. It has added a ref List which will be cleared. This is not unit-testing friendly at all.

左边的版本实际上是OK的,这就是学校的标教科书版本,无可厚非,但右边的这个版本就大有问题,因为参数含有引用 ref, 也就是说每次都把外面传进的变量给清空了,这种函数拿来单元测试并不友好。

The private methods are not unit-test friendly. And one big issue for both methods is: the member variable layoutList is referenced. If you really have to re-invent the wheel, at least make it a public, static method which takes a readonly layoutList and returns a new copy of List. In this case, the entire function is immutable, and unit-test friendly.

如果一定要重新造轮子,两个版本都有小问题,一个是 private 方法不好单元测试,另一个是都使用了成员变量 layoutList, 最好是改成 public static 公有静态方法,传入 layoutList, 然后像第一种方式返回新的List。这样的话,这个公有静态方法就是不会更改 (immutable), 较容易被单元测试。

Originally published at https://steemit.com Thank you for reading my post, feel free to Follow, Upvote, Reply, ReSteem (repost) @justyy which motivates me to create more quality posts.

原创 https://Steemit.com 首发。感谢阅读,如有可能,欢迎Follow, Upvote, Reply, ReSteem (repost) @justyy 激励我创作更多更好的内容。

// 稍后同步到我的中文博客英文算法博客

近期热贴 Recent Popular Posts

https://justyy.com/gif/steemit.gif


This page is synchronized from the post: [Code Review] - Reinventing the Wheel 代码审核之 重新造轮子

Simple Method to Insert Math Equations in SteemIt MarkDown Editor 如何在 SteemIt MarkDown Editor 里添加数学公式?

SteemIt Markdown Editor does not support Latex easily. But one alternative (workaround) is to use the Google Tex Image URL. In particular I like Markdown and Latex because it is what-you-think is what-you-get.

我们都知道 STEEMIT支持HTML和MARKDOWN两种编辑模式,一旦启用了一种就无法使用另一种。我比较喜欢用Markdown, 因为这种是一种比较面向程序员 所想即所得的方式 (What you think is what you get).

I am a math fan, in my last post, I realized that inserting equations in SteemIt Markdown or HTML editor is a pain. The fact is that the Latex is not supported in the SteemIt Markdown editor.

同时,我还是一个伪数学爱好者,在上次的帖子里我就发现STEEMIT的MARKDOWN并不支持LATEX数学公式。实际上Markdown和LATEX也是两个独立的语言,在一般的环境下,需要通过第三方的包来启用在Markdown里Latex公式的支持,但是很明显,在SteemIt里不支持。

In Latex, we use $$ or $ to begin a math equation, but it doesn’t work in SteemIt editor, obviously.

比如在Latex里,我们通过 $$ 或者 $ 来启用数学公式,这里明显不可以:

$$ \sum_{i=1}^{100} f(i^2) $$

We can use the Google API to show the image by inputing a math equation in the URL: The documentation can be found: https://developers.google.com/chart/infographics/docs/formulas

你看,还是没法显示。 其实我们完全可以通过图片的方式来插入数学公式,这里需要用 Google 的库支持,官方文档在:https://developers.google.com/chart/infographics/docs/formulas

We need to replace the following MATH-Equation with your intended math equation.
我们只需要替换以下 MATH-Equation 为你需要的数学公式即可:

1
![](https://chart.googleapis.com/chart?cht=tx&chl=MATH-Equation)

For example,
比如:

1
![](https://chart.googleapis.com/chart?cht=tx&chl=c=\sqrt{x^2%2By^2})

It shows:
显示效果为:

What the hell is the %2B in the URL? You will need to percentage-encode the URL parameters as some symbols represent special meanings in URL.

但,这里面的%2B 又是什么鬼?因为数学公式里含有的一些在URL中表达特殊的字符,像空格,加号,等号什么都得转义,

Here, I recommend an online tool (written by me) to encode the equation/text:
这里推荐一个我很久以前写的工具

https://helloacm.com/tools/url-encode-decode/

For example:
比如把

1
$$ \sum_{i=1}^{100} f(i^2) $$

URL-encoded becomes:
转义后就是:

1
%24%24%20%5Csum_%7Bi%3D1%7D%5E%7B100%7D%20f(i%5E2)%20%24%24

And the final Image URL to insert is:
然后整个图片地址就是:

1
https://chart.googleapis.com/chart?cht=tx&chl=%24%24%20%5Csum_%7Bi%3D1%7D%5E%7B100%7D%20f(i%5E2)%20%24%24

This is how it looks like:
效果为:

%20%24%24
)

I do hope that the SteemIt team supports Latex in the Markdown one day!

SteemIt里没法原生态支持,这至少目前是个可行的方案,我真心希望SteemIt团队能把LATEX这个功能加上去,这样就能方便广大数学爱好者了,至少像我这种伪数学爱好者也能时不时晒晒公式装装B,是吧?

Originally published at https://steemit.com Thank you for reading my post, feel free to Follow, Upvote, Reply, ReSteem (repost) @justyy which motivates me to create more quality posts.

原创 https://Steemit.com 首发。感谢阅读,如有可能,欢迎Follow, Upvote, Reply, ReSteem (repost) @justyy 激励我创作更多更好的内容。

// 稍后同步到我的中文博客英文博客

近期热贴 Recent Popular Posts

https://justyy.com/gif/steemit.gif


This page is synchronized from the post: Simple Method to Insert Math Equations in SteemIt MarkDown Editor 如何在 SteemIt MarkDown Editor 里添加数学公式?

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×