DEV Community: Dimitrii Lyomin

Demonstrating Bias and Mitigation in a Simple Clinical ML Pipeline

Dimitrii Lyomin — Thu, 18 Dec 2025 12:26:53 +0000

A Minimal Case Study of Bias in Clinical Machine Learning

Repository: https://github.com/lemind/clinical-ml-bias-demo

Background

This project was done as part of a university course on machine learning in clinical settings.

The course focused on bias and fairness in ML, clinical risk, interpretability, and the limits of technical mitigation in real-world systems.

One of the key inspirations was Ntoutsi et al. (2020), “Bias in Data-Driven AI Systems”[1], which emphasizes that bias can appear at all stages of an ML pipeline and that mitigation is usually partial and involves trade-offs.

The goal of this project was not to build a strong predictive model, but to:

demonstrate bias,
measure it explicitly,
and apply a simple mitigation strategy.

Problem Setup

We simulate a basic clinical prediction task using synthetic data:

Features: age, sex, severity score
Target: binary clinical outcome

Sex is treated as a protected attribute.

Bias is intentionally introduced so that female patients are more likely to be missed by the model.

This setup reflects real clinical scenarios where historical or systemic biases are encoded in data.

Method

Tools

Python
NumPy, Pandas
scikit-learn
Logistic Regression (interpretable baseline)

Steps

Generate biased synthetic clinical data
Train a logistic regression model
Evaluate performance by subgroup
Measure False Negative Rate (FNR) per group
Apply post-processing mitigation

False negatives were chosen as the primary metric due to their clinical relevance.

Results

Baseline (default threshold = 0.5)

Overall accuracy: 0.593
False Negative Rate (male): 0.468
False Negative Rate (female): 0.925

The model misses most positive cases for female patients, despite acceptable overall accuracy.

After mitigation (group-specific threshold)

False Negative Rate (male): 0.468
False Negative Rate (female): 0.094

The disparity is substantially reduced without retraining the model.

Interpretation

Mitigation was applied at decision time, not during training.

A more sensitive threshold was used for the disadvantaged group.

This improves recall for female patients but implicitly increases false positives, illustrating a real clinical trade-off.

The outcome aligns with the arguments of Ntoutsi et al. (2020):

bias mitigation redistributes errors rather than eliminating them.

Limitations

Synthetic data lacks real clinical complexity
Only one protected attribute was considered
Thresholds were manually chosen
Not all fairness metrics were evaluated

Despite this, the example effectively demonstrates key concepts from the course.

Conclusion

This project shows that:

bias can exist even in simple, interpretable models
overall accuracy can hide clinically important disparities
mitigation strategies reduce harm but introduce trade-offs

Bias in clinical ML is not purely a modeling issue, but a system-level problem, consistent with current research.

[1] - Ntoutsi, E., Fafalios, P., Gadiraju, U., Iosifidis, V., Nejdl, W., Vidal, M.-E., Ruggieri, S., Turini, F., Papadopoulos, S., Krasanakis, E., Kompatsiaris, I., Kinder-Kurlanda, K., Wagner, C., Karimi, F., Fernandez, M., Alani, H., Berendt, B., Kruegel, T., Heinze, C., Broelemann, K., Kasneci, G., Tiropanis, T., & Staab, S. (2020). Bias in data-driven artificial intelligence systems—An introductory survey. Wiley Interdisciplinary Reviews: Data Mining and Knowledge Discovery, 10(3), e1356. https://doi.org/10.1002/widm.1356

Suspense and Fiber: The Intricate Machinery Behind React's Rendering Elegance

Dimitrii Lyomin — Mon, 16 Sep 2024 09:43:36 +0000

React Fiber, the heart of React's concurrent rendering, enables the framework to break down tasks into smaller units and prioritize more important tasks, allowing for smoother and more responsive user interfaces. When paired with Suspense, it allows React to "suspend" rendering, displaying a fallback UI while waiting for tasks like data fetching or computations to finish.

A Fiber is a JavaScript object that represents a unit of work in React. It holds important information about a component during the rendering process:

All the code in that article is pseudo. You can find real files links in the end of the article

{
  tag,                // The type of fiber (e.g., HostComponent, FunctionComponent)
  stateNode,          // The actual DOM node or instance for class components
  memoizedProps,      // Props used during the last render
  memoizedState,      // State used during the last render
  return,             // Parent fiber
  sibling,            // Next sibling fiber
  child,              // First child fiber
  alternate,          // Link to the previous fiber (for reconciling updates)
}

The fiber tree allows React to efficiently traverse the component tree, perform rendering work, and track updates, state, and DOM mutations.

Let's build a simple app consisting of Header, Content, and Footer components. To highlight how Fiber works, we’ll make Header perform a heavy computation.

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Header />
      <Content />
      <Footer />
    </Suspense>
  );
}

function Header() {
  // Simulating heavy computation
  for (let i = 0; i < 1e9; i++) {}
  return <h1>Header with heavy computation</h1>;
}

function Content() {
  return <p>This is the content area</p>;
}

function Footer() {
  return <footer>Footer content</footer>;
}

How it starts? The render function is responsible for starting the initial rendering process in React. It takes a root component (like App) and creates the initial fiber tree for React to work on:

function render(element, container) {
  const rootFiber = {
    tag: HostRoot,           // Root fiber tag
    stateNode: container,    // Reference to the DOM container
    child: null,             // Initial child will be added here
  };

  // Create a new work-in-progress fiber for our App component
  const appFiber = createFiberFromElement(element);
  rootFiber.child = appFiber;

  // Start the rendering process
  scheduleWork(rootFiber);
}

Then work scheduling take into an action. scheduleWork is responsible for starting the work loop and processing the fiber tree. It determines when to start processing work, often using workLoop.

function scheduleWork(rootFiber) {
  nextUnitOfWork = rootFiber; // Set the root fiber as the starting point
  requestIdleCallback(workLoop); // Begin processing fibers when the browser is idle
}

Here, the root fiber is set as the nextUnitOfWork, and React schedules the workLoop function to process it. React uses requestIdleCallback to wait until the browser is idle before starting the work, which is essential for non-blocking rendering.

As mentioned earlier, workLoop and performUnitOfWork handle the actual processing of fibers. This is Reconciliation Phase.

workLoop processes each fiber by calling performUnitOfWork until all tasks are complete or the browser needs to prioritize other tasks.

function workLoop() {
  while (nextUnitOfWork && !shouldYield()) {
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork); // Perform work for the next fiber
  }

  if (!nextUnitOfWork) {
    // Commit all completed work to the DOM
    commitRoot();
  } else {
    // Yield control and schedule the next chunk of work
    requestIdleCallback(workLoop);
  }
}

performUnitOfWork processes individual fibers, checking for Suspense boundaries, starting rendering tasks, and managing updates.

function performUnitOfWork(fiber) {
  const next = beginWork(fiber);

  // If there's more work to do, return the next unit
  if (next) {
    return next;
  }

  // Otherwise, complete the work and move to the next sibling or parent
  let sibling = fiber.sibling;
  if (sibling) {
    return sibling;
  }

  return fiber.return;
}

function beginWork(fiber) {
  if (fiber.tag === SuspenseComponent) {
    if (fiber.suspenseState === Suspended) {
      // Render fallback UI if data is not ready
      return fiber.fallback;
    } else if (fiber.suspenseState === Resolved) {
      // Render actual content once data resolves
      return fiber.child;
    }
  }

  // Continue rendering for other fibers
}

After completing all the units of work, commitRoot is responsible for committing the fiber tree to the DOM, including handling Suspense fallback UI. This is Commit Phase.

function commitRoot() {
  let fiber = rootFiber;

  while (fiber) {
    if (fiber.tag === SuspenseComponent && fiber.suspenseState === Suspended) {
      // Commit fallback UI if Suspense is active
      updateDOM(fiber.stateNode);
    } else {
      // Commit normal content
      updateDOM(fiber.memoizedProps);
    }

    // If the fiber has a passive effect (i.e., useEffect), schedule it
    if (fiber.effectTag === Passive) {
    // Function to schedule the useEffect hooks to run after the DOM updates and browser paint
      scheduleEffectHooks(fiber);
    }

    fiber = fiber.next;  // Move to the next fiber in the tree
  }
}

During the commit phase, React invokes scheduleEffectHooks for any fiber that has side effects (like useEffect). These hooks are deferred until after the DOM updates and browser paints to avoid blocking the rendering process. This allows React to perform non-blocking updates while ensuring that side-effects are executed in a timely manner once the UI is stable.

In this article, we explored the inner workings of React's Fiber architecture and how Suspense interacts with it to enhance the rendering process. We learned how React breaks down rendering tasks into smaller units, prioritizes important tasks, and defers less critical updates to keep the user interface smooth and responsive.

We gained a clear understanding of the fiber tree structure, the work scheduling process, and how reconciliation and commit phases work to update the DOM efficiently. We also explored how Suspense integrates within this architecture, displaying fallback content while awaiting data or heavy computations.

If you have any feedback or thoughts on the article—whether parts are unclear or could be improved—I’d be glad to hear them. Your insights will help refine and enhance the content for everyone.

Sources and original implementations:

Merge Sort Demystified: A Beginner's Guide to Divide and Conquer Sorting

Dimitrii Lyomin — Thu, 12 Sep 2024 10:14:19 +0000

Merge Sort was introduced by John von Neumann in 1945, primarily to improve the efficiency of sorting large datasets. Von Neumann's algorithm aimed to provide a consistent and predictable sorting process using the divide and conquer method. This strategy allows Merge Sort to handle both small and large datasets effectively, guaranteeing a stable sort with a time complexity of O(n log n) in all cases.

Merge Sort employs the divide and conquer approach, which splits the array into smaller subarrays, recursively sorts them, and then merges the sorted arrays back together. This approach breaks the problem into manageable chunks, sorting each chunk individually and combining them efficiently. As a result, the algorithm performs well even on large datasets by dividing the sorting workload.

Recursion is a process where a function calls itself to solve a smaller version of the same problem. It keeps breaking the problem down until it reaches a point where the problem is simple enough to solve directly, which is called the base case.

Below is an implementation of Merge Sort in JavaScript, showing how the array is recursively split and merged:

function mergeSort(arr) {
    if (arr.length <= 1) return arr;

    const mid = Math.floor(arr.length / 2);
    const left = mergeSort(arr.slice(0, mid));
    const right = mergeSort(arr.slice(mid));

    return merge(left, right);
}

function merge(left, right) {
    let result = [];
    while (left.length && right.length) {
        if (left[0] < right[0]) result.push(left.shift());
        else result.push(right.shift());
    }
    return result.concat(left, right);
}

To better understand how Merge Sort works, let's walk through the process using the array: [38, 27, 43, 3, 9, 82, 10]

Step 1: Recursive Division (mergeSort function)
The array is recursively split into smaller subarrays until each subarray has only one element. This happens through the following lines in the mergeSort function:

function mergeSort(arr) {
    if (arr.length <= 1) return arr;

That stops our recursion.

Here’s how the recursive division unfolds:

Initial Call: mergeSort([38, 27, 43, 3, 9, 82, 10])
- The array is split at the midpoint: [38, 27, 43] and [3, 9, 82, 10]
First Half:
- mergeSort([38, 27, 43])
  - Split at the midpoint: [38] and [27, 43]
- mergeSort([27, 43])
  - Split into [27] and [43]
- Subarrays [38], [27], and [43] are now individual elements and ready to be merged.
Second Half:
- mergeSort([3, 9, 82, 10])
  - Split at the midpoint: [3, 9] and [82, 10]
- mergeSort([3, 9])
  - Split into [3] and [9]
- mergeSort([82, 10])
  - Split into [82] and [10]
- Subarrays [3], [9], [82], and [10] are now ready to be merged.

Step 2: Merging the Sorted Subarrays (merge function)
Now, we start merging the subarrays back together in sorted order using the merge function:

function merge(left, right) {
    let result = [];
    while (left.length && right.length) {
        if (left[0] < right[0]) result.push(left.shift());
        else result.push(right.shift());
    }
    return result.concat(left, right);
}

Here’s how the merging process works:

First Merge (from the base cases):

Merge [27] and [43] → Result is [27, 43]
Merge [38] with [27, 43] → Result is [27, 38, 43]

At this point, the left half of the array is fully merged: [27, 38, 43].

Second Merge (from the base cases):

Merge [3] and [9] → Result is [3, 9]
Merge [82] and [10] → Result is [10, 82]
Merge [3, 9] with [10, 82] → Result is [3, 9, 10, 82]

Now, the right half is fully merged: [3, 9, 10, 82].

Step 3: Final Merge
Finally, the two halves [27, 38, 43] and [3, 9, 10, 82] are merged using the merge function:

Compare 27 (left[0]) and 3 (right[0]). Since 3 < 27, add 3 to the result.
Compare 27 and 9. Add 9 to the result.
Compare 27 and 10. Add 10 to the result.
Compare 27 and 82. Add 27 to the result.
Compare 38 and 82. Add 38 to the result.
Compare 43 and 82. Add 43 to the result.
Add the remaining element 82 from the right array.
The fully merged and sorted array is:
[3, 9, 10, 27, 38, 43, 82].

Time Complexity: Best, Average, and Worst Case: O(n log n)
Let's look at it closer:

Dividing (O(log n)): Each time the array is split into two halves, the size of the problem is reduced. Since the array is divided in half at each step, the number of times you can do this is proportional to log n. For example, if you have 8 elements, you can divide them in half 3 times (since log₂(8) = 3).

Merging (O(n)): After dividing the array, the algorithm merges the smaller arrays back together in order. Merging two sorted arrays of size n takes O(n) time because you have to compare and combine each element once.

Overall Complexity (O(n log n)): Since dividing takes O(log n) steps and you merge n elements at each step, the total time complexity is the multiplication of these two: O(n log n).

Space Complexity: O(n)
Merge Sort requires extra space proportional to the size of the array because it needs temporary arrays to store the elements during the merge phase.

Comparison to Other Sorting Algorithms:
QuickSort: While QuickSort has an average time complexity of O(n log n), its worst case can be O(n^2). Merge Sort avoids this worst-case scenario, but QuickSort is generally faster for in-memory sorting when space is a concern.
Bubble Sort: Much less efficient than Merge Sort, with a time complexity of O(n^2) for average and worst-case scenarios.

Real World Usage
Merge Sort is widely used for external sorting, where large datasets need to be sorted from disk, as it efficiently handles data that doesn’t fit into memory. It's also commonly implemented in parallel computing environments, where subarrays can be sorted independently, taking advantage of multi-core processing.

Moreover, libraries and languages such as Python (Timsort), Java, and C++ (std::stable_sort) rely on variations of Merge Sort to ensure stability in sorting operations, making it particularly suitable for sorting objects and complex data structures.

Conclusion
Merge Sort continues to be a fundamental algorithm in both theoretical computer science and practical applications due to its stability, consistent performance, and adaptability for sorting large datasets. While other algorithms like QuickSort may perform faster in certain situations, Merge Sort’s guaranteed O(n log n) time complexity and versatility make it invaluable for memory-constrained environments and for maintaining the order of elements with equal keys. Its role in modern programming libraries ensures it remains relevant in real-world applications.

Sources:

Knuth, Donald E. The Art of Computer Programming, Vol. 3: Sorting and Searching. Addison-Wesley Professional, 1997, pp. 158-160.
Cormen, Thomas H., et al. Introduction to Algorithms. MIT Press, 2009, Chapter 2 (Merge Sort), Chapter 5 (Algorithm Complexity), Chapter 7 (QuickSort).
Silberschatz, Abraham, et al. Database System Concepts. McGraw-Hill, 2010, Chapter 13 (External Sorting).
"Timsort." Python Documentation, Python Software Foundation. Python's Timsort
"Java Arrays.sort." Oracle Documentation. Java's Arrays.sort()