[ast-developers] "${_Bool.true}" not working... / was: Re: AT&T Software Technology ast alpha software download update

Post by Roland Mainz

[snip]

-- snip --
$ ~/bin/ksh -o nounset -c 'print "${_Bool.true}"'
/home/test001/bin/ksh: _Bool.true: parameter not set
$ ~/bin/ksh -o nounset -c 'print "$((_Bool.true))"'
/home/test001/bin/ksh: _Bool.true: parameter not set
-- snip --

It works for me:
ksh -o nounset -c 'bool b ; print $((b.true))'
1

But there is still a bug left:

var.true/var.false don't work for array elements:
./arch/linux.i386-64/bin/ksh -o nounset -c 'bool -a b=( [4][5]=true )
; print $((b[4][5].true))'
./arch/linux.i386-64/bin/ksh: b[4][5].true: parameter not set
./arch/linux.i386-64/bin/ksh -o nounset -c 'bool -A b=( [lin]=true ) ;
print $((b[lin].true))'
./arch/linux.i386-64/bin/ksh: b[lin].true: parameter not set

Wendy

David Korn

2013-08-12 12:33:56 UTC

cc: ast-developers at research.att.com
Subject: Re: Re: [ast-developers] "${_Bool.true}" not working... / was: Re: AT&T Software Technology ast alpha software download update
--------

Post by Wendy Lin
./arch/linux.i386-64/bin/ksh -o nounset -c 'bool -a b=( [4][5]=true )
; print $((b[4][5].true))'
./arch/linux.i386-64/bin/ksh: b[4][5].true: parameter not set
./arch/linux.i386-64/bin/ksh -o nounset -c 'bool -A b=( [lin]=true ) ;
print $((b[lin].true))'
./arch/linux.i386-64/bin/ksh: b[lin].true: parameter not set
Wendy

There is no need for that to work since all elements of any array
are of the same type so that b.true works for an array element.

David Korn
dgk at research.att.com

Wendy Lin

2013-08-12 15:52:36 UTC

Post by David Korn
cc: ast-developers at research.att.com
Subject: Re: Re: [ast-developers] "${_Bool.true}" not working... / was: Re: AT&T Software Technology ast alpha software download update
--------

There is no need for that to work since all elements of any array
are of the same type so that b.true works for an array element.

It doesn't work in ksh 93v- 2013-08-05:
./arch/linux.i386-64/bin/ksh -o nounset -c 'bool -a b=( [4][5]=true )
; print $((b[4][5].true))'
./arch/linux.i386-64/bin/ksh: b[4][5].true: parameter not set

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

There is a 3rd bug:
./arch/linux.i386-64/bin/ksh -o nounset -c 'bool b ; print
"${b.true},$((b.true))'
1,1

It should print true,1 and not 1,1
${b.true} is not expanding to a true/false string as I need it.

Wendy

Wendy Lin

2013-08-21 11:18:34 UTC

There is no need for that to work since all elements of any array
are of the same type so that b.true works for an array element.

./arch/linux.i386-64/bin/ksh -o nounset -c 'bool -a b=( [4][5]=true )
; print $((b[4][5].true))'
./arch/linux.i386-64/bin/ksh: b[4][5].true: parameter not set
The reason why I want this to work are references, after which you can
./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

Tina Harriott

2013-08-21 16:13:40 UTC

There is no need for that to work since all elements of any array
are of the same type so that b.true works for an array element.

Is the next alpha going to fix this? The bug is hurting my ability to
use the _Bool.

Roland, would it be hard to adopt your patch from the 'Re:
[ast-developers] float i; (( i.MAX, i.MIN, i.EPSILON )) constants?'
thread to work with the bool type, too?

Tina

--
Tina Harriott - Women in Mathematics
Contact: tina.harriott.math at gmail.com

David Korn

2013-08-21 18:02:22 UTC

cc: ast-developers at research.att.com
Subject: Re: Re: Re: [ast-developers] "${_Bool.true}" not working... / was: Re: AT&T Software Technology ast alpha software download update
--------

Post by Wendy Lin
The reason why I want this to work are references, after which you can
./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.

David Korn
dgk at research.att.com

Tina Harriott

2013-08-21 20:24:52 UTC

Post by David Korn
cc: ast-developers at research.att.com
Subject: Re: Re: Re: [ast-developers] "${_Bool.true}" not working... / was: Re: AT&T Software Technology ast alpha software download update
--------

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...

Tina

--
Tina Harriott - Women in Mathematics
Contact: tina.harriott.math at gmail.com

Glenn Fowler

2013-08-21 22:03:21 UTC

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> ?

Irek Szczesniak

2013-08-21 22:26:07 UTC

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

Irek

Irek Szczesniak

2013-08-21 22:46:06 UTC

Post by Irek Szczesniak

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.

Irek

Glenn Fowler

2013-08-22 17:32:07 UTC

Post by Irek Szczesniak

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

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?

ольга крыжановская

2013-08-22 18:07:08 UTC

IA64 and SPARC64 64bit use 128bit long double. On x86+AMD64 long
double is an 80bit floating point type. On some platforms long double
is identical to double, because they do not support a wider floating
point type.

Olga

Post by Irek Szczesniak

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

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)
--
#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
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
ast-developers at lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-developers

--
, _ _ ,
{ \/`o;====- Olga Kryzhanovska -====;o`\/ }
.----'-/`-/ olga.kryzhanovska at gmail.com \-`\-'----.
`'-..-| / http://twitter.com/fleyta \ |-..-'`
/\/\ Solaris/BSD//C/C++ programmer /\/\
`--` `--`

Glenn Fowler

2013-08-22 18:28:31 UTC