http://qs1969.pair.com?node_id=11138347


in reply to PDEs oo

There is a very good reason why such work is done in FORTRAN: Neither Python, nor Perl are the right tools for PDEs. The reason is that PDEs can be expensive to solve and you want to choose the RIGHT code (e.g. implicit schemes for stiff problems) that runs FAST. Where Perl or any other interpreted language for that matter has a place is as a front-end or backend, for instance a graphical interface to set the parameters and possibly parse the results and create say an Xmgrace graphics file. So the answer is I cannot be certain noone has done a perl implementation of a pde solver, but honestly I'd consider this rather a waste of time.

Replies are listed 'Best First'.
Re^2: PDEs oo
by Fletch (Bishop) on Nov 03, 2021 at 15:32 UTC

    While not necessarily a "wrong" answer, I think this is kind of a bad answer to the original question.

    If you're doing this "seriously" for something, then yes you're going to want to throw something bare metal and these days probably GPU powered at it. However for the purposes of learning how they work and how they're implemented and solved I think something like perl (or python; bleh) is going to be perfectly reasonable and performant for the type of examples you'd encounter in problems. People used to solve these things with slide rules and pencil/paper. If your (again, experimental learning) implementation to solve the hairiest problem in your textbook takes 2 minutes rather than 10 seconds that's not really going to be an issue the tens of times you might be running it.

    And as to the OP not being able to understand the python examples: if you're going to be programming seriously go ahead and take the time to get a reading familiarity of python (the Pascal of the naught-ies . . .). Even if you stick with Perl as your primary language it's worthwhile to be able to digest things in other languages because there's going to be times like this where you can't find something off the shelf. To say nothing of being exposed to other language approaches helps you improve your programming in general.

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

      That's what Im doing; If I don't know how, or can't find a way, to do it in Perl, I switch to another language.Not the first time, it happens. At the moment, I think I found an answer to my problem but I'm still working on it.

        And I forgot to mention that if your problems are doing vector or matrix operations in Perl you probably would want to look at PDL (which while not necessarily as fast as more dedicated low level libraries will probably be speedier than doing things yourself in pure perl).

        The cake is a lie.
        The cake is a lie.
        The cake is a lie.