Re: About conversions

Re: About conversions

[Christoph Grein]

-14 mod 5:

 There's a common rule: ("Punkt vor Strich" in German) multiplication (* / mod 
rem) before addition (+ -), thus this is
 
      -14 mod 5 = -2**2

You wouldn't fall into the latter trap, would you?

(Hope I'm correct, did not look it up in ARM :-)

What's

  -14 mod (-5)
  -14 rem (-5)

I don't know for sure without looking it up.

Re: About conversions

[Wilhelm Spickermann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 865 bytes --]


On 23-Nov-00 Christoph Grein wrote:
> -14 mod 5:
> 
>  There's a common rule: ("Punkt vor Strich" in German) multiplication
> (* / mod 
> rem) before addition (+ -), thus this is
>  
>       -14 mod 5 = -2**2
> 
> You wouldn't fall into the latter trap, would you?
> 
> (Hope I'm correct, did not look it up in ARM :-)

Sorry, but "mod x" always delivers values between 0 and x (x excluded).
So the result is 1 and not -4.

I do like this rule of operation, because adding or subtracting a
multiple of the right operand to the left one will not change the
result of the operation. It would be nice to have a corresponding
division, such that A = (A / B) * B + A mod B. But the Ada definition of
integer division is different -- I don�t know why -- and so we need
"rem" instead of "mod" to make the above equation (and the one You have
given) true.

Wilhelm

Re: About conversions

[Florian Weimer]

Wilhelm.Spickermann@t-online.de (Wilhelm Spickermann) writes:

> On 23-Nov-00 Christoph Grein wrote:

> >  There's a common rule: ("Punkt vor Strich" in German) multiplication
> > (* / mod 
> > rem) before addition (+ -), thus this is
> >  
> >       -14 mod 5 = -2**2
> > 
> > You wouldn't fall into the latter trap, would you?
> > 
> > (Hope I'm correct, did not look it up in ARM :-)
> 
> Sorry, but "mod x" always delivers values between 0 and x (x excluded).
> So the result is 1 and not -4.

-14 mod 5 is an unary_adding_operator followed by a term, consisting
of an integer literal, a multiplying_operator and an integer literal.
So Christoph is right. ;-)

Re: About conversions

[Wilhelm Spickermann]

On 23-Nov-00 Florian Weimer wrote:
...
> So Christoph is right. ;-)
...
I see -- I should have read his mail... :-(

Wilhelm

Re: About conversions

[Robert Dewar]

In article <E13yu3q-0006pN-00@pc1.spick.nowhdus>,
  comp.lang.ada@ada.eu.org wrote:
> But the Ada definition of
> integer division is different -- I don't know why -- and so we
> need "rem" instead of "mod" to make the above equation

Easy to say why, this is the way virtually all hardware
implements signed division!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: About conversions

[Christoph Grein]

About -14 mod 5:

> Sorry, but "mod x" always delivers values between 0 and x (x excluded).
> So the result is 1 and not -4.

As always 0 - X = X = 0 + X:

0 - 14 mod 5 = -14 mod 5 = -(14 mod 5) /= (-14) mod 5 = 0 + (-14) mod 5

Re: About conversions

[Robert Dewar]

In article <200011240739.IAA22865@bulgaria.otn.eurocopter.de>,
  comp.lang.ada@ada.eu.org wrote:
> About -14 mod 5:
>
> > Sorry, but "mod x" always delivers values between 0 and x (x
excluded).
> > So the result is 1 and not -4.
>
> As always 0 - X = X = 0 + X:
>
> 0 - 14 mod 5 = -14 mod 5 = -(14 mod 5) /= (-14) mod 5 = 0 +
(-14) mod 5
>

Well you can always trust some Ada expert to get egg on their
face with this one (I certainly did the first time I saw it)

-14 mod 5 = -(14 mod 5) = -4

Yes, that's the way precedences work in Ada :-)

chuckle chuckle

Robert

P.S. I asked nearly every Ada expert this question, and all
got it wrong, except for Robert Eachus :-)

The reason that it is tricky is that it misdirects in a nasty
way. You know of course that there must be a trick, otherwise
why ask the question, but you are too clever, and think the
trick has to do with the way mod works on negative numbers :-)

Needless to say, it is terrible Ada style to depend on this
peculiar precedence rule for minus :-)



Sent via Deja.com http://www.deja.com/
Before you buy.

About conversions

[Sandro Binetti]

Hi everybody.

Can you help me understand the meaning of a type conversion, like:
  INTEGER(v)  ?

Take an example like the following.

-------------------------

procedure PROVA is
  type TYP is range 1..10;
  c:typ;

  procedure P(a,b:in integer;result:out integer) is
  begin
    result:=a+b;
  end p;

begin -- PROVA
  p(10,20,INTEGER(c)); -- <<<<
end prova;

----------------------------------------


The compiler doesn't say anything at the point <<<<

Why?

--
Ciao, Sandro


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: About conversions

[Ken Garlington]

"Sandro Binetti" <sandrobinetti@my-deja.com> wrote in message
news:8vb0h9$1ou$1@nnrp1.deja.com...
: Hi everybody.
:
: Can you help me understand the meaning of a type conversion, like:
:   INTEGER(v)  ?
:
: Take an example like the following.
:
: -------------------------
:
: procedure PROVA is
:   type TYP is range 1..10;
:   c:typ;
:
:   procedure P(a,b:in integer;result:out integer) is
:   begin
:     result:=a+b;
:   end p;
:
: begin -- PROVA
:   p(10,20,INTEGER(c)); -- <<<<
: end prova;
:
: ----------------------------------------
:
:
: The compiler doesn't say anything at the point <<<<
:
: Why?

Here's an example that might help: Suppose I need to define a type that
represents temperature, from roughly the freezing point of water to its
boiling point. If I define something like

  type Temperature is new Float range 0.0 .. 100.0;

I might be right, or I might be wrong, depending upon what units I had in
mind. However, if I define something like

  type Celsius is new Float range 0.0 .. 100.0;
  type Fahrenheit is new Float range 32.0 .. 212.0;

then the units are clear. By defining these as separate types, I can catch
certain kinds of errors, such as attempting to display a Celsius value
assuming it was Fahrenheit:

  Thermometer : Celsius;
  ...
  procedure Display_Temperature ( Value : in Fahrenheit );
  ...
  Display_Temperature (Thermometer); -- error!

Your compiler will object to this attempt. To fix it, you might discover
that Thermometer should really be Fahrenheit, or that Display_Temperature
should really display Celsius values. However, what happens if
Thermometer is really a Celsius thermometer, and the display should show
values in Fahrenheit?

This can be fixed, of course: I could create a function, such as

  function To_Fahrenheit (Temperature : Celsius) return Fahrenheit is
  begin
    return (9.0/5.0)*Temperature-32.0; -- error!
  end To_Fahrenheit;

and use it to convert the Thermometer to the right scale. Unfortunately, the
compiler will complain here, as well. It will assume that you are
inadvertantly returning a Celsius value as a Fahrenheit value. To make it
clear that the calculation actually causes the value to be of a different
type, you have to do an explicit type conversion, as follows:

  function To_Fahrenheit (Temperature : Celsius) return Fahrenheit is
  begin
    return Fahrenheit((9.0/5.0)*Temperature-32.0);  -- OK
  end To_Fahrenheit;

As you noticed, the compiler does not complain when you use an explicit type
conversion to make a value the expected type. In your example, you have a
procedure P that expects values of type Integer, you convert your Typ value
to an Integer value before calling P, so everything is consistent.

There are common-sense limits to type conversions, of course. See the Ada
Reference Manual section 4.6 for details.

http://www.adahome.com/LRM/95/rm95html/rm9x-04-06.html

package Temperature is

  type Celsius is new Float range 0.0 .. 100.0;
  type Fahrenheit is new Float range 32.0 .. 212.0;

  function To_Celsius (Temperature : Fahrenheit) return Celsius;
  function To_Fahrenheit (Temperature : Celsius) return Fahrenheit;

end Temperature;

package body Temperature is

  function To_Celsius (Temperature : Fahrenheit) return Celsius is
  begin
    return Celsius((5.0/9.0)*(Temperature-32.0));
  end To_Celsius;

  function To_Fahrenheit (Temperature : Celsius) return Fahrenheit is
  begin
    return Fahrenheit((9.0/5.0)*Temperature-32.0);
  end To_Fahrenheit;

end Temperature;

Re: About conversions

[Robert Dewar]

In article <RaaS5.5488$6W1.468063@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:


<<much general and probably irrelevant material on type
conversions removed>>

> In your example, you have a
> procedure P that expects values of type Integer, you convert
> your Typ value
> to an Integer value before calling P, so everything is
> consistent.

No, that's quite wrong. Ken misread the example.
This is indeed the "weird" case where
a type conversion is used on an OUT parameter. Even someone who
understands all the stuff about type conversions in general
can be puzzled at this peculiar use.

The deal here is that the conversion happens AFTER the call
in the OPPOSITE direction from what it looks like. So if the
call says

  p (10,20,integer(c));

the actual effect is that the function computes something of
type Integer and puts it in the output parameter. This value is
then converted FROM integer TO type "typ" and stored in C.

How's that for strange? The conversion is exactly "backwards".
In the case of an IN OUT parameter, you get two conversions, one
the way that it looks (and to which Ken was referring
incorrectly above, not having noticed the OUT keyword), and one
the peculiar opposite direction.

Why is this feature in the language?

It's really there to provide an easy explanation for what
happens in the case of derived types. I think it's actually
misguided, because although it makes the explanation of derived
types easier, it introduces a bogus misleading feature into the
language that is of very little practical use and which causes a
lot of confusion, even among people who know Ada well!

Robert Dewar


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: About conversions

[Stephen Leake]

Robert Dewar <robert_dewar@my-deja.com> writes:

> <snip explanation of type conversion on OUT parameter>
> 
> It's really there to provide an easy explanation for what
> happens in the case of derived types. I think it's actually
> misguided, because although it makes the explanation of derived
> types easier, it introduces a bogus misleading feature into the
> language that is of very little practical use and which causes a
> lot of confusion, even among people who know Ada well!

I think that's a bit strong. I've had occasion to use type conversion
on out parameters, without using derived types (no examples readily at
hand, or at least they are hard to find). I should think needing to
convert an out parameter would happen about as often as needing to
convert an in parameter, or a function result. The syntax may seem a
little backwards, but if you think of it as "convert this object as
needed to match the subprogram specification" it makes more sense.

On the other hand, I'm one of "the people who know Ada well", so maybe
I've just gotten my brain bent properly :).

-- 
-- Stephe

Re: About conversions

[Robert Dewar]

In article <u8zqe5klh.fsf@gsfc.nasa.gov>,
  Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
> convert an out parameter would happen about as often as
> needing to convert an in parameter, or a function result.

Not at all! Because you think of an out parameter as an Lvalue,
and conversions are not allowed as left sides in assignments.
If you really believe the above, you would want backwards
conversions on the left of assigments.

Note that all other comparable languages allow conversions for
input parameters, NONE of them allows these strange out
conversions.

Good advice is to avoid this feature almost always.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: About conversions

[Warren W. Gay VE3WWG]

Robert Dewar wrote:

> In article <u8zqe5klh.fsf@gsfc.nasa.gov>,
>   Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:
> > Robert Dewar <robert_dewar@my-deja.com> writes:
> > convert an out parameter would happen about as often as
> > needing to convert an in parameter, or a function result.
>
> Not at all! Because you think of an out parameter as an Lvalue,
> and conversions are not allowed as left sides in assignments.
> If you really believe the above, you would want backwards
> conversions on the left of assigments.
>
> Note that all other comparable languages allow conversions for
> input parameters, NONE of them allows these strange out
> conversions.
>
> Good advice is to avoid this feature almost always.

To avoid it requires declaring another "receiving variable" of the
correct type, and then converting it with a subsequent assignment.
This is not only inconvenient, but would create an extra source
of "duplicated variables", which complicates what would otherwise
be a simpler piece of code.

Consequently, I like the feature ;-)

>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: About conversions

[Robert Dewar]

In article <3A1AB12E.8780B626@home.com>,
  "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote:
> This is not only inconvenient

convenience of the writer is simply not a factor that should
ever be taken significantly into consideration.

> Consequently, I like the feature ;-)

If you use this feature, you will most definitely confuse
the reader, especially in the case of an out parameter,
precisely because the syntax is so confusing. Note that
the original questioner here was justifiably confused,
and in my experience, this is a construct that confuses
a good number of people.

A careful programmer avoids constructs that confuse lots of
people, even if they understand the construct perfectly
themselves.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: About conversions

[Ted Dennison]

In article <8vept5$814$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
(talking about converting actual "out" parameters)
> If you use this feature, you will most definitely confuse
> the reader, especially in the case of an out parameter,
> precisely because the syntax is so confusing. Note that

To the reader, it doesn't look any different than the conversion of an
"in" parameter. They have to go to the subprogram declaration to even
see what the mode is. Prohibiting conversions for "out" but allowing it
for "in" would just be an extra (also confusing) rule for developers to
remember about when its allowed and when it isn't. Plus it would cause
the extra source code previously mentioned to create the new temp
variable. Tracking that down and making sure its handled right before
and after the call is just going to be more extra work for maintainers.

You do have a point about it being confusing to some beginners. I'd
imagine its particularly bad for those who are comming from another
language that doesn't allow this kind of thing. But I don't think you
can say that its an inarguable maintanence problem. It can be argued
either way.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: About conversions

[Warren W. Gay VE3WWG]

Ted Dennison wrote:

> In article <8vept5$814$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> (talking about converting actual "out" parameters)
> > If you use this feature, you will most definitely confuse
> > the reader, especially in the case of an out parameter,
> > precisely because the syntax is so confusing. Note that
>
> ...snip...
> You do have a point about it being confusing to some beginners. I'd
> imagine its particularly bad for those who are comming from another
> language that doesn't allow this kind of thing. But I don't think you
> can say that its an inarguable maintanence problem. It can be argued
> either way.

I agree. In fact, there are a great many things that will be confusing to
beginners ;-)  Are we really concerned about confused beginners?

> --
> T.E.D.
>
> http://www.telepath.com/~dennison/Ted/TED.html
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: About conversions

[Robert Dewar]

In article <8vetq2$bkb$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> You do have a point about it being confusing to some
> beginners.

nope, I am just observing two things

a) this construct is very rarely used for out parameters,
a quick scan of a bunch of our test code showed up no uses
at all in a huge chunk of code, which contained hundreds
of conversions for in parameters.

b) in practice it is confusing for a lot of programmers,
again, that's just based on empirical evidence. This is not
the first time that this point has been discussed (is anything
new and interesting *ever* discussed on CLA at this stage :-)
and I have seen several people who know Ada quite well get
confused.

(see P.S.)

Why is it confusing? Simple, most people think of conversions
as basically function calls, and it is peculiar to have a
function call as an Lvalue. (peculiar in Ada as well, and indeed
notice we do not allow conversions on the left side -- Ted's
argument of symmetricality between in and out parameters applies
just as well to left and right sides of assignments).

P.S. Most people contributing to CLA know Ada far too well :-)
I have even seen people who say that it is easy for anyone
to know the value of the expression

-14 mod 5

and claim the same sort of thing for people who don't know it
(beginners etc ...)

(and before some of you get caught out by this -- here is a
little hint, if you feel like looking up the table in the RM,
gyou have already failed the test :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: About conversions

[Ted Dennison]

In article <8vfjhn$t4e$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <8vetq2$bkb$1@nnrp1.deja.com>,
> Why is it confusing? Simple, most people think of conversions
> as basically function calls, and it is peculiar to have a
> function call as an Lvalue. (peculiar in Ada as well, and indeed

I prefer to think of them as a kind of in-line compiler directive, in
effect saying "think of this object as really being of this type". I
generally tell this to others as well, since thinking of it as a
function call leads people to the erronious conclusion that the
conversion is liable to have some kind of subprogram-like overhead.

From this point of view, *not* allowing it for "out" parameters would be
confusing. (And yes, to this way of thinking it is a bit odd that you
can't use it on the left side of an assignment).

> -14 mod 5

Not a chance. I don't think I've ever needed to use "mod" for negative
numbers, so I would definitely have to look it up. That's just a matter
of use though. If I had to do it all the time, I'm sure I'd know it just
as well as a heavy C coder knows how to properly use the "?" operator.

Pretty much the only time I ever use "mod" is to index into circular
data structures. Occasionly I'll use it to effect a bit mask on an
unsigned value. There's probably a use for applying it to signed values,
but I haven't encountered it in 11 years.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: About conversions

[Wes Groleau]

> Why is it confusing? Simple, most people think of conversions
> as basically function calls, and it is peculiar to have a
> function call as an Lvalue. (peculiar in Ada as well, and indeed
> notice we do not allow conversions on the left side -- Ted's

Although I remember an Ada 83 compiler that did allow it....


-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: About conversions

[Tristan Gingold]

In article <8ve71q$meh$1@nnrp1.deja.com>, Robert Dewar wrote:
>In article <u8zqe5klh.fsf@gsfc.nasa.gov>,
>  Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:
>> Robert Dewar <robert_dewar@my-deja.com> writes:
>> convert an out parameter would happen about as often as
>> needing to convert an in parameter, or a function result.
>
>Not at all! Because you think of an out parameter as an Lvalue,
>and conversions are not allowed as left sides in assignments.
>If you really believe the above, you would want backwards
>conversions on the left of assigments.
>
>Note that all other comparable languages allow conversions for
>input parameters, NONE of them allows these strange out
>conversions.
VHDL (at least vhdl93) has an (awful) mechanism to do conversions for
input and/or output parameters.

Tristan.

Re: About conversions

[Jean-Pierre Rosen]

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


"Robert Dewar" <robert_dewar@my-deja.com> a �crit dans le message news: 8ve71q$meh$1@nnrp1.deja.com...
> In article <u8zqe5klh.fsf@gsfc.nasa.gov>,
>   Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:
> > Robert Dewar <robert_dewar@my-deja.com> writes:
> > convert an out parameter would happen about as often as
> > needing to convert an in parameter, or a function result.
>
> Not at all! Because you think of an out parameter as an Lvalue,
> and conversions are not allowed as left sides in assignments.
> If you really believe the above, you would want backwards
> conversions on the left of assigments.
>
Note that for tagged types, conversions ARE allowed as Lvalue
(another not-well-know-feature!)

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

Re: About conversions

[Jean-Pierre Rosen]

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


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> a �crit dans le message news: u8zqe5klh.fsf@gsfc.nasa.gov...
> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> > <snip explanation of type conversion on OUT parameter>
> >
> > It's really there to provide an easy explanation for what
> > happens in the case of derived types. I think it's actually
> > misguided, because although it makes the explanation of derived
> > types easier, it introduces a bogus misleading feature into the
> > language that is of very little practical use and which causes a
> > lot of confusion, even among people who know Ada well!
>
> I think that's a bit strong. I've had occasion to use type conversion
> on out parameters, without using derived types (no examples readily at
> hand, or at least they are hard to find). I should think needing to
> convert an out parameter would happen about as often as needing to
> convert an in parameter, or a function result. The syntax may seem a
> little backwards, but if you think of it as "convert this object as
> needed to match the subprogram specification" it makes more sense.
>
Typical example is if you define:
type My_String is array (My_integer_type range <>) of character;

It is nice to be able to use Get_Line...

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

Re: About conversions

[DuckE]

> It's really there to provide an easy explanation for what
> happens in the case of derived types. I think it's actually
> misguided, because although it makes the explanation of derived
> types easier, it introduces a bogus misleading feature into the
> language that is of very little practical use and which causes a
> lot of confusion, even among people who know Ada well!
>
> Robert Dewar
>

I've always thought of type conversions as equivalent to built in functions
for converting types.  Looks like I'll have to change my way of thinking.

Thanks,

SteveD

Re: About conversions

[Robert Dewar]

In article <kwlS5.54873$U46.1727359@news1.sttls1.wa.home.com>,
  "DuckE" <nospam_steved94@home.com> wrote:
> I've always thought of type conversions as equivalent to built
> in functions for converting types.  Looks like I'll have to
> change my way of thinking.


Conceptually, that *should* be a good model of type conversions.
It is true that this bizarre case disturbs this model, but in
fact nearly all programmers think of A(B) when they see it as
a functional form that converts B to the type A (after all why
did we choose the same syntax as a function for this purpose).

I am not sure the anomolous case is a good reason to change your
way of thinking here. Output conversions are very rare (much
much rarer than input conversions, depite the claim of the
previous message).


Sent via Deja.com http://www.deja.com/
Before you buy.