Sun 30 Oct 2016 03:36:53 PM UTC, comment #11:
2016a:
|
Sun 30 Oct 2016 03:18:58 PM UTC, comment #10:
With matlab 2015a
|
Tue 25 Oct 2016 12:13:19 AM UTC, comment #9:
For completeness, can this test be run under Matlab?
This checks that the Parameters field is being used to order the output in Results, and also whether the Parameters list is held in alphabetical order.
|
Fri 21 Oct 2016 03:47:01 PM UTC, comment #8:
What I am trying to achieve is something similar to the way graphics properties are handled. Every object has a core set of graphics properties that are listed first, followed by the list of properties that are specific to the object in question.
From a user perspective, I think it will be easiest to understand if the core set of ODE solver options is presented first and in alphabetical order, followed by any customized properties supplied by the user.
One way to achieve that is to have full Matlab compatibility for the inputParser function. The other would be to post-process the Results structure with orderfields(), but it sounds like Carlo has an approach that will work.
|
Fri 21 Oct 2016 02:30:53 PM UTC, comment #7:
@Carnë
While trying to prepare a patch to avoid changing the order of parameters with "parse ()" I noticed that "Switches" are not available in Matlab, why do we have that in Octave? Is there
some backward compatibility we need to keep?
|
Fri 21 Oct 2016 02:12:45 PM UTC, comment #6:
@Rik
For completeness here's the result of the test you asked:
|
Fri 21 Oct 2016 02:07:12 PM UTC, comment #5:
@Rik
Matlab does not keep struct keys sorted alphabetically
they are ordered according to the order in which they
were added to the struct.
Indeed the properties returned by odeset are not in
alphabetical order in Matlab either:
on the other hand they do not change with each assignment.
@Carnë
In inputParser.parse () the values passed are assigned first,
then the the remaining Parameters are assigned the default value.
If we would assign the default value to all parameters first,
then overwrite those passed to parse we would get the same behaviour
as Matlab, and it would propbably also run a bit faster.
But you are right that this does not seem to be a documented Matlab
feature so we don't necessarily need to copy it.
|
Fri 21 Oct 2016 11:24:22 AM UTC, comment #4:
> It may be that Matlab always maintains struct keys in sorted order.
Matlab struct keys are ordered by insertion. But Results does not have values inserted until parse is called. This is the same in Matlab addParameter/addParamValue
The actual order of insertion is kept, in Parameters:
If Matlab Results has the same order of values as the order of add*, then that's an implementation detail. And an undocumented one. Since Results is a struct, the type of thing where order of keys does not usually matter, what is the use case for this?
Also, is this a Matlab compatibility issue? There are more functions in Octave that return structs where the order of keys differ from Matlab.
|
Fri 21 Oct 2016 04:02:26 AM UTC, comment #3:
To see whether Matlab internally orders struct fields try
It may be that Matlab always maintains struct keys in sorted order.
|
Thu 20 Oct 2016 07:48:05 PM UTC, comment #2:
inputParser does not change the order of Results because Results is empty before parse.
Is this bug really about the order of values in Results (a scalar struct) or about the display method?
|
Thu 20 Oct 2016 03:22:56 PM UTC, comment #1:
@Carlo: Could you run one more test in Matlab to see if it always sorts the return values by Parameter name, or whether it uses the order in which parameters were added to the inputParser.
|
Wed 19 Oct 2016 10:37:50 PM UTC, original submission:
The following example demonstrates the issue
In Matlab 2016a:
In Octave 4.2-rc2:
|