From: Simon Wright on
csampson(a)inetworld.net (Charles H. Sampson) writes:

> I then overloaded "+" and "-" for (Bearing, Turn_Angle) arguments
> and Bearing return value. In those functions is where the mod 360
> occurred. (Actually, mod 360.0, as it were.)

Depending on what is doing the turning, in our application that would
in some cases have to be mod 720.0 ...
From: Randy Brukardt on
"Robert A Duff" <bobduff(a)shell01.TheWorld.com> wrote in message
news:wcczkwtnvhb.fsf(a)shell01.TheWorld.com...
> Niklas Holsti <niklas.holsti(a)tidorum.invalid> writes:
>
>> Yannick Duch�ne (Hibou57) wrote:
>>> This is no more valid Ada (well.... this is still valid Ada 95, this
>>> is just not more valid Ada 2005/2012)
>>
>> In the Ada 2005 RM, see section J.10 (Obsolescent Features: Specific
>> Suppression of Checks).
>
> Right. And things in the "Obsolescent Features" annex are perfectly
> good Ada, and all Ada compilers are required to support them.
> These features are "obsolescing" so slowly that they will never
> actually become "obsolete". ;-)

Somewhat irrelevant in this case, because there is no definition or
agreement as to what it means to suppress checks on a particular type or
object. One possibility is to do nothing at all (a compiler is never
*required* to suppress checks). So while this probably will work on most
compilers, there is no guarantee that it will work the same way.

To make a more concrete example:

A : Integer : = -1;
B : Natural := 0;
pragma Suppress (Range_Check, On => B);

B := A; -- ??

The language does not say what object or type needs to be suppressed in
order to suppress the range check on this assignment. It might require the
check to be suppressed on A or on B or on both or on the subtype Natural or
on something else. So this feature is best avoided. (Note that this is as
true for Ada 83 and Ada 95 as it is for Ada 2005.)

Randy.


From: Charles H. Sampson on
Robert A Duff <bobduff(a)shell01.TheWorld.com> wrote:

> csampson(a)inetworld.net (Charles H. Sampson) writes:
>
> > <tmoran(a)acm.org> wrote:
>
> >> Bearing := (Bearing + Turn_Angle) mod 360;
> >
> > I'd be interested in hearing reactions to something I did. ...
>
> > I then overloaded "+" and "-" for (Bearing, Turn_Angle) arguments
> > and Bearing return value. In those functions is where the mod 360
> > occurred. (Actually, mod 360.0, as it were.)
> >
> > There were two advantages to doing that. The more important was
> > that previously both of the kinds of values were being represented as
> > subtypes of Long_Precision and programmers would occasionally
> > interchange them and cause big debugging problems. The second was
> > removing the "mod" from sight, which allowed the programmers to simply
> > think of taking a bearing, turning an angle, and getting the resulting
> > bearing, without worrying about all the niceties that might be going on
> > inside "+".
>
> Sounds to me like a good way to do things. It would still be a good
> idea if you called it "Turn_Left" or something like that, instead
> of "+". But I don't object to "+".

This was for the U. S. Navy, and "positive is right" is pretty much
universal. For programmers, that is, not for sailors. They think port
and starbord.

> I object to having built-in support for angle arithmetic in the
> language, though.

I don't follow. What is angle arithmetic? Whatever it is, it
sounds too specific for a general purpose language.

> Did you eliminate meaningless ops like "*"? You could do that
> by making the types private, but then you lose useful things
> like literal notation. Or you could declare "*" to be
> abstract, which is an annoyance, but might be worth it.

I would have liked to eliminate meaningless ops. As you noted,
making the types private results in the loss of literals. I wasn't
ready to go that far.

What I really want is a way to hide existing visible operations,
particularly the ones from Standard. I've asked about it before and
there doesn't seem to be too much enthusiasm, not enough to warrant the
time to get the niggling details correct. The problem is, you can't
write something like

if Current_Bearing + 0.5 > 180.0

because it's ambiguous. (Is "+" from Standard or is it the special "+"
for bearings and turn angles?) So you end up having to qualify literals
when there's only one reasonable "+" in the minds of the programmers.
Of course, you won't have that problem if your style is to always use
typed constants, but I wasn't ready to go that far either.

Charlie
--
All the world's a stage, and most
of us are desperately unrehearsed. Sean O'Casey
From: Charles H. Sampson on
Simon Wright <simon(a)pushface.org> wrote:

> csampson(a)inetworld.net (Charles H. Sampson) writes:
>
> > I then overloaded "+" and "-" for (Bearing, Turn_Angle) arguments
> > and Bearing return value. In those functions is where the mod 360
> > occurred. (Actually, mod 360.0, as it were.)
>
> Depending on what is doing the turning, in our application that would
> in some cases have to be mod 720.0 ...

I'm puzzled. Unless you're very careful, intermediate calculations
could result in a quasi-Bearing of more than 360 degrees but I'm pretty
sure most programmers on my project would have been surprised to see a
real bearing of 360 degrees or more.

Charlie
--
All the world's a stage, and most
of us are desperately unrehearsed. Sean O'Casey
From: Ludovic Brenta on
Charles H. Sampson wrote on comp.lang.ada:
[on defining "+" to add angles in modular arithmetic]
>> Sounds to me like a good way to do things.  It would still be a good
>> idea if you called it "Turn_Left" or something like that, instead
>> of "+".  But I don't object to "+".
>
>      This was for the U. S. Navy, and "positive is right" is pretty much
> universal.  For programmers, that is, not for sailors.  They think port
> and starbord.

Actually, to mathematicians and engineers, "+" is "turn counter-
clockwise" or "turn left", too. Granted, they'd probably use radians
instead of degrees. So, "+" meaning "turn right" is not as universal
as you might think.

--
Ludovic Brenta.