Let us know your requirements and we'll get back to you as soon as possible.
Get in touch
By clicking on the button, I accept the terms of the transfer of personal data and agree to the privacy policy

Algorithmic Coding Tips

R&D, Software development
The research-oriented approach states
Let’s spill into the code more and more capabilities and see what comes out, nevermind code structure and alike. Just push each new piece of formula in the most comfortable place in the sense it has access to all required variables etc. and see what comes out! ASAP! Since, what if… this is a wrong direction ?! I’d like to know it ASAP, not having to invest in design and such…
The design-oriented approach replies
And what will happen after you find the one good algorithm that solves your current problem ? you won’t have time for the aftermath, will you? Is there a chance that in the meanwhile you’ll get used to the current spaghetti code and leave it almost like it was? So why not invest a little effort now for making the life of the whole team better in the near future?
I’m sure that there are many ways to approach this conflict, here’s mine:
When coding algorithms, especially in C++ and other OOP languages, it triggers two styles of thinking: the research-oriented vs. the design-oriented.
The difficulty
How to avoid conflicts between developers and researchers, or even between me and myself when I’m in a research task vs. development task?
The approach
Separate research code from Production code into different files, or even dedicate a project to it (much like a “Sandbox” test in a testing project).I’m sure that there are many ways to approach this conflict, here’s mine:
Separate Research Code
The difficulty
I’m overwhelmed by the amount of places where bugs can hide in my algorithmic code…
The approach
Cover all the basic building blocks of the algorithm with tests. For example, if you’re in Computer Vision areas: Projection of world point onto a distorted camera model, and the other way around – pixel to ray. Also test fundamental algorithms like Segmentation (of some basic easy to test examples). If you use graph algorithms – all graph building and graph iteration should be checked.
Reduce risks where possible
The difficulty
  1. I have several modified versions of the same algorithm. Often enough, I want to evaluate them all and compare results.
  2. I have difficulty to fix bugs in my algorithm since it takes a lot of time till I get to the point where it fails! Therefore each attempt to fix the problem takes a long time to test!
  3. I’ve got to a point where it works OK. Now I’m afraid to insert further improvements. How will I know I didn’t harm it?
The best algo-implementation design
The approach
  1. You can write several “Algo-Runners” instead of just one, while not having to modify the underlying data structure, and not overloading one runner with multiple branching options.
  2. Dump to disc the Algo-Data right before the program stumbles upon the current bug. Now you’ll be able to write a test that loads the data and reproduces the error!
  3. You can always add new Algo-Runner with modifications. It’s research phase threfore duplicating code is not so bad as long as you remember not to leave it like that when you move to production.
Every algorithm has it’s “steps” and required intermediate data. Create a class with all those intermediate data as public members (struct if you’re on C++) – since you have nothing to hide as long as the research goes on. I’ll call this class the “Algo-Data” class since its members are filled with meaningful data during the execution of the algo.
Then, create an “Algo-Runner” class who’s job is to execute the relevant functions in the correct order. The Algo-Runner is what’s used in the rest of the code. Algo-Data and related functions are where the research takes place.
Create a well tested serialization and deserialization for the Algo-Data class. This will allow you start debugging form the middle of an algorithm execution.
Let’s see how it answeres the concernes presented above:
When you have a new idea/elaboration for your algorithm, that would inevitably lead to significant changes, get back to “Separate Research Code” paragraph above! The best way to go here is to copy all the code to a new file, rename the Algo-Data class to something like <You_Algo_Data_Class_Name> + “_V2” (i.e., 2nd Version), and modify it there. Of course, with a separate Algo-Runner.
BUT! It’s not DRY! (DRY = Don’t Repeat Yourself) ! True. But it’s still research. And you’d better keep a working version of the algo before modifications instead risk it all and dig into versions of source control if it doesn’t work out.
The Algo Elaboration Move
As soon as the algorithm becomes stable, pack it and supply it as a tool to the rest of the team. Don’t be selfish ???? . If you want to elaborate it further, get back the previous paragraph ????
Wishing you enjoyable and productive coding,
Shmuel
The Algo Collaboration
Made on
Tilda