Re: formats and localtime
> > Language > > -> Unixcentrism > > -> 1.PROBLEM: localtime's behaviour is non-intuitive for non-Unix people > > > > (I've always wondered is why it is 'non-intuitive'? If 0 == January is > > a problem. What do they do to translate day-of-week? Is it Monday > > based or Sunday based. Don't they have to read the documentation?) > > I agree too. In C/C++/Java all arrays (everything, actually) start with > 0. Why would a computer programmer (UNIX or Microsoft or ???) be > confused by starting at 0? I have to agree with Chaim and disagree > vehemently that localtime() should be changed. > > -Nate > In my opinion the important change is pre-adding the 1900 to the year. I find this always has to happen any way so it may as well be automatic. The month and day indices should stay zero since they are array indices. The manual will reflect this. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: formats and localtime
> TJ> The month and day indices should stay zero since they are array > TJ> indices. The manual will reflect this. > > [rspier@localhost rspier]$ perl -wle 'print +(localtime)[3] ' > 31 > > To what index do you refer? > > month days are currently 1 based. > > _consistency_ would be nice, C be dammed. Yes. Sorry. Perusing the docs, months start at zero, days start at 1 and years start at year-1900. Mainly because you never use day as an array index of course... > > I propose "consistency" as a "goal". > Yes. > (Consistent with what? With itself.) > And the manual will reflect _everything_. If it's not documented, it > might as well not exist. Agreed. The localtime() docs suffer from a 'read the C manual' problem at the moment -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
RE: type-checking [Was: What is Perl?]
On Tue, 1 Aug 2000, Tony Payne wrote: > > No, I disagree. Perl gains a lot of its expressive power from being lax > > about typing. I suspect it will also impose an unacceptable overhed for > > the vast majority who don't want it - at the very least every variable > > access will have to check an 'are you typed' flag. > > I agree that weak typing is a huge advantage for Perl -- if the task is > small. However, for a large project with more than 2 engineers, strong > typing can save weeks of integration effort. In a typical large project, > the first step is to define APIs, then split off and begin coding against > those APIs. The problem with using Perl for a project of this size is that > when it's time to integrate, there's no compile-time way to check that the > inputs and outputs of the APIs are correctly typed. This is a very small > piece in a complex puzzle, but incredibly useful for this purpose. And I > don't buy the argument that I should use a different language just because > it's a large task. Isn't this almost a case for revamping the prototyping system? You can define your API in terms the current perl variables (nothing in the above suggests that integers versus floats is the main problem) and have a prototype system that actually allows you to specify that "argument 3 should be an array with 5 entries", "argument 2 must be a hash reference" (allowing you to pass in a scalar containing a hash ref as well as a hash). Would that cover what you want? -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
RE: type-checking [Was: What is Perl?]
On Tue, 1 Aug 2000, Tony Payne wrote: > > > Isn't this almost a case for revamping the prototyping system? You can > > define your API in terms the current perl variables (nothing in the above > > suggests that integers versus floats is the main problem) and have a > > prototype system that actually allows you to specify that "argument 3 > > should be an array with 5 entries", "argument 2 must be a hash reference" > > (allowing you to pass in a scalar containing a hash ref as well as a > > hash). Would that cover what you want? > > It would be a start. It certainly would address my example, especially if > you could specify that the 5th argument be a referenced blessed into the > Foo::Bar class. However, if you're going to go that far, you might as well > allow for real typed vars. > If by "typing" we actually mean adding the ability to check that arguments are the correct object type (ie the correct isa relationship) then I would be all for it. I do spend quite a lot of time adding argument checking to my classes (I've got a 25000 line extensible data reduction pipeline written in perl and I try to make sure that arguments are sane) and do occasionally pine for a better prototype system [unfortunately I don't have time today to write an RFC on the issue :-( ]. I'm pretty sure that I don't want to have to start worrying about distinctions between integers, floats and doubles though. Scalars, hashes arrays and blessed objects provide more than enough breadth for me. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC: multiline comments
On Tue, 1 Aug 2000, John Barnette wrote: > Michael Fowler wrote: > > On Tue, Aug 01, 2000 at 05:28:08PM -0400, Michael Mathews wrote: > > > Unlike many programming languages Perl does not currently implement true > > > multiline comments. This can be confusing/tedious to programmers. This could > > > be solved by adding a syntax to Perl 6 that would allow for true multiline > > > comments. > > > > I'm not sure exactly what you consider to be a "true multiline comment", but > > Perl definitely has them by my definition. > > > > =pod > > > > Hi, this is a multiline comment. > > > > =cut > > The obvious problem with this, of course, is that pseudo-multilines that > use this technique show up in the POD documentation for the program / > module. While this is sometimes desirable, it seems like a overload. > Not if it is done as =begin multiline comment Multiline commend goes here =end multiline comment =cut but that is a bit more verbose... -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: date interface (was Re: perl6 requirements, on bootstrap)
On Tue, 1 Aug 2000, J. David Blackstone wrote: > Moving from bootstrap to perl6-language ... > > In response to [EMAIL PROTECTED]'s requirements document, Hildo > Biersma wrote: > > In issue 3.2.1 (localtime), note that the month starting at 0 is very > > useful for arrays - which is of the course the reason it is done this > > way. I am not convinced going to an index of 1 is the right approach. > > It might be more useful if the core came with a useful, minimalistic but > > inheritable, Date object. > > We have been making extensive use of Time::Object since the day it > was released. The recent version 0.10 (which appeared last week) > upgraded to an XS extension while maintaining the interface. > > This is exactly the way I would like things to work, but others may > not feel the same. Sounds good since: 1. It removes unnecesary core functionality to a loadable module 2. Can be retrofitted to perl5 code fairly easily (essentially as easy as exporting a backwards compatible localtime() function). 3. It no longer has a unix specific flavour (PS I am not anti-unix in any sense) so Mac, VMS and Windows users feel less confused. It gets my vote so long as perl6 has really fast methods. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: Random items (old p5p issues)
On Wed, 2 Aug 2000, Jeremy Howard wrote: > Dan Sugalski wrote: > > I've been thinking that it'd be nice to support extended array/list stuff > > to allow the rudiments of matrix operations into perl: > > > > @foo = @bar x 3; > > @foo = @bar * 4; > > @LoL = @foo * @bar; > > @baz =~ s/here/there/; > > > This would really fill a gap, if the speed is there. Currently there are > shortcomings with the major approaches to dealing with matrix ops: > - Custom tools (eg Matlab, Mathematica): Have to jump to other more flexible > tools for many parts of most programs. Expensive > - C++ template libraries (eg Blitz++, POOMA): Poorly supported by most > compilers due to complexity of expression templates (leads to compile > failure or very slow execution). _Very_ slow compilation (expression > templates can't be easily explicitly instantiated, either) > - Modern strongly typed langauages (eg. C++ with STL/valarray, Java): Need > to use looping constructs, which does not replicate mathematical language > closely > - FORTRAN: Showing its age. Hard to use complex data types > - Functional languages: Counter-intuitive for those from procedural > backgrounds. Can require deep understanding of underlying implementation to > avoid very slow execution > > If Perl borrowed some of the list notation and folding approaches from a > functional language like Haskell, and incorporated some of the tensor > notation approaches from Blitz++ or POOMA, I think the language would be > ideal for numeric programming. > > Or, to borrow Tom's phrase, it would make numeric programming fun again. > Have you used the Perl Data Language recently? It's very fast and perlified. I use it for my numeric programming. I like Dan's suggestions though. The above array processing would be very useful for string arrays as PDL can only deal with numbers. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: date interface (was Re: perl6 requirements, on bootstrap)
On Tue, 1 Aug 2000, Tom Christiansen wrote: > >3. It no longer has a unix specific flavour (PS I am not anti-unix in any > >sense) so Mac, VMS and Windows users feel less confused. > > Did it get decided that we were *supposed* to make Unix and C programmers > feel more confused and less at home with Perl? > > --tom > No. :-) I'm not bothered either way since I try to read the manual before using a function :-) The main objection to localtime() seemed to be the perceived lack of consistency and the only way to make it "consistent" is to rename it so as not to clash with the underlying C function. No one has yet proposed an RFC that removes all the standard C-like functions and replaces them with objects (although given the brain storming going on at the moment I am actually quite surprised noone has done that yet :-) -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC: Filehandle type-defining punctuation
On Thu, 3 Aug 2000, Simon Cozens wrote:
> On Wed, Aug 02, 2000 at 04:26:56PM -0700, Nathan Wiger wrote:
> > I tend to agree with Tom's argument here. open() is kind of funny
> > anyways. Why couldn't it work like this, similar to FileHandle:
> >
> >$fh = open $filename;
>
> Testing for failure. It's a basic tenet that system calls can be
> tested for success and failure by their returned truth values. I
> believe we should keep this.
>
Except that you can test for failure by checking to see if $fh is defined.
This is how IO::File does it
$fh = new IO::File("< $filename");
and it returns undef on failure.
--
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj
Re: RFC: Filehandle type-defining punctuation
On Wed, 2 Aug 2000, Nathan Wiger wrote: > Tom Christiansen wrote: > > > > >Not sure I agree with that. I think one point of confusion / perceived > > >difference between filehandles, open(), and basically every other > > >builtin is that all the others *return* what you want. > > > > tie and bless and chop and chomp also all act upon their argument(s). > > Just to name a few. bless has the nice side effect of returning it, > > too, but the rest are probably subject to your confusion issue. > > Now, one could argue the following. You could spruce up open() so it > acted more like tie. I could see this adding a lot of functionality: > >$object = open($fh, "<$filename") or die; > > You could ignore the $object just like with tie (maybe in 90% of your > calls), but if you chose to use it you would have direct access to, say: > >$object->autoflush; >$object->untaint; > > Thus, you have the "same old open()" for those who like it, but with the > added functionality of generating a FileHandle-esque object. > I think you'll find that the autovivified $fh in the above open() already acts as an object. open my $fh, "autoflush; my $line = $fh->getline; works fine for me on perl5.6.0 so long as IO::Handle has been "use"d. In fact, if IO::Handle is not avialable perl5.6.0 currently complains: Can't locate object method "autoflush" via package "IO::Handle" at ./test.pl line 5. It seems that this issue is definitely 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 overwriting. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC stuff
On Wed, 2 Aug 2000, Jonathan Scott Duff wrote: > On Wed, Aug 02, 2000 at 07:34:36PM -0700, Nathan Wiger wrote: > > > Deprecate localtime() and replace with > > > > I'm willing to take a first whack at this one (but only with lots of > > input from others). > > I'll help. Let's call the replacement gmt2date() for now. It might be worth considering the broader issue of date handling in general. Should the localtime/gmtime functionality simply be included in some date module that will handle date processing and arithmetic? The downside seems to be that both Date::Manip and Date::Calc 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 Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC: Modify open() and opendir() to return handles
On Thu, 3 Aug 2000, Graham Barr wrote: > On Thu, Aug 03, 2000 at 09:01:44AM -0600, Tom Christiansen wrote: > > >On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote: > > >> No, that's gross. A failed constructor should return undef. See my > > >> later message. > > > > >That has always been my view. But then people say "but why did it fail" > > >and having global variables does not scale well. > > > > Syscalls should use errno. Others may vary. > > It's the other may vary that bothers me. Even the core modules > can't agree, but that is a discussion for the stdlib list. > Isn't there some way to make $! usable when returning from normal subs as well as from syscalls? It seems that $! goes a long way to providing the an error message/error number and just needs a bit of a push to extend it to be more generic. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC: Modify open() and opendir() to return handles
On Thu, 3 Aug 2000, Nathan Wiger wrote: > Tom Christiansen wrote: > > > > >On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote: > > >> >Modify open() and opendir() to return filehandle objects > > >> > > >> Here are some things that that will be a problem for: > > > > >I did not see any that would be a problem. > > > > It's not as convenient. > > I'm not sure I understand how it could be less convenient. Maybe the > term "filehandle object" is misleading and smacks of FileHandle. That > wasn't the intent. I propose a new name, "fileobject", that can refer to > something that handles any of these: sysopen() should probably be included in the list as well. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
named parameters
Reading through the docs for perl prototypes I see that there is a reference to "named parameters" being a possibility in future versions of perl. Does anyone have a more concrete example of what was intended there? (I'm assuming that since it was mentioned that there was a debate on the issue some time ago). -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: named parameters
On Fri, 4 Aug 2000, Simon Cozens wrote:
> On Thu, Aug 03, 2000 at 09:39:30AM -1000, Tim Jenness wrote:
> > Reading through the docs for perl prototypes I see that there is a
> > reference to "named parameters" being a possibility in future versions of
> > perl.
> >
> > Does anyone have a more concrete example of what was intended there?
>
> sub marine ($sailor, $captain) {
> $captain->say("One ping only");
> }
>
Fair enough. If we were going to do it I would like to see it extend to:
sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
}
or somesuch, so that we can automatically dereference array and hash refs
and make sure that argument 4, for example, is a IO::Handle object, @y has
to have N elements etc [my syntax is not meant to be all that well thought
out just at the moment.]
I find that I spend quite a lot of code checking that arguments are in the
correct class, that I have array refs and things so anything that would
save typing is a good thing IMHO.
Of course, type checking can be done as
use Type::Checking qw/ checkargs /;
sub test {
checkargs( "$x, @y:[N], %z", @_);
or die "Incorrect args";
}
[where Type::Checking is a mythical module] without extending the language
at all...
--
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj
Re: RFC: Modify open() and opendir() to return handles
On Thu, 3 Aug 2000, Nathan Wiger wrote: > > sysopen() should probably be included in the list as well. > > Good point. > In fact, you may as well go the whole way and say that all IO is done via optimised IO objects (ie include sockets etc). IO::File and friends without the overhead. All of the current open functions simply pass these objects around. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: named parameters
On Fri, 4 Aug 2000, Damian Conway wrote:
>> > Fair enough. If we were going to do it I would like to see it extend to:
>> >
>> > sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
>> >
>> > }
>>
>> Is there an RFC for this yet? If not, I think there needs to be. I think
>> this would be really cool.
>
> I'll have a proposal out later today or tomorrow.
> But others ought to consider putting one in too.
>
> Damian
>
I was going to wait until this RFC came out and comment on it rather than
writing an RFC that might duplicate things in less than 24 hours.
--
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj
Re: RFC 2 (v1) Request For New Pragma: Implicit
On Fri, 4 Aug 2000, Bart Lateur wrote: > I think it's a bad idea. I would rather do it as the C64 did: use a very > short function name as an alternative to "print". > > P "This gets printed!", "\n", "Yeah!\n"; > Just like perldl already allows(but 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)]
On Fri, 4 Aug 2000, Tuomas Lukka wrote: > On 4 Aug 2000, Ariel Scolnicov wrote: > > Well, first of all, > > 10:100, 30:200 > > is not the same: in Perl it comes out as > > 10..100, 30..200 > > 10, 11, ... , 100, 30, 31, .., 200 > Additionally, generically it would not necessarily 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
On Fri, 4 Aug 2000, Damien Neil wrote: > My opinion on the unlink()/remove() debate: Ignoring our history is > foolish. Why suddenly transform every Perl program that uses unlink(), > which has been valid for over a decade, into one using an outmoded and > deprecated construct? unlink() is, in my opinion, actually clearer > than remove(), for it more accurately specifies what the operation > does. I agree with this. Changing the name of a function without any gain in functionality seems a bit mad. localtime is under "attack" for specific reasons unrelated to its name. When I first 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: RFC17
On Sun, 6 Aug 2000, Dan Sugalski wrote: > At 01:21 AM 8/6/00 -0400, Chaim Frenkel wrote: > >I think there are two problems. One is the naming convention, the > >second, the global effects. > > > >Why not split them. The names could be improved. > > > >And the global nature (of the name) abolished. > > I'm not entirely sure that tossing the global nature of these things is a > bad idea. It is kinda convenient to be able to mess with things (like $^W) > and have them stay messed-with. Tossing that makes some sense from a > stricture/no-action-at-a-distance standpoint, but having a quick & dirty > way to just *do* something is kinda perlish. > I think the "safe" compromise is that the globals can be globally affected if they are tweaked in package "main" but localised to a specific package if they are tweaked in pakcage "Foo". This would then keep Dan happy with the perlish 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. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Sun, 6 Aug 2000, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] (Johan Vromans) wrote:
>
> > I'd argue that
> >
> > ($year, $mon, $mday, $hour, $min, $sec, $msec, $nsec,
> >
> > is much easier to remember, since it is a series of continuous
> > decrasing magnitudes.
>
> I was thinking much the same. It also means you can sort the
> dates to whatever accuracy you want by comparing each of the
> first n elements in turn for some value of n defined bu the
> accuracy you want.
>
I agree on the order but if its done right you should not have to
do a element by element comparison. You simply need to create a
date() object with your comparison date in it and overload the >
and < operators so that you can do
if ( $date1 > $date2 ) {
...
}
On a related point, since the 0 indexed parts of local time were there
specifically for easy access into an array to retrieve the string form
would there be a method to return the month name directly without having
to do an explicit lookup (I imagine the format() part will handle this).
Is the intention to allow the stringification to know about different
languages?
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
--
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Mon, 7 Aug 2000, Philip Newton wrote: > On Mon, 7 Aug 2000, Tim Jenness wrote: > > > Is localtime() used often enough to justify being part of > > the language? > > You're kidding, right? > > We wouldn't have had all those script kiddies complaining about year 19100 > bugs and month-being-off-by-one errors if localtime() wasn't being used > all of the time, whether in CGI code or not. > Well yes, except I was trying to say "how big a performance hit do you get if localtime() is a loadable module rather than core language?" If localtime() is only used once per program the slow down when using a module compared to native op will be insignificant (especially since one of the aims for perl6 is to make XS (or whatever) as fast as core operations (almost)). There is an argument for moving all system calls out of the language and placing them in modules. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Mon, 7 Aug 2000, Nathan Wiger wrote: > > > > Also, I would vote for a method to return the Julian date (yes I am an > > > > astronomer...) :-) > > > > But surely not as a part of the core language? > > Exactly. In fact, I'm going to chop a lot of the original proposal out. > It's too bloated for core. > > There's a lot of cool time/date stuff, but there's plenty of chance for > external modules for that (including backwards localtime() > compatibility). > > -Nate > Agreed. It was getting a bit out of hand (although in principal Julian date could be the internal format :-) ). What is the reason why any 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: RFC 48 (v2) Replace localtime() and gmtime() with da
On 11 Aug 2000, Russ Allbery wrote: > Nathan Wiger <[EMAIL PROTECTED]> writes: > > > The problem is, many people on this list claimed that GMT != UTC, > > Correct. > > > and that machine time is only in GMT, making UTC dicey to derive. > > Nope. Other way around. Machine time is only UTC; GMT has fractional > skew instead of leap seconds, making it rather incompatible with > computers. > See http://www.jach.hawaii.edu/JACpublic/stardocs/sun67.htx/node217.html for a description of the different timescales as implemented by the SLALIB astrometry library (used by telescopes around the world). It tells you the difference between UT, UTC, GMT and others. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
> =head2 Date Arithmetic > > Date arithmetic has been axed from this proposal. Before you get too > upset, I had discussions with several people and became convinced that > this is something too difficult and bloated to stick in core. An > external module would be much better suited to this. We can still make > sure this is included with the core distribution. I understand where you are coming from with this but I could do the date arithmetic myself if there was a method to return the date from the object in some generic form. On unix this is seconds from 1970 but the more generic answer is julian date (or modified julian date). The translation of date to modified julian date can be done with one formula (plus adding the fraction of day from the time) [and yes I could put it in a module -- in fact I already have]. The Time::Local module currently has to be used to retrieve time in seconds from localtime() output. Adding a "date to MJD (or seconds)" and "MJD (or seconds) to date" method allows date arithmetic trivially -- this adds code bloat of about 10 lines to the core but allows the date arithmetic to work. $mjd = $date->mjd; $mjd += 52.5; # add 52 days 12 hours to the date $date->mjd($mjd); # or create new date object with this mjd The MJD to date translation is slightly more complicated but the algorithms are well known. (Hatcher 1985, Quarterly Journal of the Royal Astronomical Society, volume 26, page 151). In summary, adding the functionality of Time::Local to this RFC will make date arithmetic possible (although the Time::Local looks to be more complicated than it should be) without adding undue bloat and operator overloading. Adding support for (modified) Julian Date will be much more generic and remove dependency on unix epoch 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
On Fri, 11 Aug 2000, Nathan Wiger wrote: > > Adding support for (modified) Julian Date will be much more > > generic and remove dependency on unix epoch with little > > extra code. > > To me, the real question is which date() should we use: > >$date = date $seconds_since_epoch; # uses time() >$date = date $modified_julian_date; # non-Unix This would be fine so long as time() returned an MJD rather than seconds (or another function was supplied for returning the current time). I was not really proposing that seconds should be dropped just that MJD is an alternative (the other difference is that unix time is an integer and MJD has to be a double). > > If we can make it work, the second one seems a lot more > platform-independent. After all, the epoch has no meaning to those on > Macs, PCs, or BeOS machines (except maybe historical trivia). > > Are we agreed that date() should now be based on Julian date? Here's the > advantages: > >1. Unix-independent (yeah, I love Unix, but...) > >2. Allows easy date arithmetic (complex -> module) > It should be possible to do date arithmetic with the seconds returned by time() $tomorrow = time() + 24*60*60; so the second point is not really an advantage. The main issue is that date() has a method for returning some number such as this that will allow for easy date arithmetic. MJD has a more generic feel. > And here's the disadvantages: > >1. Unix time() no longer the basis for date > > Although that really isn't a disadvantage, just a difference. Indeed. -- 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)
On Mon, 14 Aug 2000, Nick Ing-Simmons wrote: > Jonathan Scott Duff <[EMAIL PROTECTED]> writes: > >On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote: > >> =head1 TITLE > >> > >> Maintain internal time in Modified Julian (not epoch) > > There has to be _an_ epoch - even Caesar started somewhere... > Julian Date is measured (roughly) from earliest astronomical observations that we have available to us. MJD is JD with the slowly varying bit removed (and correcting for the 0.5 day so that MJD starts at midnight rather than midday). > > > >How would this be stored? As a floating point number? What about > >sub-second accuracy? To get seconds you'd need about 5.15 decimal > >places (let's just call that 6) > > IEEE 'float' (the short one) has about 6 places (24 bit mantissa). > double has many more. But even I don't think using years as the > "unit" is right thing to do. > > Seconds 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 (v2) Standardize ALL Perl platforms on UNIX epoch
On Tue, 15 Aug 2000, Buddha Buck wrote: > Leap-seconds are a PITA for generic time routines. > Not really. They don't happen very often so you simply have a subroutine that has them all (this is how SLALIB does it). The pain is that you have to release a new version of perl each time a new leap 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)
On 14 Aug 2000, Russ Allbery wrote:
> Nathan Wiger <[EMAIL PROTECTED]> writes:
>
> > The idea would be twofold:
>
> >1. time() would still return UNIX epoch time. However, it
> > would not be in core, and would not be the primary
> > timekeeping method. It would be in Time::Local for
> > compatibility (along with localtime and gmtime).
>
> >2. mjdate() would return MJD. It _would_ be in core, and
> > it _would_ be the internal timekeeping method. All
> > of the new date functions would be designed to be based
> > off of it.
>
> By comparison, who uses MJD? Practically no one. It's a theoretically
> nice time scale, but outside of the astronomy community, how many people
> even have any idea what it is?
>
In one of my previous posts I was simply suggesting that the Date object
(whatever it is) should have a method to return the internal format
(seconds, mjd, whatever) to allow for simple date arithmetic without
having to do anything more complicated. unix seconds and mjd both will
allow this.
> This appears to be a proposal to replace a *very* well-known time base
> with very well-known and commonly-used properties with a time base that
> practically no one knows or currently uses just because some of its epoch
> properties make slightly more sense. Unless I'm missing something
> fumdamental here, this strikes me as a horrible idea.
Of course, "seconds since 1970" is only obvious to unix systems
programmers. "Number of days since XXX" is just as valid for someone
coming to the language from a different direction and at least has some
kind of basis outside of computing.
>
> Unix's time representation format has no fundamental problems that aren't
> simple implementation issues. Negative values represent times before 1970
> just fine. The range problem is easily solved by making it a 64-bit
> value, something that apparently we'd need to do with an MJD-based time
> anyway. And everyone already knows how it works and often relies on the
> base being consistent with their other applications.
>
MJD is doable with 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.
--
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)
On 14 Aug 2000, Russ Allbery wrote: > Day resolution is insufficient for most purposes in all the Perl scripts > I've worked on. I practically never need sub-second precision; I almost > always need precision better than one day. > MJD allows fractional days (otherwise it would of course be useless). As I write this the MJD is 51771.20833 > If we're aiming at replacing time, it has to provide *at least* second > precision, at which point I really don't see the advantage of MJD over > Unix time. Why change something that works? It should be able to provide this precision and more. At some level time() will have to be changed to support fractions of a second and this may break current code that uses time() explicitly rather than passing it straight to localtime() and gmtime(). As long as I can do simplistic date arithmetic with the return value of time() and retrieve that from the equivalent date() object I will be happy. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: Multi-dimensional arrays and relational db data
On Sun, 10 Jun 2001, Sam Tregar wrote: > On Sun, 10 Jun 2001, Me wrote: > > > Agreed. So long as you are talking about Perl 5's arrays. > > > > I disagree, if you are talking about 2 dimensional structures. > > You appear to have some fundamental misunderstanding about Perl 5. Perl 5 > does indeed support multidimentional arrays: > >my @matrix = ( [ 1 2 3 ] > [ 4 5 6 ] > [ 7 8 9 ] ); >print $matrix[1][2]; > > You could easily use either "tie" or the new "->[]" overloading in Perl 5 > to access relational databases in Perl 5. Are you going to make me show > you an example before you believe me? > At the risk of receiving a flame perl5 does not have multi-dimensional arrays. It has something that will do the job with a massive memory overhead ands lots of pain when dimensionality is high. If it had true support for N-dim arrays then PDL would never have been 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 Jenness JAC software http://www.jach.hawaii.edu/~timj
