|
Hi,
Please take a look at this chart, it's the overnight session of AAPL and it shows something I do not understand. I can't think where else to ask to get a knowledgable response.
https://imgur.com/oM7lyJN
If you look on the right of the image you see where I have annotated the current BID and ASK prices. As you can see the trades appear to be occurring near the BID price and nothing is showing at the ask price level. The spread is consistently very wide at around 30c at the moment. The price level shown suggests the few trades that are happening are occurring at the BID price, so I would expect that these are people selling at the bid and not buying at the ASK. There appear to be no trades occurring at the ASK.
If that is the case then why is price going up? Is there another exchange with a narrower BID/ASK spread? Are these annotations correct?
Any insight is appreciated. It seems I have a fundamental misunderstanding of how the markets function. If so, then could you recommend a book or webpage that would help me understand the mechanics of this behaviour?
Many thanks for your help
Kind Regards,
-Jason
|
|
I get the feeling I'm not the first person who's asked you this :)
OK thats no problem, thanks for your help
Kind Regards,
-Jason
|
|
Hi,
Is there any way to refer to yesterdays close price in an intraday PCF ?
Perhaps with somthing like this ?
Closing price on 1/20/06
C'01/20/06'
Its easy on the daily chart but I cant think how to do it on an intraday chart (1min for example)
the other one I would like is todays open price.
Thanks for your help
-Jason
|
|
Hi Bruce, It seems like calculating the correct VWAP value would be very useful to a lot of people - the version of VWAP that is provided in TC2000 is inaccurate, its value varies depending on the time frame. So its normally wrong.
Is it not possible for the worden servers to record the VWAP for the data as it streams in?
I'd like to be able to refer to it in PCFs as well..
Kind Regards,
-Jason
|
|
Hi Bruce, FYI
I ran another Heartbeat test last week - from 18th till 22nd. It seemed to be fine until Friday when I recorded 3 failures. 3 missing alerts recorded by a repeat cross up/cross down with more than 10 minutes since preceeding alert. I think this is an improvement from the earlier loss rate, but I'm not sure if its just lucky sampling.
I'm tempted to run 5 copies of the test to 5 different email addresses to get better confidence.
I may set this up later on.
Here are some more details.
The alerts were sent (Easter standard time)
22 Feb 2013, 09:45
22 Feb 2013, 11:15
22 Feb 2013, 15:43
Busy times of day?
Alert log seems ok - just missing emails I think
Whilst writing this I notice that there is missing alert status on FDO at 09:38 and 09:33
When I look in my Alert Console I see that FDO is not present (so I probably cancelled the alert) when I click the "Old Items" button I dont see any FDO alerts at all
At the top of the list I do see this
Clicking the chart button on each in turn shows the following
None of them were for FDO and the timeframe kept changing with each one shown.
I can tell from my records that the FDO alert was a Trend Line alert on the Hourly chart with a Custom PCF Channel indicator (Right clicking a Trendline and selecting "Set Alert")
Indicator Formula Line
C
Channel WidthFormula
(((MAXH2 - MINL2)+(MAXH2.1 - MINL2.1)+(MAXH2.2 - MINL2.2)+(MAXH2.3 - MINL2.3)+(MAXH2.4 - MINL2.4)+(MAXH2.5 - MINL2.5)+(MAXH2.6 - MINL2.6)+(MAXH2.7 - MINL2.7)+(MAXH2.8 - MINL2.8)+(MAXH2.9 - MINL2.9)+(MAXH2.10 - MINL2.10)+(MAXH2.11 - MINL2.11)+(MAXH2.12 - MINL2.12)+(MAXH2.13 - MINL2.13)+(MAXH2.14 - MINL2.14)+(MAXH2.15 - MINL2.15)+(MAXH2.16 - MINL2.16)+(MAXH2.17 - MINL2.17)+(MAXH2.18 - MINL2.18)+(MAXH2.19 - MINL2.19)+(MAXH2.20 - MINL2.20)+(MAXH2.21 - MINL2.21)+(MAXH2.22 - MINL2.22)+(MAXH2.23 - MINL2.23)+(MAXH2.24 - MINL2.24)+(MAXH2.25 - MINL2.25)+(MAXH2.26 - MINL2.26)+(MAXH2.27 - MINL2.27)+(MAXH2.28 - MINL2.28)+(MAXH2.29 - MINL2.29)+(MAXH2.30 - MINL2.30)+(MAXH2.31 - MINL2.31)+(MAXH2.32 - MINL2.32)+(MAXH2.33 - MINL2.33)+(MAXH2.34 - MINL2.34)+(MAXH2.35 - MINL2.35)+(MAXH2.36 - MINL2.36)+(MAXH2.37 - MINL2.37)+(MAXH2.38 - MINL2.38)+(MAXH2.39 - MINL2.39)+(MAXH2.40 - MINL2.40)+(MAXH2.41 - MINL2.41)+(MAXH2.42 - MINL2.42)+(MAXH2.43 - MINL2.43)+(MAXH2.44 - MINL2.44)+(MAXH2.45 - MINL2.45)+(MAXH2.46 - MINL2.46)+(MAXH2.47 - MINL2.47)+(MAXH2.48 - MINL2.48)+(MAXH2.49 - MINL2.49))/50)*(0.05 + (0.6 * exp (-1*((1-(((((MAXH2 - MINL2)+(MAXH2.1 - MINL2.1)+(MAXH2.2 - MINL2.2)+(MAXH2.3 - MINL2.3)+(MAXH2.4 - MINL2.4)+(MAXH2.5 - MINL2.5)+(MAXH2.6 - MINL2.6)+(MAXH2.7 - MINL2.7)+(MAXH2.8 - MINL2.8)+(MAXH2.9 - MINL2.9)+(MAXH2.10 - MINL2.10)+(MAXH2.11 - MINL2.11)+(MAXH2.12 - MINL2.12)+(MAXH2.13 - MINL2.13)+(MAXH2.14 - MINL2.14)+(MAXH2.15 - MINL2.15)+(MAXH2.16 - MINL2.16)+(MAXH2.17 - MINL2.17)+(MAXH2.18 - MINL2.18)+(MAXH2.19 - MINL2.19)+(MAXH2.20 - MINL2.20)+(MAXH2.21 - MINL2.21)+(MAXH2.22 - MINL2.22)+(MAXH2.23 - MINL2.23)+(MAXH2.24 - MINL2.24)+(MAXH2.25 - MINL2.25)+(MAXH2.26 - MINL2.26)+(MAXH2.27 - MINL2.27)+(MAXH2.28 - MINL2.28)+(MAXH2.29 - MINL2.29)+(MAXH2.30 - MINL2.30)+(MAXH2.31 - MINL2.31)+(MAXH2.32 - MINL2.32)+(MAXH2.33 - MINL2.33)+(MAXH2.34 - MINL2.34)+(MAXH2.35 - MINL2.35)+(MAXH2.36 - MINL2.36)+(MAXH2.37 - MINL2.37)+(MAXH2.38 - MINL2.38)+(MAXH2.39 - MINL2.39)+(MAXH2.40 - MINL2.40)+(MAXH2.41 - MINL2.41)+(MAXH2.42 - MINL2.42)+(MAXH2.43 - MINL2.43)+(MAXH2.44 - MINL2.44)+(MAXH2.45 - MINL2.45)+(MAXH2.46 - MINL2.46)+(MAXH2.47 - MINL2.47)+(MAXH2.48 - MINL2.48)+(MAXH2.49 - MINL2.49))/50) - ( (ABS(H>MAXH2.1) * (H-MAXH2.1)) + (ABS(L<MINL2.1)*(MINL2.1-L)) )) / (((MAXH2 - MINL2)+(MAXH2.1 - MINL2.1)+(MAXH2.2 - MINL2.2)+(MAXH2.3 - MINL2.3)+(MAXH2.4 - MINL2.4)+(MAXH2.5 - MINL2.5)+(MAXH2.6 - MINL2.6)+(MAXH2.7 - MINL2.7)+(MAXH2.8 - MINL2.8)+(MAXH2.9 - MINL2.9)+(MAXH2.10 - MINL2.10)+(MAXH2.11 - MINL2.11)+(MAXH2.12 - MINL2.12)+(MAXH2.13 - MINL2.13)+(MAXH2.14 - MINL2.14)+(MAXH2.15 - MINL2.15)+(MAXH2.16 - MINL2.16)+(MAXH2.17 - MINL2.17)+(MAXH2.18 - MINL2.18)+(MAXH2.19 - MINL2.19)+(MAXH2.20 - MINL2.20)+(MAXH2.21 - MINL2.21)+(MAXH2.22 - MINL2.22)+(MAXH2.23 - MINL2.23)+(MAXH2.24 - MINL2.24)+(MAXH2.25 - MINL2.25)+(MAXH2.26 - MINL2.26)+(MAXH2.27 - MINL2.27)+(MAXH2.28 - MINL2.28)+(MAXH2.29 - MINL2.29)+(MAXH2.30 - MINL2.30)+(MAXH2.31 - MINL2.31)+(MAXH2.32 - MINL2.32)+(MAXH2.33 - MINL2.33)+(MAXH2.34 - MINL2.34)+(MAXH2.35 - MINL2.35)+(MAXH2.36 - MINL2.36)+(MAXH2.37 - MINL2.37)+(MAXH2.38 - MINL2.38)+(MAXH2.39 - MINL2.39)+(MAXH2.40 - MINL2.40)+(MAXH2.41 - MINL2.41)+(MAXH2.42 - MINL2.42)+(MAXH2.43 - MINL2.43)+(MAXH2.44 - MINL2.44)+(MAXH2.45 - MINL2.45)+(MAXH2.46 - MINL2.46)+(MAXH2.47 - MINL2.47)+(MAXH2.48 - MINL2.48)+(MAXH2.49 - MINL2.49))/50)))))))
When I look in the Alert Log for those times I do find matching FDO alerts - I opened both chart windows for them - doesnt look right
I think this should be logged as a new bug. Probably not a high priority since it doesnt cause any catastrophies !
Strange how there were no missing alerts all week and then 3 on Friday - and all at relatively 'busy' times of day. And all 3 were just missing emails - the alert system seems to have recorded the alert but no email has been received.
I'll set up another 4 email addresses and start another 4 Heartbeats to try to get better coverage
I hope this is helpful
-Jason
|
|
OK thats great, Thank you !
-Jason
|
|
Interesting.. It could be related to load levels.. I've noticed problems most often around 1pm EST. Not ran tests to confirm that though.. But I wrote a program that warns me when the alert system loses alerts. And it normally goes off when I'm making dinner! (I'm in the UK)
The most frequent issue I see is that the alert is present in the TC2000 alert log - but no email is sent. And this is happening with a failry simple alert - the example here is the "Heartbeat".. Its just a Price alert drawn on a MACD chart. 1 minute timeframe. Price Crossing alert set for every 5 minutes. Its not a slow PCF.
My belief is that this i just a "straight-forward" programming bug. A corner case that happens quite rarely. Perhaps made worse when the system is heavily loaded.. Probably in the code that decides if an alert should be raised - and a corresponding email sent.. Maybe some kind of race condition.. Something makes it raise the alert but not send the email. If I could get my hands on the code I'd be able to trace it back !
Or its a glitch in the mail server that makes it throw away some emails.. There are other bugs that I've documented - but this is the most common.. Sometimes the alert doesnt even appear in the alert log.. Maybe this is also load related.
I dont like the thought of having to consider complexity when creating alerts.. And I dont want them to fail at certain times of day.. I want them to work..
If it is a matter of computing power - then can we have new "Ultra platinum" service ?? I dont mind paying more if it means the alerts system is reliable - regardles of how many alerts are running. and how complex they are. If its a matter of paying more then thats not a problem
And I wish that the 500 bar limitation was gone.. Again, I'd happily pay more to get 2000 bars.. Or 5000 bars... The other major thing on my wish list is to be able to have moving averages (or PCFs) described on daily - or weekly charts - but visible right down to the 1 minute chart.. If the 200 day moving average is 2c below the current price - I'd like to know it ! And write alerts that can interact with it on the 1 minute chart ! The only way to do this at the moment is to manually draw trend lines and update them manually. Which isnt a reasonable solutions.
Wouldnt it be great if we coud create line-segments (or splines) that attach to pcfs on the higher timeframes. So they can be seen - and interacted with on the lower timeframes..
And I've also noticed the bugs related to the opening 15 minutes - But they dont seem to impact the alert bugs that I've been witnessing.. I haven't analysed them as closely as you have though... I normally close and restart TC2000 whenever it messes up.. I've got too many other things to worry about without bugging support everytime I see the opening session messed up :)
The other bug I've seen there is where the bid/ask markers stop moving. the chart freezes when the market opens.. its not pretty..
anyway - lets see what progress is made on the alerts system
I've devoted so much time to logging these bugs and reporting these issues that I'd really love to get some kind of resolution to the issues..
Jason
|
|
OK so I ran the test this afternoon and I've sent you an emial via Markus in the worden support department. Looks like there definitely is a problem. 3 alerts went missing from the test.... but they are listed in the TC2000 alert log. Nothing accessed the email account during the test period - and you can see this in the bottom right of the gmail images where it says "last account activity 18th Jan".. I also confirmed that the test itself did not delete any emails..
I put a lot more detail in my email.
Kind Regards,
-Jason
|
|
One last thing.. Its occurred to me that another possibility is that the OpenPOP library somehow manages to delete emails. I dont think this is the case.. In fact from reading the documentation it sounds like you need to send very specific commands in order to delelte emails.. But since we are trying to rule everything out then it should be considered.
To test for this its best to allow a large number of emails to build up.. Manually verify the count in the gmail.com web interface. Then run the GmailAlertScanner to check them all at once. It would only take a few seconds to check a few days worth of emails. And then verify that the count of emails in gmail hasnt changed.
To test for this I now have a new heartbeat alert sending emails to a completely fresh gmail address specifically for this purpose. I'll let it build up a few days worth of emails and then run a test.. I'll let you know the results.
-Jason
|
|
ok great, thanks Bruce :)
|