On Mon, Aug 19, 2013 at 11:24 PM, Roland Mainz <[email protected]> wrote:
> On Mon, Aug 19, 2013 at 8:10 PM, David Korn <[email protected]> wrote:
>> cc: [email protected]
>> Subject: Re: Re: [ast-developers] float i; (( i.MAX, i.MIN, i.EPSILON ))
>> constants?
>> --------
>>> Erm... doesn't this just require a small modification of the
>>> arithmetic engine (I don't know how to do the same for a plain
>>> ${i.MAX}), e.g. do a type-based (technically we "only" have six types
>>> - three integer and three float) lookup of the matching constant value
>>> if an integer name is followed by a '.' ?
>>
>> First of all there are 9 types, 3 float, 3 integer, and 3 unsigned.
>>
>> Secondly, it is much simpler of i.MAX only appears in arithmetic
>> expressions and cannot be used as ${i.MAX} because ${i.MAX} is
>> more complex because it needs to work with ${i.MAX op string}
>> and ${op i.MAX} as well.
>>
>> I am not even sure how to implement ${!i.M*} given the current
>> architecture.
>>
>> Maybe I should restrict b.true to arithmetic expressions only.
>> Programs that want ${i.MAX} can do $((i.MAX)).
>>
>> Anyway, I have enough bug reports to keep me busy for now.
>
> Attached (as "astksh20130814_math_constants001.diff.txt") is a
> prototype patch which allows constants to be defined like this:
> -- snip --
> $ ksh -o nounset -c 'compound .sh.mathconst=( float LDBL_M_PI=3.14 ) ;
> float x=5.5 ; print $((x.M_PI)) ${x.M_PI}'
> 3.14 3.14
> -- snip --
>
> AFAIK we need the following constants (mostly derived from X/OPEN and
> my own math code):
> 1. min/max/etc. limits:
> -- snip --
> # integer for $((i.MIN)) and $((i.MAX))
[snip]
>
> # float for $((i.MANT_DIG , i.MIN_EXP , i.MIN_10_EXP, i.MAX_EXP ,
[snip]
> -- snip --
>
> 2. constants (need to be per-type to get round-offs correct):
> -- snip --
[snip]
> -- snip --
> On a 2nd thought... maybe we should define these constants via C99
> hexfloat to make sure the last bits are OK...
Erm... David/Glenn: Can we chat this week about the code, please ? I
talked with Olga and she thinks ${var.CONST} (returning a C99 hexfloat
value) may be mandatory (together with [[ -v var.CONST ]] to test
whether the value is there) for same use cases. My idea to solve it
would be to use a hybrid approach... use a table and create the
|Namval_t *| nodes on the fly on the first access (that would avoid
any resource/startup time penalty and give us maximum flexibility).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
