Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Research into occasional participation in Perl/Raku development

by talexb (Canon)
on Oct 01, 2021 at 01:11 UTC ( #11137153=perlmeditation: print w/replies, xml ) Need Help??

If you have any experience with helping out with Perl/Raku, there's a survey that could use your help. I took part a few weeks back, and had a really good conversation with the research assistant.

    Dr. Ann Barcomb (her website) of the University of Calgary is conducting research to understand episodic, or occasional, participation in the Perl/Raku community, in collaboration with The Perl Foundation. The results of her research will be provided as a TPF report and will assist the community in improving practices for managing episodic participation. Please consider assisting them by taking the survey about your participation in the Perl/Raku community. The link to the survey is here.

Thanks!

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

  • Comment on Research into occasional participation in Perl/Raku development

Replies are listed 'Best First'.
Re: Research into occasional participation in Perl/Raku development
by eyepopslikeamosquito (Bishop) on Oct 01, 2021 at 04:53 UTC

      Thanks -- I did do a quick search here and didn't find anything, but I see jdporter's post was from mid-July, so this is a reminder that 2.5 months later, they are still looking for more responses.

      Alex / talexb / Toronto

      Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

Re: Research into occasional participation in Perl/Raku development
by syphilis (Bishop) on Oct 01, 2021 at 13:56 UTC
    Please consider assisting them by taking the survey about your participation in the Perl/Raku community.

    Considered ... and declined.
    Raku provided the opportunity to drag perl into the 21st century but, in terms of the way that numbers are handled, they opted to stick with an approach that I would term "neanderthal".
    So I quickly lost interest. (But that's only because the way that numbers are handled is important to me ... and I do realize that there are others with different priorities.)

    To elaborate, here's the approach that python3 chose to follow:
    $ cat demo.py from fractions import Fraction; print (Fraction(1, 10) == 0.1); # False print (Fraction(3602879701896397, 36028797018963968) == 0.1); # True $ python3 demo.py False True
    And here's the approach that raku has elected to follow:
    C:\_32>type demo.r my $x = 1/10; say $x.nude; my $y = 3602879701896397/36028797018963968; say $y.nude; say $x == 0.1e0; say $y == 0.1e0; say $y == $x; C:\_32>raku demo.r (1 10) (3602879701896397 36028797018963968) True True False
    >type demo.r say 1/10 == 0.1e0; say 3602879701896397/36028797018963968 == 0.1e0; >raku demo.r True True
    Both the raku and python3 scripts are comparing the same rationals to the same double precision floating point value, and yet they provide different results.

    Sure, I get that both of the rationals (1/10 and 3602879701896397/36028797018963968) round to the same double precision floating point value - and that's why raku reports "True" in both instances.
    But the thing is that the double 0.1 does have a precise and exact rational value - and that precise and exact rational value is 3602879701896397/36028797018963968 (or, in decimal, 0.1000000000000000055511151231257827021181583404541015625) and not the precise and exact rational value of 1/10 (in decimal, 0.1).

    I don't know why raku has made this choice. Anyone ?
    The most annoying thing about it is that it implies that (the rational) 1/10 == (the rational) 3602879701896397/36028797018963968 ... yet raku itself will tell you that isn't so (if you explicitly ask it about that).

    I'm inclined to think that it was done simply to annoy me ... though, somewhere deep inside, I think that even I realize that I'm probably not quite that important ;-)

    Cheers,
    Rob

      Moving on to fractions, when I heard that raku was going to deal with fractions in a clever way, I decided to experiment and write my own module to do fractions. Instead of adulting tonight, I decided to spend a little time fiddling with code.

      Here's my test script:

      #!/usr/bin/perl use strict; use warnings; # OK, try the division of the large numbers using my # Number::MyFraction module. No idea what result I'll get. use lib '../Number-MyFractions/lib'; use Number::MyFraction; { my $long_tenth = Number::MyFraction->new( 3602879701896397, 36028797018963968 ); my $short_tenth = Number::MyFraction->new( 1, 10 ); my $difference = $long_tenth - $short_tenth; print "Compare long tenth: " . ( $long_tenth->decimal_val == .1 ? 'TRUE' : 'FALSE' ) . "\n"; print "Compare short tenth: " . ( $short_tenth->decimal_val == .1 ? 'TRUE' : 'FALSE' ) . "\n"; print "The different is " . $difference->decimal_val . ".\n"; }
      Interestingly, it produced OK results ..
      $ perl 11137153.pl Compare long tenth: TRUE Compare short tenth: TRUE The different is 5.55111512312578e-18. $
      Sure, the difference between the values is non-zero, but comparing the individual fractions to one tenth did work.

      I think it just depends on which tool you use to get the job done.

      Alex / talexb / Toronto

      Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

        First up, I apologise for tainting this thread with that previous post of mine.
        I need to keep in mind that raku was not written for me, but written for a group of people who find that raku suits them, and who are quite happy with what raku provides - and that I have no business complaining about anything that raku does.

        I think it just depends on which tool you use to get the job done.

        I see just 2 ways to compare rationals and doubles:
        1) convert the rational to a double and compare the two doubles;
        or
        2) convert the double to a rational and compare the two rationals.

        The former is probably the easier, and that's the approach that raku takes.
        But, in converting a rational to a double, it is often the case that precision is lost, and the double thus obtained is merely an approximation of the rational value from which it was derived.
        OTOH, every finite double can be represented exactly as a rational - and it therefore makes sense to me that they should be compared via the latter option (like python3 does), as we are then always comparing exact values.
        There's a caveat here in that the numerators/denominators needed to express some doubles can be rather large, and this could be viewed as a dis-incentive to using this second option.

        Perl doesn't have a rational scalar, and C doesn't have a rational data type, so neither of those languages have needed to think about how rationals and floats should be compared.
        (Of course, perl has a core Math::BigRat module in which the overloading of comparision operators needed to be considered.)

        Cheers,
        Rob

      hi rob, from the docs we have:

      Coerces both arguments to Numeric (if necessary); returns True if they are equal.
      > my $x = 1/10; #0.1 > $x.^name; #Rat > my $y = 3602879701896397/36028797018963968; #0.100000000000000006 > $y.^name; #Rat > $x == $y #False (no coercion necessary) > $x == 0.1 #True (no coercion necessary) > $y == 0.1 #False (no coercion necessary) so comparing without coercion works as you expect > 0.1e0.^name; #Num > $x == 0.1e0 #True (coerces $x to Num, then compares) > $y == 0.1e0 #True (coerces $y to Num, then compares) coercion from Rat to Num can result in loss of precision > say $y.nude #(3602879701896397 36028797018963968) > say $y.Num #0.1 coercing this particular Rat to a Num collapses it to 0.1 IIRC the limit of Rat precision is e-14 ish (it gets lumpy), so in the general case it is fair to round away your ...00006 to 0 thus the Num 0.1 maps to both of these Rat options

      your python example does much the same...

      print (Fraction(3602879701896397, 36028797018963968) == 0.1); # True

        Coerces both arguments to Numeric (if necessary)...

        That's an unfortunate choice, IMO.

        coercion from Rat to Num can result in loss of precision

        And that's the reason that I don't like that choice. If instead, the Num was coerced to Rat, then there would be no loss of precision.

        your python example does much the same...

        If that were so, then I think the following python3 one-liner would print "True":
        $ python3 -c 'from fractions import Fraction; print (Fraction(1,10) == + 0.1);' False
        Even though the Fraction (Rat) 1/10 coerces to the float (Num) 0.1e0, python3 still recognizes that the 2 values are not equivalent.

        My only other experience with comparisons between rational types and floating point types is in the mpfr library where, like python3, the comparison is made between the "Rat" (mpq_t) and the exact rational value of the "Num" (mpfr_t) using the mpfr_cmp_q function.
        The gmp library has both a "Num" (mpf_t) and "Rat" (mpq_t) type, but doesn't provide any public functions for directly comparing the 2 types. It's therefore up to the user to come up with the comparison routines.

        Anyway, if raku users are happy with the approach taken then there's not much point in complaining about it.
        (And I haven't yet encountered any raku users that are unhappy with that current approach.)

        Cheers,
        Rob

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://11137153]
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (5)
As of 2021-12-07 03:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    R or B?



    Results (33 votes). Check out past polls.

    Notices?