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

control order in which fit parameters appear in gui (Trac #348) #483

Closed
RichardHeenan opened this issue Mar 30, 2019 · 7 comments
Closed
Assignees
Labels
Blocker Prevents a different issue from being resolved Enhancement Feature requests and/or general improvements
Milestone

Comments

@RichardHeenan
Copy link
Contributor

RichardHeenan commented Mar 30, 2019

Suspect that the current “almost alphabetical” order for most but not all models is an “accident” due to python dictionaries.

\models\c_extension\python_wrapper\WrapperGenerator.py, ~line 328, routine write_c_wrapper produces a python type dictionary by:

for par in self.params: param_str += "
PyDict_SetItemString(self->params,"%s",Py_BuildValue("d",%10.12f));\n" % \ (par, self.params[par])

The main parameter dictionary may then have the polydispersity parameters added on to it. Alas python dictionaries are assembled in random order due to use of hash tables.

When a model is loaded “param_list” is acquired via

\sas\models\BaseModel.py, ~line 125.

def getParamList(self):
    param_list = self.params.keys()
    return param_list

[Note that many other places have similar routines for other parts of sasview.]

Would it be possible to use an ordered dictionary, in order to keep parameter in a particular order, such as the order in which the default values appear.

Paul Kinsell warns that there will be consequences for the way he passes parameters to fitting routines.

Migrated from http://trac.sasview.org/ticket/348

{
    "status": "closed",
    "changetime": "2016-03-20T11:46:32",
    "_ts": "2016-03-20 11:46:32.824365+00:00",
    "description": "\nSuspect that the current \u201calmost alphabetical\u201d order for most but not all models is an \u201caccident\u201d due to python dictionaries.\n\n\\models\\c_extension\\python_wrapper\\WrapperGenerator.py, ~line 328, routine write_c_wrapper produces a python type dictionary  by:\n\n for par in self.params: param_str += \"        \nPyDict_SetItemString(self->params,\\\"%s\\\",Py_BuildValue(\\\"d\\\",%10.12f));\\n\" % \\      (par, self.params[par])\n\nThe main parameter dictionary may then have the polydispersity parameters added on to it. Alas python dictionaries are assembled in random order due to use of hash tables.\n\nWhen a model is loaded \u201cparam_list\u201d is acquired via \n\n\\sas\\models\\BaseModel.py, ~line 125.\n\n    def getParamList(self):\n        param_list = self.params.keys()\n        return param_list\n\n[Note that many other places have similar routines for other parts of sasview.]\n\nWould it be possible to use an ordered dictionary, in order to keep parameter in a particular order, such as the order in which the default values appear.\n\nPaul Kinsell warns that there will be consequences for the way he passes parameters to fitting routines.\n",
    "reporter": "richardh",
    "cc": "",
    "resolution": "fixed",
    "workpackage": "SasView GUI Enhancements",
    "time": "2015-02-18T15:33:05",
    "component": "SasView",
    "summary": "control order in which fit parameters appear in gui",
    "priority": "blocker",
    "keywords": "",
    "milestone": "SasView 4.0.0",
    "owner": "richardh",
    "type": "enhancement"
}
@RichardHeenan RichardHeenan added this to the SasView 4.0.0 milestone Mar 30, 2019
@RichardHeenan RichardHeenan self-assigned this Mar 30, 2019
@RichardHeenan RichardHeenan added Blocker Prevents a different issue from being resolved Enhancement Feature requests and/or general improvements Incomplete Migration and removed Incomplete Migration labels Mar 30, 2019
@butlerpd
Copy link
Member

Trac update at 2015/03/10 16:39:05:

  • butler commented:

This while be a lot of work in current framework and unlikely to be achieved in time and while a very nice addition not critical for a release. Further there is a real question of whether it won't just be easier as part of sasmodels project. Thus moving to next release for now. Then we can discuss best course of action

  • butler changed milestone from "SasView 3.1" to "SasView Next Release +1"

@butlerpd
Copy link
Member

Trac update at 2015/03/22 22:51:48: butler changed workpackage from "SasView Bug Fixing" to "SasView GUI Enhancements"

@butlerpd
Copy link
Member

Trac update at 2015/08/14 20:02:44: butler changed milestone from "SasView Next Release +1" to "SasView 4.0.0"

@butlerpd
Copy link
Member

Trac update at 2016/03/06 18:24:59:

  • butler commented:

This should be part of the new sasmodels work. It may be a duplicate of #496 but may be best to think of this as the !SasView GUI interfacing to the new sasmodels properly while ticket #496 refers to building the new sasmodels in a way that makes it easier for the GUI to do this.

Either way it should be part of one of the 6 core tasks for this release so making it blocker.

  • butler changed priority from "major" to "blocker"

@butlerpd
Copy link
Member

Trac update at 2016/03/06 21:03:16:

  • butler commented:

Once all models are converted, suggest Richard look at the order and make sure it makes sense from a user perspective?

  • butler changed owner from "" to "richardh"
  • butler changed status from "new" to "assigned"

@gonzalezma
Copy link
Contributor

Trac update at 2016/03/18 12:09:46: gonzalezm commented:

Solved for single models only.

@ajj
Copy link
Member

ajj commented Mar 30, 2019

Trac update at 2016/03/20 11:46:32:

  • ajj commented:

Miguel has fixed this for single models from sasmodels i.e. not easy sum/multi.

Closing this as "good enough for 4.0" and will open lower priority tickets for sum/multi and user provided models.

  • ajj changed resolution from "" to "fixed"
  • ajj changed status from "assigned" to "closed"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Blocker Prevents a different issue from being resolved Enhancement Feature requests and/or general improvements
Projects
None yet
Development

No branches or pull requests

4 participants