8:14 a.m.
Dear all,
arima command gives somewhat inconsistent results:
1) estimates are different from ones on Ubuntu and Windows 8
2) estimates are different when there are more than one
call of the same model inside an user-specified function
To be more precise:
linux_2_arma.inp is the script to illustrate the problem
linux_2_arma_output was obtained on April's git on Ubuntu 16.10, 64
The results are the same as ones from 09.05 snapshot on Windows 8, 64
(linux_2_arma_output)
Output from 09.05 snapshot on Windows 10, 64 is in win10_try_res.txt
Also with --x12-arima option output on W-10 is ok
Oleh
8:38 p.m.
On Thu, 7 Sep 2017, oleg_komashko(a)ukr.net wrote:
Dear all,
arima command gives somewhat inconsistent results:
1) estimates are different from ones on Ubuntu and Windows 8
2) estimates are different when there are more than one
call of the same model inside an user-specified function
To be more precise:
linux_2_arma.inp is the script to illustrate the problem
linux_2_arma_output was obtained on April's git on Ubuntu 16.10, 64
The results are the same as ones from 09.05 snapshot on Windows 8, 64
(linux_2_arma_output)
Output from 09.05 snapshot on Windows 10, 64 is in win10_try_res.txt
Also with --x12-arima option output on W-10 is ok
Thanks for the report, Oleh.
There are two points here: (1) difference in arima output between
Linux and Windows 10; and (2) difference in arima output across two
calls to estimate the same model in the context of a function.
On (1) we need to look into this, but since the Linux and Windows
builds use different compilers, small differences in results for
nonlinear problems are expected. I'm not yet sure whether the
differences in question are small enough to be ignorable, but we'll
see.
On (2) it seems there must be a bug somewhere -- particularly since
two successive calls to estimate the same arima model in a "main"
script (not in a function) produce identical results. On initial
inspection it seems that initialization (via NLS) is producing
different starting parameter values in the two calls to "arma"
within a function, though not outside of a function. I don't yet
understand why that should be, but hopefully I'll have something to
report before long.
Allin
9:56 p.m.
Dear Allin,
Note that Windows 8 gives absolutely the same visible
digits as Linux. Also, these estimates have at least 4
coinciding digits in comparison with using --x-12-arima
In contrast, for the constant we have 10% difference
between Windows 10 and (the same) Linux, Windows 8,
and (almost the same --x-12-arima).
So it is very unlikely due to rounding errors.
Also, I used --verbose option: the initialization steps
were different on Windows 10.
I think, it may be more convenient to compare Windows 8 (which is obviously
correct)
and Windows 10: they have more in common in comparison with Linux.
Oleh
7 вересня 2017, 23:38:41, від "Allin Cottrell" <cottrell(a)wfu.edu>:
> On Thu, 7 Sep 2017, oleg_komashko(a)ukr.net wrote:
> Dear all,
> arima command gives somewhat inconsistent results:
> 1) estimates are different from ones on Ubuntu and Windows 8
> 2) estimates are different when there are more than one
> call of the same model inside an user-specified function
> To be more precise:
> linux_2_arma.inp is the script to illustrate the problem
> linux_2_arma_output was obtained on April's git on Ubuntu 16.10, 64
> The results are the same as ones from 09.05 snapshot on Windows 8, 64
> (linux_2_arma_output)
> Output from 09.05 snapshot on Windows 10, 64 is in win10_try_res.txt
> Also with --x12-arima option output on W-10 is ok
Thanks for the report, Oleh.
There are two points here: (1) difference in arima output between
Linux and Windows 10; and (2) difference in arima output across two
calls to estimate the same model in the context of a function.
On (1) we need to look into this, but since the Linux and Windows
builds use different compilers, small differences in results for
nonlinear problems are expected. I'm not yet sure whether the
differences in question are small enough to be ignorable, but we'll
see.
On (2) it seems there must be a bug somewhere -- particularly since
two successive calls to estimate the same arima model in a "main"
script (not in a function) produce identical results. On initial
inspection it seems that initialization (via NLS) is producing
different starting parameter values in the two calls to "arma"
within a function, though not outside of a function. I don't yet
understand why that should be, but hopefully I'll have something to
report before long.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.eduhttp://lists.wfu.edu/mailman/listinfo/gretl-devel
11:42 p.m.
On Fri, 8 Sep 2017, oleg_komashko(a)ukr.net wrote:
Dear Allin,
Note that Windows 8 gives absolutely the same visible
digits as Linux. Also, these estimates have at least 4
coinciding digits in comparison with using --x-12-arima
In contrast, for the constant we have 10% difference
between Windows 10 and (the same) Linux, Windows 8,
and (almost the same --x-12-arima).
So it is very unlikely due to rounding errors.
Also, I used --verbose option: the initialization steps
were different on Windows 10.
I think, it may be more convenient to compare Windows 8 (which is obviously
correct)
and Windows 10: they have more in common in comparison with Linux.
Comparing Windows 8 with Windows 10 is not meaningful unless you're
using exactly the same gretl package on both platforms (same
build-date, same word-length): I update my cross-compilers for
32-bit and 64-bit Windows from time to time, and also update the
OpenBLAS sources from time to time. And I'm not in a position to
test on Windows 8 any more, though I can test on Windows 10; I'll do
so when I next get a chance.
Allin
12:18 a.m.
May be, this info would be useful.
I have just downloaded and unpacked
gretl-win32.zip
It gives the same as Linux and Windows 8,
i.e. it works correctly on Windows 10, 64
Oleh
8 вересня 2017, 02:43:03, від "Allin Cottrell" <cottrell(a)wfu.edu>:
> On Fri, 8 Sep 2017, oleg_komashko(a)ukr.net wrote:
> Dear Allin,
> Note that Windows 8 gives absolutely the same visible
> digits as Linux. Also, these estimates have at least 4
> coinciding digits in comparison with using --x-12-arima
> In contrast, for the constant we have 10% difference
> between Windows 10 and (the same) Linux, Windows 8,
> and (almost the same --x-12-arima).
> So it is very unlikely due to rounding errors.
> Also, I used --verbose option: the initialization steps
> were different on Windows 10.
> I think, it may be more convenient to compare Windows 8 (which is obviously
> correct)
> and Windows 10: they have more in common in comparison with Linux.
Comparing Windows 8 with Windows 10 is not meaningful unless you're
using exactly the same gretl package on both platforms (same
build-date, same word-length): I update my cross-compilers for
32-bit and 64-bit Windows from time to time, and also update the
OpenBLAS sources from time to time. And I'm not in a position to
test on Windows 8 any more, though I can test on Windows 10; I'll do
so when I next get a chance.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.eduhttp://lists.wfu.edu/mailman/listinfo/gretl-devel
12:25 a.m.
Current gretl_install.exe also
works correctly on Windows 10, 64.
It seems the problem is only with
gretl_install-64.exe
Now I'll see how other files behave
Oleh
8 вересня 2017, 02:43:03, від "Allin Cottrell" <cottrell(a)wfu.edu>:
> On Fri, 8 Sep 2017, oleg_komashko(a)ukr.net wrote:
> Dear Allin,
> Note that Windows 8 gives absolutely the same visible
> digits as Linux. Also, these estimates have at least 4
> coinciding digits in comparison with using --x-12-arima
> In contrast, for the constant we have 10% difference
> between Windows 10 and (the same) Linux, Windows 8,
> and (almost the same --x-12-arima).
> So it is very unlikely due to rounding errors.
> Also, I used --verbose option: the initialization steps
> were different on Windows 10.
> I think, it may be more convenient to compare Windows 8 (which is obviously
> correct)
> and Windows 10: they have more in common in comparison with Linux.
Comparing Windows 8 with Windows 10 is not meaningful unless you're
using exactly the same gretl package on both platforms (same
build-date, same word-length): I update my cross-compilers for
32-bit and 64-bit Windows from time to time, and also update the
OpenBLAS sources from time to time. And I'm not in a position to
test on Windows 8 any more, though I can test on Windows 10; I'll do
so when I next get a chance.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.eduhttp://lists.wfu.edu/mailman/listinfo/gretl-devel
12:33 a.m.
Current gretl-2017c-64.exe and
gretl_install-64.exe do not work
correctly on Windows 10, 64
8 вересня 2017, 02:43:03, від "Allin Cottrell" <cottrell(a)wfu.edu>:
> On Fri, 8 Sep 2017, oleg_komashko(a)ukr.net wrote:
> Dear Allin,
> Note that Windows 8 gives absolutely the same visible
> digits as Linux. Also, these estimates have at least 4
> coinciding digits in comparison with using --x-12-arima
> In contrast, for the constant we have 10% difference
> between Windows 10 and (the same) Linux, Windows 8,
> and (almost the same --x-12-arima).
> So it is very unlikely due to rounding errors.
> Also, I used --verbose option: the initialization steps
> were different on Windows 10.
> I think, it may be more convenient to compare Windows 8 (which is obviously
> correct)
> and Windows 10: they have more in common in comparison with Linux.
Comparing Windows 8 with Windows 10 is not meaningful unless you're
using exactly the same gretl package on both platforms (same
build-date, same word-length): I update my cross-compilers for
32-bit and 64-bit Windows from time to time, and also update the
OpenBLAS sources from time to time. And I'm not in a position to
test on Windows 8 any more, though I can test on Windows 10; I'll do
so when I next get a chance.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.eduhttp://lists.wfu.edu/mailman/listinfo/gretl-devel
12:48 a.m.
On Fri, 8 Sep 2017, oleg_komashko(a)ukr.net wrote:
Current gretl-2017c-64.exe and
gretl_install-64.exe do not work
correctly on Windows 10, 64
In that case it sounds as if there may be a problem with our current
64-bit build of OpenBLAS for Windows. I don't think it's to do with
our "native" arima code, which hasn't changed in quite a while, and
is the same across platforms -- though I guess I shouldn't be
jumping to conclusions!
Possibly relevant: can you tell me, what's the processor-type on
your Windows 10 machine?
Allin
12:38 a.m.
On Thu, 7 Sep 2017, Allin Cottrell wrote:
On Thu, 7 Sep 2017, oleg_komashko(a)ukr.net wrote:
> Dear all,
> arima command gives somewhat inconsistent results:
> 1) estimates are different from ones on Ubuntu and Windows 8
> 2) estimates are different when there are more than one
> call of the same model inside an user-specified function
> To be more precise:
> linux_2_arma.inp is the script to illustrate the problem
> linux_2_arma_output was obtained on April's git on Ubuntu 16.10, 64
> The results are the same as ones from 09.05 snapshot on Windows 8, 64
> (linux_2_arma_output)
> Output from 09.05 snapshot on Windows 10, 64 is in win10_try_res.txt
> Also with --x12-arima option output on W-10 is ok
Thanks for the report, Oleh.
There are two points here: (1) difference in arima output between
Linux and Windows 10; and (2) difference in arima output across
two calls to estimate the same model in the context of a function.
On (1) we need to look into this, but since the Linux and Windows
builds use different compilers, small differences in results for
nonlinear problems are expected. I'm not yet sure whether the
differences in question are small enough to be ignorable, but
we'll see.
On (2) it seems there must be a bug somewhere -- particularly
since two successive calls to estimate the same arima model in a
"main" script (not in a function) produce identical results. On
initial inspection it seems that initialization (via NLS) is
producing different starting parameter values in the two calls to
"arma" within a function, though not outside of a function. I
don't yet understand why that should be, but hopefully I'll have
something to report before long.
Point (2) is now fixed in git: calling arma/arima on the same model
successively should produce exactly the same results, whether you're
working inside a function or not. This was a bug, but a fairly
benign one; it was just to do with the initialization. The second
invocation inside a function inherited some information from the
first -- unintentionally -- thereby causing it to produce trivially
different results.
Point (1) remains to be addressed.
Allin
12:17 p.m.
My processor is Intel® Pentium(R) CPU N3540 @ 2.16GHz × 4
Short summary of my testing:
Windows 8 : both 32 and 64 bit are ok (another pc HP pavilion)
Windows 10: 32 bit ok; 64 bit - error
Oleh
8 вересня 2017, 09:47:38, від "Sven Schreiber" <svetosch(a)gmx.net>:
> Am 08.09.2017 um 02:38 schrieb Allin Cottrell:
> Point (1) remains to be addressed.
Any more testing on Windows needed? What I can offer is Win10 and Win7
(both 64bit, both on Core i5) and I guess also Win8 (32bit I think, some
Atom CPU).
cheers,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.eduhttp://lists.wfu.edu/mailman/listinfo/gretl-devel
12:33 p.m.
On Fri, 8 Sep 2017, oleg_komashko(a)ukr.net wrote:
My processor is Intel® Pentium(R) CPU N3540 @ 2.16GHz × 4
Short summary of my testing:
Windows 8 : both 32 and 64 bit are ok (another pc HP pavilion)
Windows 10: 32 bit ok; 64 bit - error
and quoted Sven thus:
2017, 09:47:38, від "Sven Schreiber" <svetosch(a)gmx.net>:
> > Am 08.09.2017 um 02:38 schrieb Allin Cottrell:
>
>> Point (1) remains to be addressed.
>
> Any more testing on Windows needed? What I can offer is Win10 and Win7
> (both 64bit, both on Core i5) and I guess also Win8 (32bit I think, some
> Atom CPU).
I've now tested on Windows 10 with Intel Haswell, and the armax
example produces exactly the same results as on Linux.
Oleh, if you do "eval $sysinfo" in gretl, what do you get for the
blascore variable? Here, for example, I see
blascore = HASWELL
Allin
1:08 p.m.
This is all (from 32-bit version)
bundle anonymous:
nproc = 4
hostname = DESKTOP-DE5ESQO
os = windows
mpi = 0
blas = netlib
omp_num_threads = 4
omp = 1
mpimax = 4
wordlen = 32
Oleh
P.S. On another pc also blas = netlib (windows 8)
8 вересня 2017, 15:34:24, від "Allin Cottrell" <cottrell(a)wfu.edu>:
> On Fri, 8 Sep 2017, oleg_komashko(a)ukr.net wrote:
> My processor is Intel® Pentium(R) CPU N3540 @ 2.16GHz × 4
> Short summary of my testing:
> Windows 8 : both 32 and 64 bit are ok (another pc HP pavilion)
> Windows 10: 32 bit ok; 64 bit - error
>
and quoted Sven thus:
>
> 2017, 09:47:38, від "Sven Schreiber" <svetosch(a)gmx.net>:
>
>> > Am 08.09.2017 um 02:38 schrieb Allin Cottrell:
>>
>>> Point (1) remains to be addressed.
>>
>> Any more testing on Windows needed? What I can offer is Win10 and Win7
>> (both 64bit, both on Core i5) and I guess also Win8 (32bit I think, some
>> Atom CPU).
I've now tested on Windows 10 with Intel Haswell, and the armax
example produces exactly the same results as on Linux.
Oleh, if you do "eval $sysinfo" in gretl, what do you get for the
blascore variable? Here, for example, I see
blascore = HASWELL
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.eduhttp://lists.wfu.edu/mailman/listinfo/gretl-devel
1:24 p.m.
On Ubuntu (the same pc) there was also 'blas = netlib'
After installing libopenblas I have blascore = Prescott
bundle anonymous:
nproc = 4
blascore = Prescott
hostname = oleh-Lenovo-B50-10
os = linux
mpi = 1
blas = openblas
omp_num_threads = 4
omp = 1
blas_parallel = pthreads
mpimax = 4
wordlen = 64
8 вересня 2017, 15:34:24, від "Allin Cottrell" <cottrell(a)wfu.edu>:
> On Fri, 8 Sep 2017, oleg_komashko(a)ukr.net wrote:
> My processor is Intel® Pentium(R) CPU N3540 @ 2.16GHz × 4
> Short summary of my testing:
> Windows 8 : both 32 and 64 bit are ok (another pc HP pavilion)
> Windows 10: 32 bit ok; 64 bit - error
>
and quoted Sven thus:
>
> 2017, 09:47:38, від "Sven Schreiber" <svetosch(a)gmx.net>:
>
>> > Am 08.09.2017 um 02:38 schrieb Allin Cottrell:
>>
>>> Point (1) remains to be addressed.
>>
>> Any more testing on Windows needed? What I can offer is Win10 and Win7
>> (both 64bit, both on Core i5) and I guess also Win8 (32bit I think, some
>> Atom CPU).
I've now tested on Windows 10 with Intel Haswell, and the armax
example produces exactly the same results as on Linux.
Oleh, if you do "eval $sysinfo" in gretl, what do you get for the
blascore variable? Here, for example, I see
blascore = HASWELL
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.eduhttp://lists.wfu.edu/mailman/listinfo/gretl-devel
3:59 p.m.
On Fri, 8 Sep 2017, oleg_komashko(a)ukr.net wrote:
My processor is Intel® Pentium(R) CPU N3540 @ 2.16GHz × 4
Short summary of my testing:
Windows 8 : both 32 and 64 bit are ok (another pc HP pavilion)
Windows 10: 32 bit ok; 64 bit - error
I have rebuilt our 64-bit libopenblas.dll for Windows using current
OpenBLAS git, in the gretl snapshot. Could you see if this fixes the
performance on Pentium N3540?
Here it works OK on Windows 10/haswell, but that doesn't tell me
anything since the old libopenblas.dll also worked fine.
Allin
7:42 p.m.
New subject: strange behavior of arima on Windows 10 1-st pc
Attached
8 вересня 2017, 18:59:31, від "Allin Cottrell" <cottrell(a)wfu.edu>:
> On Fri, 8 Sep 2017, oleg_komashko(a)ukr.net wrote:
> My processor is Intel® Pentium(R) CPU N3540 @ 2.16GHz × 4
> Short summary of my testing:
> Windows 8 : both 32 and 64 bit are ok (another pc HP pavilion)
> Windows 10: 32 bit ok; 64 bit - error
I have rebuilt our 64-bit libopenblas.dll for Windows using current
OpenBLAS git, in the gretl snapshot. Could you see if this fixes the
performance on Pentium N3540?
Here it works OK on Windows 10/haswell, but that doesn't tell me
anything since the old libopenblas.dll also worked fine.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.eduhttp://lists.wfu.edu/mailman/listinfo/gretl-devel
7:53 p.m.
New subject: strange behavior of arima on Windows 10 2-nd pc
Attached
Now openblas overrides netlib, but...
8 вересня 2017, 18:59:31, від "Allin Cottrell" <cottrell(a)wfu.edu>:
> On Fri, 8 Sep 2017, oleg_komashko(a)ukr.net wrote:
> My processor is Intel® Pentium(R) CPU N3540 @ 2.16GHz × 4
> Short summary of my testing:
> Windows 8 : both 32 and 64 bit are ok (another pc HP pavilion)
> Windows 10: 32 bit ok; 64 bit - error
I have rebuilt our 64-bit libopenblas.dll for Windows using current
OpenBLAS git, in the gretl snapshot. Could you see if this fixes the
performance on Pentium N3540?
Here it works OK on Windows 10/haswell, but that doesn't tell me
anything since the old libopenblas.dll also worked fine.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.eduhttp://lists.wfu.edu/mailman/listinfo/gretl-devel
8:02 p.m.
32 bit portable on win10, 64
8 вересня 2017, 18:59:31, від "Allin Cottrell" <cottrell(a)wfu.edu>:
> On Fri, 8 Sep 2017, oleg_komashko(a)ukr.net wrote:
> My processor is Intel® Pentium(R) CPU N3540 @ 2.16GHz × 4
> Short summary of my testing:
> Windows 8 : both 32 and 64 bit are ok (another pc HP pavilion)
> Windows 10: 32 bit ok; 64 bit - error
I have rebuilt our 64-bit libopenblas.dll for Windows using current
OpenBLAS git, in the gretl snapshot. Could you see if this fixes the
performance on Pentium N3540?
Here it works OK on Windows 10/haswell, but that doesn't tell me
anything since the old libopenblas.dll also worked fine.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.eduhttp://lists.wfu.edu/mailman/listinfo/gretl-devel
2685
days inactive
2686
days old
17 comments
3 participants
participants (3)
-
Allin Cottrell -
oleg_komashko＠ukr.net -
Sven Schreiber