Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overall review: bug fixes, unit tests, new sources, stock publication. #56

Merged
merged 50 commits into from
Jun 26, 2018

Conversation

Zapata
Copy link

@Zapata Zapata commented Jun 7, 2018

Hello @xeroc ,

sorry for this massive pull request, it's not in my habits, but I feel like it will be more efficient like this.
However, I have reported most of the issues seperately.

My initial goal was to implement stock price publication (#54), but when I saw #35 and @clockworkgr 's comment, I thought it needs a global review.

This pull request solve most of the currently open issues.
Here is the detailed content:

New feature:

Bug fix:

Se the status of all the sources: https://github.com/Zapata/bitshares-pricefeed#sources

Any feedback/review welcome!

Zapata added 30 commits June 7, 2018 15:36
Updated CER to 20% in line with wackou's price feed script.
Updated the comments to reflect recent changes.
  - Handle configuration without equities;
  - Handle configuration with only equities.
  - Improve testing.
@clockworkgr
Copy link

Is "BitsharesFeed source" similar to what I've done with the SettleGraphene source?

Overall, I think that the extern/intern/formula stuff is added complexity for no reason.

E.g. My way of calculating Hero is a Hero source that provides Hero/USD through a formula.

And when I request a feed for Hero, I add that source and the USD/BTS from SettleGraphene (which returns current settlement price for USD) only. Thus I only get 1 price which is the correct one.

This allows a simpler way of adding algorithmic feeds (by copying a source template and replacing a calculation) and keeps the pricefeed code cleaner and simpler. Part of the cleanup I want to do is keep only extern from now on.

@Zapata
Copy link
Author

Zapata commented Jun 8, 2018

Yes BitsharesFeed source is the same idea as your SettleGraphene: it returns asset['bitasset_data']['current_feed']['settlement_price'].

I agree formula computation is too complex, not sure we need the ref_asset, I agree with your approach (just compute HERO/USD then let the usual algorithm derive the HERO/BTS).

BitsharesFeed was introduced to rely on other to compute intermediary prices, but if as a publisher you already compute a USD/BTS, it's better to use it instead of the one from the DEX, this will be more consistent. (same discussion here).

@clockworkgr
Copy link

Hi I agree with using the same login for price computation. But I believe HERO price was designed to specifically use the bitUSD settlement price now? Hence why I'm only using that SettleGraphene source for hero rather than the "generic" USD/BTS price reached.

Same goes for Hertz I think

@@ -42,6 +42,11 @@
help="Skip critical feeds",
default=False,
)
@click.option(
"--node",
metavar='<wss://host:port>',
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coool. Didn't know metavar.

@@ -2,14 +2,14 @@
import numpy as num
import time
from pprint import pprint
from math import fabs, sqrt
from math import *
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not an ideal solution. Please define which modules you need when you import them directly.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is related to issue #37.

In this case only sin should be enough.
Unfortunately we don't know what user may need in their formula, that why I used *.
That's why I agree with @clockworkgr approach (and other pricefeed implementations), and use python modules for algorithmic assets instead of the configuration based approach. But I didn't want to change the approach in this pull request.

@@ -98,31 +98,35 @@ def obtain_flags(self, symbol):

# Feed too old
feed_age = self.price_result[symbol]["current_feed"]["date"] if self.price_result[symbol]["current_feed"] else datetime.min
if (datetime.utcnow() - feed_age).total_seconds() > self.assetconf(symbol, "maxage"):
if (datetime.now(timezone.utc) - feed_age).total_seconds() > self.assetconf(symbol, "maxage"):
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why that change?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See issue #57 and this commit

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More specifically utcnow() returns a date with timezone=None, and current_feed.date is, since the last python-bitshares upgrade, with a timezone.

@@ -276,7 +282,7 @@ def derive2Markets(self, asset, target_symbol):
symbol,
target_symbol,
float(self.data[interasset][target_symbol][idx]["price"] * ratio["price"]),
float(self.data[interasset][target_symbol][idx]["price"] * ratio["price"]),
float(self.data[interasset][target_symbol][idx]["volume"] * ratio["price"]),
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice catch!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be fair it's not mine, see #36 . I don't know why @notchxor abandonned his changes.

Original change cherrypicked.

if 'position24' in coin and
int(coin['position24']) <= 11 and
coin['short'] != "BTC"]
for coin in coincap_front[0:11]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make that 11 and the 10 a parameter maybe?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, it should be a named constant. I'll change it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see
e5f2551

import yaml
import math

@pytest.fixture
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sweet. wanted to learn about pytest.fixtures anyways :D

@xeroc
Copy link
Owner

xeroc commented Jun 25, 2018

Excellent work. If you may improve on the comments I made, I am fine merging this in.

@Zapata
Copy link
Author

Zapata commented Jun 25, 2018

Code updated according to comments + spotted an unitialized parameter in Alphavantage source.
If it's fine for you I think it can be merged and we can close the related issues.

@xeroc xeroc merged commit 095ffa4 into xeroc:develop Jun 26, 2018
@xeroc
Copy link
Owner

xeroc commented Jun 26, 2018

Excellent piece of work. Thank you for your contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants