Re: Euphoria's identity/philosophy -- Where is the focus?
- Posted by Spock Nov 04, 2014
- 3004 views
The issues you describe above with the old Euphoria are _exactly_ what I encounter with the new Euphoria, ironically. I write and maintain business apps on a daily basis. I just can't use the new std lib routines for the tasks I require.
Irv complained about routines that did not exist under the old version of Euphoria. Your own example however is about routines that do in fact exist under the new version of Euphoria (but not all of which existed under the old one).
NO. Irv said "..people contributed more or less complete net libraries to RDS archives, but I was never really able to use these, either because .."
This is my issue as well. The only difference between the 2 code sets is that the latter have been incorporated into the Eu bundle. So, my point remains.
The sort has to be stable
sort() - NOT stable
custom_sort() - NOT stable
What do you mean by stable?
Certainly, if there are problems with these routines that can be repeatably demonstrated with test code, then either the problems should be fixed or else the routines replaced with better versions that don't share those problems.
Jim, are you making a joke here? I think you know what stability in sort algos means. The solution has always been around: Merge Sort - but not the one that was in the old Eu demos. Rob made a mistake in the code and the sort was not stable unless you change the comparison:
if compare(a[1], b[1]) < 0 then -- wrong, not stable if compare(a[1], b[1]) <= 0 then -- good, stable since the first element is placed sooner in the sequence when compared to an equal second element
What I did was to enhance insertion_sort() and call that inside merge_sort() for sequences of less than 100 items. The result is pretty good.
sort_columns() - NOT stable..
Can you give examples where the end data is incorrect? You probably found a bug (or several), and these need to be fixed.
sort_columns() calls custom_sort() which use the unstable shell sort. Unless I'm mistaken the end result is that the data is not guaranteed to be in the intended order.
The std sort routines just dont' cut it. The code is also bloated and ugly. Whoever created std\sort.e hasn't done a good job at all:
My 2 cents: if the code works well and performs well, but happens to be ugly, that's a reasonable trade off. Of course, you're claiming failure on all three standards...
What exactly do you mean by bloated? The dictionary definition of bloated refers to swelling, which doesn't seen applicable here.
The cores inside merge() and insertion_sort() have duplicated sequences (for ascend/descend). And the core of sort() is pretty much the same as custom_sort().
Spock
