David Mertens writes: > > I was thinking about the new-from-string idea > and came up with a number of specifications. In > each case I give the string on the left and the > interpreted Perl array on the right. Does anybody > see any problems with any of these? Feel free to > add your own specifications! >
I recommend that we use matlab/octave conventions unless there is a perl/PDL specific reason not to. For me, the basic idea is that white space now is a separator token. > [1 +2 3] = [1, 2, 3] Yes > [1 + 2 3] = [1, 2, 3] No [ 1 + 2 3 ] -> [ 3, 3 ] Reason: conflict with matlab and seems inconsistent in that I would tend to read that as a list which would become something like [ 1, +, 2, 3, ]. > [1 + 2, 3] = [3, 3] Yes > [1 + .2 3] = [1, 0.2, 3] No [1 + .2 3] -> [1.2, 3] Reason: conflict with matlab and doesn't read "naturally" to me (since white space is a separator and why is the one around the + ignored but the ones around numbers are not). > [1 2 3 ; 4 5 6] = [[1, 2, 3], [4, 5, 6]] > [[1, 2][3, 4]] = [[1, 2], [3, 4]] Yes The key token types seem to be: [] as the constructor (a la matlab/octave), whitespace and commas are separators, semicolons are shorthand for [...] around the indicated elements, and math operators surrounded by space make the space not a separator. So maybe processing like this: (1) remove spaces around operators (2) replace spaces with commas (should skip inside ()) (3) add commas between adjacent ][ (4) convert delim - list ; by delim [ list ], (5) hand off the result to normal PDL::new processing Ideally, the processing should be idempotent for valid anonymous array ref constructions so you can cut and paste freely. The semicolon processing is pretty much matlab specific so a lower priority for initial implementation. I think if steps 1-3 and 5 were completed we would all be very happy. :-) --Chris
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
