-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Definition of backSample (and shiftSample) #2264
Comments
Comment by cbuerger on 24 Aug 2018 11:06 UTC
is correct. But your example is wrong, because the
I think the description in Ignore the following (see my next comment below); I missed that
in the examples, which is never specified and which I think is actually not true/required. In Dymola we can simulate it with |
Comment by cbuerger on 24 Aug 2018 12:12 UTC
Sorry, that was a false positive.
|
Comment by hansolsson on 24 Aug 2018 14:35 UTC And then shiftSample with resolution is |
Comment by eshmoylova on 27 Aug 2018 16:05 UTC
The example that Hans gave in the description is straight from the specification (definition of backSample, section 16.5.2, Specification 3.4) and is correct for the values given
The clock y2 will not tick at 0 but from then on will tick at the same time as clock u. It's just this example does not match the simplified definition with resolution set to 1 that Hans suggested. To match the definition, the example should be changed to the one that you give, and it will automatically tick at 0 as you specified.
|
Comment by eshmoylova on 27 Aug 2018 16:32 UTC
It should be at least shiftCounter+1:th tick. In the example of Clock(3,10) the first tick is 0, the second is 3/10. If you define shiftSample(u,1) the first tick should be 3/10, which is the second (shiftCounter+1) tick. But I think this is true only if the interval of the base clock is constant, i.e. the clock is periodic. Consider the example of non-periodic clock (from the definition of Clock(intervalCounter,resolution), section 16.3, Specification 3.4):
Let u be Clock(nextInterval,1000) as used above. If you define y1 = shiftSample(u,3) and say the first tick of y1 is shifted by the interval(u)*shiftCounter later you get:
There is also an implicit assumption that it is interval(u) is determined at the time of the first tick of u. It would be nice to make it explicit otherwise the definition is not clear. If you say y1 starts from the shiftCounter+1:th tick of u, you get:
|
Comment by eshmoylova on 27 Aug 2018 17:56 UTC I would like it if it was clearly stated what the interval of shiftSample or backSample is supposed to be. If, indeed, cBase clock is not used in determining the interval of shift- or backSample then it is used only to establish the first tick. Why does it need to be so complicated to define that first tick? In the definition of shiftSample, at least, the use of cBase and its second tick is at least straightforward. In the definition of backSmaple it is quite convoluted. If cBase is used to determine all ticks of shift- and backSample then the examples are incorrect. By the way, the definition of backSample says: It should be "the clock of y = backSample(..)...". |
Comment by hansolsson on 28 Aug 2018 08:13 UTC
Agree.
That seems odd - I'm unsure if you wanted to note that it was odd. The natural solution is that That means that This means that we can start by defining shiftSample(u,1) as skipping the first tick of u, and then using every tick. And the define everything else from that:
|
Comment by eshmoylova on 28 Aug 2018 21:16 UTC
I did intend to illustrate that the idea of the shiftSample without resolution is starting at (cnt+1):th tick is different from the formula given in the Specification for nonperiodic clock. What I did not expect is that Dymola does it the way you described and not using the formula. It looks like the definition of subSample was also given only with periodic clocks in mind. If you say that is factor-times slower it can be interpreted in different ways. Does it mean that if Using I think it would make more clear to rewrite the definition of subSample and shiftSample in terms how they relate to the ticks of the original clock. |
Comment by eshmoylova on 29 Aug 2018 17:25 UTC ...
Clock u = Clock(nextInterval,100);
Clock u2, u3, u4, u5, u6;
equation
when u then
nextInterval = previous(nextInterval) + 1;
y1 = previous(y1) + 1;
end when;
u2 = superSample(u,2);
u3 = shiftSample(u2,5);
u4 = shiftSample(u,5,2);
u5 = shiftSample(u2,5,3);
u6 = superSample(u2,3);
... The ticks are (based on Dymola):
Similarly, Maybe a general rule to construct
|
Conclusions:
Need to be clear that superSample samples equidistantly within each interval.
What about subsample? And backSample the inverse of shiftSample - but the otherwise case is illegal. And add examples. (Easier if we do not have to write this within a table.) |
* Named arguments for clock constructors and conversion operators. Closes modelica#2344 * Clarify exactly how parametric clock expressions must be. Closes modelica#2272 * Clarify clock conversion operators. Closes modelica#2264 * Crop images. Ideally the images should be improved overall, but these really looked weird. * With change proposed at meeting.
Reported by hansolsson on 24 Aug 2018 07:47 UTC
In 16.5.2 Sub-clock conversion operators the operator backSample is defined mixing a conceptual description with words describing parts.
To me it would be clearer if we avoid mixing this, and we could instead use shiftSample to create an implicit equation.
The example is - and I assume it is correct:
Thus without resolution a simple definition is that:
Clock y = backSample(u, cnt) implicitly defines a clock y such that shiftSample(y, cnt) ticks the same as u. (And it is an error if...)
For the resolution I am unsure both about backSample and also n of shiftSample, and the latter also suffers from the same mixing issue:
It says:
"Clock cBase = subSample(superSample(u, resolution), shiftCounter)
and the clock of y = shiftSample(..) starts at the second clock tick of cBase. At every tick of the clock of y, the operator returns the value of u from the last tick of the clock of u."
However, the examples indicate that "shiftCounter=1" means it start at second clock tick, and "shiftCounter=2" means it start at third clock tick etc; and it then returns every sample if resolution is 1 - i.e. no subsampling for resolution=1.
For clarity I also think that
is better than
Migrated-From: https://trac.modelica.org/Modelica/ticket/2264
The text was updated successfully, but these errors were encountered: