This may happen on the first request due to CSS mimetype issues. Try clearing your browser cache and refreshing.

--- a/PDL/Book/Creating.pod +++ b/PDL/Book/Creating.pod @@ -21,12 +21,14 @@ will return an appropriately-dimensioned PDL containing those values. Here are some examples: - $a = pdl(5); # double-precision scalar - $a = pdl(short,5); # short-integer scalar - $a = pdl(1,2,3); # 3-PDL (one dim) - $a = pdl([1,2,3]); # 3-PDL, another way (just one dim) - $a = pdl([[1,2,3]]); # 3x1-PDL (two dims) - $a = pdl([[1,2,3],[4,5,6]]); # 3x2-PDL (two dims) + $a = pdl( 5 ); # double-precision scalar + $a = pdl( short,5 ); # short-integer scalar + $a = pdl( 1,2,3 ); # 3-PDL (one dim) + $a = pdl( [1,2,3] ); # 3-PDL, another way (just one dim) + $a = pdl( [[1,2,3]] ); # 3x1-PDL (two dims) + $a = pdl( [[1,2,3],[4,5,6]] ); # 3x2-PDL (two dims) + $a = pdl "[[1,2,3],[4,5,6]]"; # Even strings from print output! + In the last couple of examples, notice that the innermost nested lists form the 0th dimension of the PDL. @@ -183,12 +185,11 @@ in the PDL. The two operators work quite differently. For example: - $a = xvals(3); # 3-PDL: values are (0,1,2) - $b = zeroes(3,4); # 3x3 array of zeroes - $c = zeroes(3,4); # 3x3 array of zeroes + $a = xvals(3); # 1D-PDL: values are (0,1,2) + $b = zeroes(3,4); # 3x4 array of zeroes + $c = zeroes(3,4); # 3x4 array of zeroes $b = $a; # $b becomes a clone of $a $c .= $a; # $c becomes 4 copies of $a - puts two quite different values into C<$b> and C<$c>. At the end of the code, C<$b> and C<$a> are linked (they point to the same area of @@ -229,10 +230,10 @@ (3x1000x1000). $pdl = PDL->new_from_specification(byte,1000,1000,3); - $dref = $pdl->get_dataref; # $$dref is the PDL as a string. + $dref = $pdl->get_dataref; # $$dref is the PDL data as a string. $$dref = $data; # Overwrite the string. $pdl->upd_data(); # Make sure the PDL knows it changed. - $rgb = $pdl->mv(2,0,1); # 3x1000x1000. + $rgb = $pdl->mv(2,0); # 3x1000x1000. Here, C<$$dref> is a Perl string that occupies the same location in RAM as the data in C<$pdl>. Unless you're using 2-byte Unicode @@ -413,8 +414,11 @@ String context is what you get if you use a PDL as a string. The PDL gets converted to a human-readable string suitable for printing. The -string is generally not convertible back into a PDL without some -effort. Because string conversion is intended for use with C<print>, PDLs +new C<pdl()> string input capability allows one to convert printed +piddles back into the original object. The feature includes support +for MATLAB-style C<[ ; ]> syntax as well. + +Because string conversion is intended for use with C<print>, PDLs that are moderately large (more than about 1,000 elements) don't get converted - the string that you get back is C<TOO LONG TO PRINT>. String context is easy to remember as "just" a way to give you direct access