forum.alglib.net
http://forum.alglib.net/

getting started with the test_c & test_i
http://forum.alglib.net/viewtopic.php?f=2&t=69		 Page 1 of 2
Author:  rhine [ Fri Oct 01, 2010 2:42 am ]
Post subject:  getting started with the test_c & test_i
i have just download the newest cpp version(3.0).
it looks like a very solid build.

my first try is to build the test_c and test_i files.
i got test_c running without any problem, but failed on test_i.

here is the error msg:
Compiling test_i.cpp
test_i.cpp: In function `int main()':
test_i.cpp:323: error: `_alloc_counter' is not a member of `alglib_impl'
test_i.cpp:3989: error: `_alloc_counter' is not a member of `alglib_impl'
make: *** [test_i.o] Error 1

and here is the make file i used:
TARGET = alglib_test

CFLAGS = -O3 -I ~/proj/alglib/src -Wall

LFLAGS =

CC = g++

SRC = test_i.cpp
SRC += ~/proj/alglib/src/ap.cpp
SRC += ~/proj/alglib/src/alglibinternal.cpp
SRC += ~/proj/alglib/src/alglibmisc.cpp
SRC += ~/proj/alglib/src/dataanalysis.cpp
SRC += ~/proj/alglib/src/diffequations.cpp
SRC += ~/proj/alglib/src/fasttransforms.cpp
SRC += ~/proj/alglib/src/integration.cpp
SRC += ~/proj/alglib/src/interpolation.cpp
SRC += ~/proj/alglib/src/linalg.cpp
SRC += ~/proj/alglib/src/optimization.cpp
SRC += ~/proj/alglib/src/solvers.cpp
SRC += ~/proj/alglib/src/specialfunctions.cpp
SRC += ~/proj/alglib/src/statistics.cpp

TMP = $(SRC:.cpp=.o)
OBJ = $(TMP:.c=.o)

$(TARGET): $(OBJ)
@echo Linking $@
@$(CC) $(LFLAGS) $(OBJ) -o $@
@echo Build Complete

.cpp.o: $<
@echo Compiling $<
@$(CC) -c $(CFLAGS) $< -o $@

clean:
@rm -f $(OBJ) $(TARGET)
@echo All object files and binaries removed

any insight as to why test_i failed?
thanks,

rhine
Author:  Sergey.Bochkanov [ Fri Oct 01, 2010 4:55 am ]
Post subject:  Re: getting started with the test_c & test_i
You've forgot to define AE_USE_ALLOC_COUNTER at the global level as indicated in manual.

I think that in the next release definition of this symbol will become optional, but currently it is needed to compile test_i
Author:  rhine [ Fri Oct 01, 2010 9:44 am ]
Post subject:  Re: getting started with the test_c & test_i
thanks for the suggestion.
any insight on why that after successfully compiled it,
when run test_i.cpp, the program hang after this output:
C++ tests. Please wait...
0/66
matinv_d_r1 FAILED
matinv_d_c1 FAILED
matinv_d_spd1 FAILED
matinv_d_hpd1 FAILED

from double checking the code, it is hang on
TEST matinv_t_r1

thanks a lot,
rhine
Author:  Sergey.Bochkanov [ Fri Oct 01, 2010 10:44 am ]
Post subject:  Re: getting started with the test_c & test_i
Can you post here:
* version of GCC (it was GCC, right?) you used
* OS version
* CPU type and mode (32-bit? 64-bit?)
* optimization settings (were -O3, right?)

If you have time, can you replace
Code:
        printf("0/66\n");
        _TestResult = true;
        for(_spoil_scenario=-1; _spoil_scenario<7; _spoil_scenario++)


in the beginning of test_i.cpp by

Code:
        printf("0/66\n");
        _TestResult = true;
        for(_spoil_scenario=-1; _spoil_scenario<0; _spoil_scenario++)


any try to compile/execute test one more time. Did it still outputs "matinv_d_r1 FAILED"? (matinv_d_r1, not matinv_c_r1; former may disappear, while latter will remain).

_spoil_scenario variable is an index of crash test applied to the function being investigated. -1 means than we just try to calculate result without crash tests, values from 0 to 6 denote different ways of spoiling inputs with NAN/INF or resizing arguments. I suspect that there is a bug in handling of exceptional situations, but normal execution should be OK.

I also suspect that it can be GCC's bug, because recently I've discovered one which was related to the same topic - handling of complex conversions between doubles, pointers, ints, which were needed to detect NAN/INF in efficient and portable manner. For example, following code was working under -O0 and -O1 (and under MSVC with any king of optimization settings), but failed under GCC with -Os:

Code:
void ae_state_init(ae_state *state)
{
    double a;
    ae_int32_t *p;

.......................
   
    /*
     * determine endianness and initialize precomputed IEEE special quantities.
     * two types are supported: big-endian and little-endian.
     * mixed-endian hardware is NOT supported.
     *
     * 1983 is used as magic number because its non-periodic double
     * representation allow us to easily distinguish between upper
     * and lower halfs and to detect mixed endian hardware.
     *
     */
    a = 1.0/1983.0;
    p = (ae_int32_t*)(&a);
    if( p[1]==(ae_int32_t)0x3f408642 )
    {
......... little endian hardware .........
    }
    else if( p[0]==(ae_int32_t)0x3f408642 )
    {
..................... big endian hardware .............
    }
    else
    {
................ place were GCC with -O3 sometimes sends us ..............
    }
}


This bug was fixed in ALGLIB 3.0.0 (code was rewritten to avoid triggering it), but maybe there are another possibilities to step into it.
Author:  rhine [ Fri Oct 01, 2010 10:56 am ]
Post subject:  Re: getting started with the test_c & test_i
thanks a lot for quick feedback.

info on my environment:
g++: gcc version 3.4.6
os: redhat
cpu: x86_64
optimization: -O3

by replacing scenario limit from 7 to 0,
the output becomes:
C++ tests. Please wait...
0/66
matinv_d_c1 FAILED
matinv_d_spd1 FAILED
matinv_d_hpd1 FAILED

so matinv_d_r1 disappeared,

i'm running ALGLIB 3.0.0
thanks,
colin.
Author:  rhine [ Fri Oct 01, 2010 10:59 am ]
Post subject:  Re: getting started with the test_c & test_i
i'm pretty sure it's an optimization problem.
if i remove -O3 to compile in debug mode,
test passes through with the output as:
C++ tests. Please wait...
0/66
50/66
66/66

any idea why -O3 failed?
thanks,
rhine.
Author:  rhine [ Fri Oct 01, 2010 11:06 am ]
Post subject:  Re: getting started with the test_c & test_i
it's interesting that when compiled in debug mode:
hardware: little-endian

whereas: when compiled with -O3
hardware: mixed-endian

if not -O3, any other optimization flag you suggest?
thanks,
rhine
Author:  Sergey.Bochkanov [ Fri Oct 01, 2010 11:11 am ]
Post subject:  Re: getting started with the test_c & test_i
Looks like it is bug in detection of NAN's and/or INF's. And with 95% probability it is GCC bug - 3.4 was very buggy release, and even GCC 4.4.1 was prone to some errors (like generation of incorrect code for accessing parts of double variable by converting double* to int*).

I'll install GCC 3.4.6 on some separate location and will try to reproduce this bug. Don't know, however, when I'll issue a fix - in the end of a month (along with ALGLIB 3.1) or earlier. However, if you want, I can send you development snapshot as soon as it will be ready.
Author:  Sergey.Bochkanov [ Fri Oct 01, 2010 11:17 am ]
Post subject:  Re: getting started with the test_c & test_i
Code:
any idea why -O3 failed?

The main suspect is GCC, as I told before :)

While working on another bug, I've spend several hours examining assembly output and trying to understand why my Intel Core 2 suddenly became "mixed endian hardware". And finally I've found that it is just GCC bug - assembly output contained clearly incorrect operations.

I think that you can try to test ALGLIB with -O1 or -O2. If all tests are passed, it works. Alternatively you can upgrade to the newer version of GCC. Or wait until I'll make another release which avoids triggering this bug.
Author:  rhine [ Sun Oct 03, 2010 5:05 am ]
Post subject:  Re: getting started with the test_c & test_i
-O1 works while -O2 doesn't.
I'll be looking forward to your next release.
again, thanks a lot for your quick response.
rhine.
Page 1 of 2 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/