Yeah I guess...
It's definitely different these days, where you can get 256GB of DDR4 3200 ECC for ~ 1,000 USD.
Just theorizing out loud. It was as always a head-scratcher to me, like not being able to have a function like "EditPrice("Close", BarIndex, NewPrice);" as an example for changing vast internal price datasets for things like let's say splits, dividends, futures roll back-adjustments, bad tick fixing et al. Instead of having to export data, edit it and then re-import it.
Happy St Patrick's Day.
That is incorrect. You don't need to (and should not) EXPORT anything. To fix one bar, just import ONE quote that needs fixing. AmiBroker will replace given bar with corrected amount leaving the other data untouched.
Understood on the pre-fetch subject. We'll I'm re-considering my statement on editing internal data with a function, unless it can be quickly undone. It would be like letting people play with fire.
So regarding just importing, if we are talking about tick databases from 1980, 1 minute databases across 40k symbols back to 2005, then when you have to do a split adjustment, dividend adjustment, or an adjustment for a continuous back or split adjusted futures dataset then almost ALL prices would have to be exported (assuming it didn't exist in ASCII outside of AB) then adjusted and re-imported.
I know if it was one singular price it would be fast just to import over it .
I used green shorts instead of pants because I'm only half Irish.
You can do adjustments using Symbol->Split without exporting/reimporting.
If you need automation, I can add automation for adjustments via OLE interface.
That would be cool and allow quite a bit of help with Database management. Regarding OLE, I tend to do it in C# and while I can retrieve data, edit it and then copy it back, there is something weird about C# OLE that is very slow. Maybe it is the late binding or something, but just as far as data access from AB, it is far slower than even JScript/WScript.
Any automation for adjustments maybe would need to support both a ratio adjustment, as well as a absolute value adjustment for futures. Maybe take a from Date/DateTime input with ( "adjustbackwards|AdjustForwards|ChangePriceRecordOnly" , bool includeDate/DateTimePrice) parameter options. Just some thoughts.
Will add universal method to Stock object like this:
Adjust( field_list, multiplier, offset, date_time, before )
- field list such as "OHLC"
- value of each field mentioned in field list gets multiplied by multiplier and added offset value: new_value = old_value * multiplier + offset
- quotes affected will be before (=True) or after specified date_time
UPDATE: It will be
@Tomasz, please include all data fields. I use OI to store outstanding shares. This information is critical to my trading system. Currently, when there is a split I apply it to prices then export all OI data to csv, process it and import it back in.
Awesome! Thank you.
Did I mention my other side is Polish / Ukrainian.
Many Many Thanks Mr. Tomasz,
It is something that I have been yearning for since a decade.
FeedBack Centre (2736 & 2035)
Please accept my thanks again (in advance) for the feature - I look forward to have it soon.
Yes of course, that is why field_list is a parameter so you can apply adjustment to user-selected fields and for example use different adjustments for different fields, for example you would use split factor for OHLC but inverse factor for volume and open interest. Aux fields will also be available.
Not to be greedy and just thinking out loud again.
A very common use case that I come across, perhaps others as well, which by the way I imagine would eliminate much of this and complete the subject full circle, would be an ASCII input flag like $AdjustAutoSense = 1
So for example, when updating a database to keep it current (whenever every day, over the weekend...) typically the imported data has been adjusted already, meaning the source is Split and/or Dividend adjusted, or we are importing the latest continuous futures series which may have rolled. Bottom line is that the new data being imported and appended to our AB database may have some type of adjustment. So if all that needs to be sensed is the OHLC data overlap. Meaning is the overlapped data difference across the OHLC fields is the same, then internally you have in fact "Sensed" that an adjustment was made and by how much. So an ASCII import "format flag" like $AdjustAutoSense = 1 could automatically continue the adjustment from the end (oldest point in our imported data) thru the rest of our data history in our DB.
All the user would have to do is import more data than they need. I.e., overlap where the DB left off by a couple of days. Would be be interval independent as well. Just a thought.
AND let any stop orders and entry prices know about it lol.
Anyway, sorry this should be in it's own topic and not Dream Machine Specs, but I digress.
The OLE Stock.Adjust function will be present in next version.
UPDATE: It will be
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.