Release candidate available

When you are back to your Win10 laptop, could you please check what you get for these commands?

>> getenv('NUMBER_OF_PROCESSORS')
ans = 4
>> system('wmic CPU Get NumberOfCores')
NumberOfCores
4

ans = 0
>> system('wmic CPU Get NumberOfEnabledCore')  # Only available since Windows 10
NumberOfEnabledCore
4

ans = 0
>> system('wmic CPU Get NumberOfLogicalProcessors')
NumberOfLogicalProcessors
4

ans = 0
>> getenv('NUMBER_OF_PROCESSORS')
ans = 16
>> system('wmic CPU Get NumberOfCores')
NumberOfCores
8

ans = 0
>> system('wmic CPU Get NumberOfEnabledCore')
NumberOfEnabledCore
8

ans = 0
>> system('wmic CPU Get NumberOfLogicalProcessors')
NumberOfLogicalProcessors
16

ans = 0
>>

Thanks.
I assume openblas_get_num_threads () returns 16?

Yes.

                                                                                                     
>> cd Downloads/
>> mkoctfile openblas_get_num_threads.cc
>> openblas_get_num_threads
ans = 16
>>

BTW I installed octave-2021-06-08-00-28-default-w64-installer.exe from octave.space.
Test eigs passes, test subplot fails. So it appears to be a bug in openblas.

p.s. Fedora 34 has openblas 0.3.15

Hmm… We might want to update OpenBLAS in that case.
However, that change would have a bigger impact (than the updated Octave Forge package).

@jwe and others: Do we want to do that anyway? If I understand correctly, some numeric operations are failing on some CPUs with the version of OpenBLAS that we are currently packaging.
Is that enough of a reason for an update?
If we do, should we create a new candidate of the Windows installer?

Anyway, I played around a little bit with the .vbs script.
@dasergatskov: Could you replace the octave.vbs in Octave’s installation folder with the one here?
octave.vbs (3.3 KB)
Does that set the OPENBLAS_NUM_THREADS correctly?

@dasergatskov: In the meantime, could you please show a screenshot of the figure after these commands?

close all
figure ();
for ii = 1:9
  hax(ii) = subplot (3,3,ii);
endfor
subplot (2,1,1);

For me, it looks like this:

It appears to work:

>> getenv('NUMBER_OF_PROCESSORS')
ans = 16
>> cd Downloads/
>> openblas_get_num_threads
ans = 8
>>
1 Like

Here is with qt

and with gnuplot

Does it make a difference if you run the commands line by line or in a script?

@mmuetzel: If it fixes some bugs, then it’s fine with me to update the OpenBLAS version. I also don’t mind creating a new release candidate but it may take a day or two for me to create and upload.

Does not make any difference. I also tried to add pause() here and there, but it is all the same.
Also “demo subplot” seems to run fine.

I grafted the OpenBLAS update to the release branch here:
mxe-octave: 580d6e6b0025

IIUC, subplot should delete axes which it is overlapping. For some reason that doesn’t seem to be happening for you.
Is the extent calculated correctly?
For me:

>> close all
>> figure ();
>> for ii = 1:9
  hax(ii) = subplot (3,3,ii);
endfor
>> get(hax(4), 'position')
ans =

   0.1300   0.4255   0.1818   0.1840

>> hax_new = subplot (2,1,1);
>> get(hax_new, 'position')
ans =

   0.1300   0.5999   0.7750   0.3251

Also: Is this a regression? Does it work correctly in Octave 6.2 or Octave 5.2?

>> figure()
>> for ii=1:9 hax(ii) = subplot(3,3,ii); endfor
>> get(hax(4), 'position')
ans =

   0.1300   0.4421   0.1576   0.1508

>> hax_new = subplot (2,1,1);
>> get(hax_new, 'position')
ans =

   0.1300   0.6248   0.7750   0.3002

>>

the problem in 6.2. I have not tried anything older.

Hu. It looks like it claims that the axes are smaller for you than they are for me.
Is the figure the same size?
For me:

>> close all
>> hf = figure;
>> get(hf, 'position')
ans =

   300   204   560   416

Anyway, since this is not a regression, I don’t think it should block the release.
Should we move that to a bug report on savannah?

Slightly off. I wonder if this is due to hi-res display scaling.

>> hf = figure()
hf = 1
>> get(hf, 'position')
ans =

   300   207   560   413

>>

Does it have to do with the height of the button bar (which seems to be different for you and for me)?
I also noticed that the figure position doesn’t match the default position for me:

>> get(groot, 'defaultfigureposition')
ans =

   300   200   560   420

Not sure where the 4 pixels difference comes from.
Definitely deserves a bug report if we don’t have one yet.

this is the same:

>> get(groot, 'defaultfigureposition')
ans =

   300   200   560   420

>>

It’s def something to do with high-resolution display.
I’ve changed scaling (from 200% to 150% to 100%) – no change, test is failing.
Then I was reducing the resolution from its natural (3840x2160) down;
it was still failing at 2014x1536, but passed at 2048x1152 and below.
I will fill a bug report shortly.

p.s. Done: GNU Octave - Bugs: bug #60759, test subplot fails on hi-res... [Savannah]