Is the integrated sort within the recursive FLTA migrating to production worthwhile?

[Spiff59]

I just noticed this function is in the Beta and working it's way to production... with all the sorting code and the pack of helper functions?

To be consistant are embedded sort functions going into the _FileReadFromArray and _FileWriteFromArray functions, the three _FTP_FileListToArray functions, the Excel array fucntions, the Word array functions, IE array functions?  I'm sure there are many more suitable functions. You never know when you might need a sort.

Melba could crunch this into a single function with all the current functionality, except sort, and do it in under 80 lines. It would be faster and way smaller, much more easily maintained, and not reliant upon a dozen helper functions, some of which commit the sin of calling themselves.

Why take this to production with the sort? We don't already have sort?

It is easy to see that Valik has not been around for a while.

Edited August 3, 2013 by Spiff59

[Melba23]

Spiff59,

How nice of you to share your opinion with us and, given your constant belittling about this UDF since it was released, how unsurprising that you felt it necessary to do so. I do hope you feel better getting that off your chest.

You might care to know that many of the community do not share your low opinion and that the decision to include the UDF as part of _File.au3 was at the request of others, not myself. Furthermore, I would like to point out that the helper functions that "call themselves" are just slightly modified (for speed) variants of the standard _ArraySort QuickSort functions - should we remove those too?

Until now I have been reticent to comment openly on your frequent posts attacking this UDF, but such an open and embittered post has passed any reasonable limits of polite comment and is nothing more than flaming, pure and simple. Please note that any further such posts from you in a similar vein will be treated as such and sanctioned accordingly.

M23

P.S. And Valik has gone and is not coming back - either live with it or leave.

Edit: The above post as edited bears little resemblance to the original. This might explain any apparent over-reaction on my part.

Edited August 6, 2013 by Melba23

[Spiff59]

If you're reading the same post that I authored above, it's pretty focused... it presents just a single point: An argument against the inclusion of the sort option. 

Your reply references much that is beyond the actual content of my post. You mix in old history, ad hominems, threaten to sanction me, and don't address the subject of my post.

I've expressed my opinion. I'll restate it:

I feel it's unwise to create "All-in-One" functions by embedding redundant copies of other functions already within the library, such as the "standard _ArraySort QuickSort functions".  The code for the new module becomes exponentially larger, more complex, more difficult to maintain. The maintenance of the original function is also affected as updates to it will now likely need to be duplicated in other locations. The whole function library is now larger, more complex and harder to maintain.  The basic FLTA version and many other functions get along fine without an integrated search option, why must the recursive FLTA be different?

 My post above (#308) has nothing to do with years ago when a couple of the very first Melba versions were going around and I bitched that they were 98% similar to an earlier non-Melba version. We had a spat over that a long time ago. The issue was resolved. I'm long over it.

Requests for a recursive directory search are one of the most common in the forum.  They are routinely serviced in short order by yourself and a couple others usually with a one-liner saying "This is what you need..." and a link to this UDF.  Sometimes an OP will specifically ask what's the fastest, or easiest, or most efficient, way to do a recursive directory search.  In those cases, the canned answer is insufficient.  Out of probably 150-200(?) threads requesting how to do a recursive FLTA since this UDF has been available, I may have added a reply 3 or 4 times. I'll inform the OP that there are options other than 400 lines of code and 13 functions, that some things can be done in a few lines with DOS, or that there are a number of concise, single-function recursive FLTA's that are powerful and can be found using a forum search. I'm sorry if providing additional information to a request upsets anyone. My post above (#308) also has nothing to do with this.

I think the present UDF is bloatware, due to the internal sort, and that, as is, it is inappropriate for production.

I'd Love to see it go into production without the sort.  I've long felt a recursive FLTA was a needed standard function.

I did not place "OBEY ME!" in 48pt bold at the end of my post. I attacked a single idea, that of turning a mouse into an elephant for the sake of a sort option that will often not be used, and is already available in separate functions.  My intent was to present a solid argument, and evoke debate. Censure or censor me as you like. You have that power.

[Melba23]

I've expressed my opinion. I'll restate it

Nothing like a chip on both shoulders - makes you feel balanced!

M23

[iamtheky]

Is there an answer to Spiff's inquiry?  I have used his DOS recommendation in the past as it smoked the UDF for simple sorts.  I expected this question would lead to a better discussion, and a better understanding, rather than one liners that seem to persist from old battles.

[JLogan3o13]

I would suggest the same to you as has been suggested to other members of this forum that complain about the current content but offer nothing in return - put up or shut up. If you can do it much better than Melba has - do it! Post it and show us all why yours is so much better. It is easy to criticize someone else's hard work with ambiguous statements about what "should" or "should not" be done.

How about, instead of posting a wall of text in this thread, actually create the better mousetrap and submit it for scrutiny

[czardas]

@JLogan3o13 -  I haven't read everything above, but as I remember Melba often explicitly requests that people do make suggestions for consideration.

Edited August 2, 2013 by czardas

[JLogan3o13]

I agree, and he is always open to suggestions. But reading through this thread, it seems there have been more digs and fewer concrete suggestions.

@Spiff - I did not mean my post to sound harsh, apologies if it came across that way. You may well have a better way of doing things; I'm just saying - put it in code format so we can all benefit.

[czardas]

I agree, and he is always open to suggestions. But reading through this thread, it seems there have been more digs and fewer concrete suggestions.

 

I have no time to read the whole thread right now, but I understand and agree with you on principle.

[iamtheky]

Is there a thread already in existence that discusses the

slightly modified (for speed) variants of the standard _ArraySort QuickSort

 

 

Why are the modified (for speed) variants not pushed up as changes for the _ArrayQuickSort functions and then RFLTA go there for the need?

[Melba23]

boththose,

The modifications are basically the removal of errorchecking - the UDF knows it is passing an array of the correct type and so there is no requirement to check the input. Obviously that cannot be done with the standard _ArraySort functions.

M23

[guinness]

Also including the Array UDF in File.au3, just for the sake of_ArraySort, is a huge no no.

 

If anyone should be blamed for including this UDF, blame me. I'm the one who committed it to the UDFs and asked about its inclusion, not Melba23. Therefore I am happy to hear suggestions, so long as it's kept civil.

 

It is easy to see that Valik has not been around for a while.

I don't understand what this has to do with the UDF? But it's fairly easy to see, go to his profile and you will see "Last Active". Edited August 2, 2013 by guinness

[iamtheky]

This cannot be the only UDF that would always return the correct type, so then is slowed by the standard _ArraySort().  Why not have something more handily available like an _ArraySort_noerr() in the Array UDF.  Moreover, why not have error checking free versions of all functions where it results in a notable speed increase.

Just trying to better understand why whats good for this goose would not be for the gander.

Edited August 2, 2013 by boththose

[guinness]

Moreover, why not have error checking free versions of all functions where it results in a notable speed increase.

Because this would cause a massive influx in "this function doesn't work!" like posts.

[Melba23]

boththose,

Have you even looked at the _FielListToArrayRec UDF as it currently exists in the Beta? Like the OP, probably not, as it uses a dual pivot sort algorithm which is not (yet) in the main Array.au3 UDF and the only modified existing function it uses is to concatenate various arrays - all 5 lines of it. The additional 7 lines in the existing function are pure error-checking. So chase this red herring as far as you all want.

As to having "faster" versions of the various UDFs by removing errorchecking - not a hope. It would essentially double the size of the #include files. Besides it would only be in special cases where they are called as intensively as in this UDF and the gains in normal use would be relatively minor.

And that is all I am going to say on the subject. As explained earlier, I was not the instigator of adding the UDF to the standard install - if enough people decide that it is not worthy, then appeal to the Devs to remove it. I will be perfectly happy to continue it as one of my personal UDFs in the Examples thread. But I reiterate my warning that I will not stand for any more pure flaming of the type that began this thread - just as I would not accept it in a case where I was not personally involved.

M23

[Spiff59]

I  just lost 3 long paragraphs I had written in reply due to a misclick because I'm disturbed at all the popups saying things have been added to this topic.

These are all posts made on a thread with a title you wrote and then put my name to.

I find your title highly biased. It immediately engenders the thought that I oppose a recursive FLTA in production.

How about "Should we include copies of half the Sort functions in the production recursive FLTA?" for a title?

Do you like that wording?

I have a bit of stuff to retype in reply...  but want the title off, thread locked, something...

I have a history starting before you had joined the forum of strongly supporting the development of a recursive FLTA.

I put a lot of effort over a year into the very active 96952 thread, which generated many good ideas and many good examples.

 

Grr... I can't finish this now... not with your title on a thread that you made me the author of...

Edit: I am a little perturbed now.  For creating this thread, putting a misleading title on it and making me the author.  I got flustered as a dozen replies were added while I'm writing a thought-out reply, and lost my work. 

Edit2: What percentage of users have access to the dev forum to see my anti-recursive-FLTA/anti-Melba thread title? If it's small then I'm not that excited. But I don't like the thought of this thread out there trolling to the entire world impressions about myself that were concocted by another.

Edited August 2, 2013 by Spiff59

[czardas]

Okay I have read what this is about now.

I'm just about wondering one thing that Melba said. Replacing the array sort algorithm will cause some of my older scripts to behave incorrectly. I realised this a long tiime ago when I was modelling the behaviour of the sort function. I know it's unrelated, but it's the first time I have heard this mentioned. Lucky for me I predicted the eventuality of such a change and have changed my model since, although it goes to show how much there is to consider.

Edited August 2, 2013 by czardas

[JohnOne]

I've not looked through the UDF in beta or the UDF at all in a long time, but from what I can gather, using _ArraySort would be doing the error checking twice.

Am I correct in thinking that RFLTA tests that the array is of the correct type before passing to the faster sort?

If so, I don't see what all the fuss is about.

[Mat]

For now the algorithm is not being replaced, but added as an alternative.

This is because I doesn't bring performance improvements in all cases.

Spiff, what is your specific issue with the inclusion of Melba23s function?

[czardas]

I have a tendency to rip many of the UDF functions that I use out of the includes files to make lightweight programs. With less dependancies this will be easier to do. A larger AutoIt install package is perhaps the downside, but I would have thought this to be negligible overalll.

@Mat - thanks for the new info.

Edited August 2, 2013 by czardas