Re: Multi-dimensional arrays and relational db data

invented. The main problem PDL has is that Perl does not have a syntax for N-dim slices so it has to bolt something on the side by specifying a slice as a string. (see eg PDL::Slices). Numerical applications will get a significant boost if N-dim arrays with native slicing are possible in perl6. -- Tim

Re: RFC 120 (v1) Implicit counter in Cfor statements, possiblyC$#.

use that whenever I need to loop over indices of two arrays at once. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

second is added :-) -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

onds is my favourite... Just to clarify, MJD is days not years. A 32-bit double preicision number is usually adequate -- although have not thought about nano seconds! -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

h current perl 32bit doubles. I use it all the time in perl programs and am not suffering from a lack of precision. In fact RFC #7 ("Higher Resolution time values") suggests that the concept of "number of seconds since epoch" will have to make room for fractions of a second anyway.

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

ch with little extra code. Feel free to tell me to use an external module though. I had to mention it though. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

a disadvantage, just a difference. Indeed. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj

Re: RFC 48 (v1) Replace localtime() and gmtime() with da

of this has to be in the core? Could all the date/time stuff be moved into a standard module? Is localtime() used often enough to justify being part of the language? -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj

Re: RFC17

lish global approach but would prevent module authors from messing with each others globals without realising it. Of course, from what I can see, most of the globals don't really need to be global anyway (can't remember the RFC number). We already have "use warnings" in perl5.6. -- Ti

Re: RFC 48 (v1) Replace localtime() and gmtime() with da

date (yes I am an astronomer...) :-) -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj

Re: RFC 2 (v1) Request For New Pragma: Implicit

t that's an intereactive shell so we try to reduce common typing as much as possible). -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj

Re: PDL-P: Re: Reduce [was: Re: Random items (old p5p issues)]

have to be a range of integers. The range could be specified as floating point if we are specifying a slice in physical coordinates. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj

Re: RFC 29 (v1) unlink() should be left alone

st started perl (coming from Fortran) I also had trouble sifting through the docs working out how to remove a file but once I knew it was unlink I simply used it because that was the perl command for "rm". -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj

Re: RFC: Modify open() and opendir() to return handles

of the current open functions simply pass these objects around. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj

Re: RFC: Filehandle type-defining punctuation

itely worth a quick RFC - something like "proposal to return filehandles from open/opendir rather than supply as arguments". Whether this should be extended to chomp et al is, I believe, another issue since they are modifying the contents of a variable whereas open is overw

Re: RFC stuff

are currently very large modules... The Time::Object module currently seems to be a pretty good compromise between all-singing-all-dancing and localtime() since if we are going to replace localtime/gmtime with something it would be very useful, at minimum, to allow date arithmetic on these objects. -- Tim