Re: (default) Real->Rat precision should match what compiler uses for literals

[yary]

I want an epsilon that doesn't confuse newbies and which also is efficient.
epsilon=1/2**(mantissa bits-1) fits the bill.

Why I want this-  It would be great to have numbers survive round-trip
conversions, when feasible.

Specifically I have no need to compare Rats and Nums for equality, but I do
often deal with "flat" text files full of metrics, and remotely sourced
json, and XML. The data types are sometimes unexpected.

-y

On Wed, Mar 7, 2018 at 5:16 PM, Solomon Foster  wrote:

> On Sun, Mar 4, 2018 at 8:49 AM, yary  wrote:
>
>> In that spirit, I'd expect numeric comparison in general, and epsilon
>> specifically, to be set so these return True:
>>
>> > pi == pi.Rat # Does Num to Rat conversion keep its precision?
>> False
>> > pi.Str.Num == pi # Does Num survive string round-trip? - Nothing to do
>> with epsilon
>> False
>>
>>
> Why on earth would you want to do this?
>
> I mean that quite literally.  The only reason I can see for directly
> comparing a Num and a Rat for equality is to check and see if the Rat has
> the same precision as the Num.  In practice, it's well-known you generally
> shouldn't use equality tests on floating point numbers.  Converting one
> side of the equation to a Rat just makes it make even less sense.
>
>
> I've just been playing around with Num to Rat conversion, and here are
> some quick notes.
>
> 1) You can pass 0 as the epsilon for the Rat constructor, which seems to
> be equivalent to very very small values of epsilon.
>
> 2)  pi.Rat(0) + exp(1).Rat(0) is a Rat, but pi.Rat(0) + exp(1).Rat(0) +
> sin(.2).Rat(0) is a Num.  (On the other hand, pi.Rat() + exp(1).Rat() +
> sin(.2).Rat() is still a Rat.)
>
> 3) Remember (I had forgotten!) that Nums can represent numbers much
> smaller than a Rat can.  1e-100 is a perfectly reasonable Num, but (were
> Rat behaving properly) the closest possible Rat value is 0.
>
> 4) That said, if you actually do (1e-100).Rat(0), it gives you (1
> 11590289110975991804683608085639452813897813
> 27557747838772170381060813469985856815104).  Needless to say, that's not
> actually a legal Rat.  Surprisingly (to me, anyway) it is accurate to
> better than 1e-110.
>
> 5) Somewhat more distressingly, (1e+100).Rat gives you (
> 11590289110975991804683608085639452813897813
> 27557747838772170381060813469985856815104 1).  That's only accurate to
> 10**83.  Which is to say, it's as accurate as a double gets -- 16-17
> digits.   (BTW, that is a legal Rat.)
>
> I admit don't really know what to do with this.
>
> --
> Solomon Foster: colo...@gmail.com
> HarmonyWare, Inc: http://www.harmonyware.com
>

[perl #132980] Coercion type apparently does not check the actual type of the coerced value

[Zoffix Znet via RT]

On Wed, 14 Mar 2018 14:16:06 -0700, comdog wrote:
> I was playing with coercion types and wondered what would happen if
> a .Int method did not return the right sort of type:
> 
> class Foo {
> method Int ( --> Str ) { 'Hello' }
> }
> 
> put try-it( Foo.new );
> 
> sub try-it ( Int() $n ) { "Got <$n> of type <{$n.^name}>" }
> 
> Although the subroutine signature demanded an Int, it accepted
> something that claimed to be able to convert but actually didn't:
> 
> Got  of type 
> 
> I would have expected the runtime constraint to check the ultimate
> value against the type and this would have failed.
> 
> 

Thanks for the report.

We'll likely want to extend the features of the coercers, and include the return
type check, but not until 6.e or later language versions, when we have some
headroom with respect to performance.

I've documented[^1] that no check is currently performed on the result and there
are some extra proposed spec[^2] for coercers marked for 6.d review already, so 
I'll mark
this ticket as resolved. (though given 6.d is on already the horizon, the check 
of return
type would likely not make it into 6.d). The other feature we'd want to 
eventually implement
is coercing via `Target.new(Source)`, if not `Source.Target` method exists.

I've tried[^3] implementation[^4] of checking the final result in January and it
dropped performance of coercers by 8%. Given the marginal benefit offered by the
fix, we just can't afford to spend a 8% drop in a common feature at the moment.
So currently, it's just a "verbal" contract that method Foo returns object Foo,
similar how to `sub _foo` is a private method in Perl 5 by convention, despite 
it being public.

[1] https://github.com/perl6/doc/commit/ee34834195
[2] https://github.com/perl6/roast/blob/master/S12-coercion/coercion-types.t
[3] https://irclog.perlgeek.de/perl6-dev/2018-01-07#i_15661357
[4] https://gist.github.com/zoffixznet/6d0a2085bd343535b99f548d15547729

[perl #132980] Coercion type apparently does not check the actual type of the coerced value

[Zoffix Znet via RT]

On Wed, 14 Mar 2018 14:16:06 -0700, comdog wrote:
> I was playing with coercion types and wondered what would happen if
> a .Int method did not return the right sort of type:
> 
> class Foo {
> method Int ( --> Str ) { 'Hello' }
> }
> 
> put try-it( Foo.new );
> 
> sub try-it ( Int() $n ) { "Got <$n> of type <{$n.^name}>" }
> 
> Although the subroutine signature demanded an Int, it accepted
> something that claimed to be able to convert but actually didn't:
> 
> Got  of type 
> 
> I would have expected the runtime constraint to check the ultimate
> value against the type and this would have failed.
> 
> 

Thanks for the report.

We'll likely want to extend the features of the coercers, and include the return
type check, but not until 6.e or later language versions, when we have some
headroom with respect to performance.

I've documented[^1] that no check is currently performed on the result and there
are some extra proposed spec[^2] for coercers marked for 6.d review already, so 
I'll mark
this ticket as resolved. (though given 6.d is on already the horizon, the check 
of return
type would likely not make it into 6.d). The other feature we'd want to 
eventually implement
is coercing via `Target.new(Source)`, if not `Source.Target` method exists.

I've tried[^3] implementation[^4] of checking the final result in January and it
dropped performance of coercers by 8%. Given the marginal benefit offered by the
fix, we just can't afford to spend a 8% drop in a common feature at the moment.
So currently, it's just a "verbal" contract that method Foo returns object Foo,
similar how to `sub _foo` is a private method in Perl 5 by convention, despite 
it being public.

[1] https://github.com/perl6/doc/commit/ee34834195
[2] https://github.com/perl6/roast/blob/master/S12-coercion/coercion-types.t
[3] https://irclog.perlgeek.de/perl6-dev/2018-01-07#i_15661357
[4] https://gist.github.com/zoffixznet/6d0a2085bd343535b99f548d15547729

[perl #130883] problem with RESOURCES and PERL6LIB env variable

[Jan-Olof Hendig via RT]

On Mon, 17 Jul 2017 10:50:55 -0700, ug...@cpan.org wrote:
> The %?RESOURCES bug was fixed in: https://github.com/rakudo/rakudo/pull/1106

ugexe, does that mean that the issue can be marked as resolved?

[perl #131790] [BUG] :delete silently fails on lazy Arrays

[Jan-Olof Hendig via RT]

On Mon, 24 Jul 2017 09:09:55 -0700, c...@zoffix.com wrote:
> m: my @a is default(42) = 1...*; @a[1]:delete; say @a[1]:exists; .say
> for @a[^10]
> rakudo-moar 2fb8c7: OUTPUT: «True␤1␤2␤3␤4␤5␤6␤7␤8␤9␤10␤»
> 
> Expected: reify until `1`, delete it, and have `@a[1]:exists` give
> False, and `.say for @a[^10]` give 42 for the second element.

This was fixed with commit 
https://github.com/rakudo/rakudo/commit/0385b2aa4554eca1421081968642a43f883889cd
Test was added with commit 
https://github.com/perl6/roast/commit/9cc47b28a9f4c7a6256a8521080620a50bed75a8

[perl #132980] Coercion type apparently does not check the actual type of the coerced value

[brian d foy]

# New Ticket Created by  "brian d foy" 
# Please include the string:  [perl #132980]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132980 >


I was playing with coercion types and wondered what would happen if
a .Int method did not return the right sort of type:

class Foo {
method Int ( --> Str ) { 'Hello' }
}

put try-it( Foo.new );

sub try-it ( Int() $n ) { "Got <$n> of type <{$n.^name}>" }

Although the subroutine signature demanded an Int, it accepted
something that claimed to be able to convert but actually didn't:

Got  of type 

I would have expected the runtime constraint to check the ultimate
value against the type and this would have failed.


-- 
brian d foy 
http://www.pair.com/~comdog/

[perl #128512] [BUG] utf8-c8 mangles by NFC

[Jan-Olof Hendig via RT]

On Sun, 26 Feb 2017 23:01:18 -0800, zef...@fysh.org wrote:
> This problem no longer occurs.
> 
> -zefram
> 

Fixed with commit (2017-01-02) 
https://github.com/rakudo/rakudo/commit/7c8b705b3375522fc36304b771f82f50246afcf0

[perl #128511] [BUG] utf8-c8 generates spurious NUL

[Jan-Olof Hendig via RT]

On Sun, 26 Feb 2017 23:02:00 -0800, zef...@fysh.org wrote:
> This problem no longer occurs.
> 
> -zefram
> 

This was fixed with commit (2017-01-02) 
https://github.com/rakudo/rakudo/commit/7c8b705b3375522fc36304b771f82f50246afcf0

[perl #124057] [SEGV] Proxy class attribute interaction segfaults

[Ron Schmidt via RT]

When I run this example now (Windows and Linux) I get:

P6opaque: no such attribute '$!encoded-string' on type Codeword in a Proxy when 
trying to get a value

instead of a segfault.  If I tweak the code as below to use subs instead of 
methods for the Proxy hooks it runs fine.  The P6opaque error seems reminiscent 
of a recent IRC conversation: 
https://irclog.perlgeek.de/perl6/2018-03-03#i_15879434 .  Between the IRC 
conversation and making it work by switching to subs I suspect it might be OK 
to merge this ticket with RT 126198 .

## codeword.p6

class Codeword {
has Sub $.scrambler is rw;
has $!string;
has Str $!encoded-string;

submethod BUILD {
my sub scrambler { $^s.trans: 'a..mn..z' => 'n..za..m', :ii }
$!scrambler = 
}

method codeword returns Str is rw {
return Proxy.new(
FETCH => sub ($)  { $!encoded-string },
STORE => sub ($,$s){ $!encoded-string = $!scrambler($s) }
);
}
}

my $code = Codeword.new;
$code.codeword;
$code.codeword = 'abc';
say $code.codeword;

> prints
nop