Code style query: multiple assignments in if/elif tree

[Steven D'Aprano]

We're talking deceleration, so it actually decreases linearly until it
reaches minimum


Concave upwards, since we're decelerating.


Integral of the line segment is greater than the integral of the actual
curve.

.... great.

Okay. I never studied calculus, so this is beyond my expertise. Is this
going to make a majorly significant difference to the end result?

I thought that there was a chance that there might be, but it turns out,
not so much. There is a difference, but for the purposes of the
simulation it probably doesn't matter. If you were trying to land a
spacecraft on Mars, that's a different story...

 

[Chris Angelico]

On Tue, 01 Apr 2014 16:01:40 +1100, Chris Angelico wrote:

[...]

It actually is a smooth increase in deceleration, but I'm operating the
simulator on a 1s period, so it's actually an average across the first
second, and an average across the next second...

Hmmm. A 1-second resolution doesn't really sound too great to me.

Suppose the deceleration increases linearly from 0 to 0.85 m/s over two
seconds. Averaging it in the way you suggested, we get a total distance
of:

2*u - 0.5125

(see my previous post for details) where u is measured in metres per
second. Multiply by seconds to get the units right. For a Japanese bullet
train where u = 320 km/hr that corresponds to

py> 2*88.888889 - 0.5125
177.26527800000002

metres.

Now let's do it properly! Given our assumption that the deceleration is
linear, the jerk will be constant:

j = Δa/Δt
= (0.85 - 0)/2
= 0.425 m/s^3

Let's start integrating!

py> from sympy import integrate
py> from sympy.abc import t
py> j = '0.425'
py> a = integrate(j, t)
py> v = 88.888889 - integrate(a, t)
py> s = integrate(v, (t, 0, 2))
py> s
177.211111333333

compared to 177.26527800000002 calculated the rough way. That's not bad,
only about 5cm off! Effectively, your rough calculation was accurate to
one decimal place.

5cm when we're dealing with track distances measured in meters and
usually hundreds of them? Sounds fine to me!

Of course, if the equation for acceleration was more complex, the
approximation may not be anywhere near as good.

And that's the bit I can't know. I've added a comment to the code and
will toss it back to my brother - hopefully he'll either know the
answer or know where to look it up / who to ask.

[...]

Okay, what's u here? Heh.

They're *standard* equations of motion. Weren't you paying attention
through the, oh, three years of high school where they teach this?

They're certainly the standard equations, but I learned that:

d = v₀t + at²/2

which is the same as you had, except for the names: d for distance, vâ‚€
(V zero, that's a subscript zero if encodings or fonts kill you here)
for initial velocity (ie velocity at time zero - vₜ (that's a
subscript t, U+209C, but it isn't working in this font) is velocity at
time t, which is vâ‚€+at), and a and t are the same as you have.

s = displacement (distance)
t = time
u = initial velocity
v = final velocity
a = acceleration

I have to say, the one-letter variables are a lot easier to work with.
Guess I learned them the hard way, heh. Although remembering that v is
velocity is easier than remembering which of u and v is initial and
which is final.

Since they are unrelated assignments, of two different variables, they
should be written as two separate assignments, not one using sequence
unpacking.

Change made. Yeah, that looks a bit cleaner. Although I would prefer a
simple formula to what I have there, and I'm still not perfectly sure
it's accurate.

Advice appreciated.

ChrisA

 

[Chris Angelico]

I thought that there was a chance that there might be, but it turns out,
not so much. There is a difference, but for the purposes of the
simulation it probably doesn't matter. If you were trying to land a
spacecraft on Mars, that's a different story...

I'm liking the idea of pretending it's linear acceleration. Our error
in the system is:

1) Distances are accurate to one meter at absolute best; and I
wouldn't guarantee that they're even that accurate.
2) The simulation will apply the brakes at some exact number of
seconds past its origin.
3) A human driver might well apply the brakes a couple of seconds too
soon, and then cruise at the curve's speed for a short distance before
actually reaching the curve.
4) A human driver might also apply the brakes too _late_, and there
are tolerances built into the curve speed limits to cater for this.
The train would rock a bit more than is desired, but it won't
instantly derail if it hits a 90km/h curve at 91km/h (which is how the
simulator treats it).

Add all that up, and the end result is unlikely to be accurate to
better than ten seconds - and that's being generous. Ultimately, this
would be for drawing up projected timetables, so it's not going to be
used at more than one-minute accuracy; although comparing two proposed
routes might technically make use of more accuracy than that ("we
could go around to the left of this, or to the right of it; which
would be the faster route?" "This one, by thirty seconds"), any
difference of less than a minute would really have to be called
"practically equal".

By the way, line speed (the maximum safe speed on straight track) is
400km/h, so your estimates involving a 320km/h bullet train are in the
right ballpark. Curves could be practically any speed between zero and
that, although one would hope there aren't any Kooyong Stations on the
route! (Just up [1] of the station [2] is a tram crossing, which for
decades has been so bumpy and messy that trains had to slow down to
about 10 or 20 kays to get through safely.)

ChrisA
[1] https://en.wikipedia.org/wiki/Rail_directions#United_Kingdom
[2] https://en.wikipedia.org/wiki/Kooyong_railway_station

 

[Steven D'Aprano]

Although remembering that v is
velocity is easier than remembering which of u and v is initial and
which is final.

Which comes earlier in the alphabet?

 

[Chris Angelico]

Which comes earlier in the alphabet?

So why isn't v initial velocity and w final? You start with some
velocity, right?

(Okay, now I'm mostly trolling. Heh. I did say your way was better, to
start with.)

ChrisA

 

[Ian Kelly]

5cm when we're dealing with track distances measured in meters and
usually hundreds of them? Sounds fine to me!

Erm, that's just the accumulated error over the first 2 seconds,
though. A train moving at 88 m/s and decelerating at a maximum of
0.85 m/s^2 is not going to stop in just 177 meters.

After the first 2 seconds, the model is the same using either method,
but the velocity after 2 seconds is different. Using the linear
deceleration integration, we get:

a(t) = {-0.425t, t <= 2;
-0.85, t > 2}
v(t) = {v0 - 0.2125t^2, t <= 2;
v0 - 0.85 - 0.85t, t > 2}

Giving v(2s) = v0 - 0.85 m/s

Using the averaging method, we get v(2s) = v0 - 0.2 - 0.425 = v0 - 0.625 m/s

For a difference of 0.225 m/s. Using Steven's formula (4), the
additional difference in stopping distance is thus:

Äs = ((0 - (88.888889 - 0.625)^2) - (0 - (88.888889 - 0.85)^2)) / -1.7
= 23.33 m

The reason the velocity is different after 2 seconds is because the
linear deceleration does not match the constraints of the problem. The
average deceleration for the first second is not 0.2 m/s, and the
average deceleration for the second second is not 0.425 m/s.

 

[Ian Kelly]

The reason the velocity is different after 2 seconds is because the
linear deceleration does not match the constraints of the problem. The
average deceleration for the first second is not 0.2 m/s, and the
average deceleration for the second second is not 0.425 m/s.

Which I suddenly realize after posting makes my entire point moot. It
doesn't matter how much total error there is from the linear
deceleration method because the linear deceleration is wrong. As long
as the averaging method has the actually correct velocity at 2s and thereafter
continues to have the actually correct velocity, it will only be off
by that small amount of error from the first two seconds.

 

[Ian Kelly]

Given that, I have to question your figures:



As I noted the rough way should be an underestimate, so I'm not sure
why it's an overestimate here. That said, I don't see where either of
us made a mistake.

And I realize now that this is also because the linear deceleration
assumption doesn't match the average deceleration stated in the
problem. It actually decelerates faster and cuts under the t=1s and
t=2s points in the velocity graph, and therefore is actually a
slightly larger underestimate.

 

[Ian Kelly]

.... great.

Okay. I never studied calculus, so this is beyond my expertise. Is
this going to make a majorly significant difference to the end result?
If so, I guess the code's going to have to be a whole lot more
sophisticated, which means I need to learn a whole lot more maths in
order to write it. And I'm still trying to find time to get familiar
with systemd (having jumped on the Upstart bandwagon and now find
myself backing a losing horse, if you'll forgive a mixed metaphor) and
Cython (just need an excuse for that one).

Assuming the stated acceleration averages are correct, we can put an
upper bound on the error. Draw a rectangle bounding the two
consecutive points on the velocity graph. Given that the actual
velocity decreases monotonically (which should be a safe assumption),
that curve must be contained within this rectangle. Given that the
deceleration also increases monotonically, we can also say that the
curve must be contained within the upper triangle of that rectangle,
as bisected by the straight line segment of the constant average
acceleration version. The area of this triangle is 1s * 0.2 m/s / 2 =
0.1m. The area of the same triangle between t=1s and t=2s is 1s *
0.425 m/s / 2= 0.2125 m. Summing those, the upper bound for the error
is only 0.3125 m.

 

[Chris Angelico]

And I realize now that this is also because the linear deceleration
assumption doesn't match the average deceleration stated in the
problem. It actually decelerates faster and cuts under the t=1s and
t=2s points in the velocity graph, and therefore is actually a
slightly larger underestimate.

Okay... so... hmm.

I'm trying to wrap a fried brain around your post here, and I'm not
sure it covered it properly. It's like a tortilla with the meat
spilling out. (My analogies aren't much saner when I'm not brain
fried, trust me.)

The important part here is to work out exactly how fast we'll be going
at the end of two seconds of gentle braking (before the 0.85m/s/s bit
begins). If that velocity is exactly the initial speed minus 0.625
m/s/s, then the error won't accumulate, and it's just a slight
difference that's well within tolerance. But if that velocity is
higher or lower, then it's going to be significant; the initial speed
could be 111.1Ì… m/s (line speed of 400 km/h), and at that speed, 0.1
m/s difference could make a visible difference to the distance
travelled (the difference between 111.0 and 111.1 m/s makes a 10m
difference in the distance to reach 90 km/h or 25 m/s). Although,
truth be told, that's probably still not *very* significant; it's 0.12
seconds of time difference.

The exact deceleration curve isn't significant; all that matters is
how far the train goes during that curve, and how much speed it loses.

ChrisA