Sorting arrays in VBA

Originally Posted by vba_php

. . . why does it even matter? . . .

Because arrays can have more than 32767 entries. Especially if the array in question were Application.Transpose(Range("A3:A100002")) or similar. Why write library routines for fractions of the problem domain?

. . . for most of the people that I run into on a daily basis they won't understand the mathematics of it whatsoever. . . .

Who reads this site's Tips and Tutorial forum over the course of the typical month? I figure most of them are likely to be sufficiently motivated to be able to understand quick sort. Heck, they probably already know it but just haven't seen a VBA implementation.

Originally Posted by hrlngrv

Because arrays can have more than 32767 entries. Especially if the array in question were Application.Transpose(Range("A3:A100002")) or similar.

never heard of any attempt close to these claims in 20 years. But I don't work in the space of languages that are 30+ years old. I think we've hijacked in here enough. All your points are fine. thanks.

?

Integer and Single types were needed 30+ years ago due to limited RAM and, all too often, software floating point processing.

The largest positive value for an Integer in VBA is 2^15-1, or 32,767, the figure in my previous reply. The largest positive value for a Long is 2^31-1, or 2,147,483,647. Whole Excel columns have 1,048,576 rows, so Integer variables are unreliable for indexing arrays formed from large portions of workbooks. That was even the case in Excel 97 to 2003, when it had 65,536 rows, but still too much for Integer variables to index reliably.

To repeat, if you're going to offer library routines, make them as general and robust as possible. That does, in fact, mean avoiding Integer type variables.

Originally Posted by hrlngrv

if you're going to offer library routines, .

nothing about the code in the original post here has anything to do with libraries. no extra additions are necessary.