I can get bid and ask data from my market data provider but I want to convert this in OHLC values.
What is the good calculation using bid/ask? I saw in a post that for a specific period:
Open = (first bid + first ask) / 2.
High = Highest bid
Low = Lower ask
Close = (last bid + last ask) / 2
Is it true?
You are getting confused with terminology. In forex:
Ask is the price that you, the trader, can currently buy at.
Bid is the price that you, the trader, can currently sell at.
OHLC are historical prices for a predetermined period of time (common time periods at 1 min, 5 min, 15 min, 30 min, 1 hour, 4 hour, daily and weekly) and are usually used to plot candle stick charts (and tend to be based on the Bid price only).
Open - This is the bid price at the commencement of the time period.
High - This is the highest bid price that was quoted during the time period.
Low - This is the lowest bid price that was quoted during the time period
Close - This is the last bid price at the end of the time period.
Conversion between the two is not always straightforward or even possible. What many beginners (including myself) stumble upon:
Ohlc data represents trades that did actually happen. Bid and ask represent requests for trades that might never happen.
Simplified example:
Let's say investor A wants to sell 100 shares of a specific company for 20$ each, so he places ask(100,20) on the market. Investor B wants to buy 100 shares of the same company, but only wants to pay 18$ each, so he places bid(100,18).
If both are not willing to change their price, no trade will happen and no ohlc data will be generated (if no other trades occur in this timeframe).
Of course, one can assume that if trades happen in a specific time frame, h will be the highest price someone is willing to pay (highest bid) and l will be the lowest price someone is willing to sell for (lowest ask), as those orders have the highest chance of being met. But I think o and c values really depend on which bids/asks actually turned into a trade.
Related
I want to create a stock exchange simulation using C# programming language. But I couldn't decide on how to specify the price of an asset.
For example, the following table is an order book for an asset:
Buy Sell
----------------------------- ----------------------------
ID Time Size Price ID Price Size Time
4 8:00:04 250 100 1 101 750 8:00:01
6 8:00:10 500 100 5 101 500 8:00:05
2 8:00:01 750 97 8 101 750 8:00:30
7 8:00:10 150 96 3 102 250 8:00:02
The simplest order book matching algorithm is a price-time-priority algorithm. That means that the matching priority firstly is price and then time. The participants are rewarded for offering the best price and coming early.
Every asset has a current price in stock exchanges. But how can I calculate the price of this asset? Is there any algorithm for this?
An exchange will usually show the 'top of the book', showing best bid (the highest number someone is willing to buy at) and ask (the lowest price someone is willing to sell at).
Where you see an exchange offering a single price, it is derived in one of two ways:
if there have been recent (valid) trades, then it is the last traded price
otherwise, it is the reference price
What is a Reference Price?
Most equity and derivatives exchanges maintain a reference price for each book. This is used to prevent acceptance of orders which would be too far from the reference price - aka 'extreme trading range'.
Usually the reference price is set to the last traded price during the day, but how is it set in the first place before any trading happens?
The reference price is usually determined after each trading reset (e.g. start of day, start of week or start of a new book) as one of the following in order of precedence:
price discovered during an initial auction period (usually only in equity markets)
if no auction, then last traded (or settled, depending on the market) price
use a price from another market operator running the same book
or the market operator can use it's own 'reasonable' method to determine a reference price, e.g. for an initial listing of a new security
How to apply this?
So if you want to set a new 'current price' in BTC but you don't yet have any trades on your book, then because BTC is already widely traded you can:
use the last price traded on binance for the pair you're running
take a mean or median of last prices from multiple BTC books run by others
manually set some other price you think will attract both buyers and sellers
I want to graph a portfolio of stock trades over a period of say one year.
I will have many trades with many different stocks. The question becomes, what is the best way to calculate the value of the profile over the year.
1) Query for all transactions before or on the start of the period.
2) Calculate their price and totals on that day.
Now, what would be the best method?
Do I loop through each day in the period selected, then find and sum all transactions on a stock before that day.
Loop through all the stocks, sum, store and then do it again for the next day?
How do the pros do this? Curious.
Similarly to what happens in reality, you should go day by day.
You move to the next day only after you summed all the transactions on all stocks at a certain day.
This will allow you to impose portfolio-level restrictions and allocation.
Some examples:
You trade 30 stocks. Capital is equally shared between all stocks. If one stock goes below $5, you don't trade it. Then, you allocate all the capital to the other 29 stocks.
You observe the correlation between the stocks. If 5 stocks are highly correlated, you allocated less capital to each.
You have 30 stocks in your symbol universe, but you only trade up to 10 stocks in parallel, according to relative performance of trades you took on each stock.
This kind of management will be possible only when you calculate all transactions per day before moving to the next.
I'm creating system for a company renting apartments. All pricing setup is based on some periods. For example an apartment in category 'Junior Studio' there are price periods:
30.05.2016 - 31.01.2017: 3000 EUR
01.02.2017 - Infinity: 4000 EUR
There are also additional periods like: taxes, seasonal price(plus/minus some percent value), and fees based on other periods. So prices can vary often, for example:
31.05.2016 - 30.06.2016 (3500EUR because of some seasonal price period)
01.07-31.08.2016 (5000EUR other seasonal price period)
01.09.2016 - 31.01.2017 (3000 EUR)
01.02.2017 - 4000 EUR.
Also, if someone wants to rent an apartment, for example less than 15 days, there is additional fee, let's say 15% - all this is set up dynamically.
Now the problem is on our page we should let user find apartments based on their price. For example some users want to find only apartments where the price varies between 3000 - 4000 EUR and rent an apartment for 6 months. As I said price can change for example 5 times on those periods so I'm looking to calculate an average price.
Have you any idea how implement this algorithm to incorporate all the specified periods? We assume there can be for example 500 possible records so computing this dynamically could probably cause performance issues.
UPDATE
Here is some code to take periods related to one apartment category for one building:
private RentPriceAggregatedPeriodsDto prepareRentPriceAggregator(Long buildingId, Long categoryId, LocalDate dateFrom, LocalDate dateTo, Integer duration) {
List<CategoryPricePeriod> pricePeriods = categoryPricePeriodRepository.findCategoryPricePeriods(buildingId, categoryId, dateFrom, dateTo);
List<SeasonalPricePeriod> seasonalPricePeriods = seasonalPricePeriodRepository.findSeasonalPricePeriods(buildingId, categoryId, dateFrom, dateTo);
List<LastMinuteRatePeriod> lastMinuteRatePeriods = lastMinuteRatePeriodRepository.findLastMinuteRatePeriods(buildingId, categoryId, dateFrom, dateTo);
List<TaxesDefinitionPeriodDto> taxesDefinition = taxesDefinitionService.findTaxPeriodsForBuildingAndCategory(buildingId, categoryId, TaxTypeCode.VAT,
dateFrom, dateTo);
Optional<SurchargePolicy> surcharge = surchargePolicyRepository.findForDurationAndRentalObjectCategoryIds(categoryId, buildingId, duration);
return new RentPriceAggregatedPeriodsDto(pricePeriods, seasonalPricePeriods, lastMinuteRatePeriods, taxesDefinition, surcharge);
}
Based on all those periods I prepare list of unique price periods: dateFrom, dateTo, currency, value. After those steps I have list of unique prices for one category. Then I need to compute how many days of booking is in each of those unique price periods and multiply it, maybe round + multiply by tax and sum it to have final price for booking. Now re-run those steps, let's say, 500 times (multiple categories in multiple buildings).
As mentioned in the comments, averaging 6 numbers 500 times on the fly should not cause any performance issues.
Even then, if you'd want O(1) performance on computation of price (i.e. the calculation should not depend on the number of price switches in the mentioned period), you could preprocess by defining a date as day 0, and computing the amount of total rent that would be required for all days beyond that. When a user requests the average rent between a period, subtract the total rent till day zero from the two days, giving you the rent for the period in between. Dividing this by the number of days will give you the average rent. You can also add suitable multipliers depending on duration of stay (to add the 15% charge), etc. This is similar to finding the sum of values between two indices in an array in O(1). This is not a memory friendly suggestion, although one can modify it to use less memory.
The advantage is that the computation to give results will not depend on the number of price switches. However, every additional change in apartment rents will cause some amount of preprocessing.
I think you actually need two algorithms. One for representing and querying the object price at any given time. And another one for computing the price for renting an object for a given time period.
As for the representation of the object price, you should make a decision about the temporal granularity you want to support, e.g., days or months. Then create a lookup table or a decision tree, a neural network or anything to lookup the price at the given day or month for the given object or object class. You can factor in all the variables you'd like to have in there. If you want to support special prices for renting full calendar months, have another data structure for this different granularity, which you query with months instead of dates.
Then, given a period of time, you need to generate the corresponding series of dates or months, query for the individual daily or monthly prices and then compute the sum to get the total price. If you want to, you can then compute an average daily/monthly price.
I don't think performance will be an issue here. At least no issue you should address before coming up with an actual solution (because, premature optimization). If it is, consider scaling up your database.
I'm currently facing interesting algorithm problem and I am looking for ideas or possible solutions. Topic seems to be common so maybe it's known and solved but I'm unable to find it.
So lets assume that I'm running shop and
I'm making lottery for buying customers. Each time they buy something they can win prize.
Prizes are given to customers instantly after buying.
I have X prizes and
I will be running lottery for Y days
Paying customer (act of buying, transaction) should have equal chance to win prize
Prizes should be distributed till last day (at last day there should be left some prizes to distribute)
There can not be left prizes at the end
I do not have historical data of transactions per day (no data from before lottery) to estimate average number of transactions (yet lottery could change number of transactions)
I can gather data while lottery is running
It this is not-solvable, what is closest solution?
Instant prize distribution have to stay.
Possible Solution #1
Based on #m69 comment
Lets says there are 6 prizes (total prizes) and 2 days of lottery.
Lets define Prizes By Day as PBD (to satisfy requirement have prizes till last day).
PBD = total prizes / days
We randomly choose as many as PBD events every day. Every transaction after this event is winning transaction.
Can be optimized to no to use last hour of last day of lottery to guarantee giving away all of prizes.
Pluses
Random. Simple, elegant solution.
Minuses
Seems that users have no equal chance to win.
Possible Solution #2
Based on #Sorin answer
We start to analyze first time frame (example 1 hour). And we calculate chance to win as:
where:
Δprizes = left prizes,
Δframes = left frames
What you're trying to do is impossible. Once you've gave away the last prize you can't prove any guarantee for the number of customers left, so not all customers will have equal chance to win a prize.
You can do something that approximates it fairly well. You can try to estimate the number of customers you will have, assume that they are evenly distributed and then spread the prizes over the period while the contest is running. This will give you a ratio that you can use to say if a given customer is a winner. Then as the contest progresses, change the estimates to match what you see, and what prizes are left. Run this update every x (hours/ minutes or even customer transaction) to make sure the rate isn't too low and every q prizes to make sure the rate isn't too high. Don't run the update too often if the prizes are given away or the algorithm might react too strongly if there's a period with low traffic (say overnight).
Let me give you an example. Say you figure out that you're going to see 100 customers per hour and you should give prizes every 200 customers. So roughly 1 every 2 hours. After 3 hours you come back and you see you saw 300 customers per hour and you've given out 4 prizes already. So you can now adjust the expectation to 300 customers per hour and adjust the distribution rate to match what is left.
This will work even if your initial is too low or too high.
This will break badly if your estimate is too far AND you updates are far in between (say you only check after a day but you've already given away all the prizes).
This can leave prizes on the table. If you don't want that you can reduce the amount of time the program considers the contest as running so that it should finish the prizes before the end of the contest. You can limit the number of prizes awarded in a given day to make the distribution more uniform (don't set it to X/Y, but something like X/Y * .25 so that there's some variation), and update the limit at the end of the day to account for variation in awards given.
I'm going to be starting a banner-rotation script soon and I'm getting a bit perplexed over how exactly to develop it. Suppose a client asks for
"10,000 impressions in the next 10 days for $10,000 dollars."
Another client asks for
"1,000 impressions for $100 dollars."
And a third asks for
"1,000 clicks or 10,000 impressions for $5,000."
How exactly do I determine which banner to show upon a page-request? How do I weigh one against another? Clearly the first request is rather important, as I'm expected to serve a set number of impressions within a time-window.
The second client is not nearly as important, as they don't care about a time-window, they just want some face-time.
And the last client wants to place an n or m restraint on the impressions/clicks, making matters slightly more difficult.
I'm already pretty confident that I'll need to abstract some weight from these scenarios to determine who gets the most attention. My question is what type of algorithm could handle this, and secondly how could I serve up banners by weight without always serving up the most important banner with each request?
The difficulty comes from the time constraint more than anything else. I would divide anyone's priority who did not specify a time constraint by 365 (a year), and then use time as part of the weight factor. So:
Client 1 priority: 10000/10 = 1000
Client 2 priority: 1000/365 ~ 3
Client 3 priority: 10000/365 ~30
That should get you a fairly decent indicator of priority. Now, you can't mix and match impressions and clicks can you? They either go the impression route or the click route. Seeing as you cannot control click, but you can control impressions (at least, moreso than clicks), I would weigh it according to impressions.
Use a random-number generator to pick which ad to show, and weight it with a priority for each ad. Set the weighting factor higher for clients that want more impressions or have a deadline. You can increase weighting factor if the time is almost up.
Once a client hits their requested impressions, drop weighting to 0 to prevent their ad from showing.
Default weighting could be 1 or so, with clients being allowed to pay extra to increase priority (without telling them the mechanics -- bill it as "premium" placement, etc).
Edit: weighting details
You can make this as simple or complex as you like, but a basic version would include the following terms:
weight is 0 if ad has reached purchased impressions/clicks
base weighting (1.0 probably)
multiply weight by impressions_remaining / TOTAL impressions remaining for all clients
add a small constant if remaining impressions/clicks is small -- ensures they get the last few ones needed to finish the account
for deadline clients: add term for (remaining impressions/purchased impressions)/(time left/total time)
The deadline clients should be capped at 90% of all page displays or something to ensure they don't outcompete others. The last term gives the "urgency" for deadline clients -- it goes to infinity as deadline hits, so you should put a condition on the remaining time piece to prevent problems with this.
Microsoft Commerce Server contains a NOD algorithm
(see http://msdn.microsoft.com/en-us/library/ms960081%28v=cs.70%29.aspx
and http://msdn.microsoft.com/en-us/library/ee825423%28v=cs.10%29.aspx )
I've used derived versions of this formula in 3 different ad servers, which turned out to work nice for my conditions.
The basic formula regarding your situation uses a variable called NOD, short for "Need of Delivery". At any given time, the "basic" NOD formula of a banner is:
NOD=(Remaining Events / Total Events Requested) * (Total Runtime /
Remaining Runtime)
Note that "Events" is a general term, which may represent impressions, clicks, conversions, etc. depending on your system.
The equation states that all banners start with the initial value of 1.0 to their lives, because (e / e) * (t / t) = 1.0
A higher-than-1 NOD value means you are behind your schedule, while a NOD between 0 and 1 generally means that you have displayed the banner "too fast". Values between 0.9 and 1.2 are generally in acceptable range (this is not a technical range, rather a business experience).
As long as the serving ratios match duration ratios, values stay around 1.0.
For a specific ad slot, the algorithm checks the NODs of all available banners targettable on the slot. Suppose you have 3 banners available on a slot, with NOD values 0.6, 1.35 and 1.05, which add up to 3.0. Then relative probabilities of each banner to be displayed become 20%, 45% and 35% in order [ 0.6 / (0.6 + 1.35 + 1.05)] = 20%
The algorithm uses weighted probability distribution, which means that even the banner with the least NOD value has the chance to be displayed. While the basic formula uses this approach, business decisions generally always forced me to implement algorithms favoring the urgent NOD values more than the original formula. So, I took the base NODs and multiplied them with themselves. In the same example, probabilities become 11%, 55,5%
and 33,5% in order.
For your condition, you might consider changing the formula a little bit to serve your needs. First to be able to compare the income you will earn by displaying a banner, you should convert all display types (impression, click, action, etc) to a common eCPM value. Then you might use this eCPM as a multiplier to the original equation.
Calculating eCPM (effective CPM) might be tricky for not-yet-published campaigns, in this case you should use historical data.
Let me explain this part a little bit more: When trying to compare the probable income you will earn by "displaying" a single banner, you don't need to compare impression based budgets. For click based budgets, you should use historical CTR value to guess "how many impressions does my system need to serve to get X clics". A more advanced algorithm might utilize "how many impressions does my system need to serve to get a campaign in X category, in y inventory".
Then your final equation becomes:
NOD = eCPM * (Remaining Events / Total Events Requested) * (Total
Runtime / Remaining Runtime)
You can always consider using powers of eCPM to compare the results. Like my way of changing the original formula to favor more urgent campaigns, you might favor "more paying" campaigns.
I really like AlbertoPL's time-based approach, but he doesn't factor in the clicks. Its easy to demonstrate pathological cases where clicks are relevant:
Client A offers $1000 for 1 click or 10,000 impressions
Client B offers $1000 for 5000 clicks or 10,000 impressions.
Any reasonable person would give the 1-click guy higher priority. The calculation is actually pretty trivial: assume your click-through is 100 impressions per click.
Client A wants 10,000 impressions or 1 click, so we require a bare minimum of 100 impressions to get paid. At a cost of $1000 per 100 impressions, you can figure that your client is willing to pay $10/impression.
Client B wants 10,000 impressions or 5000 clicks. 5000 clicks requires 500,000 impressions, we'll clearly meet the 10,000 impression mark before then, so we assume the client is really offering to pay $1000 for 10,000 impressions, or $0.10/impression.
We maximize revenue by maximizing our $$$$$/impression, so client A takes priority. Let's use the figures provided in the OP:
Client 1:
10,000 impressions in the next 10 days for $10,000 dollars
= minimum of 10,000 impressions * $1/impression / 10 days
= $1000/day
Client 2:
1,000 impressions for $100 dollars
= minimum of 1,000 impressions * $.01/impression / 365 days
= $0.27/day.
Client 3:
1,000 clicks or 10,000 impressions for $5000
= min(100,000 impressions to get 1,000 clicks, 10,000 impressions) = 10,000 impressions for $5000
= minimum of 10,000 impressions * $0.5/impression / 365
= $13.7/day.
Clients take priority based on how much they pay per day.