Machine learning in trading: theory, models, practice and algo-trading - page 2947
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
All that appear in the open source ONNX Runtime project.
onnx.defs.onnx_opset_version() writes that opset=17. About the version in the MT log it says 1.14.0, although I think the latest ONNX version is 1.13.1
onnx.defs.onnx_opset_version() writes that opset=17. About the version in the MT log it says 1.14.0, although it seems that the latest ONNX version is 1.13.1
No, that's right. It is ONNX latest version 1.13.1, and ONNX Runtime latest version 1.14.1
The set of functions for access to charts/ticks/trading positions/transaction history is given above. It is enough for direct work of python scripts.
Perhaps, we will add access to indicators.
Transferring indicators is not a universal method, though it is probably sufficient for most traders. For example, I am more interested in transmitting data not on every bar, but at the moments when levels are broken. Someone is interested in something else, etc.
It is hardly possible to make some ideal way of exchange that will suit everyone, so crutch methods at the development stage are inevitable. The main thing is to avoid crutch methods at the stage of launching in a tester or on a VPS.
I tested the ONNX.Price.Prediction project in the new version of MT5 b3601. Everything seems to work - training and output in python, output in MT5 (I removed the dll for onnx from the root and restarted the terminal).
We can wait for the release and start trying with our own models)
Indicator transmission is not a universal method, although it is sufficient for most traders. For example, I am more interested in transmitting data not on every bar, but at the moments when levels are broken. Someone is interested in something else, etc.
It is hardly possible to make some ideal way of exchange that will suit everyone, so crutch methods at the development stage are inevitable. The main thing is to avoid crutch methods at the stage of launching in a tester or on a VPS.
. .
If all this is solved, MT turns from an intermediary between a broker and a client into just a convenient tool for writing strategies and indicators.
MT delivers quotes and at the same time is very fast and reliable - an excellent element to build into a trading system. To allow string to be passed to python means to consolidate this role of the terminal.
For example, crypto has passed MT because the broker in crypto is superfluous and unnecessary element, but it does not cancel the use of the terminal for writing and using Expert Advisors.
To put it simply: write an EA => run it on BTCUSD => trade on Binance via a Python script => thank MetaTrader for having it.
I don't understand why you need all this stuff with ONNX.
There is an obvious basic scenario how to make MT5 and MO friends:
1. From OnInit() start python script as a separate process.
2. You need a couple of functions of information exchange between python and EA, in the mode when EA can wait for information.
3. Make a folder Models and throw TensorFlow models into it.
THAT'S IT!!! MT and MO integration has happened! Everyone is happy.
I don't understand why all the fancy stuff with ONNX in the first place.
There is an obvious basic scenario how to make MT5 and MO friends:
1. From OnInit() the python script is started as a separate process.
2. We need a couple of functions of information exchange between python and EA, in the mode when EA can wait for information to arrive.
3. We make a folder Models and throw TensorFlow models into it.
THAT'S IT!!! MT and MO integration has happened! Everyone is happy.
There is such integration with R. Only it is not clear why R is needed on VPS and why you need problems to support its integration with MT (version control of language and packages, etc.). It will be the same with python.
There is also a point related to speed, which is very important in our business. Look how fxsaber scratches out milliseconds in a constant battle with metaquotes as they turn into profit points. Obviously a bundle of anything with anything will run slower than both programmes on their own.
It would seem what could be more obvious.....
We can wait for the release and start trying with our own models)
There is such integration with R. Only it is not clear why R is needed on VPS and why we need problems with supporting its integration with MT (version control of language and packages, etc.). It will be the same with python.
There is also a point related to speed, which is very important in our business. Look how fxsaber scratches out milliseconds in a constant battle with metaquotes as they turn into profit points. Obviously a bundle of anything with anything will run slower than both programmes alone.
It would seem what could be more obvious.....
Taking into account the spread and exchange/brokers' commissions, it is necessary to forecast for the time measured in tens of minutes or hours. What does 50 milliseconds difference have to do with it?
How exactly in real life does MQ beating fxsaber by 5 milliseconds help you ?
I don't understand why all the fancy stuff with ONNX in the first place.
There is an obvious basic scenario how to make MT5 and MO friends:
1. From OnInit() the python script is started as a separate process.
2. We need a couple of functions of information exchange between python and EA, in the mode when EA can wait for information to arrive.
3. We make a folder Models and throw TensorFlow models into it.
THAT'S IT!!! MT and MO integration has happened! Everyone is happy.
It can be simpler...hook up Redis, get RedisAI with PyTorch, ONNX, TensorFlow support, and if desired, distribute the load across nodes and clouds.