Coder Legion - Recent posts tagged data-structures

Arrays are dumb. So are tuples.

Tue, 29 Sep 2026 14:43:13 +0000

The array/tuple question was never meant to be a long running thing. And as it often happens, the solution was right there in front of me the whole time.

Arrays are intuitive, fast, and let you do (basically) anything. Therein lies the problem with them, no type-constraint, no tracking (other than what you keep in your head).

Tuples are almost exactly the opposite. Powerful, dependable (in and of themselves), type-safe at the position level. But they are awkward, and tend to make code that depends on them, more brittle.

When a debate goes back and forth multiple times with NO NEW INFORMATION being submitted; it tends to devolve into an interminable loop. The only way to break the cycle is to add data, or perspective. The second is honestly the more powerful, by far.

So, what is the perspective that this question is inspected from? "a programming language needs arrays, tuples, or both." There, simply by stating what the subject is in clear terms, we can start to see that the problem is in the perspective itself.

"A programming language needs an ordered-sequence data-structure" (hyphens were hand typed, mmm). Now just look at that! The solution practically bites you on the nose.

Don't use arrays or tuples.

A "tape" is a "constrained by use-case" data sequence. You can think of it as an array with a la carte permissions. With no permissions, a tape explicitly declared will remain exactly that forever.

<primes:int[]=[2, 3, 5, 7]/>

@primes.push(11)                       // error: length is fixed
@primes[0] = 1                         // error: positions are read-only
@primes = [1, 2, 3]                    // error: replacing the whole thing is its own permission
const big = @primes.map(p => p * 10)   // fine: map returns a new value

The sequence itself is frozen: no appends, no removals, no reordering, no swapping one element for another. The elements are exactly as frozen as their own type says. If the type of the thing on the tape has a writable field, that field is writable, tape or no tape. Same rule, all the way down.

<todo:struct>
    <title:string=""/>
    <let done:bool=false/>       // this field grants its own write
</>

<todos:todo[]=[...]/>            // a tape with no permissions

@todos[0].done = true            // fine: judged by `done`, not by the tape
@todos[0].title = "x"            // error: title is locked
@todos.push(t)                   // error: the tape is frozen

The obvious way to build this is a list of allowed methods: this tape may push, that one may pop. That breaks immediately. @log = @log.slice(1) throws away the first entry using nothing but a non-mutating method and an assignment. No banned method was called. So a tape's permissions aren't a list of methods, they're axes: how the length may change, where changes may happen, whether a position may be rewritten. The compiler judges every write by what it DOES to the value, not by how it's spelled. slice(1) is a change at the front. If the tape doesn't allow front changes, that line doesn't compile.

Here's an audit log. Free length, changes only at the end, and nothing else:

type Entry:struct = { at: number, actor: string, action: string }

<audit:Entry[free, end]=[]/>

@audit.push(entry)                          // fine
@audit = [...@audit, entry]                 // same edit, different spelling: fine
@audit.shift()                              // error: a change at the front
@audit = @audit.slice(1)                    // error: still a change at the front
@audit = @audit.filter(e => e.actor != "x") // error: a removal from anywhere
@audit = []                                 // error: a replace
reset(@audit)                               // error: reset is a replace too

No statement anywhere in the program can remove or rewrite an entry, however it's spelled. That log is provably append-only, and the proof costs you one line.

The permissions are part of the tape's type, so they travel. A function only gets to do what its parameter says:

fn pushEdit(s: Edit[end], e: Edit) -> Edit[end] {
    return [...s, e]             // the only thing this function CAN do to `s`
}

<undo:Edit[end]=[]/>
@undo = pushEdit(@undo, e)       // fine: the compiler reads the body and sees an append at the end

There's no "all permissions" switch. A fully mutable tape has to name every axis it wants. An all-grant is a leaky abstraction, unacceptable.

<todos:Todo[free, anywhere, writable, replace]=[]/>

Every axis named. No shorthand. That's the point.

The tape is specified in the scrml language spec (§66.12) and is being built into the new compiler now. It is not in the shipping compiler yet, and the permission syntax shown here is the proposed spelling.

What Should Texas Businesses Look for in an ERP Software Development Company?

Fri, 11 Sep 2026 07:54:10 +0000

Texas has one of the most diverse business environments in the United States. Companies across energy, manufacturing, technology, healthcare, logistics, retail, construction, and professional services operate across the state. Because each industry has different operational requirements, choosing the right ERP technology partner requires careful evaluation.

A good ERP software development company in Texas should do more than provide software. It should understand business processes and help organizations create a technology environment that supports efficiency and future growth.

1. Industry Understanding

ERP requirements vary significantly between industries.

For example, an oil & gas company may need joint venture accounting, AFE management, production reporting, royalty calculations, and asset management. A manufacturer may prioritize production planning, BOM management, quality control, procurement, and inventory.

Texas businesses should therefore look for an ERP partner with experience understanding industry-specific processes.

2. Customization Capabilities

Standard ERP functionality may cover many common processes, but organizations often have unique workflows.

The ERP provider should be able to configure or customize workflows, reports, forms, modules, and integrations where necessary.

The objective is to make the system useful for the business without introducing unnecessary complexity.

3. Integration Experience

Modern businesses rarely operate using one application.

An ERP environment may need to connect with CRM, eCommerce, banking, payment, warehouse, IoT, or other systems.

An experienced ERP partner should understand how these integrations can improve data flow and reduce duplicate work.

4. Implementation Methodology

A strong ERP platform can still fail if implementation is poorly managed.

Businesses should ask potential providers about their approach to requirements gathering, configuration, data migration, testing, employee training, go-live, and post-launch support.

A structured methodology can help reduce implementation risks.

5. Scalability

The ERP system should support future business growth.

Texas organizations may expand into new markets, add locations, increase users, or introduce new products and services. The technology should be flexible enough to support these changes.

6. Support and Training

Employees need training to adopt a new ERP successfully. Businesses should also have access to technical support after implementation.

Matiyas Solutions provides end-to-end ERP services including consulting, implementation, customization, integration, training, support, and optimization for businesses across Texas.

7. Location-Specific Requirements

Texas businesses may have requirements related to industries, taxation, payroll, healthcare privacy, cross-border trade, energy operations, and other regulatory considerations.

An ERP provider that understands the Texas business environment can help organizations plan technology around these requirements.

Conclusion

Choosing an ERP software development company in Texas should be based on more than price or a list of software features.

Businesses should evaluate industry expertise, customization, integrations, implementation methodology, scalability, training, and ongoing support.

With the right ERP partner, Texas organizations can build a connected technology environment that supports operational efficiency and long-term growth.

visit - https://www.matiyas.com/en-us/erp-solutions-in-texas/

Backtracking Finally Clicked When I Fixed One Habit

Thu, 21 May 2026 16:14:14 +0000

For a long stretch, backtracking was the topic I quietly dreaded. The recursion was easy enough to write. The code ran. It even returned answers. They were just wrong, and not in a way that threw an error you could chase. A Combination Sum solution would spit out duplicate-looking results with no obvious culprit line. The fix, when it came, had nothing to do with understanding recursion better. It was one habit that kept getting skipped.

Here's what changed once backtracking stopped being a clever trick and became a fixed loop.

What changed

Backtracking is a depth first walk over a state space tree, and the tree is the part worth drawing first.
The loop is always the same: choose an option, check the constraint, undo the choice on the way back up.
The undo step is the easiest to drop, and dropping it silently corrupts later branches.
Pruning before you recurse, not after you reach a leaf, is where the speed lives.
Once the same partial state repeats across branches, the whole thing becomes top down DP.

Where my backtracking kept breaking

The mistake was always the same, and naming it took embarrassingly long. You build a partial solution by mutating a shared list, recurse, then move on to the next option without ever putting the list back the way you found it. So branch two starts with branch one's leftovers still inside it.

What broke wasn't the recursion. It was that the path never got restored on the way back up.

The reason it's so hard to catch: nothing crashes. A forgotten undo doesn't raise an exception. It quietly hands stale state to the next branch, and the answers look plausible until you check them by hand. That single omission costs more debugging time than any actual algorithmic concept.

Picture it concretely on a small Combination Sum case, candidates [2, 3] and target 5. The first branch explores [2, 2, ...], overshoots, and returns. If that branch left a stray 2 in the shared list, the next branch starts from [2] when it should start from []. Now the [3, ...] branch is really exploring [2, 3, ...], and the result set fills with combinations that were never asked for. Reading the function top to bottom, every line looks reasonable. The bug only shows up when you trace the shared list across two sibling branches and notice it isn't the same length going in as coming out.

What I started doing differently

The shift was to stop writing backtracking freehand and write the same three line frame every time, then fill it in. Choose, check, undo, in that order, with the undo non negotiable. Here's the before and after, once it became a fixed habit:

Then	Now
Recursion written ad hoc, undo when remembered	Choose, check, undo written as a fixed frame first
Constraints checked at the leaf	Constraint checked before recursing, so dead branches die early
Debugged by re-reading the whole function	Trace one branch, confirm state is restored after the call
Each problem treated as new	Slot the problem into one of three known shapes

The "check before recurse" row mattered more than expected. Pruning at the leaf still gives correct answers, it's just slow, and on a tight time limit slow is the same as failing.

What that looked like on Combination Sum

Combination Sum is the problem that finally made it click for me. Given a list of candidates and a target, find every combination that sums to the target, where a number can be reused. It's a conditional enumeration problem, so you prune any branch whose running sum overshoots.

Here's the frame, filled in:

def combination_sum(candidates, target):
    result = []

    def backtrack(start, path, remaining):
        if remaining == 0:
            result.append(path[:])      # finished combination
            return
        if remaining < 0:
            return                      # overshot, prune this branch
        for i in range(start, len(candidates)):
            path.append(candidates[i])                       # choose
            backtrack(i, path, remaining - candidates[i])    # explore (reuse allowed)
            path.pop()                                       # undo

    backtrack(0, [], target)
    return result

The line that used to go missing is path.pop(). Without it, every combination after the first carries elements from the previous one. The path[:] matters too, it copies the list into the result instead of storing a reference that later pop calls would mutate out from under you. Two small lines, and they're the entire difference between a function that works and one that lies to you.

The start index is the other quiet detail. Passing i rather than i + 1 into the recursive call is what allows a number to be reused. Pass i + 1 and you've written a different problem, combinations without repetition. Same frame, one parameter changes the meaning.

Why undoing state is the whole game

With the frame in hand, the three problem shapes read as one idea seen from different angles:

Unconditional enumeration, like all subsets, has no constraint, so you walk the whole tree and every node is an answer.
Conditional enumeration, like Combination Sum or valid parentheses, prunes branches that break a rule mid build.
Backtracking search, like N-Queens or Sudoku, looks for configurations under a global constraint and prunes hardest.

All three run the same choose, check, undo loop. The undo is what lets one mutable structure stand in for every node of the tree without the nodes contaminating each other. That's the thing I ended up rebuilding my own approach around.

It also reframes how the three shapes relate. They aren't three separate algorithms to learn. They're one loop with the constraint check dialled from off (subsets) to mid build (Combination Sum) to every level (N-Queens). Seeing them as one thing meant a new problem stopped being a blank page. The question became which shape it was and what the constraint was, and the frame handled the rest.

What I'd tell someone stuck on this

If you're losing time to backtracking that returns wrong answers, the fix is almost never more practice on harder problems. Grinding ten more search problems with the same blind spot just produces ten more silently wrong solutions. The thing standing between you and reliable backtracking is usually one missing line, not a missing concept. It's two habits. First, write the undo line at the same moment you write the choose line, as a pair, before anything else in the loop. Second, trace one full branch on paper and confirm the shared state looks identical before and after the recursive call.

And if the recursion itself still feels unstable underneath all this, that's worth shoring up first, because backtracking is just recursion with the choose, check, undo wrapper on top. Going back through the recursion lessons before touching backtracking again is what makes the wrapper feel mechanical instead of magical.

I originally posted this on my own blog, a slightly longer version with the N-Queens trace and a few more worked examples.

What's a bug that taught you more than the algorithm itself? For a lot of people backtracking is the one where a missing undo quietly breaks everything.

AVL Trees Explained: The Rotation Patterns Most People Memorise Wrong

Wed, 20 May 2026 19:57:13 +0000

The first time an interviewer asked me to walk through an LR rotation on a whiteboard, the four-case table was memorised cold. LL, RR, LR, RL. The interviewer drew three nodes, asked which case it was, and the answer came out fast. Then they asked: "predict what a single right rotation would do to that tree, and tell me why it fails." That part hadn't been drilled. The grade went out as "knows the table, didn't internalise the invariant."

What I figured out

The four rotation cases are not four things. They're two atomic moves applied once or twice.
The balance factor is the rule being protected, not a check. Every rotation is a local repair on the rule |left_height - right_height| <= 1.
Insertion needs at most one rotation. Deletion can need O(log n). That asymmetry is the answer to every "what's the tradeoff" question.
The double-rotation cases exist because a single rotation on an "inside" imbalance shifts the heavy side without reducing the depth.
Knowing the two atomic moves is enough to derive both LR and RL cases. Memorising the table on top is the wrong study target.

Where my approach was breaking

Three failure modes showed up on those rounds, and they show up in most engineers preparing for the same kind of question.

The four-case table got memorised without anyone tracing why each fix works. The table is a lookup. Interviewers test for the derivation. When a tree shows up on the board and the question is "what's the imbalance shape here," pattern matching against a remembered picture fails when the tree is rotated or relabelled.

Insertion got drilled, deletion didn't. Insertion is the cleaner operation. Almost every textbook walks insertion. Few walk deletion with the upward rebalance loop. Knowing "deletion is harder" as a phrase is not the same as knowing what concretely makes it harder.

Wrong rotations never got sketched. When an interviewer asks "what happens if you apply a single right rotation to an LR case," the answer has to come from a drawing, not a memory. Engineers who've never traced a failed rotation can't answer this on the spot.

What I started doing differently

Then	Now
Memorise LL / RR / LR / RL as four rotations	Internalise two atomic rotations and derive the four cases from balance factor signs
Practice insertion only	Practice deletion with the upward loop, including the worst-case `O(log n)` rotation chain
Treat balance factor as a check	Treat balance factor as the invariant being protected, with rotations as the local repair
Draw rotated trees from memory	Draw the pointer assignments explicitly and recompute heights before moving on
Skip wrong-rotation traces	Sketch what each wrong rotation does on an LR case, so the trap is recognisable under pressure

The "now" column is what interviewers actually probe. The "then" column is what most prep material asks you to drill.

The first rule that locks in is this. If you see a node with balance factor +2, the next look is at the left child's balance factor, not at the rotation table. If the left child is +1 or 0, single right rotate the parent. If the left child is -1, left rotate the left child first, then right rotate the parent. The decision is two questions, not a memorised table.

What that looked like on the next problem

Six months later, a different round asked for AVL insertion implementation. The sequence used to motivate the walk-through was [5, 3, 4], which fires an LR rotation. Here's the primitive:

def right_rotate(z):
    y = z.left
    T3 = y.right
    y.right = z
    z.left = T3
    z.height = 1 + max(height(z.left), height(z.right))
    y.height = 1 + max(height(y.left), height(y.right))
    return y

And the insertion function:

def insert(node, key):
    if not node:
        return Node(key)
    if key < node.key:
        node.left = insert(node.left, key)
    else:
        node.right = insert(node.right, key)

    node.height = 1 + max(height(node.left), height(node.right))
    bf = balance_factor(node)

    if bf > 1 and key < node.left.key:
        return right_rotate(node)
    if bf < -1 and key > node.right.key:
        return left_rotate(node)
    if bf > 1 and key > node.left.key:
        node.left = left_rotate(node.left)
        return right_rotate(node)
    if bf < -1 and key < node.right.key:
        node.right = right_rotate(node.right)
        return left_rotate(node)

    return node

Tracing [5, 3, 4]:

Insert 5. Single node, balance factor 0.
Insert 3. Goes left of 5. Node 5's balance factor is +1. Within the rule.
Insert 4. 4 < 5, go left. 4 > 3, go right of 3. Node 4 lands as 3's right child.

Walking back up: node 4 is balance factor 0, node 3 is -1, node 5 is +2. Rule broken at node 5, with its left child right-heavy. That's LR.

First rotation: left rotation on node 3. Node 4 moves up, node 3 becomes 4's left child. Node 5 still has balance factor +2, but its left subtree is now left-heavy. That's LL.

Second rotation: right rotation on node 5. Node 4 becomes the root, node 3 is 4's left child, node 5 is 4's right child. All balance factors back to 0. Height is 1.

The interviewer asked what a single right rotation would have done to the original tree. Sketched it out: node 3 becomes the root, node 5 is 3's right child, but node 4 ends up as 3's right child too, with node 5 displaced. The tree depth does not decrease. That's why the double rotation exists.

Why this works (the height theory behind it)

The choice of ±1 as the balance factor cap is not arbitrary. It's the tightest constraint that's still cheap to maintain locally.

An AVL tree with n nodes has height at most about 1.44 * log2(n). For a million nodes that's roughly 29 levels. A perfectly balanced tree would be 20 levels. The constant factor is small enough that you get the lookup speed of a balanced tree without paying the cost of full rebalancing on every insert.

Red-Black trees relax the constraint to allow heights up to about 2 log(n). That's roughly 40 levels for a million nodes. In exchange, at most 2 rotations per insertion or deletion. Looser balance, fewer rotations, faster writes.

When Adelson-Velsky and Landis named the AVL tree in 1962, the workload they had in mind was read-heavy. Lookups dominated. The strict balance was worth the rebalancing cost because every lookup was faster. Modern systems insert and delete more than they search-only, which is why Java's TreeMap, C++'s std::map, and Linux's CFS process scheduler all picked Red-Black instead. Different workload, different tradeoff. Neither tree is "better."

That's the answer the OS interviewer was looking for. AVL is read-optimised. Red-Black is tuned for mixed workloads. Picking between them is a workload question, not a theory question.

What I'd tell someone in the same spot

Three things to drill before either interview round:

Master the two atomic moves. Write left_rotate and right_rotate from memory, with the height updates in the right order. Three pointer reassignments, two height updates. Everything else builds on these.
Trace deletion at least three times. Pick at least one trace where the rebalance propagates two levels up. That's the answer to every "what's the tradeoff of stricter balance" question.
Sketch what a wrong rotation does on an LR case. Once you've drawn the broken tree, the LR / RL trap stops being a memory test.

Codeintuition's Binary Search Tree course is structured this way. The balance invariant comes before the rotation code, and the rotation code comes before the four-case table. Doing it in that order is what made the table feel mechanical instead of memorised.

I originally posted this on my own blog, a slightly longer version with the worked example for the original [3, 2, 1, 4, 5] insertion sequence and the AVL vs Red-Black tradeoff matrix.

What's the AVL or rotation question that finally made the rule click for you, where the textbook explanation had not?

Stop Writing Trading Scripts. Start Building Senses: How I Forged an Autonomous AI trading bot

Wed, 08 Apr 2026 23:30:04 +0000

Forging Herakles-octobot: How I Built an Autonomous AI Crypto Trader (That Actually Understands Risk)

The crypto markets are a dark, unforgiving place. It is a realm of endless, 24/7 chaos where traditional algorithmic trading bots march blindly to their slaughter. You write a Python script, hook up some moving average crossovers, and watch your portfolio slowly bleed out like a foot soldier caught in the vanguard.

Traditional bots are rigid. They don't understand context. They don't know that a falling Taker Buy/Sell ratio matters more right now than a lagging MACD, or that Extreme Fear on Reddit combined with an oversold StochRSI is a contrarian powder keg waiting to ignite.

I needed to forge something stronger. Going from an aerospace engineering dropout to a telecom engineer, and ultimately finding my footing as a solo software developer here in Chicago, you learn a fundamental truth about complex, high-stakes systems: surviving the chaos requires dynamic reasoning, not just hardcoded if-statements.

So, I built an autonomous trading engine. I named it Herakles. I handed the cognitive heavy-lifting to Claude, gave it a $10k paper-trading portfolio to start, and fed it a firehose of real-time market data.

Here is a technical deep dive into how you force an LLM to stop acting like a helpful chatbot and start acting like a ruthless, calculated execution engine.

The Brain: One Prompt to Bind Them

You can't just ask an LLM, "Should I buy Bitcoin?" That is like asking a goblin to guard your gold—it will hallucinate, hedge, and give you a bulleted list of useless financial disclaimers. You have to box it in. You have to build an ironclad cognitive framework.

My system prompt doesn't ask for opinions. It dictates a strict Signal Hierarchy for 1-hour directional predictions. I force the model to weigh inputs in a very specific order.

SIGNAL HIERARCHY — what to trust for 1H predictions:

LEADING (these move price in 15-45 min — weight heavily):
  • Taker buy/sell ratio: >1.1=buy pressure, <0.9=sell pressure
  • Volume Delta (CVD): rising=buyers dominating, falling=sellers dominating
  • Orderbook imbalance: immediate supply/demand pressure at current price

CONFIRMING (validate the directional thesis):
  • Multi-TF trend alignment: 1H (45%) + 4H (35%) + 1D (20%). All aligned = high conviction
  • VWAP position: above=bullish institutional bias, below=bearish. Distance amplifies
  • RSI + StochRSI — trending: extremes = strength. Ranging: extremes = reversal

REVERSAL (these override trend signals when present):
  • RSI Divergence on 4H — strongest reversal signal in crypto
  • Extreme funding rate (>0.05%) — crowded trade will snap back

SHORT TRADE RULE:
Crypto has structural long bias. To predict DOWN, require at least 2 of:
taker ratio <0.85, CVD falling, bearish divergence, price below VWAP with declining momentum.

If the LLM wants to short a structurally long market like crypto, I require it to provide at least two heavy bearish indicators. It must prove its case mathematically before the backend allows the API call to fire.

The Nervous System: The All-Seeing Eye

An LLM is only as good as its context window. To make this work, the backend acts as an all-seeing eye, aggregating an absurd amount of data every hour. We aren't just looking at Binance price action. The bot ingests 25 data points across 3 timeframes, plus real-time derivatives flow.

Latency is the enemy. If you are trading 1-hour momentum, you need sub-second aggregation. Here is a snapshot of the internal routing matrix the script uses to build the context payload:

[
  {"Source": "Binance MTF (1H/4H/1D)", "Type": "technical", "Latency": "0ms", "Contribution": "95%"},
  {"Source": "Taker Buy/Sell Ratio", "Type": "derivatives", "Latency": "0ms", "Contribution": "90%"},
  {"Source": "Orderbook 3-Exchange", "Type": "orderbook", "Latency": "0ms", "Contribution": "80%"},
  {"Source": "VWAP", "Type": "technical", "Latency": "0ms", "Contribution": "80%"},
  {"Source": "ClankApp Whales", "Type": "onchain", "Latency": "0ms", "Contribution": "70%"},
  {"Source": "Fear & Greed Index", "Type": "sentiment", "Latency": "0ms", "Contribution": "70%"}
]

The Secret Weapon: Guarding the Hoard

Here is where 99% of experimental AI trading projects fail: they treat every trade in a vacuum.

Herakles is fully aware of its own wallet. I inject the PORTFOLIO STATE directly into the prompt alongside the market data. It knows exactly how much capital it has, its current win rate, and the exact P&L of open positions. It guards the hoard.

=== PORTFOLIO AWARENESS ===
Wallet Summary:
• Total Portfolio Value: $11,367.55 USDT
• Available Balance: $8,764.57 USDT (77.1% cash)

OPEN POSITIONS:
#1 BTC/USDT 
  ├─ Size: 0.03657800 BTC ($2,602.97 / 22.9% of portfolio)
  └─ P&L:  $+97.40 (+3.89%)

I gave it strict exposure rules. If a position is profitable >20%, it must lock in gains. If the portfolio is >70% exposed, it has to minimize new entries. It is programmed for survival first, profit second.

The Crucible: Holding the Line

Let's look at a live execution. The other day, BTC was sitting at $71,168. The macro trend was up. Traditional bots would have likely sounded the horns and slammed the "BUY" button because the price was above the VWAP and the daily MACD was glowing green.

But Herakles saw something else in the shadows. Look at the strict JSON it returned:

{
  "step_analysis": {
    "flow": "BEARISH LEADING SIGNALS: Taker ratio 0.819 (<0.9 = sell pressure), CVD falling (sellers dominating). Orderbook +18.9% provides minor support. Leading indicators conflict with uptrend - suggests pullback in progress.",
    "momentum": "MIXED. StochRSI=15 OVERSOLD suggests bounce imminent. CRITICAL: 1H bearish RSI divergence detected - reversal warning but not on 4H.",
    "context": "Funding 0.0056% healthy. Fear index 17 = EXTREME FEAR (strong contrarian buy). Whale activity extreme at $2.3B."
  },
  "prediction": "up",
  "confidence": 54,
  "signal_strength": "neutral_long",
  "invalidation_condition": "Price breaks below S1 $70,496 with increasing volume, or taker ratio drops below 0.75",
  "suggested_levels": {
    "stop_loss": "$70,496 (S1 pivot)",
    "take_profit_1": "$71,540 (R1 pivot)"
  },
  "reasoning": "Uptrend intact but short-term flow is bearish (taker 0.819, CVD falling). However, StochRSI oversold + extreme fear suggests pullback nearing exhaustion. Low confidence due to conflicting leading indicators. Already hold 22.9% BTC at +3.89% profit - no need to add with mixed signals. Hold existing position.",
  "position_action": null
}

It decided to do nothing. It recognized the bullish macro structure but saw the leading bearish flow (falling CVD, low taker ratio). More importantly, it looked at its portfolio, saw it already had 22% exposure in a profitable position, and decided the risk/reward simply wasn't there to throw more capital into the fray.

That level of restraint—choosing to HOLD the line in the face of conflicting data—is something most human traders take years and thousands of dollars in liquidations to learn.

The Execution: Raising the Shield Wall

But deciding to "HOLD" doesn't mean the system is sleeping. It means it switches from acquisition mode to defense mode.

While it declined to allocate new capital, the engine autonomously calculated and placed a protective shield wall around the existing position, dispatching OCO (One-Cancels-the-Other) orders to the exchange:

[
  {
    "Pair": "BTC/USDT",
    "Type": "STOP LOSS",
    "Price": 69016.99,
    "Quantity": 0.018874,
    "TotalValue": "1302.62 USDT"
  },
  {
    "Pair": "BTC/USDT",
    "Type": "SELL LIMIT",
    "Price": 72019.58,
    "Quantity": 0.018874,
    "TotalValue": "1359.29 USDT"
  }
]

Notice the mechanical precision. It didn't just throw a blind 5% stop loss into the void. It dynamically placed the stop at $69,016—safely tucked beneath the 4H EMA50 ($68,673) and the S1 pivot to avoid getting wicked out by localized volatility. Simultaneously, it set a limit sell above to automatically lock in partial gains if the RSI divergence resolved in a quick liquidity grab.

The Road Goes Ever On

We are moving past the era of LLMs as simple code-assistants and entering the era of LLMs as autonomous execution engines. When you give an AI structured rules, massive context, and the ability to execute real API calls, the results are slightly terrifying and deeply inspiring.

I'm continuing to refine the architecture, tweaking the weights, and hunting for more alpha in the data streams. The journey is far from over.

I'm curious for the devs out there building agentic workflows:

How are you handling hallucination when the output must be strict JSON for execution? Do you use a secondary validation script before pushing to the API?
Are you using smaller, fine-tuned models for speed, or relying on heavyweights for the raw reasoning capabilities?

Let's talk about it!

see some of my other projects at https://github.com/herakles-dev

Data Structures and Algorithms on Strings

Wed, 25 Mar 2026 04:51:01 +0000

Day 1: String Algorithms Overview -

The first day of the ACM Winter School on DSA Strings began with an insightful lecture by Dr. Venkatesh Raman on essential string processing algorithms, including:

Asymptotic Analysis: Importance of Big-O notation and time/space complexity.
KMP Algorithm: Efficient pattern matching using the prefix function.
Boyer-Moore Algorithm: Focused on the bad character and good suffix rules.
Pattern Matching Techniques: Efficient substring search.
LCS & Edit Distance: Dynamic programming solutions for LCS and applications of edit distance in fields like bioinformatics.

Sriram Bhyravarapu led a hands-on tutorial where participants implemented the KMP and Boyer-Moore algorithms, practiced pattern matching, and explored dynamic programming with LCS and edit distance.

Day 2: Advanced String Algorithms -

The second day focused on advanced topics such as wildcard matching, mismatches, and suffix trees:

Wildcard Matching: Algorithms for handling * and ? characters in patterns.
Pattern Matching with Mismatches: Techniques for approximate pattern matching.
Suffix Trees: Construction and applications in substring search, longest repeated substring, and lexicographical analysis.

Sriram Bhyravarapu guided the hands-on implementation of wildcard matching, approximate pattern matching, and suffix trees, giving participants practical experience with these
advanced techniques.

Day 3: Suffix Arrays and Their Applications -

Dr. Sharma Thankachan's lecture focused on the fundamentals of suffix arrays, including their construction (Manber-Myers and Kasai's LCP algorithm) and applications in pattern matching, data compression, and bioinformatics.

Sriram Bhyravarapu guided participants through hands-on implementation of suffix arrays, LCP arrays, and applications like substring searches, longest repeated substring identification, and Burrows-Wheeler Transform (BWT) for compression tasks.

Day 4: Advanced String Data Structures and Queries -

Dr. Thankachan discussed advanced applications of suffix trees and arrays in text indexing, bioinformatics, and data compression. He also introduced K-th lexicographical substring queries and Range Minimum Queries (RMQ).

Sriram led coding exercises on K-th queries, RMQs, and their integration with suffix structures. Participants worked on real-world problems involving substring ranking, pattern matching, and optimization.

The combination of theory and practical coding exercises provided participants with a solid understanding of advanced string algorithms for solving complex real-world problems.

Day 5: Rank-Select Operations, Wavelet Trees, and Applications -

Lecture by Dr. Chirag Jain:
Introduced rank (count of occurrences) and select (position of K-th occurrence) operations.
Explained wavelet trees for efficient sequence representation and supporting queries.
Discussed real-world applications in text compression, pattern matching, and bioinformatics.

Tutorial by Sriram Bhyravarapu:
Hands-on implementation of rank-select operations and wavelet tree construction.
Solved practical problems like substring frequency and range queries.

Key Takeaways:
Gained practical skills in rank-select operations and wavelet trees for computational problems.

Day 6: Burrows-Wheeler Transform (BWT), FM-Index, and Applications -

Lecture by Dr. Chirag Jain:
Introduced BWT for text compression and FM-Index for efficient substring matching.
Discussed applications in text indexing and genomic data analysis.

Tutorial by Sriram Bhyravarapu:
Implemented BWT and FM-Index, with exercises in pattern matching and text compression.

Key Takeaways:
Mastered BWT and FM-Index, essential for text processing and genomic analysis.

Day 7: Locality-Sensitive Hashing (LSH), Bloom Filters, and Applications -

Lecture by Dr. Naveen Sivadasan:
Introduced LSH for approximate nearest neighbor searches and Bloom Filters for efficient set membership testing.
Discussed applications in image similarity, web indexing, and network security.

Tutorial by Sriram Bhyravarapu:
Implemented LSH and Bloom Filters, with exercises on query optimization and false positive rates.

Key Takeaways:
Learned advanced techniques for efficient data retrieval and set operations using LSH and Bloom Filters.

Day 8: Applications and Closing Ceremony -

Session by Dr. Naveen Sivadasan:
Explored real-world applications of LSH and Bloom Filters in data deduplication, genomic data analysis, and recommendation systems.
Highlighted their role in bridging theoretical knowledge with practical industry challenges.

Closing Ceremony: -
Reflected on the week-long program, emphasizing the advanced concepts, hands-on skills, and real-world applications covered.
Celebrated participants’ achievements and growth in tackling complex computational problems.

Key Takeaway: -
The final day reinforced the practical relevance of advanced algorithms and marked a fitting conclusion to an intensive and enriching learning journey.

Key Math Concepts in Data Structures and Algorithms

Sat, 07 Mar 2026 23:13:34 +0000

At the core of data structures and algorithms are fundamental mathematical principles that guide their design and implementation. This article explores key math concepts essential for mastering data structures and algorithms, helping developers write optimized and effective code.

Number Systems

A number system is a structured way of representing numbers using specific symbols and rules. Different number systems are based on different base values (also called the radix).

We are most familiar with the decimal number system, which is used in everyday life. It uses ten digits (0 through 9) to represent all numbers. Because it uses ten distinct digits, its base is 10.

Computers, however, operate using only two digits: 0 and 1. Therefore, they use the binary number system, which has a base of 2. All data inside a computer is ultimately stored and processed in binary form.

The octal number system uses eight digits (0 to 7) so its base is 8. It is used as a more compact way to represent binary numbers, since each octal digit corresponds to a group of three binary digits (bits). Octal is still used in certain areas of computing, such as file permissions in Unix and Linux systems.

The hexadecimal number system uses sixteen symbols: the digits 0–9 and the letters A–F. Because it has sixteen symbols, its base is 16. Each hexadecimal digit corresponds to a group of four binary digits, making it a convenient way to represent memory addresses, machine code, and other low-level data in computers.

The octal number system has a base of 8, which means it uses eight symbols: 0 to 7.
Since 8 = 2³, each octal digit can represent exactly three binary digits (bits). Same goes for hexadecimal number system.

You can learn how to convert between these number systems from this detailed article.

Now, let’s talk about the binary number system. We are familiar with representing positive numbers using unsigned binary. But how do we represent negative numbers? For this, we use the two’s complement method, which is the standard way to represent signed binary numbers.

Two's complement method

Negative of any decimal number is mathematically found by subtracting that number from 0. The same applies to the binary number system. In the signed binary number system, the most significant bit (the leftmost bit) indicates the sign of the number.

See the image below if you are not familiar with the most and least significant bits in the binary representation of a number:

Let’s take the example of decimal 7 whose binary representation is 0111. Its binary number system is stored in 4 bits. Zero can be represented as 0000 (in 4 bits). In 4-bit representation, if a fifth bit is present in the leftmost position, it is discarded due to lack of space. So, we can represent zero as 10000 (the bit 1 will be discarded). Now, 10000 can be written as the sum of 1111 and 1. We can then proceed as follows:

Essentially, the negative of a binary number will be its complement added to 1. This method is called as the two’s complement method.

Bitwise Operators

In the decimal number system, we use arithmetic operators like +, -, *, and / to perform mathematical operations. In computing, numbers are represented in binary, and in addition to arithmetic operators, we also use bitwise operators like &, |, ^, ~, >>, and << to manipulate individual bits. Let’s discuss each of these operators.

AND Operator (&)

This operator performs bit-by-bit AND operation on two values. This means that for each bit in the operands, the resulting bit is set to 1 only if both corresponding bits in the operands are 1; otherwise, it is set to 0.

Observation: The AND operation of any number with 1 gives the least significant bit (LSB) of that number.
Example: 5 & 1 results in 1 because 101 & 001 gives its LSB, which is 1.

OR Operator (|)

This operator performs a bitwise OR operation between two operands, setting each resulting bit to 1 if at least one of the corresponding bits in the operands is 1; otherwise, it is set to 0.

XOR Operator (^)

XOR stands for exclusive OR. This operator performs a bitwise comparison between two operands, setting each resulting bit to 1 if the corresponding bits in the operands are different; otherwise, it is set to 0.

Observations:

The XOR operation on any number with 1, results in a number where the least significant bit (LSB) is flipped.
Example: 3 ^ 1 results in 2 because 11 ^ 01 changes the LSB to 0 in this case.
The XOR operation on any number with 0 results in the same number.
Example: 4 ^ 0 results in 4 because 100 ^ 000 gives 100, which is 4.
The XOR operation on any number with itself results in 0 because there are no differing bits.
Example: 5 ^ 5 results in 0 because 101 ^ 101 gives 0 as there are no bits that differ.

Complement Operator (~)

The complement operator gives the bitwise inverse of a number, flipping each bit from 0 to 1 and from 1 to 0.

Left Shift Operator (<<)

The left shift operator is a bitwise operator that shifts the bits of a number to the left by a specified number of positions. Example: 5 << 1 gives 10 because shifting the bits of 5 (which is 101 in binary) one position to the left results in 1010, which is 10 in decimal. If we shift twice (5 << 2), we will get 20 because shifting the bits of 5 (which is 101 in binary) two positions to the left results in 10100, which is 20 in decimal. Therefore, each left shift operation effectively multiplies the number by 2 for each position shifted. In general, if the number is shifted k times, it is multiplied by 2^k.

Right Shift Operator (>>)

The right shift operator is a bitwise operator that shifts the bits of a number to the right by a specified number of positions. Example: 8 >> 1 gives 4 because shifting the bits of 8 (which is 1000 in binary) one position to the right results in 0100, which is 4 in decimal. If we shift twice (8 >> 2), we would get 2 because shifting the bits of 8 (which is 1000 in binary) two positions to the right results in 0010, which is 2 in decimal. Therefore, each right shift operation effectively divides the number by 2 for each position shifted. In general, if the number is shifted k times, it is divided by 2^k.

Core Number Theory

Prime Number

A prime number is a natural number greater than 1 with exactly two positive divisors: 1 and itself. To determine if a number is prime, we typically check divisibility from 2 up to n−1 since it is always divisible by 1 and itself.

int n = 24;
boolean isPrime = true;
for (int i = 2; i < n; i++) {
    if (n % i == 0) {
        isPrime = false;
        break;
    }
}
if (isPrime) {
    System.out.println("Prime");
} else {
    System.out.println("Not prime");
}

The above algorithm makes a maximum of n - 2 (2 to n-1) checks. So, its time complexity is O(N). Let's see if we can optimise it. If we closely examine the factors of any number, they appear in pairs (one smaller and one larger). Mathematically, we can say that for every divisor d > √n (like d = 6), there exists a corresponding divisor $\frac {n} {d} < \sqrt n$ (like 4). Therefore, checking beyond √n is redundant.

If we look into the above possible pairs of factors of 24, we can see that we're checking divisibility of each pair twice. It is sufficient to check divisibility only up to √n since √24 ≈ 4.89, checking up to 4 is enough. Hence, we can reduce the number of computations from the order of N to √N.

int n = 24;
boolean isPrime = true;
for (int i = 2; i * i <= n; i++) {
    if (n % i == 0) {
        isPrime = false;
        break;
    }
}
if (isPrime) {
    System.out.println("Prime");
} else {
    System.out.println("Not prime");
}

The time complexity of this algorithm is now O(√N).

Prime Numbers in Range

Let's say we need to find prime numbers between two certain numbers. The simplest idea would be to check if each of the numbers between them is prime or not.

public class Main {
    public static void main(String[] args) {
        int n = 50;
        displayAllPrimes(n);
    }
    
    public static void displayAllPrimes(int n){
        for (int i = 2; i <= n; i++) {
            if (isPrime(i)) {
                System.out.print(i + " ");
            }
        }
    }
    
    public static boolean isPrime(int n){
        if (n <= 1) return false;
        for (int i = 2; i * i <= n; i++) {
            if (n % i == 0) return false;
        }
        return true;
    }
}

In the above program, the isPrime() method takes O(√N) to check whether a certain number is prime. The displayAllPrimes() method calls the isPrime() method approximately N times. So, the time complexity of the entire algorithm is O(N√N). If we carefully observe the numbers we're checking for prime, we'll notice that there are a number of redundant checks. For example, if we already know that 2 is a prime number then its multiples won't be prime.

Similarly for the rest of the numbers, the below image shows the multiples of smaller prime numbers we've checked earlier.

The unmarked numbers turn out to be the prime numbers we're finding in that range of 2 to 50. This is known as the Sieve of Eratosthenes.

public class Sieve {
    public static void main(String[] args) {
        int n = 50;
        boolean[] isComposites = new boolean[n+1]; // size is n+1 to include n 
        sieve(n, isComposites);
    }

    public static void sieve(int n, boolean[] isComposite){
        for (int i = 2; i * i <= n; i++) {
            if (!isComposite[i]) {
                for (int j = 2 * i; j <= n; j += i) {
                    isComposite[j] = true;
                }
            }
        }

        for (int i = 2; i <= n; i++) {
            if (!isComposite[i]) {
                System.out.print(i + " ");
            }
        }
    }
}

In the program above, we check for multiples up to √N because large numbers can be factored using smaller numbers' multiples. The number of times the inner loop (the loop responsible for marking the composite numbers) runs for each prime number P is $\frac {N} {P}$. Therefore, total number of times the inner loop runs will be:

Hence, the time complexity of this algorithm is O(N loglog(N)).

Newton Raphson Method

The Newton Raphson method is an iterative method of finding better approximations to the roots of a real-valued function. The best linear approximation to any differential function near the point $x = x_i$ will be its tangent with the equation:

where x_i is the ith iterative approximation of root

The root of the tangent equation will be the next iterative approximation x_{i+1} when it intercepts the x-axis (y = 0).

Now, if we want to find the square root of any number (say n), we can take f(x) = x² - n. The root of that equation will give us the closest approximation of √n.

You can view this animated image from Wikipedia, which visually demonstrates all the iteration of approximated roots of f(x).

Let's try to write a program for finding the approximate square root of any number.

public class NewtonRaphsonSqrt {
    public static void main(String[] args) {
        System.out.println(sqrt(43));
    }

    public static double sqrt(double n) {
        double x = n;
        double root;
        while (true) {
            root = 0.5 * (x + (n/x));

            if (Math.abs(root - x) < 0.5) { // Error threshold, can be adjusted for more precision
                break;
            }
            x = root;
        }
        return root;
    }
}

Reducing the error threshold, currently set at 0.5, will result in a more accurate approximation of the square root.

Modular Arithmetic

It is a system of arithmetic operations for integers where the numbers "wrap around" when exceeding a certain number called as the modulus. For a given integer m ≥ 1, it is called a modulus if the difference of two integers a and b (a - b) is an integer multiple of m i.e. a - b = k*m (where k is an integer). The integers a and b are said to be congruent modulo m and is mathematically denoted by a ≡ b (mod m).

The parentheses mean that (mod m) applies to the entire equation, not just to the right-hand side (here, b). In particular, (a mod m) = (b mod m) is equivalent to a ≡ b (mod m), and this explains why "=" is often used instead of "≡" in this context.

The congruence relation is written as *a = b + k\m**.

Source: Wikipedia

In programming, we don’t write congruences directly. Instead, we use the % operator, which computes the remainder. The % operator is the practical realization of the congruence relation. For example: ≡ (mod m) ⇔ (a % m) == (b % m) in code.

The range of (a % m) is always in the range (\[0, m-1\]) when (m > 0). This ensures the remainder is non-negative, which is crucial for consistent modular arithmetic in programming.

Properties:

Addition Property: When adding two numbers, their remainders modulo (m) add up, but if the sum exceeds (m), subtracting (m) (i.e., taking modulo again) brings it back within the valid range.
Subtraction Property: Subtraction can lead to negative results, so adding (m) before taking modulo ensures the result stays within (\[0, m-1\]).
Multiplication Property: Multiplying the remainders and then taking modulo keeps the product within the modular system, preserving equivalence.
Division Property: Division is not straightforward in modular arithmetic. For division by (b) modulo (m) to be valid, (b) must have a modular inverse modulo (m), which exists only if gcd(b, m) = 1.

Modular multiplicative inverse of an integer b is the solution (which exists only when b and m are coprime) of the equation: ax ≡ 1 (mod m).

Bézout's Identity

It is a theorem which related two arbitrary integers with their greatest common divisor (GCD). Mathematically,

where, x and y are integers.

If gcd(a, b) = d, then every integer linear combination ax + by is a multiple of d.

For example, if a = 3 and b = 16, then 3*(-5) + 16*1 = 1 = gcd(3, 16).
Let's take another example: a = 8 and b = 18. Then, 8*(-2) + 18*1 = 2 = gcd(8, 18).

The coefficients x and y can be found using the Extended Euclidean algorithm and the gcd can be calculated using the Euclidean algorithm.

Euclidean Algorithm

The Euclidean Algorithm is one of the oldest and most efficient methods to compute the greatest common divisor (GCD) of two integers. Since Bézout’s identity relies on the GCD, understanding this algorithm is essential. It's based on the principle that if

Effectively, a is reduced by multiples of b until only the remainder is left. Therefore, gcd(a, b) = gcd(b, a % b).

Let’s compute gcd(514, 106) using the Euclidean Algorithm.

We start by dividing the larger number by the smaller one and continue replacing the pair with (b, a % b) until the remainder becomes zero:

514 = 106*4 + 90 → gcd(514, 106) = gcd(106, 90)
106 = 90*1 + 16 → gcd(106, 90) = gcd(90, 16)
90 = 16*5 + 10 → gcd(90, 16) = gcd(16, 10)
16 = 10*1 + 6 → gcd(16,10) = gcd(10, 6)
10 = 6*1 + 4 → gcd(10, 6) = gcd(6, 4)
6 = 4*1 + 2 → gcd(6, 4) = gcd(4, 2)
4 = 2*2 + 0 → gcd(4, 2) = 2

Therefore, gcd(514, 106) = 2.

public static int gcd(int a, int b) {
    if (a == 0) {
        return b;
    }
    return gcd(b % a, a);
}

We can also calculate the LCM of two numbers using their GCD with the formula:
\[\text{LCM}(a, b) = \frac{|a \times b|}{\text{GCD}(a, b)}\]

public static int lcm(int a, int b) {
    return a * b / gcd(a, b);
}

Extended Euclidean Algorithm

This algorithm is an extension of the Euclidean Algorithm which computes the coefficients of the Bézout's identity. We start with the gcd of the two numbers and eventually represent that as a linear combination of those two numbers.

For example, we have found gcd(514, 106) = 2. We start with the last non-zero remainder step: 6 = 4 + 2 ⇒ 2 = 6 - 4.
Then, from previous steps, we can write 6 = 16 - 10 and 4 = 10 - 6. We'll back-substitute them in the above equation.
∴ 2 = (16-10) - (10 - 6) = 16 - 2*10 + 6 = 16 - 2*10 + (16 - 10) = 2*16 - 3*10
∴ 2 = 2*16 - 3*(90 - 16*5) = 17*16 - 3*90
∴ 2 = 17*(106 - 90) - 3*90 = 17*106 - 20*90
∴ 2 = 17*106 - 20*(514 - 4*106) = (-20)*514 + 97*106

Hence, (-20)*514 + 97*106 = 2 = gcd(514, 106). So, the coefficients (Bézout's coefficients) of Bézout's identity would be -20 and 97.

We can utilise the recursion stack to keep track of the steps performed in Euclidean Algorithm. Below is the code for this algorithm:

static int gcdExtended(int a, int b, int[] xy) {
    if (a == 0) {
        xy[0] = 0; // x
        xy[1] = 1; // y
        return b;
    }

    int[] temp = new int[2];
    int gcd = gcdExtended(b % a, a, temp);

    // Update x and y using results of recursion
    xy[0] = temp[1] - (b / a) * temp[0];
    xy[1] = temp[0];

    return gcd;
}

Conclusion

In this article, we explored fundamental mathematical concepts that are crucial for understanding and implementing data structures and algorithms. We delved into number systems, including binary, octal, and hexadecimal, and discussed how computers represent numbers using the two's complement method for signed integers. We also covered bitwise operators and their applications in manipulating individual bits of data.

⭐ Check out the DSA GitHub repo for more code examples.

Proving Programs Mathematically: Understanding Hoare Logic with Python

Wed, 25 Feb 2026 13:47:45 +0000

Introduction

Have you ever wondered if a program really does what it’s supposed to — mathematically?

Most programmers test code manually, but there’s a formal way to prove program correctness: it’s called Hoare Logic.

In this post, we’ll:

Introduce Hoare Logic and its basic idea
Show how it applies to Python if/else statements
Connect it to algebraic models of loops
Give you an intuitive way to “prove your code”

By the end, you’ll see how logic meets code, and how mathematics can verify programs.

1. What is Hoare Logic?

Hoare Logic was introduced by C. A. R. Hoare in 1969. It’s a method to reason about program correctness using Hoare triples:

[ {P}\ S\ {Q} ]

Where:

(P) = Precondition (what must be true before the code)
(S) = Statement (the program code)
(Q) = Postcondition (what will be true after the code, if it terminates)

Example:

x = 5
y = x + 2

Precondition (P): (x = 5)
Statement (S): y = x + 2
Postcondition (Q): (y = 7)

So we can write the Hoare triple:

[ {x = 5}\ y = x + 2\ {y = 7} ]

✅ This triple is mathematically correct.

2. Proving `if/else` Statements

Hoare Logic has a rule for conditionals:

[ \frac{{P \wedge B}\ S_1\ {Q},\ {P \wedge \neg B}\ S_2\ {Q}}{{P}\ \text{if } B \text{ then } S_1 \text{ else } S_2\ {Q}} ]

In plain words:

If the condition (B) is true → (S_1) executes correctly
If (B) is false → (S_2) executes correctly
Then the entire if/else is correct

Python Example:

x = 10
if x > 5:
    y = 1
else:
    y = 2

Precondition (P): x = 10
Condition (B): x > 5
Postcondition (Q): y = 1

Check:

(x > 5) → executes y = 1 ✅ Correct
(x <= 5) → would execute y = 2 (not taken in this case)

Hoare triple:

[ {x = 10}\ \text{if } x > 5\ \text{then } y=1\ \text{else } y=2\ {y=1} ]

3. Connecting Hoare Logic to Algebraic Models

In my research, I represent conditionals as algebraic functions:

def f(x):
    if x == 0:
        return 0
    else:
        return 1

0 → false, 1 → true
Precondition: x ∈ {0,1}
Postcondition: output ∈ {0,1}

Mathematically:

[ f(x) = \begin{cases} 0 & \text{if } x=0 \ 1 & \text{if } x=1 \end{cases} ]

Notice how this matches Hoare logic:

Precondition (P): (x \in {0,1})
Statement (S): if/else
Postcondition (Q): output ∈ {0,1}

✅ Algebraic function = Hoare triple in practice

4. Loops: Summations and Hoare Invariants

Hoare Logic handles loops using loop invariants:

[ {I \wedge B}\ S\ {I} ]

Where:

(I) = Loop invariant (true before and after every iteration)
(B) = Loop condition

For Python for loops, I model them as summations over arithmetic progressions:

for i in range(0, 5):
    sum += i

range(0,5) → 0,1,2,3,4
Algebraic model:

[ \sum_{i=0}^{4} i = 10 ]

Precondition: sum = 0
Postcondition: sum = 10

Again, this is Hoare Logic applied numerically:

[ {sum = 0}\ \text{for } i \text{ in range(0,5)}\ {sum = 10} ]

5. Why This Matters

You can prove code correctness without running it
Combine algebraic models + Hoare Logic for clearer reasoning
This makes Python programs mathematically verifiable

Even simple programs can be formally verified, giving you confidence in correctness and runtime behavior.

6. Conclusion

Hoare Logic provides a mathematical framework for proving program correctness, and algebraic models of conditionals and loops give a computational perspective.

By combining both:

if/else → algebraic functions = Hoare triples
for loops → summations = Hoare invariants

You get a powerful, accessible, and mathematically sound way to reason about programs.

References

Hoare, C. A. R. (1969). An Axiomatic Basis for Computer Programming. Communications of the ACM, 12(10), 576–580.
Jadon, P. (2026). A Theoretical Framework for Conditional Statements: Modeling If/Else as Algebraic Functions. Zenodo. https://doi.org/10.5281/zenodo.18758094
Jadon, P. (2026). A Mathematical Framework for Python Loops: Modeling For-Loops as Finite Summations. Zenodo. https://doi.org/10.5281/zenodo.18772270

]

Understanding Basic Data Structures for Web Development

Mon, 16 Feb 2026 12:00:00 +0000

In the world of web development, grasping basic data structures is vital. They form the backbone of efficient algorithms and applications. Let's dive into some fundamental data structures: arrays, linked lists, and trees.

Arrays

Arrays are collections of elements stored in contiguous memory locations. They offer fast access to elements, making them ideal for scenarios where you need to access or modify data frequently.

Use cases:

Storing lists: Arrays are great for managing items like user profiles or product lists.
Data manipulation: Many algorithms work seamlessly with arrays for sorting or searching data.

Performance:

Access: O(1)
Insertion/Deletion: O(n) (in worst case)

Linked Lists

Linked lists consist of nodes where each node points to the next. This structure allows for dynamic memory allocation, making it easier to manage data that grows or shrinks.

Use cases:

Dynamic data: If you’re building applications like chat systems where messages keep coming and going, a linked list can efficiently manage this dynamic set of data.
Implementing stacks and queues: Both can be easily implemented using linked lists for LIFO (Last In, First Out) and FIFO (First In, First Out) structures respectively.

Performance:

Access: O(n)
Insertion/Deletion: O(1) (when you have a pointer to the node)

Trees

Trees are hierarchical structures made up of nodes. The most common type is the binary tree, where each node has at most two children. Trees excel at representing data that has a relational structure.

Use cases:

Hierarchical data representation: Think about website navigation or organizational structures.
Search operations: Binary search trees allow for efficient searching, inserting, and deleting of data.

Performance:

Access: O(log n) (in balanced trees)
Insertion/Deletion: O(log n) (in balanced trees)

Conclusion

Understanding data structures not only enhances your programming skills but also allows you to optimize web applications for better performance. Choosing the right data structure for the right job is crucial in building scalable and efficient applications. As web developers, mastering these basics is essential to solve complex problems effectively.

Don’t hesitate to experiment with these structures in your next project. Whether you’re managing state in a React application or dealing with database results, being well-versed in these data structures will give you the edge you need to create efficient solutions.

How Insertion Sort Works: Simplified Explanation

Sat, 29 Nov 2025 09:40:50 +0000

Insertion sort is a simple comparison-based sorting algorithm that sorts by repeatedly inserting elements into their correct position. Let's explore how it works in detail.

What is Insertion Sort?

Insertion Sort is a comparison sort algorithm. It divides the array into two parts: the sorted part and the unsorted part. It repeatedly inserts each element from the unsorted part into its correct position in the sorted part of the array.

How does it work?

Let’s take the following array as an example. We need to sort it in ascending order.

The insertion sort algorithm uses two loops: one controls the number of passes (or traversals) through the array, and the other compares adjacent elements and performs swap if needed, starting from the first element of the unsorted section. Let variable i control the number of passes and variable j control the comparison of adjacent elements. As i increases, the sorted section grows, and j helps place each element in its correct position within the sorted section.

Since we are sorting in ascending order, the sorted part of the array is on the left side.

Initially, i should start from index 0. The variable j takes the value i+1 which in the initial case is index 1.

As the sorted region lies behind the initial value of j in each pass, the algorithm compares the jth element with the j-1th element.
It will check: is 9 less than 3? No, it isn’t. So, it will get swapped.

After the swap, the value of j decreases by a unit. As the j-1th element is undefined (error will be thrown if we try to access that element), so j should always be greater than 0.

Now, in the second pass, i increases to 1. j takes the value of 2.

Now, the algorithm checks: is 9 less than 6? No, it is not. So, they will be swapped.

The value of j changes to 1. The algorithm now checks: is 3 less than 6? Yes, it is. So, no swap operation will be performed.

Now, the third pass starts. The value of i changes to 2 and j becomes 3.

Now, the algorithm checks: is 9 less than 10? Yes, it’s. So, no swap operation will be performed.

As we know, the part of the array on the left side of j is already sorted at the beginning of each pass. Therefore, it's unnecessary to check all the way to the leftmost end of the array. If the desired order is found between adjacent elements during comparison, the internal loop can exit for that pass.

Now, starting with the fourth pass, the value of i becomes 3 and that of j becomes 4.

The algorithm now checks: is 10 less than 1? No, it isn’t. So, they will be swapped.

The value of j changes to 3. Now, it checks: is 9 less than 1? No, it isn’t. So, they’ll be swapped.

j is now at index 2. It checks: is 6 less than 1? No, it isn’t. So, they get swapped.

The value of j decreases to 1. Now, it checks: is 3 less than 1? No, it isn’t. So, they get swapped.

Now, the internal loop exits. As j takes the value i+1 and index 5 does not exist, so the maximum value of i should be 3. In general, i must be less than N - 1 where N is the length of the array.

Our array is finally sorted!

Time Complexity

There are two possible scenarios: the best case and the worst case.

Worst Case

The worst case occurs when the array is sorted in the reverse order. Let’s try to find out the total number of comparisons made.

In the 1st pass, only 1 comparison is made.
In the 2nd pass, 2 comparisons are made.
…
In the N-1th pass, N-1 comparisons are made.

So, the total number of comparisons made is:

Hence, the time complexity is O(N²) as constants are cancelled, and less dominating terms are removed.

Best Case

The best case occurs when the array is already sorted in the desired order. In that case, there will be utmost 1 comparison made in each pass because the internal loop will break once it finds that the desired order is followed by the adjacent elements while comparing them. Therefore, total number of comparisons made is N-1 where N is the size of the array.

Hence, the time complexity in this scenario is O(N).

Space Complexity

As the insertion sort algorithm is an in-place sorting algorithm, it does not use any auxiliary space. Hence, its space complexity is O(1).

Stability

The insertion sort is a stable sorting algorithm as the original order of the equal elements (or the duplicate elements) is maintained in the final sorted array.

Uses of Insertion Sort

Insertion sort is the most efficient sorting algorithm for small arrays because it is adaptive. Adaptive means that for smaller values of N, the number of comparisons made are reduced and number of swaps performed is also less compared to bubble sort.

It works better when the array is nearly sorted. Hence, it is often used in hybrid sorting algorithms like TimSort and IntroSort.

Example Code

import java.util.Arrays;

public class Main {
    public static void main(String[] args) {
        int[] arr = {9, 3, 6, 10, 1};
        insertionSort(arr);
        System.out.println(Arrays.toString(arr));
    }

    static void insertionSort(int[] arr) {
        for (int i = 0; i < arr.length - 1; i++) {
            for (int j = i + 1; j > 0; j--) {
                if (arr[j] < arr[j - 1]) {
                    swap(arr, j, j-1);
                } else {
                    break;
                }
            }
        }
    }

    static void swap(int[] arr, int first, int second) {
        int temp = arr[first];
        arr[first] = arr[second];
        arr[second] = temp;
    }
}

Conclusion

Insertion sort is a straightforward and efficient algorithm for sorting small arrays. Because of its adaptive nature and its stability, it performs well on nearly sorted arrays. Understanding insertion sort provides a solid foundation for learning more complex sorting techniques.

⭐ Check out the DSA GitHub repo for more code examples.

Autocomplete Demystified: A Common Use-Case of Trie

Sun, 24 Aug 2025 09:42:32 +0000

Imagine this: You're typing a friendly message in a WhatsApp group directed to one of your peers, and your fingers,
seemingly possessed by a digital imp, instead of typing 'far too nice', types 'fart oo nice'. Now everyone thinks you're
a creep. Frustrating, right? Fear not! Trie is the unseen sidekick behind your keyboard here to maintain your public
image.

How 'Trie' Solves the Typo Trouble

Think of Trie as your personal autocorrect wizard. When you type a word, Trie steps in to predict what you're trying to
say. It's like having a smart assistant that finishes your sentences, but for typing!

Imagine you're typing "eleph." Trie jumps in and goes, "Ah, you must mean 'elephant'!" It's like magic—no more wrestling
with the keyboard to spell out every word perfectly.

So, How Does It Work?

I'll do something different here. Instead of starting off with a written explanation, I'll do a visual walkthrough on
how the Trie works (yes, I also happen to be an artist). If the visual explanation doesn't work for you, feel free to
read on!

Picture Trie as a giant family tree of words. Each letter in a word is like a family member. The journey from the root (
the grandparent) to the leaves (the kids) spells out a complete word.

Let's say you've typed "eleph." Trie checks its family tree and quickly realizes that "eleph" fits perfectly into the "
elephant" branch. Voila! It suggests the complete word without missing a beat.

A Friendly Go-Away Message

This silent sidekick is also evident in other aspects of your life other than Autocorrect. An example most of us might
relate to: Browser History. So for those clandestine folks who toggle 'Incognito Mode' at those wee hours to remove
traces
of their online presence, think of the 'Trie' and it's selfless contributions next time you do this.

Feel free to share your feedback especially if something wasn't clearly explained!

If you are intrigued by the inner workings of Trie, and ready for a deep dive into the digital ocean (don't sue me,
digitalocean), keep reading. The next section is where we unveil the code sorcery behind Trie for our tech-savvy
friends. Also, if you have already read the previous blog titled: 'Unveiling the Trie: A Masterstroke for Efficient
String Searches', you can stop here (but you don't have to :-)).

Gentlemen, and women, and everyone else, shall we?

A brief introduction to Trie: it's a data structure (similar to an array, a list, a tuple etc.) that stores data as
a tree where the branch of the tree traces out the path to where the data is, i.e. the leaf nodes/child nodes.

Here's the link to
the GitHub repository with the full implementation.

Now, let's get hands-on with some JavaScript code!

Here's our Trie implementation:

// Trie Node
function TrieEntry(word) {
  this.word = word;
  const words = [];
  for (let i = 0; i < 26; i++) {
    words.push(null);
  }
  this.words = words;
}

// Main Trie Dictionary
function TrieDictionary() {
  const letterToIndexMapping = {
    "a": 1,
    "b": 2,
    "c": 3,
    "d": 4,
    "e": 5,
    "f": 6,
    "g": 7,
    "h": 8,
    "i": 9,
    "j": 10,
    "k": 11,
    "l": 12,
    "m": 13,
    "n": 14,
    "o": 15,
    "p": 16,
    "q": 17,
    "r": 18,
    "s": 19,
    "t": 20,
    "u": 21,
    "v": 22,
    "w": 23,
    "x": 24,
    "y": 25,
    "z": 26,
  }

  this.root = new TrieEntry();

  this.insertWord = (word) => {
    const wordChars = word.toLowerCase().split("");
    let currWord = "";

    let currSlot = this.root;
    for (const char of wordChars) {
      currWord += char;
      // traverse our root adding each char.
      const idx = letterToIndexMapping[char] - 1;
      const arraySlotForChar = currSlot.words[idx];
      if (arraySlotForChar) {
        currSlot = arraySlotForChar;
      } else {
        currSlot.words[idx] = new TrieEntry(currWord);
        currSlot = currSlot.words[idx];
      }
    }
  }

  this.searchWord = (word) => {
    const wordChars = word.toLowerCase().split("");

    let currSlot = this.root;
    for (const char of wordChars) {
      const idx = letterToIndexMapping[char] - 1;
      const arraySlotForChar = currSlot.words[idx];
      if (!arraySlotForChar) {
        break;
      }
      currSlot = arraySlotForChar;
    }
    return currSlot.word === word;
  }

  this.printDictionary = () => {
    const printRecursively = (entry) => {
      if (!entry) return "";

      for (const en of entry.words) {
        if (en) {
          console.log("en: ", en);
          console.log("--------------------");
        }
        printRecursively(en);
      }
    }

    printRecursively(this.root);
  }
}

Why Trie? A Performance Benchmark Comparison Between Trie and Linear Search

Feel free to run the code directly on your machine if you'd prefer a more hands-on approach.

1. Dictionary Population (1049938 words)

Adding words to our Trie is a breeze. Here's the javascript code sample:

const trieDict = new TrieDictionary();
const wordsDictionary = ["apple", "banana", "orange", /* ...a million more words */];

const start = new Date();
for (const word of wordsDictionary) {
  trieDict.insertWord(word);
}
const end = new Date();

const elapsedTime = (end - start) / 1000;
console.log(`Trie Population Time: ${elapsedTime} seconds`);

Dictionary population (1049938 words) timestamp start:  1699963909921
Timestamp after population:  1699963911482
Trie Population Time:  1.561
------------------------------------------------------------

In a mere 1.561 seconds, our Trie is ready to rock and roll with over a million words. Impressive, isn't it?

2. The Great Search Showdown

Now, let's pit Trie against the traditional linear search in a battle for supremacy. Our contenders: Trie vs. Linear
Search!

const wordsToSearch = ["apple", "programming", "debugging", /* ...4,829 more words */];

// Linear Search
const linearSearchStart = new Date();
for (const word of wordsToSearch) {
  // ... linear search logic
}
const linearSearchEnd = new Date();

// Trie Search
const trieSearchStart = new Date();
for (const word of wordsToSearch) {
  trieDict.searchWord(word);
}
const trieSearchEnd = new Date();

// Calculating and Displaying Results
const linearSearchTime = (linearSearchEnd - linearSearchStart) / 1000;
const trieSearchTime = (trieSearchEnd - trieSearchStart) / 1000;

console.log(`Linear Search Time: ${linearSearchTime} seconds`);
console.log(`Trie Search Time: ${trieSearchTime} seconds`);

Drumroll, please! The results are staggering:

Linear Search Time: 8.839 seconds
Trie Search Time: 0.004 seconds

Yes, you read it right! Trie search takes a mere fraction of a second, showcasing a jaw-dropping 2200X performance
boost!

Use-Cases: 'Trie's' Playgrounds

1. Autocomplete During Search

Ever wondered how autocomplete in search bars works seamlessly? Trie is the wizard behind the curtain, swiftly
predicting your next word as best as it can.

2. Spell Checking

Tries are responsible for checking typos and spelling mishaps. It detects errors with the swiftness of a
well-optimized algorithm, making corrections before you finish typing "debug."

Wrapping it Up: Trie and the Future of Performance

In the blink of an eye, Trie has transformed the landscape of our search experiences. With its unparalleled speed in
word insertion and instant searches, this data structure emerges as a strategic asset for software optimization.

As you navigate through the complexities of code, consider the Trie as a reliable companion, streamlining your path
through the intricate web of linguistic data.

Before we part ways, contemplate this: How might integrating Trie elevate the efficiency of your software projects?
Share your insights in the comments below! Stay tuned for our upcoming tech discussions, where we'll unravel more coding
intricacies.

Wishing you seamless coding journeys!

A practical guide to identifying common algorithm patterns for efficient problem-solving.

Mon, 18 Aug 2025 06:43:05 +0000

The Developer's Field Guide to Algorithm Patterns (and How to Stop Guessing)

Have you ever faced a coding problem on platforms like LeetCode or HackerRank and felt paralyzed? You read the prompt, understand what's being asked, but your mind goes blank. "Where do I even start?" you ask yourself. "Is this a loop? Two loops? Recursion?"

This feeling is incredibly common. We often try to solve algorithm problems as if each one were a unique, uncharted island. But the truth is, the vast majority of problems fit into a limited number of fundamental patterns.

What if, instead of tackling a problem from scratch, you could recognize its "family" and already have a good idea of the right strategy and tools to solve it? This article is exactly that: a field guide for identifying the most common algorithm patterns based on keywords and the problem's structure. Let's learn to stop guessing and start recognizing.

The Lens We'll Use: A Quick Review of Complexity (Big O)

Before we start pattern hunting, we need to adjust our lens. The goal of choosing the right pattern is almost always to find an efficient solution. To measure this efficiency, we use Big O Notation.

The objective isn't to measure the exact time in seconds, but rather to understand how the execution time grows as the size of the input (n) increases. If you double the size of the list, does the runtime double? Does it quadruple? Or does it barely change?

Remember the two golden rules of Big O simplification:

Drop Constant Factors: A loop that iterates through n items and one that iterates through n/2 items have the same linear growth. Both are O(n).
Keep Only the Dominant Term: An O(n²) operation followed by an O(n) operation is simplified to O(n²), because the quadratic term dominates the growth for large n.

With that in mind, let's explore the most common patterns.

The Field Guide: Identifying 8 Essential Algorithm Patterns

Sliding Window

When to Think About It: The problem involves a linear data structure (array, list, string) and asks for a contiguous sub-section (subarray or substring) that is optimal in some way (longest, shortest, max sum, etc.).
Keywords / Telltale Signs: "contiguous subarray," "substring," "longest/shortest length," "maximum/minimum sum," "contains k distinct elements."
Typical Problem: "Given an array of integers, find the maximum sum of any contiguous subarray of size k."
Typical Complexity: O(n).

Two Pointers

When to Think About It: The problem involves a sorted array (or one that can be sorted) and asks to find a pair or a triplet of elements that satisfy a condition. Usually, one pointer starts at the beginning and the other at the end, and they move toward each other.
Keywords / Telltale Signs: "sorted array," "find a pair/triplet," "target sum," "remove duplicates," "palindrome."
Typical Problem: "In a sorted array, find two numbers that add up to a value X."
Typical Complexity: O(n).

Backtracking

When to Think About It: The problem asks to find all possible solutions or a single solution that satisfies complex constraints by building the answer step-by-step. If a choice leads to a dead end, you "go back" (backtrack) and try another. It's a structured Depth-First Search (DFS).
Keywords / Telltale Signs: "find all combinations," "permutations," "subsets," "all possible paths," "puzzle," "Sudoku," "maze."
Typical Problem: "Given a set of numbers, find all unique subsets."
Typical Complexity: Exponential, such as O(2ⁿ) or O(n!).

Dynamic Programming (DP)

When to Think About It: It's an optimization problem (find the maximum/minimum) or a counting problem (count the number of ways) where the solution to a larger problem can be built from the solutions of smaller, overlapping subproblems.
Keywords / Telltale Signs: "number of ways to...", "minimum/maximum cost path," "maximum/minimum value you can get," "maximum profit." If you find yourself solving the same subproblem multiple times in a recursive solution, it's a sign to use DP.
Typical Problem: "Knapsack Problem: given items with weights and values, what is the maximum value that can fit in a knapsack of capacity W?"
Typical Complexity: Polynomial, such as O(n²) or O(n*m).

Breadth-First Search (BFS)

When to Think About It: The problem involves graphs or matrices and asks for the shortest path from one point to another, assuming all steps have the same cost. BFS explores the neighborhood in "layers."
Keywords / Telltale Signs: "shortest path," "fewest number of steps," "levels of a tree," "unweighted graph," "maze."
Typical Problem: "In a matrix with walls, find the shortest path from the top-left corner to the bottom-right."
Typical Complexity: O(V + E) (V = vertices, E = edges).

Depth-First Search (DFS)

When to Think About It: The problem involves graphs or matrices and asks to explore paths to their end, check if a path exists, or find connected components. It does not guarantee the shortest path. (Backtracking is a type of DFS).
Keywords / Telltale Signs: "find a path (any path)," "check if a path exists," "connected components," "cycles in a graph," "count islands."
Typical Problem: "Given a matrix of 1s (land) and 0s (water), count the number of islands."
Typical Complexity: O(V + E).

Heap (Priority Queue)

When to Think About It: The problem asks to find or keep track of the "top K" elements (the K largest or K smallest) from a collection of data, especially if the collection is very large or a stream.
Keywords / Telltale Signs: "k-th largest/smallest element," "top k," "median of a stream," "schedule tasks" (based on priority).
Typical Problem: "Find the 10 most liked tweets from a real-time feed."
Typical Complexity: O(n log k) to find the top K elements.

Binary Search

When to Think About It: The problem involves finding an item in a sorted array. More advanced uses include optimization problems where you can "guess" an answer and check if it's valid, and the search space for answers is monotonic.
Keywords / Telltale Signs: "sorted array," "find the index of," "the smallest/largest value X such that condition P(X) is true."
Typical Problem: "Find the first number in a sorted array that is greater than or equal to Y."
Typical Complexity: O(log n).

Appendix: How to Identify Complexity in Your Code (The Quick Guide)

To help connect theory to practice, here are the most common code patterns and their complexities:

O(1) – Constant Time: The code takes the same amount of time regardless of the input size. There are no loops that depend on n.
```
def get_first_element(my_list):
    return my_list[0] # Accessing an index is O(1)
```
O(log n) – Logarithmic Time: The algorithm cuts the problem in half with each iteration. Think Binary Search.
```
The loop in a Binary Search throws away half the list with each step.
```

O(n) – Linear Time: A single loop that iterates over the input of size n.

def find_max(my_list):
    max_val = my_list[0]
    for number in my_list: # The loop goes through each of the 'n' elements
        if number > max_val:
            max_val = number
    return max_val

O(n log n) – "n-log-n" Time: Usually associated with efficient sorting algorithms (Merge Sort, Quick Sort). Python's built-in sorted() function is a good example.

O(n²) – Quadratic Time: A nested loop where both loops depend on the input size n.

def find_pairs(my_list):
    pairs = []
    for i in my_list: # Outer loop (n)
        for j in my_list: # Inner loop (n)
            pairs.append((i, j))
    return pairs # Total: n * n = n²

O(2ⁿ) – Exponential Time: Often found in a recursive function that calls itself twice (or more) for an input of n-1.

def recursive_fibonacci(n):
    if n <= 1: return n
    # For each n, it generates two new "trees" of calls
    return recursive_fibonacci(n-1) + recursive_fibonacci(n-2)

Conclusion: Stop Memorizing, Start Recognizing

Mastering algorithms isn't about memorizing hundreds of specific solutions. It's about building a mental toolkit of patterns. When you encounter a new problem, instead of searching for a pre-made answer, try to identify its characteristics: is it about a contiguous subarray? Think Sliding Window. Does it ask for the shortest path? Think BFS. Does it need all possible combinations? Think Backtracking.

This field guide is your starting point. The more you practice with this pattern-recognition mindset, the faster and more intuitive your problem-solving process will become.

Coder Legion - Recent posts tagged data-structures

Arrays are dumb. So are tuples.

What Should Texas Businesses Look for in an ERP Software Development Company?

Backtracking Finally Clicked When I Fixed One Habit

Where my backtracking kept breaking

What I started doing differently

What that looked like on Combination Sum

Why undoing state is the whole game

What I'd tell someone stuck on this

AVL Trees Explained: The Rotation Patterns Most People Memorise Wrong

What I figured out

Where my approach was breaking

What I started doing differently

What that looked like on the next problem

Why this works (the height theory behind it)

What I'd tell someone in the same spot

Stop Writing Trading Scripts. Start Building Senses: How I Forged an Autonomous AI trading bot

Forging Herakles-octobot: How I Built an Autonomous AI Crypto Trader (That Actually Understands Risk)

The Brain: One Prompt to Bind Them

The Nervous System: The All-Seeing Eye

The Secret Weapon: Guarding the Hoard

The Crucible: Holding the Line

The Execution: Raising the Shield Wall

The Road Goes Ever On

Data Structures and Algorithms on Strings

Key Math Concepts in Data Structures and Algorithms

Number Systems

Two's complement method

Bitwise Operators

AND Operator (&)

OR Operator (|)

XOR Operator (^)

Complement Operator (~)

Left Shift Operator (<<)

Right Shift Operator (>>)

Core Number Theory

Prime Number

Prime Numbers in Range

Newton Raphson Method

Modular Arithmetic

Bézout's Identity

Euclidean Algorithm

Extended Euclidean Algorithm

Conclusion

Proving Programs Mathematically: Understanding Hoare Logic with Python

Introduction

1. What is Hoare Logic?

2. Proving if/else Statements

3. Connecting Hoare Logic to Algebraic Models

4. Loops: Summations and Hoare Invariants

5. Why This Matters

6. Conclusion

References

Understanding Basic Data Structures for Web Development

Arrays

Use cases:

Performance:

Linked Lists

Use cases:

Performance:

Trees

Use cases:

Performance:

Conclusion

How Insertion Sort Works: Simplified Explanation

What is Insertion Sort?

How does it work?

Time Complexity

Worst Case

Best Case

Space Complexity

Stability

Uses of Insertion Sort

Example Code

Conclusion

Autocomplete Demystified: A Common Use-Case of Trie

How 'Trie' Solves the Typo Trouble

So, How Does It Work?

A Friendly Go-Away Message

Why Trie? A Performance Benchmark Comparison Between Trie and Linear Search

2. Proving `if/else` Statements