Re: Dispatching and generics - language lawyer question

Re: Dispatching and generics - language lawyer question

[Grein, Christoph]

> There is a problem with "reemergence" of predefined operators ...

For untagged types, _redefined_ equality does not correctly compose and 
_predefined_ equality reemerges in generics if not properly transferred by a 
formal parameter:

  type X is something;
  function "=" (L, R: X) return Boolean;  -- redefine

  type Y is record
    C: X;
  end record;

  A, B: Y;
  L: Boolean := A = B;  -- here predefined "=" on component C is used, not the
                        -- equality redefined above

  generic
    type T is private;
    --with function "=" (L, R: T) return Boolean is <>;
  package P is ...

  package P_on_X is new P (X);  -- here also predefined "=" on X is used,
                                -- not the equality redefined above

You have to uncomment the generic parameter function to prevent reemergence.

This whole astonishing rule has been introduced because of compatibility with 
Ada 83 (note there were no tagged types in Ada 83 so there reemergence could 
safely be avoided).

In Ada 83, it was not possible to redefine "=" without using a trick (I do not 
remember the exact way to do it, I never did this; you have to use generics with 
the a limited private formal type). When you used this trick to redefine 
equality, also the predefined equality reemerged as in the cases above. Thus for 
compatibility, we have this rule in Ada 95.

Re: Dispatching and generics - language lawyer question

[Robert A Duff]

"Grein, Christoph" <christoph.grein@eurocopter.com> writes:

> For untagged types, _redefined_ equality does not correctly compose and 
> _predefined_ equality reemerges in generics if not properly transferred by a 
> formal parameter:

What do you think the rule *should* be?  It does seem bad that
predefined "=" reemerges.  And of course the rule for "/=" should be the
same as for "=".

What about "<"?  Should the predefined one reemerge?  If a generic
sorting package calls the primitive "<" of the generic formal type,
it would seem desirable to use the user-defined one, rather than the
predefined one.

But what about "+" and "mod" and so forth?  Package Text_IO.Integer_IO
probably uses the predefined "mod" to format the number as a string.
But the *spec* of that package doesn't say that -- it just says the
string is formatted according to some rules.  If the predefined "mod"
did *not* reemerge, then a user-defined "mod" operator would break
Text_IO.Integer_IO.  You may say, "tough luck; that's the programmer's
fault".  But how should the semantics of Integer_IO be defined in the
RM?  Surely the use of "mod" there is an implementation detail.

- Bob

Re: Dispatching and generics - language lawyer question

[Ben Brosgol]

> > For untagged types, _redefined_ equality does not correctly compose and
> > _predefined_ equality reemerges in generics if not properly transferred
by a
> > formal parameter:
>
> But what about "+" and "mod" and so forth?  Package Text_IO.Integer_IO
> probably uses the predefined "mod" to format the number as a string.
> But the *spec* of that package doesn't say that -- it just says the
> string is formatted according to some rules.  If the predefined "mod"
> did *not* reemerge, then a user-defined "mod" operator would break
> Text_IO.Integer_IO.  You may say, "tough luck; that's the programmer's
> fault".  But how should the semantics of Integer_IO be defined in the
> RM?  Surely the use of "mod" there is an implementation detail.

As another interesting case, suppose that you declare an integer type T with
"mod" specified as abstract.  If "mod" on the formal type is invoked from
the generic body, then either the instantiation Ada.Text_IO.Integer_IO(T)
would need to be rejected (a rather flagrant violation of the "contract
model") or else the predefined "mod" would need to reemerge.

Re: Dispatching and generics - language lawyer question

[Robert A Duff]

Hi, Ben.

"Ben Brosgol" <brosgol@world.std.com> writes:

> As another interesting case, suppose that you declare an integer type T with
> "mod" specified as abstract.  If "mod" on the formal type is invoked from
> the generic body, then either the instantiation Ada.Text_IO.Integer_IO(T)
> would need to be rejected (a rather flagrant violation of the "contract
> model") or else the predefined "mod" would need to reemerge.

Yes, that *is* an interesting case, which I hadn't thought of.

Note that for tagged types, the generic declares whether it wants to
accept types with abstract primitive ops, so the instantiation can be
rejected without violating the contract model.  It's uncomfortable that
there are misc. rules like this that distinguish tagged types from
untagged types.  Could we do better if designing the language from
scratch?  (I think many such rules are needed for compatibility with Ada
83.)  I'm not sure what the right answer is in this case.

I'm disappointed that nobody answered my previous question -- what
should the rules about predefined operators in generics be?  I don't
like the current Ada rules (which require reemergence of the "wrong"
operator), but the alternatives are uncomfortable in various ways.
Christoph Grein, or anybody else want to comment?

Here's an interesting case: a generic Sort routine, that takes "<" as a
parameter.  (Or it could be called "Less_Than" -- it doesn't matter what
it's called, or whether it's an operator symbol.)  The Sort routine
might require that the "<" behave in certain ways (like if A<B and B<C
both return True, then A<C should always return True).  Is there any way
to specify that (other than via comments)?  Is there some way to design
the language so that the generic Sort could formally require such
properties of "<"?

This is similar to the Text_IO.Integer_IO example, where the code wants
to assume that "mod" behaves according to some mathematical rules.
(I'm not even sure how to state those rules precisely.)

- Bob

Re: Dispatching and generics - language lawyer question

[Dmitry A.Kazakov]

Robert A Duff wrote:

> "Ben Brosgol" <brosgol@world.std.com> writes:
> 
>> As another interesting case, suppose that you declare an integer type T
>> with
>> "mod" specified as abstract.  If "mod" on the formal type is invoked from
>> the generic body, then either the instantiation Ada.Text_IO.Integer_IO(T)
>> would need to be rejected (a rather flagrant violation of the "contract
>> model") or else the predefined "mod" would need to reemerge.
> 
> Yes, that *is* an interesting case, which I hadn't thought of.
> 
> Note that for tagged types, the generic declares whether it wants to
> accept types with abstract primitive ops, so the instantiation can be
> rejected without violating the contract model.  It's uncomfortable that
> there are misc. rules like this that distinguish tagged types from
> untagged types.  Could we do better if designing the language from
> scratch?  (I think many such rules are needed for compatibility with Ada
> 83.)  I'm not sure what the right answer is in this case.

[away from Ada 95] There should be only tagged types and no untagged ones. 
Then I suppose the formal derived types will do the whole work, because the 
set of all available operations will be defined by the root type. All types 
tagged means only that T'Class exists for all but class-wide types. The tag 
should be kept in the instances of T'Class and class-wide pointers, but not 
in the values of T, so no performance hit when objects are specific.

> I'm disappointed that nobody answered my previous question -- what
> should the rules about predefined operators in generics be?  I don't
> like the current Ada rules (which require reemergence of the "wrong"
> operator), but the alternatives are uncomfortable in various ways.
> Christoph Grein, or anybody else want to comment?
> 
> Here's an interesting case: a generic Sort routine, that takes "<" as a
> parameter.  (Or it could be called "Less_Than" -- it doesn't matter what
> it's called, or whether it's an operator symbol.)  The Sort routine
> might require that the "<" behave in certain ways (like if A<B and B<C
> both return True, then A<C should always return True).  Is there any way
> to specify that (other than via comments)?  Is there some way to design
> the language so that the generic Sort could formally require such
> properties of "<"?

[far away form Ada 95] You should simply have different root types. 
Transitive_Ordered should be a[!] root type for "all" types with transitive 
"<". "All" means the types you want to pass the actual parameter. Of course 
then the language should allow creating supertypes on-fly, because one 
cannot foresee all possible root types like Ada tries with its 
classification of formal types. Let Integer is not a descendant of 
Transitive_Ordered. Then one could create a "proxy" type which is 
simultaneously a supertype of Integer and a subtype of Transitive_Ordered. 
[The compiler should check that "<" be implemented.] So Integer would 
become a subtype Transitive_Ordered in the given context and thus could be 
used as an actual parameter of the generic. This of course would require MI 
and dynamically maintained dispatch tables.

> This is similar to the Text_IO.Integer_IO example, where the code wants
> to assume that "mod" behaves according to some mathematical rules.
> (I'm not even sure how to state those rules precisely.)

Well, this is about LSP. No one can enforce semantics of an operation. 
However, the difference between what we have in Ada now and what I would 
like to have, is that presently operations of a private formal type are 
matched by their profiles. This warranties absolutely nothing. With generic 
derived types, you would have a subtype relation which assumes a 
meaningfull implementation of the root type operations.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Dispatching and generics - language lawyer question

[Robert A Duff]

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:

> [away from Ada 95] There should be only tagged types and no untagged ones. 
> Then I suppose the formal derived types will do the whole work, because the 
> set of all available operations will be defined by the root type. All types 
> tagged means only that T'Class exists for all but class-wide types. The tag 
> should be kept in the instances of T'Class and class-wide pointers, but not 
> in the values of T, so no performance hit when objects are specific.

This is a reasonable idea (not new -- I and probably others have thought
of it before).

As you imply, there are two ways to implement tags: (1) Store the tag
with each object.  Then an access value (or a pass-by-reference
parameter) can be represented as the address of the object.  Or (2),
do not store the tag with each object, but gin it up when necessary.
This requires access values and parameters to be a pair -- the tag, plus
the address of the object.  When you do X'Access, the compiler creates
the pair.

Neither method is uniformly better: there are some programs that will be
more efficient with method (1), and some more efficient with method (2).
This indicates that the user should have the option.  I would suggest
the default (in this hypothetical language) should be (2), and a
per-type pragma could request (1) for that type and its descendants.
This preserves the Bauer Principle -- if you never say 'Class, you never
have any overhead for storing or manipulating tags at run time.

Of course, having options like that complicates compilers.

For most of the Ada 9X design, either (1) or (2) were feasible (for
tagged types).  However, a last-minute change to the language made (2)
infeasible.  Namely, the fact that all tagged parameters are aliased.

As far as I know, all existing compilers use (1).

Note that the distinction between (1) and (2) is analogous to the
compiler storing array bounds with the array, or with pointers to the
array.  Neither one is uniformly better.  I believe GNAT allows a user
choice, and I think all other compilers store bounds with the array
(analogous to (1)).

> > I'm disappointed that nobody answered my previous question -- what
> > should the rules about predefined operators in generics be?  I don't
> > like the current Ada rules (which require reemergence of the "wrong"
> > operator), but the alternatives are uncomfortable in various ways.
> > Christoph Grein, or anybody else want to comment?
> > 
> > Here's an interesting case: a generic Sort routine, that takes "<" as a
> > parameter.  (Or it could be called "Less_Than" -- it doesn't matter what
> > it's called, or whether it's an operator symbol.)  The Sort routine
> > might require that the "<" behave in certain ways (like if A<B and B<C
> > both return True, then A<C should always return True).  Is there any way
> > to specify that (other than via comments)?  Is there some way to design
> > the language so that the generic Sort could formally require such
> > properties of "<"?
> 
> [far away form Ada 95] You should simply have different root types. 
> Transitive_Ordered should be a[!] root type for "all" types with transitive 
> "<". "All" means the types you want to pass the actual parameter. Of course 
> then the language should allow creating supertypes on-fly, because one 
> cannot foresee all possible root types like Ada tries with its 
> classification of formal types. Let Integer is not a descendant of 
> Transitive_Ordered. Then one could create a "proxy" type which is 
> simultaneously a supertype of Integer and a subtype of Transitive_Ordered. 
> [The compiler should check that "<" be implemented.] So Integer would 
> become a subtype Transitive_Ordered in the given context and thus could be 
> used as an actual parameter of the generic. This of course would require MI 
> and dynamically maintained dispatch tables.

Again, good ideas.  But they don't solve the problem I was thinking of.

By the way, I don't see why you need dynamically maintained dispatch
tables.  To me, "on the fly" means "somewhere later in the code" --
i.e. in some module other than where the type is first declared.
That need not imply "at run time", I think.

The notion of dynamically maintained dispatch tables scares me: I hope
that "<" on type T does not dispatch to different subprogram bodies
at different times (for the same type tag)!

It seems like adding new operations to a type should only be allowed at
the same nesting level as the original type declaration.  I shudder to
think of the run-time overhead of adding an operation in a recursive
procedure.  ("Adding new op" is essentially the same thing as "adding a
new parent type", here.)

But anyway, as you explain below, none of this solves the problem.  The
compiler checks that "<" exists with the right parameter types, but that
doesn't *prove* its transitive (whether or not the Transitive_Ordered
idea is used).

> > This is similar to the Text_IO.Integer_IO example, where the code wants
> > to assume that "mod" behaves according to some mathematical rules.
> > (I'm not even sure how to state those rules precisely.)
> 
> Well, this is about LSP. No one can enforce semantics of an operation. 

Exactly my point.  For *this* issue, all of the above good ideas are
equivalent to simply changing the language so that predefined operators
do not reemerge.

> However, the difference between what we have in Ada now and what I would 
> like to have, is that presently operations of a private formal type are 
> matched by their profiles. This warranties absolutely nothing.

Right, it warranties nothing.

>... With generic 
> derived types, you would have a subtype relation which assumes a 
> meaningfull implementation of the root type operations.

But this also warranties nothing.  One must "assume" that operations do
what they're supposed to do; the compiler can't prove it.  That's no
different from the current case, where "mod" could be redefined to do
something weird, thus breaking Text_IO.Integer_IO (I mean, if we changed
the rules to avoid the reemergence).

You still haven't answered my question: What should the RM say that
Integer_IO.Put does?  (Or if it were user-defined, what should the
comment on its spec say?)  I don't care whether the language removes
reemergence, or all your nice ideas above, including about formal
derived types, are adopted -- either way, it's difficult to define the
semantics of Put if it might be calling some user-defined version of
"mod".

The current RM doesn't even mention that Put calls "mod".  In fact,
there are various ways of implementing Put, some of which call "mod" and
some of which don't.  Surely, Put calling "mod" is an implementation
detail?

- Bob

Re: Dispatching and generics - language lawyer question

[Dmitry A.Kazakov]

Robert A Duff wrote:

> Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>> [away from Ada 95] There should be only tagged types and no untagged
>> [ones.
>> Then I suppose the formal derived types will do the whole work, because
>> the set of all available operations will be defined by the root type. All
>> types tagged means only that T'Class exists for all but class-wide types.
>> The tag should be kept in the instances of T'Class and class-wide
>> pointers, but not in the values of T, so no performance hit when objects
>> are specific.
> 
> This is a reasonable idea (not new -- I and probably others have thought
> of it before).
> 
> As you imply, there are two ways to implement tags: (1) Store the tag
> with each object.  Then an access value (or a pass-by-reference
> parameter) can be represented as the address of the object.  Or (2),
> do not store the tag with each object, but gin it up when necessary.
> This requires access values and parameters to be a pair -- the tag, plus
> the address of the object.  When you do X'Access, the compiler creates
> the pair.
> 
> Neither method is uniformly better: there are some programs that will be
> more efficient with method (1), and some more efficient with method (2).
> This indicates that the user should have the option.  I would suggest
> the default (in this hypothetical language) should be (2), and a
> per-type pragma could request (1) for that type and its descendants.
> This preserves the Bauer Principle -- if you never say 'Class, you never
> have any overhead for storing or manipulating tags at run time.
> 
> Of course, having options like that complicates compilers.

I think that (1) would cause many problems with MI. When tag is a part of 
the value and then view conversions are problematic.

> For most of the Ada 9X design, either (1) or (2) were feasible (for
> tagged types).  However, a last-minute change to the language made (2)
> infeasible.  Namely, the fact that all tagged parameters are aliased.

There is also redispatch which is IMO incompatible with (1). I think 
redispatch must be removed, because when object identification is really 
necessary (to redispatch) one could use a solution similar to J.-P. Rosen 
trick.

> As far as I know, all existing compilers use (1).
> 
> Note that the distinction between (1) and (2) is analogous to the
> compiler storing array bounds with the array, or with pointers to the
> array.  Neither one is uniformly better.  I believe GNAT allows a user
> choice, and I think all other compilers store bounds with the array
> (analogous to (1)).

Yes. Same with discriminants. I have only a vague idea, that there should 
be way to separate all things like that from values. The goal is of course 
to make arrays, strings etc user-defined types without additional overhead. 
Then of course you should be able to derive from an abstract array and 
provide an implementation which is internally not an array at all. So the 
client will never know.

>> > I'm disappointed that nobody answered my previous question -- what
>> > should the rules about predefined operators in generics be?  I don't
>> > like the current Ada rules (which require reemergence of the "wrong"
>> > operator), but the alternatives are uncomfortable in various ways.
>> > Christoph Grein, or anybody else want to comment?
>> > 
>> > Here's an interesting case: a generic Sort routine, that takes "<" as a
>> > parameter.  (Or it could be called "Less_Than" -- it doesn't matter
>> > what
>> > it's called, or whether it's an operator symbol.)  The Sort routine
>> > might require that the "<" behave in certain ways (like if A<B and B<C
>> > both return True, then A<C should always return True).  Is there any
>> > way
>> > to specify that (other than via comments)?  Is there some way to design
>> > the language so that the generic Sort could formally require such
>> > properties of "<"?
>> 
>> [far away form Ada 95] You should simply have different root types.
>> Transitive_Ordered should be a[!] root type for "all" types with
>> transitive "<". "All" means the types you want to pass the actual
>> parameter. Of course then the language should allow creating supertypes
>> on-fly, because one cannot foresee all possible root types like Ada tries
>> with its classification of formal types. Let Integer is not a descendant
>> of Transitive_Ordered. Then one could create a "proxy" type which is
>> simultaneously a supertype of Integer and a subtype of
>> Transitive_Ordered.
>> [The compiler should check that "<" be implemented.] So Integer would
>> become a subtype Transitive_Ordered in the given context and thus could
>> be used as an actual parameter of the generic. This of course would
>> require MI and dynamically maintained dispatch tables.
> 
> Again, good ideas.  But they don't solve the problem I was thinking of.
> 
> By the way, I don't see why you need dynamically maintained dispatch
> tables.  To me, "on the fly" means "somewhere later in the code" --
> i.e. in some module other than where the type is first declared.
> That need not imply "at run time", I think.
> 
> The notion of dynamically maintained dispatch tables scares me: I hope
> that "<" on type T does not dispatch to different subprogram bodies
> at different times (for the same type tag)!
>
> It seems like adding new operations to a type should only be allowed at
> the same nesting level as the original type declaration.  I shudder to
> think of the run-time overhead of adding an operation in a recursive
> procedure.  ("Adding new op" is essentially the same thing as "adding a
> new parent type", here.)

Yes, I also do not think that one could override in any context without a 
heavy penalty. I think if that would be allowed then no expression would be 
static when used in a subprogram. No, I meant another thing. If a derived 
type is created in some nested context and overrides, say "<", then the 
dispatching table of "<" should be modified once when the type is 
elaborated and restored when the context is finalized.

> But anyway, as you explain below, none of this solves the problem.  The
> compiler checks that "<" exists with the right parameter types, but that
> doesn't *prove* its transitive (whether or not the Transitive_Ordered
> idea is used).
> 
>> > This is similar to the Text_IO.Integer_IO example, where the code wants
>> > to assume that "mod" behaves according to some mathematical rules.
>> > (I'm not even sure how to state those rules precisely.)
>> 
>> Well, this is about LSP. No one can enforce semantics of an operation.
> 
> Exactly my point.  For *this* issue, all of the above good ideas are
> equivalent to simply changing the language so that predefined operators
> do not reemerge.

One should distinguish overloading and overriding. If ">" is overridden 
then a reemergence would clearly violate LSP. On contrary in the case of 
overloading reemergence would enforce LSP. So logically, the reemergency 
rule is OK so far the type is untagged [but there should be no such (:-))]. 
But look at this:

package Some_Type is
   type X is tagged null record;
   function "<" (A, B : X) return Boolean;
end Some_Type;

package body Some_Type is
   function "<" (A, B : X) return Boolean is
   begin
      return True;
   end "<";
end Some_Type;

with Ada.Text_IO; use Ada.Text_IO;
with Some_Type;   use Some_Type;

procedure Test is
   XX : X;

   generic procedure Compare (A : X);

   procedure Compare (A : X) is
   begin
      if A < A then
         Put_Line ("Reemerged");
      else
         Put_Line ("Overloaded");
      end if;
   end Compare;

   procedure G1 is new Compare;
   procedure N1 (A : X) is
   begin
      if A < A then
         Put_Line ("Reemerged");
      else
         Put_Line ("Overloaded");
      end if;
   end N1;

   function "<" (A, B : X) return Boolean is
   begin
      return False;
   end "<";

   procedure G2 is new Compare;
   procedure N2 (A : X) is
   begin
      if A < A then
         Put_Line ("Reemerged");
      else
         Put_Line ("Overloaded");
      end if;
   end N2;

begin
   G1 (XX); -- Reemerged
   N1 (XX); -- Reemerged
   G2 (XX); -- Reemerged
   N2 (XX); -- Overloaded
end Test;

Is THIS OK? I do not think so. The first thought is to prohibit overloading 
of primitive operations.

>> However, the difference between what we have in Ada now and what I would
>> like to have, is that presently operations of a private formal type are
>> matched by their profiles. This warranties absolutely nothing.
> 
> Right, it warranties nothing.
> 
>>... With generic
>> derived types, you would have a subtype relation which assumes a
>> meaningfull implementation of the root type operations.
> 
> But this also warranties nothing.  One must "assume" that operations do
> what they're supposed to do; the compiler can't prove it.

To some extent it could. Let we introduce, as many proposed, pre-, 
post-conditions and invariants. Then some of requirements on operations of 
Transitive_Order could be expressed in their terms. Then (do not ask me 
how) the compiler could check that a pre-condition of a derived type 
declared to be a "strong subtype" is not stronger than it was for the base 
type etc.

This will still warranty nothing, but it is much like 
Unchecked_Deallocation. How do you warranty that it is not called twice? 
One thing is when the compiler silently uses ">", just because it has a 
right name and profile. Another thing is when the compiler says: sorry guy, 
">" is abstract, please, override it, even if the overriding would be a 
simple renaming, even if some idiot would call a TRAP instruction from the 
overriding.

> That's no
> different from the current case, where "mod" could be redefined to do
> something weird, thus breaking Text_IO.Integer_IO (I mean, if we changed
> the rules to avoid the reemergence).
> 
> You still haven't answered my question: What should the RM say that
> Integer_IO.Put does?  (Or if it were user-defined, what should the
> comment on its spec say?)  I don't care whether the language removes
> reemergence, or all your nice ideas above, including about formal
> derived types, are adopted -- either way, it's difficult to define the
> semantics of Put if it might be calling some user-defined version of
> "mod".

The precondition of Integer_IO is that the generic parameter is of some 
integer type. It means that all what is said about integer types in RM 
should be true for it. RM could say that for an integer type for any x and 
any y/=0 there are d and r of the type that x=y*d+r and etc (*). There is a 
related question: how to make preconditions as weak as possible? 
Definitely, Put does not need *all* integer operations. How to express 
that? To refine further the type hierarchy like with Transitive_Order would 
be a heavy burden for a programmer, because then he/she should instantiate 
each procedure of the package separately depending on what subset of 
operations (subtype) the procedure require.

(*) You can always write in RM: "it is a bounded error if" and a draconian 
requirement follows (:-))

Also any polymorphic solution (generic or class-wide) may face 
substitutability problems because of overriding. Thus for simple things 
like Integer_IO it could be better to have a non-polymorphic one. I mean 
user-defined type conversions and subtyping through conversions. In fact we 
do it manually on daily basis when write something like:

type X is range ...;
A : X;

Put (Integer'Image (Integer (A)));

Let we have some integer type Int_Out which cannot have instances 
(variables). Then let's declare Put on it. Then if I would like to make an 
output for X, I would declare X a subtype of IO_Int by providing a 
conversion X->Int_Out. The compiler would apply the conversion should I 
write Put (X). This suffers no substitutability problems (**), because Put 
will always deal with an Int_Out.

(**) If Int_Out is capable to represent all values of the derived type.

> The current RM doesn't even mention that Put calls "mod".  In fact,
> there are various ways of implementing Put, some of which call "mod" and
> some of which don't.  Surely, Put calling "mod" is an implementation
> detail?

Yes. Yet it is consistent, because what is not an implementation detail is 
that Put *may* call "mod" expecting a meaningfull behaviour from it. 

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Dispatching and generics - language lawyer question

[Hyman Rosen]

Dmitry A.Kazakov wrote:
> I think that (1) would cause many problems with MI. When tag is a part of 
> the value and then view conversions are problematic.
> There is also redispatch which is IMO incompatible with (1). I think 
> redispatch must be removed, because when object identification is really 
> necessary (to redispatch) one could use a solution similar to J.-P. Rosen 
> trick.

C++ uses (1), storing multiple "tags" (actually, virtual
table pointers) in the object if necessary, and supports
redispatch just fine. The scheme used by the new version
of g++ is described at
<http://www.codesourcery.com/cxx-abi/abi.html>.

I doubt that the language designers, assuming they do add
MI to Ada, would be so silly as to deliberately choose to
implement it in a way that could never be compatible with
C++ object layout.

Re: Dispatching and generics - language lawyer question

[Dmitry A.Kazakov]

Hyman Rosen wrote:

> Dmitry A.Kazakov wrote:
>> I think that (1) would cause many problems with MI. When tag is a part of
>> the value and then view conversions are problematic.
>> There is also redispatch which is IMO incompatible with (1). I think
>> redispatch must be removed, because when object identification is really
>> necessary (to redispatch) one could use a solution similar to J.-P. Rosen
>> trick.
> 
> C++ uses (1), storing multiple "tags" (actually, virtual
> table pointers) in the object if necessary, and supports
> redispatch just fine. The scheme used by the new version
> of g++ is described at
> <http://www.codesourcery.com/cxx-abi/abi.html>.

So in C++ int will never be a class, worse to C++.
 
> I doubt that the language designers, assuming they do add
> MI to Ada, would be so silly as to deliberately choose to
> implement it in a way that could never be compatible with
> C++ object layout.

I do not think that to repeat others faults is a good idea. As long as we 
have no C++ operating system APIs (shudder), I doubt that it is worth 
effors to keep objects Ada and C++ compatible. To communicate with C++ one 
could declare a simple record type with fields reserved for places where 
vtptrs are.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Dispatching and generics - language lawyer question

[Hyman Rosen]

Dmitry A.Kazakov wrote:
> So in C++ int will never be a class, worse to C++.

It's never going be a class in Ada either.

 > I doubt that it is worth effors to keep objects Ada
 > and C++ compatible.

I think that the GNAT creators would disagree with you.
As far as I know, they make corresponding Ada and C++
objects layout compatible. Perhaps one of them will
explain why.

Re: Dispatching and generics - language lawyer question

[Stephen Leake]

Hyman Rosen <hyrosen@mail.com> writes:

> Dmitry A.Kazakov wrote:
> > So in C++ int will never be a class, worse to C++.
> 
> It's never going be a class in Ada either.
> 
>  > I doubt that it is worth effors to keep objects Ada
>  > and C++ compatible.
> 
> I think that the GNAT creators would disagree with you.
> As far as I know, they make corresponding Ada and C++
> objects layout compatible. Perhaps one of them will
> explain why.

It allows you to derive a new Ada type from a C++ class, and vice
versa. Then a dispatching call from a C++ routine can call an Ada
body, and vice versa.

It allows _full_ mixed language programming with Ada and C++. This is
a _very_ good feature. The alternative requires a C interface between
C++ and Ada, which is simply not as good.

-- 
-- Stephe

Re: Dispatching and generics - language lawyer question

[Warren W. Gay VE3WWG]

Stephen Leake wrote:
> Hyman Rosen <hyrosen@mail.com> writes:
>>Dmitry A.Kazakov wrote:
>>>So in C++ int will never be a class, worse to C++.
>>
>>It's never going be a class in Ada either.
>>
>> > I doubt that it is worth effors to keep objects Ada
>> > and C++ compatible.
>>
>>I think that the GNAT creators would disagree with you.
>>As far as I know, they make corresponding Ada and C++
>>objects layout compatible. Perhaps one of them will
>>explain why.
> 
> It allows you to derive a new Ada type from a C++ class, and vice
> versa. Then a dispatching call from a C++ routine can call an Ada
> body, and vice versa.
> 
> It allows _full_ mixed language programming with Ada and C++. This is
> a _very_ good feature. The alternative requires a C interface between
> C++ and Ada, which is simply not as good.

At least at the level of GNAT 3.13p, the C++ support was not quite
"full". To the best of my knowledge, the C++ destructors did
not work when the object went out of scope within Ada code.

You could call the destructor manually, but this of course is
not as convenient as the Ada.Finalization.Controlled type of
object that GNAT does support finalization for.

So in this respect, unless they have fixed this in later
versions (I did not check), the C++ level of support is not yet
"full" in GNAT.

Warren.

Re: Dispatching and generics - language lawyer question

[Dmitry A. Kazakov]

On Fri, 02 Aug 2002 11:49:34 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A.Kazakov wrote:
>> So in C++ int will never be a class, worse to C++.
>
>It's never going be a class in Ada either.

It was rather about an imaginary successor of Ada, which should not be
Ada++ in the sense of C++ = "C with classes". At some point one will
have to drive the line.

> > I doubt that it is worth effors to keep objects Ada
> > and C++ compatible.
>
>I think that the GNAT creators would disagree with you.
>As far as I know, they make corresponding Ada and C++
>objects layout compatible. Perhaps one of them will
>explain why.

Maybe because they get it more or less free. (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Dispatching and generics - language lawyer question

[Robert Dewar]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1028303374.179416@master.nyc.kbcfp.com>...

> I think that the GNAT creators would disagree with you.
> As far as I know, they make corresponding Ada and C++
> objects layout compatible. Perhaps one of them will
> explain why.


That's a bit confused. The layout of tagged types in
GNAT is defined by the body of the run-time unit Ada.Tags.
Whether this corresponds or not to some particular C++
compiler depends on whether you tailor Ada.Tags
appropriately. 

In practice, the only significant use of the tight C++
binding of objects and tagged types in GNAT was by SGI
for some of their graphics packages, otherwise I don't
think the feature has been used. 

(there are lots of things in GNAT that are very interesting
but don't get used, e.g. the entire Information Systems
Annex :-)

Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert C. Leif]

From: Bob Leif
To: Robert Dewar et al.

"(there are lots of things in GNAT that are very interesting
but don't get used, e.g. the entire Information Systems
Annex :-)" 
This is very unfortunate. I would prefer financial institutions employ
reliable software that works in decimals. One problem with the
Information Systems Annex is that it was to some extent based on COBOL,
particularly, the picture clause. For both marketing and technical
reasons, I believe that the Information Systems Annex would make an
excellent engine for an XML based system. In terms of Ada, the XML
Pattern element has some excellent layout features and capabilities.
However, some of its syntax is too terse. An Ada version would increase
the utility of the Information Systems Annex.

I also believe that a way around the static requirement for Ada decimals
should be created. I still would like to use the slide-rule formula to
calculate the exponent. Would a pragma To_Static be possible?

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Robert Dewar
Sent: Monday, August 12, 2002 5:45 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Dispatching and generics - language lawyer question

Hyman Rosen <hyrosen@mail.com> wrote in message
news:<1028303374.179416@master.nyc.kbcfp.com>...

> I think that the GNAT creators would disagree with you.
> As far as I know, they make corresponding Ada and C++
> objects layout compatible. Perhaps one of them will
> explain why.


That's a bit confused. The layout of tagged types in
GNAT is defined by the body of the run-time unit Ada.Tags.
Whether this corresponds or not to some particular C++
compiler depends on whether you tailor Ada.Tags
appropriately. 

In practice, the only significant use of the tight C++
binding of objects and tagged types in GNAT was by SGI
for some of their graphics packages, otherwise I don't
think the feature has been used. 

(there are lots of things in GNAT that are very interesting
but don't get used, e.g. the entire Information Systems
Annex :-)

Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert Dewar]

"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029204063.16221.comp.lang.ada@ada.eu.org>...
> One problem with the
> Information Systems Annex is that it was to some extent 
> based on COBOL,
> particularly, the picture clause.

To me that is a strength. After all, most financial software is still
written in COBOL, and the picture
clause in particular is one of the successful features
of that language. I think the reason for the lack of
use of Ada in the IS field has nothing whatever to do
with technical features in fact.

> I also believe that a way around the static requirement 
> for Ada decimals should be created.

I have no idea what this means

> I still would like to use the slide-rule formula to
> calculate the exponent. Would a pragma To_Static be 
> possible?

I have no guess as to what this might mean
 
> -----Original Message-----

Robert, please don't quote entire original messages when
it is completely irrelevant to do so. Stop your mailer
or newsreader from doing this!

RE: Information Systems Annex

[Robert C. Leif]

From: Bob Leif
To: Robert Dewar

I agree about COBOL providing strength; however, XML is and will be used
for reporting and achieving purposes. It is one of the few subjects that
Microsoft, IBM, Sun, and Adobe agree on. The XML Pattern element and its
attributes could be considered a generalized 21st century picture
clause.

As for decimals, how do I do the following in Ada?
2*10**-x * 3*10**y = 6*10**(y-x)      y and x being non-negative
integers.

If I have 10 or more decimal numbers with different exponents, I do not
know how to assign the optimum exponent at run-time. It would be
perfectly acceptable to have created a package of decimal types for the
entire range. However, the elegant way would be to instantiate a generic
at run-time, which is what one can presently do to size an array. The
y-x formula for the value of the exponent is the one I was taught in
high school for my slide-rule. 


-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Robert Dewar
Sent: Tuesday, August 13, 2002 1:18 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Information Systems Annex was RE: Dispatching and generics
- language lawyer question

"Robert C. Leif" <rleif@rleif.com> wrote in message
news:<mailman.1029204063.16221.comp.lang.ada@ada.eu.org>...
> One problem with the
> Information Systems Annex is that it was to some extent 
> based on COBOL,
> particularly, the picture clause.

To me that is a strength. After all, most financial software is still
written in COBOL, and the picture
clause in particular is one of the successful features
of that language. I think the reason for the lack of
use of Ada in the IS field has nothing whatever to do
with technical features in fact.

> I also believe that a way around the static requirement 
> for Ada decimals should be created.

I have no idea what this means

> I still would like to use the slide-rule formula to
> calculate the exponent. Would a pragma To_Static be 
> possible?

I have no guess as to what this might mean

Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Keith Thompson]

"Robert C. Leif" <rleif@rleif.com> writes:
[...]
> I also believe that a way around the static requirement for Ada decimals
> should be created. I still would like to use the slide-rule formula to
> calculate the exponent. Would a pragma To_Static be possible?

If you're talking about a fundamental change to the way certain types
are implemented and represented, I don't think a pragma is the way to
do it.  Ada decimal types (as currently defined) are fixed-point
types.

Are you asking for decimal floating-point?

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert C. Leif]

From: Bob Leif
To: Keith Thompson et al.
I would be happy with a decimal floating-point; but, would gladly settle
for a less elegant work-around. 

Since I have never worked with binary fixed-point types, please forgive
a naive question. Would the same capacity to create types with exponents
at run-time be of any use or is this equivalent to floating-point?

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Keith Thompson
Sent: Tuesday, August 13, 2002 10:38 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Information Systems Annex was RE: Dispatching and generics
- language lawyer question

"Robert C. Leif" <rleif@rleif.com> writes:
[...]
> I also believe that a way around the static requirement for Ada
decimals
> should be created. I still would like to use the slide-rule formula to
> calculate the exponent. Would a pragma To_Static be possible?

If you're talking about a fundamental change to the way certain types
are implemented and represented, I don't think a pragma is the way to
do it.  Ada decimal types (as currently defined) are fixed-point
types.

Are you asking for decimal floating-point?

-- 
Keith Thompson (The_Other_Keith) kst@cts.com
<http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Keith Thompson]

"Robert C. Leif" <rleif@rleif.com> writes:
> From: Bob Leif
> To: Keith Thompson et al.
> I would be happy with a decimal floating-point; but, would gladly settle
> for a less elegant work-around. 
> 
> Since I have never worked with binary fixed-point types, please forgive
> a naive question. Would the same capacity to create types with exponents
> at run-time be of any use or is this equivalent to floating-point?

I don't understand what kind of less elegant workaround you have in
mind.  I understand (I think) that you want an exponent value (or,
nearly equivalently, the position of the decimal point) to be
determined at run time.  If you want it to vary for each object, I
think you're talking about floating-point.  If you just want a
non-static but constant value determined when the type is created,
that's something else.

Here's an example from the RM:

    type Money is delta 0.01 digits 15;

The delta and digits values must both be static expressions.  Are you
saying you want one or both of them to be non-static?

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert C. Leif]

From: Bob Leif
To: Keith Thompson et al.

Since virtually all of these decimal types will be intermediates in a
calculation, they could all have the same number of digits. The delta is
the problem. My crude workaround was to turn a non-static number into a
static number by either a pragma or a method. However, I would be happy
with a decimal floating type.  

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Keith Thompson
Sent: Wednesday, August 14, 2002 1:53 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Information Systems Annex was RE: Dispatching and generics
- language lawyer question

"Robert C. Leif" <rleif@rleif.com> writes:
> From: Bob Leif
> To: Keith Thompson et al.
> I would be happy with a decimal floating-point; but, would gladly
settle
> for a less elegant work-around. 
> 
> Since I have never worked with binary fixed-point types, please
forgive
> a naive question. Would the same capacity to create types with
exponents
> at run-time be of any use or is this equivalent to floating-point?

I don't understand what kind of less elegant workaround you have in
mind.  I understand (I think) that you want an exponent value (or,
nearly equivalently, the position of the decimal point) to be
determined at run time.  If you want it to vary for each object, I
think you're talking about floating-point.  If you just want a
non-static but constant value determined when the type is created,
that's something else.

Here's an example from the RM:

    type Money is delta 0.01 digits 15;

The delta and digits values must both be static expressions.  Are you
saying you want one or both of them to be non-static?

-- 
Keith Thompson (The_Other_Keith) kst@cts.com
<http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert Dewar]

"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029362042.2405.comp.lang.ada@ada.eu.org>...
> Since virtually all of these decimal types will be 
> intermediates in a
> calculation, they could all have the same number of 
> digits.

I really have no idea what the above means.

> The delta is
> the problem.

Ditto


> My crude workaround was to turn a non-static number into 
> a static number by either a pragma or a method.

And double ditto here. Robert please explain at least vaguely what you
have in mind. What on earth does it mean
to turn a non-static number into a static number. You are
certainly not using the term static in the Ada sense, or
in any other common sense that I can guess.

> However, I would be happy
> with a decimal floating type. 

This seems to be of very marginal use to me. Certainly not
something to build into the language. If you need such a
facility, just program it, that's easy enough, Yes, it
will be inefficient, but no more or less inefficient than
if it is put in the language, since obviously no machines
support this at the hardware level, and all the compiler
would do is call runtime routines anyway. So all you are
talking about here is a minor bit of syntactic convenience
for a feature with very limited use. Hardly a good candidate for a
language extension.

Decimal Floating point was RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert C. Leif]

From: Bob Leif
To: Robert Dewar et al.

Since intermediate values in a calculation how a low frequency of being
printed out, the simplest solution to digits is to leave it at a fixed
value, which will usually be the maximum number of digits allowed. This
simplifies the use of precompiled datatypes. Only one for each value of
digits needs to be created.

Since Ada has a function Ada.Unchecked_Conversion(S : Source) return
Target; she does permit a change in types. In the case of the delta, I
am proposing what I hope is much less extreme. I want to tell the
compiler to accept a non-static number as a static number. Since this is
not a type change but the change of a property of a type, I do not know
how to do this? 


-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Robert Dewar
Sent: Thursday, August 15, 2002 2:32 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Information Systems Annex was RE: Dispatching and generics
- language lawyer question

"Robert C. Leif" <rleif@rleif.com> wrote in message
news:<mailman.1029362042.2405.comp.lang.ada@ada.eu.org>...
> Since virtually all of these decimal types will be 
> intermediates in a
> calculation, they could all have the same number of 
> digits.

I really have no idea what the above means.

> The delta is
> the problem.

Ditto


> My crude workaround was to turn a non-static number into 
> a static number by either a pragma or a method.

And double ditto here. Robert please explain at least vaguely what you
have in mind. What on earth does it mean
to turn a non-static number into a static number. You are
certainly not using the term static in the Ada sense, or
in any other common sense that I can guess.

> However, I would be happy
> with a decimal floating type. 

This seems to be of very marginal use to me. Certainly not
something to build into the language. If you need such a
facility, just program it, that's easy enough, Yes, it
will be inefficient, but no more or less inefficient than
if it is put in the language, since obviously no machines
support this at the hardware level, and all the compiler
would do is call runtime routines anyway. So all you are
talking about here is a minor bit of syntactic convenience
for a feature with very limited use. Hardly a good candidate for a
language extension.

Re: Decimal Floating point was RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Keith Thompson]

"Robert C. Leif" <rleif@rleif.com> writes:
> Since intermediate values in a calculation how a low frequency of being
> printed out, the simplest solution to digits is to leave it at a fixed
> value, which will usually be the maximum number of digits allowed. This
> simplifies the use of precompiled datatypes. Only one for each value of
> digits needs to be created.
> 
> Since Ada has a function Ada.Unchecked_Conversion(S : Source) return
> Target; she does permit a change in types. In the case of the delta, I
> am proposing what I hope is much less extreme. I want to tell the
> compiler to accept a non-static number as a static number. Since this is
> not a type change but the change of a property of a type, I do not know
> how to do this? 

You "want to tell the compiler to accept a non-static number as a
static number".  That barely even makes sense, and I don't believe
it's what you really need.

You're saying you want to use a non-static value in a context where
the language requires a static value.  Coercing the compiler to accept
a non-static value in such a context is not a "much less extreme" way
to do this, and a pragma is not an appropriate way to specify it.

I think you're jumping from what you want to be able to do to a
proposed implementation.  Unfortunately, the implementation you're
proposing is not workable.

What problem are you trying to solve?

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

RE: Decimal Floating point was RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert C. Leif]

From: Bob Leif,
To: Keith Thompson et al.
I only suggested To_Static as a possible implementation. All I want to
do is to create or be able to use a decimal type at run-time based on
either automatic or the simple-minded sum the exponents for
multiplication and subtract the exponents for division algorithm. As I
have previously stated, I would be quite happy with a decimal floating
type.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Keith Thompson
Sent: Thursday, August 15, 2002 11:26 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Decimal Floating point was RE: Information Systems Annex
was RE: Dispatching and generics - language lawyer question

"Robert C. Leif" <rleif@rleif.com> writes:
> Since intermediate values in a calculation how a low frequency of
being
> printed out, the simplest solution to digits is to leave it at a fixed
> value, which will usually be the maximum number of digits allowed.
This
> simplifies the use of precompiled datatypes. Only one for each value
of
> digits needs to be created.
> 
> Since Ada has a function Ada.Unchecked_Conversion(S : Source) return
> Target; she does permit a change in types. In the case of the delta, I
> am proposing what I hope is much less extreme. I want to tell the
> compiler to accept a non-static number as a static number. Since this
is
> not a type change but the change of a property of a type, I do not
know
> how to do this? 

You "want to tell the compiler to accept a non-static number as a
static number".  That barely even makes sense, and I don't believe
it's what you really need.

You're saying you want to use a non-static value in a context where
the language requires a static value.  Coercing the compiler to accept
a non-static value in such a context is not a "much less extreme" way
to do this, and a pragma is not an appropriate way to specify it.

I think you're jumping from what you want to be able to do to a
proposed implementation.  Unfortunately, the implementation you're
proposing is not workable.

What problem are you trying to solve?

-- 
Keith Thompson (The_Other_Keith) kst@cts.com
<http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: Decimal Floating point was RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Keith Thompson]

"Robert C. Leif" <rleif@rleif.com> writes:
> I only suggested To_Static as a possible implementation.

If I understand your suggestion correctly, it isn't.  It's not
feasible, it's not well-defined, and it's not likely to give you what
you want.  I'm afraid the suggestion has only served to muddy the
waters.

> All I want to do is to create or be able to use a decimal type at
> run-time based on either automatic or the simple-minded sum the
> exponents for multiplication and subtract the exponents for division
> algorithm. As I have previously stated, I would be quite happy with
> a decimal floating type.

Ok, there's some dispute over whether that would actually be useful,
or whether the existing decimal fixed-point facilities would meet your
needs, but presumably you know your application domain best.

There are probably multiple software implementations of decimal
floating-point.  Do a Google search and grab one of them.  If it's
implemented in a language other than Ada, write a binding.  Use it in
your application.  You'll lose a small amount of syntactic sugar
relative to having it as a language feature, but syntactic sugar is
often overrated.  You won't lose any significant efficiency; since
most hardware doesn't support decimal floating-point, a compiler would
have to use library calls anyway.

If it works out for you, if it lets you do useful things you couldn't
have done without it, let us know; we may be able to help you refine
your solution.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: Decimal Floating point was RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert Dewar]

"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029448502.10542.comp.lang.ada@ada.eu.org>...
> From: Bob Leif
> To: Robert Dewar et al.
> 
> Since Ada has a function Ada.Unchecked_Conversion(S : 
> Source) return Target; she does permit a change in types. 

Yes, but with implementation defined effects!

In the case of the delta, I
> am proposing what I hope is much less extreme. I want to tell the
> compiler to accept a non-static number as a static number. Since this is
> not a type change but the change of a property of a type,

Once again Bob, this is compeltely incomprehensible. A
"number" is not static or non-static in Ada, an expression
is static or non-static. See the rules in 4.9, and please
try to express what you have in mind in a comprehensible
manner using Ada terminology. If you can't do that, perhaps
you can provide a complete, even if vague example, and we
might be able to figure out what you have in mind.

It seems that you have some confusion between exponent and
delta in your mind. They of course are quite different
concepts. 

It is of course possible to change the delta of a number,
and if you want variable scaling (perhaps that is what you
are talking about) the easiest way is just to use conversions.

Remember that fixed point in Ada is nothing more than scaled integer
arithmetic. You can always do scaling yourself.

So what I would propose you do to illustrate your idea (which may have
merit, I can't tell, I don't have the
foggiest idea what it is), is to first program it manually
doing the scaling yourself.

Then imagine some syntactic sugar to help you with the
scaling. and illustrate the desired sugar.





 I do not know
> how to do this? 
> 
> 
> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org
> [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Robert Dewar
> Sent: Thursday, August 15, 2002 2:32 AM
> To: comp.lang.ada@ada.eu.org
> Subject: Re: Information Systems Annex was RE: Dispatching and generics
> - language lawyer question
> 
> "Robert C. Leif" <rleif@rleif.com> wrote in message
> news:<mailman.1029362042.2405.comp.lang.ada@ada.eu.org>...
> > Since virtually all of these decimal types will be 
> > intermediates in a
> > calculation, they could all have the same number of 
> > digits.
> 
> I really have no idea what the above means.
> 
> > The delta is
> > the problem.
> 
> Ditto
> 
> 
> > My crude workaround was to turn a non-static number into 
> > a static number by either a pragma or a method.
> 
> And double ditto here. Robert please explain at least vaguely what you
> have in mind. What on earth does it mean
> to turn a non-static number into a static number. You are
> certainly not using the term static in the Ada sense, or
> in any other common sense that I can guess.
> 
> > However, I would be happy
> > with a decimal floating type. 
> 
> This seems to be of very marginal use to me. Certainly not
> something to build into the language. If you need such a
> facility, just program it, that's easy enough, Yes, it
> will be inefficient, but no more or less inefficient than
> if it is put in the language, since obviously no machines
> support this at the hardware level, and all the compiler
> would do is call runtime routines anyway. So all you are
> talking about here is a minor bit of syntactic convenience
> for a feature with very limited use. Hardly a good candidate for a
> language extension.

Re: Decimal Floating point was RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert Dewar]

"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029448502.10542.comp.lang.ada@ada.eu.org>...
> From: Bob Leif

> Since intermediate values in a calculation how a low 
> frequency of being
> printed out, the simplest solution to digits is to leave 
> it at a fixed
> value.

This is also incomprehensible in the Ada context. In PL/1
and in COBOL, the precision and scaling of intermediate
results is not explicit. In PL/1 there are implicit rules
which turn out to have very surprising effects, and are
generally considered a signal failure.

In COBOL, intermediate precision is implementation defined
and as a consequence most COBOL coding standards forbid the
use of COMPUTE, with the possible exception of

   COMPUTE A = B ** C

since the exponentiation operator is only available in the
COMPUTE verb. But in this case there is no intermediate
result so all is well.

In Ada, we have a much better design where the programmer
is forced to specifically give the precision and scaling
of all intermediate results where an issue arises (addition
and subtraction do not present a problem, it is division
and multiplication that cause trouble).

So I don't understand your comment about intermediate
values in the context of Ada fixed-point.

Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert Dewar]

"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029282844.28090.comp.lang.ada@ada.eu.org>...
> Ada decimal types (as currently defined) are fixed-point
> types.
> 
> Are you asking for decimal floating-point?


Decimal floating-point would be quite useless in financial
applications as far as I can see (COBOL does not have this
facility). What you need in financial calculations is decimal
fixed-point, and very occasionally (this has only
recently been included in the COBOL standard) binary fpt.

Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Darren New]

Robert Dewar wrote:
> Decimal floating-point would be quite useless in financial
> applications as far as I can see (COBOL does not have this

Just out of curiousity, do people use decimal arithmetic for monetary
systems that aren't decimal? E.g., pence/shillings/pounds don't decompose
nicely into decimals to start with. Just curious if there are programming
languages that have built-in support (language or library) to handle such?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

Humility? Why would I need to show some humility?

Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[David C. Hoos]

Where have you been?  The Brits went to decimal pounds years ago.

----- Original Message -----
From: "Darren New" <dnew@san.rr.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Thursday, August 15, 2002 11:17 AM
Subject: Re: Information Systems Annex was RE: Dispatching and generics -
language lawyer question


> Robert Dewar wrote:
> > Decimal floating-point would be quite useless in financial
> > applications as far as I can see (COBOL does not have this
>
> Just out of curiousity, do people use decimal arithmetic for monetary
> systems that aren't decimal? E.g., pence/shillings/pounds don't decompose
> nicely into decimals to start with. Just curious if there are programming
> languages that have built-in support (language or library) to handle such?
>
> --
> Darren New
> San Diego, CA, USA (PST). Cryptokeys on demand.
>    ** http://images.fbrtech.com/dnew/ **
>
> Humility? Why would I need to show some humility?
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Darren New]

"David C. Hoos" wrote:
> Where have you been?  The Brits went to decimal pounds years ago.

Yes. I know. That's irrelevant to the question, tho.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

Humility? Why would I need to show some humility?

Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Frank J. Lhota]

"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
news:mailman.1029432361.2987.comp.lang.ada@ada.eu.org...
> Where have you been?  The Brits went to decimal pounds years ago.

... but back when PL/1 was first created, it included a predefined type
specifically for representing a quantity in the old British system (1 pound
= 240 pence).

Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[tmoran]

> systems that aren't decimal? E.g., pence/shillings/pounds don't decompose
> nicely into decimals to start with. Just curious if there are programming
  Some years ago I did a system for an outfit that sold historical
stock and commodity price data.  Some things were in pennies, some (like
stocks) in eighths, some in quarters, etc.  IIRC we defined a fixed point
type with the LCM of those things as its 'delta and then it was a simple
type conversion to move the odd prices in/out of that fixed point type.

Re: Information Systems Annex was RE: Dispatching and generics -

[Larry Kilgallen]

In article <3D5BD43F.D85D3CF3@san.rr.com>, Darren New <dnew@san.rr.com> writes:
> Robert Dewar wrote:
>> Decimal floating-point would be quite useless in financial
>> applications as far as I can see (COBOL does not have this
> 
> Just out of curiousity, do people use decimal arithmetic for monetary
> systems that aren't decimal? E.g., pence/shillings/pounds don't decompose
> nicely into decimals to start with.

They make the government change it to a decimal-based system to suit
the computers.  Another example besides the British one is the US
Stock exchanges which formerly quoted prices in eighth of a dollar
and similar fractions.

Re: Information Systems Annex was RE: Dispatching and generics -

[Hyman Rosen]

Larry Kilgallen wrote:
> They make the government change it to a decimal-based system to suit
> the computers.  Another example besides the British one is the US
> Stock exchanges which formerly quoted prices in eighth of a dollar
> and similar fractions.

US decimalization wasn't for the convenience of computers!
There was a pretty huge programming effort involved to effect
the change. Decimalization was done to allow quoted prices to
change in smaller increments, to make markets more efficient.

Of course, with price changes coming in pennies instead of in
eighths, some systems couldn't handle the resultant increase
in reporting volume :-)

Re: Information Systems Annex was RE: Dispatching and generics -

[Robert Dewar]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<r1usDG7Y2QvO@eisner.encompasserve.org>...

> They make the government change it to a decimal-based 
> system to suit computers.

That really was a small part of the motivation behind
the change, Britain's monetary system was a real mess
before the change, with crowns, guineas and pounds all
in simultaneous use as the primary currency unit. Also
the introduction of VAT really means that you want it
to be easy (for people) to compute percentages.

It also makes comparison shopping much easier.

As for computers, they could handle the old stuff just
fine, and indeed my uncle worked for Plesseys where
one of their early computers had registers implemented
with

   a row of decatrons  (for the pounds)

   a binary device and a decatron (for the shillings)

   a duodecatron (12 state decvice) for the pence

:-)
(this was a tube machine, where decimal devices made some reasonable hardware sense)

Re: Information Systems Annex was RE: Dispatching and generics -

[Simon Wright]

dewar@gnat.com (Robert Dewar) writes:

> That really was a small part of the motivation behind
> the change, Britain's monetary system was a real mess
> before the change, with crowns, guineas and pounds all
> in simultaneous use as the primary currency unit.

As I remember it the _practical_ unit was the half-crown (crowns were
only issued to celebrate significant events).

What about the florin!

Re: Information Systems Annex was RE: Dispatching and generics -

[Robert Dewar]

Simon Wright <simon@pushface.org> wrote in message news:<x7vadnm6lo2.fsf@pushface.org>...
> dewar@gnat.com (Robert Dewar) writes:
> 
> > That really was a small part of the motivation behind
> > the change, Britain's monetary system was a real mess
> > before the change, with crowns, guineas and pounds all
> > in simultaneous use as the primary currency unit.
> 
> As I remember it the _practical_ unit was the half-crown 
> (crowns were
> only issued to celebrate significant events).
> 
> What about the florin!

Well the florin and half crown were actual coins, but
certain dept instruments were denominated in crowns, and 
auctions were always in guineas (so I am talking about
financial transactions, that computers had to be prepared
to deal with, not names of coins).

Decimal Floating types was RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert C. Leif]

From: Bob Leif
To: Robert Dewar et al.

Please see IBM http://www2.hursley.ibm.com/decimal/
"Standard Decimal Arithmetic"

"Most computers today support binary floating-point in hardware. While
suitable for many purposes, binary floating-point should not be used for
financial, commercial, and user-centric applications and web services
because the decimal data used in these applications cannot be
represented exactly using binary floating-point. (See the Frequently
Asked Questions page for more reasons and examples.) "

"The problems of binary floating-point can be avoided by using base 10
(decimal) exponents and preserving those exponents where possible. This
site describes a decimal arithmetic which achieves the necessary results
and conforms to the relevant ANSI and IEEE standards. Notably, a single
data type can be used for integer, fixed-point, and floating-point
decimal arithmetic."


Since COBOL does not have a decimal floating point, COBOL programmers,
who still do most of the financial applications, have not had a chance
to try it!.  There is another class of financial programmers, the Wall
Street analysts. The analysts do derivatives and other exotic financial
instruments. Do they use conventional binary floating point or COBOL
decimal? 

I might note that you have in the past quite properly cautioned on the
complexity of conventional floating point calculations. One good way to
check them would be to employ a decimal floating point.

On a philosophical level, since computers are supposed to work for
humans, why not have them work in the most understandable way? I would
greatly prefer my spreadsheets and computer assisted mechanical design
programs be in decimal. Humans work in pseudo-integer space. We like our
numbers and dimensions, in particular, to be a float that corresponds to
an integer followed by a decimal point, followed by zeros. Designers do
not like to fiddle with a dimension that comes out 28.998. We greatly
prefer 29.000.



-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Robert Dewar
Sent: Thursday, August 15, 2002 2:27 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Information Systems Annex was RE: Dispatching and generics
- language lawyer question

"Robert C. Leif" <rleif@rleif.com> wrote in message
news:<mailman.1029282844.28090.comp.lang.ada@ada.eu.org>...
> Ada decimal types (as currently defined) are fixed-point
> types.
> 
> Are you asking for decimal floating-point?


Decimal floating-point would be quite useless in financial
applications as far as I can see (COBOL does not have this
facility). What you need in financial calculations is decimal
fixed-point, and very occasionally (this has only
recently been included in the COBOL standard) binary fpt.

Re: Decimal Floating types was RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert Dewar]

"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029448504.10558.comp.lang.ada@ada.eu.org>...

> Since COBOL does not have a decimal floating point, COBOL 
> programmers, who still do most of the financial 
> applications, have not had a chance
> to try it!.

And why do you suppose COBOL does not have this? It is
because the COBOL standards committee does not consider
it worth adding. What does Robert Leif know that the
committee does not :-)

The point is that in financial calculations, you either
want absolute error control, e.g. in computing yields of
bonds, where very often the instruments specify the exact
algorithm in terms of fixed-point decimal.

Or you want approximate results rounded. There is no
requirement for mathematically accurate rounding for
decimal floating-point that I am aware of, so in practice
if you are doing approximate calculations, it is just fine
to do things in binary with sufficient precision and then
round the binary to decimal. Yes, there are marginal cases
where the double rounding can lead you to be "off" by 1 ulp
but there are no situations where this would matter.

Furthermore, as I noted before, there is no point in embedding such a
feature into the language. If you want
decimal floating-point, just use a library, there are many,
that supply this capability and make calls to this library.
That's what the compiler would do anyway.

COBOL programmers can perfectly well use such libraries.
COBOL is perfectly capable of calling library routines!

This seems a perfect example of a "requirement" generated
out of the blue, without full understanding of the actual
problem space.

The COBOL committee has been extremely adventurous in
extending the language (the COBOL object model is for
example more ambitious than that of C++ or Ada). If there
was the slightest good argument for adding decimal floating
point to the language, it would have been seriously considered.

Re: Decimal Floating types

[Warren W. Gay VE3WWG]

Robert Dewar wrote:
> "Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029448504.10558.comp.lang.ada@ada.eu.org>...
>>Since COBOL does not have a decimal floating point, COBOL 
>>programmers, who still do most of the financial 
>>applications, have not had a chance
>>to try it!.
...
> Furthermore, as I noted before, there is no point in embedding such a
> feature into the language. If you want
> decimal floating-point, just use a library, there are many,
> that supply this capability and make calls to this library.
> That's what the compiler would do anyway.
> 
> COBOL programmers can perfectly well use such libraries.
> COBOL is perfectly capable of calling library routines!

It is not a problem for Ada or C++ to embrace a library, because
wrappers can be put around those calls to allow the natural use
of the +/- and other operators. But for COBOL it means using
library calls directly instead of a more natural "mathematic
expression", whatever that be in COBOL ;-)  But then, maybe
my knowledge of modern COBOL is limited.

To a maintenance programmer, there is nothing worse than
difficult to read code: library support for floating
decimal in COBOL does precisely this, AFAIK. It solves
one problem and creates another. For Ada, this is a non-issue
(apart from the limitations of the Adjust() primitive).
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Decimal Floating types

[Robert Dewar]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3D5D2529.8070501@cogeco.ca>...
> But for COBOL it means using
> library calls directly instead of a more natural 
> "mathematic expression", whatever that be in COBOL ;-) 

As I mentioned in my previous message, it is not usual
to use COMPUTE at all in COBOL, so the difference is 
between

   ADD FIELD-1 TO FIELD-2 GIVING FIELD-3.

and

   CALL DEC-FLOAT-ADD USING FIELD-1 FIELD-2 FIELD-3

Now to be fair, it will be a bit annoying that for the
CALL, these fields have to be defined in a particular way,
but the requirement for decimal floating-point is marginal
in any case, so one can live with this perfectly well.

> To a maintenance programmer, there is nothing worse than
> difficult to read code: library support for floating
> decimal in COBOL does precisely this, AFAIK. It solves
> one problem and creates another. 

You exaggerate. Probably because of "lack of knowledge of
modern COBOL" :-)

Seriously, I don't see any significant maintenance problem
here. COBOL programmers use libraries all the time.

Re: Decimal Floating types

[Warren W. Gay VE3WWG]

Robert Dewar wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3D5D2529.8070501@cogeco.ca>...
>>But for COBOL it means using
>>library calls directly instead of a more natural 
>>"mathematic expression", whatever that be in COBOL ;-) 
> 
> As I mentioned in my previous message, it is not usual
> to use COMPUTE at all in COBOL, so the difference is 
> between
> 
>    ADD FIELD-1 TO FIELD-2 GIVING FIELD-3.
> 
> and
> 
>    CALL DEC-FLOAT-ADD USING FIELD-1 FIELD-2 FIELD-3
> 
> Now to be fair, it will be a bit annoying that for the
> CALL, these fields have to be defined in a particular way,

I'll concede that this is not too bad. I tend to think in
C/Ada terms where you might have nested calls. But if you
already have to read statements like:

  ADD FIELD-1 TO FIELD-2 GIVING FIELD-3.

then I see no great leap in pain ;-)

>>To a maintenance programmer, there is nothing worse than
>>difficult to read code: library support for floating
>>decimal in COBOL does precisely this, AFAIK. It solves
>>one problem and creates another. 
> 
> You exaggerate. Probably because of "lack of knowledge of
> modern COBOL" :-)

It is true that I have no "modern COBOL experience". ;-)

> Seriously, I don't see any significant maintenance problem
> here. COBOL programmers use libraries all the time.

I wasn't questioning this issue at all. Merely the "compute
experience", but I think we agree on that above.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Decimal Floating types

[Robert Dewar]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3D5E5E14.5010405@cogeco.ca>...

> >    ADD FIELD-1 TO FIELD-2 GIVING FIELD-3.

ouch! I have been away from COBOL for too long, this
should of course be

       ADD FIELD-1 FIELD-2 GIVING FIELD-3

Re: Decimal Floating types

[SteveD]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0208191626.288b143d@posting.google.com...
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:<3D5E5E14.5010405@cogeco.ca>...
>
> > >    ADD FIELD-1 TO FIELD-2 GIVING FIELD-3.
>
> ouch! I have been away from COBOL for too long,...

Are you sure that's possible ;-)

SteveD

Re: Decimal Floating types

[Richard Riehle]

Robert Dewar wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3D5E5E14.5010405@cogeco.ca>...
>
> > >    ADD FIELD-1 TO FIELD-2 GIVING FIELD-3.
>
> ouch! I have been away from COBOL for too long, this
> should of course be
>
>        ADD FIELD-1 FIELD-2 GIVING FIELD-3

Actually,  the TO is not illegal, according to the syntax chart in my
closest-to-hand COBOL book.    It is simply optional when using the
GIVING option.  .

       ADD {identifier-1/literal-1} ... TO {identifier-2/literal-2}
               GIVING {identifier-3}   ...
       END-ADD

The ADD, GIVING and END-ADD are underscored.  The TO is not.

Robert is correct that COBOL programmers are quite able to do their
job without a floating point type.   However, the USAGE IS clause
offers some data formats beyond those found in Ada and of particular
value to the day-to-day COBOL practitioner.

Richard Riehle

Re: Decimal Floating types

[Robert Dewar]

Richard Riehle <richard@adaworks.com> wrote in message news:<3D652A33.B5FE93B9@adaworks.com>...

> Actually,  the TO is not illegal, according to the syntax 
> chart in my closest-to-hand COBOL book.

Yes, but it is not used in practice, at least in my
experience, and I prefer to use typical style when I
quote COBOL (or any other language) :-)

Re: Information Systems Annex (usefulness of Decimal Floats)

[Warren W. Gay VE3WWG]

Robert Dewar wrote:
> "Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029282844.28090.comp.lang.ada@ada.eu.org>...
> 
>>Ada decimal types (as currently defined) are fixed-point
>>types.
>>
>>Are you asking for decimal floating-point?
> 
> Decimal floating-point would be quite useless in financial
> applications as far as I can see (COBOL does not have this
> facility). 

"Useless" is extreme. There are situations where decimal floating
point is useful in computing financial values, but normally as
intermediate results. The final values of financial calculations
are obviously stored in fixed point.

Currency conversions are often performed in floating point
decimal since the currencies move all over the map in
relative terms in terms of scale. As long as the precision
is maintained in the intermediate results, and that you
properly anticipate the resulting scale and precision, the
use of decimal floats as intermediates work well, with
the final results being stored in a fixed point decimal form.

One recent example of this, was the Euro conversion,
where we had to do those triangulation computations (three
currencies were involved). You have a broad range of values
between British pound and the Turkish Lira, for example.

For smaller numbers you might still cry foul, but when you're
computing the asset value of fund or fund(s) or management
company(ies), you run into larger numbers ;-)

Again of course, you _could_ structure your computations such
that you don't need decimal floats, but this requires
extreme care and good testing (something you don't often
get from junior programmers - but that is a different issue ;-).
So often it is just easier and safer to use decimal floats
provided that the necessary precision is maintained.

As a side note I should mention that in C/C++ code, floating
point decimal is really the only other choice to binary
floating point values. Database vendors INFORMIX
and ORACLE for example, provide routines for decimal
floating point computations (but not for fixed point).
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Information Systems Annex (usefulness of Decimal Floats)

[Robert Dewar]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3D5D1EA5.1040406@cogeco.ca>...
> Robert Dewar wrote:
> > "Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029282844.28090.comp.lang.ada@ada.eu.org>...
> "Useless" is extreme. There are situations where decimal 
> floating point is useful in computing financial values, 
> but normally as intermediate results.

For intermediate results, decimal floating-point offers no
particular advantages over binary floating-point. Indeed
the proposal carefully considered by CODASYL, but as far
as I know not adopted, was to require the use of IEEE
64-bit binary floating-point arithmetic for calculation
of intermediate results in COMPUTE.

Note that in general the COBOL style is not to use COMPUTE
but rather to carefully control the intermediate precision
of each step, in which case floating-point offers very little advantage if any.

Re: Information Systems Annex (usefulness of Decimal Floats)

[Warren W. Gay VE3WWG]

Robert Dewar wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3D5D1EA5.1040406@cogeco.ca>...
>>Robert Dewar wrote:
>>>"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029282844.28090.comp.lang.ada@ada.eu.org>...
>>
>>"Useless" is extreme. There are situations where decimal 
>>floating point is useful in computing financial values, 
>>but normally as intermediate results.
> 
> For intermediate results, decimal floating-point offers no
> particular advantages over binary floating-point. 

I disagree because binary floating point carries with it the
disadvantage of not being able to represent values
like 0.3 (it uses 0.299999 repeat), where a decimal floating
point does this precisely.

> Indeed
> the proposal carefully considered by CODASYL, but as far
> as I know not adopted, was to require the use of IEEE
> 64-bit binary floating-point arithmetic for calculation
> of intermediate results in COMPUTE.

I was speaking more generally about "computing financial
values" -- not strictly about COBOL.

> Note that in general the COBOL style is not to use COMPUTE
> but rather to carefully control the intermediate precision
> of each step, in which case floating-point offers very little advantage if any.

No disagreement there.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Information Systems Annex (usefulness of Decimal Floats)

[Robert Dewar]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3D5D1EA5.1040406@cogeco.ca>...

> One recent example of this, was the Euro conversion,
> where we had to do those triangulation computations 
> (three currencies were involved). You have a broad range 
> of values between British pound and the Turkish Lira, for 
> example.

Sorry, I don't see this. Were you writing in COBOL? I would
guess not. In COBOL, this calculation is easily done in
decimal fixed point (and in Ada you could do the same
thing :-)

Re: Information Systems Annex (usefulness of Decimal Floats)

[Warren W. Gay VE3WWG]

Robert Dewar wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3D5D1EA5.1040406@cogeco.ca>...
>>One recent example of this, was the Euro conversion,
>>where we had to do those triangulation computations 
>>(three currencies were involved). You have a broad range 
>>of values between British pound and the Turkish Lira, for 
>>example.
> 
> Sorry, I don't see this. Were you writing in COBOL? I would
> guess not. In COBOL, this calculation is easily done in
> decimal fixed point (and in Ada you could do the same
> thing :-)

No, not COBOL, and I wish it were Ada. Unfortunately one
system is predominantly C (some C++) which can make use
of the INFORMIX decimal floating point routines. Another
system uses COGNOS' Powerhouse, in which I was not much
involved with at the time.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

RE: Information Systems Annex (usefulness of Decimal Floats)

[Robert C. Leif]

From: Robert C. Leif
To: Robert Dewar et al.
Decimal fixed point is sufficient only if you have a common intermediate
reference, such as the Dollar, Euro, or gold. However, one can get into
a combinatorial catastrophe employing multiple conversion factors.
Complex scientific and engineering calculations require a floating type.
I still believe that given the existence of gigahertz processors, that
there is a benefit in performing calculations in the most human
understandable format, decimal. However, since this is a philosophical
question, rather than an Ada question, I am quite willing to terminate
this discussion.
-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Robert Dewar
Sent: Saturday, August 17, 2002 3:56 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Information Systems Annex (usefulness of Decimal Floats)

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:<3D5D1EA5.1040406@cogeco.ca>...

> One recent example of this, was the Euro conversion,
> where we had to do those triangulation computations 
> (three currencies were involved). You have a broad range 
> of values between British pound and the Turkish Lira, for 
> example.

Sorry, I don't see this. Were you writing in COBOL? I would
guess not. In COBOL, this calculation is easily done in
decimal fixed point (and in Ada you could do the same
thing :-)

Re: Information Systems Annex (usefulness of Decimal Floats)

[Robert Dewar]

"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029611105.24616.comp.lang.ada@ada.eu.org>...
> From: Robert C. Leif
> To: Robert Dewar et al.

> Decimal fixed point is sufficient only if you have a 
> common intermediate
> reference, such as the Dollar, Euro, or gold. However, 
> one can get into
> a combinatorial catastrophe employing multiple conversion 
> factors.

Sorry, this just seems like FUD. I have written a lot of
financial code of some complexity in COBOL, and never run
into any requirement like this. And as I pointed out before
clearly the COBOL community has not considered this a problem or this
facility would have been provided. Remember
that fixed-point can always be used for any calculations
if you are willing to worry carefully about scaling.

> Complex scientific and engineering calculations require a 
> floating type. I still believe that given the existence 
> of gigahertz processors, that
> there is a benefit in performing calculations in the most 
> human understandable format, decimal. 

This is wrong for two reasons.

1. The efficiency hit on modern processors between binary
floating-point (IEEE 754) and simulated decimal floating
point (IEEE 854) is simply huge. Probably a factor of 200
in practice at least, perhaps more with modern pipelined
machines. That means your gigahertz processor is crawling
along at the equivalent of 5 megahertz (like the original
PC-1), totally hopeless for "complex scientific and engineering
calculations".

2. There are no gains in practice over binary floating-point. Yes, it
may avoid surprises for naive users, but naive users of floating-point
should be banned
from doing "complex scientific and engineering calculations" since
they will make a complete mess of it.
Such applications [I have even more experience in that
sphere] require a proper understanding of how floating-point works,
and how errors propagate, and there is nothing inherently better about
decimal fpt.

The one area where decimal fpt has turned out to be an advantage is in
hand held calculators, where abysmal performance does not matter at
all, and you avoid surprises for naive users :-)

Note that once you start talking about "complex scientific
and engineering" applications, you have completely shifted
the sphere of argument away from the subject material. This has
nothing whatever to do with the Information Systems Annex.

Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question

[Robert Dewar]

"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029282844.28090.comp.lang.ada@ada.eu.org>...
 
> Since I have never worked with binary fixed-point types, > please forgive
> a naive question. Would the same capacity to create types 
> with exponents
> at run-time be of any use or is this equivalent to 
> floating-point?

I had not noticed this earlier, but in fact this may account for a lot
of the issues here. Bob, I am not sure
you understand what fixed point is all about in COBOL or
in Ada, and that may explain things. There is of course
no exponent for fixed-point numbers, static or otherwise.
They are simply scaled integers, and the arithmetic is
scaled integer arithmetic.

The request for decimal floating-point is a completely
orthogonal issue. Just as binary floating-point has nothing
whatever to do with with binary fixed-point from a 
representation point of view, it is the case that decimal
fixed-point has nothing to do with decimal floating-point.

Doing my best to guess what you are thinking here. I suspect that you
are assuming that decimal fixed point
representation is like floating point but with a fixed
exponent (which you have called static), and that leads
to your confusing discussion of allowing this exponent
to be dynamic.

But there *is* no exponent at all in decimal fixed-point
so this viewpoint is unhelpfully confusing.

Fixed-point in Ada is just like Fixed-point in COBOL or
PL/1. In all three languages we are just talking about
scaled integer arithmetic, so if you write

   type Money is delta 0.01 digits 10;

then you are just asking that values of type Money be
stored in pennies. So that if you write

   M : Money := 34.56;

then M contains the integer 3456

Note that it does not matter for most practical purposes
whether this integer is stored in binary or decimal, since
that will not affect any calculation results. In GNAT we
normally store such values in binary. There is some work
towards supporting IBM mainframe compatible packed decimal
for the purposes of interfacing with COBOL, but no one ever
showed any interest in this, so this work was not completed
(see i-pacdec if you are interested in looking at this
partial work -- indeed i-pacdec can be used directly from
user code, but the idea was to have the compiler generate
calls for arithmetic on decimal fixed-point represented
in decimal form).

Re: Dispatching and generics - language lawyer question

[Randy Brukardt]

Robert A Duff wrote in message ...
Bon Duff wrote:

>Note that the distinction between (1) and (2) is analogous to the
>compiler storing array bounds with the array, or with pointers to the
>array.  Neither one is uniformly better.  I believe GNAT allows a user
>choice, and I think all other compilers store bounds with the array
>(analogous to (1)).


Janus/Ada actually does neither -- the bounds are stored separately, and
belong to neither. (The memory used is allocated separately if needed.)
Indeed, I don't think you can store the bounds with the array for
slices, so I think your analogy is incorrect (there is nothing like
slices for tagged types, of course).

           Randy.

Re: Dispatching and generics - language lawyer question

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Janus/Ada actually does neither -- the bounds are stored separately, and
> belong to neither. (The memory used is allocated separately if needed.)
> Indeed, I don't think you can store the bounds with the array for
> slices, so I think your analogy is incorrect (there is nothing like
> slices for tagged types, of course).

Good point.  If a slice is passed as a parameter, the bounds ought to be
passed separately from the pointer-to-data.  In Ada 83, I suppose one
could always copy slices, but in Ada 95, some types require pass by
reference.  Including a slice of one of those.

- Bob

Re: Dispatching and generics - language lawyer question

[Robert Dewar]

"Grein, Christoph" <christoph.grein@eurocopter.com> wrote in message news:<mailman.1027489082.2047.comp.lang.ada@ada.eu.org>...
> When you used this trick to redefine 
> equality, also the predefined equality reemerged as in 
> the cases above. Thus for 
> compatibility, we have this rule in Ada 95.

The compatibility consideration here does not relate solely
to the use of the trick for redefining equality.