forum.alglib.net

ALGLIB forum
It is currently Sun Dec 22, 2024 2:08 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  [ 6 posts ] 
Author Message
 Post subject: praise for ALGLIB
PostPosted: Wed Jul 07, 2010 5:21 pm 
Offline

Joined: Tue Jul 06, 2010 8:00 pm
Posts: 21
First, thank you for putting together this fantastic project! I ported select functions from the VBA version to VB.NET (Visual Basic 2010 Express) with no major issues. Here are the major porting hints should you ever decide to add a translator from AlgoPascal to VB.NET:
- Change extensions of all source/test filenames from ".bas" to ".vb". While the former are still recognized by Visual Studio, the latter are now standard.
- Long in VBA --> Integer in VB.NET (Long here means 64-bit integer, which is non-optimal and excessive in a 32-bit environment)
- Abs() --> Math.Abs() (In VB.NET, most math functions have to be prefixed with the class name.)
- Sqr() --> Math.Sqrt()
- Atn() --> Math.Atan()
- Exp() --> Math.Exp()
- There is no Math.Sgn() in VB.NET, so need to write one in the ap.vb module. Make sure this function returns a Double not an Integer to speed up calculations; otherwise, a cast from Integer to Double will be used everywhere at runtime which burns cycles unnecessarily.
- Type --> Structure and "End Type" --> "End Structure"
- Explicitly declare all variables used in a sub/function *and* all fields in structures using the Dim prefix.
- The '#' numerical literal suffix, as in "Dim x(3#)" forces a constant to a Double type in VB.NET. This suffix should be avoided for constants that are meant to be integer (or, use an "I" suffix instead), such as array bounds and indices. For constants meant to be Double, such as "2.0" in a numerical expression, use the 'R' suffix, as in "1.02R", to explictly force them to Double.
- Lower array bounds are always 0 in VB.NET, so "ReDim x(0# to 2#)" is superfluous and should be "ReDim x(2)" or "ReDim x(2I)" if you want to enforce the Integer type.
- Ideally, encapsulate all functions in VB Modules or better yet, Classes. This way, one can prefix the name of the function with the name of the parent module or class to make it unambiguous. Use classes with Get/Set properties wherever you have private variables. For example, in MinLBFGS, there is a large State structure just asking to be hidden in a class.
- Consider making the entire ALGLIB into a DLL source in VB.NET -- this would be awesome for using with all other languages running on the CLR.

Hope the above is helpful.


Top
 Profile  
 
 Post subject: Re: praise for ALGLIB
PostPosted: Wed Jul 07, 2010 11:52 pm 
Offline

Joined: Sun May 16, 2010 11:42 pm
Posts: 63
Hi alusr1 - interesting and useful post. I mainly use VBA (with Excel) in my work, with occaisional forrays into C/C++ or Fortran when I need better performance for maths intensive work. I haven't used VB.Net at all yet. How do you find VB.Net compares with VBA for speed? Is it fully compiled? Have you compared it with any other languages?

A couple of comments/questions.
I'm not sure I agree with dropping the lower bound in the ReDim statement. If nothing else it serves as a reminder, and if you are mixing different languages I think it helps to avoid errors. It only involves a little extra typing (and Sergey uses automatic code generation anyway :)).

Do array bounds default to double if you omit the "I" suffix?

Are you suggesting one function per module? That seems like an awful lot of modules! I'm not sure I see the advantage here.

I won't comment on the use of classes; that's another area where I really need to get up to speed.

Any comment on how VB.net compares with other languages for interaction with Excel (and other programmes with built in VBA)?

_________________
Doug Jenkins
http://newtonexcelbach.wordpress.com/


Top
 Profile  
 
 Post subject: Re: praise for ALGLIB
PostPosted: Thu Jul 08, 2010 2:01 pm 
Offline

Joined: Tue Jul 06, 2010 8:00 pm
Posts: 21
> How do you find VB.Net compares with VBA for speed?

Doug, so far I have clocked only the TestMinLBFGS subroutine: on a Core2Duo 2.9 GHz PC, it takes about 45 ms to execute on the first run and 31.5 ms on subsequent runs. In my pursuit of optimization with constraints, I have also ported the ALGLIB's MinASA module. I have a reference setup in Excel and compare the MinASA results to those in Excel to make sure everything works fine. While I have not clocked MinASA yet, I can tell you that it is many times (100x?) faster than Solver in Excel. That's good enough for me.

> Is it fully compiled? Have you compared it with any other languages?

I have been wondering about the VB.NET code optimizations. There is a notion of "compilation", which supposedly translates the VB code to the CLR code (common language runtime). So, unless expression/subroutine/global optimizations are not possible in a line-oriented BASIC-like language, I would venture that the performance will be almost identical with what you would get with C/C++.

> Do array bounds default to double if you omit the "I" suffix?

Not that I know of, which is why it should be OK to state "x(0 to 1)" instead of explicitly "x(0I to 1I)".

> Are you suggesting one function per module?

There are pros/cons of having one function per module. The main pro is optimization of the program size: the classic principle is that you statically link only what you need; re: standard C libraries with only one function per file (a typical linker has a file granularity, but modern linkers may be smarter). Another pro is logical containment, e.g., I would like to have all functions related to, say, MinLBFGS or MinASA in one module and that module should not contain any other functions (this is exactly how ALGLIB sources and tests are partitioned).

> I won't comment on the use of classes; that's another area where I really need to get up to speed.

To simplify things, a class is a module with private data (members in C++, properties in VB.NET) and functions/subroutines (methods in C++, members in VB.NET) that facilitate access to and manipulation of this data. The basic principle here is encapsulation; think of it as a glorified structure. AFAIK, VB.NET supports simple inheritance (from one base class, just like in Java, but not multiple classes, as in C++). It also supports polymorphism, the 3rd tenet of object-oriented programming: you can have multiple identically named functions that accept slightly different parameters, so that their "signatures" are different; at compile time, the right function is called depending on the type of args you supply.

> Any comment on how VB.net compares with other languages for interaction with Excel (and other programmes with built in VBA)?

As I mentioned, ideally the entire ALGLIB should be in a DLL, so that all these useful tools could be invoked from any language running on the CLR. This way, Sergey & Co. would have to produce only the interface ("header") files for each language, and not translate the entire ALGLIB to all languages. Much less work, and if the DLL is developed in C++, it will be as fast as it gets after translation to the CLR.

How things would be partitioned inside of this DLL can be a matter of debate. Personally, I like classes because that is a more modern approach than modules and it will support future extensions through inheritance and polymorphism (if, like I, you have been around for a while, you may recall the evolution from Pascal to Modula2 to C++/Java/etc.). For interaction of Excel VBA with a DLL, see:
http://support.microsoft.com/kb/317535


Top
 Profile  
 
 Post subject: Re: praise for ALGLIB
PostPosted: Thu Jul 08, 2010 3:05 pm 
Offline

Joined: Tue Jul 06, 2010 8:00 pm
Posts: 21
Two more pieces of info.

When porting from VBA to VB.NET:
- Two-dimensional arrays have to be explicitly declared as such, i.e., if you state "Dim A() as Double" you cannot later "ReDim A(1, 2)"; you have to first declare "Dim A(,)".
- Structures have to be explicitly instantiated using the New operator, i.e., when you have a local variable "Dim State as MinLBFGSState" in a subroutine, before you use it, you have to make "State = New MinLBFGSState"; otherwise, your State will be Nothing.

Also, I just clocked the MinASATest sub on my 2.9 GHz Core2 Duo PC: first run 62.5 ms, subsequent runs 46.875 ms (probably due to caching in memory). Please post the numbers for VBA/Excel. Here is how you could clock it (code modifications may be needed in VBA):
- At the beggining of the test subroutine, add the following code
Dim _StartTime As Date
Dim _ElapsedTime As TimeSpan
_StartTime = Now
Randomize()
- Just before the section marked " ' end" add
_ElapsedTime = Now - _StartTime
- Then in the result printout section add
ConsoleOutputString("ELAPSED TIME: " & FormatFReal(_ElapsedTime.TotalMilliseconds, 5, 3) & " MILLISECONDS")

NOTE: the ConsoleOutputString() sub in ap.bas is empty by default, so you may add a body to it like that:
Debug.Print("ALGLIB " & S)


Top
 Profile  
 
 Post subject: Re: praise for ALGLIB
PostPosted: Thu Jul 08, 2010 6:27 pm 
Offline

Joined: Tue Jul 06, 2010 8:00 pm
Posts: 21
I clocked MinASA vs. a comparable Excel Solver-based implementation with an identical input data set (6 independent variables, 84 subsets of double-precision floating point data): Excel 2007 ~3 min 47 sec; MinASA ~2.4 sec. So, in this particular test, MinASA was approx. 95x faster (I was not too far off when I initially estimated 100x :D ).

I then increased the number of independent variables to the max. available 25, while keeping the same number of 84 data subsets. MinASA clocked in at ~134.8 sec and Excel at ~17 min 32 sec. So, in that case the performance improvement was only 7.8x.

I then decreased the number of independent variables to 14 with the same 84 data subsets. Excel took ~595 sec and MinASA ~37.7 sec, so the performance improvement was approx. 15.8x.

With 10 variables, I got 368 sec for Excel and 11.9 sec for MinASA, for a performance improvement of 30.9x.

Conclusion: Excel scales better with the number of independent variables but MinASA beats it hands-down when the number of variables is relatively small. This may not entirely be a function of pure Solver's performance, as certain data fetching functions may contributed to a fixed overhead. Nevetheless, the improvements are generally impressive.

The MinLBFGS algorithm is said to scale well with the number of independent variables but it does not seem to easily accommodate constraints, even simple ones, like non-negative Xs or sum of Xs being 1. Wish there was an algorithm that combined the desirable MinLBFGS and MinASA properties -- perhaps Sergey or someone else can point me to one?


Top
 Profile  
 
 Post subject: Re: praise for ALGLIB
PostPosted: Fri Jul 09, 2010 11:41 am 
Offline

Joined: Sun May 16, 2010 11:42 pm
Posts: 63
I just ran the TestMinLBFGS and TestMinASA routines in Excel, on a Core2 Duo 2.53 GHz notebook.

The run times were 270 ms TestMinLBFGS for and 310 ms for TestMinASA, so that looks like about 10 x slower than the VB.net versions. I ran them in silent mode, just returning the run time at the end, so there should be any overhead in there.

I'll compare them with Solver when I work out how they work :)

_________________
Doug Jenkins
http://newtonexcelbach.wordpress.com/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 9 guests


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:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group