Opened 6 years ago
Closed 6 years ago
#5135 closed defect (fixed)
PartialFunctionApplication lookup fails in model
Reported by: | Owned by: | Per Östlund | |
---|---|---|---|
Priority: | high | Milestone: | 2.0.0 |
Component: | New Instantiation | Version: | |
Keywords: | Cc: |
Description
The argument value lookup for partially applied function in a model doesn't work correctly. It seems that the default values are searched relative to the function call and not relative to the function location. In one case the value seems to be uninitialized.
Attachments (1)
Change History (10)
by , 6 years ago
Attachment: | PartialApplication.mo added |
---|
comment:1 by , 6 years ago
Component: | *unknown* → New Instantiation |
---|---|
Milestone: | Future → 2.0.0 |
Owner: | changed from | to
follow-up: 3 comment:2 by , 6 years ago
So you agree, that this model is correct Modelica? That would solve many issues for me.
follow-up: 4 comment:3 by , 6 years ago
Replying to c.schulze@…:
So you agree, that this model is correct Modelica?
As I understand it, what you have in the test is not really partial function application (which is described in Section 12.4.2.1 of the Modelica specification) but rather a short class definition, as described in Section 4.5.1.
I'm not sure you can bind a function input to a time-varying variable, because that makes the function impure, so unless you declare it as impure, it should be illegal according to Section 12.3.
@perost, can you please comment on this?
follow-ups: 5 8 comment:4 by , 6 years ago
Replying to casella:
Replying to c.schulze@…:
So you agree, that this model is correct Modelica?
As I understand it, what you have in the test is not really partial function application (which is described in Section 12.4.2.1 of the Modelica specification) but rather a short class definition, as described in Section 4.5.1.
Correct, it just declares a new function where the input has a default value.
I'm not sure you can bind a function input to a time-varying variable, because that makes the function impure, so unless you declare it as impure, it should be illegal according to Section 12.3.
I'm not sure it would make the function impure, the default argument is just a provided argument to use if the user chooses to not provide one. It doesn't change the function behaviour, only how the function is called. Of course, the function might look impure from a user perspective if the default argument is used.
Anyway, all of the example models in the attached file seem to work just fine with the new instantiation.
follow-up: 7 comment:5 by , 6 years ago
Replying to perost:
I'm not sure you can bind a function input to a time-varying variable, because that makes the function impure, so unless you declare it as impure, it should be illegal according to Section 12.3.
I'm not sure it would make the function impure, the default argument is just a provided argument to use if the user chooses to not provide one. It doesn't change the function behaviour, only how the function is called. Of course, the function might look impure from a user perspective if the default argument is used.
@perost I'm not sure I understand your argument. Modelica functions are expected to be pure, i.e. always provide the same result when called with the same input values. Do you mean that in this case the inputs are not the same because of the binding to the time-varying variable, so the funciton is still pure?
Of course the situation would be different in case of partial application, because then you really have a new function and the bound inputs are gone.
comment:6 by , 6 years ago
I don’t think it is impure, you still can override the default value. Some tools seem to have problems with the lookup of the default argument.
comment:7 by , 6 years ago
Replying to casella:
Replying to perost:
I'm not sure you can bind a function input to a time-varying variable, because that makes the function impure, so unless you declare it as impure, it should be illegal according to Section 12.3.
I'm not sure it would make the function impure, the default argument is just a provided argument to use if the user chooses to not provide one. It doesn't change the function behaviour, only how the function is called. Of course, the function might look impure from a user perspective if the default argument is used.
@perost I'm not sure I understand your argument. Modelica functions are expected to be pure, i.e. always provide the same result when called with the same input values. Do you mean that in this case the inputs are not the same because of the binding to the time-varying variable, so the funciton is still pure?
Of course the situation would be different in case of partial application, because then you really have a new function and the bound inputs are gone.
Is this function pure or impure?
function f input Real x = time; output Real y = x; end f;
Calling the function with f(time)
it's undoubtedly pure, because it doesn't matter if the argument is time-varying or not, only that the function gives the same result for the same input. Does calling it without an argument like f()
then make it impure? I would say not, since f()
is actually translated into f(time)
by OMC as per the specification (12.4.1), which also says that the calls are equivalent.
comment:8 by , 6 years ago
Replying to perost:
Anyway, all of the example models in the attached file seem to work just fine with the new instantiation.
OK, so based on this comment I understand I can close this ticket for 2.0.0, when the new front-end will become the default. @c.schultze, until then, you may try to run your models with -d=newInst
.
I would suggest that you use the latest nightly build to maximize the chance that there are no other issues when using the new front-end.
comment:9 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
@c.schulze, this issue is currently being addressed by @perost in the new front-end, see #4837. You may check the behaviour with
-d=newInst
when #4837 is closed, then the new front end will become the default in version 2.0.0.The current front end will be abandoned soon, so we won't fix the issue there.