
Supervised fine-tuning can teach a model to imitate. It cannot teach a model to
be better than what it imitates.

That is the whole reason RLHF exists. If you have a dataset of good answers, you
can train the model to reproduce them token by token — that is next-token
prediction with a nicer dataset. But a lot of what makes an answer good is not
expressible as a target string. It is comparative: this answer is more helpful
than that one, this one refuses when it should not, this one is technically
right but insufferable to read. Nobody can write down the correct answer, but
almost anyone can pick the better of two.

RLHF is the machinery for turning that comparison into a gradient. PPO is the
part that keeps the gradient from wrecking the model on the way.

## The three stages

RLHF is not one algorithm. It is three training runs stacked on top of each
other, and confusing them is the usual source of confusion about the whole
thing.

**Stage 1 — supervised fine-tuning.** Take a pretrained base model and fine-tune
it on demonstrations: prompts paired with responses a human wrote or approved.
This is ordinary cross-entropy training. Its job is not to make the model good,
only to make it answer in roughly the right format so the later stages have
something workable to sample from. Call the result the SFT model.

**Stage 2 — the reward model.** Sample several responses to the same prompt from
the SFT model, have a human rank them, and train a separate model to predict
those rankings as a scalar score.

**Stage 3 — reinforcement learning.** Let the SFT model generate, score its
generations with the reward model, and update the model to get higher scores.
This is where PPO comes in.

<RlhfStages />

The interesting design decisions are all in stages 2 and 3.

## Stage 2: learning a reward from comparisons

Humans are bad at absolute scores. Ask ten annotators to rate an answer from 1
to 10 and you get ten different scales. Ask them which of two answers is better
and they agree far more often. So preference data is collected as pairs: for a
prompt `x`, a chosen response `y_w` and a rejected one `y_l`.

The reward model `r` is usually the SFT model with the language-modelling head
replaced by a single scalar output. It is trained with the Bradley-Terry
objective, which says the probability a human prefers `y_w` over `y_l` is the
sigmoid of the score difference:

```python
# reward_chosen, reward_rejected: (batch,) scalars from the reward model
loss = -torch.nn.functional.logsigmoid(reward_chosen - reward_rejected).mean()
```

Three consequences fall out of this loss, and all three matter later.

The reward is only meaningful **relative to other completions of the same
prompt**. Nothing anchors the absolute value — add a constant to every score and
the loss is unchanged. So the numbers a reward model emits are not comparable
across prompts, and "reward went up" only means something within a prompt.

It is a **learned, imperfect proxy** for human preference, trained on a finite
sample. Anywhere the policy wanders outside the distribution the reward model
was trained on, its output is a guess.

And it is **frozen** during stage 3. The policy will be optimised against a
fixed, imperfect function for thousands of steps. Hold that thought.

## Why reinforcement learning at all?

Here is the honest version of the question: you have a scalar score for each
generated sequence. Why not just fine-tune on the high-scoring ones and be done?

You can, and that is roughly what rejection sampling or best-of-n fine-tuning
does. It works, and it is much simpler. RL earns its complexity for one reason:
the reward arrives **once, at the end of a whole sequence**, and it is not
differentiable with respect to the model's parameters.

Think about what the model actually does. At each step it picks a token from a
distribution over the vocabulary. Sampling is not differentiable — you cannot
backpropagate through "and then it chose token 4,712". The reward model scores
the finished text, so there is no per-token target to compute a cross-entropy
against.

Reinforcement learning is the toolkit for exactly this shape of problem:
discrete actions, non-differentiable feedback, credit that has to be assigned
backwards across a sequence of choices. In RL terms the mapping is:

- **state** — the prompt plus everything generated so far
- **action** — the next token
- **policy** — the language model itself
- **reward** — the reward model's score, delivered at the final token

## Policy gradients, and how they go wrong

The basic policy-gradient idea is intuitive. Increase the log-probability of
actions that led to high reward, decrease it for actions that led to low reward,
weighted by how much better than expected the outcome was:

```python
loss = -(log_prob * advantage).mean()
```

The `advantage` is the reward minus a baseline — how much better this action was
than what you would normally expect from that state. Subtracting a baseline does
not change what the gradient points at on average, but it enormously reduces its
variance, which is why every practical implementation has a value network
predicting that baseline.

The problem is step size. This gradient is only valid for the policy that
generated the data. Take one large step and the new policy is different enough
that the collected trajectories no longer describe it, and the next update is
computed from stale information. In a language model this failure is dramatic:
the model finds some degenerate high-reward region, collapses onto it, and starts
emitting the same sycophantic paragraph regardless of the prompt. Once it stops
producing varied samples it cannot recover, because it never explores anything
the reward model would score differently.

So you need small steps. But "use a small learning rate" is a blunt instrument —
the same learning rate is far too large in some regions and wastefully small in
others.

## PPO: clip the update, not the learning rate

PPO's insight is to constrain the update in terms of **how much the policy's
output distribution changed**, rather than how far the parameters moved.

Define the probability ratio between the new policy and the one that generated
the data:

```
ratio = pi_new(a | s) / pi_old(a | s)
```

A ratio of 1 means the policy has not changed for this token. Above 1 means the
new policy is more likely to produce that token. The clipped surrogate objective
is:

```python
ratio = torch.exp(new_log_probs - old_log_probs)   # exp of a difference of logs
unclipped = ratio * advantages
clipped = torch.clamp(ratio, 1 - eps, 1 + eps) * advantages
policy_loss = -torch.min(unclipped, clipped).mean()
```

with `eps` typically 0.2. Read the `min` carefully, because it is the entire
trick and it is not symmetric.

<PpoClip />

When the advantage is **positive** — this token was better than expected — the
objective wants to increase the ratio. Clipping caps it at `1 + eps`. Past that
point the gradient is zero: the model gets no further reward for pushing this
token's probability higher within this update. It has already moved enough.

When the advantage is **negative**, the objective wants to decrease the ratio,
and clipping floors it at `1 - eps`. Same logic in reverse.

Because it takes the minimum of the clipped and unclipped terms, PPO is
pessimistic. It never lets an update be *more* attractive because of clipping,
only less. And the clipping is one-directional in a useful way: if the ratio has
already blown far past the range in the wrong direction, the unclipped term is
selected and the gradient still pulls it back. Clipping stops you running away;
it does not stop you coming home.

The practical payoff is that you can take several gradient steps on the same
batch of generated data before it goes stale — normally you would be limited to
one — which matters enormously when generating that data means running inference
over a large model.

## The KL leash

Clipping bounds how far the policy moves **per update**. It says nothing about
where the policy ends up after ten thousand updates. Left alone, the model will
happily drift somewhere the reward model scores highly and humans find useless,
because the reward model is a proxy and every proxy has exploits.

This is not hypothetical. Optimise hard enough against a reward model and you
get outputs stuffed with the surface features it correlated with quality:
excessive hedging, bullet points everywhere, restating the question, and above
all **length**, because longer answers score better in most preference datasets
and the reward model learned that.

The fix is a KL penalty against the frozen SFT model, applied per token:

```python
# reference = the frozen SFT model; both are log-probs of the sampled token
kl = new_log_probs - ref_log_probs
rewards = reward_model_score - kl_coef * kl
```

The policy is now optimising the reward model's score *minus* a charge for every
token where it disagrees with the model it started from. The coefficient sets the
exchange rate: how much reward is a unit of drift worth. Tune it too high and
nothing changes; too low and the model wanders off and games the reward.

Two details worth knowing. The reward-model score is a single number at the end
of the sequence, whereas the KL term is charged at every token — the total
reward signal is dense in KL and sparse in actual preference. And in practice the
KL is often estimated with a lower-variance unbiased estimator rather than the
raw log-ratio difference, because the naive version is noisy enough to hurt.

## The loop, end to end

```python
for batch in prompts:
    # 1. generate, and record the log-probs of the policy that generated them
    responses, old_log_probs = policy.generate(batch)

    # 2. score
    scores = reward_model(batch, responses)             # one scalar per response
    ref_log_probs = reference_model.log_probs(batch, responses)
    kl = old_log_probs - ref_log_probs
    rewards = scores - kl_coef * kl                     # per token

    # 3. credit assignment
    values = value_head(batch, responses)
    advantages = compute_gae(rewards, values, gamma, lam)

    # 4. several epochs over the same batch, which is what clipping buys you
    for _ in range(ppo_epochs):
        new_log_probs = policy.log_probs(batch, responses)
        ratio = torch.exp(new_log_probs - old_log_probs)

        policy_loss = -torch.min(
            ratio * advantages,
            torch.clamp(ratio, 1 - eps, 1 + eps) * advantages,
        ).mean()

        value_loss = ((value_head(batch, responses) - returns) ** 2).mean()
        loss = policy_loss + vf_coef * value_loss

        loss.backward()
        optimizer.step()
```

That is four models in memory at once: the policy being trained, the frozen
reference, the reward model, and the value head. It is why RLHF is remembered as
expensive and fiddly as much as for what it achieves.

## What actually goes wrong

**Reward hacking** is the headline failure, and it is not a bug you can fix by
being careful. The reward model is a finite-sample approximation of human
preference; optimising a proxy hard enough will always find the gap between the
proxy and the thing it proxies for. Watching the reward curve go up tells you
nothing on its own — it goes up in exactly the same way whether the model is
improving or learning to exploit.

**Length bias** deserves its own name because it is so consistent. Annotators
mildly prefer thorough answers, the reward model learns "longer is better" as an
easy correlate, and the policy learns to pad. Some implementations subtract an
explicit length penalty; most just watch the mean token count.

**KL collapse in either direction.** Too much penalty and you have spent a great
deal of compute to reproduce the SFT model. Too little and the policy leaves the
distribution the reward model understands, where its scores are guesses, and it
optimises against noise.

**Value function instability.** The value head starts out knowing nothing, so
early advantages are mostly noise, which produces bad updates while the policy is
at its most malleable. Warming up the value head before letting the policy move
is a common remedy.

## Where this went next

The obvious complaint about the pipeline above is that it is enormous for what it
does. Train a reward model, then run an RL loop with four models resident,
carefully balanced against a KL term, to extract signal from data that is just
pairs of "this one is better".

Direct Preference Optimization is the well-known response. The derivation shows
that the optimal policy under a KL-constrained reward objective has a closed
form, which can be rearranged to express the *reward* in terms of the policy and
the reference model. Substitute that back into the Bradley-Terry loss and the
reward model cancels out. What remains is a supervised loss on preference pairs
directly:

```python
chosen_logratio = policy_chosen_logps - reference_chosen_logps
rejected_logratio = policy_rejected_logps - reference_rejected_logps
loss = -torch.nn.functional.logsigmoid(beta * (chosen_logratio - rejected_logratio)).mean()
```

No reward model, no sampling loop, no value head. Two models instead of four, and
an ordinary training loop.

It is not strictly better. DPO trains only on the fixed preference dataset, so it
never sees the policy's own current outputs — and the ability to generate, score,
and learn from what the model produces *now* is precisely what online RL gives
you. That is why the online variants exist, and why PPO has not disappeared.

Which is the useful way to hold all of this: PPO is not the point of RLHF. The
point is converting preferences into a training signal. PPO is one answer to the
question of how to follow that signal without falling over, and understanding
*why* it clips tells you more than memorising that it does.

## References

- [Training language models to follow instructions with human feedback](https://arxiv.org/abs/2203.02155) — the InstructGPT paper, the canonical description of the three-stage pipeline
- [Proximal Policy Optimization Algorithms](https://arxiv.org/abs/1707.06347) — PPO itself, predating any of this by five years
- [Direct Preference Optimization](https://arxiv.org/abs/2305.18290) — the derivation that removes the reward model
- [Deep reinforcement learning from human preferences](https://arxiv.org/abs/1706.03741) — the earlier work that established learning a reward model from comparisons


A language model cannot be taught "this answer is better than that one" by supervised learning. RLHF turns that comparison into a gradient, and PPO is what keeps the gradient from destroying the model.

How RLHF Works, and Why It Uses PPO


Every "math for ML" reading list is the same three courses: linear algebra,
calculus, probability. Each is a semester. Together they are a year you do not
have, and most of what is in them you will never use.

The useful version of the question is narrower. Which ideas keep reappearing in
the code, and what does knowing them let you do that you could not do otherwise?
That list is short. It is maybe six ideas, and none of them are hard. What makes
them worth learning properly is that they turn library calls from incantations
into things with reasons.

If you came through an engineering degree you have already met all of this. I
did civil engineering, and every piece below was in those courses — matrices for
structural analysis, derivatives for everything, probability for load factors.
What changed was not the mathematics. It was what it is pointed at.

## A matrix is a function, not a grid of numbers

This is the single reframing that makes linear algebra click for ML.

At school a matrix is a table you learn rules for multiplying. In ML a matrix is
a **linear map**: a function that takes a vector in and gives a vector out.
Multiplying two matrices is not a grid operation, it is **composing two
functions**. `AB` means do `B`, then do `A`.

Once you see it that way, a neural network layer stops being mysterious:

```python
h = W @ x + b
```

`W` maps the input vector into a different space, possibly of a different
dimension, and `b` shifts it. That is the whole layer. A network is a stack of
these maps.

Which immediately raises a question worth sitting with. If every layer is a
linear map, and composing linear maps gives another linear map, then a hundred
stacked layers collapse into a single equivalent matrix. All that depth buys
nothing.

That is exactly why the activation function is not optional. `ReLU`, `sigmoid`,
`tanh` — their job is to break linearity so composition actually adds
expressive power. The activation is not a detail bolted on for convenience; it
is the reason depth means anything. You cannot get to that from the grid-of-
numbers view, and you get to it immediately from the function view.

### The dot product is the workhorse

Two vectors, multiply elementwise, add it up. Trivially simple, and it is doing
most of the work in modern ML, because the dot product measures **alignment**.

```python
similarity = a @ b        # large when a and b point the same way
```

<DotProduct />

Every embedding-based system runs on this. "Find similar documents" is a dot
product against stored vectors. Attention scores are dot products between
queries and keys — how much should this token care about that one — and the
answer is how aligned their vectors are.

Here is a detail that shows what the math buys you. Attention is not `q @ k`, it
is:

```python
scores = (q @ k.T) / math.sqrt(d_k)
```

Why divide by the square root of the dimension? Because if the components of `q`
and `k` are roughly independent with unit variance, their dot product over `d_k`
terms has variance proportional to `d_k`. So as the dimension grows, the scores
spread out, and softmax over spread-out values saturates — it goes nearly
one-hot, gradients vanish, and the model stops learning what to attend to.
Dividing by the square root of `d_k` holds the variance steady.

That is a line of code that looks arbitrary and is not. One paragraph of
probability explains it.

### Shapes are your debugger

The least glamorous and most useful habit: track the shape of every tensor.

```python
x        # (batch, seq_len, d_model)
W_q      # (d_model, d_head)
q = x @ W_q   # (batch, seq_len, d_head)
```

A large share of real bugs are shape errors that do not crash — a broadcast that
silently did the wrong thing, a transpose that should not have been there, a
batch dimension that got summed over. If you can predict the output shape of
every line before you run it, you catch these by reading. If you cannot, you are
debugging by print statement.

## Derivatives: which way is downhill

Training is one idea repeated: measure how wrong you are, work out which
direction reduces the wrongness, take a small step that way.

The **derivative** answers "if I nudge this input slightly, how much does the
output change, and in which direction?" The **gradient** is that answer for every
parameter at once, collected into a vector. It points in the direction of
steepest increase, so you step the opposite way:

```python
for p in parameters:
    p -= learning_rate * p.grad
```

That is gradient descent. It is the entire optimisation story before the
refinements.

### Backpropagation is the chain rule and nothing else

The chain rule says: to differentiate nested functions, multiply the derivatives
of each layer of nesting.

Take a network so small you can do it by hand:

```python
z = w * x + b          # linear
a = sigmoid(z)         # activation
L = (a - y) ** 2       # loss
```

How does the loss change with `w`? Walk backwards, multiplying:

```
dL/dw = dL/da * da/dz * dz/dw
      = 2 * (a - y)   *  a * (1 - a)  *  x
```

Three local derivatives, each obvious on its own, multiplied together. That is
backprop. A framework does it for a million parameters instead of one, and
caches the intermediate values so nothing is recomputed, but there is no
additional idea.

And now the payoff, because this explains a piece of history. Look at the middle
term, the derivative of sigmoid: `a * (1 - a)`. Its largest possible value is
`0.25`, at `a = 0.5`. In a deep network you multiply one of these per layer. Ten
sigmoid layers and the gradient reaching the first layer is scaled by at most
`0.25 ** 10`, which is about one in a million. The early layers receive
essentially nothing and never learn.

<VanishingGradient />

That is the vanishing gradient problem, and it is why `ReLU` — whose derivative
is exactly `1` for positive inputs, so it multiplies through without shrinking —
was such a large practical unlock. Two lines of chain rule tell you why an
architectural choice mattered.

## Probability: your model outputs a distribution

The step that reorganises everything: a classifier does not output an answer, it
outputs a **probability distribution over answers**. A language model does not
output the next token, it outputs a distribution over the whole vocabulary.

Once you accept that, the loss function stops being a design choice and becomes
a derivation.

### Maximum likelihood, and where the losses come from

You have data and a model with parameters. Ask: which parameters make the
observed data most probable?

Assuming the examples are independent, the probability of the whole dataset is
the product of the individual probabilities:

```
likelihood = p(y_1 | x_1) * p(y_2 | x_2) * ... * p(y_n | x_n)
```

Products of many small numbers underflow, so take the log, which turns the
product into a sum and is monotonic so it does not move the maximum. Flip the
sign to make it a minimisation, and you have the **negative log-likelihood**:

```
NLL = -sum( log p(y_i | x_i) )
```

Now specialise it, and watch the familiar losses fall out.

**Classification.** The model gives a probability per class. The negative log
probability of the correct class, summed over the data, is exactly
cross-entropy loss. It was not chosen because it works well. It is what maximum
likelihood *is* for a categorical output.

**Regression.** Assume the target is the prediction plus Gaussian noise with
fixed variance. Write down the Gaussian density, take its log, and everything
except the squared term is a constant with respect to the parameters. What is
left is the squared error. Mean squared error is maximum likelihood under an
assumption of Gaussian noise.

This is worth more than trivia. It tells you when MSE is the wrong tool: when
your noise is not Gaussian. Heavy-tailed targets with occasional large outliers
violate the assumption, the squared term lets one outlier dominate the gradient,
and the fix — Huber loss, or predicting a quantile — comes from questioning the
assumption rather than from a list of alternative losses.

## Information theory: three quantities

Three definitions, tightly related, and they show up constantly.

**Entropy** is the average surprise of a distribution — how uncertain it is. A
fair coin has high entropy; a coin that always lands heads has none.

**Cross-entropy** is the average surprise you get when you believe distribution
`Q` but reality follows `P`. It is minimised when `Q` equals `P`, which is why
it works as a loss: you are penalised for the gap between your predicted
distribution and the truth.

**KL divergence** is the difference between the two:

```
KL(P || Q) = cross_entropy(P, Q) - entropy(P)
```

Read it as: how much extra surprise you pay for using `Q` instead of the true
`P`. It is zero when they match and grows as they diverge.

Two consequences. Since `entropy(P)` does not depend on your model, minimising
cross-entropy and minimising KL divergence are the same optimisation — the
standard classification loss is already a KL minimisation, just written without
the constant.

And KL is not symmetric. `KL(P || Q)` is not `KL(Q || P)`, and the asymmetry has
teeth. Minimising one direction produces a `Q` that spreads out to cover
everywhere `P` has mass; the other produces a `Q` that concentrates on one mode
and ignores the rest. Which you pick changes what your model does.

If you read [the RLHF post](/article/rlhf-and-ppo), this is the same KL that
appears there as a penalty term. The policy is charged for diverging from the
model it started from, and the coefficient on that charge is the exchange rate
between reward and drift. Same quantity, used as a leash instead of a loss.

## Optimisation: why the simple thing works

Gradient descent has an obvious failure mode. The gradient is local — it only
knows the slope right where you stand — so it walks downhill into whatever
valley it happens to be in, not the deepest one.

For a **convex** loss, shaped like a bowl, there is only one valley and this is
not a problem. Linear and logistic regression are convex, which is why they
train reliably.

Neural networks are wildly non-convex. Enormously many local minima and saddle
points. By the textbook, gradient descent should be hopeless.

It works anyway, and the reasons are worth knowing because they justify things
that otherwise look like folklore:

**In very high dimensions, bad local minima are rare.** For a point to be a
local minimum, the loss must curve upward in *every* one of millions of
directions. That is an extraordinary coincidence. Far more common are saddle
points, which curve up in some directions and down in others — and a saddle has
a downhill direction, so you can leave.

**The noise helps.** Stochastic gradient descent computes the gradient on a
small batch, so each step is a noisy estimate of the true gradient. That noise
is not just a computational compromise; it lets the optimiser rattle out of
narrow valleys. It is a feature.

**Most minima are about as good.** Empirically, the many minima a large network
can land in reach similar loss. You are not searching for one special solution
among millions of bad ones.

This is also where the learning rate gets its outsized reputation. Too large and
you step past the minimum and oscillate or diverge; too small and training takes
forever and settles into the first shallow dip. Nothing else you tune matters as
much.

## What you can skip, for now

Being honest about the other direction matters as much.

You do not need to compute eigenvalues by hand, invert matrices by hand, or
prove convergence theorems. You do not need measure theory. You do not need most
of a real analysis course. You do not need to derive backprop for an arbitrary
architecture — you need to know it is the chain rule so that when a gradient is
`NaN` you know where to look.

Determinants, eigendecomposition and SVD are genuinely useful, but useful *later*
and in specific places: PCA, some initialisation schemes, analysing what a
trained model has learned. Learn them when you hit one, not before.

The failure mode is not skipping too much. It is spending six months on a
linear algebra course before writing any code, and arriving with a lot of
theorems and no idea which ones matter.

## A workable order

Learn it interleaved with building things, not before.

1. **Vectors, matrices, shapes.** Enough to read a model definition and predict
   every tensor shape. Do this first; it pays off immediately.
2. **Derivatives and the chain rule.** Enough to hand-derive the two-layer
   example above. Then read a from-scratch backprop implementation and follow
   every line.
3. **Probability, up to maximum likelihood.** Enough to derive cross-entropy
   yourself rather than accept it.
4. **Entropy, cross-entropy, KL.** Small, and they unlock a lot of papers.
5. **Everything else, on demand.** When a paper uses something you do not know,
   learn that thing. This is a better filter than any curriculum, because the
   things you keep meeting are by definition the things that matter.

If you want one source rather than three courses,
[Mathematics for Machine Learning](https://mml-book.github.io/) (Deisenroth,
Faisal and Ong) is free online and written for exactly this — the mathematics
that ML uses, without the rest of the degree. For intuition rather than
mechanics, 3Blue1Brown's
[Essence of linear algebra](https://www.3blue1brown.com/topics/linear-algebra)
and [Essence of calculus](https://www.3blue1brown.com/topics/calculus) are the
best few hours you can spend on either.

## The point

None of this is about being able to prove things. It is about the difference
between reading `scores / math.sqrt(d_k)` as a line someone told you to write
and reading it as variance control. Between "cross-entropy is the loss for
classification" and "cross-entropy is what maximum likelihood reduces to here,
so it stops being right when this assumption stops holding."

That difference is what lets you debug a model instead of restarting the
training run with a different random seed and hoping.


Not a syllabus. The handful of ideas that keep showing up in the code, why each one is there, and which parts of the textbook you can safely skip until something breaks.

The Math You Actually Need for Machine Learning


Welcome to my blog 🥰

## What is Crop View ?

[Crop View](https://autode.sk/3pas1jq) help to display the elements inside the box that wrapped by the region.

## How to active Crop View in Revit ?

Let active two properties or the icon like image.

![Cropbox Property](/assets/images/blogs/cropview/cropbox-property.png 'Cropbox Property')

## So how to do multiple selection crop a view by RevitAPI ?

In RevitAPI, Crop View is definition by CropBox Property which it can be set by `BoundingBoxXYZ`

**So now let's started 🚀🚀🚀**

### Step 1:

The region which Crop View is limited to is enclosed by two points. In the current view, two points are located top-right and bottom-left.

Use the method `PickBox` which will return two points:

```csharp

// Selection Box by pick rectangular
 PickedBox pickedBox = uidocument.Selection.PickBox(PickBoxStyle.Directional, "Draw Rectangular Box, Press ESC to exit");
 XYZ pointBottomLeft = pickedBox.Min;
 XYZ pointTopRight = pickedBox.Max;
```

### Step 2:

The active view has a `Transform`. So we need modify the point to be the correct point with the transform of the view.

```csharp

//Get the invert transform of active view
Transform transform = view.get_BoundingBox(null).Transform.Inverse;
//Transform of the point
pointBottomLeft = transform.OfPoint(pointBottomLeft);
pointTopRight = transform.OfPoint(pointTopRight);

// Get exactly value min and max
double minX = Math.Min(pBox.Min.X, pBox.Max.X);
double maxX = Math.Max(pBox.Min.X, pBox.Max.X);

double minY = Math.Min(pBox.Min.Y, pBox.Max.Y);
double maxY = Math.Max(pBox.Min.Y, pBox.Max.Y);
```

### Step 3:

Declared new `BoundingBoxXYZ` and apply for `CropBox`.

```csharp
//Create new instance of boundingBox
BoundingBoxXYZ boundingBoxXYZ = new BoundingBoxXYZ();
boundingBoxXYZ.Min = new XYZ(minX, minX, 0);
boundingBoxXYZ.Max = new XYZ(maxX, maxY, 0);
boundingBoxXYZ.Transform = view.CropBox.Transform;

//Active Crop View and aplly the new boundingBox for Cropbox
view.CropBoxActive = true;
view.CropBoxVisible = true;
view.CropBox = boundingBoxXYZ;
doc.Regenerate();
```

### Step 4:

Add the `while-loop` for the code, so you can multiple set Crop View. Remember using `Transaction`.

```csharp
PickedBox pickedBox = null;
while (true)
{
    try
    {
        pickedBox = uiDocument.Selection.PickBox(PickBoxStyle.Directional, "Draw Rectangular, Press ESC to exit");
    }
    catch
    {
        break;
    }

    if (pickedBox != null)
    {
        using (Transaction transaction = new Transaction(document))
        {
            transaction.Start("Crop view by selection");
            // code block
            transaction.Commit();
        }
    }
}
```

## Conclusion

Yeah 🎯, So we finished the small tool can help create quickly Crop View.

## Reference

You can get full source code and another tool at [RevitAPI-Learning](https://github.com/LDATuan/RevitAPI-Learning)


The small tool will help create quickly the crop the view in any view

Writing

How RLHF Works, and Why It Uses PPO

The Math You Actually Need for Machine Learning

How To Crop View With RevitAPI