On Thu, 22 Aug 2013 00:46:06 +0200 Irek Szczesniak wrote:
> On Thu, Aug 22, 2013 at 12:26 AM, Irek Szczesniak <[email protected]>
> wrote:
> > On Thu, Aug 22, 2013 at 12:03 AM, Glenn Fowler <[email protected]>
> > wrote:
> >>
> >> On Wed, 21 Aug 2013 22:24:52 +0200 Tina Harriott wrote:
> >>> On 21 August 2013 20:02, David Korn <[email protected]> wrote:
> >>> > cc: [email protected]
> >>> > Subject: Re: Re: Re: [ast-developers] "${_Bool.true}" not working... /
> >>> > was: Re: AT&T Software Technology ast alpha software download update
> >>> > --------
> >>> >
> >>> >> > The reason why I want this to work are references, after which you
> >>> >> > can
> >>> >> > no longer differ between plain bool and array element book:
> >>> >> > ./arch/linux.i386-64/bin/ksh -o nounset -c 'bool -a b=( [4][5]=true )
> >>> >> > ; nameref nb=b[4][5] ; print ${nb.true}'
> >>> >> > ./arch/linux.i386-64/bin/ksh: nb.true: parameter not set
> >>> >> >
> >>> >> > /arch/linux.i386-64/bin/ksh -o nounset -c 'bool b ; nameref nb=b ;
> >>> >> > print ${nb.true}'
> >>> >> > 1
> >>> >>
> >>> >> Is the next alpha going to fix this? The bug is hurting my ability to
> >>> >> use the _Bool.
> >>> >>
> >>> >> Wendy
> >>> >>
> >>> >
> >>> > The next alpha (not counting the one gsf wants to test without my
> >>> > changes), allow bool array variables (and name references to them)
> >>> > to have .enumconstat appended.
> >>
> >>> Will num.MIN/.MAX/.EPSILON/.M_PI work in the next alpha, too? The code
> >>> appears to be almost identical for all those cases...
> >>
> >> the libast features/float iffe script will need to provide *_EPSILON
> >> on systems that don't provide it in <float.h>, and it has to be done
> >> without the benefit of libast, meaning possibly no hexfloat and most
> >> likely a printf that does a bad job rounding floating point numbers
> >>
> >> anybody have C code that does that sans <float.h> ?
> >
> > That's an easy request: http://en.wikipedia.org/wiki/Machine_epsilon
> On a 2nd thought, there are only binary16, binary32, binary64,
> binary128 and the nonstandard x387 binary80
> to deal with. libast doesn't support binary16 yet, leaving four
> formats which can be identified through sizeof and handled with
> constants embedded in the iffe probe. That might be safer than to
> trust an algorithm which may fall victim to bizarre compiler
> optimizations or bugs.
thanks for the ref
tabulating may not be that easy
bear with me ...
libast related regression tests are in
$PACKAGEROOT/src/cmd/tests
in there is the ast strtof test harness strtof.c which generates the exeutable
$INSTALLROOT/src/cmd/tests/strtof
when strtof is run with no arguments it prints out a one line signature for the
current floating point implementation (I just today added sizeof() to the
signature)
the signature is the first line of output from this program:
--
#include <stdio.h>
#include <float.h>
#define S(x) # x
#define X(x) S(x)
int
main(int argc, char** argv)
{
printf("%u.%u.%u.%u-%u.%u.%u.%u-%u.%u.%u.%u\n",
8 * sizeof(float), FLT_DIG, -(FLT_MIN_10_EXP), FLT_MAX_10_EXP,
8 * sizeof(double), DBL_DIG, -(DBL_MIN_10_EXP), DBL_MAX_10_EXP,
8 * sizeof(long double), LDBL_DIG, -(LDBL_MIN_10_EXP),
LDBL_MAX_10_EXP);
printf("\n");
printf(" FLT_MAX %s\n", X(FLT_MAX));
printf(" DBL_MAX %s\n", X(DBL_MAX));
printf("LDBL_MAX %s\n", X(LDBL_MAX));
printf("\n");
printf(" FLT_EPSILON %s\n", X(FLT_EPSILON));
printf(" DBL_EPSILON %s\n", X(DBL_EPSILON));
printf("LDBL_EPSILON %s\n", X(LDBL_EPSILON));
return 0;
}
--
the signatures are used to select the approriate strtof test script which is
read by the strtof harness:
strtof-<SIGNATURE>.tst
this is what I've collected so far
32.6.37.38-64.15.307.308-128.31.291.308 # lost access to machine
32.6.37.38-64.15.307.308-128.31.307.308 # lost access to machine
--
# i386-32
32.6.37.38-64.15.307.308-96.18.4931.4932
FLT_MAX 3.40282347e+38F
DBL_MAX 1.7976931348623157e+308
LDBL_MAX 1.18973149535723176502e+4932L
FLT_EPSILON 1.19209290e-7F
DBL_EPSILON 2.2204460492503131e-16
LDBL_EPSILON 1.08420217248550443401e-19L
# i386-64
32.6.37.38-64.15.307.308-128.18.4931.4932
FLT_MAX 3.40282347e+38F
DBL_MAX 1.7976931348623157e+308
LDBL_MAX 1.18973149535723176502e+4932L
FLT_EPSILON 1.19209290e-7F
DBL_EPSILON 2.2204460492503131e-16
LDBL_EPSILON 1.08420217248550443401e-19L
# ppc64
32.6.37.38-64.15.307.308-64.15.307.308
FLT_MAX 3.40282347e+38F
DBL_MAX 1.7976931348623157e+308
LDBL_MAX 1.7976931348623157e+308L
FLT_EPSILON 1.19209290e-7F
DBL_EPSILON 2.2204460492503131e-16
LDBL_EPSILON 2.2204460492503131e-16L
# ia64
4.6.37.38-8.15.307.308-16.33.4931.4932
FLT_MAX 3.40282346638528859812E+38F
DBL_MAX 1.79769313486231570815E+308
LDBL_MAX 1.18973149535723176508575932662800702E+4932L
FLT_EPSILON 1.19209289550781250000E-07F
DBL_EPSILON 2.22044604925031308085E-16
LDBL_EPSILON 1.92592994438723585305597794258492732E-34L
# sun4
32.6.37.38-64.15.307.308-128.33.4931.4932
FLT_MAX 3.4028234663852885981170E+38F
DBL_MAX 1.7976931348623157081452E+308
LDBL_MAX 1.189731495357231765085759326628007016E+4932L
FLT_EPSILON 1.1920928955078125000000E-07F
DBL_EPSILON 2.2204460492503130808473E-16
LDBL_EPSILON 1.925929944387235853055977942584927319E-34L
# mvs.390
32.6.78.75-64.15.78.75-128.32.78.75
FLT_MAX ((const float) ((float * const)(*_Gtab(26)))[1])
DBL_MAX ((const double) ((double * const)(*_Gtab(27)))[1])
LDBL_MAX ((const long double) ((long double * const)(*_Gtab(28)))[1])
FLT_EPSILON ((const float) ((float * const)(*_Gtab(26)))[2])
DBL_EPSILON ((const double) ((double * const)(*_Gtab(27)))[2])
LDBL_EPSILON ((const long double) ((long double * const)(*_Gtab(28)))[2])
# mvs.390 with %g for *_MAX and *_EPSILON
FLT_MAX 7.2370051e+75
DBL_MAX 7.237005577332262e+75
LDBL_MAX 7.23700557733226221397318656304299e+75
FLT_EPSILON 9.5367432e-07
DBL_EPSILON 2.220446049250313e-16
LDBL_EPSILON 3.08148791101957736488956470813588e-33
--
it would be good to know of any other signatures and the corresponding *_EPSILON
and also which ones correspond to IEEE 754
for example, ia64 and sun4 can't both be IEEE 754 considering the diffs, can
they?
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
