Discussing the article: "Сode Lock Algorithm (CLA)"

 

Check out the new article: Сode Lock Algorithm (CLA).

In this article, we will rethink code locks, transforming them from security mechanisms into tools for solving complex optimization problems. Discover the world of code locks viewed not as simple security devices, but as inspiration for a new approach to optimization. We will create a whole population of "locks", where each lock represents a unique solution to the problem. We will then develop an algorithm that will "pick" these locks and find optimal solutions in a variety of areas, from machine learning to trading systems development.

Code locks, also known as digital or combination locks, are security mechanisms used to control access to rooms, safes, cabinets, and other objects. They differ from ordinary locks in that instead of using a key, a certain number combination is inserted to open them.

Code locks are usually equipped with a keypad, special cylinders or other rotary mechanisms allowing a user to enter a code sequence. Once the correct combination is entered, the code lock activates a mechanism that unlocks the lock, allowing a user to open a door or access the contents of a safe. User can set their own codes or use the provided code to open the lock.

Code lock advantages:

  • Security. Code locks can provide a high level of security, especially if the codes are changed regularly.
  • Convenience. There is no need to carry the keys, which makes code locks convenient to use.
  • Ability to set multiple codes. Some models allow setting several different codes for different users or for different time intervals.


Author: Andrey Dik

 

Do all AOs make the same number of FF calculations?

Probably it would be useful to compare AOs by the average number of FF calculations when the optimum is reached.


This number is the speed of optimisation.

 
fxsaber #:

Do all AOs do the same number of FF calculations?

Perhaps it would be useful to compare AOs in terms of average number of FF calculations when the optimum is reached.


This number is the speed of optimisation.

Yes, all AOs perform the same number of FF calculations in tests - 10000. Different AOs have different populations, but here the number of epochs is simply changed: 10000 / population_size = number_epochs.

An interesting suggestion is to compare by the number of FF runs before reaching the maximum value that the algorithm was able to reach. However, in this case there is an unclear point: an algorithm stuck at the very beginning of optimisation on low FF values will show a high result on such a test....

 
Andrey Dik #:

an algorithm stuck at the very beginning of optimisation at low FF values will show a high result on such a test...

That's why I was talking about the average. Or the worst.

 
fxsaber #:

That's why I was talking about the average. Or the worst.

Yes, I was referring to the average as well. It can be useful to specify the zone, e.g. how many runs the FF, on average, falls into the 90%, 70%, 50% zone. I.e., it is, in fact, an indicator of the non-randomness of the search strategy, since the results of the first epoch are obviously random, so the higher the results at each subsequent epoch, the higher the search ability of the algorithm. It is also possible to measure the average convergence gain with each subsequent epoch for a specified number of epochs.