Structure rules. Learning how to structure programmes, exploring possibilities, errors, solutions, etc. - page 11

 
TheXpert:

It's a crooked one, too. Using a switch... case and using a state machine pattern are two different things. You can tell from the text that there's no such thing as a pattern, just like in the article you cited.

It reads something like "I've invented a unique winning system..." and then a crooked martin statement.

O.K. What's the fundamental difference then?
 
C-4:
O.K. What is the fundamental difference then?
There you go. That's what I needed to prove :)
 
TheXpert:
There you go. That's what I needed to prove :)
Prove what? Don't pretend like you're the only one who knows something amazing that you'll never say because you think it's beneath your dignity.
 
TheXpert:

Another way to do it. Using a switch... case and using a state machine pattern are two different things. You can see from the text that there's no trace of a pattern there as well as in the cited article.

But don't worry that the article about the state machine you've given says it in black and white:

Let's say now Vasya makes a project in C# and he needs a simple state machine for one type of objects. He writes something like this:

private enum State { Disabled, Idle, Animating }

private State state;
 
void setState(State value) {
    state = value;
    switch (state) {
        case State.Disabled:
            ...
        case State.Idle:
            ...
        case State.Animating :
            ...
        break;
    }
}

Then he goes on rambling about various frameworks and ready-made classes.

The conclusion of the article is as follows:

"And then Vasya got fed up and went back to the world's simplest finite state machine. He reworked it a bit and came up with the rules of how to write code in it."

 

First of all, I didn't cite any article. :)

Secondly, to take an article as the truth in the first instance just because someone cited it and it's on hubra is a bit... um...

A stone axe is also a kind of axe.

 
TheXpert:

First of all, I didn't cite any article. :)

Secondly, to take an article as the truth in the first instance just because someone cited it and it's on hubra is a bit... um...

A stone axe is also a kind of axe.

Yes, I'm sorry, it was cited by Urain.

If this article describes a non-state pattern, then what is a true state pattern? If you can get the topo... code to the studio, let's discuss it.

 
C-4:
Well... I'll do some googling.
 
Here's an interesting thought.
C-4:
An important exception: the logic of HFT algorithms is actually described by the execution method.

I almost agree.

On this basis, I plan to further intellectualise the trading driver, namely to equip it with "brains" for independent decision making in fast trend situations.

// (Which actually just shifts the trailing limit into a "negative area").

 
TheXpert:
Well... I'll do some googling.
A familiar name came up on the link: A. A. Shalyto. I think I've heard it somewhere before...
 
MetaDriver:
Here's an interesting idea.

I almost agree.

On this basis, I plan to further intellectualize the trading driver, namely to equip it with "brains" for making independent decisions in situations of a fast trend.

// (Which, in fact, simply moves the trailing limit into a "negative area").

I.e. it turns out to be a robot in a robot. Suppose there is a medium-term algorithm that gives an order to buy at the market. Another, low-level robot executes that order at the best price using the HFT best move technique.