FIX: index fsolve result in un_insure r_error so brentq gets a scalar

[mmcky]

Problem

un_insure.md failed to execute on a fresh build with the current quantecon-build image (numpy 2.4.4, scipy 1.17.1):

TypeError: only 0-dimensional arrays can be converted to Python scalars

It also emitted a RuntimeWarning: The iteration is not making good progress from fsolve.

Cause

In the calibration cell, r_error was:

Vu_star = sp.optimize.fsolve(Vu_error_Λ, 15000, args=(r))
a_star  = invp_prime(1/(β*(Ve-Vu_star)), r)
return  p(a_star, r) - 0.1

• fsolve returns a length-1 array, so r_error returned a shape-(1,) array. The outer brentq then coerces that to a Python float; under numpy 2.x this raises (older numpy silently accepted 1-element arrays). Cache-warmed CI builds masked it because the notebook wasn't re-executed.
• Separately, Vu_error computed a = invp_prime(...) without enforcing a ≥ 0, so during fsolve's inner search the implied effort a could go negative — feeding back into the error and causing the not making good progress warning. (calc_a already had a = max(0, ...); the two functions were inconsistent.)

Fix

Three changes:

1. Scalar return from r_error — index [0] so the brentq objective returns a Python float (same pattern as Vu_aut = fsolve(...)[0] just below; args=(r,) also corrects the missing tuple comma):

   -    Vu_star = sp.optimize.fsolve(Vu_error_Λ,15000,args = (r))
   +    Vu_star = sp.optimize.fsolve(Vu_error_Λ, 15000, args=(r,))[0]

2. Enforce a ≥ 0 inside Vu_error — small numerical-behavior change that brings Vu_error into line with the clamp calc_a already had, so both functions consistently enforce the economic constraint that search effort is non-negative:

   -    a = invp_prime(1/(β*(Ve-Vu)),r)
   +    a = max(0, invp_prime(1 / (β * (Ve - Vu)), r))

   This eliminates the iteration not making good progress RuntimeWarning.

3. PEP8 / style sweep across the file (spaces around operators, no spaces around = in kwargs, two blank lines between top-level defs, comment spacing, long-line wrapping) and two spelling fixes (utiliy → utility, consumpton → consumption).

Verification

Ran the full un_insure.md notebook inside ghcr.io/quantecon/quantecon-build:latest (numpy 2.4.4 / scipy 1.17.1):

• ✅ Completes end-to-end with no warnings.
• ✅ Calibrated r = 0.00034314093941788904 — matches the published live page (0.0003431409393866701) to ~10 significant figures.
• ✅ All iteration error values match the live page to 10+ significant figures.
• ✅ Rendered figure is byte-identical to the live page (same PNG SHA256, 07de52ef…6578e16).

Tiny last-digit drift in the iteration trace comes from max(0, …) cutting off a small infeasible region during fsolve; converged policy functions and the plot are identical at display precision.

Context

Surfaced while syncing this lecture into lecture-dp; a matching minimal fix landed there as QuantEcon/lecture-dp#17. A follow-up SYNC will bring the warning fix + PEP8 cleanup downstream too.

Warning fix, max(0, …) clamp, and PEP8 sweep contributed by @HumphreyYang.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for lustrous-melomakarona-3ee73e ready!

Name	Link
🔨 Latest commit	b6e0be4
🔍 Latest deploy log	https://app.netlify.com/projects/lustrous-melomakarona-3ee73e/deploys/6a17b0b68daeec00084086f6
😎 Deploy Preview	https://deploy-preview-327--lustrous-melomakarona-3ee73e.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[Copilot]

Pull request overview

Fixes execution of the un_insure.md lecture notebook under newer NumPy/SciPy builds by ensuring the brentq objective function returns a scalar (not a length-1 ndarray), preventing TypeError: only 0-dimensional arrays can be converted to Python scalars.

Changes:

• Indexes the fsolve return value in r_error ([0]) so r_error returns a scalar compatible with scipy.optimize.brentq.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

🚀 Deployed on https://6a17b340d144add6e29989d0--lustrous-melomakarona-3ee73e.netlify.app

[mmcky]

@HumphreyYang would you mind to cast your eye over this. I've done some validation checks and it looks right. But it would be nice to have confirmation.

[HumphreyYang]

Many thanks @mmcky!

The edit is good. There is another warning that I think I know how to fix. Where should I push my commit?

/tmp/ipykernel_10718/2412693371.py:6: RuntimeWarning: The iteration is not making good progress, as measured by the 
 improvement from the last five Jacobian evaluations.
  Vu_star = sp.optimize.fsolve(Vu_error_Λ,15000,args = (r))

[mmcky]

Thanks @HumphreyYang — yes, resolving that RuntimeWarning from fsolve is a good idea. Please push directly to this branch (fix-un_insure-fsolve-scalar-return); I've granted maintainer-edit on the PR so you should be able to push.

(For context on the close-then-reopen: the mirror PR in lecture-dp was merged with a commit message containing "Mirrors upstream fix QuantEcon/lecture-python-advanced.myst**#327**", and GitHub's closing-keyword auto-linker treated fix <cross-repo>#N as a closing reference, so it auto-closed this PR. Reopened now.)

[HumphreyYang]

Thanks @mmcky, so the PRs are now synced!

I have just pushed the fix and the warning is gone. I also made some PEP8 formatting.

[mmcky]

Thanks @mmcky, so the PRs are now synced!

I have just pushed the fix and the warning is gone. I also made some PEP8 formatting.

Thanks @HumphreyYang greatly appreciated.

The PRs syncing issue was unintentional and a side effect have the word "fix" in the lecture-dp PR(!) yikes. Added a rule in my global CLAUDE.md to avoid this scenario.

[mmcky]

Reviewed and verified inside the actual build container (ghcr.io/quantecon/quantecon-build:latest, python 3.13.13 / numpy 2.4.4 / scipy 1.17.1).

Results match the live page to ~10 significant figures and the rendered figure is byte-identical:

Check	Live page	This PR
Calibrated r	0.0003431409393866701	0.00034314093941788904	✅
Check p at r	0.1000000000000214	0.10000000000502518	✅
All 5 iteration errors	match to 10+ sig figs		✅
Figure (PNG SHA256)	07de52ef…6578e16	identical	✅
RuntimeWarning	present	gone	✅

The tiny last-digit drift in the iteration trace is just max(0, …) cutting off a small infeasible region during fsolve. Converged policy functions and the rendered plot are identical at display precision.

One small non-blocking suggestion on the PR body: the title/description reads "update fix and PEP8 check", but max(0, invp_prime(...)) inside Vu_error is actually a substantive numerical-behavior change (not pure refactor). It brings Vu_error into line with the clamp calc_a already had — so both functions now consistently enforce a ≥ 0, which is what eliminates the iteration not making good progress warning. Worth a one-line note in the PR body, so future readers see the substantive vs. cosmetic split clearly.

Nice catch on the warning and clean PEP8 sweep 🙏

🤖 Generated with Claude Code

[mmcky]

@HumphreyYang please merge when you're ready. Just did a few quick updates to PR descriptions and ran a test.

[HumphreyYang]

Many thanks @mmcky, merging!