Re: RFC 237 (v1) hashes should interpolate in double-quoted strings
On Sun, 17 Sep 2000 21:59:47 -0700, Nathan Wiger wrote:
Yeah, I for one think %hashes should be interpolated exactly like
@arrays. It's simple and consistent.
Simple and consistent would be behaviour like
"@{[%hash]}"
However, convenient it is not, getting all key/value pairs in one row.
It's not what was proposed, anyway.
--
Bart.
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Hi Ilya, I have three questions about your RFC: Firstly does your proposal allow for a slice like 10..20:2 (i.e. with a stride of 2) ? If not is there an easy way to incorporate that? Secondly, what about having multidim support in the core so that the tie-tokenisers get optimised away? i.e. would we be able to say something like: @x = @y[10..20; 1..3] for core arrays Finally as an overload expert what do you think about the proposals to make arrays overloadable objects so one can say things like: @x = 3 * @y; Katl
Re: RFC 237 (v1) hashes should interpolate in double-quoted strings
Chaim Frenkel writes:
What about formating the output as a value that can be used by eval?
%hash = (a = 1, b = 'the world');
print "%{hash}\n";
('a' = 1, 'b'= 'the world')
Interesting.
And as for having to escape % in printf strings. Why not enable the
interpolation if the %{ is seen?
Too inconsistent. People often write dollar amounts, but we don't
only enable scalar interpolation for ${varname}.
Nat
Re: RFC 237 (v1) hashes should interpolate in double-quoted strings
On 17 Sep 2000 23:54:05 -0400, Chaim Frenkel wrote:
What about formating the output as a value that can be used by eval?
%hash = (a = 1, b = 'the world');
print "%{hash}\n";
('a' = 1, 'b'= 'the world')
So, what about arrays? Or scalars?
We have Data::Dumper for that.
--
Bart.
Re: RFC 246 (v1) pack/unpack uncontrovercial enhancements
How about a Base64 to match with uuencode? chaim "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL =head1 ABSTRACT PRL This RFC proposes simple enhancements to templates of pack/unpack builtins. PRL These enhancements do not change the spirit of how pack/unpack is used. PRL The semantic is enhanced as much as possible under this constaint. PRL Additional changes to pack/unpack are listed in other proposals. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 246 (v1) - RFC 250 pack/unpack enhancements
Michael G Schwern writes: RFC 142 may help out existing un/pack users, but does nothing to help in the understanding of un/pack by native speakers of Perl. I'm starting to think this is largely a documentation issue. Yes. Please put this thread out of our collective misery. Nat
Re: RFC 246 (v1) - RFC 250 pack/unpack enhancements
Michael G Schwern wrote: RFC 142 may help out existing un/pack users, but does nothing to help in the understanding of un/pack by native speakers of Perl. I'm starting to think this is largely a documentation issue. The existing documentation of pack/unpack is terse, and assumes a knowledge of "other language" data layouts. I think everyone can agree on that. The need for pack/unpack is mostly to coexist with those other languages' data structures. If you know the other language, pack/unpack becomes less obscure. If you don't, it doesn't. So maybe a good part of that is a documentation issue. Another use of pack/unpack could be to [re]store Perl data in binary form, which can sometimes be smaller than ASCII form (source that can be eval'd). For this purpose, non-other-language-knowledge documentation would be extremely helpful. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Finally as an overload expert what do you think about the proposals to make arrays overloadable objects so one can say things like: @x = 3 * @y; Is this where RFC 231's suggestion for OO slicing comes in (see quote)? For example, $matrix1-[2..5; 2..4] * $matrix2-[1,3,5; 11..64]; would denote: create two new objects for the specified submatrices, apply (overloaded) multiplication to these objects. Such a request is illegal for untie()d arrays; for tie()d arrays it is converted to a call to FETCH_SLICE in a scalar context. (Alternative: introduce two new tie()d methods: FETCH_SUBOBJECT, STORE_SUBOBJECT.) or is this supposed to be othogonal? Another questing re RFC 231. Is it really required to make the syntactical distinction between ranges (..) and bi_ranges (...)? Some more explanation would be appreciated. Christian
RFC 148 (v2) Add reshape() for multi-dimensional array reshaping
=head1 VERSION Reply-To: [EMAIL PROTECTED] This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Add reshape() for multi-dimensional array reshaping =head1 VERSION Maintainer: Nathan Wiger [EMAIL PROTECTED] Date: 24 Aug 2000 Last Modified: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 148 Version: 2 Status: Developing =head1 CHANGES 1. Altered syntax to increase flexibility 2. Removed arbitrary interleaving feature 3. Almost had a stroke trying to update all my RFC's =head1 ABSTRACT Currently, there is no easy way to reshape existing arrays into multiple arrays or matrices. This makes nifty array manipulation and complex math hard. A general-purpose tool that can do arbitrary multi-dimensional array reshaping, from which other array manipulation functions can be derived, makes data manipulation easier. =head1 DESCRIPTION Let's jump in. This RFC proposes a Creshape builtin with the following syntax: @reshaped = reshape [$x, $y, $z, ..], @a, @b ... The prototype would look something like this: sub reshape (\@;\@\@\@\@\@\@...); The first argument is an array of dimensions, where C$x and C$y are the shape of the array to produce. The order and meaning of the arguments are the same ones used by the C:shape array attribute described in BRFC 203. We only need one Creshape since it is a multipurpose tool that works in any direction, serving as its own inverse. The dimensions used are subject to the following properties: 1. Less data than specified causes Creshape to return undef 2. More data than specified is silently discarded If any of the dimensions is specified as C-1, then that indicates a wildcard and grabs enough data to fill up the list. See below. =head2 Single Array Form - SPLIT When one array is passed in, it is split up. Here, the C$x and C$y determine the dimensions of the resulting lists. The C$i determines the interleave. For example, assume reshape is called with the list (1..23) in the following forms: @a = 1..23; @results = reshape [$x,$y], @a; $x,$y @results - -- 3, 2( [1,2,3], [4,5,6] ) 2, 4( [1,2],[3,4],[5,6],[7,8] ) 14,20 undef - not enough data to fill Notice how both dimensions work together to Creshape the array. As such, the combination of the arguments is more significant than the individual arguments themselves. Also, note that any excess data left over after the dimensions have been fulfilled is discarded. In the final example, undef is returned, allowing you to easily check if you have enough data: @matrix = reshape [14,20], @input or die "Not enough data!"; In addition, wildcards can be used. With a fixed C$y, only that many lists are returned. However, with a wildcard C$y, any number of C$x-long lists are returned: $x,$y @results - -- 4, -1 ( [1,2,3,4], [5,6,7,8], [9,10,11,12], [13,14,15,16], [17,18,19,20] ) # lose 21..23 Note that we lose data here because we can't get an exact number of lists length C$x. With a fixed C$x, lists Imust be returned that fixed length. However, with a wildcard C$x, lists will be expanded to fill the number specified by C$y, even in mismatched sizes: $x,$y @results - -- -1, 2 ( [1,2,3,4,5,6,7,8,9,10,11,12], [13,14,15,16,17,18,19,20,21,22,23]) Here, all the data is guaranteed to be preserved. It is simply split into exactly the number of parts specified by C$y, even if that results in some lists being different sizes. =head1 Multiple Array Form - JOIN In this form, multiple arrays are joined back together. Here, C$x and C$y, specify the dimensions to use to rejoin the lists, not to split them up. The dimensions simply work in reverse: Rather than specifying how many lists to create, they specify which elements of the input lists are joined back together. So, we'll assume an input array of the form: ( [1,2,3,4], [5,6,7,8], [9,10,11,12] ) Which is called by Creshape with the following dimensions: $x,$y @results - -- -1,-1 ( 1,4,7,10,2,5,8,3,6,9 ) # simple concat 3, -1 ( 1,2,3,5,6,7,8,9,10 )# 3 vals from all lists -1, 2 ( 1,2,3,4,5,6,7,8 ) # all vals from 2 lists 3, 2( 1,2,3,4,5,6 ) # 3 vals x 2 lists Hopefully this is easy to understand. C$x controls how many elements of each list are used, and C$y controls how many lists are used. This is just like the splitting operation, but in reverse. Again, wildcards of C-1 can be used here as well. =head2 Matrix Calculations and Extensions It is the opinion of the author that extensive matrix calculations and manipulations be left to external modules. A function such as this should be able to take care of most of the
RFC 225 (v2) Data: Superpositions
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: Superpositions
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 225
Version: 2
Status: Frozen
=head1 ABSTRACT
This RFC (seriously) proposes Perl 6 provide Cany and Call operators,
and, thereby, conjunctive and disjunctive superpositional types.
=head1 DESCRIPTION
The advantages and possibilities of superpositional programming were
demonstrated in well-received presentations at both YAPC'19100 and TPC 4.0.
It is proposed that the Cany, Call, and Ceigenstates operators
proposed in those talks be added to Perl 6. Adding them to the core is
suggested because the use of superpositions changes the nature of
subroutine and operator invocations that have superpositions as
arguments. This is currently impossible to reproduce in a module.
Furthermore, the fundamental utility of being able to write:
if (any(@value) 10) { ... }
or:
die unless all(@tests)-($data);
ought to be available to all Perl users.
Inclusion in the core would also allow the current module-based pure Perl
implementation to be greatly optimized (perhaps even parallelized on suitable
SIMD or other multiprocessing platforms).
A paper proposing the full semantics of superpositions (including their
effect when used as subroutine arguments and operator operands) will soon
be available from:
http://www.csse.monash.edu.au/~damian/papers/#Superpositions
=head1 MIGRATION ISSUES
The any and all functions may collide with existing user-defined
or module-exported subroutine names.
=head1 IMPLEMENTATION
See the Quantum::Superpositions module.
=head1 REFERENCES
[1] Bohr, N., On the Constitution of Atoms and Molecules, Philosophical
Magazine, s.6, v.24, pp.1-25, 1913.
[2] Einstein, A., ber einen die Erzeugung und Verwandlung des Lichtes
betreffenden heuristischen Gesichtspunkt ("On a Heuristic Viewpoint
Concerning the Production and Transformation of Light"), Annalen
der Physik, v.17, p.132-148, 1905.
[3] Lewis, G.N., The Conservation of Photons, Nature, v.118(2),
pp.874-875, 1926.
[4] Monroe, C., Meekhof, D.M., King, B.E., Itano, W.M. Wineland, D.J.
Demonstration of a Fundamental Quantum Logic Gate, Phys. Rev. Lett.
v.75, pp.4714-4717, 1995.
[7] Cirac, J.I. Zoller P., Quantum Computations with Cold Trapped
Ions, Phys. Rev. Lett. v.74, pp.4091-4096, 1995.
[8] Gershenfeld, N. Chuang, I. L. Bulk Spin-resonance Quantum
Computation, Science v.275, pp.350-356, 1997.
[9] Cory, D.G., Fahmy, A.F. Havel, T.F., Ensemble Quantum
Computing by NMR Spectroscopy, Proc. Natl Acad. Sci. USA 94,
pp.1634-1639, 1997.
[10] Deutsch, D. Quantum Theory, the Church-Turing Principle and the
Universal Quantum Computer, Proc. R. Soc. Lond., v.A400,
pp.97-117, 1985.
[11] Deutsch, D. Jozsa, R., Rapid Solution of Problems by Quantum
Computation, Proc. R. Soc. Lond., v.A439, pp. 553-558, 1992.
[12] Shor, P. Algorithms for Quantum Computation: Discrete Logarithms
and Factoring, Proc. 35th Symp. on Found'ns of Computer Science,
pp. 124-134, 1994.
[13] Grover, L.K., A Fast Quantum Mechanical Algorithm for Database
Search, Proc. 28'th ACM Symp. on the Theory of Computing, pp.
212-219, 1996.
[14] Wallace, J., Quantum Computer Simulators - A Review, Technical
Report 387, School of Engineering and Computer Science, University
of Exeter, June 1999.
Re: RFC 148 (v2) Add reshape() for multi-dimensional array reshaping
Let's jump in. This RFC proposes a Creshape builtin with the following syntax: Err... this syntax isn't what I expected at all! I thought the first argument would define the shape of the result, like NumPy or PDL... When one array is passed in, it is split up. Here, the C$x and C$y determine the dimensions of the resulting lists. The C$i determines the interleave. This $i definition should be removed now. So, we'll assume an input array of the form: ( [1,2,3,4], [5,6,7,8], [9,10,11,12] ) Which is called by Creshape with the following dimensions: $x,$y @results - -- -1,-1 ( 1,4,7,10,2,5,8,3,6,9 ) # simple concat I think that a simple concat is: reshape ([-1], @a); since here the rank of a list is one, so the length of the first argument to reshape is one. The -1 means 'use up the whole list'. It should be an error to have more than one arg of -1. 3, -1 ( 1,2,3,5,6,7,8,9,10 )# 3 vals from all lists That should be a rank 2 matrix of shape (3,4), i.e. ([1,2,3],[4,5,6],[7,8,9],[10,11,12]). -1, 2 ( 1,2,3,4,5,6,7,8 ) # all vals from 2 lists That's a rank 2 matrix of shape (6,2). 3, 2( 1,2,3,4,5,6 ) # 3 vals x 2 lists That's a rank 2 matrix of shape (3,2), which would discard the last 6 elements. Hopefully this is easy to understand. C$x controls how many elements of each list are used, and C$y controls how many lists are used. This is just like the splitting operation, but in reverse. Again, wildcards of C-1 can be used here as well. I don't think that there's 2 types of reshape(). There's one, and it takes an array of one shape, and returns an array of a different shape. The shape of the new array is specified by the first argument. The second argument is a list, so it succumbs to Perl's normal list flattening behaviour. The behaviour of reshape() should reflect: - PDL's reshape() - NumPy's reshape() -- which is the only one allowing '-1' in the shape - J's '$' verb which all behave the same way. Also, the examples should show reshaping into and out of arrays other than rank 1 or 2. Sorry Nate--I know we thought we were on the same wavelength here, but it looks like we weren't at all! Would you like me to redraft this for you, or create a new RFC?
Re: RFC 148 (v2) Add reshape() for multi-dimensional array reshaping
Sorry Nate--I know we thought we were on the same wavelength here, but it looks like we weren't at all! Would you like me to redraft this for you, or create a new RFC? It's all yours. My brain is toast, and I'm totally RFC'ed out. The only thing I care about is that the lists wind up on the end, i.e. @results = reshape [...], @a, @b, ...; Sorry for screwing it up. Please take over as maintainer. -Nate
Re: pack/unpack is damn unperlish. Explain them as Perl.
At 02:53 AM 9/18/00 -0400, Michael G Schwern wrote: Perhaps someone could attempt to write an explaination of pack and unpack in completely Perl terms. No bits, no ints, no nybbles, no IEEE floating point arithmetic, no prior knowledge of C necessary. I don't see how you could possibly do it without that any more than you can use numbers without understanding the range limits of integers and floating point roundoff. However, you're right, a tutorial is desperately needed. I rarely need pack/unpack but when I do, it takes me ages to figure out what to do. I don't think there's anything wrong with the interface though, it seems quite appropriate. -- Peter Scott Pacific Systems Design Technologies
Re: pack/unpack is damn unperlish. Explain them as Perl.
On Mon, Sep 18, 2000 at 10:54:04AM -0700, Peter Scott wrote: I don't see how you could possibly do it without that any more than you can use numbers without understanding the range limits of integers and floating point roundoff. You ignore that incidental detail until later on in the docs and assume that by the time users start writing programs with numbers 2**31 they'll have read that far. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson
