如何防止整数序列经常具有相同的值 [英] how to prevent series of integers to have the same value to often

问题描述

我有在线整数系列，所以每隔几毫秒我就有一个新的整数。没有指定频率-有时我有很多数字，有时我没有数字。

实际上，这些数字被称为股票的真实价格。我在交易应用程序中使用它。

现在，我仅将最后一个数字用作真实价格，因此我根本不会跟踪序列。但是这种方法存在一些问题。让我们看看这个系列：

1. 98; last = 98


2. 100; last = 100


3. 101; last = 101


4. 100; last = 100


5. 101; last = 101


6. 100; last = 100


7. 101; last = 101


8. 100; last = 100


9. 101; last = 101


10. 100; last = 100


11. 99; last = 99


12. 98; last = 98

问题在于，我的真实价格在很短的时间内从100变为101很多次。真实价格的每次更改都意味着大量工作（重新计算，下订单等），因此我不需要像那样更改真实价格。此更改（100-101-100-101）是由于测量问题引起的，我需要对其进行过滤。我无法修复测量，因此必须在此处修复。

一种方法是使用 3LastAverage算法：

1. 98； 3lastAverage = 98


2. 100; 3lastAverage = 99


3. 101; 3lastAverage = 99.67 => 100


4. 100; 3lastAverage = 100.33 => 100


5. 101; 3lastAverage = 101


6. 100; 3lastAverage = 100


7. 101; 3lastAverage = 101


8. 100; 3lastAverage = 100


9. 101; 3lastAverage = 101


10. 100; 3lastAverage = 100


11. 99; 3lastAverage = 100


12. 98; 3lastAverage = 99

如您所见，这种方法并不总是有效，但我仍然遇到100-101-100的问题。也许我可以使用更多的数字来计算平均值 ...但是由于这样的例子，这种方法对我不起作用：

1. 99 ; 3lastAverage = 99（我想要99）


2. 100; 3lastAverage = 100（我想要100）


3. 101; 3lastAverage = 100（我想要101）


4. 102; 3lastAverage = 101（我想要102）


5. 103; 3lastAverage = 103（我想要103）

通常，当事情确定时，我需要truePrice才是最后一个数字！

因此，具有在线整数系列，我需要计算该系列的所谓真实值，其定义如下：

• 如果一切正常，那么这只是最后一个数字


• 如果序列中的相同数字过多（ （因为测量存在问题），那么真实值不应经常更改。应该使用最适当的值

我的建议是：

• 只是禁止真实值每秒具有相同的价格。

例如：

1. 0.000：98；真实值= 98


2. 0.100：100;真实值= 100


3. 0.200：101；真实值= 101


4. 0.300：100；真实值= 101（0.2秒前在第2步已使用100）


5. 0.400：98；真实值= 101（0.4秒前在第1步已使用98）


6. 0.500：99;真实值= 99


7. 0.600：100;真实值= 99（0.5秒前在第2步使用了100）


8. 1.500：101；真实值= 101（自从使用101后经过了超过一秒钟的时间）。

但是这种方法也有这样的错误：

1. 99 tp = 99


2. 100 tp = 100


3. 101 tp = 101


4. 102 tp = 102


5. 103 tp = 103


6. 102 tp = 103


7. 101吨= 103


8. 100吨= 103


9. 99吨= 103


10. 98吨= 98


11. 97吨= 97

这里的问题是 tp在103级的冻结时间太长了。

对于如此大的问题，我真的感到很抱歉。但是可能有人正在解决紧密的问题并可以分享经验。我的主要问题是，我确实需要同时解决两个相反的问题：

• 真实价格必须只是最后一个 一般情况下的价值


• 真实价格不应经常更改（因此，我需要以一种或另一种方式使用以前的价值）


• 也很难说什么时候我们有一般条件，什么时候有测量问题

所以我的问题真的很模糊我只是希望有人试图解决类似问题。与往常一样，应该使用常识来解决此问题。

解决方案

您要对长期（低频）做出响应价格变化，但忽略小的短期（高频）波动。因此，您需要的是 低通滤波器 。 / p>

有许多不同类型的具有不同特性的低通滤波器。移动平均值是一种低通滤波器，但是（您观察到）它存在一个问题，即它需要对延迟进行平滑处理（为了平滑高频波动，您需要在相当长的序列上进行平均，但是

所以您可以尝试使用其他低通滤波器，例如指数加权移动平均线，并查看它们是否满足您的要求。

关于此任务的另一件事是，您决定何时重新计算与移动平均值最接近的整数是不好的事情，因为当移动平均值接近一半时，它会放大较小的波动在两个整数之间。 （如果移动平均线从99.49变为99.51，则舍入运算会将这种小的波动放大为从99到100的大波动。）

您应该使用的是< a href = http://en.wikipedia.org/wiki/Hysteresis#Hysteresis_in_engineering rel = nofollow> 迟滞 以避免这种响应。重新计算时，请记录移动平均线 a 的当前值 a ₀ ，直到移动平均线后再进行其他重新计算 a 已移动至少ε，即| a - a ₀ | ≥ε。

I have "online" series of integers number, so every several milliseconds I have new number. Frequency is not specified - sometimes I have many numbers, sometimes I have no numbers.

In reality this numbers are so called "true price" of the stock. I use it in my trading application.

Now I just use last number as a "true price" so I do not track series at all. But there are some problems with such approach. Let's look at this series:

1. 98; last = 98
2. 100; last = 100
3. 101; last = 101
4. 100; last = 100
5. 101; last = 101
6. 100; last = 100
7. 101; last = 101
8. 100; last = 100
9. 101; last = 101
10. 100; last = 100
11. 99; last = 99
12. 98; last = 98

The problem is that in very short period of time my "true price" is changed from 100 to 101 and back too many times. Every change of true price implies a lot of work (recalculations, orders placement etc) so i do not need to change true price like that. This change (100-101-100-101) is due "measurement problems" and i need to filter it. I can not fix "measurement" so I have to fix it here.

One of the approach would be to use "3LastAverage" algorithm:

1. 98; 3lastAverage = 98
2. 100; 3lastAverage = 99
3. 101; 3lastAverage = 99.67 => 100
4. 100; 3lastAverage = 100.33 => 100
5. 101; 3lastAverage = 101
6. 100; 3lastAverage = 100
7. 101; 3lastAverage = 101
8. 100; 3lastAverage = 100
9. 101; 3lastAverage = 101
10. 100; 3lastAverage = 100
11. 99; 3lastAverage = 100
12. 98; 3lastAverage = 99

As you can see such approach doesn't always work, i still have 100-101-100 problem. Probably i can use more numbers to calculate "average"... but such approach will not work for me because of such example:

1. 99; 3lastAverage = 99 (i want 99)
2. 100; 3lastAverage = 100 (i want 100)
3. 101; 3lastAverage = 100 (i want 101)
4. 102; 3lastAverage = 101 (i want 102)
5. 103; 3lastAverage = 103 (i want 103)

In general, when things go "OK" i need truePrice to be just the last number!

So, having "online" series of integers numbers, i need to calculate so called "true value" of this series, which defined this way:

• if everything is OK then this is just the last number
• if there are too much the same number in series (because measurement problems) then "true value" shouldn't change too often. most adequate value should be used

My suggestion would be:

• just prohibit "true value" to have the same price more than once per second.

For example:

1. 0.000 : 98; true value = 98
2. 0.100 : 100; true value = 100
3. 0.200 : 101; true value = 101
4. 0.300 : 100; true value = 101 (100 was already used at step 2 0.2 seconds ago)
5. 0.400 : 98; true value = 101 (98 was already used at step 1 0.4 seconds ago)
6. 0.500 : 99; true value = 99
7. 0.600 : 100; true value = 99 (100 was used at step 2 0.5 seconds ago)
8. 1.500 : 101; true value = 101 (more than one second is elapsed since 101 was used).

However such approach also has such "bug":

1. 99 tp = 99
2. 100 tp = 100
3. 101 tp = 101
4. 102 tp = 102
5. 103 tp = 103
6. 102 tp = 103
7. 101 tp = 103
8. 100 tp = 103
9. 99 tp = 103
10. 98 tp = 98
11. 97 tp = 97

The problem here is that "tp" was "frozen" at level 103 for too long time.

I'm really sorry for such a big question. But probably someone was solving close problem and can share experience. My primary problem is that I do need to solve two opposite problems at the same time:

• "true price" must just be the "last" value under general conditions
• "true price" shouldn't change to often (so I need to use previous values one way or another)
• also it's hard to say when we have "general" conditions and when we have "measurement problems"

So my question is really vague and I just hope that someone was tring to solve something like that. As always "common sense" should be used solving this problem.

解决方案

You want to respond to long-term (low frequency) changes in price, but ignore small short-term (high frequency) fluctuations. So what you need is a low-pass filter.

There are lots of different kinds of low-pass filters with different characteristics. A moving average is one kind of low-pass filter, but it has the problem (which you observe) that it trades smoothing for lag (in order to smooth out high-frequency fluctuations you need to average over quite a long sequence, but then it takes a long time for low-frequency changes to become apparent).

So you might try out the other low-pass filters, for example the exponentially-weighted moving average, and see if they meet your requirements.

The other thing to say about this task is that basing your decision about when you do a recalculation on the nearest integer to your moving average is a bad thing to do, because it amplifies small fluctuations when the moving average is close to halfway between two integers. (If the moving average goes from 99.49 to 99.51 the rounding operation amplifies this small fluctuation to a big one from 99 to 100.)

What you should do instead is use hysteresis to avoid this kind of response. When you do a recalculation, record the current value a₀ of your moving average a, and don't do another recalculation until the moving average a has moved by at least ε, that is, |a − a₀| ≥ ε.

这篇关于如何防止整数序列经常具有相同的值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！