When you have a trait (interface for those unfamiliar with rust), you have to put the function signature of what all classes or struct will implement.

Let's call this trait Vehicle that could declare methods such as drive get_hp and many others. There could be many classes implementing this interface.

Now, typically in many languages (like Java), when the program meets an instance of Vehicle, It will dynamically find which implementation it has to execute, like doing an instanceof and executing the right implementation (the JVM indeed performs a type check, but not an instanceof)

Dynamic dispatching is this process of finding the proper implementation of a polymorphic operation.

While traditional approaches exist, this session dives into optimized techniques that can unlock up to 10x performance gains! We'll explore how these strategies leverage the new features introduced in Java 21.

The code

First let's implement a simple trait, here Vehicle

trait Vehicle {
    fn get_hp(&self) -> u32;
}

Then we will create two structs and implement them with this trait.

struct Mercedes {
    hp: u32,
}

struct AMG {
    hp: u32,
}

impl Vehicle for Mercedes {
    fn get_hp(&self) -> u32 {
        self.hp
    }
}

impl Vehicle for AMG {
    fn get_hp(&self) -> u32 {
        self.hp * 2
    }
}

Now, let's write a function that takes 2 instances of Vehicle and returns one of them. Like in this example:

fn test_dynamic_dispatching<'a>(x: &'a AMG, y: &'a Mercedes) -> &'a dyn Vehicle {
    if x.get_hp() > y.get_hp() {
        return x;
    }
    y
}

The compiler does not have prior knowledge of which concrete instance of Vehicle will be returned during runtime. This uncertainty necessitates the use of the dyn keyword. Unlike generic parameters or impl Trait, where the compiler can infer the concrete type being passed, dynamic dispatching requires explicit indication using dyn.

So calling get_hp on the returned instance of Vehicle will be done using a vtable, containing all the possible implementations and execute the right one.

Understanding static dispatching.

Now we are going to do something new in our code, we are going to add an enum, that contains structs that implements our trait.

enum VehicleDispatcher<'a> {
    AMG(&'a AMG),
    Mercedes(&'a Mercedes),
}

And we will make the same function as we declared above, but slightly different:

fn test_static_dispatching<'a>(x: &'a AMG, y: &'a Mercedes) -> VehicleDispatcher<'a> {
    if x.get_hp() > y.get_hp() {
        return VehicleDispatcher::AMG(&x);
    }
    VehicleDispatcher::Mercedes(&y)
}

Now, when calling this function, we will have to do a match on it, in order to call the function on it. This is now static dispatching, there is no more performance loss looking at a map in order to find the proper implementation.

Performance test

Using black_box is critical to prevent the compiler from "optimizing" to much and remove this part of the code.

Do not forget to run or build this code using --release

    let m = Mercedes { hp: 234 };
    let a = AMG { hp: 987 };

    let start1 = Instant::now();
    for i in 0..100000000 {
        let v = test_dynamic_dispatching(&a, &m);
        black_box(v.get_hp());
    }
    let duration1 = start1.elapsed();
    println!("Time elapsed in dynamic dispatching is: {:?}", duration1);


    let start2 = Instant::now();
    for i in 0..100000000 {
        let v = test_static_dispatching(&a, &m);
        match v {
            VehicleDispatcher::AMG(amg) => { black_box(amg.get_hp()); }
            VehicleDispatcher::Mercedes(mer) => { black_box(mer.get_hp()); }
        };
    }
    let duration2 = start2.elapsed();
    println!("Time elapsed in static dispatching is: {:?}", duration2);

While running the code, we get this gain in performance.

Amazing! Isn't it?

Conclusion

For such a slight difference in the code, we get such an improvement that can be life-changing when performance is critical.

That is the reason we have crates that created macros to simplify the process of doing so, such as enum_dispatch https://docs.rs/enum_dispatch/latest/enum_dispatch/

I said I would write about Java 21, but do you see a similarity?

I saw many people around me not understanding the sealed type's benefits and being baffled by the permits keyword. This video from a Youtuber I like made me laugh: https://youtu.be/w87od6DjzAg?si=KxGea4GhmzsG9oeb&t=480

Does everything click now?

Java knows all possible subclasses/implementations because you explicitly list them in the permits clause. The compiler will ensure these are the only extensions/implementations allowed. This means the type system can be fully checked for completeness at compile time.

This is static dispatching introduced to Java, and that is amazing. Behind the door, it is precisely what we have done before by listing all the subclasses/implementations in an enum, but without our knowledge.

I hope you liked this article, and, as always, you can find the code on my GitHub.

https://github.com/mathias-vandaele/dynamic-vs-static-dispatching

Although I've nearly completed all the exercises, there's one in particular that I found quite intriguing.

You can access it here: https://github.com/mathias-vandaele/google-foobar-challenge/blob/master/src/main/java/dev/mathias/exercise_3_2/Solution.java

Prepare the Bunnies' Escape

You're awfully close to destroying the LAMBCHOP doomsday device and freeing Commander Lambda's bunny prisoners, but once they're free of the prison blocks, the bunnies are going to need to escape Lambda's space station via the escape pods as quickly as possible. Unfortunately, the halls of the space station are a maze of corridors and dead ends that will be a deathtrap for the escaping bunnies. Fortunately, Commander Lambda has put you in charge of a remodeling project that will give you the opportunity to make things a little easier for the bunnies. Unfortunately (again), you can't just remove all obstacles between the bunnies and the escape pods - at most you can remove one wall per escape pod path, both to maintain structural integrity of the station and to avoid arousing Commander Lambda's suspicions.

You have maps of parts of the space station, each starting at a prison exit and ending at the door to an escape pod. The map is represented as a matrix of 0s and 1s, where 0s are passable space and 1s are impassable walls. The door out of the prison is at the top left (0,0) and the door into an escape pod is at the bottom right (w-1,h-1).

Write a function answer(map) that generates the length of the shortest path from the prison door to the escape pod, where you are allowed to remove one wall as part of your remodeling plans. The path length is the total number of nodes you pass through, counting both the entrance and exit nodes. The starting and ending positions are always passable (0). The map will always be solvable, though you may or may not need to remove a wall. The height and width of the map can be from 2 to 20. Moves can only be made in cardinal directions; no diagonal moves are allowed.

The solution

Many online solutions employ a dual Dijkstra's algorithm and utilize a double for loop to discover the shortest paths both from the starting point to the endpoint and vice versa. The objective is to identify the optimal location for breaking a wall, allowing the determination of the overall shortest path.

I believe this solution is not only inefficient, but can not be generalized, what if we are allowed to break more than one wall this algorithm becomes useless. This solution also has an early return, meaning the best solution can be found really really fast.

My chosen approach diverges significantly; I intend to transform the maze into a heat map. As the bunny takes more steps, the corresponding points on the map become hotter.

I subsequently determine the threshold for considering a non wall-crossing path as worthwhile. I arbitrarily set this threshold at 100,000 steps. This implies that I find it acceptable to explore a path that avoids wall crossings but is still at least 100,000 steps behind a path that did involve wall crossings.

I will make it into steps to give an example:

Here is the maze:

{
        {0, 1, 1, 0},
        {0, 0, 0, 1},
        {1, 1, 0, 0},
        {1, 1, 1, 0}
}

Here is the heating map associated (Note that I am using MAX_INTEGER to represent an unexplored node):

[[0, 2147483647, 2147483647, 2147483647],
[2147483647, 2147483647, 2147483647, 2147483647],
[2147483647, 2147483647, 2147483647, 2147483647],
[2147483647, 2147483647, 2147483647, 2147483647]]

Few steps after, we are ending up with this:

[0, 100000, 2147483647, 2147483647]
[1, 2, 2147483647, 2147483647]
[100001, 2147483647, 2147483647, 2147483647]
[2147483647, 2147483647, 2147483647, 2147483647]

When a wall is destroyed, I increase the value in the heatmap for the preceding cell by 100,000 and update the current cell accordingly. In the absence of a wall, I simply increment the value by one. This approach enables the re-exploration of a path as long as a better score is achieved.

[0, 100002, 100003, 100004]
[1, 2, 3, 100005]
[100001, 100004, 4, 5]
[2147483647, 2147483647, 100004, 6]

And when we finally found the end of the maze, we return early with the number of steps we have achieved.

Conclusion

I believe that employing a combination of a heatmap and Dijkstra's algorithm enhances the effectiveness of resolving this LeetCode problem compared to the conventional technique. This approach boasts a simpler time complexity and is capable of determining the shortest paths even when breaking more than one wall, possibly up to two or three walls.

The onion architecture

Onion architecture is a way to architecture your project in a layered manner.

This technic aims to create better separation of concerns, testability, maintainability, etc. It respects every SOLID principle. Here is a corresponding image of how onion architecture is layered.

The way I made it is a little bit different, but I find it more straightforward and more understandable

• Domain:

It's in charge of the Data Access Object (DAO), which is a fancy way of saying it handles how we talk to our data. The domain layer also has this thing called a 'repository trait.' Think of it like a blueprint for how we'll interact with data from the outside. We'll get into the nitty-gritty in a bit, but just know that the repository trait will be brought to life by the infra layer. It's like a set of rules the infra layer will follow to play nice with the data.

#[async_trait]
pub trait ReceiptRepository{
    async fn find_by_id(&self, id: String) -> Result<Receipt, Box<dyn Error>>;
    async fn insert(&self, receipt : Receipt) -> Result<(), Box<dyn Error>>;
}

• Infra:

The infra layer is like the backstage crew for our code. It's responsible for making sure all the tools the domain layer needs are ready to go. So, when the use cases (we'll get to those in a bit) need something from the domain, the infra layer is there to provide it from whereever (database, API etc.). Think of it as a helpful assistant that hands over everything the main show (our app) needs to run smoothly.

    pub fn provide_mongo_collection(&self, collection : String) -> impl ReceiptRepository + Send + Sync {
        MongoCollection::new(self.mongo_client.collection::<Receipt>(&collection))
    }

• Use Cases

Alright, let's talk about the use case. This is where the actual brainpower is. Imagine it as the decision-maker of our app. It's got this 'execute' function that does the heavy lifting. This function knows all the moves to get data in and out of the database. How does it know? With the repositories we talked about earlier. They give it the secret codes it needs to work its magic. Think of the use case as the superhero of our app, making sure everything happens just the way it should.

    pub async fn execute(&self, id: String) -> Result<domain::Receipt, Box<dyn std::error::Error>> {
        self.collection.find_by_id(id).await
    }

• Dependency Injection:

This module holds all the essential stuff the app needs, like connections to the database or other APIs. It's like a treasure chest of tools. But It's also a matchmaker. When we need a specific job done (that's where the use cases come in), it finds the perfect worker from the infra team, hooks them up, and creates a dream team for that task. This super-smooth teamwork means our app's different parts don't get tangled up; this is what low coupling is. It's like having a well-organized team that can pass the ball flawlessly.

This is FeatureContainer

    pub fn get_receipt(&self, from : String) -> GetReceipt {
        GetReceipt::new(Box::new(self.infra_provider.provide_mongo_collection(from)))
    }

• Presentation :

The presentation layer is our app's front door for customers. It's like the face of our project, the part you'll start up. This is where the magic begins! It's the one that fires up the Actix web server and sets the rules for how it talks to the outside world.

The error manager is like the translator that takes the messy technical stuff and turns it into plain English for the customer.

The presentation layer also keeps 'DTO' – that's short for Data Transfer Object. It's like the messenger that carries data back and forth with the client; it turns this data into the proper format that the layer underneath understands (DAO), like translating between two languages. This layer also holds an instance of FeatureContainer, with essential connections. This container's job is to ensure everyone has what they need, like a backstage organizer (what we talked about just above).

#[get("/receipt/{id}")]
pub async fn get_receipt(
    data: Data<FeatureContainer>,
    req: HttpRequest,
    id: web::Path<String>,
) -> Result<HttpResponse, ApiError> {

    let from = req.headers().get("from").ok_or_else(|| {
        ApiError::new(
            "Please pass a correct header".to_string(),
            "There is no header from".to_string(),
            actix_web::http::StatusCode::BAD_REQUEST,
        )
    })?.to_str().map_err(|err| {
        ApiError::new(
            "Please pass a correct header".to_string(),
            err.to_string(),
            actix_web::http::StatusCode::BAD_REQUEST,
        )
    })?.to_string();

    match data.get_receipt(from).execute(id.into_inner()).await {
        Ok(receipt) => Ok(HttpResponse::Ok().json(ReceiptDto::from(receipt))),
        Err(err) => Err(ApiError::new(
            "Error inserting receipt".to_string(),
            err.to_string(),
            actix_web::http::StatusCode::INTERNAL_SERVER_ERROR,
        )),
    }
}

Conclusion

If you want to see the code more in-depth, don't hesitate to take a look at: https://github.com/mathias-vandaele/receipts_inserter_onion

I have been working a lot with Webflux for the past 6 months, I have designed new services for my customers, and am always striving to deliver the best.

For most of my applications, I like to use the functional endpoint instead of the classic RestController decorator. I can manipulate directly the server response and I feel more in control of what I am doing. The whole thing feels more concise, explicit and easy to document.

Using functional endpoints also means I have to manage all the exceptions that might be thrown from my app. Using the functionals endpoint, I can't use the classic RestControllerAdvice to manage those exceptions. I have also seen in some blog posts that using it is a "bad practice".

I needed to find a way to manage exceptions properly for the services I am designing.

I came across multiple articles advising on extending AbstractErrorWebExceptionHandler which does not sound the right way to do it.

How to manage the exceptions?

First, let's build a classic WebFlux app using SpringInitializr.

I am creating an interface that we can call Error that will describe the way of returning the right error content to the client.

public interface Error {

    Mono<ServerResponse> getAsServerResponse();
}

Then I will Build my Exception Type, let's say I want Business Exception and Technical Exception.

I will create them extending RuntimeException and implementing Error

I will give them a constructor, and a function to build a response body associated to the type of error.

public class BusinessException extends RuntimeException implements Error {

    private final Integer code;
    private final String message;
    private final String advice;

    public BusinessException(Integer code, String message, String advice) {
        super(message);
        this.code = code;
        this.message = message;
        this.advice = advice;
    }

    @Override
    public Mono<ServerResponse> getAsServerResponse() {
        return ServerResponse.badRequest().bodyValue(this.createBusinessErrorMessage());
    }

    protected BusinessError createBusinessErrorMessage() {
        return BusinessError.builder()
                .message(this.message)
                .advice(this.advice)
                .code(this.code)
                .build();
    }

}

The Technical can be created the same way.

Now If I wanna create a new exception, I would just have to extend either TechnicalException or BusinessException. The getAsServerResponse can stay the same or I can override it individually depending on the response code I want to return.

Testing the error management.

    @Bean
    RouterFunction<ServerResponse> getEmployeeByIdRoute() {
        return route(GET("/hello-world/{name}"),
                helloController::execute);
    }

I create a simple endpoint in which I will throw an error.

And here is how I manage everything at the same time.

 return Mono
                .fromSupplier(() -> new DummyReturn(request.pathVariable("name")))
                .flatMap( dummyReturn -> ServerResponse.ok().bodyValue(dummyReturn))

                .onErrorResume(BusinessException.class, BusinessException::getAsServerResponse)
                .onErrorResume(TechnicalException.class, TechnicalException::getAsServerResponse);
    }

Now I will just throw an error depending on random/fixed parameters

public DummyReturn(String name) {
        this.name = name;
        this.id = random.nextInt(20);
        if (Objects.equals(name, "error")) {
            throw new BusinessException(100, "Error in DummyReturn constructor", "Enter a correct name");
        }
        if (this.id > 10) {
            throw new TechnicalException("An error happened while attributing the ID");
        }
    }

And here is the result

GET http://localhost:8080/hello-world/df
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 20

{
  "id": 2,
  "name": "df"
}

GET http://localhost:8080/hello-world/df
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json
Content-Length: 56

{
  "message": "An error happened while attributing the ID"
}

I love this way cause we can be very explicit without having to write a ton of code.

If you are interested in seeing more of this, the entire codebase can be found on my GitHub at https://github.com/mathias-vandaele/webflux-error-management-functional-endpoint

Thank you for reading!

I believe we can harness the power of Rust and WebAssembly to perform heavy calculations on the client-side. By creating a WebWorker in WebAssembly using Rust, we can achieve much greater processing power than traditional JavaScript-based solutions.

To demonstrate this, I plan to build a web application that calculates prime numbers. However, I want to ensure that the calculations are verified on the client-side, with the server managing connections and receiving results via an endpoint for the client.

To build this application, I will create a back end with Rust that will manage each client socket. The architecture I will be using is powerful, with the client socket being passed to the relevant function as needed. I will open a thread using a Tokio runtime to manage each client that wants to connect to the server.

fn handle_server(addr: String, sender: Sender<Event>) {
    Runtime::new().expect("Could not start a new runtime").block_on(async {
        let listener = TcpListener::bind(addr.to_string()).await.expect("Failed to bind socket");
        let mut id_manager = Counter::new(0);
        loop {
            match listener.accept().await {
                Ok((stream, socket_addr)) => {
                    tokio::spawn(handle_new_client(Connection::new(id_manager.next(),
                                                                   sender.clone(),
                                                                   stream,
                                                                   socket_addr)));
                }
                Err(e) => {
                    eprintln!("Impossible to connect with remote client, error : {}", e);
                }
            }
        }
    });
}

We give the task of managing the client a Sender<Event>, which is a channel that allows the task to communicate with the main thread.

async fn handle_new_client(connection: ImmatureConnection) {
    connection
        .accept_handshake().await
        .send_connection_opened_notification();
}

Once the handshake is complete, the Connection object has a method that sends a connection_opened notification using the channel.

Here's where it gets interesting: the channel sends the Connection object itself to the main thread wrapped in a notification.

fn send_connection_opened_notification(self) {
        self.event_sender.clone().send(Event::ConnectionOpened(self)).expect("Failed to send `Connection Opened` example");
    }

And all those notifications are managed in the main thread.

loop {
        let event = match sm.poll_event() {
            Ok(event) => { event }
            Err(e) => {
                eprintln!("An unexpected error happened when trying to poll an event : {}", e);
                exit(1);
            }
        };

        match event {
            Event::ConnectionOpened(connection) => {
                let next = job.pop_front().unwrap();
                id_worker_number_map.entry(connection.get_id()).or_insert(next);
                connection.send_message(next.to_string());
                job.push_back(number_manager.next())
            }
            Event::MessageReceived(connection, message) => {
                let value = id_worker_number_map.get_mut(&connection.get_id()).expect("An unexpected error happened");
                if message == "true" {
                    //println!("worker n°{} has found a prime number : {}", connection.get_id(), value);
                    *last_prime.lock().unwrap() = *value
                }
                let next = job.pop_front().unwrap();
                connection.send_message(next.to_string());
                *value = next;
                job.push_back(number_manager.next());
            }
            Event::ConnectionClosed(connection) => {
                let value = id_worker_number_map.get(&connection.get_id()).expect("An unexpected error happened");
                println!("Worker n°{} has closed the connection without finishing his job, his number {} goes back to the queue", connection.get_id(), value);
                job.push_back(*value);
                id_worker_number_map.remove(&connection.get_id()).expect("This worker should have been in the map");
            }
            Event::CloseReceived(connection, _close_frame) => {
                let value = id_worker_number_map.get(&connection.get_id()).expect("An unexpected error happened");
                println!("Worker n°{} has closed the connection without finishing his job, his number {} goes back to the queue", connection.get_id(), value);
                job.push_back(*value);
                id_worker_number_map.remove(&connection.get_id()).expect("This worker should have been in the map");
            }
            e => println!("{:?}", e),
        }
    }

Now that the back-end is ready, I will be building the front-end in Yew. This will make it easy to compile Rust into a WebAssembly package that can be displayed on the front-end. To implement the WebWorker, I will be using Gloo, which is relatively easy to use.

After some work, I have created an agent that creates a web worker that connects to the back-end, requests a number, and replies with either true (if prime) or false (if not prime). I understand that this implementation is not optimized (it would be better to use a range of numbers where the client can send back the prime numbers in that range), but I created this to showcase the proof of concept of this architecture.

I used Traefik to manage the SSL certificate and other aspects efficiently, and now the application is ready to go! Check it out at https://distributed-computing.mathias-vandaele.dev/

If you're interested, the entire codebase is available at https://github.com/mathias-vandaele/project-distributed-calculus. Thank you for reading!

Being in the world of Bitcoin and, more generally, crypto-currencies for a while, I wondered if a complex algorithm could not be used to predict the price.

That happens to be harder than I thought.

After all the models I have done, I decided that I would try to prove the point that without very complex models, insight data, or a lot of money, you can't predict it; I came up to the conclusion that stock price and bitcoin price are just noise by itself. I believe it is possible to have more precise predictions, not just the price or the RSI.

How will I show you the difference between a predictable time series and a not-predictable one?

Using a predictable trigonometric function

Here it is :

The predictable time series I am going to use is a sum of sinus and cosinus

n = 10000

array = np.array([math.sin(i*0.02) + math.cos(i*.05) - math.sin(i*0.01) for i in range(1, n)])
fig, ax = plt.subplots()
ax.plot([i for i in range(1, n)], array, linewidth=0.75)
plt.show()

That gives us this curve :

Every algorithm you will find on the internet proposes you to predict the next value given the 150 last one. We are going to make something a bit different. Let's take all our values and associate each of them with a buy index, which would be 1 when the best action to do is to buy and 0 when the best move would be to sell.

We can do this with a simple algorithm :

SELL_INDEX = np.zeros((len(array), 1))

for index, row in enumerate(array):

    if index > len(array) - 150:
        continue

    max_price = np.amax(array[index:index + 150])
    min_price = np.amin(array[index:index + 150])

    current_sell_index = (row - min_price) / (max_price - min_price)

    SELL_INDEX[index][0] = 1 if current_sell_index > 0.8 else 0

data_with_sell_index = np.hstack((array.reshape(-1,1), SELL_INDEX))
data_final =  np.hstack( (data_with_sell_index,  np.arange(len(data_with_sell_index)).reshape(-1, 1)) )
data_final = data_final[:len(data_final) - 150]

Let's apply it to our sum of sinus and cosinus curve, and that is what is showing :

Ok, we are all set now. The idea of the model now would be to predict the nᵗʰ buy index, using the 150 previous prices, so from n - 150 to n -1.

The model looks like this :

input_layer = Input(shape=(150, 1))
layer_1_lstm = LSTM(50, return_sequences=True)(input_layer)
dropout_1 = Dropout(0.1)(layer_1_lstm)
layer_2_lstm = LSTM(50, return_sequences=True)(dropout_1)
dropout_2 = Dropout(0.1)(layer_2_lstm)
layer_3_lstm = LSTM(50)(dropout_2)

output_sell_index_proba = Dense(1, activation='sigmoid')(layer_3_lstm)

model = Model(inputs=input_layer, outputs=output_sell_index_proba)
model.compile(optimizer='adam', loss='binary_crossentropy', metrics=[keras.metrics.BinaryAccuracy()])
model.summary()

As I am getting either 1 or 0 as a result, I decided to use the metric binaryAccuracy. and the loss function binary_crossentropy. The optimizer, Adam is often the best choice; it is the one that has given me the best results.

After training with ten epochs, I end up with about 0.03 loss and almost 0.99 accuracy.

Epoch: 8. Reducing Learning Rate from 0.0009227448608726263 to 0.000913517433218658
Epoch 10/10
125/125 [==============================] - 28s 221ms/step - loss: 0.0389 - binary_accuracy: 0.9853 - val_loss: 0.0310 - val_binary_accuracy: 0.9864

Let's now try to predict from new data unseen by the algorithm during the training.

data = np.array(data_final[:,0][9000:])
results = np.array([])
for i in range (150, 1000):
    result = model.predict(data[i - 150 : i].reshape(1, 150, 1))
    results = np.append(result, results)

Here is the chart :

The accuracy of unseen data is pretty good, even though there are some inconsistencies.

Using Bitcoin price

Let's plot the last 10000 CLOSE CANDLE on BTC (60S).

I will apply the previous algorithm I used for the trigonometric function, and here is the result.

So now I have everything to work with, I can reapply the same process I did in the previous section. The only difference is that I will use a MinMaxScaler, so the input value will only vary from 0 to 1; neural networks have a hard time working with input that vary lot (here between 20k and 40k).

scaler = MinMaxScaler(feature_range=(0, 1))
fitter = scaler.fit(x)
x = fitter.transform(x)

The first difference that I noticed is the loss; It is stuck at 0.5

Epoch: 8. Reducing Learning Rate from 0.000817907159216702 to 0.0008097281097434461
Epoch 10/10
125/125 [==============================] - 27s 218ms/step - loss: 0.5074 - binary_accuracy: 0.7952 - val_loss: 0.4372 - val_binary_accuracy: 0.8475

And here is a prediction chart :

There is nothing we can rely on.

The model does not find any pattern in the price; it is considered noise.

Conclusion

People have been trying to predict stock prices for the longest time; they have invented many ways to do it :

• Technical analysis, like RSI, Ichimoku candle
• Artificial inteligence technique
• Sentiment analysis

I think that no one can accurately predict the stock market without a solid understanding of the asset or massive investments.

You can find the code on my GitHub repository: https://github.com/mathias-vandaele/keras-research.