New limited range type?

New limited range type?

[Martin Dowie]

Ok, as we're in "my favourite thing I'd like in Ada" season, here's mine...

I'd like to be able to declare integer/float/fixed/decimal types that are
limited, at both ends, and never raise exceptions, e.g.

   type Safe_Degrees is
      digits 6 limited range -180.0 .. +180.0;  -- new use of 'limited'

such that

declare
   A, B, C : Safe_Degrees;
begin
   B := 170.0;
   C := 50.0;
   A := B + C;
   -- A equals +180.0 after this statement
   ...
end;

We limit values like this all the time (we're not allowed exceptions)
and although we can write and instantiate generics to help, it's still
a pain.

Could even prove useful in things like SPARK?

Flames welcome! :-)

Re: New limited range type?

[Hyman Rosen]

Martin Dowie wrote:
> I'd like to be able to declare integer/float/fixed/decimal types that are
> limited, at both ends, and never raise exceptions

This is generally called saturating arithmetic, and you are
far from the first to request it. I belive the difficulty
lies in assigning meaning to expressions and intermediate
results. What if you say A := B + C - D, with values such
that (B + C) saturates but B + (C - D) does not?

Re: New limited range type?

[Martin Dowie]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1068220677.950551@master.nyc.kbcfp.com...
> Martin Dowie wrote:
> > I'd like to be able to declare integer/float/fixed/decimal types that
are
> > limited, at both ends, and never raise exceptions
>
> This is generally called saturating arithmetic, and you are
> far from the first to request it.

Well, at least I'm not asking for anything _completely_ stupid then! :-)


> I belive the difficulty
> lies in assigning meaning to expressions and intermediate
> results. What if you say A := B + C - D, with values such
> that (B + C) saturates but B + (C - D) does not?

Standard operator precedent rules should apply - I can't see
that as being outragous?

Re: New limited range type?

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

I agree,

if in this situation  (B + C) saturates

but B + (C - D) does not then it wouldn't saturate in the end result However

B + C - D would saturate at the B + C part of the operation

-- 
"To err is human.  To really screw up, you need C++!"

St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:boggo8$3us$1@titan.btinternet.com...
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1068220677.950551@master.nyc.kbcfp.com...
> > Martin Dowie wrote:
> > > I'd like to be able to declare integer/float/fixed/decimal types that
> are
> > > limited, at both ends, and never raise exceptions
> >
> > This is generally called saturating arithmetic, and you are
> > far from the first to request it.
>
> Well, at least I'm not asking for anything _completely_ stupid then! :-)
>
>
> > I belive the difficulty
> > lies in assigning meaning to expressions and intermediate
> > results. What if you say A := B + C - D, with values such
> > that (B + C) saturates but B + (C - D) does not?
>
> Standard operator precedent rules should apply - I can't see
> that as being outragous?
>
>
>
>

Re: New limited range type?

[Hyman Rosen]

Martin Dowie wrote:
> Standard operator precedent rules should apply - I can't see
> that as being outragous?

But Ada doesn't define operator evaluation order, so this would
be a major change in the language. (Not a bad one, just big.)

Re: New limited range type?

[Martin Dowie]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1068224385.790621@master.nyc.kbcfp.com...
> Martin Dowie wrote:
> > Standard operator precedent rules should apply - I can't see
> > that as being outragous?
>
> But Ada doesn't define operator evaluation order, so this would
> be a major change in the language. (Not a bad one, just big.)

Well it 'kind of' does in that the order must be "an allowed result
for the left-to-right association".

You could argue that the case "A := B + C - D," for these 'limited
range' types _can_only_ be equivilent to "A := (B + C) - D;".

Re: New limited range type?

[Larry Hazel]

Martin Dowie wrote:
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1068224385.790621@master.nyc.kbcfp.com...
> 
>>Martin Dowie wrote:
>>
>>>Standard operator precedent rules should apply - I can't see
>>>that as being outragous?
>>
>>But Ada doesn't define operator evaluation order, so this would
>>be a major change in the language. (Not a bad one, just big.)
> 
> 
> Well it 'kind of' does in that the order must be "an allowed result
> for the left-to-right association".
> 
> You could argue that the case "A := B + C - D," for these 'limited
> range' types _can_only_ be equivilent to "A := (B + C) - D;".
> 
> 
> 
An analog computer implements saturating arithmetic.  Oh my God, how 
long has it been since anyone saw an analog computer.  The sum B + C - D 
would be computed all at once and would only saturate if the final 
result was out of range.  So, I think the expression should be evaluated 
in a base type with saturation applied to the result.

Re: New limited range type?

[Martin Dowie]

"Larry Hazel" <lhhazel@otelco.net> wrote in message
news:l%Sqb.1767$X5.22782@eagle.america.net...
> > You could argue that the case "A := B + C - D," for these 'limited
> > range' types _can_only_ be equivilent to "A := (B + C) - D;".
> >
> An analog computer implements saturating arithmetic.  Oh my God, how
> long has it been since anyone saw an analog computer.  The sum B + C - D
> would be computed all at once and would only saturate if the final
> result was out of range.  So, I think the expression should be evaluated
> in a base type with saturation applied to the result.

or, how about lets not and support the 99.99999999999999999999999etc%
digital world only! :-)

Is there an Ada (any variant) compiler for an analogue computer?..

Re: New limited range type?

[Larry Hazel]

Martin Dowie wrote:

> "Larry Hazel" <lhhazel@otelco.net> wrote in message
> news:l%Sqb.1767$X5.22782@eagle.america.net...
> 
>>>You could argue that the case "A := B + C - D," for these 'limited
>>>range' types _can_only_ be equivilent to "A := (B + C) - D;".
>>>
>>
>>An analog computer implements saturating arithmetic.  Oh my God, how
>>long has it been since anyone saw an analog computer.  The sum B + C - D
>>would be computed all at once and would only saturate if the final
>>result was out of range.  So, I think the expression should be evaluated
>>in a base type with saturation applied to the result.
> 
> 
> or, how about lets not and support the 99.99999999999999999999999etc%
> digital world only! :-)
> 
> Is there an Ada (any variant) compiler for an analogue computer?..
> 
> 
I seriously doubt you will find any kind of compiler that will correctly 
wire an analog patchboard.  But I surely could have used one in the 60s 
and 70s.

Re: New limited range type?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]


"Hyman Rosen" <hyrosen@mail.com> a �crit dans le message de news:1068224385.790621@master.nyc.kbcfp.com...
> Martin Dowie wrote:
> > Standard operator precedent rules should apply - I can't see
> > that as being outragous?
>
> But Ada doesn't define operator evaluation order, so this would
> be a major change in the language. (Not a bad one, just big.)
>
Nope.
Ada does not define "evaluation order", but it does define associativity.
A+B-C is definitely (A+B) - C
However, Ada does not define whether (A+B) is evaluated before or after C.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: New limited range type?

[Hyman Rosen]

Jean-Pierre Rosen wrote:
> Nope.
> Ada does not define "evaluation order", but it does define associativity.
> A+B-C is definitely (A+B) - C

But in floating arithmetic, A + B - C may produce the numerically
correct result even if A + B by itself would overflow. Would this
need to be changed for saturating arithmetic? If A + B would saturate
but A + B - C (in ordinary arithmetic) would not, should the result
be required to be UPPER_LIMIT - C?

Re: New limited range type?

[Robert I. Eachus]

Hyman Rosen wrote:

> But in floating arithmetic, A + B - C may produce the numerically
> correct result even if A + B by itself would overflow. Would this
> need to be changed for saturating arithmetic? If A + B would saturate
> but A + B - C (in ordinary arithmetic) would not, should the result
> be required to be UPPER_LIMIT - C?

No.  This is a consequence of the principle in Ada that predefined 
operations return a value of the base type, and any constraint checks 
required for a subtype are done as part of the assignment operation.

If bounded types were added to the RM without modifying 4.5(8&10), then 
if A + B is within the range of the base type, the result of A + B - C 
would be REQUIRED to be the mathematically correct result or UPPER_LIMIT 
if (A + B - C) > UPPER_LIMIT.  If the mathematical result of A + B is 
outside the base range for the type then the permitted result set could 
contain additional values.

But assuming that type'Base'Last > 2 * Upper_Limit, then overflow would 
not be an issue (even if the value of C were less than zero).

Incidently this is an argument for adding saturating arithmetic to the 
language, as you can't do it right by overloading the math operations. 
In the case of a (language or implementation defined) attribute, you 
would have to write every calculation such as this as:

X := Some_Subtype'Limit(A + B - C);

Of course, that makes what is going on very clear...
-- 
                                           Robert I. Eachus

100% Ada, no bugs--the only way to create software.

Re: New limited range type?

[tmoran]

>In the case of a (language or implementation defined) attribute, you
>would have to write every calculation such as this as:
>
>X := Some_Subtype'Limit(A + B - C);
>
>Of course, that makes what is going on very clear...
  Sometimes "very clear" conflicts with "higher abstraction level".
If the variables involved were light intensities in 0 .. 255, say,
"Observed := Direct + Reflected - Absorbed;" says what's going
on just fine, IMHO.  If someone wants to be even more explicit,
"Observed := Brightness'(Direct + Reflected - Absorbed);" should
do the job.  It's overkill to say
"Observed := Brightness'Limit(Direct + Reflected - Absorbed);"

Re: New limited range type?

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1068220677.950551@master.nyc.kbcfp.com>...
> Martin Dowie wrote:
> > I'd like to be able to declare integer/float/fixed/decimal types that are
> > limited, at both ends, and never raise exceptions
> 
> This is generally called saturating arithmetic, and you are
> far from the first to request it. I belive the difficulty
> lies in assigning meaning to expressions and intermediate
> results. What if you say A := B + C - D, with values such
> that (B + C) saturates but B + (C - D) does not?

Well, this may be a very naive answer, but it seems that there's
already an Ada solution to the difficulty: why not just saturate under
the same circumstances that a normal range-limited type would generate
an out-of-range exception?

Mike

Re: New limited range type?

[Marin David Condic]

But that's just a matter of order of evaluation, which is well defined. 
You've got Left-To-Right without parens which implies one result and 
with parens, you have another result. Other equations have evaluation 
order dependencies - why not here?

More important is this: At present, what does it do with respect to 
raising an exception? With fixed precision on the RHS, it would raise an 
exception one way, but not another. Couldn't it saturate instead? With 
infinite precision on the RHS, what happens when you assign it to the 
LHS? Overflow/Exception? Why can't it saturate there? The saturation is 
primarily a benefit when it gets assigned to the LHS - not on the 
intermediate results. So long as you deal with that situation, you're 
all right.

MDC


Hyman Rosen wrote:
> 
> This is generally called saturating arithmetic, and you are
> far from the first to request it. I belive the difficulty
> lies in assigning meaning to expressions and intermediate
> results. What if you say A := B + C - D, with values such
> that (B + C) saturates but B + (C - D) does not?
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================

Re: New limited range type?

[Mike Silva]

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message news:<bogf20$q1$1@titan.btinternet.com>...
> Ok, as we're in "my favourite thing I'd like in Ada" season, here's mine...
> 
> I'd like to be able to declare integer/float/fixed/decimal types that are
> limited, at both ends, and never raise exceptions, e.g.
> 
>    type Safe_Degrees is
>       digits 6 limited range -180.0 .. +180.0;  -- new use of 'limited'
.....

If the details could be worked out I'd sure like to see it.  It would
answer a *very* common need in the "real world" that Ada was designed
to address.

Mike

Re: New limited range type?

[Nick Roberts]

Mike Silva wrote:

> "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message news:<bogf20$q1$1@titan.btinternet.com>...
> 
>>Ok, as we're in "my favourite thing I'd like in Ada" season, here's mine...
>>
>>I'd like to be able to declare integer/float/fixed/decimal types that are
>>limited, at both ends, and never raise exceptions, e.g.
>>
>>   type Safe_Degrees is
>>      digits 6 limited range -180.0 .. +180.0;  -- new use of 'limited'
> 
> .....
> 
> If the details could be worked out I'd sure like to see it.  It would
> answer a *very* common need in the "real world" that Ada was designed
> to address.

I have an alternative proposal: a new language-defined attribute Conform, 
which would be applicable to any fixed-point subtype S, and would be a 
function with the profile:

    function S'Conform (X: in universal_real) return S;

If X lies within the range of S, the function returns S. If X > S'Last, the 
function returns S'Last. If X < S'First, the function returns S'First. The 
function has the convention intrinsic.

To recast Martin's example, we would have:

    declare
       type Working_Degrees is
          digits 6 range -100*180.0 .. +100*180.0;  -- normal fixed-point
       subtype Normal_Degrees is Working_Degrees range -180.0 .. +180.0;
       A, B, C : Normal_Degrees;
    begin
       B := 170.0;
       C := 50.0;
       A := Normal_Degrees'Conform(B + C);
       -- A equals +180.0 after this statement
       ...
    end;

Note how I define a fixed point type to provide a big enough base range (in 
this case 50 complete turns either way) for all calculations, and then a 
subtype of it to define the required confined or normalised range.

I think the explicit use of the Conform attribute aids readability. The 
reviewer will not be kept in the dark that something unusual is going on. 
In addition, there can be no ambiguity as to where, in a complex 
expression, a normalisation takes place. Finally, the change to the 
standard is lesser (merely a new attribute).

-- 
Nick Roberts

Re: New limited range type?

[Martin Dowie]

Nick Roberts <nick.roberts@acm.org> wrote in message news:<bojou0$1f4o0i$1@ID-25716.news.uni-berlin.de>...
> I have an alternative proposal: a new language-defined attribute Conform, 
> which would be applicable to any fixed-point subtype S, and would be a 
> function with the profile:
> 
>     function S'Conform (X: in universal_real) return S;

I can cope with that - although I don't like the name much. How about:

   function S'Limit (X:...

 
[snip]
> Note how I define a fixed point type to provide a big enough base range (in 
> this case 50 complete turns either way) for all calculations, and then a 
> subtype of it to define the required confined or normalised range.

While that's good technique, I presume your NOT saying that the RM would
require this?

Also, why not allow it for any scalar type?

-- Martin

Re: New limited range type?

[Nick Roberts]

Martin Dowie wrote:

>>    function S'Conform (X: in universal_real) return S;
> 
> I can cope with that - although I don't like the name much.

I agree, Conform is not good.

> How about:
> 
>    function S'Limit (X:...

Or maybe Limit_to_Bounds? Wordy, but clearer.

>>Note how I define a fixed point type to provide a big enough base range (in 
>>this case 50 complete turns either way) for all calculations, and then a 
>>subtype of it to define the required confined or normalised range.
> 
> While that's good technique, I presume your NOT saying that the RM would
> require this?

I thinkj it would be necessary to adopt this approach, since the base range 
required cannot be guessed. I think the neatest solution is to require a 
named type with this range to be declared, and then subtypes with the 
required limited ranges to be declared and used to indicate the bounds of 
the operation.

> Also, why not allow it for any scalar type?

Yes, I think you're right. Shall I send a proposal to ada-comment?

-- 
Nick Roberts

Re: New limited range type?

[Martin Dowie]

> > How about:
> > 
> >    function S'Limit (X:...
> 
> Or maybe Limit_to_Bounds? Wordy, but clearer.

I still prefer 'Limit ;-)

I don't think the extra words add much, if I saw "'Limit" and I'd never
seen it before I'd simply look up the RM. There are loads of existing
attribute names that could be wordier to be made clearer...


> > While that's good technique, I presume your NOT saying that the RM would
> > require this?
> 
> I thinkj it would be necessary to adopt this approach, since the base range 
> required cannot be guessed. I think the neatest solution is to require a 
> named type with this range to be declared, and then subtypes with the 
> required limited ranges to be declared and used to indicate the bounds of 
> the operation.

No it isn't - like I said in my original post, it can all be done with
generics as it is - it's just a pain to have to keep including new
instances when it could easily be part of the language - see example
at the end of this reply.


> > Also, why not allow it for any scalar type?
> 
> Yes, I think you're right. Shall I send a proposal to ada-comment?

Ok :-)

-----------------------------
-- generic_limit_fixed.ads --
-----------------------------
generic
   type T is delta <>;
function Generic_Limit_Fixed (V : T'Base) return T;

-----------------------------
-- generic_limit_fixed.adb --
-----------------------------
function Generic_Limit_Fixed (V : T'Base) return T is
begin
   if V < T'First then
      return T'First;
   elsif V > T'Last then
      return T'Last;
   else
      return V;
   end if;
end Generic_Limit_Fixed;

-----------------------------
-- generic_limit_float.ads --
-----------------------------
generic
   type T is digits <>;
function Generic_Limit_Float (V : T'Base) return T;

-----------------------------
-- generic_limit_float.adb --
-----------------------------
function Generic_Limit_Float (V : T'Base) return T is
begin
   if V < T'First then
      return T'First;
   elsif V > T'Last then
      return T'Last;
   else
      return V;
   end if;
end Generic_Limit_Float;

---------------
-- tests.ads --
---------------
with Generic_Limit_Fixed;
with Generic_Limit_Float;

package Tests is

   type Safe_Fixed_Degrees is
      delta 0.125 range -180.00 .. 180.0;

   function Limit is
      new Generic_Limit_Fixed (Safe_Fixed_Degrees);

   type Safe_Float_Degrees is
      digits 6 range -180.00 .. 180.0;

   function Limit is
      new Generic_Limit_Float (Safe_Float_Degrees);

end Tests;

--------------
-- test.adb --
--------------
with Ada.Text_IO; use Ada.Text_IO;

with Tests; use Tests;

procedure Test is
   procedure Test_Float is
      A, B, C : Safe_Float_Degrees;
   begin
      B := 170.0;
      C := 50.0;
      A := Limit (B + C);
      Put_Line ("A =" & Safe_Float_Degrees'Image (A));
   end Test_Float;

   procedure Test_Fixed is
      A, B, C : Safe_Fixed_Degrees;
   begin
      B := 170.0;
      C := 50.0;
      A := Limit (B + C);
      Put_Line ("A =" & Safe_Fixed_Degrees'Image (A));
   end Test_Fixed;
begin
   Test_Float;
   Test_Fixed;
end Test;

Re: New limited range type?

[Martin Dowie]

> > Also, why not allow it for any scalar type?
> 
> Yes, I think you're right. Shall I send a proposal to ada-comment?


You'll note that from my example, you need different versions for
fixed/float and scalers - it would be nice if there was a generic
formal type parameter that allowed you to specify any *scaler*.

Perhaps you could mention that to ada-comment too? :-)

Re: New limited range type?

[Lutz Donnerhacke]

* Martin Dowie wrote:
> You'll note that from my example, you need different versions for
> fixed/float and scalers - it would be nice if there was a generic
> formal type parameter that allowed you to specify any *scaler*.

generic
   type Scaler (<>) is private;
   with function "<"(a, b : Scaler) return Boolean is <>;
   First, Last : constant Scaler;
package Generic_Limits is
   ...

Re: New limited range type?

[Marin David Condic]

That sort of gets you Ordinal, but not Scalar. For Scalar, you've got to 
import a bunch of math functions. Even then, it doesn't work very 
smoothly as a heierarchy. "Scalar" is not an "Ordinal" with some 
additional operations.

MDC


Lutz Donnerhacke wrote:
> 
> generic
>    type Scaler (<>) is private;
>    with function "<"(a, b : Scaler) return Boolean is <>;
>    First, Last : constant Scaler;
> package Generic_Limits is
>    ...


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Trying is the first step towards failure."
         --  Homer Simpson

======================================================================

Re: New limited range type?

[Martin Dowie]

Lutz Donnerhacke <lutz@iks-jena.de> wrote in message news:<slrnbr1f74.ru.lutz@taranis.iks-jena.de>...
> * Martin Dowie wrote:
> > You'll note that from my example, you need different versions for
> > fixed/float and scalers - it would be nice if there was a generic
> > formal type parameter that allowed you to specify any *scaler*.
> 
> generic
>    type Scaler (<>) is private;

You surely mean:

generic
   type Indefinite (<>) is private;

:-)

But I could easily pass 'String' to this and it would be ok. I want a
generic formal type parameter that accept Scalers and only Scalers.

-- Martin

Re: New limited range type?

[Marin David Condic]

In developing something else, I created a type heierarchy that had a 
base type "Object" from which you could derive anything, then a type 
"Ordinal" that required comparison operators, and from that, "Scalar" 
which required basic math operations. The scalar type had problems when 
you wanted things like exponentiation, since you then had to pick some 
integer or real type for various other parameters, but in general it 
worked nice for the app at hand. You could build something with a 
collection of things derived from Ordinal and presume to be able to sort 
them, etc. With the scalars, you could compute statistical data & such 
on the collection. Very useful and *much* less painful than trying to 
build generics for float, fixed, decimal, integer, etc. Plus, you could 
have a type derived from Ordinal or Scalar that had more than just a 
number associated with it. A record type with ">" or "+" operators 
defined for it would work just as well so long as you were willing to 
live with some inefficiency and ambiguity. (What does it *mean* to say 
"Y := X + Z;" if X, Y and Z are records containing a float plus a string?)

Perhaps there is a way to imply a type heierarchy on Ada types that 
would allow generics to handle any ordinal or scalar type & get the 
presumption of various comparison & math operators. Going with tagged 
types instead of generics lets you get there, but there is a certain 
amount of awkwardness and extra work involved. (You've got to have 
abstract functions for all the operators and then you have to fill them 
in, etc.) I'm not sure what the syntax would look like or how the 
language would handle the operators, but it would allow the development 
of generics for math and sorting needs without having to make all sorts 
of duplications of the code.

MDC


Martin Dowie wrote:
> 
> You'll note that from my example, you need different versions for
> fixed/float and scalers - it would be nice if there was a generic
> formal type parameter that allowed you to specify any *scaler*.
> 
> Perhaps you could mention that to ada-comment too? :-)


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Trying is the first step towards failure."
         --  Homer Simpson

======================================================================