Re: [Pdl-general] Blue sky - raku

[Boyd Duffee]

If you're still on the fence about Raku, this might swing it for you.

Modules compile down to bytecode the first time they are used which is then
kept in the ".precomp" directory, so that the next time that module is
used, you save on the compilation at start up.
https://docs.raku.org/language/faq#What_is_precompilation?
Traps: Constants are frozen at compile time (unless you turn it off)

This is my experience on migrating a module to Raku (baby steps
https://perl6advent.wordpress.com/2018/12/09/
recent talk on migrating code from Perl to Raku
https://lancewicks.com/2019/10/24/lpw2019-perl-6-losing-your-perl-5-accent/


best,
Boyd

More docs on precompilation:
https://docs.perl6.org/language/pragmas#precompilation - turning it off
https://docs.perl6.org/language/traps#Constants_are_computed_at_compile_time
- things to watch out for
https://docs.raku.org/language/5to6-nutshell#Changed_semantics_with_regards_to_precompilation
 - and more generally
https://docs.raku.org/programs/03-environment-variables#Affecting_precompilation
- turn on diagnostics for precompilation

On Mon, Feb 3, 2020 at 2:35 PM Boyd Duffee  wrote:

> 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 
> 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 

Re: [Pdl-general] Blue sky - raku

[Boyd Duffee]

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 
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 a

Re: [Pdl-general] Blue sky - raku

[Karl Glazebrook via pdl-general]

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  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

Re: [Pdl-general] Blue sky - raku

[Boyd Duffee]

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

[0] https://docs.raku.org/language/concurrency
[1] https://docs.raku.org/language/nativecall
[2] https://docs.raku.org/type/Rat
[3] https://docs.raku.org/type/Seq
[4] https://raku.org/community/  - they're a friendly bunch 🦋
[5] https://rakuadventcalendar.wordpress.com/
[6] https://perl6advent.wordpress.com/

On Fri, Jan 10, 2020 at 4:35 AM Karl Glazebrook via pdl-general <
pdl-general@lists.sourceforge.net> wrote:

> I wanted to open a blue sky discussion. I see that Perl 6 is now renamed
> as ‘Raku’
>
> https://raku.org
>
> So camels are now butterflies.
>
> Seems like a good decision to me, it seems quite a different language
> syntactically and makes clear there will be different paths for Perl vs
> Raku going forward. No one will expect PDL to work on Raku for example
>
> Has anyone on the list had a good play with Raku? I was wondering what
> features it might have that could be good for numerical computing (future
> PDL like extension?). Does it offer things and features that would be hard
> to achieve in numpy for example?
>
> Karl
>
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general
>


-- 
Boyd Duffee
   Bring on a brand-new renaissance - TTH
___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-general] Blue sky - raku

[Karl Glazebrook via pdl-general]

I wanted to open a blue sky discussion. I see that Perl 6 is now renamed as 
‘Raku’

https://raku.org 

So camels are now butterflies.

Seems like a good decision to me, it seems quite a different language 
syntactically and makes clear there will be different paths for Perl vs Raku 
going forward. No one will expect PDL to work on Raku for example

Has anyone on the list had a good play with Raku? I was wondering what features 
it might have that could be good for numerical computing (future PDL like 
extension?). Does it offer things and features that would be hard to achieve in 
numpy for example?

Karl

___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general