Re: sorting dates
- From: fox <spamtrap@xxxxxxxxxxxxx>
- Date: Sat, 30 Jul 2005 02:51:21 -0500
RobG wrote:
fox wrote: [...]
Function arguments in String.replace() are not supported in some browsers, e.g. Safari and according to Mike Winter:
"... IE5 and earlier ... don't support function arguments, and Opera 6 won't perform a replacement at all (a no-op)."
There may be others.
That is a PISS POOR argument. From whom are you repeating it?
The attribution is right where I posted it. It came from another thread where you also proposed using functions with the replace method. It is useful to point out to others where things may fail - what they choose to do with that advice is completely up to them.
solutions are better than advice... interesting that you deleted mine from this post
> [my take on these other browsers]
Until these browsers get their numbers up... they don't matter -- not to my clients, and therefore, not to me.
Whatever is posted here is expected to be suitable for the web in general and not be specific to intranets or corporate clients. If specific advice has know limitations then they should be noted so that others may decide for themselves whether it suits their circumstance or not.
So -- it's just about "lightweight solutions for lightweight browsers" -- right?
Comply or Die worked against Netscape 4. So why not all the others? Now it's "let's mollycoddle all these poor minority browsers to give them a chance to survive?" Don't make me laugh.
Excluding certain browsers purely on the basis that they are a small minority is not reasonable.
It's more than reasonable -- it's called competition... If "minority" browsers can't pull it together enough to survive... they are doomed to die out... I am not compelled to hold back anything to accommodate poor impelementations. If these minority browsers want to survive, they have to fix their shortcomings... that's all there is to it. Before you take further issue with this, I am merely reflecting the attitude of all of those on this and other newsgroups when everybody couldn't wait for Netscape 4 to "die and go away"... that precedence has been set.
String.replace with function as second argument was implemented in JavaScript 1.3 -- FULLY six years ago. There is NO excuse. ECMA describes String.prototype.replace with the first case for the second argument (replaceValue) as a *function.* There IS no excuse. I am fully justified to offer string.replace options with functions as second arguments.
[...]
Returned strings should probably contain delimiters (say '-') to make them more obviously dates (yyyy-mm-dd). Sorting should be unaffected.
comparing strings no doubt takes longer than comparing numbers.
if all dates to be sorted are in YYYY-MM-DD format, and -- worst case, they are all in the first week of the same year and month, then the MINIMUM # of comparisons needed to be made to pass one as <> the other would be 10 (one per character as long as they are equal) - two week span, 9 -- etc... Unless, of course, JavaScript can compare "chunks" of strings in one "throw" (I used to do it in C -- up to 8 characters at a time -- typecast to longints -- really good way to speed up searches too)
The idea is to have them in a format that sort() can use without any further modification and that doesn't require a comparison function. Whether they are strings or numbers will likely make very little difference in the OP's case as whatever operations are done to the table rows will likely take far, far longer than the actual sort.
with integers: 2 numbers, 1 subtraction... you do the math...
Unless you know the actual internal algorithm of how the sort works, discussing what you think it might be doing means you are basing your argument on conjecture.
Offhand, I don't for sure -- but I've seen enough of them to guess... probably quicksort...
I'm basing my argument on the "typical" sorting algorithms I have come across (as well as written from the ground up) in "my time." I'm also weighing in the algorithms I have worked out for myself. For strings, the "typical" algorithm compares one character (code) at a time until there is a difference, at which point the choice of order is made. For long strings, this can be a "lengthy" process, all things being relative. Atypical algorithms will optimize comparisons by measuring data, then "biting" it off a "register" at a time. 64-bit registers have been around for some time now, so that means 8 characters at a time. Eight characters can be typecast to an unsigned long long and compared numerically. You can't do this from the javascript language itself, that requires pointers (direct memory addressing) (not to mention long long datatypes), and I would be surprised if the engine actually takes this approach.
take for example: reciprocity and reciprocate.
it would take the typical sort algorithm 9 loops to find 'a' vs 'i'. the atypical algorithm described would take only 2. The atypical routine "views" the raw data as:
0x7265636970726f63 0x69747900...trash // '00' is end of string \0
and
0x7265636970726f63 0x61746500...trashfor case-insensitve, you can bitwise | 0x2020202020202020
if "last word" is not exactly 8 bytes long, the extra bytes should be zeroed/cleared in case of = entries.
in MORE than 75% of the time, the atypical algorithm will find a difference on the first comparison.
[AFAIK I am the inventor of this comparison algorithm... approx. 10 or so years ago when 64-bit integer support became available on Macs...now that doesn't mean that others might have developed the same or similar on *their* own and I wouldn't believe it if I were the ONLY one to come up with this -- but I doubt it is in use in the JS engine -- and upon "cursory" checking, that appears to be the case]
In C, where one has low-level access to the CPU and direct memory access, the algorithms in use are easily overridden and/or customized. Since this access is not available through JavaScript, the algorithms in place do not really concern me as I am not likely to be writing or improving any of them...ever. I don't have the time nor the inclination.
I have considerable background and experience on which to base my conjecture... and most general purpose public domain sort algorithms are of the "typical" type. Your statement makes it sound like you might know better -- why didn't you enlighten us as to which kind of algorithm *is* used?
[but this only matters if the operations are "time-critical"]
oh... that little YYYYMMDD integer format -- it's called a "packed" date format (packing integers is a "time-honored programming tradition") -- been around for considerably longer than JavaScript. Technically, the "digits" should be hexadecimal, but for sorting purposes, decimal digits work just as well with the extra added benefit of being easily readable in human terms.
So you know some other names for that format - bravo.
This isn't "special" or even "arcane" knowledge. And "that format" is not meant for representing information to humans (it's not really ANY "format" - packing can take any arrangement) -- it is used only in programming for data storage/manipulation.
Packing data is not language specific -- nor is it specific to dates. It is, and has been for a very long time, a useful programming "tool." It is used in data compression algorithms. One application of packed data you SHOULD know about is RGB or HTML color representation: #CC9933 -- CC is the red color component, 99 the green color component, and 33 the blue color component. Using "integers" to store more than one piece of datum is considered "packing." [packing does not really require integers -- any block of memory will do -- longints, arrays, etc...even just simple bytes.]
I made no assertion that it was peculiar to JavaScript - I know it isn't.>
I suggested the ISO standard format since it is an international standard that is unambiguous and widely understood and therefore very well suited for the web. It also sorts effortlessly and therefore is likely suitable for this and many other purposes.
All I'm saying is: if you have a considerable number of dates, all within a narrow span of time, it is worth the effort to convert to a number and use subtraction to make the comparison. In terms of programming, it is usually MORE useful to keep the date in integer (number) format, and use conversion to string for display instead of vice versa... Make sense? ISO date format makes going from packed date to string very easy.
The OP may think it's a load of crap and totally ignore everything I posted - ain't life grand.
granted...
.
- Follow-Ups:
- Re: sorting dates
- From: RobG
- Re: sorting dates
- References:
- Re: sorting dates
- From: RobG
- Re: sorting dates
- Prev by Date: Re: Pop-Up Window in need of delay?
- Next by Date: Text Scroller: scrolling stops in Firefox
- Previous by thread: Re: sorting dates
- Next by thread: Re: sorting dates
- Index(es):
Relevant Pages
|
