Ascent - Average: The average vertical distance of ascent since the last reset.

You asked a good question.  It matters to anyone using the device on multi-day outings.  I don't think anyone here or even at frontline support has access to the algorithm. 

One would expect the ascent (and decent) to be the sum of non-negative (non-positive) elevation differences between each recorded track point and its predecessor since the measurement is in something called a "Trip Recorder."  In other words, total ascent should always be greater than or equal to the positive change in elevation, and total descent should always be greater than or equal to the negative change in elevation.

In my experience over all recent firmware updates (this wasn't true in the past) the device gives a close approximation to the expected value for ascents and descents recorded during a continuous track recording of up to several hours.

But there is a very common situation where the expectation fails.  If you reset the Trip Recorder and then hike to an elevation that is 1000 m about the reset point, the total ascent should show 1000 m plus whatever amount you descended along the way since those descents mean repeated ascents.  So when you reach the point 1000 m above your reset point, the device gives a fairly good approximation of the total ascent. 

Say, for purposes of example, that the device shows 1100 m at that point and you pause recording for a long lunch and siesta.  From that point on, the device will generally fail to meet the expectation of a close approximation.  When you check the ascent after your nap, you'll find that you climbed as much as 100 or 200 m while you were lying on your back.  The problem is that even though it's called a "Trip Recorder" and even though all other measurements freeze when track recording is paused or stopped, ascent and descent keep on incrementing upward as long as the device is on.  Without direct knowledge of the algorithm, I can only assume that it is because the natural uncertainties in each measurement keep accumulating as phantom ascent and decent.  If you camp overnight and leave the device on, the next day you will discover that yesterday's ascent could be a few hundred meters greater than it was when you went to bed even if atmospheric pressure did not change.  

Atmospheric pressure changes are another source of error.  As far as I know, that error is unavoidable.  Pilots, for whom, precise altitude is important, reset their altimeters every hour or so.  By my calculation, you can expect that pressure-change error to be less than 50 m/day except during weather events like swift frontal passage when the one-time error will typically be about 100 m.  Unlike the aforementioned accumulated recorded errors, the atmospheric pressure changes over durations of a few days or less should all be in one direction.  In other words, if the error causes ascent to be wrong, the barometric error will not ordinarily affect decent, and vice versa.

Personally (as I've often told the Garmin feedback page), I would like to see the firmware altered so that when recording is paused or stopped ascent/descent stop changing like all the other metrics in the Trip Recorder.  That way, you could freeze ascent/descent when you expect to be stationary for several hours, like overnight, then resume recording when you start moving.  Assuming you use the default setting to reset the pressure when the device is turned on, I believe the atmospheric pressure changes while the device was not recording would be fairly obvious in the track record since they would appear as spikes when the device resumed recording.  So at least the errors from atmospheric pressure change that occur when the device is not recording would be easy to correct for.

As it is, the only way to get a good approximation of your total ascent/decent over a multi-day trek is to keep a written record of the descent/ascent numbers at the beginning and end of each stationary period and then do the math yourself.

A more general complaint of mine applies to most electronic device manufacturers.  They hire documentation writers who might be good communicators but who know little about the inner workings of the devices on which they give instruction.  So the documentation only gives recommended sequences of steps and leaves it to reader to figure out by inference what the device is really doing. 

If anyone knows (notice emphasis) what the algorithm is for ascent and descent, I hope he'll share it. This thread would be a good place.