Re: [bug-gawk] gawk-4.0.0 test failures on HP/UX 10.20

[Aharon Robbins]

Hi. You're right.  So make that:

        function comp_val_num(s1, v1, s2, v2,   num)
        {
                num = "^[-+]?([0-9]+[.]?[0-9]*|[.][0-9]+)([eE][-+]?[0-9]+)?$"
                # force stable sort, compare as strings if not numeric
                if ((v1 - v2) == 0 && (v1 !~ num || v2 !~ num))
                        return comp_val_str(s1, v1, s2, v2)
                return (v1 - v2)
        }

Please try that and let me know how it goes.

It changes the output for me - but it's still "correct", moving the
uppercase value before lower case ones.

Thanks,

Arnold

> Date: Mon, 25 Jul 2011 12:05:38 -0500
> From: Peter Fales <address@hidden>
> To: Aharon Robbins <address@hidden>
> Cc: address@hidden
> Subject: Re: [bug-gawk] gawk-4.0.0 test failures on HP/UX 10.20
>
> Aharon,
>
> I haven't actually tested this, but that doesn't look right to 
> me.    You have it returning a boolean (v1 < v2) in the string case
> and and positive/zero/negative in the numeric case.   Shouldn't it
> have logic like comp_val_str?
>
> On Fri, Jul 22, 2011 at 11:43:07AM +0300, Aharon Robbins wrote:
> > Hi. Apologies for not answering earlier, this got buried in my inbox.
> > 
> > I think you are right; we are expecting qsort() to be stable - the built-in
> > comparison functions go to extra work to make the results be stable.
> > The test should probably be enhanced to something like:
> > 
> >     function comp_val_num(s1, v1, s2, v2,   num)
> >     {
> >             num = "^[-+]?([0-9]+[.]?[0-9]*|[.][0-9]+)([eE][-+]?[0-9]+)?$"
> >             # force stable sort, compare as strings if not numeric
> >             if ((v1 - v2) == 0 && (v1 !~ num || v2 !~ num))
> >                     return v1 < v2
> >             return (v1 - v2)
> >     }
> > 
> > Thanks,
> > 
> > Arnold
> > 
> > > Date: Fri, 1 Jul 2011 10:10:21 -0500
> > > From: Peter Fales <address@hidden>
> > > To: address@hidden
> > > Subject: [bug-gawk] gawk-4.0.0 test failures on HP/UX 10.20
> > >
> > > I'm not completely sure that this is a bug.  However, the README
> > > file in the test directory says that any mismatches between
> > > _foo and foo.ok should be reported as a bug.   
> > >
> > > On our HP/UX 10.20 machine, the sortu test is failing.   The actual
> > > results are:
> > >
> > > --- asort(a, b, "comp_val_num"), IGNORECASE = 0---
> > > [1]       :barz      Zebra     
> > > [2]       :blattt    blattt    
> > > [3]       :Zebra     barz      
> > > [4]       :1234      234       
> > > [5]       :234       1234      
> > >
> > > but the expected results in sortu.ok are:
> > >
> > > --- asort(a, b, "comp_val_num"), IGNORECASE = 0---
> > > [1]       :barz      barz      
> > > [2]       :blattt    blattt    
> > > [3]       :Zebra     Zebra     
> > > [4]       :1234      234       
> > > [5]       :234       1234      
> > >
> > > The numeric values are correctly sorted in numeric order, and string
> > > values (numerically zero) are correctly placed at the beginning. 
> > > Apparently, the test expects the sort to be stable, but I can't find
> > > any indication of that in the documentation.  
> > >
> > > So, I'm not sure if this is a bug in the test (the change in the 
> > > order of the first three values is OK), the documentation (which
> > > should say that the sort is stable), or the code (which does not
> > > implement a stable sort).
> > >
> > > It looks like array.c depends on the system-supplied qsort().   Is that
> > > the issue?   The HP/UX man page for qsort says:
> > >
> > >   The order in the output of two items which compare as equal  is  
> > >   unpredictable.
> > >
> > > But, the linux (Fedora 14) man page has similar language:
> > >
> > >   If two members compare as equal, their order in the sorted array is 
> > >   undefined.
> > > -- 
> > > Peter Fales
> > > Alcatel-Lucent
> > > Member of Technical Staff
> > > 1960 Lucent Lane
> > > Room: 9H-505
> > > Naperville, IL 60566-7033
> > > Email: address@hidden
> > > Phone: 630 979 8031
>
> -- 
> Peter Fales
> Alcatel-Lucent
> Member of Technical Staff
> 1960 Lucent Lane
> Room: 9H-505
> Naperville, IL 60566-7033
> Email: address@hidden
> Phone: 630 979 8031
>