Hi Boyd et al., I finally got round to having a play with raku/perl6. Here are some random thoughts for the list:
Installed with a one line homebrew command, the executable is still called perl6. Everything it says on the tin (https://raku.guide <https://raku.guide/>) works. They finally made a built in object system, rationalised the use of sigils and cleaned up syntax and subroutine arguments. I kind of think that should have been done 15 years ago. Regarding objects they now use something called ‘roles’, I don’t know enough about OO together this or know if it is a good idea. I hope someone can enlighten me. Added built-ins complex numbers, multidim arrays and rational fractions as defaults for decimals. The very easy C native calling is extremely nice. You can use unicode for variable names e.g. greek letters. You can do this: > e**(π*i) -1+1.2246467991473532e-16i Most of this is stuff python2 had a decade ago. Here is a nice review: https://www.evanmiller.org/a-review-of-perl-6.html <https://www.evanmiller.org/a-review-of-perl-6.html> A few more interesting things > e**(π×i) + 1 ≅ 0 True I read the bit on built in N:M concurrency - that DID look interesting and novel. There is no global interpreter thread lock. https://www.evanmiller.org/why-im-learning-perl-6.html <https://www.evanmiller.org/why-im-learning-perl-6.html> I am not a big thread person. Is concurrency a killer app for numerics? It seems more useful for massive web loads. I think this depends on the MoarVM - so wouldn’t reach down to C-level extensions? Regarding the future of PDL, any thing like that for raku would be a complete rewrite. That is overdue anyway, but would be a lot of work. It’s not so much the implementation of the fast array type and slicing, the real work would be in catching up with the vast ecosystem of scipy in terms of graphics libraries, machine learning toolkits, documentation etc. Given the number of people writing new stuff for that ecosystem it seems like a Sisyphean task, unless there is some killer new stuff that can only be done in raku. I haven’t seen that yet. The ruby folk have started down the path - http://sciruby.com <http://sciruby.com/> is acknowledged by them to be an order of magnitude behind python and R. Maybe there is a short cut where we can use the python libraries but still program in perl? For those of us who don’t think whitespace should be a syntax error and like real scoping. It all puts PDL in a very awkward position. Should we be re-factoring for perl5? Does perl5 have a future? Is there a case for numerical extension for raku? As with all OSS any re-factor or re-write will depend on enough people having a passion and a use case to do this. Anyway I would be most interested to hear what others think! The list seems to have gone to quiet low traffic in the last year, which I suspect represents all this, Best, Karl > On 11 Jan 2020, at 1:41 am, Boyd Duffee <boyd.duf...@gmail.com> wrote: > > I've dipped my toe in the Raku waters and can recommend Andrew Shitov's Deep > Dive as a good first book for those on this list. > > The one thing that I could see that Raku brings to numerical computing is > concurrency[0], making parallelization easy(ish) Being able to distribute > your computation over multiple cores has got to find a win from some types of > problems. Also, it makes it easier to use external libraries with the > NativeCall[1] interface. It calls the library (C++, python, fortran even?) > directly without resorting to something like XS. > > The Rat type is interesting, storing numbers as numerator and denominator > Ints to avoid rounding errors, but I'm not sure who's going to take advantage > of it in heavy numerical situations. Sequences are lazy iterators [3] and > there are types for Set theory and other math operations which could be > interesting. > > I think you'd get a lot of millage from listing the "5 things you hate" about > PDL (or numpy) and then looking through the docs and/or ask the > community[4][5][6] to see if you can find a solution for any of them. > > Boyd >
_______________________________________________ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
