# [Tutor] Lotka-Volterra Model Simulation Questions

Oscar Benjamin oscar.j.benjamin at gmail.com
Sun Sep 30 12:50:54 CEST 2012

On 30 September 2012 09:37, Alan Gauld <alan.gauld at btinternet.com> wrote:

> On 29/09/12 23:57, Oscar Benjamin wrote:
>
>> On 29 September 2012 22:57, Alan Gauld <alan.gauld at btinternet.com
>>
>
>      My point is that we should not choose short names just to keep an
>>     expression on a single line....
>>
>>
>>     in written math too. (Most of the equations I remember reading from
>>     my quantum mechanics days were split over at least 3 lines... trying
>>
>> I wouldn't advocate forcing an equation onto a single line if it doesn't
>> fit on a single line. However, I'm sure that the equations you're
>> refering to would have already been using lots of symbols described by
>> very succinct single-greek/latin-letters and other simple glyphs.
>>
>
> Yes which made them even more difficult to understand.

Quantum mechanics is hard for anyone. I don't think that an alternative
notation will make it any easier for people in the business of
learning/teaching/using quantum mechanics (there are already several
notations developed specifically for quantum mechanics). I also don't think
that it is possible to find a notation that will make quantum mechanics
intelligible to a layperson: whether you call it psi or
time_dependent_wave_function you will still be assuming that the reader
knows what a wave function is.

>
> > Now imagine replacing each of those single letter symbols
> > with English underscore-separated words so instead of letter
> > capital psi you would have 'time_dependent_wave_function'
> > and instead of hbar you would have 'planks_constant_over_twopi'
> > and so on. Your equation would go from three lines to thirty
>
> One of the things I like about programming is that I can take those types
> of equations and break them into chunks and put them in
> separate named functions. Then each term gets evaluated separately
> and has a name that represents what it means in physical terms.
>

I often write scripts like the one that the OP is tasked with writing.
While I can write a script like the OP's in less than 5 minutes, in
practise it takes longer to convince myself that the code is correct (if it
is important for it to be so). I spend most of the time when developing
such a script simply looking at the code and comparing it with the
mathematical problem I was trying to solve. The further your code diverges
from the original problem statement the harder it becomes to really
convince yourself that the code is correct. Renaming all of your variables
(any more than you need to) so that cross-referencing always requires a
mental table would be a waste of time and would increase the likelihood of
bugs.

>
> <off topic rant>
> One of the things that makes math hard for people to grasp is its
> insistence on abstracting functions/values to single letter names etc.
> (especially when those names are in a foreign language/symbology,
> like Greek!) Of course, the abstraction is powerful in its own right
> because it can then be applied in multiple domains, but that abstraction is
> often the barrier to people understanding the
> principle. Those that are "good at math" are often really those
> who are "good at abstraction".
> </off topic>

I'll agree with the last sentence. The  conventions used in mathematical
symbols convey a lot of meaning (to me). If you look at the Lotka-Volterra
equations on Wikipedia, you'll see that the letters x and y are used for
the variables and greek letters are used for the constants. That
distinction between the variables and constants ("parameters" in dynamics
jargon) is very important when trying to understand the model. It is also
code that solves the system (and is obscured by renaming the variables).

In any case I guess you won't be pleased by my discovery that, thanks to
PEP 3131, the following is valid code in Python 3 (I've attached the code
in case it doesn't display properly):

'''
#!/usr/bin/env python3
# -*- encoding: utf-8 -*-

# Parameters
α = 1
β = 0.1
γ = 1.5
δ = 0.075

# Initial conditions
xₒ = 10
yₒ = 5
Zₒ = xₒ, yₒ

# Solution parameters
tₒ = 0
Δt = 0.001
T = 10

# Lotka-Volterra derivative
def f(Z, t):
x, y = Z
ẋ = x * (α - β*y)
ẏ = -y * (γ - δ*x)
return ẋ, ẏ

# Accumulate results from Euler stepper
tᵢ = tₒ
Zᵢ = Zₒ
Zₜ, t = [], []
while tᵢ <= tₒ + T:
Zₜ.append(Zᵢ)
t.append(tᵢ)
Zᵢ = [Zᵢⱼ+ Δt*Żᵢⱼ for Zᵢⱼ, Żᵢⱼ in zip(Zᵢ, f(Zᵢ, tᵢ))]
tᵢ += Δt

# Output since I don't have plotting libraries in Python 3
print('t', 'x', 'y')
for tᵢ, (xᵢ, yᵢ) in zip(t, Zₜ):
print(tᵢ, xᵢ, yᵢ)
'''

Oscar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20120930/b47c2af6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sim.py
Type: application/octet-stream
Size: 735 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tutor/attachments/20120930/b47c2af6/attachment.obj>