Ugur Arikan orxfun

Hi, I'm Uğur Arıkan

Operations Research (OR) Scientist / Practitioner (wiki)
Middle East Technical University & Singapore University of Technology and Design
Located in Bonn Germany, working at DHL
| github | email | linkedin | cv | crates | nuget |

All things OR, optimization, networks, routing, algorithms, multi objective decision making.

Programming, algorithms, data structures, speed, efficiency and recently concurrency.

Also love programming languages:

An expressive, efficient and productive mathematical programming / modeling crate for rust.

macro-free and concise api which does not require more lines than model-on-paper has
concise, simple, solver agnostic, immutable, type safe
with a separation of model and data, and hence, enable abstraction over inputs
with reusable & composable model components
below is a demo of my attempt in C# and here is the documentation

Working more and more on concurrent programming and parallel processing in rust. One thing lead to another, and I got more and more interested:

First, worked on defining the PinnedVec trait and its implementations such as the SplitVec and FixedVec. A pinned vector is nothing but a vector which keeps its elements pinned in their memory locations.
Turns out this feature is very useful in defining concurrent collections such as ConcurrentBag, ConcurrentVec or ConcurrentOrderedBag. This allows to write outputs of a computation concurrently.
Then, the missing piece is to provide inputs concurrently with the convenience of an iterator. And hence, the ConcurrentIter.
Having concurrent readers and concurrent writers, we can have a very simple yet very performant parallel iterator Par.

Working on convenient and efficient self referential collections.

Such collections are common building blocks of data structures used in many algorithms, but they are tricky to build in rust, certainly trickier than garbage collected languages.
The goal is to define how to create such collections safely and efficiently in rust.
Again the PinnedVec serves as the starting point since we want our references to stay valid.
Second goal is to define and provide core functionalities of such collections. SelfRefCol aims to serve as the core structure for self referential collection.
As the first consumer, worked on building the famously tricky LinkedList on top of SelfRefCol, which turned out to be very efficient.
Efficient & flexible trees 🌴 and graphs are in progress. To continue with graphs.

working on efficient data structures as I need in algorithms, such as PriorityQueue trait and efficient d-ary heap implementations.
and whenever I have time, I am trying some experimental ideas such as Closure and FunVec.