Hi Karl, My take on some of the issues you've raised:
In OO, Roles are seen as an improvement over Inheritance in composing the desired behaviour of an object. A contrived example is that the problems of the Penguin class inheriting from the Bird class are avoided by instead giving it the Swims role, but not the Flies role. > Is concurrency a killer app for numerics I'm sold on the argument that CPUs aren't getting much faster any more, manufacturers are just adding more cores (laptops now come with 4-8 cores and the Intel Xeon W-3275 has 28 cores). In these circumstances, one of the few ways to crunch numbers faster is through parallelization. If you consider the increase in the amount of data we were dealing with when PDL was first announced (I seem to remember that a mega-pixel would run you $100k and you had to do the soldering yourself), it seems sensible to look to concurrency to differentiate between projects despite the huge investment of effort required. Not tried it yet, but I think that NativeCall will give you that short cut to using python libraries that you're looking for. Which means that you've got the application coverage while you do the re-write in Raku to make something that's thread-safe. > Does perl5 have a future? I bet you also like poking bears with a sharp stick. :) It has been declared that they are now "sister languages"[0], so that Perl 5 has an upgrade path and Raku avoids some of the historical issues around the name. Some of the better ideas from Raku have been back-ported to Perl 5, which is where the Moose [1] ecosystem came from. Personally, I will keep writing Perl because that's how I think, but I will start porting my modules to Raku. If there is something that hasn't yet been ported to Raku, you can fill the gap with the Inline::Perl5 module [2] I had wondered if the low traffic on the list meant that those PDL users out there had already scratched all their itches. I'm starting to see new folk take up an interest in learning it. Is the list ready to face newbie questions again? random thoughts: The ease of overloading operators has the potential to make PDL slice syntax a bit more Nice. Junctions and set operators could be a very powerful addition if used with care. Lazy iterators can take ∞ as an argument. Hyper operators [3] are outside my ken. best, Boyd [0] https://www.hackster.io/news/perl-6-is-dead-long-live-raku-perl-5-s-sister-language-gets-a-clean-break-shiny-new-name-3f72ebd298b7 [1] https://perlmaven.com/object-oriented-perl-using-moose [2] https://modules.raku.org/dist/Inline::Perl5:cpan:NINE [3] https://docs.perl6.org/language/operators#index-entry-hyper_%3C%3C-hyper_%3E%3E-hyper_%C2%AB-hyper_%C2%BB-Hyper_operators On Fri, Jan 31, 2020 at 1:36 AM Karl Glazebrook <[email protected]> wrote: > 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) 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 > > 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 > > 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 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 <[email protected]> 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 > > > -- Boyd Duffee Bring on a brand-new renaissance - TTH
_______________________________________________ pdl-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pdl-general
