[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GLPSOL in webassemby faster than native ?

From: Domingo Alvarez Duarte
Subject: Re: GLPSOL in webassemby faster than native ?
Date: Wed, 23 Sep 2020 13:47:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Hello Michael !

Thanks for reply !

After your reply I did a refactoring on this this branch where I replaced all occurrences of "double" by "glp_double" and added a definition for it as shown bellow, but it seems that there are several hard coded constants that are tied to using "double" (float64) and the solver is producing wrong results when using "long double" with the changes made so far.

If someone could help fix it we could have GLPK working with both and could compare performance/accuracy or even other numeric representations.

I also made available binaries (compiled with "double") to facilitate others fiddle with it without need to (ideally) build form source -> .


#ifndef glp_double
        #define glp_double long double
        #define GLP_DBL_FMT_G "Lg"
        #define GLP_DBL_FMT_F "Lf"
        #define GLP_DBL_FMT_E "LE"
        #define GLP_DBL_FMT_e "Le"
        #define glp_double double
        #define GLP_DBL_FMT_G "g"
        #define GLP_DBL_FMT_F "f"
        #define GLP_DBL_FMT_E "E"
        #define GLP_DBL_FMT_e "e"


Cheers !

On 22/9/20 21:49, Michael Hennebry wrote:
On Tue, 22 Sep 2020, Domingo Alvarez Duarte wrote:

Due to the big difference in solver time how could we figure out what's is it in order to use this knowledge to improve the native solver time ?

I mean what debug/verbose options could help us have a clue ?

I expect the answer is none.
My guess is that neither platform is inherently better than the other.
Which small roundings will be better doubtless depends
on the particular problem and version of GLPK.
Andrew insists on C89.
That pretty much eliminates control over how floating point is done.

double x=1./3., y=1./3.;
C89 does not require x and y to have the same value.
IEEE arithmetic would, despite possible double rounding.

Even with IEEE, platforms are allowed to evaluate floating point
expressions with a precision larger than required by the expressions.
They are not required to be consistent.
double x=2.0+DBLE_EPSILON-2.0, y=2.0+DBL_EPSILON-2.0;
x could be 0 or DBLE_EPSILON, as could y.
They need not be the same.
Once upon a time, that was a real problem with gcc.
For C89, it might still be.

With a lot of casts to long double and sufficient
care in the representation of constants,
Andrew might be able to get consistent behaviour between
IEEE platforms with matching doubles and long doubles.

It's been a while since I looked at any GLPK code.
My expectation is that at least some of it, e.g. dot product, is memory bound.
In such a case, explicitly using long doubles would
not slow it down and could improve its accuracy.
Possibly Andrew already does that.
I haven't looked lately.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]