# Calculus week-1 lab Cost Minimization, off by a few decimal places

For the Week-1 assignment: Optimizing Functions of One Variable: Cost Minimization

All my unit tests pass for Exercises 1-3

But for Exercise 4, I get this:

print(“dLdOmega(omega = 0) =”,dLdOmega_array[0])
print(“dLdOmega(omega = 1) =”,dLdOmega_array[N-1])

dLdOmega(omega = 0) = -288.96
dLdOmega(omega = 1) = 122.47998

Expected Output

``````dLdOmega(omega = 0) = -288.96
dLdOmega(omega = 1) = 122.47999
``````

I can’t figure out what I’m doing wrong to be slightly off. I’ve tried using different python functions to set the array value, but the error always persists.

(And for Question 3, my answer is accurate, so I think my error is contained in my code for Question 4?:
L(omega = 0) = 110.72
L(omega = 1) = 27.48

Expected Output

``````L(omega = 0) = 110.72
L(omega = 1) = 27.48
``````

)

That all seems fine to me.

Are you getting any error messages or failed tests?

Sorry, yes I’m failing some tests in Question 4:

Test case “default_check”. Wrong output of dLdOmega_of_omega_array for omega_array =
[0. 0.001 0.002 … 0.998 0.9990001 1. ]
Test for index i = 400.
Expected:
-124.38398
Got:
-124.38400268554688
Test case “extra_check”. Wrong output of dLdOmega_of_omega_array for omega_array =
[0. 0.1 0.2 0.3 0.4 0.5
0.6 0.7 0.8 0.90000004 1. ]
Test for index i = 5.
Expected:
-83.240036
Got:
-83.24000549316406
6 Tests passed
2 Tests failed

These sorts of small numerical discrepancies are usually due to you implementing some math operations in a different order than the unit tests expected.

Can I post my code for you to check? I went through each my 4 answers and couldn’t really see any obvious math that could be re-ordered, but I wonder if I’m just missing something specific to Python

@himmat1 Are you running the notebook on your local machine, from a download? If so, that may be the cause of the issue with these slight differences. Try running the same code in the Coursera lab notebook. Jax running locally gave me very different results.

It may also be the data type you’re using. The 64-bit float will take your answer out to significantly more digits, double that of the 32-bit type.

The issue was with the order of operations in one of the math-heavy functions. It was creating small differences due to roundoff and truncation issues.

I’ve submitted an issue to have the test limits increased to allow for other mathematically-correct implementations.