ALGLIB forum
It is currently Sat Apr 13, 2024 9:54 am

All times are UTC

Forum rules

1. This forum can be used for discussion of both ALGLIB-related and general numerical analysis questions
2. This forum is English-only - postings in other languages will be removed.

Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: Incorporation of ALGLIB into a future AI/DSP framework
PostPosted: Tue Mar 19, 2019 8:23 pm 

Joined: Mon Nov 20, 2017 11:14 pm
Posts: 21

I've posted a few comments over the last year on the design and structuring of the library. Behind these remarks is a longer-term vision and plan that I will describe to you, because it's something that may also be of interest to you and your project.

In our local copy, we've moved more toward nativizing it to C++. The resulting library - ALGLIB++ - will form the core of a new library dedicated to advanced digital signal processing (DSP), applications in sound, music, video editing and production; as well as natural language processing, advanced computer vision, and other core AI fields of applications.

It uses more streamlined object modelling: the routines have been reduced to _init(), _copy() (formerly _init_copy()) and _free() (a combination of _destroy() and _clear()). Several hidden bugs have been resolved. The issue with floating point rounding has also been resolved for the Linux:x86:GCC configuration. (GCC has a problem dealing with this correctly).

The manual has been completely reformatted.

All of the changes are under GPL with a special provision to allow them all to be incorporated into your versions both GPL and commercial. I think you will like the reformatting of the manual section, in particular.

Last edited by RockBrentwood on Fri Feb 14, 2020 4:37 am, edited 2 times in total.

 Post subject: Fixing the FP-comparison vs. optimization bug.
PostPosted: Thu Mar 21, 2019 10:23 pm 

Joined: Mon Nov 20, 2017 11:14 pm
Posts: 21
Additional notes on the floating point / optimjization fix:
The issue of the bad interaction between g++'s optimization and floating point, arising from the fact that Intel uses 80-bit internal math, has been noted in the thread here:
where it is suggested to also use the compiler option -ffloat-store, if compiling under g++ with optimization. In the thread, there is also discussion on what compiler options to use with VisualStudio.

The root of the issue can be seen clearly by #defining the FP operations, e.g.

#define ae_fp_less(A, B) (isnan(A)? (A) < 0.0: isnan(B)? 0.0 < (B): (A) < (B))

This, and similar defines for the other comparison operators, removes all problems (at least -- on my version of GCC). The problem is that the compiler, when optimization is turned on, is not "flushing to zero" its intermediate results. Both that and a fix are described here:

The fix is described for the Intel processors: which is to force the CPU's floating point unit to round to double-sized values.

This is what we did.

Last edited by RockBrentwood on Fri Feb 14, 2020 4:39 am, edited 1 time in total.

 Post subject: ALGLIB++: Incorporation of ALGLIB into a new AI/DSP framewor
PostPosted: Sun Mar 31, 2019 9:56 pm 

Joined: Mon Nov 20, 2017 11:14 pm
Posts: 21
The revision has been released as ALGLIB++ here
It is to be the core of a new framework dedicated to advanced DSP and AI applications. Slated for future inclusion, for instance, will be routines for time-frequency analysis (expanding on fast transforms), file I/O (expanding on the serialization/deserialization).

The modification are under GPL with the following exception:
* the changes made are available for use in the commercial version of ALGLIB.

The chief issues resolved and revisions made:
* macros for all the *_init(), *_init_copy(), *_clear(), *_destroy() routines (now called *_init(), *_copy() and *_free()) that encapsulate the data flow of the variables/objects
* macros for the object class declaration and definition code encapsulate these and allow for easy revision
* the object classes were recoded to bring them in line with the {vector/matrix}_wrapper classes: the need for malloc()/free() was eliminated.
* the RCOMM interface was simplified and mostly removed (multi-threaded apps will need to use thread_local declarations)
* the control flow in both the RCOMM routines and legacy FORTRAN routines (e.g. mcsrch()) was restored
* a makefile with a "make test" was added; specifically configured for Linux:GCC:x86/x64 configuraiton with SSE2 support enabled and -O3 optimization
* the FPU bug for x86/x64 was resolved for GCC/Linux (*NOT* portable), and the FP-comparison functions were all removed.
* a reformatted manual, including an appendix section.

Removal of the RCOMM interface and FPU comparison functions, by itself, entailed a 25% speedup in the code ... before SSE2 and -O3 were turned on.

This is an intermediate form between the GPL version of ALGLIB and the newer library "Lydia" ... that will eventually also include a C++ translation of LAPACK - LAPACK++. Both will be maintained on Lydia's GitHub page.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group