February 2, 2014 at 09:39 #930
I need to establish the context for this request so apologies in advance for what must seem like I am telling you about your own very capable program’s behaviour.
The QtFuzzylite control screen input mu value sliders start at zero the first time you switch to the control screen after opening an existing FLL file. You can select the desired input mu value by either sliding the slider for that input, using the up and down arrows associated with the control/display box, or typing a value into the control/display box above the graph. When you hit return or tab away from the control/display box after typing in a number, the value in the box snaps to what I assume is the nearest value that can be represented on the screen based on what seems to be some sort of arbitrary subdivision of the displayed range. If you use the slider or control/display box up and down arrows, the values displayed in the box increment and decrement based upon what seems to be some internally selected delta value.
I think it would be better when the user types a specific value into the box if that value was kept exactly and the slider position moved to the nearest value. I don’t expect a user would get out a ruler and start measuring values on their screen so it would not matter if the displayed slider position was not exactly the same as what is displayed in the control box for that input. For me, what is important is the value used in the underlying calculations. My Arduino based FLC uses a mixture of ints for input term specification and floats elsewhere, to save very limited memory and a little processing time. To check behaviour of my FLC implementation, I find myself wanting to enter whole number values into the control/display boxes.
For instance, for a mu of 106.000 the sliders will let me select 103.888 or 106.908 with a delta of 3.02. Another time when I run QtFuzzylite it selects values of 105.700 and 108.720, also with a delta of 3.02. Interestingly, if I enter 106.002 the value is not replaced and displays OK. When I enter 106.002 and it sticks, the up/down arrows then let me select values of 102.982, 106.002 and 109.022, also with a delta of 3.02. When I subsequently use the slider the 106.002 seems to be replaced by some internally chosen value. Having made the 106.002 value stick, I sort of expected subsequent slider movements would have maintained this value as part of the range of values used. Is this behaviour a function of the Qt GUI or something you have some control over? This input has a range of -151 to 151.
What I really want to do is enter 106.000 and 2.000 for my second input. The second input has a range of -25 to 25 and behaves OK, letting you select values with the up/down arrows in increments of 0.500 exactly. If I type in the single digit 2 for my second input variable, as expected it is replaced by 2.000 when I hit return or tab away from the control.
Interestingly, if I enter 2.001 it sticks and subsequent up/down arrow increments select 1.501, 2.001 and 2.501. When I subsequently move the slider, a different range of numbers is then used. It seems that value selection is different depending upon whether slider movement or the up/down arrows are used to make changes.
Is it possible to retain user entered input values exactly, please. If this is done, I suppose the problem then becomes a matter of what do you do with the up/down arrow increment value and also subsequent slider movements. If this is too hard, how about using and displaying the user entered value precisely for the first computational pass after it is entered and moving the slider to the nearest approximate point on the graph? For subsequent arrow or slider driven changes after the exact user entered value is used once, you could return to the internally selected values based upon the delta value presently deployed. I was sort of expecting up/down arrow and slider selected changes to track. Maybe they do and I have not seen it yet. I suppose the issue then becomes one of the resolution associated with the arrows (+/- 0.001) and that achievable with the slider.
If this change is not worthwhile for you, I have still found QtFuzzylite to be extremely useful as it stands now.
BrianFebruary 2, 2014 at 10:18 #931
thank you very much for your kind words and for taking the time to describe the issue. I totally agree with the behaviour that you expect. At the moment, my guess is that the value you are entering in the QDoubleSpinBox gets reflected in the QSlider, which cannot represent every floating-value that you enter and then rounds to the nearest possible value, which then triggers another signal to the QDoubleSpinBox and changes its value. As for the delta increments, I honestly cannot remember what I did for those. I think the delta increment changes according to the range of the variable, the resolution of the QSlider, or maybe both (range/resolution).
At the moment, I am working on a new version of QtFuzzyLite from scratch, taking much more care on the details, and a much better design. I will address the issues you have mentioned in the new version, which I expect to release late February or early March. As soon as I have a working version, if you are interested, I could build the binaries for you so you can test it and let me know your suggestions. Otherwise, if you prefer to modify the source code of the current version, I think all you need to do is increase the range of the QSliders.
If you have more feature requests, please feel free to post them! It is a good time since I am working many hours during the week on (qt)fuzzylite.
Juan.February 2, 2014 at 11:41 #932
Thank you for the very prompt reply.
I do not have any worthwhile experience with fuzzy logic so I am not certain I would be of any use to you as a tester. I expect you would be better off with someone with a great deal of knowledge and experience with fuzzy to make the testing process more meaningful and any results obtained more useful to you. However, if you need someone for basic look and feel testing I could perhaps be of some use.
Seems like the delta increment is set to 1% of the range value at present. It sounds like the near instantaneous feedback from Qslider to the QDoubleSpinBox is the culprit. This may work OK when you are sliding the slider but is a pain following manual data entry. Sounds like the feedback needs to be deactivated only for manual data entry cases, if that is at all possible. The up/down arrows probably complicate matters here. Could there be a tick box somewhere to temporarily deactivate this feature? This box would NOT be ticked by default and could reset to inactive every time you switched to the control screen.
BrianFebruary 2, 2014 at 16:17 #933
At the moment, the only option to fix the behaviour you are seeing is to increase the range of the QSliders and build from source, unfortunately. In version 5.0, it will be far easier to fix that without building from source. The behaviour you are seeing is somewhat necessary as both must be in sync: moving slider changes value, changing value moves slider.
As for testing, I did not mean anything exhaustive whatsoever. Just making sure the issues you have mentioned have been addressed in 5.0 would be enough. I like very much the details, like the ones you have mentioned, that’s all.
You must be logged in to reply to this topic.