Let me understand the problem: 1. `implemented_function` creates a custom function with an implementation (`_imp_` method) 2. When calling `evalf()` on such a function, it should evaluate the function implementation and return a numeric result 3. But when the function is composed (like `f(g(2))`), `evalf()` doesn't call `_imp_` recursively on the arguments Let me look at the relevant code to understand the bug.

Let me look at the Function class in function.py, specifically the `_eval_evalf` method.

Let me look at the `_eval_evalf` method in the Function class at line 500.

Let me try again.

Now I can see the `_eval_evalf` method at lines around 500. Let me look at it more carefully: ```python def _eval_evalf(self, prec): # Lookup mpmath function based on name fname = self.func.__name__ try: if not hasattr(mpmath, fname): from sympy.utilities.lambdify import MPMATH_TRANSLATIONS fname = MPMATH_TRANSLATIONS[fname] func = getattr(mpmath, fname) except (AttributeError, KeyError): try: return Float(self._imp_(*self.args), prec) except (AttributeError, TypeError, ValueError): return # Convert all args to mpf or mpc ... ``` The issue is in the try/except block. When the function doesn't have an mpmath equivalent, it tries `self._imp_(*self.args)`. But `self.args` contains the arguments as they are - for example, if we have `f(g(2))`, then `self.args` would be `(g(2),)`. The `_imp_` function receives `g(2)` as its argument, but `g(2)` is a SymPy expression, not a number. The `_imp_` function for `f` (which is `lambda x: x**2`) can't evaluate `g(2)`. The fix should be to first call `.evalf()` on each argument before passing it to `_imp_`. So `self._imp_(*self.args)` should become something like `self._imp_(*[arg.evalf(prec) for arg in self.args])`. Wait, but that would call evalf on the arguments. The problem is that `g(2)` is an implemented function too, and calling `.evalf()` on it should work if the bug is fixed. So we need to recursively call evalf on the args. But wait, there's also the other path where it converts args to mpmath. Let me check if the same issue exists there. Actually, looking at the code more carefully: the mpmath path converts args using `arg._to_mpmath(prec + 5)`. This should work fine for compositions because `_to_mpmath` should recursively evaluate. The issue is specifically in the fallback path: ```python return Float(self._imp_(*self.args), prec) ``` This should be: ```python return Float(self._imp_(*[arg.evalf(prec) for arg in self.args]), prec) ``` But wait, `Float` constructor already processes the result. Let me think about this more carefully. Actually, the arguments need to be evaluated to floats before being passed to `_imp_`. The `_imp_` function takes numerical values, not symbolic expressions. So we need to call `evalf()` on each argument. But there's a subtlety: what if one of the arguments is itself a function that also needs `_imp_` to be called? The recursive call to `evalf()` should handle that. Let me also check the lambdify module to understand `implemented_function` better.

Now let me look at the `_eval_evalf` method more closely and the `implemented_function` function:

Let me read the relevant sections with proper parameters.

Now I understand the issue. In `_eval_evalf`, when the function doesn't have a corresponding mpmath function, it falls back to: ```python return Float(self._imp_(*self.args), prec) ``` This passes `self.args` (which are SymPy expressions) directly to `_imp_`. For `f(g(2))`, `self.args` is `(g(2),)`, and `_imp_` for `f` receives `g(2)` which is a SymPy expression, not a number. The fix should be to evaluate the arguments (using `evalf`) before passing them to `_imp_`. So: ```python return Float(self._imp_(*[arg.evalf(prec) for arg in self.args]), prec) ``` But wait, there's a subtlety. We need to be careful about recursion. When we call `arg.evalf(prec)`, it will eventually call `_eval_evalf` on the argument if it's also a Function. That should work correctly since the same fix applies recursively. Actually, let me think again. The `_imp_` function expects numerical values. After calling `evalf()` on an argument, if that argument is a function like `g(2)`, then `g(2).evalf()` should call `g`'s `_eval_evalf` which would call `g._imp_(2)` and return `Float(4, prec)`. Then `f._imp_(Float(4, prec))` would return `Float(4, prec)**2` which is `Float(16, prec)`. Wait, that's not right either. Actually the `_imp_` function is a Python lambda like `lambda x: x**2`. When called with a Float, it would return a Float. And then `Float()` of that result would handle the precision conversion. But actually, there's another subtlety. The `_imp_` function expects raw Python numbers, not SymPy Float objects. Let's check: `lambda x: x**2`. If x is a Float, then `x**2` would be a Float. Then `Float(Float(4, prec), prec)` would just return `Float(4, prec)` (with the given precision). Wait, that's not right for `f(g(2))` where f(x) = x^2 and g(x) = 2*x. Let me trace through more carefully: - `f(g(2))` → `f` has args `(g(2),)` - `f._eval_evalf(prec)` is called - Arguments: `[g(2).evalf(prec)]` → this calls `g._eval_evalf(prec)` - `g._eval_evalf(prec)`: `g._imp_(*[2.evalf(prec)])` = `g._imp_(2.0)` = `4.0` → returns `Float(4.0, prec)` - Now `f._imp_(Float(4.0, prec))` = `Float(4.0, prec)**2` = some Float - `Float(that_result, prec)` = Float with correct precision Actually, I realize the `_imp_` should receive plain numbers, not Float objects. But `evalf` returns Float objects. Hmm. Let me look at how `_imp_` is typically used. Looking at `_imp_namespace` in lambdify.py: ```python imp = getattr(func, '_imp_', None) ``` This is used to get the implementation for lambdify. When lambdify is used, the arguments are plain Python numbers. But in `_eval_evalf`, the `_imp_` is called with `self.args` which are SymPy expressions. The `_imp_` function should be written to handle plain numbers (like `lambda x: x**2`), but it could also potentially handle SymPy types. Regardless, for the composition to work, we need the arguments to be evaluated first. Let me check: would `_imp_` work correctly if passed a Float instead of a plain Python float? For `lambda x: x**2`, yes - `Float(4)**2` would give `Float(16)`. And then wrapping in `Float(..., prec)` would set the precision. So the fix is to change: ```python return Float(self._imp_(*self.args), prec) ``` to: ```python return Float(self._imp_(*[arg.evalf(prec) for arg in self.args]), prec) ``` Wait, but `evalf` might call `_eval_evalf` recursively. For arguments that are already numbers (like `Integer(2)`), `evalf` would just return a `Float`. For arguments that are `Function` instances like `g(2)`, `evalf` would call `_eval_evalf`. This should work recursively. But there might be an issue: what if `_imp_` expects a specific type? For instance, what if someone writes `implemented_function('f', lambda x: x + 1)` and then calls `f(2).evalf()`? With the current code, `_imp_` receives `Integer(2)`, and `Integer(2) + 1` returns `Integer(3)`. Then `Float(Integer(3), prec)` returns a Float. If we change it to pass `Float(2, prec)` to `_imp_`, then `Float(2, prec) + 1` returns `Float(3, prec)`, and `Float(F ... [truncated 1,046 characters]

Now I understand the bug. Let me look at the exact code block in `_eval_evalf`:

The bug is on line 510: `return Float(self._imp_(*self.args), prec)`. The problem is that `self.args` are not evaluated before being passed to `_imp_`. For composition like `f(g(2))`, the args would be `(g(2),)` — a symbolic expression, not a number. The fix is to evaluate each argument with `evalf(prec)` before passing to `_imp_`: ```python return Float(self._imp_(*[arg.evalf(prec) for arg in self.args]), prec) ``` Let me verify by reproducing the bug first, then apply the fix.

Let me reproduce the bug first:

I've confirmed the bug. Now let me fix it.

Confirmed the bug. Now let me fix it:

Now let me verify the fix works.

Now let me verify the fix:

The fix works: `f(g(2)).evalf()` now correctly returns `16.0000000000000` (since f(x)=x² and g(x)=2x, f(g(2)) = f(4) = 16). Let me also run the existing tests to make sure nothing is broken.

The fix works. `f(g(2)).evalf()` now correctly returns `16.0000000000000` (since `f(x)=x²`, `g(x)=2x`, so `f(g(2)) = f(4) = 16`). Let me also run the existing tests related to evalf to make sure nothing is broken:

Let me try with the test runner that's available.

Let me try running the tests another way.

All tests pass. Let me also run the lambdify tests to make sure the fix doesn't break anything there.

All tests pass. Let me also run the lambdify tests: