Need to fix SyntaxError in cycle try

[alexfrol86]

Perhaps the following will help (perhaps not):
Solve Differential Equations in Python

In this link, search for Cauchy problem
Experiments with SymPy to solve first-order ordinary differential equations

Thanks, but my question was about code acceleration (speeding up loops).

[deanhystad]

Speeding up loops is not your problem. Your main problem is you don't know Python very well and you are trying to use it in a way it is not meant to be used. You are using Python like it is C++ and disappointed that it does not act like C++. If you want a language to act like C++ maybe you should use C++?

You can do what you want to do using Python, but you can't really do it the way you are trying. Larz gives you good advice and you just decide to ignore it because it doesn't fit with you view. Sorry, but Python was not written for you. If you want to use Python you have to change your ways to fit better with what Python provides. One thing that Python is particularly bad at is loops. Some loops can be sped up, but many cannot. Quite often people trying to speed up their code using something like numba and see no benefit or even worse results. Like Python, these tools are meant to be used in a certain way, and if you don't follow their rules, they don't work.

[stevendaprano]

There is so much wrong that this really can't be called Python code.

Ouch!!! That's cruel and unfair. It really can be called Python code. Not the best Python code, and it has at least one syntax error, but it is Python code.

You should not use == when comparing float numbers. Your equation may return a value really close to zero, but it is unlikely any combination of arguments will produce a result that is exactly zero. That is just the nature of floating point math on computers; ridiculous resolution, but almost never results that are exactly right.

That is pure superstition, and bad advice. Please don't say that, it really is terrible, terrible advice.

Python uses IEEE-754 floats, and equality in IEEE-754 is perfectly well defined. Two floats will compare equal if, and only if, they actually are equal. And there are vast numbers of expressions that will result in exactly zero, starting with the most obvious cases x*0.0 and x - x, and going to more complex expressions:

# All of these will return 0.0
math.sin(0.0)
math.exp(-1000)
math.acos(-1.0) - math.pi
(2/3)**2 - 4/9
0.5**1075
(1/8 + 1/64)**2 - 81/8**4

and many, many more. They aren't even hard to find.

Although it is true that arbitrary float expressions may not give exactly zero, that is very different from "you should not...".

Unlike floating point arithmetic pre-IEEE-754, it is never the case that

if x != 0:
    y = 1/x

can fail with a ZeroDivisionError. It just cannot happen, which was not the case back in the dark ages prior to IEEE-754.

Using math.isclose() is the wrong solution here. And why choose 1e-9 for the tolerance? Where does that magic value come from? Floats have about 16-17 significant figures of precision, so you are accepting billions of legitimately non-zero floats as "close enough" to zero.

It is especially, doubly wrong when the OP's intention is to record the combination of values which actually do give a result of zero.

Please read Bruce Dawson, he's writing from a C++ perspective but if you remember that Python floats are C/C++ doubles you can't go wrong.

"don’t blindly trust floating-point math, but don’t assume that it introduces errors at random." -- Bruce Dawson.

[stevendaprano]

Thanks, but my question was about code acceleration (speeding up loops).

You can't speed up code that won't even run because it has syntax errors, and your code has syntax errors. If you fix those errors, it is still not even clear that it works.

Forget about speeding up code until it works.

[stevendaprano]

There are lots of things to improve in your code.

Start with the easy things: move your function outside of the loop, and use intermediate results to simply that enormous, complex, confusing mess of an expression.

def gam0(et0, y30, ph0b, o, l):
    a = o[0] * et0 * cos(i) / sqrt(ph0b)
    b = o[1] * -et0 * sin(i) / sqrt(ph0b)
    c = l * sqrt(1 / ph0b) * et0 * sin(i)
    d = (sqrt(1 / ph0b) * (1 + et0 * cos(i) * (1 + et0 * cos(i)**2) / ph0b**2
    ht = a + b + c + funct_labt(i, o[1], l, o[0]) * d
    return ht

As soon as I split the unreadable mess into individual sub-calculations, it became clear what the error is. Look at the d = ... line. See what is missing?

Hint: count the open and close brackets.

Now let us work on the rest of your code.

for i in z30:
  for o in zres:
    for l in z70:
        result = gam0( something goes here )  # FIX THIS LINE
        if result == 0:
            lh0 = i, o[0], o[1], l
            print(lh0)

I don't know what values should be passed to the gam0 function. You need to fix that yourself.

Notice that I've thrown away the try ... except block. Never, ever try to use try/except blocks to disguise bugs in your code. First of all, it can't work to disguise syntax errors. You have to fix the syntax error, or the code won't run at all.

And secondly, even if you do end up catching exceptions caused by bugs in your code, you are just making more work for yourself, not less.

And lastly, if you have to catch an exception, you should (almost) never use a bare "except":

The most diabolical Python anti-pattern