# Transition Path: 'additionalfactor' to speed up shooting algorithm

**URL:** https://discourse.vfitoolkit.com/t/transition-path-additionalfactor-to-speed-up-shooting-algorithm/699
**Category:** Uncategorized
**Created:** [August 28, 2026, 12:32am UTC](https://discourse.vfitoolkit.com/t/transition-path-additionalfactor-to-speed-up-shooting-algorithm/699 "2026-08-28T00:32:55Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![robertdkirkby](https://discourse.vfitoolkit.com/user_avatar/discourse.vfitoolkit.com/robertdkirkby/32/287_2.png) [@robertdkirkby](https://discourse.vfitoolkit.com/u/robertdkirkby)
#### Post date: [August 28, 2026, 12:34am UTC](https://discourse.vfitoolkit.com/t/transition-path-additionalfactor-to-speed-up-shooting-algorithm/699/2 "2026-08-28T00:34:05Z")

</div>

Here is Claude explanation with more detail:

# additionalfactor: ramping the shooting update

With `transpathoptions.GEnewprice=3` you give the solver a `howtoupdate` rule per general eqm condition:

```matlab
transpathoptions.GEnewprice3.howtoupdate={'CapitalMarket','r',0,0.1; ...
                                          'LabourMarket','w',0,0.1};
% {GE condn name, price name, add, factor}

```

and each iteration updates `new = old ± factor * residual`.

`factor` is a damping constant, and setting it is a compromise. A value small enough to be stable in the early iterations, when the guess is poor and the residuals are large, is usually smaller than you need later, once the path is in the right region. You pay for that in iterations.

`additionalfactor` lets `factor` grow (or shrink) as the solve proceeds.

```matlab
transpathoptions.GEnewprice3.additionalfactor=[f_add,t1_add,t2_add];

```

`factor` is held as given up to iteration `t1_add`, then ramps linearly to `f_add*factor` by iteration `t2_add`, and stays there:

```matlab
rampweight = min(max((itercounter-t1_add)/(t2_add-t1_add),0),1);
factor_iter = factor*(1+(f_add-1)*rampweight);

```

It is written as `1+(f_add-1)*w` rather than as a `min`, so that `f_add<1` — damping the step _down_ over iterations — works just as well as `f_add>1`. `itercounter` is 1 during the first iteration’s update.

## Example

```matlab
transpathoptions.GEnewprice3.additionalfactor=[3,10,30];

```

With `factor=0.1`: the first ten iterations run at `0.1`, then the step grows linearly to `0.3` by iteration 30 and holds there. In a test case here that was the difference between converging comfortably inside a 250-iteration cap and not converging at all.

If your solve oscillates rather than converging, try `f_add<1` instead. Same mechanism, damping down.

## Per-equation rows

One row applies to every general eqm condition. Alternatively give one row per condition, in the same order as `howtoupdate`:

```matlab
transpathoptions.GEnewprice3.additionalfactor=[3,10,30; ... % CapitalMarket
                                               1,1,2]; % LabourMarket, no ramp

```

`[1,1,2]` is the no-op, and the default, since `f_add=1` leaves `factor` alone.

## Rules

- `t1_add` must be an integer of at least 1
- `t2_add` must be an integer strictly greater than `t1_add`
- all entries must be finite
- `f_add~=1` is rejected on any row where you set `factor=Inf`. That is the sentinel meaning “replace the price outright”, so there is no step to scale.

## Where else it works

The same option exists for the stationary general eqm shooting algorithm:

```matlab
heteroagentoptions.fminalgo5.additionalfactor=[f_add,t1_add,t2_add];

```

with identical semantics, and it is supported in the PType transition path and stationary commands too.

It is **not** available with `fminalgo=9` (Anderson acceleration), which accelerates the fixed-point map itself; rescaling the step underneath it would fight the acceleration. That combination raises an error rather than being quietly ignored.

## One thing worth knowing

Because the update factor no longer affects how convergence is measured (see the convergence post), a more aggressive ramp cannot make a path _look_ converged when it is not. It changes how fast you reach the answer, not what counts as the answer.

That was not true before both changes went in together: the old convergence test was the price change, which is `factor * residual`, so a larger `factor` moved the measuring stick at the same time as the prices.

---

_[View the full topic](https://discourse.vfitoolkit.com/t/transition-path-additionalfactor-to-speed-up-shooting-algorithm/699)._