Hi all,
Is there a place where one can find 64 bits binaries for Octave 4.2.x on Windows with support for large arrays ? @++ Julien 
How "large" would you want to have them? With the 64bit binaries on ftp.gnu.org/pub/octave/windows it is easy to create double arrays that are far larger than the 16 GB RAM in my machine and make it start trashing. IIRC for sparse arrays there was (or is) an old bug about the default (integer) index pointer bit width; 64bit indexing would be handy there. Philip 
Le 15/03/2017 à 16:40, PhilipNienhuis a
écrit :
Julien Bect2 wroteHi all, Is there a place where one can find 64 bits binaries for Octave 4.2.x on Windows with support for large arrays ?How "large" would you want to have them? With the 64bit binaries on ftp.gnu.org/pub/octave/windows it is easy to create double arrays that are far larger than the 16 GB RAM in my machine and make it start trashing.

No (AFAIK), but they've been built for 64bit Windows to take advantage of the 64bit architecture. That means that the max *process limit* of 2 or 3 GB for all of Octave + its data is gone. IOW Octave is a real 64bit program. See here for max array sizes: https://www.gnu.org/software/octave/doc/interpreter/CompilingOctavewith64_002dbitIndexing.html#CompilingOctavewith64_002dbitIndexing In some places the information there seems a bit contradictionary to me (again I see 2GB metntioned but that doesn't hold, limits are larger depending on class of data); the section could use some cleaning up. E.g., in a 64bit (not 64bit indexing!) Octave4.3.0+ I can do this: ================================================== >> a = zeros (30000); >> whos Variables in the current scope: Attr Name Size Bytes Class ==== ==== ==== ===== ===== a 30000x30000 7200000000 double ans 1x1 8 double Total is 900000001 elements using 7200000008 bytes ================================================== Anyway it isn't hard to crossbuild 64bit indexing Octave with mxe. Actually all that is needed is to configure mxeoctave with at least enable64 (plus other flags you need). (JWE made a few changes so that configure flag may have another name now but "configure help" will show you the right options.) Philip 
In reply to this post by jbect
 Original Message 
>From: Julien Bect >To: octavemaintainers >Date: 2017/3/16, Thu 01:01 >Subject: Re: Octave on Windows with large arrays ? > > >Le 15/03/2017 à 16:40, PhilipNienhuis a écrit : > >Julien Bect2 wrote >>Hi all, Is there a place where one can find 64 bits binaries for Octave 4.2.x on >>How "large" would you want to have them? With the 64bit binaries on ftp.gnu.org/pub/octave/windows it is easy to create double arrays that are far larger than the 16 GB RAM in my machine and make it start trashing. > >You mean that they already have 64 bits indexing ? > @Julien I have built octave4.2.1 for windows with 64 bits indexing. http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1LA0.7z size 256,085,305 byte sha1sum 62e50e31a0b3c2fe9e570958accd7be91e9f9529 Source http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1.tar.lz size 15,826,565 sha1sum 057dbaa30d0ef75e84db30aeda623a2561b0d547 Note that this build does not include prebuild octaveforge packages. To install octaveforge packages From octave prompt, execute cd <install dir>/src build_packages you can install octaveforge packages but I have not tested yet. At this moment, this is temporal and not described in my web site. http://www.tatsuromatsuoka.com/octave/Eng/Win/ Regards Tatsuro 
Le 16/03/2017 à 03:53, Tatsuro MATSUOKA a écrit :
>  Original Message  >> From: Julien Bect >> To: octavemaintainers >> Date: 2017/3/16, Thu 01:01 >> Subject: Re: Octave on Windows with large arrays ? >> >> >> Le 15/03/2017 à 16:40, PhilipNienhuis a écrit : >> >> Julien Bect2 wrote >>> Hi all, Is there a place where one can find 64 bits binaries for Octave 4.2.x on > Windows with support for large arrays ? >>> How "large" would you want to have them? With the 64bit binaries on ftp.gnu.org/pub/octave/windows it is easy to > create double arrays that are far larger than the 16 GB RAM in my machine > and make it start trashing. >> You mean that they already have 64 bits indexing ? >> > @Julien > > I have built octave4.2.1 for windows with 64 bits indexing. > > http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1LA0.7z > size 256,085,305 byte > > sha1sum 62e50e31a0b3c2fe9e570958accd7be91e9f9529 > > Source > http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1.tar.lz > size 15,826,565 > sha1sum 057dbaa30d0ef75e84db30aeda623a2561b0d547 > > Note that this build does not include prebuild octaveforge packages. > > To install octaveforge packages > > From octave prompt, execute > cd <install dir>/src > build_packages > > you can install octaveforge packages but I have not tested yet. > > At this moment, this is temporal and not described in my web site. > http://www.tatsuromatsuoka.com/octave/Eng/Win/ Thanks a lot Tatsuro. I will forward your email to my colleague who needed this. @++ Julien 
 Original Message 
>From: Julien Bect >To: octavemaintainers >Date: 2017/3/16, Thu 14:51 >Subject: Re: Octave on Windows with large arrays ? > >Le 16/03/2017 à 03:53, Tatsuro MATSUOKA a écrit : >> @Julien >> >> I have built octave4.2.1 for windows with 64 bits indexing. >> >> http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1LA0.7z >> size 256,085,305 byte >> >> sha1sum 62e50e31a0b3c2fe9e570958accd7be91e9f9529 >> >> Source >> http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1.tar.lz >> size 15,826,565 >> sha1sum 057dbaa30d0ef75e84db30aeda623a2561b0d547 >> >> Note that this build does not include prebuild octaveforge packages. >> >> To install octaveforge packages >> >> From octave prompt, execute >> cd <install dir>/src >> build_packages >> >> you can install octaveforge packages but I have not tested yet. >> >> At this moment, this is temporal and not described in my web site. >> http://www.tatsuromatsuoka.com/octave/Eng/Win/ > > >Thanks a lot Tatsuro. > >I will forward your email to my colleague who needed this. > >@++ >Julien > @Julien Excuse me I have forgotten to clean up the directory so that some files and directory for 4.2.0 remains. Perhaps this will have side effect other than sizes But I will build again after clean up. Tatsuro 
 Original Message  > From: Tatsuro MATSUOKA > To: Julien Bect "octavemaintainers > Cc: > Date: 2017/3/16, Thu 15:37 > Subject: Re: Octave on Windows with large arrays ? > >  Original Message  >> From: Julien Bect >> To: octavemaintainers >> Date: 2017/3/16, Thu 14:51 >> Subject: Re: Octave on Windows with large arrays ? >> >> Le 16/03/2017 à 03:53, Tatsuro MATSUOKA a écrit : >>> @Julien >>> >>> I have built octave4.2.1 for windows with 64 bits indexing. >>> >>> http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1LA0.7z >>> size 256,085,305 byte >>> >>> sha1sum 62e50e31a0b3c2fe9e570958accd7be91e9f9529 >>> >>> Source >>> http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1.tar.lz >>> size 15,826,565 >>> sha1sum 057dbaa30d0ef75e84db30aeda623a2561b0d547 >>> >>> Note that this build does not include prebuild octaveforge packages. >>> >>> To install octaveforge packages >>> >>> From octave prompt, execute >>> cd <install dir>/src >>> build_packages >>> >>> you can install octaveforge packages but I have not tested yet. >>> >>> At this moment, this is temporal and not described in my web site. >>> http://www.tatsuromatsuoka.com/octave/Eng/Win/ >> >> >> Thanks a lot Tatsuro. >> >> I will forward your email to my colleague who needed this. >> >> @++ >> Julien >> > > > @Julien > > Correction > Excuse me I have forgotten to clean up the directory so that some files and > directory for 4.2.0 remains. > Perhaps this will have side effect other than sizes Perhaps this will *not* have side effect other than sizes > But I am building again after clean up. > > Tatsuro Tatsuro 
 Original Message 
> From: Tatsuro MATSUOKA > To: tmacchant Julien Bect "octavemaintainers > Cc: > Date: 2017/3/16, Thu 16:11 > Subject: Re: Octave on Windows with large arrays ? > > > > > >  Original Message  >> From: Tatsuro MATSUOKA >> To: Julien Bect "octavemaintainers >> Cc: >> Date: 2017/3/16, Thu 15:37 >> Subject: Re: Octave on Windows with large arrays ? >> >>  Original Message  >>> From: Julien Bect >>> To: octavemaintainers >>> Date: 2017/3/16, Thu 14:51 >>> Subject: Re: Octave on Windows with large arrays ? >>> >>> Le 16/03/2017 à 03:53, Tatsuro MATSUOKA a écrit : >>>> @Julien >>>> >>>> I have built octave4.2.1 for windows with 64 bits indexing. >>>> >>>> http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1LA0.7z >>>> size 256,085,305 byte >>>> >>>> sha1sum 62e50e31a0b3c2fe9e570958accd7be91e9f9529 >>>> >>>> Source >>>> http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1.tar.lz >>>> size 15,826,565 >>>> sha1sum 057dbaa30d0ef75e84db30aeda623a2561b0d547 >>>> >>>> Note that this build does not include prebuild octaveforge > packages. >>>> >>>> To install octaveforge packages >>>> >>>> From octave prompt, execute >>>> cd <install dir>/src >>>> build_packages >>>> >>>> you can install octaveforge packages but I have not tested yet. >>>> >>>> At this moment, this is temporal and not described in my web site. >>>> http://www.tatsuromatsuoka.com/octave/Eng/Win/ >>> >>> >>> Thanks a lot Tatsuro. >>> >>> I will forward your email to my colleague who needed this. >>> >>> @++ >>> Julien >>> >> >> >> @Julien >> >> > > Correction >> Excuse me I have forgotten to clean up the directory so that some files and > >> directory for 4.2.0 remains. >> Perhaps this will have side effect other than sizes > > > Perhaps this will *not* have side effect other than sizes > > >> But I am building again after clean up. >> >> Tatsuro > > > Tatsuro I manually remove 4.2.0 related files and directories from archived directory and recompress it on windows. New binary (....LA0.7z => .....LA1.7z) http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1LA1.7z size 209,082,028 byte sha1sum 5ec10ea6c1fe4023e785d5eaecfa6b289684bddb Source http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1.tar.lz size 15,826,565 sha1sum 057dbaa30d0ef75e84db30aeda623a2561b0d547 I have executed __run_test_suite__ but hangs. libinterp\corefcn\lsode.cctst .............................. LSODE AT T (=R1) AND STEP SIZE H (=R2), THE CORRECTOR CONVERGENCE FAILED REPEATEDLY OR WITH ABS(H) = HMIN In above, R1 = 0.0000000000000D+00 R2 = 0.3802108489572D09 LSODE AT T (=R1) AND STEP SIZE H (=R2), THE CORRECTOR CONVERGENCE FAILED REPEATEDLY OR WITH ABS(H) = HMIN In above, R1 = 0.0000000000000D+00 R2 = 0.6424715644617D09 LSODE AT T (=R1) AND STEP SIZE H (=R2), THE CORRECTOR CONVERGENCE FAILED REPEATEDLY OR WITH ABS(H) = HMIN In above, R1 = 0.0000000000000D+00 R2 = 0.4165001171641D09 PASS 2/5 FAIL 3 libinterp\corefcn\lu.cctst .................................panic: Segmentation fault  stopping myself... Mmmmmmmm. Anyway I will test again against binary I am now rebuilding after clean up. Tatsuro 
Le 16/03/2017 à 09:11, Tatsuro MATSUOKA
a écrit :
I have executed __run_test_suite__ but hangs. libinterp\corefcn\lsode.cctst .............................. LSODE AT T (=R1) AND STEP SIZE H (=R2), THE CORRECTOR CONVERGENCE FAILED REPEATEDLY OR WITH ABS(H) = HMIN In above, R1 = 0.0000000000000D+00 R2 = 0.3802108489572D09 LSODE AT T (=R1) AND STEP SIZE H (=R2), THE CORRECTOR CONVERGENCE FAILED REPEATEDLY OR WITH ABS(H) = HMIN In above, R1 = 0.0000000000000D+00 R2 = 0.6424715644617D09 LSODE AT T (=R1) AND STEP SIZE H (=R2), THE CORRECTOR CONVERGENCE FAILED REPEATEDLY OR WITH ABS(H) = HMIN In above, R1 = 0.0000000000000D+00 R2 = 0.4165001171641D09 PASS 2/5 FAIL 3 libinterp\corefcn\lu.cctst .................................panic: Segmentation fault  stopping myself... Mmmmmmmm. Anyway I will test again against binary I am now rebuilding after clean up.
***** assert (det ([1, 2; 3, 4]), 2, 10*eps)
***** assert (det (single ([1, 2; 3, 4])), single (2),
10*eps ("single"))
***** test

 Original Message 
>From: Julien Bect >To: [hidden email] >Date: 2017/3/17, Fri 06:06 >Subject: Re: Octave on Windows with large arrays ? > > >Le 16/03/2017 à 09:11, Tatsuro MATSUOKA a écrit : > >I have executed __run_test_suite__ but hangs. libinterp\corefcn\lsode.cctst .............................. LSODE AT T (=R1) AND STEP SIZE H (=R2), THE CORRECTOR CONVERGENCE FAILED REPEATEDLY OR WITH ABS(H) = HMIN In above, R1 = 0.0000000000000D+00 R2 = 0.3802108489572D09 LSODE AT T (=R1) AND STEP SIZE H (=R2), THE CORRECTOR CONVERGENCE FAILED REPEATEDLY OR WITH ABS(H) = HMIN In above, R1 = 0.0000000000000D+00 R2 = 0.6424715644617D09 LSODE AT T (=R1) AND STEP SIZE H (=R2), THE CORRECTOR CONVERGENCE FAILED REPEATEDLY OR WITH ABS(H) = HMIN In above, R1 = 0.0000000000000D+00 R2 = 0.4165001171641D09 PASS 2/5 FAIL 3 libinterp\corefcn\lu.cctst .................................panic: Segmentation fault  stopping myself... Mmmmmmmm. Anyway I will test again against binary I am now rebuilding after clean up. > >Hi Tatsuro, > >I haven't tried myself, but my colleague confirmed the crash with lsode. > >There were also some failed tests with det and eig (see below). Have you already seen these ? > >@++ >Julien > > >________________________________ > >***** assert (det ([1, 2; 3, 4]), 2, 10*eps) >!!!!! test failed >ASSERT errors for: assert (det ([1, 2; 3, 4]),2,10 * eps) > > Location  Observed  Expected  Reason > () 2 2 Abs err 4 exceeds tol 2.2204e015 > >***** assert (det (single ([1, 2; 3, 4])), single (2), 10*eps ("single")) >!!!!! test failed >ASSERT errors for: assert (det (single ([1, 2; 3, 4])),single (2),10 * eps ("single")) > > Location  Observed  Expected  Reason > () 2 2 Abs err 4 exceeds tol 1.1921e006 > >***** test > A = diag([10^16, 10^15]); > chol_qz_accuracy (A, A, true, false); >!!!!! test failed >ASSERT errors for: assert (isequal (A * V2, A * V2 * D2),is_chol_accurate) > > Location  Observed  Expected  Reason > () 1 0 Abs err 1 exceeds tol 0 > > I have built again octave4.2.1 with LargeArray after clean up but results are the same. >I haven't tried myself, but my colleague confirmed the crash with lsode. crash happens on lu but not onlsode libinterp\corefcn\lu.cctst .................................panic: Segmentation fault  stopping myself... on lsode error happens. Hang on lu is easy to reproduce. >> A=rand(5); >> [L,U,P]=lu(A); panic: Segmentation fault  stopping myself... attempting to save variables to 'octaveworkspace'... save to 'octaveworkspace' complete >There were also some failed tests with det and eig (see below). Have you already seen these ? I have also seen this. On octave4.0.3 for windows with Large Arrays, I have not seen such errors on __run_test_suite__. Unfortunately octave4.2.x for windows with Large Arrays has many fault, it cannot be usable. octave4.0.3 for windows with Large Arrays can be downloaded from http://www.tatsuromatsuoka.com/octave/Eng/Win/ Tatsuro 
 Original Message 
> From: Tatsuro MATSUOKA > > To: Julien Bect ; "octavemaintainers > Cc: > Date: 2017/3/17, Fri 08:35 > Subject: Re: Octave on Windows with large arrays ? > >  Original Message  >> From: Julien Bect >> To: [hidden email] >> Date: 2017/3/17, Fri 06:06 >> Subject: Re: Octave on Windows with large arrays ? >> >> >> Le 16/03/2017 à 09:11, Tatsuro MATSUOKA a écrit : >> >> I have executed __run_test_suite__ but hangs. > libinterp\corefcn\lsode.cctst .............................. LSODE > AT T (=R1) AND STEP SIZE H (=R2), THE > CORRECTOR CONVERGENCE FAILED REPEATEDLY > OR WITH ABS(H) = HMIN > In above, R1 = 0.0000000000000D+00 R2 = 0.3802108489572D09 > LSODE AT T (=R1) AND STEP SIZE H (=R2), THE > CORRECTOR CONVERGENCE FAILED REPEATEDLY > OR WITH ABS(H) = HMIN > In above, R1 = 0.0000000000000D+00 R2 = 0.6424715644617D09 > LSODE AT T (=R1) AND STEP SIZE H (=R2), THE > CORRECTOR CONVERGENCE FAILED REPEATEDLY > OR WITH ABS(H) = HMIN > In above, R1 = 0.0000000000000D+00 R2 = 0.4165001171641D09 > PASS 2/5 > FAIL 3 > libinterp\corefcn\lu.cctst .................................panic: > Segmentation fault  stopping myself... Mmmmmmmm. Anyway I will test again > against binary I am now rebuilding after clean up. >> >> Hi Tatsuro, >> >> I haven't tried myself, but my colleague confirmed the crash with > lsode. >> >> There were also some failed tests with det and eig (see below). > Have you already seen these ? >> >> @++ >> Julien >> >> >> ________________________________ >> >> ***** assert (det ([1, 2; 3, 4]), 2, 10*eps) >> !!!!! test failed >> ASSERT errors for: assert (det ([1, 2; 3, 4]),2,10 * eps) >> >> Location  Observed  Expected  Reason >> () 2 2 Abs err 4 exceeds tol 2.2204e015 >> >> ***** assert (det (single ([1, 2; 3, 4])), single (2), 10*eps > ("single")) >> !!!!! test failed >> ASSERT errors for: assert (det (single ([1, 2; 3, 4])),single (2),10 * eps > ("single")) >> >> Location  Observed  Expected  Reason >> () 2 2 Abs err 4 exceeds tol 1.1921e006 >> >> ***** test >> A = diag([10^16, 10^15]); >> chol_qz_accuracy (A, A, true, false); >> !!!!! test failed >> ASSERT errors for: assert (isequal (A * V2, A * V2 * D2),is_chol_accurate) >> >> Location  Observed  Expected  Reason >> () 1 0 Abs err 1 exceeds tol 0 >> >> > > > I have built again octave4.2.1 with LargeArray after clean up but results are > the same. > >> I haven't tried myself, but my colleague confirmed the crash with > lsode. > > > crash happens on lu but not onlsode > > libinterp\corefcn\lu.cctst .................................panic: > Segmentation fault  stopping myself... > > > on lsode error happens. > > Hang on lu is easy to reproduce. > >>> A=rand(5); >>> [L,U,P]=lu(A); > > panic: Segmentation fault  stopping myself... > attempting to save variables to 'octaveworkspace'... > save to 'octaveworkspace' complete > >> There were also some failed tests with det and eig (see below). > Have you already seen these ? > > > I have also seen this. > > On octave4.0.3 for windows with Large Arrays, I have not seen such errors on > __run_test_suite__. > > Unfortunately octave4.2.x for windows with Large Arrays has many fault, it > cannot be usable. > > octave4.0.3 for windows with Large Arrays can be downloaded from > http://www.tatsuromatsuoka.com/octave/Eng/Win/ > Perhaps my build failed without enablefortranint64. (That option was not required for mxebuild before I think ) I am trying rebuild 4.2.1 adding this option. Tatsuro 
Administrator

On 03/17/2017 03:13 AM, Tatsuro MATSUOKA wrote:
> Perhaps my build failed without enablefortranint64. > (That option was not required for mxebuild before I think ) > > I am trying rebuild 4.2.1 adding this option. That is not an option for the 4.2.1 configure script. With 4.2.1, enable64 should cause Octave to use 64bit integers for array dimensions and indexing, and to expect the Fortran libraries like BLAS and LAPACK to also be compiled to use 64bit integers for indexing. Was fdefaultinteger8 added to FFLAGS by the configure script? That should also happen automatically. To know what happened, I'd have to see the output displayed when running the configure script and maybe the config.log file. jwe 
In reply to this post by jbect
 jwe
> On 03/17/2017 03:13 AM, Tatsuro MATSUOKA wrote: > > > Perhaps my build failed without enrablefortranint64. > > (That option was not required for mxebuild before I think ) > > > > I am trying rebuild 4.2.1 adding this option. > > That is not an option for the 4.2.1 configure script. With 4.2.1, enable64 should cause Octave to use 64bit integers for array dimensions and indexing, and to expect the Fortran libraries like BLAS and LAPACK to also be compiled to use 64bit integers for indexing. > > Was fdefaultinteger8 added to FFLAGS by the configure script? That should also happen automatically. > > To know what happened, I'd have to see the output displayed when running the configure script and maybe the config.log file. > > jwe > > As written in the thead, enrablefortranint64 is configure option of mxe octave. http://octave.1599824.n4.nabble.com/mxeoctaveenablefortranint64isrequiredfor64bitsindexbuildtd4682442.html Tatsuro 
Administrator

On 03/17/2017 01:04 PM, [hidden email] wrote:
> As written in the thead, enrablefortranint64 is configure option of mxe octave. Sorry, I missed that part. Yes, because now it is possible to build the development version of Octave with support for 64bit indexing and still use 32bit indexing in the BLAS and other libraries, we need to control the type of index used for those libraries separately from whether Octave uses 64bit indexing. Sorry for the confusion, most likely due to not having a separate mxeoctave branch for building stable Octave. OTOH, I'm not sure we really want to add that complexity. At first I was surprised that Octave was successfully configured with enable64 when the libraries are using 32bit indexing, but then I remembered that this is a cross build, so we can't run the program that is necessary to detect that problem. So we have to trust that the options have been selected correctly. Sorry. jwe 
 Original Message 
> From: John W. Eaton > To: "tmacchant; Julien Bect ; "octavemaintainers > Cc: > Date: 2017/3/18, Sat 04:21 > Subject: Re: Octave on Windows with large arrays ? > > On 03/17/2017 01:04 PM, [hidden email] wrote: > >> As written in the thead, enrablefortranint64 is configure option of > mxe octave. > > Sorry, I missed that part. > > Yes, because now it is possible to build the development version of Octave with > support for 64bit indexing and still use 32bit indexing in the BLAS and other > libraries, we need to control the type of index used for those libraries > separately from whether Octave uses 64bit indexing. Sorry for the confusion, > most likely due to not having a separate mxeoctave branch for building stable > Octave. OTOH, I'm not sure we really want to add that complexity. > > At first I was surprised that Octave was successfully configured with > enable64 when the libraries are using 32bit indexing, but then I remembered > that this is a cross build, so we can't run the program that is necessary to > detect that problem. So we have to trust that the options have been selected > correctly. Sorry. > > jwe Sorry for late reply. I understand the situation. I rebuild octave4.2.1 for windows with large arrays with enablefortranint64 for mxeoctave. This time __run_test_suite__ works with out hang. (3 FAIL exist, tolerance and round off? issue?) Thanks for detailed and comprehensive explanation. Tatsuro 
In reply to this post by tmacchant
 Original Message  > From: Tatsuro MATSUOKA > To: tmacchantJulien Bect ; "octavemaintainers > Cc: > Date: 2017/3/17, Fri 16:13 > Subject: Re: Octave on Windows with large arrays ? > [snip] > Perhaps my build failed without enablefortranint64. > (That option was not required for mxebuild before I think ) > > I am trying rebuild 4.2.1 adding this option. > > Tatsuro @Julien I have rebuilt octave4.2.1 for windows with 64 bits indexing adding enablefortranint64. This time __run_test_suite__ runs to the end. Test results are included in the directory "run_test" in the package. Binary archive http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1LA2.7z size 19,4466,920 byte sha1sum 461e6695231e7ab094e13430a8fdd51c58a17663 Source http://www.tatsuromatsuoka.com/octave/Eng/Win/octave4.2.1.tar.lz size 15,826,565 sha1sum 057dbaa30d0ef75e84db30aeda623a2561b0d547 Notes 1. This build does not include prebuild octaveforge packages. To install octaveforge packages From octave prompt, execute cd <install dir>/src build_packages I have not tested octaveforge. 2. Default blas is reference blas. To use openblas, In bin directory, use explorer rename libblas.dll to other name. copy and paste libopenblas.dll by other name in bin folder rename copied libopenblas.dll to libblas.dll Tatsuro 
In reply to this post by tmacchant
Le 21/03/2017 à 02:14, Tatsuro MATSUOKA a écrit :
>  Original Message  > >> From: John W. Eaton >> To: "tmacchant; Julien Bect ; "octavemaintainers >> Cc: >> Date: 2017/3/18, Sat 04:21 >> Subject: Re: Octave on Windows with large arrays ? >> >> On 03/17/2017 01:04 PM, [hidden email] wrote: >> >>> As written in the thead, enrablefortranint64 is configure option of >> mxe octave. >> >> Sorry, I missed that part. >> >> Yes, because now it is possible to build the development version of Octave with >> support for 64bit indexing and still use 32bit indexing in the BLAS and other >> libraries, we need to control the type of index used for those libraries >> separately from whether Octave uses 64bit indexing. Sorry for the confusion, >> most likely due to not having a separate mxeoctave branch for building stable >> Octave. OTOH, I'm not sure we really want to add that complexity. >> >> At first I was surprised that Octave was successfully configured with >> enable64 when the libraries are using 32bit indexing, but then I remembered >> that this is a cross build, so we can't run the program that is necessary to >> detect that problem. So we have to trust that the options have been selected >> correctly. Sorry. >> >> jwe > Sorry for late reply. > > I understand the situation. > I rebuild octave4.2.1 for windows with large arrays with enablefortranint64 for mxeoctave. > > This time __run_test_suite__ works with out hang. (3 FAIL exist, tolerance and round off? issue?) Hi Tatsuro, Thank you for your work. Did you upload this new build on your web site ? @++ Julien 
Le 21/03/2017 à 07:13, Julien Bect a
écrit :

Free forum by Nabble  Edit this page 