@@ -60,85 +104,84 @@ const Content = () => {
- {/* ------- ALGORITHMIC STEPS – LIFT CARDS ------- */}
+ {/* ------- OPERATIONS ------- */}
-
diff --git a/app/visualizer/trees/bst/deletion/content.jsx b/app/visualizer/trees/bst/deletion/content.jsx
index 8656220..3e6a30b 100755
--- a/app/visualizer/trees/bst/deletion/content.jsx
+++ b/app/visualizer/trees/bst/deletion/content.jsx
@@ -54,16 +54,16 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `Deleting from a Binary Search Tree starts the same way insertion does — you search for the value by comparing and moving left or right — but once you find it, keeping the tree a valid BST afterward takes more care than insertion ever did, because removing a node can leave a gap that needs to be patched correctly.`,
- `There are exactly three shapes the node-to-delete can have, and each is handled differently: a leaf is simply removed, a node with one child is replaced by that child, and a node with two children is trickier — you can't just delete it without breaking the ordering, so you borrow a replacement value from elsewhere in the tree.`,
- `Deletion needs O(1) extra space beyond the recursion stack — no matter which of the three cases applies, only a constant number of pointers get rewired.`,
- `Repeated deletions (and insertions) can gradually unbalance a BST even if it started out balanced, which is exactly the problem self-balancing trees like AVL and Red-Black trees are designed to prevent — they perform extra rotation work on every insert/delete specifically to keep the height close to log n.`,
+ `Deleting from a Binary Search Tree starts the same way insertion does: you search for the value by comparing and moving left or right. But once you find it, keeping the tree a valid BST afterward takes more care than insertion ever did, because removing a node can leave a gap that needs to be patched correctly.`,
+ `There are exactly three shapes the node-to-delete can have, and each is handled differently: a leaf is simply removed, a node with one child is replaced by that child, and a node with two children is trickier, since you can't just delete it without breaking the ordering, so you borrow a replacement value from elsewhere in the tree.`,
+ `Deletion needs O(1) extra space beyond the recursion stack, since no matter which of the three cases applies, only a constant number of pointers get rewired.`,
+ `Repeated deletions (and insertions) can gradually unbalance a BST even if it started out balanced, which is exactly the problem self-balancing trees like AVL and Red-Black trees are designed to prevent: they perform extra rotation work on every insert/delete specifically to keep the height close to log n.`,
];
const cases = [
{
title: "Case 1: Deleting a leaf",
- body: "No children to worry about — just remove the node outright. The parent's pointer to it becomes null.",
+ body: "No children to worry about, just remove the node outright. The parent's pointer to it becomes null.",
},
{
title: "Case 2: Deleting a node with one child",
@@ -71,7 +71,7 @@ const Content = () => {
},
{
title: "Case 3: Deleting a node with two children",
- body: "Find the in-order successor (the smallest value in the right subtree), copy that value into the node being deleted, then delete the successor from its original spot — which is guaranteed to be a leaf or have only a right child, so it reduces to Case 1 or Case 2.",
+ body: "Find the in-order successor (the smallest value in the right subtree), copy that value into the node being deleted, then delete the successor from its original spot, which is guaranteed to be a leaf or have only a right child, so it reduces to Case 1 or Case 2.",
},
];
diff --git a/app/visualizer/trees/bst/deletion/page.jsx b/app/visualizer/trees/bst/deletion/page.jsx
index 077c0c1..9059da9 100755
--- a/app/visualizer/trees/bst/deletion/page.jsx
+++ b/app/visualizer/trees/bst/deletion/page.jsx
@@ -14,7 +14,7 @@ import { MODULE_MAPS } from "@/lib/modulesMap";
export const metadata = {
title: "Binary Search Tree Deletion | Step-by-Step Animation & Explanation",
description:
- "Learn how deletion works in a Binary Search Tree — leaf, one-child, and two-children cases, in-order successor replacement — with an interactive visualizer, code examples in JavaScript, C, Python, and Java, and a quiz.",
+ "Learn how deletion works in a Binary Search Tree, covering leaf, one-child, and two-children cases, plus in-order successor replacement, with an interactive visualizer, code examples in JavaScript, C, Python, and Java, and a quiz.",
keywords: [
"Binary Search Tree Deletion",
"BST Deletion",
diff --git a/app/visualizer/trees/bst/deletion/quiz.jsx b/app/visualizer/trees/bst/deletion/quiz.jsx
index 10126a1..500afb6 100755
--- a/app/visualizer/trees/bst/deletion/quiz.jsx
+++ b/app/visualizer/trees/bst/deletion/quiz.jsx
@@ -9,7 +9,7 @@ const BstDeletionQuiz = () => {
question: "How do you delete a leaf node from a BST?",
options: [
"Replace it with its parent",
- "Simply remove it — its parent's pointer becomes null",
+ "Simply remove it, its parent's pointer becomes null",
"Find its in-order successor",
"You can't delete a leaf"
],
@@ -58,7 +58,7 @@ const BstDeletionQuiz = () => {
"It does require handling that case again"
],
correctAnswer: 1,
- explanation: "Since the successor is found by going as far left as possible, it can't have a left child — so removing it is always the leaf case or the one-child case."
+ explanation: "Since the successor is found by going as far left as possible, it can't have a left child, so removing it is always the leaf case or the one-child case."
}
];
diff --git a/app/visualizer/trees/bst/insertion/animation.jsx b/app/visualizer/trees/bst/insertion/animation.jsx
index c596c1d..f8bd1ed 100755
--- a/app/visualizer/trees/bst/insertion/animation.jsx
+++ b/app/visualizer/trees/bst/insertion/animation.jsx
@@ -291,7 +291,7 @@ const BstInsertionVisualizer = () => {
) : (
- A stack follows LIFO — Last In, First Out — meaning whatever you pushed most recently is the first thing that comes back out. Backing it with an array is the most direct way to build one, since push and pop just work on the array's last index in constant time. + A stack follows LIFO (Last In, First Out), meaning whatever you pushed most recently is the first thing that comes back out. Backing it with an array is the most direct way to build one, since push and pop just work on the array's last index in constant time.
- Algorithmic Steps + Initialize
++ An empty array is allocated with a fixed capacity, and the top pointer starts at -1 to signal there's nothing on the stack yet. +
+
+
+
- {/* Basic Operations */}
-
+
- {/* Helper Operations */}
-
-
-
+ Stack Basic Operations
-
- {[{t:"Initialize Stack", s:initialize}, {t:"push()", s:push}, {t:"pop()", s:pop}].map(
- ({t, s}, idx) => (
-
-
- Step {idx + 1}
-
-
- )
- )}
-
- {t}
--
- {s.map((p, i) => (
-
- - {p.points} - - ))} -
+ + push() +
++ If the array isn't already at capacity, the top pointer is incremented first, then the new value is written at that index, so top always marks the most recently added element. +
+
+
+ ↓ push(7) ↓
+
-
+
+
+
+
+
+
+
diff --git a/app/visualizer/stack/implementation/usingLinkedList/content.jsx b/app/visualizer/stack/implementation/usingLinkedList/content.jsx
index 5940557..12dac3f 100755
--- a/app/visualizer/stack/implementation/usingLinkedList/content.jsx
+++ b/app/visualizer/stack/implementation/usingLinkedList/content.jsx
@@ -6,63 +6,125 @@ import React from "react";
import { useTheme } from "@/app/contexts/ThemeContext";
import InContentAd from "@/app/components/ads/InContentAd";
+const StackListDiagram = ({ nodes, highlight, keyPrefix }) => {
+ const boxSize = 40;
+ const gap = 36;
+ const startX = 56;
+ const topPadding = 22;
+ const width = startX + Math.max(nodes.length, 1) * (boxSize + gap) + 34;
+ const height = boxSize + topPadding + 18;
+
+ const boxX = (idx) => startX + idx * (boxSize + gap);
+ const boxY = topPadding;
+ const cy = boxY + boxSize / 2;
+
+ const colorFor = (idx) => (highlight === idx ? "#10b981" : "#3b82f6");
+
+ if (nodes.length === 0) {
+ return (
+
+ );
+ }
+
+ return (
+
+ );
+};
+
const Content = () => {
const { theme } = useTheme();
const paragraph = [
- `Building a stack with a linked list instead of an array gets you the same LIFO (Last In, First Out) behavior, but without a fixed capacity — every push allocates a fresh node, so the stack can keep growing as long as memory allows.`,
- ];
-
- const opeartions = [
- {
- points: "Initialize Stack",
- subpoints: [
- "Create a head pointer initialized to null.",
- "Optional: Maintain a size counter initialized to 0.",
- ],
- },
- {
- points: "push()",
- subpoints: [
- "Create a new node with the given data.",
- "Set new node's next pointer to current head.",
- "Update head to point to the new node.",
- "Increment size counter (if maintained).",
- ],
- },
- {
- points: "pop()",
- subpoints: [
- "Check if stack is empty (head is null).",
- `If empty, return "Stack Underflow".`,
- "Store current head node in a temporary variabl.",
- "Update head to point to the next node.",
- "Decrement size counter (if maintained).",
- "Return data from the temporary node.",
- ],
- },
- ];
-
- const helper = [
- {
- points: "peek()",
- subpoints: [
- "Check if stack is empty (head is null).",
- "If empty, return null.",
- "Return data from head node without removal.",
- ],
- },
- {
- points: "isEmpty()",
- subpoints: ["Return true if head is null.", "Return false otherwise."],
- },
- {
- points: "size()",
- subpoints: [
- "If size counter is maintained, return its value.",
- "Otherwise, traverse the list and count nodes.",
- ],
- },
+ `Building a stack with a linked list instead of an array gets you the same LIFO (Last In, First Out) behavior, but without a fixed capacity: every push allocates a fresh node, so the stack can keep growing as long as memory allows.`,
];
return (
@@ -85,79 +147,78 @@ const Content = () => {
- {/* Algorithmic Steps */}
+ {/* Initialize */}
Stack Helper Operations
-
- {[{t:"peek()", s:peek}, {t:"isEmpty()", s:isEmpty}, {t:"isFull()", s:isFull}].map(
- ({t, s}, idx) => (
-
-
- Step {idx + 1}
-
-
- )
- )}
-
+ {t}
--
- {s.map((p, i) => (
-
- - {p.points} - - ))} -
+ + pop() +
++ The element at array[top] is read and returned, then the top pointer is decremented; the value itself is left in the array, just no longer considered part of the stack. +
+
+
+ ↓ pop() → returns 7 ↓
++ + peek() +
++ Returns array[top] without touching the pointer, so the stack is left exactly as it was, useful for checking what's on top before deciding whether to pop. +
+
+
+ + + isEmpty() & isFull() +
+
+ Both are just pointer comparisons: isEmpty() is true when top equals -1, and isFull() is true when top reaches the array's last valid index.
+
+
+
+ isEmpty() → true
+
+
isFull() → true
+- Algorithmic Steps + Initialize
++ A top pointer is created and set to null, meaning there are no nodes yet. Some implementations also keep a size counter, initialized to 0, so size() doesn't need to walk the whole list. +
+
+
+
- {/* Stack Basic Operations */}
-
+
- {/* Stack Helper Operations */}
-
+
diff --git a/app/visualizer/stack/isempty/animation.jsx b/app/visualizer/stack/isempty/animation.jsx
index 7728f8f..e3711e0 100755
--- a/app/visualizer/stack/isempty/animation.jsx
+++ b/app/visualizer/stack/isempty/animation.jsx
@@ -1,240 +1,166 @@
"use client";
-import React, { useState, useEffect, useRef } from "react";
+import React, { useState, useRef } from "react";
import { gsap } from "gsap";
+import PushPop from "@/app/components/ui/PushPop";
const StackVisualizer = () => {
- /* ---------- state ---------- */
const [stack, setStack] = useState([]);
- const [inputValue, setInputValue] = useState("");
const [operation, setOperation] = useState(null);
const [message, setMessage] = useState("Stack is empty");
const [isAnimating, setIsAnimating] = useState(false);
- const [peekedItem, setPeekedItem] = useState(null);
const [isEmptyStatus, setIsEmptyStatus] = useState(null);
+ const topRef = useRef(null);
- const itemRefs = useRef([]);
-
- /* ---------- helpers ---------- */
- const resetRefs = () => (itemRefs.current = []);
-
- /* ---------- push ---------- */
- const push = () => {
- const val = inputValue.trim();
- if (!val) {
- setMessage("Please enter a value to push");
- return;
- }
- setIsAnimating(true);
- setOperation(`Pushing "${val}"…`);
- setMessage("");
- setPeekedItem(null);
+ // Intercept state updates coming from PushPop so a single-item pop
+ // (stack shrinking by exactly one) gets a "fly away" exit animation
+ // before it's actually removed. Pushes and resets pass straight through.
+ const handleSetStack = (updater) => {
+ const next = typeof updater === "function" ? updater(stack) : updater;
setIsEmptyStatus(null);
- setStack((prev) => [val, ...prev]);
-
- setTimeout(() => {
- const el = itemRefs.current[0];
- gsap.set(el, { y: -60, scale: 0.8, opacity: 0 });
- gsap
- .timeline({ onComplete: () => setIsAnimating(false) })
- .to(el, { y: 0, scale: 1, opacity: 1, duration: 0.4, ease: "back.out(1.7)" })
- .to(el, { boxShadow: "0 0 10px #3b82f6", duration: 0.2, yoyo: true, repeat: 1 }, "-=0.2")
- .call(() => setMessage(`"${val}" pushed to stack!`));
- }, 10);
-
- setInputValue("");
- };
-
- /* ---------- pop ---------- */
- const pop = () => {
- if (stack.length === 0) {
- setMessage("Stack is empty!");
- setIsEmptyStatus(true);
+ if (stack.length - next.length === 1 && topRef.current) {
+ const el = topRef.current;
+ gsap.to(el, {
+ y: -140,
+ x: 36,
+ rotate: 14,
+ opacity: 0,
+ duration: 0.4,
+ ease: "power2.in",
+ onComplete: () => setStack(next),
+ });
return;
}
- setIsAnimating(true);
- const val = stack[0];
- setOperation(`Popping "${val}"…`);
- setMessage("");
- setPeekedItem(null);
- setIsEmptyStatus(null);
- const el = itemRefs.current[0];
- gsap
- .timeline({ onComplete: () => {
- setStack((prev) => prev.slice(1));
- setIsAnimating(false);
- setMessage(`"${val}" popped from stack!`);
- } })
- .to(el, { scale: 0.5, rotation: 15, y: 80, opacity: 0, duration: 0.5, ease: "power2.in" });
+ setStack(next);
};
- /* ---------- peek ---------- */
- const peek = () => {
- if (stack.length === 0) {
- setMessage("Stack is empty!");
- setIsEmptyStatus(true);
- return;
- }
- setIsAnimating(true);
- setOperation("Peeking at top element…");
- setPeekedItem(stack[0]);
- setIsEmptyStatus(false);
-
- const el = itemRefs.current[0];
- gsap
- .timeline({ onComplete: () => setIsAnimating(false) })
- .to(el, { y: -6, boxShadow: "0 0 15px #a855f7", duration: 0.25 })
- .to(el, { y: 0, boxShadow: "0 0 0px transparent", duration: 0.25 })
- .to(el, { y: -6, duration: 0.25 })
- .to(el, { y: 0, duration: 0.25 })
- .call(() => setMessage(`Top element is "${stack[0]}"`));
+ // Runs the moment a new "top" box mounts in the DOM: a reliable
+ // drop-in entrance that doesn't depend on any surrounding state timing.
+ const animateDropIn = (el) => {
+ if (!el || el.dataset.dropped) return;
+ el.dataset.dropped = "true";
+ gsap.fromTo(
+ el,
+ { y: -220, opacity: 0 },
+ {
+ y: 0,
+ opacity: 1,
+ duration: 0.55,
+ ease: "bounce.out",
+ onComplete: () => {
+ gsap.fromTo(
+ el,
+ { scaleX: 1, scaleY: 1 },
+ {
+ scaleX: 1.08,
+ scaleY: 0.85,
+ duration: 0.08,
+ yoyo: true,
+ repeat: 1,
+ ease: "power1.out",
+ }
+ );
+ },
+ }
+ );
};
- /* ---------- isEmpty ---------- */
const checkEmpty = () => {
setIsAnimating(true);
setOperation("Checking if stack is empty…");
- setPeekedItem(null);
setTimeout(() => {
const empty = stack.length === 0;
setIsEmptyStatus(empty);
setOperation(null);
setMessage(empty ? "Stack is empty!" : "Stack is not empty");
setIsAnimating(false);
- }, 1000);
+ }, 800);
};
- /* ---------- reset ---------- */
- const reset = () => {
- setIsAnimating(true);
- gsap.to(itemRefs.current.filter(Boolean), {
- scale: 0,
- y: -60,
- opacity: 0,
- stagger: 0.06,
- duration: 0.3,
- onComplete: () => {
- setStack([]);
- setInputValue("");
- setOperation(null);
- setMessage("Stack is empty");
- setPeekedItem(null);
- setIsEmptyStatus(null);
- setIsAnimating(false);
- resetRefs();
- },
- });
- };
+ // Oldest first so the container can be laid out column-reverse: the
+ // newest item always lands visually on top without existing items
+ // ever needing to move, matching how a physical stack behaves.
+ const displayStack = [...stack].reverse();
return (
-
+
diff --git a/app/visualizer/trees/applications/heap-sort/content.jsx b/app/visualizer/trees/applications/heap-sort/content.jsx
index 72882ed..e2deb8f 100755
--- a/app/visualizer/trees/applications/heap-sort/content.jsx
+++ b/app/visualizer/trees/applications/heap-sort/content.jsx
@@ -66,7 +66,7 @@ const WalkthroughDiagram = () => {
transition={{ delay: 1.1, duration: 0.5 }}
className="fill-gray-500 dark:fill-gray-400"
>
- array: [9, 5, 8, 2, 4] — the same heap, stored flat
+ array: [9, 5, 8, 2, 4], the same heap, stored flat
);
@@ -76,10 +76,10 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `Heap Sort sorts an array in place by first turning it into a max-heap — a binary tree where every parent is greater than or equal to its children — and then repeatedly removing the largest element (the root) and placing it at the end of the unsorted region. Because the largest remaining value is always at the root of a max-heap, this naturally produces the array in ascending order, one extraction at a time.`,
- `A binary heap doesn't need pointers or a separate tree structure at all — it can be stored directly in an array. For a node at index i, its children live at indices 2i+1 and 2i+2, and its parent lives at index floor((i-1)/2). This "implicit tree" is exactly what makes Heap Sort an in-place algorithm: the same array that holds the values also encodes the tree shape.`,
- `The algorithm runs in two phases. First, build a max-heap out of the entire array by sifting down every non-leaf node, starting from the last one and working back to the root — this bottom-up approach builds the heap in linear time. Second, repeatedly swap the root with the last element of the current heap, shrink the heap by one, and sift the new root down to restore the heap property. After n-1 extractions, the array is fully sorted.`,
- `Because it needs no extra memory beyond a few variables and never degrades on any input, Heap Sort is a reliable choice when worst-case O(n log n) time and O(1) space both matter — it's what backs priority queues, and shows up in hybrid sorts like introsort, which falls back to Heap Sort when Quick Sort's recursion gets too deep.`,
+ `Heap Sort sorts an array in place by first turning it into a max-heap (a binary tree where every parent is greater than or equal to its children) and then repeatedly removing the largest element (the root) and placing it at the end of the unsorted region. Because the largest remaining value is always at the root of a max-heap, this naturally produces the array in ascending order, one extraction at a time.`,
+ `A binary heap doesn't need pointers or a separate tree structure at all: it can be stored directly in an array. For a node at index i, its children live at indices 2i+1 and 2i+2, and its parent lives at index floor((i-1)/2). This "implicit tree" is exactly what makes Heap Sort an in-place algorithm: the same array that holds the values also encodes the tree shape.`,
+ `The algorithm runs in two phases. First, build a max-heap out of the entire array by sifting down every non-leaf node, starting from the last one and working back to the root; this bottom-up approach builds the heap in linear time. Second, repeatedly swap the root with the last element of the current heap, shrink the heap by one, and sift the new root down to restore the heap property. After n-1 extractions, the array is fully sorted.`,
+ `Because it needs no extra memory beyond a few variables and never degrades on any input, Heap Sort is a reliable choice when worst-case O(n log n) time and O(1) space both matter: it's what backs priority queues, and shows up in hybrid sorts like introsort, which falls back to Heap Sort when Quick Sort's recursion gets too deep.`,
];
const algorithm = [
@@ -93,18 +93,18 @@ const Content = () => {
points: "Repeatedly extract the maximum:",
subpoints: [
"Swap the root (largest value) with the last element of the current heap",
- "Shrink the heap size by one — that swapped element is now in its final sorted position",
+ "Shrink the heap size by one, since that swapped element is now in its final sorted position",
"Sift the new root down to restore the max-heap property",
],
},
- { points: "Stop once the heap size reaches 1 — the array is fully sorted" },
+ { points: "Stop once the heap size reaches 1, since the array is fully sorted" },
];
const complexity = [
- { points: "Best Case: O(n log n) — building the heap is O(n), and each of the n extractions costs O(log n)." },
- { points: "Average Case: O(n log n) — same shape of work regardless of the input's initial order." },
- { points: "Worst Case: O(n log n) — unlike Quick Sort, there's no pathological input that degrades this." },
- { points: "Space Complexity: O(1) — sorting happens in place within the array." },
+ { points: "Best Case: O(n log n), since building the heap is O(n), and each of the n extractions costs O(log n)." },
+ { points: "Average Case: O(n log n), the same shape of work regardless of the input's initial order." },
+ { points: "Worst Case: O(n log n); unlike Quick Sort, there's no pathological input that degrades this." },
+ { points: "Space Complexity: O(1), since sorting happens in place within the array." },
];
return (
@@ -152,7 +152,7 @@ const Content = () => {
-
+
-
+ {/* pop() */}
+ - Stack Basic Operations -
+ {/* push() */} ++ + push() +
++ A new node is created pointing to whatever top currently points to, then top is repointed to the new node. Nothing else in the list is touched, which is why this runs in O(1). +
+
+
+ ↓ push(7) ↓
+
-
-
-
- -
- {opeartions.map((item, index) => (
-
-
-
- {item.points} -
- {item.subpoints && ( --
- {item.subpoints.map((subitem, subindex) => (
-
- - {subitem} - - ))} -
- ))}
-
+ + pop() +
++ If top is null there's nothing to remove, so pop reports "Stack Underflow". Otherwise the data at top is saved, top is moved to point at the next node, and the saved data is returned. The old top node itself is left for garbage collection. +
+
+
+ ↓ pop() → returns 7 ↓
+
-
+
-
+ {/* isEmpty() & size() */}
+ - Stack Helper Operations -
+ {/* peek() */} ++ + peek() +
++ Returns the data at the top node without moving the top pointer, so the stack is left exactly as it was. If top is null, it returns null instead. +
+
+
+
-
-
-
- -
- {helper.map((item, index) => (
-
-
-
- {item.points} -
- {item.subpoints && ( --
- {item.subpoints.map((subitem, subindex) => (
-
- - {subitem} - - ))} -
- ))}
-
+ + isEmpty() & size() +
+
+ isEmpty() is just a null check on top. size() is O(1) if a counter is maintained on every push/pop, or O(n) if it has to walk the whole list counting nodes instead.
+
+
isEmpty() → true
+- Visualize Push, Pop, Peek, and IsEmpty operations + Visualize the IsEmpty operation on a stack
-
- {/* Controls */}
-
-
+
- setInputValue(e.target.value)}
- placeholder="Enter a value"
- className="flex-1 p-2 rounded dark:bg-neutral-900 border"
- disabled={isAnimating}
- />
-
-
-
-
-
-
-
+
- {
const { theme } = useTheme();
const paragraphs = [
- `Serialization converts a tree into a flat string (or byte stream) that can be saved to disk, sent over a network, or stored in a database. Deserialization is the reverse: reading that string back and rebuilding a tree that's structurally identical to the original — same shape, same values, same left/right placement everywhere.`,
- `The tricky part isn't encoding the values — it's encoding the *shape*. A plain list of values loses information about which nodes were children of which, and where branches were missing. The standard fix is to explicitly record empty children with a marker (commonly "null" or "#") at every point a node is absent, using a preorder traversal: visit the node, then recurse left, then recurse right, writing a marker whenever a child doesn't exist.`,
- `Because every empty spot is explicitly recorded, deserialization can rebuild the exact structure by reading tokens in that same preorder sequence: read one token — if it's a null marker, that subtree is empty; otherwise create a node from it, then recursively build its left child from the next tokens, then its right child. The reader never needs to guess where one subtree ends and another begins.`,
+ `Serialization converts a tree into a flat string (or byte stream) that can be saved to disk, sent over a network, or stored in a database. Deserialization is the reverse: reading that string back and rebuilding a tree that's structurally identical to the original: same shape, same values, same left/right placement everywhere.`,
+ `The tricky part isn't encoding the values; it's encoding the *shape*. A plain list of values loses information about which nodes were children of which, and where branches were missing. The standard fix is to explicitly record empty children with a marker (commonly "null" or "#") at every point a node is absent, using a preorder traversal: visit the node, then recurse left, then recurse right, writing a marker whenever a child doesn't exist.`,
+ `Because every empty spot is explicitly recorded, deserialization can rebuild the exact structure by reading tokens in that same preorder sequence: read one token, and if it's a null marker, that subtree is empty; otherwise create a node from it, then recursively build its left child from the next tokens, then its right child. The reader never needs to guess where one subtree ends and another begins.`,
`This pattern shows up anywhere tree-shaped data needs to survive outside memory: saving a game's scene graph, sending a parsed expression tree between services, caching a computed index structure, or simply persisting any hierarchical data model to JSON or a file.`,
];
@@ -92,14 +92,14 @@ const Content = () => {
points: "Deserialize (read tokens in the same order they were written):",
subpoints: [
"Read the next token",
- "If it's a null marker, this subtree is empty — return immediately",
+ "If it's a null marker, this subtree is empty, so return immediately",
"Otherwise, create a node from it, then recursively read its left child, then its right child",
],
},
];
const complexity = [
- { points: "Time Complexity: O(n) for both serialize and deserialize — every node and every null marker is visited exactly once." },
+ { points: "Time Complexity: O(n) for both serialize and deserialize, since every node and every null marker is visited exactly once." },
{ points: "Space Complexity: O(n) for the output string, plus O(h) recursion stack for the traversal." },
];
diff --git a/app/visualizer/trees/algorithms/serialize-deserialize/quiz.jsx b/app/visualizer/trees/algorithms/serialize-deserialize/quiz.jsx
index 5e6f214..f5c18e5 100755
--- a/app/visualizer/trees/algorithms/serialize-deserialize/quiz.jsx
+++ b/app/visualizer/trees/algorithms/serialize-deserialize/quiz.jsx
@@ -21,17 +21,17 @@ const SerializeDeserializeQuiz = () => {
options: [
"Values can't be written as text",
"A list of values alone loses information about which nodes were children of which and where children were missing",
- "It's actually enough — no extra information is needed",
+ "It's actually enough, no extra information is needed",
"Lists can only hold numbers, not tree nodes"
],
correctAnswer: 1,
- explanation: "Without recording the shape — including exactly where children are absent — many different trees could produce the same list of values."
+ explanation: "Without recording the shape, including exactly where children are absent, many different trees could produce the same list of values."
},
{
question: "What does the null marker represent during serialization?",
options: [
"A node with value zero",
- "An empty child — the traversal reached a spot where no node exists",
+ "An empty child: the traversal reached a spot where no node exists",
"The end of the entire string",
"A duplicate value that should be skipped"
],
@@ -47,7 +47,7 @@ const SerializeDeserializeQuiz = () => {
"It reconstructs the tree in reverse order"
],
correctAnswer: 2,
- explanation: "A null marker is a direct signal to stop — there's no child here, so the recursive call returns without consuming any more tokens for that branch."
+ explanation: "A null marker is a direct signal to stop: there's no child here, so the recursive call returns without consuming any more tokens for that branch."
},
{
question: "What is the time complexity of both serialize and deserialize?",
diff --git a/app/visualizer/trees/algorithms/tree-diameter/animation.jsx b/app/visualizer/trees/algorithms/tree-diameter/animation.jsx
index b7143bd..1490f55 100755
--- a/app/visualizer/trees/algorithms/tree-diameter/animation.jsx
+++ b/app/visualizer/trees/algorithms/tree-diameter/animation.jsx
@@ -23,7 +23,7 @@ const height = (node) => (node ? 1 + Math.max(height(node.left), height(node.rig
// Post-order pass: at every node, the longest path *through* it is
// leftHeight + rightHeight edges. The overall diameter is the max of that
-// value across every node — not necessarily the one at the root.
+// value across every node, not necessarily the one at the root.
const computeDiameter = (root) => {
const steps = [];
let best = { diameter: -1, node: null };
@@ -134,7 +134,7 @@ const DiameterVisualizer = () => {
const revealStep = () => {
const s = steps[step];
setComputedHeights((prev) => ({ ...prev, [s.value]: s.h }));
- setMessage(`height(${s.value}) = ${s.h} — longest path through ${s.value} spans ${s.diameter} edge${s.diameter === 1 ? "" : "s"}`);
+ setMessage(`height(${s.value}) = ${s.h}: longest path through ${s.value} spans ${s.diameter} edge${s.diameter === 1 ? "" : "s"}`);
step++;
if (step < steps.length) {
@@ -365,7 +365,7 @@ const DiameterVisualizer = () => {
) : (
diff --git a/app/visualizer/trees/algorithms/tree-diameter/content.jsx b/app/visualizer/trees/algorithms/tree-diameter/content.jsx
index 4af861d..fb81745 100755
--- a/app/visualizer/trees/algorithms/tree-diameter/content.jsx
+++ b/app/visualizer/trees/algorithms/tree-diameter/content.jsx
@@ -78,14 +78,14 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `The diameter of a tree is the number of edges on the longest path between any two nodes. That path doesn't have to pass through the root — it can start and end anywhere, and in most trees it actually cuts through some node in the middle where two deep subtrees meet.`,
- `The key insight: for any single node, the longest path that passes *through* it is the height of its left subtree plus the height of its right subtree — one leg going down each side. Checking every node this way and keeping the largest total automatically finds the true diameter, because whichever node happens to be the meeting point of the two longest branches will produce the biggest sum.`,
- `This means diameter can be computed in a single post-order traversal: recursively find the height of the left and right subtrees first, use them to compute this node's own height (1 + the taller side) and its "path-through" value (left height + right height), then update a running maximum. No repeated re-traversal is needed — every node's height is computed exactly once and reused by its parent.`,
+ `The diameter of a tree is the number of edges on the longest path between any two nodes. That path doesn't have to pass through the root: it can start and end anywhere, and in most trees it actually cuts through some node in the middle where two deep subtrees meet.`,
+ `The key insight: for any single node, the longest path that passes *through* it is the height of its left subtree plus the height of its right subtree, one leg going down each side. Checking every node this way and keeping the largest total automatically finds the true diameter, because whichever node happens to be the meeting point of the two longest branches will produce the biggest sum.`,
+ `This means diameter can be computed in a single post-order traversal: recursively find the height of the left and right subtrees first, use them to compute this node's own height (1 + the taller side) and its "path-through" value (left height + right height), then update a running maximum. No repeated re-traversal is needed, since every node's height is computed exactly once and reused by its parent.`,
`Diameter shows up whenever "the two most distant points in a hierarchy" matters: the worst-case latency between two nodes in a network topology tree, the longest chain of dependencies in a build graph, or simply describing how "spread out" or "stringy" versus "bushy" a tree's shape is.`,
];
const algorithm = [
- { points: "Run a post-order traversal — process both children before the current node" },
+ { points: "Run a post-order traversal, processing both children before the current node" },
{
points: "At each node, using the already-computed heights of its children:",
subpoints: [
@@ -93,12 +93,12 @@ const Content = () => {
"The longest path through this node = left child height + right child height",
],
},
- { points: "Track the maximum path-through value seen across every node — that maximum is the diameter" },
+ { points: "Track the maximum path-through value seen across every node: that maximum is the diameter" },
];
const complexity = [
- { points: "Time Complexity: O(n) — every node's height is computed exactly once in a single traversal." },
- { points: "Space Complexity: O(h) — recursion stack depth equals the tree's height (O(log n) balanced, O(n) skewed)." },
+ { points: "Time Complexity: O(n), since every node's height is computed exactly once in a single traversal." },
+ { points: "Space Complexity: O(h), where recursion stack depth equals the tree's height (O(log n) balanced, O(n) skewed)." },
];
return (
@@ -139,7 +139,7 @@ const Content = () => {
Stack Visualization
+ - {/* Operation Status */} +
{operation && (
-
+
diff --git a/app/visualizer/trees/algorithms/lowest-common-ancestor/content.jsx b/app/visualizer/trees/algorithms/lowest-common-ancestor/content.jsx
index 8c61d6d..d105f0f 100755
--- a/app/visualizer/trees/algorithms/lowest-common-ancestor/content.jsx
+++ b/app/visualizer/trees/algorithms/lowest-common-ancestor/content.jsx
@@ -72,9 +72,9 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `The Lowest Common Ancestor of two nodes A and B is the deepest node in the tree that has both A and B as descendants (a node counts as its own descendant, so LCA(A, A) is just A). It's "lowest" in the sense of being as far from the root as possible while still being an ancestor of both — the point where the paths from A and B up to the root first merge.`,
- `On a general binary tree (no ordering guarantee), finding the LCA needs to search the whole tree: recursively check the left and right subtrees for A and B. If a node's left subtree contains one of them and its right subtree contains the other, that node is the split point — the LCA. If only one subtree contains either of them, the LCA must be further down inside that subtree.`,
- `A Binary Search Tree's ordering turns this into something far cheaper. Starting at the root and comparing both values against the current node: if both A and B are smaller, the LCA must be somewhere in the left subtree (skip the right entirely). If both are larger, it must be in the right subtree. The moment they're no longer both on the same side — one is smaller (or equal) and the other is larger (or equal) — the paths to A and B have just diverged, and the current node is the LCA. No backtracking, no exploring the "wrong" subtree at all.`,
+ `The Lowest Common Ancestor of two nodes A and B is the deepest node in the tree that has both A and B as descendants (a node counts as its own descendant, so LCA(A, A) is just A). It's "lowest" in the sense of being as far from the root as possible while still being an ancestor of both: the point where the paths from A and B up to the root first merge.`,
+ `On a general binary tree (no ordering guarantee), finding the LCA needs to search the whole tree: recursively check the left and right subtrees for A and B. If a node's left subtree contains one of them and its right subtree contains the other, that node is the split point: the LCA. If only one subtree contains either of them, the LCA must be further down inside that subtree.`,
+ `A Binary Search Tree's ordering turns this into something far cheaper. Starting at the root and comparing both values against the current node: if both A and B are smaller, the LCA must be somewhere in the left subtree (skip the right entirely). If both are larger, it must be in the right subtree. The moment they're no longer both on the same side (one is smaller-or-equal and the other is larger-or-equal), the paths to A and B have just diverged, and the current node is the LCA. No backtracking, no exploring the "wrong" subtree at all.`,
`LCA queries show up any time a "closest shared point" needs to be found across two positions in a hierarchy: git's merge-base command (the common ancestor commit two branches diverged from), routing decisions in network topology trees, and evolutionary/phylogenetic trees (the most recent common ancestor of two species). When the same tree needs many repeated LCA queries, the answers are often precomputed into an O(1)-per-query structure using techniques built on top of range-minimum queries.`,
];
@@ -85,7 +85,7 @@ const Content = () => {
subpoints: [
"If both are smaller, move to the left child",
"If both are larger, move to the right child",
- "Otherwise (one is smaller-or-equal and the other is larger-or-equal), the current node is the LCA — stop",
+ "Otherwise (one is smaller-or-equal and the other is larger-or-equal), the current node is the LCA, so stop",
],
},
{ points: "Repeat until the split point is found" },
@@ -134,7 +134,7 @@ const Content = () => {
{operation}
)}
- {/* Message Display */}
- {message && (
+ {message && isEmptyStatus !== null && (
{message}
)}
- {/* Vertical Stack */}
-
- {/* Top indicator */}
-
diff --git a/app/visualizer/trees/advanced/segment-trees/content.jsx b/app/visualizer/trees/advanced/segment-trees/content.jsx
index 6911ce4..262dd01 100755
--- a/app/visualizer/trees/advanced/segment-trees/content.jsx
+++ b/app/visualizer/trees/advanced/segment-trees/content.jsx
@@ -65,10 +65,10 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `A Segment Tree answers a question that neither a plain array nor a running-total (prefix-sum) array handles well at the same time: "what's the sum (or min, max, gcd...) of elements from index l to r?", while also supporting fast updates to individual elements. A prefix-sum array answers range queries in O(1), but a single update forces you to recompute every prefix after it — O(n) per update. A segment tree gets both operations down to O(log n).`,
- `Every node in a segment tree represents a contiguous range of the underlying array. Leaves represent single elements; every internal node represents the union of its two children's ranges, and stores the combined result of some associative operation (sum, min, max, etc.) over that whole range — computed once and cached, not recomputed from scratch on every query.`,
- `A range query works by decomposing the query range into a small number of these pre-combined node ranges. Starting from the root, if a node's range falls entirely outside the query, it's skipped. If it falls entirely inside the query, its cached value is used directly — no need to look at its children at all. Only when a node's range partially overlaps the query does the search recurse into both children. This decomposition never needs more than O(log n) nodes to cover any range.`,
- `A point update walks straight from the root down to the one leaf that needs to change, updates it, and then recomputes each ancestor's cached value on the way back up — exactly one path of length O(log n), touching nothing else in the tree.`,
+ `A Segment Tree answers a question that neither a plain array nor a running-total (prefix-sum) array handles well at the same time: "what's the sum (or min, max, gcd...) of elements from index l to r?", while also supporting fast updates to individual elements. A prefix-sum array answers range queries in O(1), but a single update forces you to recompute every prefix after it, O(n) per update. A segment tree gets both operations down to O(log n).`,
+ `Every node in a segment tree represents a contiguous range of the underlying array. Leaves represent single elements; every internal node represents the union of its two children's ranges, and stores the combined result of some associative operation (sum, min, max, etc.) over that whole range, computed once and cached, not recomputed from scratch on every query.`,
+ `A range query works by decomposing the query range into a small number of these pre-combined node ranges. Starting from the root, if a node's range falls entirely outside the query, it's skipped. If it falls entirely inside the query, its cached value is used directly, no need to look at its children at all. Only when a node's range partially overlaps the query does the search recurse into both children. This decomposition never needs more than O(log n) nodes to cover any range.`,
+ `A point update walks straight from the root down to the one leaf that needs to change, updates it, and then recomputes each ancestor's cached value on the way back up, exactly one path of length O(log n), touching nothing else in the tree.`,
];
const algorithm = [
@@ -85,9 +85,9 @@ const Content = () => {
];
const complexity = [
- { points: "Build: O(n) — every node is computed exactly once." },
- { points: "Range Query: O(log n) — at most a constant number of nodes per level are visited." },
- { points: "Point Update: O(log n) — exactly one root-to-leaf path is touched." },
+ { points: "Build: O(n), every node is computed exactly once." },
+ { points: "Range Query: O(log n), at most a constant number of nodes per level are visited." },
+ { points: "Point Update: O(log n), exactly one root-to-leaf path is touched." },
];
return (
diff --git a/app/visualizer/trees/advanced/segment-trees/quiz.jsx b/app/visualizer/trees/advanced/segment-trees/quiz.jsx
index 7cc5207..0452598 100755
--- a/app/visualizer/trees/advanced/segment-trees/quiz.jsx
+++ b/app/visualizer/trees/advanced/segment-trees/quiz.jsx
@@ -25,35 +25,35 @@ const SegmentTreeQuiz = () => {
"A pointer to every leaf in the tree"
],
correctAnswer: 1,
- explanation: "Every node — leaf or internal — represents a range; internal nodes cache the combined result of their two children's ranges so it never needs recomputing from scratch."
+ explanation: "Every node, whether leaf or internal, represents a range; internal nodes cache the combined result of their two children's ranges so it never needs recomputing from scratch."
},
{
question: "During a range query, what happens when a node's range falls entirely inside the query range?",
options: [
"The query fails",
- "Its cached value is used directly — there's no need to look at its children at all",
+ "Its cached value is used directly, so there's no need to look at its children at all",
"It must still recurse into both children to double-check",
"It's skipped entirely"
],
correctAnswer: 1,
- explanation: "This is exactly what makes segment trees fast — a single cached value stands in for an entire subrange, which is what keeps the number of visited nodes at O(log n) instead of O(n)."
+ explanation: "This is exactly what makes segment trees fast: a single cached value stands in for an entire subrange, which is what keeps the number of visited nodes at O(log n) instead of O(n)."
},
{
question: "What happens on a point update?",
options: [
"The entire tree is rebuilt from scratch",
- "Only the path from the root down to the affected leaf is touched — the leaf's value changes, then every ancestor's cached value is recomputed",
+ "Only the path from the root down to the affected leaf is touched: the leaf's value changes, then every ancestor's cached value is recomputed",
"Only the leaf is updated; ancestors are left stale until the next query",
"All leaves are updated"
],
correctAnswer: 1,
- explanation: "Updating one element only invalidates the O(log n) ancestors whose ranges include that index — everything else in the tree stays correct and untouched."
+ explanation: "Updating one element only invalidates the O(log n) ancestors whose ranges include that index; everything else in the tree stays correct and untouched."
},
{
question: "What is the time complexity of building a segment tree over n elements?",
options: ["O(1)", "O(log n)", "O(n)", "O(n log n)"],
correctAnswer: 2,
- explanation: "Every node — there are O(n) of them in total — is computed exactly once during the build, giving O(n) overall."
+ explanation: "Every node (there are O(n) of them in total) is computed exactly once during the build, giving O(n) overall."
}
];
diff --git a/app/visualizer/trees/algorithms/lowest-common-ancestor/animation.jsx b/app/visualizer/trees/algorithms/lowest-common-ancestor/animation.jsx
index bf4a8a0..42d02bd 100755
--- a/app/visualizer/trees/algorithms/lowest-common-ancestor/animation.jsx
+++ b/app/visualizer/trees/algorithms/lowest-common-ancestor/animation.jsx
@@ -35,8 +35,8 @@ const collectValues = (node, out = []) => {
return out;
};
-// Walks from the root toward the split point where p and q's paths diverge —
-// that split point is the LCA — recording, at each step, every value in the
+// Walks from the root toward the split point where p and q's paths diverge,
+// that split point is the LCA, recording, at each step, every value in the
// subtree ruled out by that comparison.
const lcaWithElimination = (root, p, q) => {
const path = [];
@@ -152,9 +152,9 @@ const LcaVisualizer = () => {
setHighlightPath((prev) => [...prev, current]);
setDimmedValues((prev) => [...prev, ...(eliminatedPerStep[step] || [])]);
if (step < path.length - 1) {
- setMessage(`Both ${p} and ${q} are on the same side of ${current} — descending further`);
+ setMessage(`Both ${p} and ${q} are on the same side of ${current}, descending further`);
} else {
- setMessage(`${p} and ${q} split apart at ${current} — this is the LCA`);
+ setMessage(`${p} and ${q} split apart at ${current}: this is the LCA`);
}
step++;
@@ -388,7 +388,7 @@ const LcaVisualizer = () => {
) : (
- {stack.length > 0 ? "↑ Top" : ""}
+
+
) : (
diff --git a/app/visualizer/trees/advanced/prefix-tree/content.jsx b/app/visualizer/trees/advanced/prefix-tree/content.jsx
index 0c8b324..89c5d68 100755
--- a/app/visualizer/trees/advanced/prefix-tree/content.jsx
+++ b/app/visualizer/trees/advanced/prefix-tree/content.jsx
@@ -76,16 +76,16 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `A Trie (pronounced "try", from re-"trie"-val, and also called a Prefix Tree) stores a set of strings by turning shared prefixes into shared paths through the tree. Unlike a BST, a trie doesn't store a whole key per node — each edge represents a single character, and the string you get by reading the characters from the root down to any node is that node's prefix. A small boolean flag on a node marks whether the prefix ending there is also a complete word that was inserted.`,
- `This "shared paths for shared prefixes" structure is what makes tries so effective for prefix-based operations: "cat" and "car" and "cart" all share the same "ca"/"car" path and only branch where they actually differ. That single property is why tries are the standard structure behind autocomplete and search-as-you-type suggestions, spell-checkers, and IP routing tables (where the longest matching prefix determines the route) — all workloads built entirely around "find everything starting with X."`,
- `Both insertion and search walk one character at a time from the root: insertion follows existing edges where they already exist and creates new nodes only where the path doesn't yet exist, then marks the final node as end-of-word. Search does the same walk — if it ever needs an edge that doesn't exist, the word (or prefix) definitely isn't in the trie; if it reaches the end of the word, it still has to check that node's end-of-word flag, because the path existing only proves the string is a prefix of something, not that it was inserted as its own word.`,
- `Both operations run in O(L) time, where L is the length of the word — not O(log n) or O(n) in terms of how many words are already stored. A hash set can also do exact lookups in roughly that time, but it can't efficiently answer "what words start with this prefix" the way a trie can, since a matching prefix's subtree already holds exactly the words that share it.`,
+ `A Trie (pronounced "try", from re-"trie"-val, and also called a Prefix Tree) stores a set of strings by turning shared prefixes into shared paths through the tree. Unlike a BST, a trie doesn't store a whole key per node: each edge represents a single character, and the string you get by reading the characters from the root down to any node is that node's prefix. A small boolean flag on a node marks whether the prefix ending there is also a complete word that was inserted.`,
+ `This "shared paths for shared prefixes" structure is what makes tries so effective for prefix-based operations: "cat" and "car" and "cart" all share the same "ca"/"car" path and only branch where they actually differ. That single property is why tries are the standard structure behind autocomplete and search-as-you-type suggestions, spell-checkers, and IP routing tables (where the longest matching prefix determines the route), all workloads built entirely around "find everything starting with X."`,
+ `Both insertion and search walk one character at a time from the root: insertion follows existing edges where they already exist and creates new nodes only where the path doesn't yet exist, then marks the final node as end-of-word. Search does the same walk: if it ever needs an edge that doesn't exist, the word (or prefix) definitely isn't in the trie; if it reaches the end of the word, it still has to check that node's end-of-word flag, because the path existing only proves the string is a prefix of something, not that it was inserted as its own word.`,
+ `Both operations run in O(L) time, where L is the length of the word, not O(log n) or O(n) in terms of how many words are already stored. A hash set can also do exact lookups in roughly that time, but it can't efficiently answer "what words start with this prefix" the way a trie can, since a matching prefix's subtree already holds exactly the words that share it.`,
];
const algorithm = [
{ points: "Insertion: start at the root; for each character in the word, follow the matching child edge if it exists, or create a new node for it if it doesn't; after the last character, mark that node as end-of-word" },
- { points: "Search: start at the root; for each character, follow the matching child edge — if it's missing at any point, the word isn't in the trie" },
- { points: "If every character is matched, the word is in the trie only if the final node's end-of-word flag is set — otherwise it's merely a prefix of other stored words" },
+ { points: "Search: start at the root; for each character, follow the matching child edge; if it's missing at any point, the word isn't in the trie" },
+ { points: "If every character is matched, the word is in the trie only if the final node's end-of-word flag is set; otherwise it's merely a prefix of other stored words" },
];
const complexity = [
diff --git a/app/visualizer/trees/advanced/prefix-tree/quiz.jsx b/app/visualizer/trees/advanced/prefix-tree/quiz.jsx
index 9cf0cbb..e59ede5 100755
--- a/app/visualizer/trees/advanced/prefix-tree/quiz.jsx
+++ b/app/visualizer/trees/advanced/prefix-tree/quiz.jsx
@@ -20,12 +20,12 @@ const PrefixTreeQuiz = () => {
"Because both words are the same length"
],
correctAnswer: 1,
- explanation: "A trie only branches where words actually differ — 'cat' and 'car' both follow c -> a and only split into separate 't' and 'r' children."
+ explanation: "A trie only branches where words actually differ: 'cat' and 'car' both follow c -> a and only split into separate 't' and 'r' children."
},
{
question: "If searching for a word successfully follows an edge for every character, why isn't that enough to confirm the word is in the trie?",
options: [
- "It actually is enough — nothing else needs to be checked",
+ "It actually is enough, nothing else needs to be checked",
"Because reaching that node only proves the string is a prefix of something stored; you still need to check that node's end-of-word flag",
"Because trie searches are always inaccurate",
"Because you'd need to check every other node in the tree too"
@@ -42,7 +42,7 @@ const PrefixTreeQuiz = () => {
"There's no real difference between the two"
],
correctAnswer: 1,
- explanation: "Once you walk to the node for a prefix, everything below it in the trie is, by construction, every stored word that starts with that prefix — a hash set has no equivalent structure to exploit."
+ explanation: "Once you walk to the node for a prefix, everything below it in the trie is, by construction, every stored word that starts with that prefix, while a hash set has no equivalent structure to exploit."
},
{
question: "What is the time complexity of inserting or searching for a word of length L in a trie?",
diff --git a/app/visualizer/trees/advanced/red-black/animation.jsx b/app/visualizer/trees/advanced/red-black/animation.jsx
index b7bbfa9..d353f94 100755
--- a/app/visualizer/trees/advanced/red-black/animation.jsx
+++ b/app/visualizer/trees/advanced/red-black/animation.jsx
@@ -52,7 +52,7 @@ const fixInsertRB = (root, z, events) => {
uncle.color = "BLACK";
grandparent.color = "RED";
events.push({
- text: `uncle ${uncle.value} is red — recolor ${parent.value} and ${uncle.value} to black, ${grandparent.value} to red`,
+ text: `uncle ${uncle.value} is red, so recolor ${parent.value} and ${uncle.value} to black, ${grandparent.value} to red`,
touched: [parent.value, uncle.value, grandparent.value],
});
z = grandparent;
@@ -60,7 +60,7 @@ const fixInsertRB = (root, z, events) => {
if (z === parent.right) {
z = parent;
root = rotateLeftRB(root, z);
- events.push({ text: `zig-zag shape — rotate left at ${z.value}`, touched: [z.value] });
+ events.push({ text: `zig-zag shape, rotate left at ${z.value}`, touched: [z.value] });
}
z.parent.color = "BLACK";
grandparent.color = "RED";
@@ -77,7 +77,7 @@ const fixInsertRB = (root, z, events) => {
uncle.color = "BLACK";
grandparent.color = "RED";
events.push({
- text: `uncle ${uncle.value} is red — recolor ${parent.value} and ${uncle.value} to black, ${grandparent.value} to red`,
+ text: `uncle ${uncle.value} is red, so recolor ${parent.value} and ${uncle.value} to black, ${grandparent.value} to red`,
touched: [parent.value, uncle.value, grandparent.value],
});
z = grandparent;
@@ -85,7 +85,7 @@ const fixInsertRB = (root, z, events) => {
if (z === parent.left) {
z = parent;
root = rotateRightRB(root, z);
- events.push({ text: `zig-zag shape — rotate right at ${z.value}`, touched: [z.value] });
+ events.push({ text: `zig-zag shape, rotate right at ${z.value}`, touched: [z.value] });
}
z.parent.color = "BLACK";
grandparent.color = "RED";
@@ -177,13 +177,13 @@ const RedBlackVisualizer = () => {
setTimeout(() => {
setRoot(newRoot);
if (wasEmpty) {
- setMessage(`Inserted ${value} as the root — colored black`);
+ setMessage(`Inserted ${value} as the root, colored black`);
setHighlightNodes([]);
} else if (events.length === 0) {
- setMessage(`Inserted ${value} as a red leaf — its parent was black, so no fixup was needed`);
+ setMessage(`Inserted ${value} as a red leaf; its parent was black, so no fixup was needed`);
setHighlightNodes([]);
} else {
- setMessage(`Inserted ${value} — ${events.map((e) => e.text).join("; then ")}`);
+ setMessage(`Inserted ${value}: ${events.map((e) => e.text).join("; then ")}`);
const touched = events.flatMap((e) => e.touched);
setHighlightNodes(touched);
setTimeout(() => setHighlightNodes([]), 1400);
@@ -392,7 +392,7 @@ const RedBlackVisualizer = () => {
) : (
diff --git a/app/visualizer/trees/advanced/red-black/content.jsx b/app/visualizer/trees/advanced/red-black/content.jsx
index e6fc31b..6efc261 100755
--- a/app/visualizer/trees/advanced/red-black/content.jsx
+++ b/app/visualizer/trees/advanced/red-black/content.jsx
@@ -52,17 +52,17 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `A Red-Black Tree is a self-balancing Binary Search Tree that keeps itself roughly balanced by coloring every node either red or black and enforcing a small set of rules about how those colors can be arranged. Unlike an AVL tree, which balances strictly by height, a Red-Black Tree balances by color — and that looser constraint is exactly what makes it cheaper to maintain.`,
- `The five rules (the "red-black properties") together guarantee that the longest possible root-to-leaf path is never more than twice as long as the shortest one. That's a weaker balance guarantee than AVL's, but it's enough to keep every operation at O(log n), and it means Red-Black Trees need at most one or two rotations per insertion or deletion — compared to AVL, which can cascade rotations back up the tree. This is why Red-Black Trees are the default choice inside C++'s \`std::map\`/\`std::set\`, Java's \`TreeMap\`/\`TreeSet\`, and the Linux kernel's process scheduler and virtual memory management.`,
- `Insertion always starts the same way a plain BST insertion does, and the new node is always colored red. Coloring it red (rather than black) means it can never violate the "same black-height on every path" rule by itself — the only rule a fresh red leaf can break is "a red node can't have a red parent." If that happens, a fixup procedure runs, walking back up the tree recoloring nodes and, when recoloring alone isn't enough, performing at most two rotations to restore all five properties.`,
- `Insertion (with fixup) needs O(1) extra space beyond the recursion/loop state — only a constant number of pointers get rewired or recolored, no matter how large the tree is.`,
+ `A Red-Black Tree is a self-balancing Binary Search Tree that keeps itself roughly balanced by coloring every node either red or black and enforcing a small set of rules about how those colors can be arranged. Unlike an AVL tree, which balances strictly by height, a Red-Black Tree balances by color, and that looser constraint is exactly what makes it cheaper to maintain.`,
+ `The five rules (the "red-black properties") together guarantee that the longest possible root-to-leaf path is never more than twice as long as the shortest one. That's a weaker balance guarantee than AVL's, but it's enough to keep every operation at O(log n), and it means Red-Black Trees need at most one or two rotations per insertion or deletion, compared to AVL, which can cascade rotations back up the tree. This is why Red-Black Trees are the default choice inside C++'s \`std::map\`/\`std::set\`, Java's \`TreeMap\`/\`TreeSet\`, and the Linux kernel's process scheduler and virtual memory management.`,
+ `Insertion always starts the same way a plain BST insertion does, and the new node is always colored red. Coloring it red (rather than black) means it can never violate the "same black-height on every path" rule by itself: the only rule a fresh red leaf can break is "a red node can't have a red parent." If that happens, a fixup procedure runs, walking back up the tree recoloring nodes and, when recoloring alone isn't enough, performing at most two rotations to restore all five properties.`,
+ `Insertion (with fixup) needs O(1) extra space beyond the recursion/loop state: only a constant number of pointers get rewired or recolored, no matter how large the tree is.`,
];
const properties = [
{ title: "1. Every node is red or black", body: "Each node stores one extra bit of information: its color." },
{ title: "2. The root is always black", body: "If an insertion colors the root red, it's flipped back to black once the fixup finishes." },
{ title: "3. Every NIL leaf is black", body: "The (implicit) null children at the bottom of the tree are treated as black leaves." },
- { title: "4. No red node has a red child", body: "Two reds can never appear back-to-back on any path — this is the rule a new red insertion can violate." },
+ { title: "4. No red node has a red child", body: "Two reds can never appear back-to-back on any path; this is the rule a new red insertion can violate." },
{ title: "5. Equal black-height on every path", body: "Every path from a node to any of its descendant NIL leaves passes through the same number of black nodes." },
];
@@ -171,7 +171,7 @@ const Content = () => {
+ {stack.length > 0 && "↑ Top"}
-
- {stack.length === 0 ? (
-
diff --git a/app/visualizer/trees/advanced/b-trees/content.jsx b/app/visualizer/trees/advanced/b-trees/content.jsx
index 1a65f6e..03b8146 100755
--- a/app/visualizer/trees/advanced/b-trees/content.jsx
+++ b/app/visualizer/trees/advanced/b-trees/content.jsx
@@ -39,7 +39,7 @@ const SplitDiagram = () => (
- {stack.map((item, index) => (
-
@@ -243,32 +169,4 @@ const StackVisualizer = () => {
);
};
-/* ---------- cute floating cloud (empty) ---------- */
-const EmptyCloud = () => {
- const cloudRef = useRef(null);
- useEffect(() => {
- gsap.to(cloudRef.current, { y: -6, duration: 2, repeat: -1, yoyo: true, ease: "power1.inOut" });
- }, []);
- return (
- (itemRefs.current[index] = el)}
- className={`p-3 border-2 rounded text-center font-medium transition-all ${
- index === 0 && peekedItem !== null
- ? "bg-purple-200 dark:bg-purple-800 border-purple-400 dark:border-purple-600"
- : index === 0
- ? "bg-blue-100 dark:bg-blue-900 border-blue-300 dark:border-blue-700"
- : "bg-white dark:bg-gray-700 border-gray-200 dark:border-gray-600"
- }`}
- >
- {item}
-
- ))}
+
+ {stack.length === 0 && (
+
- {/* Bottom indicator */}
-
+ Stack is empty
)}
+
+ {displayStack.map((item, i) => {
+ const isTop = i === displayStack.length - 1;
+ return (
+ {
+ if (isTop) topRef.current = el;
+ animateDropIn(el);
+ }}
+ className={`h-11 shrink-0 rounded-lg shadow-md flex items-center justify-center font-semibold text-sm text-white bg-gradient-to-br ${
+ isTop
+ ? "from-blue-500 to-blue-600 ring-2 ring-blue-300 dark:ring-blue-700 ring-offset-2 ring-offset-white dark:ring-offset-neutral-950"
+ : "from-slate-400 to-slate-500 dark:from-slate-600 dark:to-slate-700"
+ }`}
+ >
+ {item}
+
+ );
+ })}
- {stack.length > 0 ? "↓ Bottom" : ""}
+
+ {stack.length > 0 && "Bottom"}
-
- Stack is empty
-
- );
-};
-
-export default StackVisualizer;
\ No newline at end of file
+export default StackVisualizer;
diff --git a/app/visualizer/stack/isempty/content.jsx b/app/visualizer/stack/isempty/content.jsx
index d41df60..b5b666b 100755
--- a/app/visualizer/stack/isempty/content.jsx
+++ b/app/visualizer/stack/isempty/content.jsx
@@ -8,7 +8,7 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `isEmpty just tells you whether there's anything on the stack at all. It exists so you can guard pop() and peek() calls — checking first avoids trying to read or remove from a stack that has nothing in it.`,
+ `isEmpty just tells you whether there's anything on the stack at all. It exists so you can guard pop() and peek() calls: checking first avoids trying to read or remove from a stack that has nothing in it.`,
`The isEmpty operation is a simple but crucial part of stack implementation, ensuring safe stack manipulation and preventing runtime errors.`,
];
@@ -191,4 +191,4 @@ const Content = () => {
);
};
- export default content;
\ No newline at end of file
+ export default Content;
\ No newline at end of file
diff --git a/app/visualizer/stack/isfull/content.jsx b/app/visualizer/stack/isfull/content.jsx
index ee3ccd6..00f6293 100755
--- a/app/visualizer/stack/isfull/content.jsx
+++ b/app/visualizer/stack/isfull/content.jsx
@@ -8,7 +8,7 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `isFull tells you whether a stack has run out of room to accept another push. It only really matters for a fixed-capacity stack like an array-backed one — a linked-list stack can just keep allocating nodes, so it rarely needs this check.`,
+ `isFull tells you whether a stack has run out of room to accept another push. It only really matters for a fixed-capacity stack like an array-backed one; a linked-list stack can just keep allocating nodes, so it rarely needs this check.`,
`The Is Full operation is crucial when working with fixed-size stacks to prevent overflow errors. While not needed for dynamically-sized stacks, it's an essential safety check in many system-level implementations.`,
];
diff --git a/app/visualizer/stack/peek/content.jsx b/app/visualizer/stack/peek/content.jsx
index 3f70e6f..aa3cf60 100755
--- a/app/visualizer/stack/peek/content.jsx
+++ b/app/visualizer/stack/peek/content.jsx
@@ -8,7 +8,7 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `Peek gives you a look at whatever's currently on top of the stack, but it leaves the stack exactly as it was — nothing gets popped.`,
+ `Peek gives you a look at whatever's currently on top of the stack, but it leaves the stack exactly as it was: nothing gets popped.`,
`The peek operation is useful when you need to inspect the top element before deciding whether to pop it or push another element onto the stack.`,
];
diff --git a/app/visualizer/stack/polish/postfix/content.jsx b/app/visualizer/stack/polish/postfix/content.jsx
index 0f473e6..a3acfcd 100755
--- a/app/visualizer/stack/polish/postfix/content.jsx
+++ b/app/visualizer/stack/polish/postfix/content.jsx
@@ -8,7 +8,7 @@ const Content = () => {
const paragraph = [
`In postfix notation, also known as Reverse Polish Notation, you write the operator right after its two operands instead of between them.`,
- `So the everyday expression 3 + 4 becomes 3 4 + once converted. There's no ambiguity about order of operations here — the position of each operator in the string already tells you exactly when to apply it, so parentheses become unnecessary.`,
+ `So the everyday expression 3 + 4 becomes 3 4 + once converted. There's no ambiguity about order of operations here: the position of each operator in the string already tells you exactly when to apply it, so parentheses become unnecessary.`,
`Note: Higher precedence means the operation will happen first. When operators have equal precedence, they are evaluated left-to-right (except for exponentiation which is right-to-left).`,
];
@@ -169,4 +169,4 @@ const Content = () => {
);
};
- export default content;
\ No newline at end of file
+ export default Content;
\ No newline at end of file
diff --git a/app/visualizer/stack/push-pop/animation.jsx b/app/visualizer/stack/push-pop/animation.jsx
index 652be02..afe6672 100755
--- a/app/visualizer/stack/push-pop/animation.jsx
+++ b/app/visualizer/stack/push-pop/animation.jsx
@@ -33,7 +33,7 @@ const StackVisualizer = () => {
setStack(next);
};
- // Runs the moment a new "top" box mounts in the DOM — a reliable
+ // Runs the moment a new "top" box mounts in the DOM: a reliable
// drop-in entrance that doesn't depend on any surrounding state timing.
const animateDropIn = (el) => {
if (!el || el.dataset.dropped) return;
diff --git a/app/visualizer/stack/push-pop/content.jsx b/app/visualizer/stack/push-pop/content.jsx
index eb20b07..7a02636 100755
--- a/app/visualizer/stack/push-pop/content.jsx
+++ b/app/visualizer/stack/push-pop/content.jsx
@@ -117,7 +117,7 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `Push and pop are the only two moves a stack really needs. Push adds a value on top, pop takes the top value back off, and because of that, whatever went on last is always the first thing to come off — that's the LIFO (Last In, First Out) rule in action.`,
+ `Push and pop are the only two moves a stack really needs. Push adds a value on top, pop takes the top value back off, and because of that, whatever went on last is always the first thing to come off: that's the LIFO (Last In, First Out) rule in action.`,
`Push and Pop operations are fundamental to stack functionality. While simple to implement, stacks are powerful data structures used in many algorithms and system designs.`,
];
diff --git a/app/visualizer/trees/advanced/b-trees/animation.jsx b/app/visualizer/trees/advanced/b-trees/animation.jsx
index f862bf9..c9af02e 100755
--- a/app/visualizer/trees/advanced/b-trees/animation.jsx
+++ b/app/visualizer/trees/advanced/b-trees/animation.jsx
@@ -3,7 +3,7 @@ import React, { useState } from "react";
import { gsap } from "gsap";
import { Plus, Shuffle, RotateCcw } from "lucide-react";
-const T = 2; // minimum degree — max keys per node = 2T-1 = 3, max children = 2T = 4
+const T = 2; // minimum degree: max keys per node = 2T-1 = 3, max children = 2T = 4
class BTreeNode {
constructor(leaf) {
@@ -31,7 +31,7 @@ const splitChild = (parent, i, events) => {
parent.keys.splice(i, 0, midKey);
events.push({
- text: `node [${[...leftKeys, midKey, ...newChild.keys].join(", ")}] was full — split it, moving median ${midKey} up`,
+ text: `node [${[...leftKeys, midKey, ...newChild.keys].join(", ")}] was full, so split it, moving median ${midKey} up`,
nodes: [fullChild, newChild, parent],
});
};
@@ -155,10 +155,10 @@ const BTreeVisualizer = () => {
setTimeout(() => {
setRoot(newRoot);
if (events.length === 0) {
- setMessage(`Inserted ${value} into a leaf node that had room — no split needed`);
+ setMessage(`Inserted ${value} into a leaf node that had room, so no split was needed`);
setHighlightNodes([]);
} else {
- setMessage(`Inserted ${value} — ${events.map((e) => e.text).join("; then ")}`);
+ setMessage(`Inserted ${value}: ${events.map((e) => e.text).join("; then ")}`);
setHighlightNodes(events.flatMap((e) => e.nodes));
setTimeout(() => setHighlightNodes([]), 1400);
}
@@ -368,7 +368,7 @@ const BTreeVisualizer = () => {
) : (
- No tree yet — insert a value or generate a random tree
+ No tree yet, insert a value or generate a random tree
)}
- Node [10, 20, 30] is full — inserting 25 triggers a split
+ Node [10, 20, 30] is full: inserting 25 triggers a split
- No Fenwick tree yet — build one over a random array
+ No Fenwick tree yet, build one over a random array
)}
diff --git a/app/visualizer/trees/advanced/fenwick-tree/content.jsx b/app/visualizer/trees/advanced/fenwick-tree/content.jsx
index d1e8daa..7b3753d 100755
--- a/app/visualizer/trees/advanced/fenwick-tree/content.jsx
+++ b/app/visualizer/trees/advanced/fenwick-tree/content.jsx
@@ -47,23 +47,23 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `A Fenwick Tree (also called a Binary Indexed Tree, or BIT) solves the same core problem a Segment Tree does — prefix/range sums with fast point updates — but with a much smaller footprint: one plain array, no explicit tree nodes or pointers at all. The "tree" is implicit, encoded entirely in the binary representation of each index.`,
- `Every index i in the BIT array is responsible for a range of the original array whose length is exactly the value of i's lowest set bit (its "lowbit"). Index 6 in binary is 110, whose lowest set bit is 2, so BIT[6] covers a range of 2 elements. Index 8 is 1000, whose lowest set bit is 8, so BIT[8] covers all 8 elements up to it. This single bit trick is the entire structure — no recursion, no children pointers, just index arithmetic.`,
+ `A Fenwick Tree (also called a Binary Indexed Tree, or BIT) solves the same core problem a Segment Tree does, prefix/range sums with fast point updates, but with a much smaller footprint: one plain array, no explicit tree nodes or pointers at all. The "tree" is implicit, encoded entirely in the binary representation of each index.`,
+ `Every index i in the BIT array is responsible for a range of the original array whose length is exactly the value of i's lowest set bit (its "lowbit"). Index 6 in binary is 110, whose lowest set bit is 2, so BIT[6] covers a range of 2 elements. Index 8 is 1000, whose lowest set bit is 8, so BIT[8] covers all 8 elements up to it. This single bit trick is the entire structure: no recursion, no children pointers, just index arithmetic.`,
`Moving between indices uses that same lowbit value: adding it to an index walks up toward larger ranges (used when propagating a point update to every range that includes it), and subtracting it walks down toward smaller ranges (used when accumulating a prefix sum). Both walks take exactly O(log n) steps, because each step clears or sets one more bit in the index.`,
- `The tradeoff for this smaller footprint is flexibility: a Fenwick Tree's range query only works by combining prefix sums (range[l,r] = prefix(r) - prefix(l-1)), which requires the underlying operation to have an inverse. That works great for sum, but not for operations like minimum or maximum, which don't have an inverse — a Segment Tree is needed for those instead.`,
+ `The tradeoff for this smaller footprint is flexibility: a Fenwick Tree's range query only works by combining prefix sums (range[l,r] = prefix(r) - prefix(l-1)), which requires the underlying operation to have an inverse. That works great for sum, but not for operations like minimum or maximum, which don't have an inverse, so a Segment Tree is needed for those instead.`,
];
const algorithm = [
{ points: "Build: start with an all-zero BIT array, then apply a point update for every element of the input array" },
{
- points: "Point Update(index, delta) — add delta to the element at index:",
+ points: "Point Update(index, delta): add delta to the element at index:",
subpoints: [
"Convert to 1-indexed: i = index + 1",
"While i is within bounds: add delta to BIT[i], then move to the next responsible index with i += lowbit(i)",
],
},
{
- points: "Prefix Sum(index) — sum of everything from 0 to index:",
+ points: "Prefix Sum(index): sum of everything from 0 to index:",
subpoints: [
"Convert to 1-indexed: i = index + 1",
"While i > 0: add BIT[i] to the running total, then move down with i -= lowbit(i)",
@@ -74,8 +74,8 @@ const Content = () => {
const complexity = [
{ points: "Build: O(n log n) naively (n point updates), or O(n) with a direct construction trick." },
- { points: "Point Update: O(log n) — one walk upward through responsible ranges." },
- { points: "Prefix/Range Query: O(log n) — one walk downward accumulating partial sums." },
+ { points: "Point Update: O(log n), one walk upward through responsible ranges." },
+ { points: "Prefix/Range Query: O(log n), one walk downward accumulating partial sums." },
];
return (
diff --git a/app/visualizer/trees/advanced/fenwick-tree/quiz.jsx b/app/visualizer/trees/advanced/fenwick-tree/quiz.jsx
index 67bf740..3121000 100755
--- a/app/visualizer/trees/advanced/fenwick-tree/quiz.jsx
+++ b/app/visualizer/trees/advanced/fenwick-tree/quiz.jsx
@@ -14,13 +14,13 @@ const FenwickQuiz = () => {
"It's chosen randomly during construction"
],
correctAnswer: 1,
- explanation: "BIT[i] covers exactly lowbit(i) elements ending at position i — e.g. index 6 (binary 110) has lowbit 2, so it covers 2 elements."
+ explanation: "BIT[i] covers exactly lowbit(i) elements ending at position i, e.g. index 6 (binary 110) has lowbit 2, so it covers 2 elements."
},
{
question: "During a point update, how does the algorithm move from one BIT index to the next?",
options: ["i = i * 2", "i += lowbit(i)", "i -= lowbit(i)", "i = i / 2"],
correctAnswer: 1,
- explanation: "Adding the lowbit moves to the next larger range that also needs to include this update — this is how the update propagates upward through all responsible ranges."
+ explanation: "Adding the lowbit moves to the next larger range that also needs to include this update: this is how the update propagates upward through all responsible ranges."
},
{
question: "During a prefix sum query, how does the algorithm move from one BIT index to the next?",
@@ -48,7 +48,7 @@ const FenwickQuiz = () => {
"Because Fenwick trees can only store one number total"
],
correctAnswer: 1,
- explanation: "Subtraction only works to 'undo' addition. There's no way to 'subtract out' a minimum from a combined minimum, so that trick — and therefore a plain Fenwick Tree — doesn't work for min/max; a Segment Tree is used instead."
+ explanation: "Subtraction only works to 'undo' addition. There's no way to 'subtract out' a minimum from a combined minimum, so that trick, and therefore a plain Fenwick Tree, doesn't work for min/max; a Segment Tree is used instead."
}
];
diff --git a/app/visualizer/trees/advanced/prefix-tree/animation.jsx b/app/visualizer/trees/advanced/prefix-tree/animation.jsx
index f716c2f..9c251c6 100755
--- a/app/visualizer/trees/advanced/prefix-tree/animation.jsx
+++ b/app/visualizer/trees/advanced/prefix-tree/animation.jsx
@@ -139,9 +139,9 @@ const PrefixTreeVisualizer = () => {
if (createdPrefixes.length === 0 && alreadyExisted) {
setMessage(`"${word}" is already in the trie`);
} else if (createdPrefixes.length === 0) {
- setMessage(`"${word}" existed only as a prefix of another word — now marked complete too`);
+ setMessage(`"${word}" existed only as a prefix of another word, now marked complete too`);
} else {
- setMessage(`Inserted "${word}" — created ${createdPrefixes.length} new node${createdPrefixes.length === 1 ? "" : "s"}`);
+ setMessage(`Inserted "${word}": created ${createdPrefixes.length} new node${createdPrefixes.length === 1 ? "" : "s"}`);
}
setHighlightCreated(createdPrefixes);
setTimeout(() => setHighlightCreated([]), 1300);
@@ -164,16 +164,16 @@ const PrefixTreeVisualizer = () => {
const revealStep = () => {
if (i < steps.length) {
setHighlightPath(steps.slice(0, i + 1));
- setMessage(`Following '${word[i]}' — path so far: "${steps[i]}"`);
+ setMessage(`Following '${word[i]}', path so far: "${steps[i]}"`);
i++;
setTimeout(revealStep, STEP_DELAY);
} else {
if (brokeAt) {
- setMessage(`"${word}" isn't in the trie — no branch for prefix "${brokeAt}"`);
+ setMessage(`"${word}" isn't in the trie: no branch for prefix "${brokeAt}"`);
} else if (found) {
- setMessage(`Found "${word}" — it's a complete word in the trie`);
+ setMessage(`Found "${word}": it's a complete word in the trie`);
} else {
- setMessage(`"${word}" is only a prefix of other words — not itself stored as a complete word`);
+ setMessage(`"${word}" is only a prefix of other words, not itself stored as a complete word`);
}
setBusy(false);
}
@@ -373,7 +373,7 @@ const PrefixTreeVisualizer = () => {
) : (
- No trie yet — insert a word or generate random words
+ No trie yet, insert a word or generate random words
)}
- No tree yet — insert a value or generate a random tree
+ No tree yet, insert a value or generate a random tree
)}
- A right rotation at 10 fixes it — black-height unchanged
+ A right rotation at 10 fixes it, black-height unchanged
- No tree yet — build one over a random array
+ No tree yet, build one over a random array
)}
- No tree yet — insert a value or generate a random tree
+ No tree yet: insert a value or generate a random tree
)}
- LCA(1, 6) — paths to 1 and 6 split apart at node 3
+ LCA(1, 6): paths to 1 and 6 split apart at node 3
- No tree yet — insert a value or generate a random tree
+ No tree yet, insert a value or generate a random tree
)}
- Diameter = 4 edges — the path 1 → 3 → 8 → 10 → 14 turns at node 3
+ Diameter = 4 edges: the path 1 → 3 → 8 → 10 → 14 turns at node 3
- Check whether two trees are isomorphic — identical in structure once children can be freely swapped + Check whether two trees are isomorphic, identical in structure once children can be freely swapped
diff --git a/app/visualizer/trees/algorithms/tree-isomorphism/content.jsx b/app/visualizer/trees/algorithms/tree-isomorphism/content.jsx
index c9249d4..e31a15d 100755
--- a/app/visualizer/trees/algorithms/tree-isomorphism/content.jsx
+++ b/app/visualizer/trees/algorithms/tree-isomorphism/content.jsx
@@ -87,15 +87,15 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `Two binary trees are isomorphic if one can be transformed into the other by swapping the left and right children at any number of nodes — the values and the overall branching structure must match, but the left/right arrangement at each node is allowed to flip. It's a looser notion of "the same tree" than exact structural equality: two trees that look like mirror images of each other in places can still be isomorphic.`,
+ `Two binary trees are isomorphic if one can be transformed into the other by swapping the left and right children at any number of nodes: the values and the overall branching structure must match, but the left/right arrangement at each node is allowed to flip. It's a looser notion of "the same tree" than exact structural equality: two trees that look like mirror images of each other in places can still be isomorphic.`,
`The check is a recursive comparison of two nodes at a time, starting from both roots. If both are empty, they match. If exactly one is empty, or their values differ, the trees aren't isomorphic. Otherwise, the node's children are compared two ways: "straight" (left-with-left, right-with-right) and "flipped" (left-with-right, right-with-left). If either pairing matches all the way down, the current pair of nodes is isomorphic.`,
- `This differs from an exact structural-equality check only in that extra flipped attempt — without it, this is the same algorithm used to test whether two trees are identical. The flip is what makes isomorphism forgiving of left/right orientation while still being strict about values and shape.`,
+ `This differs from an exact structural-equality check only in that extra flipped attempt: without it, this is the same algorithm used to test whether two trees are identical. The flip is what makes isomorphism forgiving of left/right orientation while still being strict about values and shape.`,
`Isomorphism checks are common wherever "same shape regardless of arbitrary left/right layout choices" matters: comparing parse trees or expression trees generated by different tools, verifying that a serialized tree round-trips correctly regardless of child ordering, and canonicalizing tree-shaped data before hashing or deduplication.`,
];
const algorithm = [
{ points: "If both nodes are null, they match" },
- { points: "If exactly one is null, or their values differ, the trees are not isomorphic — stop" },
+ { points: "If exactly one is null, or their values differ, the trees are not isomorphic: stop" },
{
points: "Otherwise, compare children two ways:",
subpoints: [
@@ -107,8 +107,8 @@ const Content = () => {
];
const complexity = [
- { points: "Time Complexity: O(n) in the best case, up to O(4^n) in the worst case for the naive version — in practice close to O(n) for most trees since a mismatch usually short-circuits early." },
- { points: "Space Complexity: O(h) — recursion stack depth equals the smaller tree's height." },
+ { points: "Time Complexity: O(n) in the best case, up to O(4^n) in the worst case for the naive version, though in practice close to O(n) for most trees since a mismatch usually short-circuits early." },
+ { points: "Space Complexity: O(h), where recursion stack depth equals the smaller tree's height." },
];
return (
@@ -149,7 +149,7 @@ const Content = () => {
- Tree B is Tree A with children swapped at nodes 1 and 3 — they're isomorphic
+ Tree B is Tree A with children swapped at nodes 1 and 3, so they're isomorphic
- Predicting "play outside?" from temperature — two splits fully separate the classes
+ Predicting "play outside?" from temperature: two splits fully separate the classes
- {sorted ? "Heap is empty — every element has been extracted in sorted order" : "The heap view fills in once sorting starts"}
+ {sorted ? "Heap is empty, every element has been extracted in sorted order" : "The heap view fills in once sorting starts"}
)}
- Root — always the maximum
+ Root, always the maximum
diff --git a/app/visualizer/trees/applications/heap-sort/quiz.jsx b/app/visualizer/trees/applications/heap-sort/quiz.jsx
index 0442263..eeadb3e 100755
--- a/app/visualizer/trees/applications/heap-sort/quiz.jsx
+++ b/app/visualizer/trees/applications/heap-sort/quiz.jsx
@@ -22,10 +22,10 @@ const HeapSortQuiz = () => {
"At indices i-1 and i+1",
"At indices 2i+1 and 2i+2",
"At indices i/2 and i*2",
- "Children aren't derivable from the index — pointers are required"
+ "Children aren't derivable from the index, so pointers are required"
],
correctAnswer: 1,
- explanation: "This index arithmetic is what lets a heap live entirely inside a flat array with no pointers — the tree shape is implicit in the indices."
+ explanation: "This index arithmetic is what lets a heap live entirely inside a flat array with no pointers: the tree shape is implicit in the indices."
},
{
question: "What are the two main phases of Heap Sort?",
@@ -43,7 +43,7 @@ const HeapSortQuiz = () => {
options: [
"The heap is rebuilt completely from scratch",
"The new root is sifted down to restore the max-heap property, using the now-smaller heap size",
- "Nothing — the array is already sorted at that point",
+ "Nothing, since the array is already sorted at that point",
"The swapped element is sifted down"
],
correctAnswer: 1,
@@ -55,7 +55,7 @@ const HeapSortQuiz = () => {
"Heap Sort doesn't actually sort correctly in the worst case",
"Sifting down always costs O(log n) regardless of the input's initial arrangement, so there's no pathological input that degrades it to O(n²)",
"Heap Sort uses extra memory to avoid worst cases",
- "It isn't more predictable — both have the same worst case"
+ "It isn't more predictable, since both have the same worst case"
],
correctAnswer: 1,
explanation: "Quick Sort can degrade to O(n²) on certain inputs depending on pivot choice, but Heap Sort's heap operations stay O(log n) no matter how the input is arranged, keeping it at O(n log n) always."
diff --git a/app/visualizer/trees/applications/huffman-coding/animation.jsx b/app/visualizer/trees/applications/huffman-coding/animation.jsx
index 1d8ecf1..3e5d41d 100755
--- a/app/visualizer/trees/applications/huffman-coding/animation.jsx
+++ b/app/visualizer/trees/applications/huffman-coding/animation.jsx
@@ -136,7 +136,7 @@ const HuffmanVisualizer = () => {
setTimeout(() => {
setRoot(finalRoot);
setCodes(computeCodes(finalRoot));
- setMessage("Only one distinct character — it gets the trivial code \"0\"");
+ setMessage("Only one distinct character, so it gets the trivial code \"0\"");
setBusy(false);
}, STEP_DELAY);
return;
@@ -159,7 +159,7 @@ const HuffmanVisualizer = () => {
setTimeout(() => {
setRoot(finalRoot);
setCodes(computeCodes(finalRoot));
- setMessage("Huffman tree complete — codes assigned by root-to-leaf path (0 = left, 1 = right)");
+ setMessage("Huffman tree complete: codes assigned by root-to-leaf path (0 = left, 1 = right)");
setBusy(false);
}, STEP_DELAY);
}
diff --git a/app/visualizer/trees/applications/huffman-coding/content.jsx b/app/visualizer/trees/applications/huffman-coding/content.jsx
index 508f165..8df1663 100755
--- a/app/visualizer/trees/applications/huffman-coding/content.jsx
+++ b/app/visualizer/trees/applications/huffman-coding/content.jsx
@@ -77,10 +77,10 @@ const Content = () => {
const { theme } = useTheme();
const paragraphs = [
- `Huffman coding compresses data by giving frequent symbols short binary codes and rare symbols longer ones — the opposite of fixed-width encodings like ASCII, where every character costs the same 8 bits regardless of how often it appears. The codes it produces are prefix-free: no character's code is a prefix of another's, which means a stream of bits can be decoded unambiguously without any separators between codes.`,
+ `Huffman coding compresses data by giving frequent symbols short binary codes and rare symbols longer ones, the opposite of fixed-width encodings like ASCII, where every character costs the same 8 bits regardless of how often it appears. The codes it produces are prefix-free: no character's code is a prefix of another's, which means a stream of bits can be decoded unambiguously without any separators between codes.`,
`The codes come directly out of a binary tree built specifically for this purpose. Every leaf holds one symbol, and a symbol's code is the sequence of left/right turns (0s and 1s) on the path from the root down to its leaf. Because frequent symbols end up near the root and rare ones get pushed deeper, frequent symbols naturally get shorter codes.`,
- `That tree is built greedily, bottom-up: start with every symbol as its own single-node tree, weighted by its frequency. Repeatedly take the two trees with the smallest total weight and merge them under a new parent node (weight = the sum of the two), putting the result back into the pool. After enough merges only one tree remains — the Huffman tree — and it's provably optimal: no other prefix-free code achieves a shorter total encoded length for that exact frequency distribution.`,
- `Huffman coding is a building block inside many real compression formats — it's the final entropy-coding stage in DEFLATE (used by ZIP and gzip), JPEG, and MP3, typically applied after some other transform has already reduced redundancy in the data.`,
+ `That tree is built greedily, bottom-up: start with every symbol as its own single-node tree, weighted by its frequency. Repeatedly take the two trees with the smallest total weight and merge them under a new parent node (weight = the sum of the two), putting the result back into the pool. After enough merges only one tree remains, the Huffman tree, and it's provably optimal: no other prefix-free code achieves a shorter total encoded length for that exact frequency distribution.`,
+ `Huffman coding is a building block inside many real compression formats: it's the final entropy-coding stage in DEFLATE (used by ZIP and gzip), JPEG, and MP3, typically applied after some other transform has already reduced redundancy in the data.`,
];
const algorithm = [
@@ -94,11 +94,11 @@ const Content = () => {
"Insert the merged tree back into the queue",
],
},
- { points: "Assign each symbol's code by reading the path from the root to its leaf — 0 for left, 1 for right" },
+ { points: "Assign each symbol's code by reading the path from the root to its leaf, using 0 for left and 1 for right" },
];
const complexity = [
- { points: "Time Complexity: O(n log n), where n is the number of distinct symbols — each of the n-1 merges costs O(log n) with a priority queue." },
+ { points: "Time Complexity: O(n log n), where n is the number of distinct symbols, since each of the n-1 merges costs O(log n) with a priority queue." },
{ points: "Space Complexity: O(n) for the tree and the code table." },
];
diff --git a/app/visualizer/trees/applications/syntax-trees/animation.jsx b/app/visualizer/trees/applications/syntax-trees/animation.jsx
index ff1b5b0..e1d3fb5 100755
--- a/app/visualizer/trees/applications/syntax-trees/animation.jsx
+++ b/app/visualizer/trees/applications/syntax-trees/animation.jsx
@@ -32,7 +32,7 @@ const tokenize = (input) => {
};
// Standard recursive-descent parser respecting + - (lowest precedence),
-// * / (higher precedence), and parentheses — grammar:
+// * / (higher precedence), and parentheses. Grammar:
// expression := term (('+'|'-') term)*
// term := factor (('*'|'/') factor)*
// factor := NUMBER | '(' expression ')'
@@ -194,7 +194,7 @@ const SyntaxTreeVisualizer = () => {
setTraversals({ prefix: toPrefix(tree), infix: toInfix(tree), postfix: toPostfix(tree) });
setError("");
clearResult();
- setMessage("Parsed into a syntax tree — operators are internal nodes, numbers are leaves");
+ setMessage("Parsed into a syntax tree: operators are internal nodes, numbers are leaves");
} catch (e) {
setError(e.message);
setRoot(null);
@@ -222,7 +222,7 @@ const SyntaxTreeVisualizer = () => {
} else {
setTimeout(() => {
setActiveIds([]);
- setMessage(`Evaluation complete — result is ${steps[steps.length - 1].result}`);
+ setMessage(`Evaluation complete: result is ${steps[steps.length - 1].result}`);
setBusy(false);
}, STEP_DELAY);
}
diff --git a/app/visualizer/trees/applications/syntax-trees/content.jsx b/app/visualizer/trees/applications/syntax-trees/content.jsx
index f09249c..384f38f 100755
--- a/app/visualizer/trees/applications/syntax-trees/content.jsx
+++ b/app/visualizer/trees/applications/syntax-trees/content.jsx
@@ -64,9 +64,9 @@ const Content = () => {
const paragraphs = [
`A syntax tree (also called an expression tree, or more generally an Abstract Syntax Tree/AST) captures the grammatical structure of an expression or piece of code, rather than its raw text. For arithmetic expressions specifically, every operator becomes an internal node with its operands as children, and every literal value becomes a leaf. The shape of the tree, not the order characters appear on the page, is what encodes precedence and grouping.`,
- `Building one from an infix expression like "3 + 4 * (2 - 1)" requires a parser that respects operator precedence and parentheses — multiplication and division bind tighter than addition and subtraction, and anything inside parentheses is parsed as its own self-contained sub-expression first. A common approach is recursive-descent parsing: one function handles addition/subtraction terms, which calls another handling multiplication/division factors, which calls another handling numbers and parenthesized groups — the recursive call structure mirrors the grammar's precedence levels directly.`,
- `Once built, the tree makes evaluation and notation conversion almost mechanical, because each is just a different tree traversal. Evaluating the expression is a post-order traversal: recursively compute both children's values first, then apply the operator to combine them — by the time an operator node is processed, both its operands are already known. Reading the tree with a pre-order traversal produces prefix notation, and post-order traversal produces postfix notation; both eliminate the need for parentheses or precedence rules entirely, since the tree structure alone determines evaluation order.`,
- `Syntax trees are the intermediate representation nearly every compiler and interpreter builds after parsing source code, before generating machine code or bytecode from it. The same idea powers calculator apps, spreadsheet formula engines, and query planners in databases — anywhere text needs to become something with an unambiguous, machine-processable structure.`,
+ `Building one from an infix expression like "3 + 4 * (2 - 1)" requires a parser that respects operator precedence and parentheses: multiplication and division bind tighter than addition and subtraction, and anything inside parentheses is parsed as its own self-contained sub-expression first. A common approach is recursive-descent parsing: one function handles addition/subtraction terms, which calls another handling multiplication/division factors, which calls another handling numbers and parenthesized groups, and this recursive call structure mirrors the grammar's precedence levels directly.`,
+ `Once built, the tree makes evaluation and notation conversion almost mechanical, because each is just a different tree traversal. Evaluating the expression is a post-order traversal: recursively compute both children's values first, then apply the operator to combine them, since by the time an operator node is processed, both its operands are already known. Reading the tree with a pre-order traversal produces prefix notation, and post-order traversal produces postfix notation; both eliminate the need for parentheses or precedence rules entirely, since the tree structure alone determines evaluation order.`,
+ `Syntax trees are the intermediate representation nearly every compiler and interpreter builds after parsing source code, before generating machine code or bytecode from it. The same idea powers calculator apps, spreadsheet formula engines, and query planners in databases: anywhere text needs to become something with an unambiguous, machine-processable structure.`,
];
const algorithm = [
@@ -84,8 +84,8 @@ const Content = () => {
];
const complexity = [
- { points: "Parsing Time: O(n) — each token is consumed exactly once by the recursive-descent parser." },
- { points: "Evaluation Time: O(n) — each node in the tree is visited exactly once during the post-order traversal." },
+ { points: "Parsing Time: O(n), since each token is consumed exactly once by the recursive-descent parser." },
+ { points: "Evaluation Time: O(n), since each node in the tree is visited exactly once during the post-order traversal." },
{ points: "Space Complexity: O(n) for the tree, plus O(h) recursion stack depth for parsing and evaluating." },
];
@@ -127,7 +127,7 @@ const Content = () => {
- The syntax tree for 3 + 4 * (2 - 1) — its shape alone encodes precedence, no parentheses needed
+ The syntax tree for 3 + 4 * (2 - 1): its shape alone encodes precedence, no parentheses needed
Height
- {root ? stats.height : "—"}
+ {root ? stats.height : "N/A"}
Total Nodes
@@ -290,7 +290,7 @@ const TreePropertiesVisualizer = () => {
) : (
- No tree yet — insert a value or generate a random tree
+ No tree yet, insert a value or generate a random tree
)}
Since most tree operations (search, insert, delete) walk from the root - down to a leaf, their time complexity is O(height) — O(log n) for a + down to a leaf, their time complexity is O(height): O(log n) for a balanced tree, degrading to O(n) for a skewed one.
- No tree yet — insert a value or generate a random tree
+ No tree yet, insert a value or generate a random tree
)}
- No tree yet — insert a value or generate a random tree
+ No tree yet, insert a value or generate a random tree
)}
- No tree yet — insert a value or generate a random tree
+ No tree yet, insert a value or generate a random tree
)}