Skip to content
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

Restriction on clock expressions being parameteric #2272

Closed
modelica-trac-importer opened this issue Nov 4, 2018 · 2 comments
Closed

Restriction on clock expressions being parameteric #2272

modelica-trac-importer opened this issue Nov 4, 2018 · 2 comments
Labels
bug Something isn't working decided A decision has been made (label added before the spec is changed)

Comments

@modelica-trac-importer
Copy link
Collaborator

Reported by eshmoylova on 11 Oct 2018 14:19 UTC
Restrictions on clock variables are specified in Section 16.3 (Specification 3.4) as follows.
Clock variables can be used in a restricted form of expressions. Generally, every expression containing clock variables must have parametric variability [in order that clock analysis can be performed when translating a model.]....

What does it mean? If taken literally, the expression

xd = sample(x,c);

where x is a continuous variable, xd is a clocked variable, and c is a clock variable should be illegal. Or what about clocks with non-parametric intervals?

Clock c = Clock(nextInterval,1000);

where nextInterval is a clocked variable, technically falls under the category of "every expression" and it does not have the parametric variability.

I think it should be specified more clearly what "every expression" means or what is meant by the parametric variability. It would make sense to me that if there is a for-loop in which a clock variable or a clock constructor occurs then the bounds of the for-loop must be parametric. Or the conditions of an if-expression in the example later in this section must be parametric:

  • If-expressions of clocks in equations [Example: Clock c2 = if f>0 then subSample(c1, f) elseif f < 0 then superSample(c1, f) else c1].

Migrated-From: https://trac.modelica.org/Modelica/ticket/2272

@HansOlsson
Copy link
Collaborator

HansOlsson commented Nov 27, 2018

I think it should be specified more clearly what "every expression" means or what is meant by the parametric variability.

I also think that is the key. Subscripts on Clock-variables, conditions for switching between Clock-variables, and subsample/superSample factors for Clock variables must be parameter expressions.

Note that Clock(sin(time)>0) is allowed, i.e. the clock themselves can be constructed using discrete expressions, it's the relation-ship between clocks that must parametric.

However, I realize a related flaw. Consider:
Clock c2 = if f>0 then subSample(c1, f) elseif f < 0 then superSample(c1, f) else c1;
What is the right-hand side?
Should we call it a "Clock expression" and have "Clock variable" as a special case of it?

@HansOlsson HansOlsson modified the milestones: Design97, Design98 Jan 15, 2019
@HansOlsson HansOlsson added the decided A decision has been made (label added before the spec is changed) label May 13, 2019
@HansOlsson HansOlsson modified the milestones: Design98, ModelicaSpec3.5 May 13, 2019
@HansOlsson
Copy link
Collaborator

Language group:

The restrictions on subsample and superSample (as well as shiftSample and backSample) are already there so only specify that subscripts on Clock-variables, and conditions for switching between Clock-variables must be parameter expressions.

Agreement by acclamation.

HansOlsson added a commit to HansOlsson/ModelicaSpecification that referenced this issue Jul 12, 2019
christoff-buerger pushed a commit to christoff-buerger/ModelicaSpecification that referenced this issue Oct 3, 2019
* 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working decided A decision has been made (label added before the spec is changed)
Projects
None yet
Development

No branches or pull requests