Perlgeek.de

Fixing Rakudo Memory Leaks

Moritz Lenz — Thu, Aug 26 13:52:12 2010

Rakudo has been leaking memory for a few month. The other day, after some nagging, Will Coleda identified a memory leak, and Tyler Curtis fixed it.

Now we can again make long-running processes with Rakudo. For example for my talk at YAPC::EU I plotted a resonance curve. For that I needed to start a new Rakudo process for every data point because it would leak so badly that it died after processing a few data points. Now I recalculated a whole curve in one process, with memory usage not exceeding 200MB of virtual mem.

I also had some fun recalculating a mandelbrot fractal in a size that would previously make Rakudo segfault or consume too much memory.

(Rendered with colomon's mandelbrot code)).

Pascal's Triangle in Perl 6

Moritz Lenz — Wed, Aug 25 17:03:32 2010

Today on IRC, Larry Wall showed this piece of Perl 6 code, which he wrote for Rosetta Code:

sub pascal { [1], -> @p { [0, @p Z+ @p, 0] } ... * };
say pascal[^10].perl
# output (reformatted for easy readbility):
# ([1],
#  [1, 1],
#  [1, 2, 1],
#  [1, 3, 3, 1],
#  [1, 4, 6, 4, 1],
#  [1, 5, 10, 10, 5, 1],
#  [1, 6, 15, 20, 15, 6, 1],
#  [1, 7, 21, 35, 35, 21, 7, 1],
#  [1, 8, 28, 56, 70, 56, 28, 8, 1],
#  [1, 9, 36, 84, 126, 126, 84, 36, 9, 1])

That's Pascal's triangle, generated in one line of Perl 6.

The ... is the series operator, which generates lists by feeding the previous value(s) (here always one array) to the generating block on its left, until it reaches the goal on the right (in this case "whatever", which means it returns a lazy, infinite list).

So for example if the previous item was the array [1, 2, 1], the code block evaluates 0, 1, 2, 1 Z+ 1, 2, 1, 0.

Z is the zip operator, Z+ is pairwise addition (ie adding the pairs that the zip operator produced). In our example that leads to 0+1, 1+2, 2+1, 1+0 or 1, 3, 3, 1.

It takes a while to get used to the meta operators and the series operator, but once you've understood them, you can do pretty neat things with them.

Programming Languages Are Not Zero Sum

Moritz Lenz — Mon, Aug 23 10:54:54 2010

From Wikipedia, the free encyclopedia:

In game theory and economic theory, zero-sum describes a situation in which a participant's gain or loss is exactly balanced by the losses or gains of the other participant(s). If the total gains of the participants are added up, and the total losses are subtracted, they will sum to zero.

Being advocate, implementor, tester and co-designer of a new programming language, I often hear objections along the lines of you are killing $other_programming_language, combined with a mixture of fear and resentment. People are afraid that having a new player on the market will decrease market share of their own, favorite programming language.

While I can understand these thinking patterns, there is no reason for concern. The market for programming languages is not a zero-sum situation. While I don't have hard data, I have the impression that the programming job sector is growing, and the US government expects it to grow further, too.

Certainly the growth of world population sets a rapidly increasing baseline, and even if we assume a constant percentage of all people related to programming in some way, the total number of programmers rises, and will continue for quite some time.

(I'm pointing to some resources about programming jobs, and I fully realize that it's not the same as number of overall programmers; but it's easier to get data for jobs, and I do think that the general trend statements are true for both).

So as long as the total number of programmers increases, a decrease in relative market share doesn't automatically mean a loss. In fact the job trends show an increase for "scripting" languages, and while Ruby is certainly the winner in terms of growth, Python, Perl and PHP win too!

Non-job data shows for example a noisy but steady growth of uploads to the Comprehensive Perl Archive Network (CPAN) -- data from a programming language that is often perceived as a loser of ruby's and python's success.

A recent Linux distribution trend analysis fell into the same trap: it shows relative numbers of search terms, and talks about a decline for all distributions except Ubuntu. Again I don't have hard numbers (the mirror infrastructure of most Linux distributions makes it nearly impossible to get accurate download counts), but I haven't seen any evidence that total usage numbers of any of the Linux distributions actually decreased.

The State of Regex Modifiers in Rakudo

Moritz Lenz — Mon, Aug 16 17:16:15 2010

During the last one and a half month, I've been working on making regex modifiers easily available in Rakudo.

The regex compiler itself has to support only a few of the adverbs that can be applied to regexes; those include :ignorecase, :sigspace, :ignoremark and :continue/:pos. NQP-rx, the regex engine that Rakudo uses under the hood, supports those (except :ignoremark), so previously you could write

if 'ABC' ~~ /:i abc/ {
    say "case insensitive match";
}

But not

if 'ABC' ~~ rx:i/abc/ {
    say "case insensitive match";
}

nor m:i/abc/, for that matter.

I've patched Rakudo to actually recognize those adverbs outside of the regex, and also for s/// substitutions.

Another category of adverbs are those that apply to regex calls, not to the compilation of a regex. Among those are :global/:g, :overlap/:ov, :nth($n), :x. I've implemented those for substitutions, but implementing them for m// turns out to be quite a bit harder.

The reason is the return value: each regex match returns a Match object, which can store positional and named parts. S05 says that regex matches with multiple results should return a single match object, with all results as positional parts. It can be distinguished from a normal match object by evaluating it in slice context... which Rakudo doesn't support yet.

Now the subst method and thus s/// are implemented by calling .match(:global, ...), and without slice context, it can't distinguish between multiple matches, and a single match with subcaptures. And so my changes to the global match broke the substitution, and I see no easy way to fix it.

Anyway, here are a few examples of what works today:

$_ = 'ab12fg34';
s:g/\d/X/;
.say; # output: abXXfgXX


$_ = 'Hello, World';
# :ii is the same as :samecase
s:ii/world/perl/;
.say; # output: Hello, Perl

$_ = 'I did not know that that work together';
s:2nd/that/they/;
.say; # output: I did not know that they work together

What is the "Cool" class in Perl 6?

Moritz Lenz — Thu, Aug 12 15:28:39 2010

In Perl, subroutine and operator names determine what happens, usually not the type of the arguments. Instead the arguments are coerced to a type on which the operation makes sense:

say uc 34;      # coerces 34 to a string, and upper-cases it
say 1 + "2";    # converts "2" to a number before adding

To make things more extensible, the uc function re-dispatches to the uc method on its argument. So for the example above to work, we need an uc function in Int. And in Array, so that @a.uc works. And so on.

The original approach was to stuff all these methods into Any, the base class of the object hierarchy. Which kinda worked, but also meant that all user-defined classes ended up having some few hundreds methods to start with. Not good.

These days, the type Cool fills this niche: most built-in types (all that are meant to be used in that polymorphic way) inherit from Cool, so the uc method is actually defined in class Cool, coerces to string, and then re-dispatches to the internal logic that actually does the upper-casing.

The name either stands for Convenient object oriented loopback, or just expresses that that most built-ins are cool with an argument of that type.

If users want to write a type that can be used like a built-in type now just inherit from Cool, and define coercion methods to other built-in types. If the types don't inherit from Cool, they are more light-weight, and less magic. There's more than one way to do it.

Cool is a class (and not a role), because classes are mutable; so if you want to inject behavior into nearly all built-in types, augmenting Cool is an option (though usually considered evil, and should not be done lightly).

Perl 6 Questions on Perlmonks

Moritz Lenz — Tue, Aug 10 11:18:42 2010

Since the Rakudo Star release, there has been a noticeable increase in Perl 6 questions on perlmonks - a good sign, because it means people are using it.

Array interpolation in Rakudo
Rakudo build problems
Perl6, latest Rakudo bug or error on my part? (parsing issue related to missing whitespace).
Perl6, modifying @*INC (another ws parsing issue)
Perl6's LWP::Simple -- seemingly an installation issue
Perl 6, defining a hash with interpolated string

I've assembled this list by looking through the 100 newest nodes in Seekers of Perl Wisdom, which makes it 6% of the questions asked, or on average 1 per day (used to be around 1 per week).

Most of the questions are related to environmental issues (building/installing stuff), or beginner's questions related to syntax.

It's good to see the questions flowing in, and I hope that we'll soon see more questions where I can show off cool Perl 6 features in the answers :-).

Notes from the YAPC::EU 2010 Rakudo hackathon

Moritz Lenz — Fri, Aug 6 16:48:40 2010

At YAPC::EU 2010 we had a long discussion about Perl 6, Rakudo and related matters. Here are some (very incomplete) notes of the ongoing discussions and results.

Attendees

Patrick Michaud, Jonathan Worthington, Carl Mäsak, Moritz Lenz, Gabor Szabo, and a fluctuation of other Perl 6 hackers.

Speed

What can we do to improve Rakudo's performance?

jnthn's grant proposal for a low-level meta object protocol: See http://news.perlfoundation.org/2010/07/hague-grant-application-meta-m.html. Will probably bring the biggest speed improvement of all options we have under our control
Rakudo built-in optimizations: Most Rakudo built-ins are written for correctness first, and without a good feeling for what constructs are fast and what aren't. A thorough review (and preferably profiling) could bring decent speed improvements, as the case of int ranges showed.
Garbage collector: Parrot's GC is... suboptimal. To be gentle.
Optimization framework: We will try to convince people that Tyler Curtis' optimization framework for PAST and POST should be shipped with parrot (probably compile PIRs in ext/, just like NQP-rx does it now). Using that, we can do constant folding
Moving stuff to compile time: Number parsing needs to be moved to compile time.

What do we need to keep hacking?

Brought up by Gabor

Money

We do much volunteer work, but when we get funding, we can devote more time to hacking

Travel/Conferences

We'd like to get together a few times (2? 3? 4?) a year, in real life.

Funding and organization would be very welcome

Short-time funding

It would be nice to have a way to have funding available much more quickly than through the usual grant process, which tends to be longish.

Rakudo Star feedback

Good: It worked. It did what we wanted it to.

Bad:

It lacked a module installer (It shipped proto, but didn't install it).
Compilation takes too much memory. pmichaud will try a hack to split the setting, which would solve that problem.
There was some discussion about the roles + outer scopes bugs, which was way over my head. It seems to be related to the fact that parrot has two outer chains for nested blocks: one at compile time, one at runtime. Since role methods are flattened into classes, there compile time outer block is actually different than where it runs, and that screws up ... forget it, somebody else must describe it.
Lack of modules - doesn't seem to bee a big problem
Lack of features: not a big problem.

Biggest complaints: missing perl6doc. Missing non-blocking IO, binary file support.
Prefix paths with spaces are not supported :(

jnthn: "I actually tried to write a C program that binary patches the perl6 executable to allow spaces in path names. It almost worked."
We will try to advocate compilation to PBC, not PIR - once that's supported.

Proto/Pls

Proto needs to be end-of-life'd.

It confuses people that there are two different project lists, and the lists diverge.

We would like to decentralize the module list somehow. Still open how.

People don't release Perl 6 modules, because there's no need so far, and it's tedious to add the version name in each .pm/.pm6 file. We might need to come up with a clever idea for that.

Backend diversity

Additionally to the parrot backend, we want to run Perl 6 code on other virtual machines.

jnthn will work on a .NET/CLR port. He wants to prototype the new low-level class composition code in .NET anyway, which will provide the basic foundations for running NQP.

pmichaud wants to explore javascript on V8 as a possible backend. "I managed PIR, I'll certainly manage javascript" :-)

Huge time sink, but still worth doing it
Apache runtime library might be worth looking into
risks: stalled refactors are dangerous (see: PHP 6, cardinal (the ruby-on-parrot compiler))

We want to avoid fragmentation into many subprojects
We want to increase the number of possible contributors to rakudo by enabling non-parrot people to contribute.
Code for different backends will be maintained as directories in Rakudo and NQP, not as branches.
pir:: things will be hidden behind an nqp:: abstraction layer

Attracting contributors

Moritz wants to continue with the "weekly" challenges, but runs out of ideas. Add ideas to http://svn.pugscode.org/pugs/misc/helpnow/README.

We will try to apply patches faster, thus encouraging people who already did the first step.

Documentation

in p5 pod for now, so that people can contribute easily
masak and szabgab expressed interest in working on pod6 tools

My first YAPC - YAPC::EU 2010 in Pisa

Moritz Lenz — Fri, Aug 6 16:37:07 2010

This week I attended my first international Perl conference, the YAPC::EU 2010 in Pisa, Italy. I very much enjoyed it.

I arrived a few days earlier, and spent the time visiting Pisa, talking with old and new friends, and did some collaborative hacking. I especially enjoyed meeting people with whom I had had only contact via Internet so far, and found all of them to be very nice in meat space.

On Tuesday, the day before the conference started officially, a group of Perl 6 hackers met and discussed topics around Perl 6 and Rakudo. I recall talking with Patrick Michaud, Jonathan Worthington, Carl Mäsak, Paweł Murias, Gabor Szabo, smash (I can't spell his full name correctly from memory, sorry for that), and we have a very productive discussion (about 5 hours or so). Notes from the discussion will be published later.

On Wednesday the actual conference started, and there were plenty of very interesting talks, and very amusing lightning talks. I generally like the humor that is widespread in the Perl community.

On Thursday I continued to attend nice and informative talks, and also gave a talk on my own. It was about physical modelling with Perl 6, and in general the feedback was very positive, and somebody even commented that while he didn't understand everything I wrote, it reminded him that it was important to learn Perl 6 now. Win \o/. (There was also some criticism, but from somebody who apparently hasn't read the abstract; the "write-only" meme seems to apply to perl bloggers, not code). You can find the slides to my talk here.

Firday was the day of my departure too - sadly I had to leave after the first talk, and missed the rest of the day, including the closing keynote by mst (I did attend a talk of his) and the traditional auction.

I especially enjoyed...

meeting Patrick, Larry, Gloria, Aaron, Gabor and many others for the first time in real-life
a thorough, high-bandwith discussion with Larry, Jonathan, Patrick and Carl about p6 spec questions, and the Perl 6 discussions mentioned earlier
a lightning talk imagine you're in a data center with no connection to the outside, and you accidentally executed chmod -x chmod. What would you do?
good Italian Pizzas (although I had to wait 50 minutes for one of them)
A talk by Tim Bunce, where he demonstrated database access in Perl 6 both with libraries that do native calls, and through the Blizkost project using the Perl 5 DBI/DBD::SQLite modules
the general relaxed attitude in the Perl community, where people help each other, and don't seem to be easily offended (at least in meat space :)
being surrounded by many other geeks
realizing that several Perl hackers brought their family to the conference

It was an overwhelming experience, and I look forward to my next YAPC!

Gabor: Keep going

Moritz Lenz — Mon, Jul 19 22:36:05 2010

After reading this blog post, I just want to say: keep going.

Gabor does really awesome things for Perl (and especially for Perl 6, which I tend to notice more): beginner's tutorials, screencasts, training courses, writes an IDE and so on. If his primary interest was his own success, his priorities would be quite different.

I hope that Gabor doesn't pay too much attention to the hostilities from parts of the Perl community, and I wish him and us all the best for his current project.

This Week's Contribution to Perl 6 Week 9: Implement Hash.pick for Rakudo

Moritz Lenz — Tue, Jul 13 15:22:47 2010

For this week's contribution to Perl 6 we ask you to implement the Hash.pick method (which does a weighted random selection) for Rakudo.

(Introduction to this series of challenges)

Background

In Perl 6 the List class has a method called pick, which randomly selects one item from a list. It has a few more options too:

<a b c>.pick;       # pick one random element
<a b c>.pick(2);    # pick two distinct, random elements
<a b c>.pick(2, :replace); # pick two random elements, it's ok
                           # if they are the same
<a b c>.pick(*);    # return a random permutation of the elements
<a b c>.pick(*, :replace); # infinite, random stream of elements

This is already implemented through several multi methods in Rakudo.

Now the specification describes such a method for hashes too (actually it talks about Bags, but Rakudo doesn't have Bags yet. Pretend it says "Hash" instead). It assumes that each value in the hash is numeric, and that the value is a weight that determines the probability of picking one value. For example

{a => 1, b => 2}.pick;  # returns 'a' with probability 1/3
                        # and 'b' with probability 2/3

{a => 1, b => 2}.pick(*);  # <a b b> with probability 1/3
                           # <b a b> with probability 1/3
                           # <b b a> with probability 1/3
{a => 1, b => 0.5}.pick(*) # dies, because the weights aren't all integers
{a => 1, b => 0.5}.pick(*, :replace)  # ok

What you can do

Implement Hash.pick. It's ok if your patch doesn't cover all cases. It would be nice if it supported non-integer weights.

Hint: this could be done by storing a list of accumulated weights, and a list of keys.

{a => 1, b => 2.5, c => 1}

# could translate to 
my @keys = ('a', 'b', 'c');
my @accumulated_weights = (1, 3.5, 4.5);

# now pick a random number between 0 and 4.5,
# find the next-highest index in @accumulated_weights
# with a binary search, and then use that to obtain the key.

Of course other schemes are fine too.

Second hint: because it takes quite some time to recompile Rakudo, it is probably easier to implement the actual logic in a function in a normal source file first, and only later move it into src/core/Hash.pm.

Submission

Please submit your source code to the perl6-compiler@perl.org mailing list (and put moritz@faui2k3.org on CC, because the mailing list sometimes lack quite a bit).

Update: there's one submission on the perl6-compiler mailing list already, which looks pretty good.

Want to write shiny SVG graphics with Perl 6? Port Scruffy!

Moritz Lenz — Mon, Jul 12 15:43:27 2010

First let my apologize for waiting so long to come up with a new "weekly" Perl 6 challenge - I'm running out of ideas, and the one I have left needs more time to prepare.

Instead I want to motivate you to help porting the ruby scruffy charting library to Perl 6. It can generate shiny SVG graphics (they are currently broken on their main website, hence the waybackmachine link).

There's already an initial version Perl 6 port called "tufte", but it's not running yet. It needs your help. If you know a little ruby, and want to learn some more Perl 6, join #perl6, ask for a commit bit, and translate some ruby code into Perl 6. And in the end you'll be rewarded with nice SVG charts :-).

This Week's Contribution to Perl 6 Week 8: Implement $*ARGFILES for Rakudo

Moritz Lenz — Tue, Jun 29 00:00:00 2010

For this week's contribution to Perl 6 we ask you to implement the $*ARGFILES special variable (and underlying object) for Rakudo.

(Introduction to this series of challenges)

Background

In Perl 5, there is a "magic" way to iterate over input: while (my $line = <>) { ... }. This reads from standard input if no command line arguments were provided. If there are command line arguments, they are taken as file names, and <> iterates over the contents of these files.

In Perl 6 this magic is performed with the $*ARGFILES special variable. Please implement it!

To do that, you have to understand how file reading works in Perl 6. Once you have a file handle, there are two ways to read lines: either by calling $handle.get, which returns just one line, or by calling $handle.lines, which returns a (lazy) list of all the remaining lines.

You can obtain the command line arguments from @*ARGS, open a file with my $handle = open $filename; for reading; And finally you can use lines('filename') to read all lines from a file.

What you can do

Implement a backend class for $*ARGFILES. You can do that in normal Perl 6 code, no need to change the actual compiler. Once that's done, we will plug it into Rakudo. Your code might look like this:

class IO::ArgFiles {
    has @!filenames;
    method get() { ... }
    method lines() { ... }
    method filename() {
        # return the current filename, or '-' if standard input
        ...
    }
}
my $*ARGFILES = IO::ArgFiles.new(filenames => @*ARGS);
.say for $*ARGFILES.lines();

(Of course this is only a rough skeleton, you might need to change some details, or add some things).

Submission

Please submit your source code to the perl6-compiler@perl.org mailing list (and put moritz@faui2k3.org on CC, because the mailing list sometimes lack quite a bit).

Update:: there have been two submissions, and a mixture of both has been applied.

This Week's Contribution to Perl 6 - Lottery Intermission

Moritz Lenz — Mon, Jun 28 23:29:11 2010

In the original "Contribute now" announcement I've promised that there would be some t-shirts to win.

Since then there have seven challenges (mostly weekly), and I've decided on the rules of the lottery:

Every contributor can win at most one t-shirt, even if he had submissions for multiple weeks
The lottery will be done on a per-week base

Of course the lottery was conducted by a Perl 6 script. Here it is:

 
use v6;

my @contribs =
    [ "patrickas", "shawjef3@<omitted>", "Dagur Valberg Johannsson", "Juan José 'Peco' San Martín"],
    [ "bubaflub" ],
    [ "patrickas", "David Green" ],
    [ "Hongwn Qiu"],
    [ "David Green", "Chris Fields", "rgrau"],
    [ "sahadev" , "Dean Serenevy"],
    [ "cygx" ],
    ;

my %winners;

for @contribs.pairs.pick(*) -> $p {
    my $week = $p.key + 1;
    my @people = $p.value.flat.grep({ !%winners{$_} });
    say "Candidates for Week $week: @people.join(', ')";;
    my $winner = @people.pick;
    say "And the winner is... $winner!";
    %winners{$winner} = $week;
}

say %winners.perl;

And then, in the moment of truth, it produced this output:

Candidates for Week 7: cygx
And the winner is... cygx!
Candidates for Week 2: bubaflub
And the winner is... bubaflub!
Candidates for Week 5: David Green, Chris Fields, rgrau
And the winner is... David Green!
Candidates for Week 1: patrickas, shawjef3@<omitted>, Dagur Valberg Johannsson, Juan José 'Peco' San Martín
And the winner is... shawjef3@<omitted>!
Candidates for Week 4: Hongwn Qiu
And the winner is... Hongwn Qiu!
Candidates for Week 3: patrickas
And the winner is... patrickas!
Candidates for Week 6: sahadev, Dean Serenevy
And the winner is... sahadev!
{"Hongwn Qiu" => 4, "patrickas" => 3, "bubaflub" => 2, "David Green" => 5,
"cygx" => 7, "sahadev" => 6, "shawjef3\@<omitted>" => 1}

If you are one of the winners, and haven't told me your address yet, please do so. Also tell me your t-shirt size, and whether you want a Rakudo or a Perl 6 t-shirt.

I'd like to thank again everybody who contributed, and The Perl Foundation for sponsoring some of the t-shirts!

This Week's Contribution to Perl 6 Week 7: Implement try.rakudo.org

Moritz Lenz — Mon, Jun 21 09:00:00 2010

For this week's contribution to Perl 6 we ask you to write a web shell for Rakudo, just like tryruby.org (or this js course) but for Perl 6 + Rakudo.

(Introduction to this series of challenges)

Background

We want a website like tryruby, but for Perl 6: A combination of web shell and built-in tutorial.

The idea is that for each session a supervisor/controller process runs on the server, which talks to a Rakudo process, and listens at a local socket. A CGI script receives the program lines to be executed, looks up the port number in a session file or database, and connects via a local socket to the controller process.

What you can do

You can help to make try.rakudo.org come real. This week I ask you to work on the front end, ie. a HTML page with some javascript that works like a shell; it sends the command entered by the user to a CGI script, and displays its response.

It should also be able to show instructions, and advance to the next instruction when the user has entered what he should.

Submission

A stub of the source code can be found on github. Please join our IRC channel and ask for commit access to that repository.

Then fill in any parts you want, primarily concerning the front-end. If you have any questions, don't hesitate to ask either on the IRC channel, or on the perl6-compiler@perl.org mailing list (and put moritz@faui2k3.org on CC, because the mailing list sometimes lack quite a bit).

Update: We now have a frontend and parts of the backend, by courtesy of cygx++. If you want to join the project, please improve what we have now instead of submitting a new solution.

Physical modeling with Math::Model and Perl 6

Moritz Lenz — Sun, Jun 20 13:50:01 2010

Let's talk about physics. I'm a physicist by education and profession, so it might be not be too surprising. But I also want to talk about programming, so please bear with me.

When physicists try to understand a system, typically they first come up with a lot of equations, and then try to solve them. Unfortunately some of those equations are quite hard to solve. I've written a module that solves them numerically, and allows you to express the equations in very simple Perl 6 code.

Getting started

Let's start with a very simple model. As a prerequisite you need the Rakudo Perl 6 compiler (latest release or current development version), and then use proto to proto install Math-Model (which also installs its dependencies).

A first model: throwing a stone horizontally into the air

Let's start with an example (to be found in examples/vertical-throw.pl in the Math-Model repository, with small modifications to unconfuse the syntax hilighter used for this page).

It describes the path of stone thrown vertically into the air.

use v6;
use Math::Model;

my $m = Math::Model.new(
    derivatives => {
        y_velocity      => 'y',
        y_acceleration  => 'y_velocity',
    },
    variables   => {
        y_acceleration  => { $:force / $:mass },
        mass            => { 1 },           # kg
        force           => { -9.81 },       # N = kg m / s**2
    },
    initials    => {
        y               => 0,               # m
        y_velocity      => 20,              # m/s
    },
    captures    => ('y', 'y_velocity'),
);

$m.integrate(:from(0), :to(4.2), :min-resolution(0.2));
$m.render-svg('throw-vertically.svg', :title('vertical throwing'));

First we declare that we use Perl 6 (use v6;), and then we load the module that does all the hard work, Math::Model.

Then comes the interesting part: the actual model. It starts by declaring that the derivative of y (which is the name we use for the current height of the stone) is called y_velocity. Likewise the derivative of y_velocity is called y_acceleration.

A derivative describes the rate of change of some other variables. Here is a short list of useful physical quantities and their derivatives:

Quantity	Derivative
position	velocity
velocity	acceleration
acceleration	jerk
momentum	force
energy	power
charge	current

Next in the model are formulas for some variables. We don't need to give formulas for those values on the right-hand side of the derivatives declarations (y and y_velocity), which we will call integration variables. We just need formulas for the derivatives that are not also integration variables, and for other variables we use in the formulas.

You might remember from physics class that F = m * a, force is mass times acceleration. We use this formula for calculating the acceleration

        y_acceleration  => { $:force / $:mass },

The other variables are actually constants (but Math::Model doesn't distinguish those); mass is set to 1 kg, and the force to the -9.81 N that a mass of 1 kg experiences at the latitude where I live (Germany).

The programmer in you might ask what the heck the : in $:force means. It's a variable that is automatically a named parameter to the current block. Math::Model uses Signature introspection to find out which variables such a block depends on, and topologically sorts all variables into an order of execution that satisfies all the dependencies.

Back to the physical model; all integration variables need an initial value, which are provided on the next few lines. The line

    captures    => ('y', 'y_velocity'),

tells Math::Model which variables to record while the simulation is running.

$m.integrate(:from(0), :to(4.2), :min-resolution(0.2));
$m.render-svg('throw-vertically.svg', :title('vertical throwing'));

Finally these two lines are responsible for running the actual simulation (for the time t = 0s to t = 4.2s), and then write the resulting curves into the file throw-vertically.svg. And here it is, without further ado:

The blue line is the height (in meter), and the yellow line the velocity (in meter/second). Positive velocities mean that the stone is moving upwards, negative that it's moving downwards. After about 4 seconds the stone has the height with which it started, at a velocity of about -20m/s. You don't see any effect of the stone hitting the ground, because the model knows nothing about a ground located at a height of 0m. Just imagine the stone fell into a well or down a cliff, and thus can have negative height too.

Iterating: throwing a stone at an arbitrary angle

It gets a bit more involved when you consider not only the y direction, but also the x direction, and throw the stone at an arbitrary angle. Still the x and y axis are rather independent:

use v6;
use Math::Model;

for 30, 45, 60 -> $angle {

    my $m = Math::Model.new(
        derivatives => {
            y_velocity      => 'y',
            y_acceleration  => 'y_velocity',
            x_velocity      => 'x',
        },
        variables   => {
            y_acceleration  => { $:force / $:mass },
            mass            => { 1 },           # kg
            force           => { -9.81 },       # N = kg m / s**2
            x_velocity      => { 20 * cos($angle, Degrees) } # m / s
        },
        initials    => {
            y               => 0,               # m
            y_velocity      => 20 * sin($angle, Degrees),    # m/s
            x               => 0,               # m
        },
        captures    => <y x>,
    );

    $m.integrate(:from(0), :to(2 * 20 * sin($angle, Degrees) / 9.81), :min-resolution(0.2));
    $m.render-svg("throw-angle-$angle.svg", :x-axis<x>,
                  :width(300), :height(200),
                  :title("Throwing at $angle degreees"));
}

The x velocity stays approximately constant (we disregard air drag), and it's value is the cosine of the throwing angle times the initial, total velocity. The velocity in y direction is the sine of the throwing angle times the initial, total velocity.

As a trick to get nicer graphs in the end, I calculated the expected time until it hits the ground (which I know to be 2 * v_y / a; this is cheating, but it doesn't change the physics behind it).

Finally this time we don't want to have the elapsed time on the x axis, but the actual position in x direction. That can be done with the :x-axis<x> option.

(Note that I cheated to produces these charts; normally SVG::Plot, the module that produces these graphs, automatically scales the axis; I've manually suppressed that; if you try to out the example you'll see that the three charts look much the same, except for different axis scaling).

The maximum reach in x direction before hitting the ground is achieved at 45 degrees. For smaller angles it's not long enough in the air, and for larger angles too much of the velocity is "wasted" in the vertical direction, so the stone doesn't get very far.

A third model: oscillating spring

Finally I want to present a third, simple model: a mass hanging down from a spring, this time including air drag. It doesn't show off any new features of Math::Model, but the result is a nice, oscillating curve.

use v6;
use Math::Model;

my $m = Math::Model.new(
    derivatives => {
        velocity     => 'height',
        acceleration => 'velocity',
    },
    variables   => {
        acceleration    => { $:force / $:mass },
        mass            => { 1 },
        force           => { - $:height - 0.2 * $:velocity * abs($:velocity)},
    },
    initials    => {
        height      => 1,
        velocity    => 0,
    },
    captures    => <height>,
);

$m.integrate(:from(0), :to(20), :min-resolution(1));
$m.render-svg('spring.svg', :title('Spring with damping'));

The air drag/damping is built into the formula for the force. It is proportional to the square of the velocity (making analytical solutions a nuisance), and always points in the opposite direction as the velocity.

Moving on

If you want to have some fun with Math::Model, here's a nice idea: You can simulate a mass attached to a spring, which can move freely in the xy plane. If you chose random initial values for the velocities in both directions, you can get non-periodic (chaotic?) trajectories in the xy plane.

(If you do, please send me the model so that I can also play with it :-))

A personal note

Ever since I've used the simulation tool "stella" in school (must have been year 2002 or so), I've wanted to write something similar. Math::Model is it. It was quite fun to implement in Perl 6. The only drawback is that it's quite slow.