@Matt C Anderson 

Did you mean to put that in another thread? I don't see any connection to this thread. Your worksheet is about exact polynomial algebra, and this thread is about fitting a sinusoidal function.

By the way, I like your idea of posting PDFs of worksheets. I think I'll start using that because they are immediately viewable from almost any browser, regardless of whether the viewing computer has Maple. If more people did this, I'd be able to view their worksheets from my phone, which I use to read MaplePrimes about half the time.

@mmcdara In your code, it's solve, not CharactericticPolynomial, that determines the order of the roots/eigenvalues. It may indeed now be the case that solve uses a consistent order (I don't know); however, that has not always been true.

Your code can only handle low-degree cases without parameters. It also has trouble with repeated eigenvalues. For example, change Sy to an identity matrix.

Your title gives the impression that using sort is undesirable.

For floating-point cases, the algorithm used by Eigenvalues doesn't solve a polynomial. There are other methods with less round-off error.

@Carl Love The code in the Answer above has been updated in several significant ways:

1. It now handles all documented calling sequences of LinearAlgebra:-Eigenvalues, in particular the generalized eigenvalue problem (whose input is two square matrices).
2. It now preserves all Matrix options, in particular shape and datatype, which Eigenvalues uses for algorithm selection.
3. All options to Eigenvalues are handled, including options that do not yet exist but may be added in the future, as long as they're of type {name, name= anything}.
4. The results are now remembered after sorting.

Regarding 2: This done by applying ToInert to the Matrices, which makes them immutable, which in turn makes them suitable as cache/remember table indices.

Regarding 3: On the off chance that an option not of that type is added, or if a completely new calling sequence is added, it'll still be handled correctly; it just won't be sorted.

Regarding 4: The earlier code sorted them after remembering them. While that did produce correct results, the new way is more efficient.

Finally, let me re-emphasive that this process is completely transparent to the end user. Once the overload is defined, you can call LinearAlgebra:-Eigenvalues in exactly the same ways that you've always called it, and it'll produce output in exactly its documented formats. The only thing that my code does is intercept that output, sort it, and remember it. The overload command is an extremely powerful tool for modifying what stock commands do in transparent ways.

@Kitonum Unfortunately, there are subtle, nonstandardized, imprecise, and often overlapping shades of meaning between residuals and errors, even when those words are used in a purely mathematical context. The present context appears to be fitting a real-valued model function to a finite set of data. In such a case the goodness of fit is often empirically checked by "plotting the residuals". One usually wants to check (often simply visually) not just the magnitude of the residuals but also that their mean is 0 (unbiasedness) and that their variance is constant over different subintervals of the independent variable (homoscedasticity). This can't be done if you use absolute values.

Of course, the 1-norm and infinity-norm of the residuals are also useful information wrt goodness of fit, and of course they use absolute value, but they don't require a plot. That a plot was requested suggests that the situation described in the first paragraph applies.

@Scot Gould The set sorting order is used in my Answer below.

@Preben Alsholm 

That's great, and very useful to know in general. Vote up! I didn't know that procedure options could be subsop'd. It's not allowed for some op numbers of a procedure.

There's 5 issues that I'd like to change. All of these are addressed in the following Answer.

1. I don't think that option system would be desirable, as it makes the remembered data too ephemeral. Option cache can be used to replace the timewise ephemerality of system with spacewise ephermerality. 
2. There's also the issue of the ephemerality (or, more precisely, the mutability) of Matrices themselves, which make them less-than-ideal candidates as arguments to cache- or remember-table procedures.
3. A consistent sort of the eigenvalues and eigenvectors can make this more useful across sessions.
4. The sort can also be used for list-form output (output= list).
5. This can all be done with no need to change the calling sequence of LinearAlgebra:-Eigenvectors (from the end user's POV) by using overload.

All these issues are solved in the following Answer.

@Kitonum Your suggestion is useful; however, it should be noted that the output thus produced is nearly impossible to use programmatically as a mathematical expression---it's only suitable for display.

@lcz In addition to collapsing the multiple loops, the Cartesian product completely eliminates the need for indexing. You don't even need to count the number of pairs.

@Earl A good starting keyword for researching this may be "catenary". See the Wikipedia article with that title. In particular, see its last section "Chain under a general force".

As is well known, a static uniform chain supported by two uprights of equal height assumes the shape of a simple hyperbolic cosine function.

It's not clear from your worksheet what the direction of gravity is. Is it parallel to or perpendicular to the axes of rotation of the gears? The shape of the chain will depend on that.

@lcz I just posted an application of breadth-first search in graphs in the Posts section.

By the way, I don't think that you understand the proper English usage of re in a title. One may use (but is not obligated to use) the title "Re: X" if one is responding to something titled "X". It doesn't make sense to put "Re" on an original title, such as at the beginning of a Question thread.

@Axel Vogt Is it perhaps the case that the reason that int doesn't do this straightaway is that the constant of integration is not just a constant but rather a function that depends on y but not x? If so, then this probably shouldn't be considered a bug.

@Kitonum Yes, it is simpler and easier to understand; however, the following illustrates why I chose to use AllPairsDistance rather than Distance:

G:= GraphTheory:-SpecialGraphs:-HallJankoGraph():
CodeTools:-Usage(AllEdgesDistance(G,1)):
memory used=488.23KiB, alloc change=0 bytes, 
cpu time=0ns, real time=7.00ms, gc time=0ns

CodeTools:-Usage(Dist~(1, convert(GT:-Edges(G), list), G)):
memory used=249.29MiB, alloc change=0 bytes, 
cpu time=1.80s, real time=1.59s, gc time=437.50ms

There is nothing special about the chosen graph; any sufficiently large graph will serve.

If I modify my procedure as follows, then it'll look more like your procedure but still retain its efficiency. Note that I also sort the output wrt [distance, edge] as requested by the OP. Most of the perceived complexity of the last line of my procedure comes from including the edge in the sort criteria.

AllEdgesDistance:= proc(G::GRAPHLN, v)
uses GT= GraphTheory;
local 
    VL:= GT:-Vertices(G), V:= table(VL=~ [$1..nops(VL)]),
    D:= GT:-AllPairsDistance(G), 
    Distance:= (u,v)-> D[V[u],V[v]], 
    Dist:= (v,e)-> min(Distance~(v,e))
;
    sort((E-> `[]`~(Dist~(v,E), E))([GT:-Edges(G)[]]))
end proc
:    

@vs140580 Both the error message and the help page ?GraphTheory,Distance are very clear on this point. You need to change Distance(e[1], v) to Distance(g, e[1], v).