* New limited range type?
@ 2003-11-07 15:51 Martin Dowie
2003-11-07 15:57 ` Hyman Rosen
2003-11-07 18:05 ` Mike Silva
0 siblings, 2 replies; 25+ messages in thread
From: Martin Dowie @ 2003-11-07 15:51 UTC (permalink / raw)
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! :-)
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 15:51 New limited range type? Martin Dowie
@ 2003-11-07 15:57 ` Hyman Rosen
2003-11-07 16:20 ` Martin Dowie
` (2 more replies)
2003-11-07 18:05 ` Mike Silva
1 sibling, 3 replies; 25+ messages in thread
From: Hyman Rosen @ 2003-11-07 15:57 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 15:57 ` Hyman Rosen
@ 2003-11-07 16:20 ` Martin Dowie
2003-11-07 16:36 ` Stephane Richard
2003-11-07 16:59 ` Hyman Rosen
2003-11-07 18:19 ` Mike Silva
2003-11-07 19:03 ` Marin David Condic
2 siblings, 2 replies; 25+ messages in thread
From: Martin Dowie @ 2003-11-07 16:20 UTC (permalink / raw)
"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?
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 16:20 ` Martin Dowie
@ 2003-11-07 16:36 ` Stephane Richard
2003-11-07 16:59 ` Hyman Rosen
1 sibling, 0 replies; 25+ messages in thread
From: Stephane Richard @ 2003-11-07 16:36 UTC (permalink / raw)
[-- 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?
>
>
>
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 16:20 ` Martin Dowie
2003-11-07 16:36 ` Stephane Richard
@ 2003-11-07 16:59 ` Hyman Rosen
2003-11-07 18:18 ` Martin Dowie
2003-11-12 8:22 ` Jean-Pierre Rosen
1 sibling, 2 replies; 25+ messages in thread
From: Hyman Rosen @ 2003-11-07 16:59 UTC (permalink / raw)
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.)
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 15:51 New limited range type? Martin Dowie
2003-11-07 15:57 ` Hyman Rosen
@ 2003-11-07 18:05 ` Mike Silva
2003-11-08 21:58 ` Nick Roberts
1 sibling, 1 reply; 25+ messages in thread
From: Mike Silva @ 2003-11-07 18:05 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 16:59 ` Hyman Rosen
@ 2003-11-07 18:18 ` Martin Dowie
2003-11-07 20:11 ` Larry Hazel
2003-11-12 8:22 ` Jean-Pierre Rosen
1 sibling, 1 reply; 25+ messages in thread
From: Martin Dowie @ 2003-11-07 18:18 UTC (permalink / raw)
"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;".
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 15:57 ` Hyman Rosen
2003-11-07 16:20 ` Martin Dowie
@ 2003-11-07 18:19 ` Mike Silva
2003-11-07 19:03 ` Marin David Condic
2 siblings, 0 replies; 25+ messages in thread
From: Mike Silva @ 2003-11-07 18:19 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 15:57 ` Hyman Rosen
2003-11-07 16:20 ` Martin Dowie
2003-11-07 18:19 ` Mike Silva
@ 2003-11-07 19:03 ` Marin David Condic
2 siblings, 0 replies; 25+ messages in thread
From: Marin David Condic @ 2003-11-07 19:03 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 18:18 ` Martin Dowie
@ 2003-11-07 20:11 ` Larry Hazel
2003-11-07 22:40 ` Martin Dowie
0 siblings, 1 reply; 25+ messages in thread
From: Larry Hazel @ 2003-11-07 20:11 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 20:11 ` Larry Hazel
@ 2003-11-07 22:40 ` Martin Dowie
2003-11-07 23:31 ` Larry Hazel
0 siblings, 1 reply; 25+ messages in thread
From: Martin Dowie @ 2003-11-07 22:40 UTC (permalink / raw)
"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?..
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 22:40 ` Martin Dowie
@ 2003-11-07 23:31 ` Larry Hazel
0 siblings, 0 replies; 25+ messages in thread
From: Larry Hazel @ 2003-11-07 23:31 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 18:05 ` Mike Silva
@ 2003-11-08 21:58 ` Nick Roberts
2003-11-09 14:34 ` Martin Dowie
0 siblings, 1 reply; 25+ messages in thread
From: Nick Roberts @ 2003-11-08 21:58 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-08 21:58 ` Nick Roberts
@ 2003-11-09 14:34 ` Martin Dowie
2003-11-11 5:13 ` Nick Roberts
0 siblings, 1 reply; 25+ messages in thread
From: Martin Dowie @ 2003-11-09 14:34 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-09 14:34 ` Martin Dowie
@ 2003-11-11 5:13 ` Nick Roberts
2003-11-11 10:18 ` Martin Dowie
2003-11-11 10:35 ` Martin Dowie
0 siblings, 2 replies; 25+ messages in thread
From: Nick Roberts @ 2003-11-11 5:13 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-11 5:13 ` Nick Roberts
@ 2003-11-11 10:18 ` Martin Dowie
2003-11-11 10:35 ` Martin Dowie
1 sibling, 0 replies; 25+ messages in thread
From: Martin Dowie @ 2003-11-11 10:18 UTC (permalink / raw)
> > 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;
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-11 5:13 ` Nick Roberts
2003-11-11 10:18 ` Martin Dowie
@ 2003-11-11 10:35 ` Martin Dowie
2003-11-11 10:41 ` Lutz Donnerhacke
2003-11-11 12:34 ` Marin David Condic
1 sibling, 2 replies; 25+ messages in thread
From: Martin Dowie @ 2003-11-11 10:35 UTC (permalink / raw)
> > 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? :-)
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-11 10:35 ` Martin Dowie
@ 2003-11-11 10:41 ` Lutz Donnerhacke
2003-11-11 12:37 ` Marin David Condic
2003-11-11 14:19 ` Martin Dowie
2003-11-11 12:34 ` Marin David Condic
1 sibling, 2 replies; 25+ messages in thread
From: Lutz Donnerhacke @ 2003-11-11 10:41 UTC (permalink / raw)
* 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
...
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-11 10:35 ` Martin Dowie
2003-11-11 10:41 ` Lutz Donnerhacke
@ 2003-11-11 12:34 ` Marin David Condic
1 sibling, 0 replies; 25+ messages in thread
From: Marin David Condic @ 2003-11-11 12:34 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-11 10:41 ` Lutz Donnerhacke
@ 2003-11-11 12:37 ` Marin David Condic
2003-11-11 14:19 ` Martin Dowie
1 sibling, 0 replies; 25+ messages in thread
From: Marin David Condic @ 2003-11-11 12:37 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-11 10:41 ` Lutz Donnerhacke
2003-11-11 12:37 ` Marin David Condic
@ 2003-11-11 14:19 ` Martin Dowie
1 sibling, 0 replies; 25+ messages in thread
From: Martin Dowie @ 2003-11-11 14:19 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-07 16:59 ` Hyman Rosen
2003-11-07 18:18 ` Martin Dowie
@ 2003-11-12 8:22 ` Jean-Pierre Rosen
2003-11-12 15:00 ` Hyman Rosen
1 sibling, 1 reply; 25+ messages in thread
From: Jean-Pierre Rosen @ 2003-11-12 8:22 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-12 8:22 ` Jean-Pierre Rosen
@ 2003-11-12 15:00 ` Hyman Rosen
2003-11-12 15:34 ` Robert I. Eachus
0 siblings, 1 reply; 25+ messages in thread
From: Hyman Rosen @ 2003-11-12 15:00 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-12 15:00 ` Hyman Rosen
@ 2003-11-12 15:34 ` Robert I. Eachus
2003-11-12 17:37 ` tmoran
0 siblings, 1 reply; 25+ messages in thread
From: Robert I. Eachus @ 2003-11-12 15:34 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: New limited range type?
2003-11-12 15:34 ` Robert I. Eachus
@ 2003-11-12 17:37 ` tmoran
0 siblings, 0 replies; 25+ messages in thread
From: tmoran @ 2003-11-12 17:37 UTC (permalink / raw)
>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);"
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2003-11-12 17:37 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-07 15:51 New limited range type? Martin Dowie
2003-11-07 15:57 ` Hyman Rosen
2003-11-07 16:20 ` Martin Dowie
2003-11-07 16:36 ` Stephane Richard
2003-11-07 16:59 ` Hyman Rosen
2003-11-07 18:18 ` Martin Dowie
2003-11-07 20:11 ` Larry Hazel
2003-11-07 22:40 ` Martin Dowie
2003-11-07 23:31 ` Larry Hazel
2003-11-12 8:22 ` Jean-Pierre Rosen
2003-11-12 15:00 ` Hyman Rosen
2003-11-12 15:34 ` Robert I. Eachus
2003-11-12 17:37 ` tmoran
2003-11-07 18:19 ` Mike Silva
2003-11-07 19:03 ` Marin David Condic
2003-11-07 18:05 ` Mike Silva
2003-11-08 21:58 ` Nick Roberts
2003-11-09 14:34 ` Martin Dowie
2003-11-11 5:13 ` Nick Roberts
2003-11-11 10:18 ` Martin Dowie
2003-11-11 10:35 ` Martin Dowie
2003-11-11 10:41 ` Lutz Donnerhacke
2003-11-11 12:37 ` Marin David Condic
2003-11-11 14:19 ` Martin Dowie
2003-11-11 12:34 ` Marin David Condic
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox