Re: GLPSOL in webassemby faster than native ?

[Domingo Alvarez Duarte]

Hello Michael !

Thanks for reply !

After your reply I did a refactoring on this this branch 
https://github.com/mingodad/GLPK/tree/local-set-param 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 -> 
https://github.com/mingodad/GLPK/releases/tag/test .

====

#ifndef glp_double
    #ifdef WITH_LONG_DOUBLE
        #define glp_double long double
        #define GLP_DBL_EPSILON LDBL_EPSILON
        #define GLP_DBL_FMT_G "Lg"
        #define GLP_DBL_FMT_F "Lf"
        #define GLP_DBL_FMT_E "LE"
        #define GLP_DBL_FMT_e "Le"
    #else
        #define glp_double double
        #define GLP_DBL_EPSILON DBL_EPSILON
        #define GLP_DBL_FMT_G "g"
        #define GLP_DBL_FMT_F "f"
        #define GLP_DBL_FMT_E "E"
        #define GLP_DBL_FMT_e "e"
    #endif
#endif

====

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.