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
Did you write this in Rust? I'd be very interested to know how you did it, as I too have decided to switch to Rust because of the huge benefits for complex projects like this.
Well yes the threshold of entry in Rust is high. But modern LLMs are very good for learning and coding too
inspired and recalled:
Not that visualisation, but a very unexpected file manager and Zoomable UI https://sourceforge.net/projects/eaglemode/
because they all look like twin-brothers.
ps/ for practical use it certainly lacks a lot of functions and plugins, but it's worth to see what UI can be like.
Muhammad Minhas Qamar #:
How about trading charts that are zoomable. You zoom in on the 1H candle and see 30 minute candles inside it, and the deeper you go, the lower the timeframes.
like this?
HAHA! Well...Yes.
But I guess it can be made with a bit more distinct visual. The idea is the same, but I can't really make out what timeframe we are looking at when zoomed in/out without looking at the top left corner.
I was just thinking about how one would implement this, and was building a prototype. Immediately a problem occurred that candlesticks at different timeframes don't geometrically contain each other cleanly. Looking at your vid, I guess this was solved by using a line chart and fractional timeframes. Other engineering problems are also present like real-time updates are more complex, but I will try to do something about this. Thanks for sharing the video
I've been writing PineScript inside Rust, so my script for using it is very different from what you do. Nevertheless, it would be interesting to see an implementation of the file explorer inside Rust, so kindly share the github link if you decide to publish it as OS
But be warned that the code is only implemented as a prototype, as a test of an idea. Memory usage is very inefficient and caching is not implemented and nothing is implemented at all. Only 3D visualisation of the file structure
HAHA! Well... yeah.
But I think it could be done with a clearer visual series. Same idea, but I can't figure out what time frame we're looking at when zooming in/out without looking at the top left corner.
I was just thinking about how this could be implemented and was prototyping. Immediately there was a problem with the fact that candles on different timeframes are geometrically not very tight to each other. Looking at your video, I assume this was solved by using a line chart and fractional timeframes. There are other engineering issues like real-time updates are more difficult, but I will try to do something about it. Thanks for sharing the video
Main timeframe M1. Index timeframes M4, M16, M64, M256, M1024, M4096
https://github.com/Nikolai-Semko/forest_fm_2
But be warned that the code is only implemented as a prototype, as a test of an idea. Memory usage is very inefficient and caching is not implemented and nothing is implemented at all. Only 3D visualisation of the file structure
I am actually more impressed by looking at the code since it's footprint is extremely tiny. I thought that the codebase would be massive, but it's just a handful of files. I understand that it's a prototype, but still worth noting
you're almost right.
Main timeframe M1. Index timeframes M4, M16, M64, M256, M1024, M4096
I guess powers of 4 instead of the natural timeframes is an elegant solution to the geometric "nesting" problem. But I think more importantly, for traders isn't it a bit non-intuitive? Because natural timeframes are the norm, and seeing M16 just puzzles the brain of a retail trader. There has to be a way to get the best of both worlds...hmm a good challenge I suppose
I'm actually more impressed looking at the code as it takes up very little space. I thought the codebase would be huge, but it's just a handful of files. I realise it's a prototype, but it's still worth paying attention to.
I think numbers of 4 instead of natural timeframes is an elegant solution to the geometric "nesting" problem. But I think more importantly, isn't it a bit unintuitive for traders? After all, natural timeframes are the norm, and seeing M16 is just a puzzle for the retail trader's brain. There has to be a way to get the best of both worlds.... hmmm, a good challenge I suppose.
And there is no need for that in this task. M1 is the main TF in MT5. Other TFs are synthetic from it.
In MT5 you load the history of only M1(!!!), other TFs are calculated in the terminal from M1. In MT4, all TFs are loaded.
It does not matter what is intuitive for a trader. The main thing is that EA is conflict-free. And M1, M4, M16, M64, M256, M1024, M4096 give this conflict-free due to the same uniformity of time density on different scales.
I don't know. I beg to differ. Rust's new releases are stable. MO libraries are also on top of their game. Moreover, I have a bias towards the server side. There Rust feels very confident, the more and high-performance frontend is also written mainly in Rust (as WASM development environment).