The plots of the main indicators (running means) look displaced from the actual price plots. The reason is that a mean price that is computed from data up to a certain time is "logically located" at some earlier time
That's how they are defined (and used everywhere), so that's also how they are plotted. If you shift the plots backwards in time its no longer what a trader would expect to see when he is told that this is a simple moving average (SMA) or exponential moving average (EMA), it would be an entirely different indicator. It would be possible but then it wouldn't be the good old well known SMA or EMA anymore. 
Topic: BitcoinWisdom.com - Live Bitcoin/LiteCoin Charts - page 112. (Read 502630 times)
Another observation:
The plots of the main indicators (running means) look displaced from the actual price plots. The reason is that a mean price that is computed from data up to a certain time is "logically located" at some earlier time, which is the mean of the weight indices.
Specifically, suppose a mean price V is computed by V = SUM{ W(k)*P(t-k) : k in 0..N-1 }, where P(i) is the price at time i and W(0..N-1) are weights that add to 1. Then V should be plotted at time t - m where m = SUM{ W(k)*k : k in 0..N-1 }.
If the weights are positive (say, uniform 1/N or exponentially decreasing) then m is positive, so the plot should be displaced to the right. In that case, the indicator V is in fact using data up to time t to "predict" a price in the past, namely P(t-m).
To get a true predictor for the price P(t+1), one must use positive and negative weights that still add to 1 but are such that the mean index m, as defined above, is -1 For example W(0)=2 and W(1)=-1 will give the simplest (two-point) linear extrapolation predictor. The mean V computed with these weights should then be plotted at time t+1 rather than t.
The plots of the main indicators (running means) look displaced from the actual price plots. The reason is that a mean price that is computed from data up to a certain time is "logically located" at some earlier time, which is the mean of the weight indices.
Specifically, suppose a mean price V is computed by V = SUM{ W(k)*P(t-k) : k in 0..N-1 }, where P(i) is the price at time i and W(0..N-1) are weights that add to 1. Then V should be plotted at time t - m where m = SUM{ W(k)*k : k in 0..N-1 }.
If the weights are positive (say, uniform 1/N or exponentially decreasing) then m is positive, so the plot should be displaced to the right. In that case, the indicator V is in fact using data up to time t to "predict" a price in the past, namely P(t-m).
To get a true predictor for the price P(t+1), one must use positive and negative weights that still add to 1 but are such that the mean index m, as defined above, is -1 For example W(0)=2 and W(1)=-1 will give the simplest (two-point) linear extrapolation predictor. The mean V computed with these weights should then be plotted at time t+1 rather than t.
Any chance of getting a response to my post?
I find it hard to believe that I'm the only one who'd like to see this implemented?
I think it is helpful too. the feature will be supported.I find it hard to believe that I'm the only one who'd like to see this implemented?
.
.
.
If there was one "improvement" or enhancement I could suggest though, that would be to address those miniscual "noise" bids/offers that traders make to push other serious bids/offers off of the visible view of 15 bids/offers. You know what I'm referring to?
My suggestion is to make their miniscual bids/offers disappear completely by having a checkbox for example with "show only bids/offers > 1", "show only bids/offers > 10 etc..
If a particular chechbox is checked, then you remove all bids/offers below that particular volume, and in this way only bids/offers of the relative minimum volume magnitude are shown.
I think this would be a wonderful enhancement to this already amazing app! And it would also go a long way in neutralising the sabotage attempts of those who attempt to "hog" the bid/offer view windows with their pathetically small volume noise.
Let's face it - if one wants to buy or sell 1000 litecoins - for example - you really DO NOT want to see consecutive bids/offers for 0.0001 ltc - 0.00001 cent apart - being shown and thereby hiding all the serious volumes on offer below that do you?
I know i certainly don't
.
.
If there was one "improvement" or enhancement I could suggest though, that would be to address those miniscual "noise" bids/offers that traders make to push other serious bids/offers off of the visible view of 15 bids/offers. You know what I'm referring to?
My suggestion is to make their miniscual bids/offers disappear completely by having a checkbox for example with "show only bids/offers > 1", "show only bids/offers > 10 etc..
If a particular chechbox is checked, then you remove all bids/offers below that particular volume, and in this way only bids/offers of the relative minimum volume magnitude are shown.
I think this would be a wonderful enhancement to this already amazing app! And it would also go a long way in neutralising the sabotage attempts of those who attempt to "hog" the bid/offer view windows with their pathetically small volume noise.
Let's face it - if one wants to buy or sell 1000 litecoins - for example - you really DO NOT want to see consecutive bids/offers for 0.0001 ltc - 0.00001 cent apart - being shown and thereby hiding all the serious volumes on offer below that do you?
I know i certainly don't
Thank you so much! I look very much forward to its implementation ...
now I've changed it to break price.
Thanks! My "vertically shift" suggestion was to format it as followsexcept with smaller dots (or dashes) between the two columns...
As for which end of the interval is open or closed: it will be confusing to readers either way, so it is indifferent.
The Salomonic solution is to split orders that are eactly equal to the break price (say 4850) and count half their volume on each side of it (half above and half below 4850). But this solution may be even more confusing to readers...
However, the criterion should be symmetric around the spread, since one usually reads the asks upwards and the bids downwards.
Thanks again, and all the best.
Add option is much more complex. now I've changed it to break price.
Great! This was fast! Get this man another drink!(sent)
Why is the current price shown actually the last trade that was executed? The current price on a chart would usually be the mid point between best bid and best ask on the order book, and so a 0.0001 trade $10 away from best wouldn't influence the price displayed on the chart.
Cheers,
I'm afraid not. Also the price will be display on tab title. I think the closing price is better. especially for panic sell/buy. Cheers,
and count half their volume on each side of it (half above and half below 4850). But this solution may be even more confusing to readers...
Yes, this would be really confusing. Now if I see "850 46" I can go ahead and buy 46@850 and eat this wall precisely and completely without anything left.
now I've changed it to break price.
Thanks! My "vertically shift" suggestion was to format it as follows
except with smaller dots (or dashes) between the two columns...
As for which end of the interval is open or closed: it will be confusing to readers either way, so it is indifferent.
The Salomonic solution is to split orders that are eactly equal to the break price (say 4850) and count half their volume on each side of it (half above and half below 4850). But this solution may be even more confusing to readers...
However, the criterion should be symmetric around the spread, since one usually reads the asks upwards and the bids downwards.
Thanks again, and all the best.
Add option is much more complex. now I've changed it to break price.
Great! This was fast! Get this man another drink!(sent)
Why is the current price shown actually the last trade that was executed? The current price on a chart would usually be the mid point between best bid and best ask on the order book, and so a 0.0001 trade $10 away from best wouldn't influence the price displayed on the chart.
Cheers,
Cheers,
I still prefer the consistency
But as it is now it is inconsistent, the ask is treated different than the bid. Bid shows correctly the amount laying at the level and in front of it, ask is showing the amount laying behind the level. Traders are normally interested in the size of a "wall" at a certain level and that is the volume at this level including the orders in front of it. "Top of the book" on the ask side is the smallest ask while top of the book on the bid side is the highest bid, the sort order is inverted (relative to the top of the book) and then naturally "in front of a level" means the usage of floor() on the bid side and ceil() on the ask side. This is the only way to achieve symmetry and consistency. Please reconsider your decision, it would be a great usability improvement for us traders if the ask side were grouped the same way as the bid side.So it won't be changed, maybe would be an option.
Yes, please consider that option and maybe also consider making it the default option (and then eventually you might also consider removing the old option as it makes no sense anyways)It was talked several months ago, I still prefer the consistency to consider it is break or not.
The graphic looks like[...]
So it won't be changed, maybe would be an option.
Why not shift the price column down by half a line? Then it would look sort of like thisThe graphic looks like[...]
So it won't be changed, maybe would be an option.
4900 -
653
4850 -
233
4800 -
25
4778.22
12
4750 -
63
4700 -
423
4650 -
1024
except that it would be squeezed vertically so that both columns are single-spaced.
[/quote]
The mode you wanted is
---- 4900
| 164 (4850,4900]
---- 4850
| 132 (4800,4850]
---- 4800
| <- Current price 4823
---- 4800
| 78 [4750,4800)
---- 4750
| 122 [4700,4750)
---- 4700
or
---- 4900
| 164 (4850,4900]
---- 4850
| 132 (4800,4850]
| <- Current price 4823
| 78 [4750,4800)
---- 4750
| 122 [4700,4750)
---- 4700
depends on 4850 or 4800 used.
The second mode looks no problem. just the brain need think in other way. the number beside 4850 means the sum of volume less and equal 4850 instead of think it's always the amount greater or equal. or think it is break price instead of axis price.
I still prefer the consistency
But as it is now it is inconsistent, the ask is treated different than the bid. Bid shows correctly the amount laying at the level and in front of it, ask is showing the amount laying behind the level. Traders are normally interested in the size of a "wall" at a certain level and that is the volume at this level including the orders in front of it. "Top of the book" on the ask side is the smallest ask while top of the book on the bid side is the highest bid, the sort order is inverted (relative to the top of the book) and then naturally "in front of a level" means the usage of floor() on the bid side and ceil() on the ask side. This is the only way to achieve symmetry and consistency. Please reconsider your decision, it would be a great usability improvement for us traders if the ask side were grouped the same way as the bid side.So it won't be changed, maybe would be an option.
Yes, please consider that option and maybe also consider making it the default option (and then eventually you might also consider removing the old option as it makes no sense anyways)
It was talked several months ago, I still prefer the consistency to consider it is break or not.
The graphic looks like[...]
So it won't be changed, maybe would be an option.
[/quote]
Why not shift the price column down by half a line? Then it would look sort of like this
4900 -
653
4850 -
233
4800 -
25
4778.22
12
4750 -
63
4700 -
423
4650 -
1024
except that it would be squeezed vertically so that both columns are single-spaced.
The graphic looks like[...]
So it won't be changed, maybe would be an option.
[/quote]
Why not shift the price column down by half a line? Then it would look sort of like this
4900 -
653
4850 -
233
4800 -
25
4778.22
12
4750 -
63
4700 -
423
4650 -
1024
except that it would be squeezed vertically so that both columns are single-spaced.
are there any plans to add ablility to save lines/fib levels/fans for registered/pro users?
4850 means the sum amount of 4850 to 4899.999999
This is quite counterintuitive, this would also have been my next feature request. It should be displayed in a more symmetrical manner: asks between (and including) 4850.00001 and 4900.00000 should be summarized under 4900.
if on the bid side it reads
4800 142
then this means 142 BTC must be sold to break 4800
so consequently if on the ask side it reads
4900 132
it should also mean the same: 132 must be bought to break 4900
and not 132 must be bought to break 4949.9999 (which is a very odd number)
Currently its quite cumbersome to read the ask side, one has to add 50 (or 5) to the number and even then it includes only the orders that are lying in front of this level and omits the ones that are at exactly this level. I would be very thankful if this could be changed, this is the last and only remaining tiny little annoyance that separates this otherwise brilliant website from true and universal perfection. I will have no more reason to complain from the moment on this becomes implemented.
The graphic looks like
---- 4900
| 164 [4850,4900)
---- 4850
| 132 [4800,4850)
| <- Current price 4823
---- 4800
| 78 [4750,4800)
---- 4750
| 122 [4700,4750)
---- 4700
So it won't be changed, maybe would be an option.
Currently its quite cumbersome to read the ask side, one has to add 50 (or 5) to the number and even then it includes only the orders that are lying in front of this level and omits the ones that are at exactly this level. I would be very thankful if this could be changed, this is the last and only remaining tiny little annoyance that separates this otherwise brilliant website from true and universal perfection. I will have no more reason to complain from the moment on this becomes implemented.
nice find!
Hi, can we have a BTCLTC kraken on your site? there are already BTCEUR and LTCEUR from kraken. And BTCLTC volume is already as high as LTCEUR.
any news about that? from technical point of view it should be a piece of cake as you already have two currency pairs from kraken.besides BTCLTC would be the first such pair on your platform
Also that BTCLTC is different from LTCBTC I see more as an advantage than disadvantage.
Anyway, lets just wait for more volume, kraken is the highest quality market at the moment so it is just a matter of time
Regards
4850 means the sum amount of 4850 to 4899.999999
This is quite counterintuitive, this would also have been my next feature request. It should be displayed in a more symmetrical manner: asks between (and including) 4850.00001 and 4900.00000 should be summarized under 4900.
if on the bid side it reads
4800 142
then this means 142 BTC must be sold to break 4800
so consequently if on the ask side it reads
4900 132
it should also mean the same: 132 must be bought to break 4900
and not 132 must be bought to break 4949.9999 (which is a very odd number)
Currently its quite cumbersome to read the ask side, one has to add 50 (or 5) to the number and even then it includes only the orders that are lying in front of this level and omits the ones that are at exactly this level. I would be very thankful if this could be changed, this is the last and only remaining tiny little annoyance that separates this otherwise brilliant website from true and universal perfection. I will have no more reason to complain from the moment on this becomes implemented.
You could use CandleStickHLC instead of CandleStick if want shows continuously.
Oops, thanks!Jump to: