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

Component Parameter Type Parameterization #473

Closed
lrennels opened this issue May 7, 2019 · 7 comments
Closed

Component Parameter Type Parameterization #473

lrennels opened this issue May 7, 2019 · 7 comments
Assignees
Milestone

Comments

@lrennels
Copy link
Collaborator

lrennels commented May 7, 2019

Continuation of #469 discussion, deciding the best way to type parameterize the parameters of a component, with options such as:

  1. param::Array{String, 1} = Parameter(index=[time])

  2. paramName::String = Parameter(index=[time])

  3. Avoid overloading Julia syntax and add a keyword to our Parameter definition, e.g.,
    paramName = Parameter(index=[time], type=String)

@lrennels lrennels added this to the Backlog milestone May 7, 2019
@davidanthoff davidanthoff modified the milestones: Backlog, v1.0.0 Oct 11, 2019
@davidanthoff
Copy link
Collaborator

davidanthoff commented Oct 11, 2019

So we go with option 3, but call the parameter eltype, and the old 2 option should error.

@rjplevin
Copy link
Collaborator

Do we want to support syntax option 2 for scalar values? That is, do we allow:

paramName::Int = Parameter(default=42)

or require:

paramName = Parameter(eltype=Int)

We could also keep both and only error when using ::Type when indexes are present.

@davidanthoff
Copy link
Collaborator

I think if we move things into the Parameter constructor, we should probably move everything in there?

But one question is whether we should use eltype for the scalar case... Does that make sense? Doesn't seem too bad...

@corakingdon
Copy link
Collaborator

I thought we were still going to support the (2) syntax, just not for using it to define the eltype of an array. But that the following would be okay:

paramName::Int = Parameter( )    # paramName would be an integer
paramName::String = Parameter( )    # paramName would be a string
paramName::Matrix{Float64} = Parameter( )    # paramName would be a matrix

But this would error, since the index implies that it needs to be an array:

paramName::String = Parameter(index=[time])    # not allowed

@davidanthoff
Copy link
Collaborator

Well, should we? I'm unsure... I almost feel that if we do away with the ::Foo syntax, we should do away with it entirely.

Btw., another option would be p1 = Parameter{Int}(...)... The benefit of this would be that we don't need to use a keyword arg like eltype that might be wrong for the scalar case.

@rjplevin
Copy link
Collaborator

rjplevin commented Oct 11, 2019

p1 = Parameter{Int}(...)

I like that, though it's somewhat more complicated for less-Julia-expert modelers.

@corakingdon
Copy link
Collaborator

(I'm just writing this down now so we don't forget what we agreed on. I'm going to start trying to implement soon)

We will implement:

p1 = Parameter{Int}()    # ScalarModelParameter that is an Int
p2 = Parameter{Int}(index = [regions])    # ArrayModelParameter whose eltype is Int

p3 = Parameter{Matrix{Float64}}()    # ScalarModelParameter that is a Matrix

Basically, if there are "index"s listed in the Parameter definition, then it will be an ArrayModelParameter whose eltype is the type specified in the curly brackets. If there are no "index"s listed, then the type specified in the curly brackets is the actual type of the parameter value, and it will be represent by Mimi as a ScalarModelParameter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants