Alternative implementations of standard functions/approaches - page 12
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
Wow - cool! Thanks. And I thought - it counts every time. Yeah, well, it's logical, you can already calculate at the compilation stage.
So, like this:
But it would be more correct to writeDBL_MANT_DIG instead of 53.
Case of minimal gain, if all values of double are fractional.
1. Your implementation is incomplete, it can be used only if the range of possible values is known in advance.
Here is the code of the full implementation
2. Self-written functions are significantly slower than built-in functions when compiled for debugging, when optimisations are disabled.
1. Your implementation is incomplete and can only be used if the range of possible values is known in advance.
Here is the code for the full implementation
2. Self-written functions are much slower than built-in ones when compiling for debugging when optimizations are disabled.
Thank you very much, Ilyas, for the excellent code.
Of course, it's a great helper here.
I am studying it.
Isn't that the same thing?Nikolai, hi. I see you're working on graphics, but I don't fully understand what the actual task is. What are you working on?
Speeding up rendering functions?
In general, on the topic of the thread, I've managed to implement a completely alternative approach to drawing on canvas. Without using CCanvas class.
That is, not to modify a separate set of functions, but to create a complete drawing mechanism, consisting of a single block.
(Of course, I can hardly demonstrate all this in the code, as there is a lot of code and it is written non-standard way, but I would like to tell you in general).
So:
1. the block (function)
accepts only 2 parameters - Kanvas and Element.
2. Each MT-object has its own resource assigned to it. It is immediately loaded into the "pixel array" using ResourceReadImage(); If the resource doesn't exist yet, a flag is set, which will subsequently determine the range of the cycle over the kernel.
3. the kernel, is an array of properties of all elements. It contains data on the sizes of objects, and colours for different states. And a lot of other data. There are 235 properties in total for every object. At the same time, each element (depending on the type) may contain from one to 11 objects (there is no limitation).
4. In the Drawing block, each object implies a "Detail" of the drawing. Hence, the cycle by object in the kernel, is a drawing cycle in which the image of each Detail is created. If a Canvas has not yet been created, a complete cycle is done on all the Detail of that Canvas alone. The affiliation to the Kanvas is prescribed in the kernel, for each Detail. That is, all Kanvases, (and Parts) have their own sequence numbers. Through these numbers it is possible to draw the content of only the required Kanvas.
4. If a Kanvas already exists and its image is loaded in an array of pixels, and we only need to redraw a single element (on a colour change event, for example), then the range of the core loop is narrowed down to the boundaries of the single element whose number was obtained by the drawing function.
The drawing itself is simple. It is a cycle through the cells of a one-dimensional array from left to right. Before the cycle is set:
1. The starting cell (point A).
2. The end cell (Point B).
3. Step over.
It's hard to summarise the operation of a block of 1500 lines of code in a nutshell. It is one function, which has been growing and polishing for 20 months. I know it almost by heart, which makes it easy to keep developing it.
By using the kernel and the focus (putting important variables on the global scope), the block acquires enormous possibilities. Their limits are not visible to me to this day.
That's the alternative to the standard kanvas drawing approach.
zy. If interested in the details, I can explain.
This is what the beginning of the block looks like:
1. Your implementation is incomplete and can only be used if the range of possible values is known in advance.
Here is the code for the full implementation
Thank you once again for the code. I've been puzzling over these bit masks like double. It turns out it's not as easy as I thought before.
I slightly adjusted my version to yours. There was only one difference: your version returned at values -1>x>0 Ceil(-0.1)= - 0.0, while mine returned 0.0. Although I don't know when it may be useful.
And you get the following:
Same thing, only readable and with comments:
I wrote a script (attached), which confirms 100% identity with your version.
But this variant is faster, more compact and, in my opinion, more readable.
Note that not even a single variable is created in the function body, while your version creates 4 8-byte variables.
Maybe I'm wrong?
Results when input x always has a fractional part:
Results when the input x has a fractional part are rare:
2. Self-written functions are significantly slower than built-in ones when compiling for debugging, when optimizations are disabled.
It's not clear why the speed is needed for debugging.
But if you really need it, you may use the construct:
And there's one more thing I don't understand:
Why does the documentation and the actual DBL_MANT_DIG = 53 ?
as according to the same Wikipedia= 52.
And, as it seems, it follows from your code that 52 too ?
Nikolai, hi. I see you're working on graphics, but I don't fully understand what the actual task is. What are you working on?
Speeding up rendering functions?
Hello Piotr!
I'll reply in person.
And there is one more thing I don't understand:
Why does the documentation and the actual DBL_MANT_DIG = 53 ?
whereas according to the same wikipedia= 52.
And it seems that your code also implies that it is 52 ?
Have you tried to find the answer to the question yourself?
Hint: In the google search, type "DBL_MANT_DIG 53 52".