BUG: SOM widget does not remember grid dimensions

[dsanalytics]

Upon opening previously saved workflow, SOM widget in most cases resets its grid size to 5x5 no matter what's been set and saved previously. Sometimes and rarely, it does remember its width, but reset to 5x5 is the most common. No errors or crashes. Thanks in advance for your time.

Orange: v3.23.1
OS: Windows 7 SP1 64bit Home Premium

[janezd]

Did you start the optimization after changing the grid size? If you don't, it won't "apply" and store your changes. If you do, it should. And it works for me.

... except that I found a bug related to the height. Width should be stored and retrieved properly. If it's not, please describe, step by step, how to replicate it. Thanks.

[dsanalytics]

I tested it again and noticed that width also resets to the previous value even after optimization is applied.

This is what I've done. I changed SOM width to 15 and height to 15, run optimize, saved workflow, closed Orange, reopened the same workflow, the width shows 15 and height 5, changed the width to 20 and height to 15, run optimize, saved workflow, closed Orange, reopened the same workflow, the width shows 15 and height shows 5. Saved the workflow again without changing either, reopened the same workflow, the width shows 5 and height 5. There's something going on behind the scenes when workflow is being saved as it pertains to SOM.

Hope this helps.

[ajdapretnar]

I can't replicate this. Width and height get saved correctly for me. I tried about 4 different versions. The only thing that happens is when I change the width and height and not run optimization, then they don't get saved. Which is some way makes sense.

[janezd]

Please don't close this yet. If I remember correctly (but I'm not sure), I could replicate.

I am not too happy with the logic of the widget. Not saving settings unless optimization is run is a design choice forced by my inability to properly implement and interrupt optimization threads. So this part stays (for now?), but I have to fix the bug if I can replicate it.

[dsanalytics]

Ajda, are you testing this on Mac or Windows? Which multi-threading OSS lib is used in O3?

P.S.1 In general, one would expect SOM size settings to be saved if workflow is saved even if optimization is not run.

P.S.2 I'm happy to have SOM in O3, so that I can retire O2. Thanks for implementing it.

[ajdapretnar]

I am testing this on OSX 10.13.6.

We use AnyQt with some extras: https://github.com/biolab/orange3/blob/37e7b0232760ec39b8206a578f63449fdd004615/Orange/widgets/utils/concurrent.py
SOM uses just AnyQt.

[janezd]

Actually, I can't replicate this. Have you tried it on the current master (not just the latest release)?

If it doesn't work on master, it could be related to saved settings from before the fix. Can you clear settings (Options / Reset widget settings), restart Orange and start with a new schema from scratch? Does the problem still appear?

PS. I agree the settings should be saved without applying optimization. But it would be too annoying to implement before somebody properly implements optimization threads. (We use Qt's threads.)

[dsanalytics]

I believe I found the problem - width gets overwritten by height and height is then reset to default (5). Use different non-default values for both and test with saving the workflow with SOM, closing Orange, and reopening the same workflow. It seems like a typo bug in the assignment code.

[janezd]

Yes, of course, this is happenning in the last released version. But have you checked the last version from Github? I believe I fixed this problem in #4097 -- here: https://github.com/biolab/orange3/pull/4097/files.

[dsanalytics]

No, I have not. I usually use only official releases published in https://orange.biolab.si/download/files/ When is the next official release planned? By the way, yes, #4097 seems to be the one.

[janezd]

I think we haven't fixed the date for our next release. It should be in a few weeks.