Searching \ for '[OT] cyclic average' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=cyclic+average
Search entire site for: 'cyclic average'.

Exact match. Not showing close matches.
'[OT] cyclic average'
2004\09\13@061133 by

Is there a (standard) way to calculate the average of a parameter that
is cyclic in nature, like the wind direction or the month of the year?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

I don't know if there's a 'correct' or 'standard' way, but typically
I've handled such cases by making a scale that's twice as large as what
I'm measuring, and keeping the average away from the edges.

0-360 degrees becomes -360 to 360.  When the average gets close to the
edge, perhaps 100 degrees away from either edge then I add or subtract
360 degrees depending on the edge.

The input and output have to be changed into the correct range.  If the
average is below 0 then subtract 360 from the input before adding to the
average, and add 360 to the average to get the output.

There is an interesting corner case at 0, however, which may need some
careful thought depending on the application.  In this case, if the
average is 0, then look at the input - if the input is above 180 then
subtract 360 from the input.  If below 180 then do not modify.  In
either case the average will have moved from 0 so the output equations
can remain the same.  If the input is at 360 or zero then the average
remains the same, and the output is 0 (or 360 if you allow that in your
system).

Of course, if your input varies by 1/2 a cycle per measurement then
you've got bigger problems than keeping a correct average - consult
nyquist.  :-)

Wouter van Ooijen wrote:

{Quote hidden}

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> I don't know if there's a 'correct' or 'standard' way, but typically
> I've handled such cases by making a scale that's twice as
> large as what
> I'm measuring, and keeping the average away from the edges.

But how do you know up front what the average will be?

Anyway, while bathing my children I had time to think about it. A solid
way to do it is to model each number as a vector on the unit (or any
other zero-origin) circle, and add these vectors (vector-wise of
course). The resulting vector points in the average direction. There is
of course the problematic case where the resulting vector is 0, which is
a real problem of averaging in a modulo world, not an artifact of the
method.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

On Sep 13, 2004, at 1:04 PM, Wouter van Ooijen wrote:

>> I don't know if there's a 'correct' or 'standard' way,

The weighted running average that has:

avg = avg*(1-c) + (c*sample)

(where C is typically 1/8 or 1/16)

Is pretty standard.  It's used for calculating TCP Round Trip Times,
for instance...

BillW

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

Wouter van Ooijen wrote:

>But how do you know up front what the average will be?
>
>Anyway, while bathing my children I had time to think about it. A solid
>way to do it is to model each number as a vector on the unit (or any
>other zero-origin) circle, and add these vectors (vector-wise of
>course). The resulting vector points in the average direction. There is
>of course the problematic case where the resulting vector is 0, which is
>a real problem of averaging in a modulo world, not an artifact of the
>method.
>
>
Excellent!  I hadn't thought of it that way.  A little too much math for
some situations, but certianly a perspective worth keeping in mind when
running into such a situation.

>
>
_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

>Excellent!  I hadn't thought of it that way.  A little too much math for some situations, but certianly a perspective worth keeping in mind when running into such a situation.

This sounds like a problem I faced a while back, averaging compass headings.
90,89,91 averages to 90, no problem, but 359,0,1 averages to 180 which is dead wrong.

What I did, was to convert the polar coordinates to rectangulars, then add them, then convert back to polar.

I had to do 7200 of these every second, while dealing with a ton of serial traffic as well, on nine ports.

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> >> I don't know if there's a 'correct' or 'standard' way,
>
> The weighted running average that has:
>
>        avg = avg*(1-c) + (c*sample)
>
> (where C is typically 1/8 or 1/16)
>
> Is pretty standard.  It's used for calculating TCP Round Trip Times,
> for instance...

That's a running average of a continous parameter. I was looking for
something that you could use for instance to detect a yearly birth peak
given a number of birth dates. Averaging the month does not work for
instance the average of november (11) and january (1) should be december
(12).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

On Tuesday 14 September 2004 12:04 am, Wouter van Ooijen wrote:
> > >> I don't know if there's a 'correct' or 'standard' way,
> >
> > The weighted running average that has:
> >
> >        avg = avg*(1-c) + (c*sample)
> >
> > (where C is typically 1/8 or 1/16)
> >
> > Is pretty standard.  It's used for calculating TCP Round Trip Times,
> > for instance...
>
> That's a running average of a continous parameter. I was looking for
> something that you could use for instance to detect a yearly birth peak
> given a number of birth dates. Averaging the month does not work for
> instance the average of november (11) and january (1) should be december
> (12).

avg = [BD_jan + BD_feb + BD_mar + ..... + BD_nov + BD_dec]/12   (1 year)

otherwise you may be probably looking for something like a matrix where you
can average by month over years, or over yearN, or ????:
BDmatrix[n][12] = {
BD_jan04, BD_feb04,......BD_nov04,BD_dec04,
BD_jan03, BD_feb03,......BD_nov03,BD_dec03,
BD_jan02, BD_feb02,......BD_nov02,BD_dec02,
...
BD_jan80, BD_feb80,......BD_nov80,BD_dec80,
....
}

avg_Jan =[ BD_jan04 + BD_jan03 + ..... BD_janX] / N
_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> avg = [BD_jan + BD_feb + BD_mar + ..... + BD_nov + BD_dec]/12
>   (1 year)
>
> otherwise you may be probably looking for something like a
> matrix where you
> can average by month over years, or over yearN, or ????:
> BDmatrix[n][12] = {
> BD_jan04, BD_feb04,......BD_nov04,BD_dec04,
> BD_jan03, BD_feb03,......BD_nov03,BD_dec03,
> BD_jan02, BD_feb02,......BD_nov02,BD_dec02,
> ...
> BD_jan80, BD_feb80,......BD_nov80,BD_dec80,
> ....
> }
>
> avg_Jan =[ BD_jan04 + BD_jan03 + ..... BD_janX] / N

Sorry, I don't understand enough of your post to state where it fails to
match what I want. But I have already posted an answer to my own
question (and someone else posted essentially the same solution in
different words).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

Hi,

I am not sure the conversion helps. If the resulting Cartesian coordinates
tends to be zero, then the variability of the polar angle increases
dramatically.

I would suggest the following process:

1. add a huge constant to each number before averaging
2. calculate the average
3. subtract the said constant from the result

Actually the user moves the point in a secure distance from the origo.

Regards,
Imre

On Mon, 13 Sep 2004, Dave VanHorn wrote:

{Quote hidden}

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

>> This sounds like a problem I faced a while back, averaging compass
>> 90,89,91 averages to 90, no problem, but 359,0,1 averages to 180 which is

It's actually NOT "wrong" - it's just not the interpretation that you wanted
to place on the data :-)

Imagine that the same data related not to compass headings but instead to a
(fast) vehicle speedometer. The answer of 180 would be correct for some
purposes. For a 360 degres 360 kph speedo the data would correspond to both
vehicle speed AND speedo pointer angle, but the summing method would work
for one and not the other.

{Quote hidden}

This also doesn't work.
For his example, if K is added each time, the average = (0 + 1 + 360 + 3k -
3k) /3 = 180
Good for speedo. Bad for angle.

What is needed is a strict definition of the problem in this particular
instance so that the data can then be described in terms of the problem
structure. (Echoes of Jackson structured programming - and no doubt much
since then).

In the case of eg wind direction the polar system works IF the amounts added
are vectors corresponding to distance travelled during each measurement
period ie the integral wrt time of the direction vector. If the sampling is
at constant rate then the vectors may be polar summed correctly. What you
are really calculating is not the mean heading but the resultant distance
vector. The heading that generated this is an implicit part of it.

The method needs to be re-evaluated each time the fundamental nature of the
data measured varies.

RM

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

On Thu, 16 Sep 2004 13:14:20 +0200 (CEST), dr. Imre Bartfai wrote:

> Hi,
>
> I am not sure the conversion helps. If the resulting Cartesian coordinates
> tends to be zero, then the variability of the polar angle increases
> dramatically.

But surely the points you are converting would be on the circumference of an imaginary circle, so only one of
the coordinates of any point could be 0.  Since we're dealing with an angle, and the circle doesn't really
exist, the diameter of the circle can be anything convenient - say 100, so the four cardinal points would be
100,0 0,100 -100,0 and 0,-100.

If this doesn't give sufficient accuracy, use a larger circle!  It's really just moving the decimal point in
the calculations, but that may make things easier.

> I would suggest the following process:
>
> 1. add a huge constant to each number before averaging
> 2. calculate the average
> 3. subtract the said constant from the result
>
> Actually the user moves the point in a secure distance from the origo.

I don't quite follow what you mean here - adding a constant to the original value (say in degrees) wouldn't
help, because the average of 10000359 and 10000001 is 10000180, minus 10000000 still gives 180 the same as
averaging 359 and 1, when it should be zero.  If you mean adding it to the cartesian coordinates, then I don't
see that gets anything that "using a large circle" doesn't.

Cheers,

Howard Winter
St.Albans, England

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> I am not sure the conversion helps. If the resulting Cartesian
coordinates
> tends to be zero, then the variability of the polar angle increases
> dramatically.

That is not an artifact of the calculation method, it is inherent in the
problem statement. What is the average direction of two compass
readings, one North and one South ?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> >> This sounds like a problem I faced a while back, averaging compass
> >> 90,89,91 averages to 90, no problem, but 359,0,1 averages
> to 180 which is
>
> It's actually NOT "wrong" - it's just not the interpretation
> that you wanted to place on the data :-)

It might not be wrong when the question is to average numbers, but the
question was to average a measurement that is cyclic (circular) in
nature, like a compass reading. There is no usefull interpretation of
'right' or 'wrong' without a question.  :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> I would suggest the following process:
>
> 1. add a huge constant to each number before averaging
> 2. calculate the average
> 3. subtract the said constant from the result
>
> Actually the user moves the point in a secure distance from the origo.

But that does not help: when avaraging months the average of november
(11) and january (1) will still end up as june (6), the correct answer
would be december.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

At 08:56 AM 9/16/2004, Wouter van Ooijen wrote:

>> I am not sure the conversion helps. If the resulting Cartesian
>coordinates
>> tends to be zero, then the variability of the polar angle increases
>> dramatically.
>
>That is not an artifact of the calculation method, it is inherent in the
>problem statement. What is the average direction of two compass
>readings, one North and one South ?

In my case, I was getting bearings from a doppler DF unit (actually another section of software, and some fun hardware). It would be quite reasonable for me to get bearing data that looks like this:

90,90,87,270,93,91...  Just the nature of the beast.
The math average is wrong no matter how you do it, because it can't handle the wrap.

What I ended up doing, was five layers of 16 bearings.
When I got the first 16 raw bearings, that made one "level two" bearing.
When I accumulated 16 level two bearings,that made a level three. and so on.
When the signal went away, I would take the best data I had and output it.

In the end, IIRC, I could average up about 4 seconds of 7200 bearings/sec this way, in much less ram than you'd otherwise expect.

With the pol-rect-pol method, I also got the length of the vector, which directly expressed how much "noise" was in the data. A short vector indicates that the bearing is too noisy to use, probably because of multipath reflections.

I never implemented it that way, but I could have tossed the shortest vector in each level before averaging, to clean it up, but I'm not sure that's entirely valid.

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

>
>90,90,87,270,93,91...  Just the nature of the beast.
>The math average is wrong no matter how you do it, because it can't handle the wrap.

Maybe I should illuminate this further.
Taking this as a math average, bad bearings from behind, which is a pretty common thing, shifts the resultant bearing southward, instead of making it still east, but less confident.

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

>> I would suggest the following process:
>>
>> 1. add a huge constant to each number before averaging
>> 2. calculate the average
>> 3. subtract the said constant from the result
>>
>> Actually the user moves the point in a secure distance from the origo.
>
> But that does not help: when avaraging months the average of november
> (11) and january (1) will still end up as june (6), the correct answer
> would be december.

much to a solution for cyclic problems, there isn't really anything like an
average between November and January, I guess...

There might be one between November 2003 and January 2004, though, which is
different from the one between November 2003 and January 2003. By adding
the year in this case, you get back to simple linear averages.

Gerhard
_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

>
>There might be one between November 2003 and January 2004, though, which is
>different from the one between November 2003 and January 2003. By adding
>the year in this case, you get back to simple linear averages.

Depending on the purpose, the calendar is then a circle, or a spiral.

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\16@234412 by
> There is no usefull interpretation of
> 'right' or 'wrong' without a question.  :)

Agree. That was my point a little further on. A number of problems may
appear similar because the data is presented in the same way and/or they use
the same variables. Without matching the data structure to the reality model
you can easily answer the wrong question. Understanding the question is an
essential part of the problem definition (obviously enough :-) ).

RM.

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> there isn't really anything like an
> average between November and January, I guess...

Then you guessed wrong. The problem was specifically stated as cyclic,
for instance trying to find a yearly peak in something (births, deaths,
bird migration, etc). When seen it this context (which was the context
of the original question) there *is* an average of November + Januaty,
and it is December. If this example is beyond you consider the other
example: averaging wind directions.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

Summary:
The original question does not allow of an answer as put.
Apparently alike cyclic things are being lumped together when they are too
different to be able to be treated identically.
This may not be obvious at 1st glance.

> The problem was specifically stated as cyclic,
> for instance trying to find a yearly peak in something (births, deaths,
> bird migration, etc). When seen it this context (which was the context
> of the original question) there *is* an average of November + Januaty,
> and it is December. If this example is beyond you consider the other
> example: averaging wind directions.

We are not, perhaps, out of the wood yet:-)

If the averaging is of a variable that you sum in units across the period
concerned, such as births, then the month's result can be represented by a
single number. (eg 6,467,123 births)(!)

Take wind as an example in the following.
If the variable is a vector with direction and magnitude and we wish to take
the mean vector then we need to perform a vector sum. Even then the desired
calculation is not certain as we may be interested in just the vector
directions or we MAY be interested in direction and magnitude and in each
case we will probably be interested in the time duration of each
measurement. If measurements are made at equal time periods then that
component apparently vanishes. (It's still there but cancels out).
The vector sum can be quite meaningless if what we are trying to represent
is REALLY something else than what we try to represent. I may ask for the
average wind direction in each month. If I take 1000 samples and 498 are due
south and 498 are due north and 2 are due east then I can say that, by
adding the vectors, the average wind direction was due east :-). If I do the
same the next month and the results are much the same except that the 2
samples are North by East (just a tad East of North) then adding the two
months tells me that the mean wind direction was North East. It wasn't. It
was South or North almost without exception. There was no truly
representative direction. The question does not allow the data to tell the
truth :-)

Worse. If the wind blew as in the first example BUT when it blew north it
did so at 100 kph and when it blew south it did so at 5 kph, the average
wind direction by summing the results would be east, as in the first
example. But the true answer would be "The wind direction doesn't matter
much at all unless it's blowing North, And it does that half the time, and
when it does it's invariably at 100 kph.

This problem is somewhat solved by, as i suggested previously, summing not
DIRECTION but its time interval, distance. Now the northerly readings will
be 100/5 = 20 times more significant than the southerly and the answer will
be more representative of reality.

It can be seen with some sitting and thinking about it, that it's still
unclear what you are REALLY measuring even then, and the question of what
the question asker REALLY wants to achieve with the answer may come to mind
:-). Having the specifier tell you what they wish to achieve rather than how
they wish to achieve it (ie measure mean wind direction is HOW in this case)
should help. Note that "measure mean wind direction" will usually sound more
like "what" than"how" so you have to be careful.

What was the aim of the original request?
Which was

> Is there a (standard) way to calculate the average of a parameter that
> is cyclic in nature, like the wind direction or the month of the year?

The answer so far has to be: "ABSOLUTELY NOT, as cyclic variables can be
quite dissimilar to each other. So the problem has to be specified more
tightly than a generic answer would allow."

:-)

Hey - this is real engineering (or an attempt at it). What's that doing on
the PICList OT tag ? :-)

Russell McMahon

How do you

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> If I take 1000 samples and 498 are due
> south and 498 are due north and 2 are due east then I can say that, by
> adding the vectors, the average wind direction was due east :-). If I do the
> same the next month and the results are much the same except that the 2
> samples are North by East (just a tad East of North) then adding the two
> months tells me that the mean wind direction was North East. It wasn't. It
> was South or North almost without exception. There was no truly
> representative direction. The question does not allow the data to tell the
> truth :-)

If you take an average, you usually need the variance, too, in order to get
something significant -- unless you know that it will be in a certain
range. In your examples, the variance would tell that the average is not a
good one.

Gerhard
_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> What was the aim of the original request?
> Which was
>
> > Is there a (standard) way to calculate the average of a
> parameter that
> > is cyclic in nature, like the wind direction or the month
> of the year?
>
> The answer so far has to be: "ABSOLUTELY NOT, as cyclic
> variables can be
> quite dissimilar to each other. So the problem has to be
> specified more
> tightly than a generic answer would allow."

I disagree. Vector addition is the real generic answer. It might be that
the step 'what do I need' to 'I need to average a cyclic parameter' is
wrong, but that was not the original question.

> Hey - this is real engineering (or an attempt at it). What's
> that doing on the PICList OT tag ? :-)

For lack of a [GE] (general engineering) or [MATH] tag it has to ride on
[OT] :(

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> If I take 1000 samples and 498 are due
> south and 498 are due north and 2 are due east then I can say that, by
> adding the vectors, the average wind direction was due east :-). If I do the
> same the next month and the results are much the same except that the 2
> samples are North by East (just a tad East of North) then adding the two
> months tells me that the mean wind direction was North East. It wasn't. It
> was South or North almost without exception. There was no truly
> representative direction. The question does not allow the data to tell the
> truth :-)

There is an issue close to this that wasn't in the problem statement: what happens if all of the values cancel
out?  What is the average wind direction when the two samples have a direction that's exactly 180 degrees
apart?  You can't say there's no wind, because there was, and you can't say there was no direction, because
that's meaningless.  It's a problem that doesn't have a pure arithmetic solution in special cases like this.

Anything that has a "circular" characteristic will give this problem - if you're heading due North and you
want to head due South, which way should the navigation software tell you to turn for the shortest route?
This is the sort of thing that throws up bugs at the most awkward time, and the programmer needs to check for
it, otherwise the program may loop trying to make a decision which will never happen... until you reach the
North Pole!  :-)

Cheers,

Howard Winter
St.Albans, England

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

>> there isn't really anything like an
>> average between November and January, I guess...
>
> Then you guessed wrong. The problem was specifically stated as cyclic,
> for instance trying to find a yearly peak in something (births, deaths,
> bird migration, etc).

I'm not sure why you would average months to get a peak of something over
time. Average doesn't help with peaks. That's more like counting how many
instances occurred in a given period, and find the period(s) (day of year,
week, month, whatever) that have periods with fewer instances on both
sides.

> When seen it this context (which was the context
> of the original question) there *is* an average of November + Januaty,
> and it is December.

I don't quite agree. If we say Nov 03 and Jan 04, the mid-point is Dec 03.
We are not on a cyclic scale, but on a linear one. If you go cyclic, there
are two mid-points between any given set of two different points, and the
only difference is that one is closer than the other (usually). So without
adding additional information -- which is specific to the problem that you
want to solve --, there's no general way to say which one of the two is the
"right" one.

You say that it's obvious that Dec is the mid-point between Nov and Jan.
But there might be a good reason to say that June (2004) is the mid-point
between Feb (2004) and Oct (2004), and not December...  Whether it makes
sense to calculate December (and not June) as a mid-point between two
points Feb 04 and Oct 04 depends very much on the very specific question

I'm not that fit in statistics, but I'm not sure it makes at all sense to
talk about "average" in a cyclic domain. Probably an average requires at
least an unambiguous mid-point operation for any two points, which is not
given in a generic cyclic domain. There need to be additional definitions,
and these depend on the specific problem.

Gerhard
_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

mmm with that OT / new tag thing
perhaps some kind of "technical" tag?
things that are interesting and informative to general technical
type people, keeping OT for religion, politics and stuff that really is
off topic.

just a thaught?

> {Original Message removed}
At 07:06 AM 9/17/2004, Gerhard Fiedler wrote:

>> If I take 1000 samples and 498 are due
>> south and 498 are due north and 2 are due east then I can say that, by
>> adding the vectors, the average wind direction was due east :-). If I do the
>> same the next month and the results are much the same except that the 2
>> samples are North by East (just a tad East of North) then adding the two
>> months tells me that the mean wind direction was North East. It wasn't. It
>> was South or North almost without exception. There was no truly
>> representative direction. The question does not allow the data to tell the
>> truth :-)
>
>If you take an average, you usually need the variance, too, in order to get
>something significant -- unless you know that it will be in a certain
>range. In your examples, the variance would tell that the average is not a
>good one.

That's the point of doing the vector math.
The inputs all have a radius of "1".
The output is a vector with a radius of less than 1. How much less, tells you how "clean" the data was.

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> There is an issue close to this that wasn't in the problem
> statement: what happens if all of the values cancel
> out?

That was not explicitly mentioned, but this a real problem: the cyclic
average (if that is a correct term) of a set of values can be undefined.
In the IMHO correct mathematical way of calculating the cyclic average
you will get a zero vector, which indeed has no direction.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

Wouter van Ooijen wrote:

> Then you guessed wrong. The problem was specifically stated as cyclic,
> for instance trying to find a yearly peak in something (births, deaths,

I don't know if this helps or not, just one way of thinking about it (and
I've not followed the thread all that closely so this might have been
mentioned before).

If you take the example of the averaging of dates / months. Think of how a
date is represented in a PC. It is just a big number that is converted to a
proper date format for display purposes.

If you were to represent (arbitrarily) 31st Dec as 1000 and 2nd Jan as 1002
then the average would be 1001 which would be 1st Jan, which would be
correct. In a PC the date/time is held in a very big number and is an offset
from some baseline date or other.

I think if you do it this way then the date example should always work, as
long as you feed it the correct data (i.e. november 1966 and january 2004
wouldn't necesarily give a november average). It doesn't help the dearings
example though.

Cheers....Mike.

---
Outgoing mail is certified as Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.760 / Virus Database: 509 - Release Date: 10/09/2004

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> Subject: RE: [OT] cyclic average
>
> mmm with that OT / new tag thing
> perhaps some kind of "technical" tag?
> things that are interesting and informative to general technical
> type people, keeping OT for religion, politics and stuff that
> really is
> off topic.
>
> just a thaught?

Even this (mathematical?) discussion has a tendecy to drift into
more-or-less regilious viewpoints, so maybe [OT] is the right tag :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

>
>I think if you do it this way then the date example should always work, as
>long as you feed it the correct data (i.e. november 1966 and january 2004
>wouldn't necesarily give a november average). It doesn't help the dearings
>example though.

There's the crux of the problem..

Time can be represented as a line, a spiral, or a circle, depending on your purpose.
Bearings can only be properly represented as a circle.

_______________________________________________
http://www.piclist.com
http://mailman.mit.edu/mailman/listinfo/piclist

> There's the crux of the problem..
>
> Time can be represented as a line, a spiral, or a circle, depending on
> Bearings can only be properly represented as a circle.

And, as I have described, there are at least two classes of problems in that
subset. eg those that care about the magnitude and direction of the samples,
and those that only care about the direction.

RM

_______________________________________________
http://www.piclist.com