Re: [perl #69194] rakudo 2009-08 and when with lists
On Sat, Sep 19, 2009 at 6:48 AM, Carl Mäsak cma...@gmail.com wrote:
David (), Moritz (), Aaron ():
2,3 constructs a list. 2..3 also constructs a list, unless it's in a
given/when condition in which case it's just a range.
No. 2..3 is always a range. It's just list context that turns it into a
list.
That seems confusing.
It sounds like the split personality of Ranges strikes again. I still think
it makes more sense to have one Series-only type and one Range-only type,
rather than one Series type and one Range-plus-Series type.
If for no other reason than to contribute a contrasting viewpoint, I'm
not sure I see the problem in this case. A range is an object in Perl
6, in a much more palpable way than in Perl 5. This might be what
causes the mental mismatch for Perl5-ers.
As far as I can see, the range object already is of your proposed
Range-plus-Series type, and when I apply list context to the range, I
get your proposed Series-only type (which happens to be an ordinary
list, but still).
The one thing that worries me about this is how :by fits into it all.
rakudo: given 1.5 { when 1..2 { say 'between one and two' }; say 'not'; };
p6eval rakudo 4b141a: OUTPUT«between one and two»
feels like it makes sense to me. But
rakudo: given 1.5 { when Range.new(from = 1, to = 2, by = 1/3) {
say 'between one and two' }; say 'not'; };
p6eval rakudo 4b141a: OUTPUT«between one and two»
makes me very leery. I know :by isn't actually implemented yet, but
what should it do here when it is?
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
Re: How does List.map: { .say } work?
On Mon, Nov 2, 2009 at 9:53 AM, Moritz Lenz mor...@faui2k3.org wrote:
Hi,
the current spec doesn't allow immutable containers to call .map with a
block that implicitly uses $_ as an implicit parameter.
Here's why:
S06 says
The C$_ variable functions as a placeholder in a block without any
other placeholders or signature. Any bare block without placeholders
really has a parameter like this:
- $_ is rw = OUTER::$_ { .mumble }
So $_ is marked as rw, which is checked at binding time.
Now lists are immutable, meaning that you can't bind a list item rw, so
even if the block doesn't try to modify $_, calling the { .say } block
fails.
(Note that 'for' has the same problem)
How should that be resolved? Should a temporary variable be created that
can be changed, without any effect? or should it fail() on detecting a
modification? Somehow this approach seems very backward to me...
Is there a reason $_ is readonly isn't a possible solution?
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
Re: How does List.map: { .say } work?
On Mon, Nov 2, 2009 at 10:21 AM, Carl Mäsak cma...@gmail.com wrote:
Solomon (), Moritz ():
the current spec doesn't allow immutable containers to call .map with a
block that implicitly uses $_ as an implicit parameter.
Here's why:
S06 says
The C$_ variable functions as a placeholder in a block without any
other placeholders or signature. Any bare block without placeholders
really has a parameter like this:
- $_ is rw = OUTER::$_ { .mumble }
So $_ is marked as rw, which is checked at binding time.
Now lists are immutable, meaning that you can't bind a list item rw, so
even if the block doesn't try to modify $_, calling the { .say } block
fails.
(Note that 'for' has the same problem)
How should that be resolved? Should a temporary variable be created that
can be changed, without any effect? or should it fail() on detecting a
modification? Somehow this approach seems very backward to me...
Is there a reason $_ is readonly isn't a possible solution?
For one thing, then you couldn't do this:
my @a = 1, 2, 3;
for @a {
++$_;
}
I meant, make it readonly if the container being iterated over is
readonly. We're working hard to make the language prefer immutable
things, it seems very odd to short circuit that in a key area like
this...
(Though personally, I would prefer it if map was readonly by default
on all containers.)
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
Re: How does List.map: { .say } work?
On Mon, Nov 2, 2009 at 2:03 PM, Solomon Foster colo...@gmail.com wrote:
On Mon, Nov 2, 2009 at 10:21 AM, Carl Mäsak cma...@gmail.com wrote:
Solomon (), Moritz ():
the current spec doesn't allow immutable containers to call .map with a
block that implicitly uses $_ as an implicit parameter.
Here's why:
S06 says
The C$_ variable functions as a placeholder in a block without any
other placeholders or signature. Any bare block without placeholders
really has a parameter like this:
- $_ is rw = OUTER::$_ { .mumble }
So $_ is marked as rw, which is checked at binding time.
Now lists are immutable, meaning that you can't bind a list item rw, so
even if the block doesn't try to modify $_, calling the { .say } block
fails.
(Note that 'for' has the same problem)
How should that be resolved? Should a temporary variable be created that
can be changed, without any effect? or should it fail() on detecting a
modification? Somehow this approach seems very backward to me...
Is there a reason $_ is readonly isn't a possible solution?
For one thing, then you couldn't do this:
my @a = 1, 2, 3;
for @a {
++$_;
}
I meant, make it readonly if the container being iterated over is
readonly. We're working hard to make the language prefer immutable
things, it seems very odd to short circuit that in a key area like
this...
(Though personally, I would prefer it if map was readonly by default
on all containers.)
Or Larry could just find an elegant way to do it. Yay!
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
Re: r29111 - docs/Perl6/Spec
On Wed, Nov 18, 2009 at 3:33 AM, Darren Duncan dar...@darrenduncan.net wrote: Acknowledging that 'FatRat' is current name for above 'Ratio' ... pugs-comm...@feather.perl6.nl wrote: -For applications that really need arbitrary precision denominators -as well as numerators, CRatio may be used, which is defined as CInt/Int. +For applications that really need arbitrary precision denominators as +well as numerators at the cost of performance, CRatio may be used, +which is stored as CInt/Int, that is, as arbitrary precision in +both parts. There is no literal form for a CRatio, so it must +be constructed using CRatio.new($nu,$de). In general, only math +operators with at least one CRatio argument will return another +CRatio, to prevent accidental promotion of reasonably fast CRat +values into arbitrarily slow CRatio values. Given the above, if one wants to construct a full-precision rational value in terms of 3 Int values analogous to a mantissa and radix and exponent, what is the best way to write it in Perl 6? For example, say I want the following expression to result in a FatRat because presumably that's the only type which will represent the result value exactly: 45207196 * 10 ** -37 How should that be spelled out in terms of 3 integers? And note that a decimal-specific answer isn't what I want, since I want something that would also work for this: 45207196 * 11 ** -37 Any thoughts? Basically where I'm coming from here is the idea that any rational can also be expressed as 3 integers like the above, not just the numerator/denominator pair; the 3 integers are advantages both for being efficient with common pathological cases such as very large or very small rationals with a small amount of precision, such as the above, as well as for exactly reflecting the concept of a radix-agnostic floating-point number. What's your objection to FatRat.new(45207196, 11 ** 37)? -- Solomon Foster: colo...@gmail.com HarmonyWare, Inc: http://www.harmonyware.com
Re: Custom errors on subsets?
On Tue, Jan 5, 2010 at 11:18 AM, Ovid
publiustemp-perl6langua...@yahoo.com wrote:
--- On Tue, 5/1/10, Jonathan Scott Duff perlpi...@gmail.com wrote:
From: Jonathan Scott Duff perlpi...@gmail.com
I'd imagine that the functionality will fall
out of the ability to have nice failures because surely
something like the following works now:
subset Filename of Str where { $_ ~~ :f or
fail No such file: '$_' }
Perhaps s/fail/die/, but that seems like a means
to your desired end.
Ah, the die works fine. However, fail causes that sub call to be skipped
altogether:
subset Filename of Str where { $_ ~~ :f or fail $_ is not a filename };
sub foo (Filename $name) {
say Houston, we have a filename: $name;
}
foo($*EXECUTABLE_NAME);
say before;
foo('no_such_file');
say after;
Output:
Houston, we have a filename: /Users/ovid/bin/perl6
before
after
Is this a bug or just documented behavior that I don't know about?
fail just returns an uncalled exception. What does that do in a where block?
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
Re: Custom errors on subsets?
On Tue, Jan 5, 2010 at 11:36 AM, Ovid publiustemp-perl6langua...@yahoo.com wrote: --- On Tue, 5/1/10, Solomon Foster colo...@gmail.com wrote: From: Solomon Foster colo...@gmail.com Is this a bug or just documented behavior that I don't know about? fail just returns an uncalled exception. What does that do in a where block? I knew it returned an uncalled exception, but I'm still not expecting the sub call to be skipped silently due to a constraint failure. Silent failures are bad :) Good point. :) -- Solomon Foster: colo...@gmail.com HarmonyWare, Inc: http://www.harmonyware.com
Re: One-pass parsing and forward type references
On Mon, Feb 1, 2010 at 3:46 PM, Patrick R. Michaud pmich...@pobox.com wrote:
On Mon, Feb 01, 2010 at 05:55:47PM +0100, Carl Mäsak wrote:
Is it allowed to do 'class B { ... }' several times in different files
before finally declaring the real B? If so, then I'd consider it
equivalent to my proposed keyword, and thus there'd be no need for the
latter.
Yes. And declaring the real B doesn't have to be final, nor
does it have to occur at all (as long as none of the features needed
from B are ever needed).
And just to finish it off... are you allowed to do 'class B { ... }'
even after declaring the real B?
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
Re: Something about the cascade calling of sort() in rakudo.
2010/3/23 Moritz Lenz mor...@faui2k3.org:
Hi,
Hongwen Qiu wrote:
Hi, I'm new to Perl6. And just ran the first example in the perl6 book.
But, it refused to work. It complains as follows:
Too many positional parameters passed; got 2 but expected between 0 and 1
I find out that the problem is in the line:
my @sorted = @names.sort({ %sets{$_} }).sort({ %games{$_} }).reverse;
And I tried eliminate the second sort, or just the parameters in the
second sort. In both cases, it works.
So, why is this happen? Can it be a bug?
Yes. Thank you for your report.
Rakudo has gone through a major rewrite, and in that process some of the
features have temporarily disappeared. .sort() with a block accepting
just one parameter is one of these features.
Actually, as we just determined on #perl6, it works normally, and only
fails under certain conditions -- basically when you get a low-level
collection of things rather than something based on the Perl 6 Seq or
Iterator classes. So there is a fairly simple workaround:
colomon: rakudo: say (-5...10).sort({.abs}).sort({.abs}).perl
p6eval: rakudo db0f85: OUTPUT«Too many positional parameters passed;
got 2 but expected between 0 and 1current instr.: '_block68' pc -1
((unknown file):-1)»
colomon: rakudo: say (-5...10).sort({.abs}).Seq.sort({.abs}).perl
p6eval: rakudo db0f85: OUTPUT«(0, -1, 1, -2, 2, -3, 3, -4, 4, -5, 5,
6, 7, 8, 9, 10)»
That is, adding a .Seq between the two sorts clears up the problem.
That is admittedly a hack, but it is a simple one.
Thanks for reporting the problem!
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
Announce: Rakudo Perl 6 development release #29 (Erlangen)
On behalf of the Rakudo development team, I'm pleased to announce the
May 2010 development release of Rakudo Perl #29 Erlangen.
Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine
(see http://www.parrot.org). The tarball for the May 2010 release
is available from http://github.com/rakudo/rakudo/downloads .
Rakudo Perl follows a monthly release cycle, with each release named
after a Perl Mongers group. The May 2010 release is code named
Erlangen in recognition of Erlangen.pm and the Perl 6 talk that Moritz
Lenz, one of our core developers, gave this month.
Some of the specific changes and improvements occurring with this
release include:
* Lexical classes and roles were implemented. Additionally, anonymous classes
-- which were never quite right in alpha -- are now implemented more
correctly, and anonymous roles are also supported.
* Basic support for named enumerations of the form 'enum Weekday Monday
Tuesday ...' has been restored.
* First cut of use Foo:fromperl5 and eval('foo', :langperl5); needs
Blizkost[1] to be installed to work.
* Numeric / Real roles much closer to the spec now.
* As always, many additional small features and bug fixes make working with
Rakudo more pleasant.
* Rakudo now passes 32,347 spectests. We estimate that there are about
39,500 tests in the test suite, so Rakudo passes about 82% of all tests.
For a more detailed list of changes see docs/ChangeLog.
The development team thanks all of our contributors and sponsors for
making Rakudo Perl possible, as well as those people who worked on parrot, the
Perl 6 test suite and the specification.
The following people contributed to this release:
Solomon Foster, Moritz Lenz, Jonathan Worthington, Martin Berends,
chromatic, Carl Masak, snarkyboojum, Stefan O'Rear, Reini Urban,
Jonathan Scott Duff, takadonet, Christoph Otto, isBEKaml,
ash_, bubaflub, Jimmy Zhuo, Peter Lobsinger and Patrick Abi Salloum
If you would like to contribute,
see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org
mailing list, or ask on IRC #perl6 on freenode.
The next release of Rakudo (#30) is scheduled for June 17, 2010.
A list of the other planned release dates and code names for 2010 is
available in the docs/release_guide.pod file. In general, Rakudo
development releases are scheduled to occur two days after each
Parrot monthly release. Parrot releases the third Tuesday of each month.
Have fun!
[1] http://github.com/jnthn/blizkost
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
Re: r31050 -[S03] refine hyper dwimminess to be more like APL, with modular semantics
On Wed, Jun 2, 2010 at 3:52 PM, Aaron Sherman a...@ajs.com wrote: Is there some automatic translation of these examples into tests? If not, here's what they'd be: ok(( (1,2,3,4) «+» (1,2) ) ~~ (2,4,4,6) ) ok(( (1,2,3) «+» (1,2) ) ~~ (2,4,4) ) ok(( (1,2,3,4) «+« (1,2) ) ~~ (2,4) ) ok(( (1,2,3,4) »+» (1,2) ) ~~ (2,4,4,6) ) ok(( (1,2,3) »+» (1,2) ) ~~ (2,4,4,6) ) ok(( (1,2,3) »+» 1 ) ~~ (2,4,4,6) ) I tested these all with Rakudo, and they all currently fail, though I guess that's not shocking. ~~ (2, 4, 4) (for example) isn't actually supposed to work, is it? Certainly doesn't work in Rakudo and I've never seen a spectest written like that... -- Solomon Foster: colo...@gmail.com HarmonyWare, Inc: http://www.harmonyware.com
Re: Suggested magic for a .. b
On Tue, Jul 20, 2010 at 7:31 PM, Aaron Sherman a...@ajs.com wrote:
2) We deny that a range whose LHS is larger than its RHS makes sense, but
we also don't provide an easy way to construct such ranges lazily otherwise.
This would be annoying only, but then we have declared that ranges are the
right way to construct basic loops (e.g. for (1..1e10).reverse - $i {...}
which is not lazy (blows up your machine) and feels awfully clunky next to
for 1e10..1 - $i {...} which would not blow up your machine, or even make
it break a sweat, if it worked)
Ranges haven't been intended to be the right way to construct basic
loops for some time now. That's what the ... series operator is
for.
for 1e10 ... 1 - $i {
# whatever
}
is lazy by the spec, and in fact is lazy and fully functional in
Rakudo. (Errr... okay, actually it just seg faulted after hitting
968746 in the countdown. But that's a Rakudo bug unrelated to
this, I'm pretty sure.)
All the magic that one wants for handling loop indices -- going
backwards, skipping numbers, geometric series, and more -- is present
in the series operator. Range is not supposed to do any of that stuff
other than the most basic forward sequence.
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
Re: Suggested magic for a .. b
On Tue, Jul 20, 2010 at 10:00 PM, Jon Lang datawea...@gmail.com wrote:
Solomon Foster wrote:
Ranges haven't been intended to be the right way to construct basic
loops for some time now. That's what the ... series operator is
for.
for 1e10 ... 1 - $i {
# whatever
}
is lazy by the spec, and in fact is lazy and fully functional in
Rakudo. (Errr... okay, actually it just seg faulted after hitting
968746 in the countdown. But that's a Rakudo bug unrelated to
this, I'm pretty sure.)
You took the words out of my mouth.
All the magic that one wants for handling loop indices -- going
backwards, skipping numbers, geometric series, and more -- is present
in the series operator. Range is not supposed to do any of that stuff
other than the most basic forward sequence.
Here, though, I'm not so sure: I'd like to see how many of Aaron's
issues remain unresolved once he reframes them in terms of the series
operator.
Sorry, didn't mean to imply the series operator was perfect. (Though
it is surprisingly awesome in general, IMO.) Just that the right
questions would be about the series operator rather than Ranges.
The questions definitely look different that way: for example,
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz is easily and
clearly expressed as
'A' ... 'Z', 'a' ... 'z' # don't think this works in Rakudo yet :(
That suggests to me that the current behavior of 'A' ... 'z' is pretty
reasonable.
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
On Sun, Nov 7, 2010 at 11:19 PM, Jon Lang datawea...@gmail.com wrote: Mason Kramer wrote: I'd like to anticipate one objection to this - the existence of the 'hyper' operator/keyword. The hyper operator says, I am taking responsibility for this particular code block and promising that it can execute out of order and concurrently. Creating a Bag instead of an Array says, there is no meaning to the ordering of this group of things, ever. Basically, if I know at declaration time that my collection has no sense of ordering, then I shouldn't have to annotate every iteration of that collection as having no sense of ordering, which is nearly what hyper does (though, I readily admit, not quite, because there are unordered ways to create race conditions). My understanding of the hyperoperator is that its primary use is to say operate on the individual elments of this collection, instead of on the collection itself. In that regard, it's just as applicable to Bags and Sets as it is to lists. Except... Except that the hyperoperator assumes that the collections are ordered. It matches the first element on the left with the first element on the right; the second element on the left with the second on the right; and so on. Bags and Sets don't have a useful notion of first, second, etc. So what should happen if I try to apply a hyperoperator with a Bag or Set on one side? Well, hyperoperators work fine on Hashes, they operate on the values, paired up by key if needed. (That is, %hash++ doesn't care about the keys, %hash1 + %hash2 sums based on keys.) I would assume that Bag should work in the exact same way. Dunno how Set should work in this context, though. -- Solomon Foster: colo...@gmail.com HarmonyWare, Inc: http://www.harmonyware.com
Re: How to make a new operator.
On Wed, Mar 21, 2012 at 7:52 PM, Daniel Carrera dcarr...@gmail.com wrote:
* = $b --- this determines where the sequence ends: when the current value
is greater or equal to $b.
So... after the ... you have an anonymous function that has to
return 'True' for the sequence to end? Seems strange, but it works:
# A function that always returns True = List of one item.
2,5...True
2
It actually smartmatches whatever is on the right hand side against
the sequence, and stops when the smartmatch returns True. It just
happens that you smartmatch an anonymous function, it executes the
function and returns its result.
In particular, note that True there is not an anonymous function, it's
just the value True. You'd need to say { True } to get an anonymous
function which returns True.
Examples:
2, 5 ... 11 # smartmatch is true when you hit 11
2, 5 ... True # stop right away
2, 5 ... False # never stop
2, 5 ... * # shorter way of saying never stop
2, 1, 1/2 ... Num # stop when the number switches from a Rat to a Num
'a' ... /f/ # stop when the regular expression matches
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
Re: [perl6/specs] 5277fe: Add expmod and is-prime as built-ins in Int
On Mon, Sep 24, 2012 at 10:09 AM, Richard Nuttall richard.nutt...@pirum.com wrote: A quick search throws up http://primes.utm.edu/prove/prove2_3.html Which says that for/n/ 341,550,071,728,321 it is enough to test 2, 3, 5, 7, 11, 13 and 17 to be definitive (and fewer specific tries for smaller n) That also verifies the 75/25 figures mentioned below. So, depending on the implementation, the documentation should be able to be explicit about how accurate it is. Niecza's implementation of is-prime already takes advantage of this, and my understanding of Rakudo's implementation is that it always tests against the first 256 primes, so it also takes advantage of this in correctness, if possibly not in speed. -- Solomon Foster: colo...@gmail.com HarmonyWare, Inc: http://www.harmonyware.com
Re: Are set operations needed?
All set operations work on Rakudo, but none of the Unicode set operators are enabled, because multibyte Unicode characters kill the performance of Rakudo's parser when compiling Rakudo. So for example you can use (|) for set union, but not ∪. I think there are probably some glitches there yet, particularly with set construction -- Rakudo's version is based on an older version of Niecza's implementation. I'll probably get around to porting Niecza's updates over to Rakudo before the August release. On Thu, Jul 18, 2013 at 11:21 AM, Richard Hainsworth rich...@rusrating.ru wrote: I'm well behind the curve on implementation, this I know. But before writing the email, I checked the perl6 web site on what was implemented. Set operations still given as not implemented. The impression I formed was that set operations would be a long time coming - even after Christmas. What subset is implemented (perhaps better, where is this documented). Richard On 07/18/2013 07:16 PM, Moritz Lenz wrote: On 07/18/2013 01:07 PM, Richard Hainsworth wrote: Are set operations needed in Perl6? No implementation of the perl6 set specification yet exists (AFAIK). You are wrong. Both rakudo and niecza implement significant subsets of the set specification. Cheers, Moritz -- Solomon Foster: colo...@gmail.com HarmonyWare, Inc: http://www.harmonyware.com
Re: Are set operations needed?
Full list of Texas (ie ASCII) set operators: union: (|) intersection: () set difference: (-) symmetric difference: (^) subset: (=) proper subset: () superset: (=) proper superset: () is an element of: (elem) is contained by: (cont) On Thu, Jul 18, 2013 at 11:45 AM, Solomon Foster colo...@gmail.com wrote: All set operations work on Rakudo, but none of the Unicode set operators are enabled, because multibyte Unicode characters kill the performance of Rakudo's parser when compiling Rakudo. So for example you can use (|) for set union, but not ∪. I think there are probably some glitches there yet, particularly with set construction -- Rakudo's version is based on an older version of Niecza's implementation. I'll probably get around to porting Niecza's updates over to Rakudo before the August release. On Thu, Jul 18, 2013 at 11:21 AM, Richard Hainsworth rich...@rusrating.ru wrote: I'm well behind the curve on implementation, this I know. But before writing the email, I checked the perl6 web site on what was implemented. Set operations still given as not implemented. The impression I formed was that set operations would be a long time coming - even after Christmas. What subset is implemented (perhaps better, where is this documented). Richard On 07/18/2013 07:16 PM, Moritz Lenz wrote: On 07/18/2013 01:07 PM, Richard Hainsworth wrote: Are set operations needed in Perl6? No implementation of the perl6 set specification yet exists (AFAIK). You are wrong. Both rakudo and niecza implement significant subsets of the set specification. Cheers, Moritz -- Solomon Foster: colo...@gmail.com HarmonyWare, Inc: http://www.harmonyware.com -- Solomon Foster: colo...@gmail.com HarmonyWare, Inc: http://www.harmonyware.com
Re: Grammars and biological data formats
On Sat, Aug 9, 2014 at 7:26 PM, Fields, Christopher J cjfie...@illinois.edu wrote: I have a fairly simple question regarding the feasibility of using grammars with commonly used biological data formats. My main question: if I wanted to parse() or subparse() vary large files (not unheard of to have FASTA/FASTQ or other similar data files exceed 100’s of GB) would a grammar be the best solution? For instance, based on what I am reading the semantics appear to be greedy; for instance: Grammar.parsefile($file) appears to be a convenient shorthand for: Grammar.parse($file.slurp) since Grammar.parse() works on a Str, not a IO::Handle or Buf. Or am I misunderstanding how this could be accomplished? My understanding is it is intended that parsing can work on Cats (hypothetical lazy strings) but this hasn't been implemented yet anywhere. -- Solomon Foster: colo...@gmail.com HarmonyWare, Inc: http://www.harmonyware.com
Re: Rationalizing numeric types
Yary, There already is a Perl 6 continue fractions module. Spoiler alert: it doesn't work in the least. But I'd be happy to give you a commit bit. I don't think we should even begin to think about including something like that in the Perl 6 core before we have a complete, working implementation in a module. Frankly, I'm much more concerned with making the math functions we already have support the types we already have. For instance, right now most such operations use standard floating point doubles under the hood. The exact range of Ints and Rats vastly exceeds that of doubles, so this means that (at least in theory) there are perfectly good mathematical answers we could return that we're not. So, for instance, according to Wolfram Alpha, ln(3 * 10 ** 500) = 1152.391158785690951700390972579104629505198234872209237468398... On the other hand, if I give Rakudo that same problem (switch ln to log), we get Inf, because 3 * 10 ** 500 cannot be presented as a double. That said, I'm not terrible concerned about that problem, either. But if you were hankering for a Perl 6 math problem to work on, IMO it would be a much better one than trying to exactly represent irrational numbers. On Mon, Jun 22, 2015 at 1:41 PM, yary not@gmail.com wrote: Thinking over my programming career, there were a few occasions I had to spend time working around floating point errors, and it was a nuisance. There were even fewer times when I worked with transcendental numbers- programs dealing with geometry or tones or logarithmic scales- and those times, floating point was good enough. Which is to say, Perl 6's Rats would have solved my nuisance issues, and I would not have appreciated exact types for irrational numbers in my tasks to date. Still, I couldn't resist thinking about them and web-searching on them a bit more, and here's my brain-dump. Periodic continued fractions https://en.wikipedia.org/wiki/Continued_fraction can represent any quadratic root http://www.millersville.edu/~bikenaga/number-theory/periodic-continued-fractions/periodic-continued-fractions.html. Haskel has this package implementing a quadratic irrational type https://hackage.haskell.org/package/quadratic-irrational-0.0.2/docs/Numeric-QuadraticIrrational.html, and it can translate between those and continued fractions. ... here is a decent intro to continued fractions http://www.maths.surrey.ac.uk/hosted-sites/R.Knott/Fibonacci/cfINTRO.html . That's a comprehensive answer for square roots of rationals, but not for transcendental numbers http://sprott.physics.wisc.edu/pickover/trans.html. My math is not so hot, but perhaps a generalized continued fraction https://en.wikipedia.org/wiki/Generalized_continued_fraction type could perfectly represent transcendental constants like pi and e, with trig and log/exponentiation functions using them. Then Perl 6 could get this famous relationship *exactly right*: say 1 + e ** (pi * i) ... though I suspect it really does take a symbolic math package to get all combinations of the trig exponential functions right https://cloud.sagemath.com/projects/3966ff36-7109-449d-83a9-49e48e078fea/files/2015-06-22-133206.sagews . -y -- Solomon Foster: colo...@gmail.com HarmonyWare, Inc: http://www.harmonyware.com
Re: (default) Real->Rat precision should match what compiler uses for literals
On Sun, Mar 4, 2018 at 8:49 AM, yary <not@gmail.com> 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 1159028911097599180468360808563945281389781327557747838772170381060813469985856815104). 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 (1159028911097599180468360808563945281389781327557747838772170381060813469985856815104 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
Re: (default) Real->Rat precision should match what compiler uses for literals
On Sat, Mar 3, 2018 at 3:32 PM, yary <not@gmail.com> wrote: > Or instead of 1/2**(32 or 64), re-asking these questions about epsilon: > > " Why so large? > >Why not zero? " > > What's justification for using 1/100,000 vs. something smaller vs. 0 "max > possible precision?" > The problem with using max possible precision is that you will generate a Rat with a large denominator. And when you start doing math with those, the results will usually flip back over to Nums pretty quickly. But if you went through the trouble of converting your number from a Num to a Rat, presumably it's because you wanted to work with Rats, so ending up with a Num again is a frustrating result. I don't remember if I was responsible for 1e-6 as the epsilon or not, but it's quite possible it was me, because in my experience that number is a common 3D tolerance in CAD software (I believe it's the default in ACIS) and I tend to grab it for that purpose. My intuition is that the number should probably be between 1e-6 and 1e-8, but it would be great if someone wanted to put in some research/testing to figure out a better value. It's important to remember that the purpose of Rat in p6 is to dodge around the common pitfalls of floating point numbers in casual use, while degrading to Num to prevent your calculations from crawling to a halt when the denominator gets too big. For real world measures, a double's 15 digits of accuracy is normally overkill. (If I'm doing the math right, if you had a CAD model of the second Death Star in meters, 15 digits would allow you to specify dimensions to the nanometer.) If you actually need unbounded precision, then you should be using FatRats. One thing I think we absolutely should have is a quick and easy way to convert from Num to FatRat with minimal loss of precision. I believe right now the default Num -> FatRat conversion also uses 1e-6 as an epsilon, which seems wrong to me. -- Solomon Foster: colo...@gmail.com HarmonyWare, Inc: http://www.harmonyware.com
