CVS difference for ai12s/ai12-0208-1.txt

Differences between 1.3 and version 1.4
Log of other versions for file ai12s/ai12-0208-1.txt

--- ai12s/ai12-0208-1.txt	2018/01/25 05:53:25	1.3
+++ ai12s/ai12-0208-1.txt	2018/02/27 04:29:33	1.4
@@ -1026,7 +1026,8 @@
 
     function Convert (Val : in Bignum'Class) return Bignum;
 
-but thinking about it now, I can't figure out how one would implement one of those.
+but thinking about it now, I can't figure out how one would implement one of
+those.
 
 You'd probably have to have a concrete universal representation to make that
 work:
@@ -1035,9 +1036,12 @@
 
     function Convert (Val : in Universal_Big) return BigNum;
 
-but of course that would bring in the memory allocation/finalization issues that you are trying to avoid.
+but of course that would bring in the memory allocation/finalization issues
+that you are trying to avoid.
 
-So at this moment I'm thinking that direct conversions would have to be left out; you could generally do it through intermediary types like Max_Integer using Numerator/Demomonator.
+So at this moment I'm thinking that direct conversions would have to be left
+out; you could generally do it through intermediary types like Max_Integer
+using Numerator/Demomonator.
 
 > >> 4) We need an Assign procedure. In the unbounded case it can be just
 > >>      a wrapper for predefined assignment, but in the bounded case it
@@ -1058,9 +1062,9 @@
 > It may be that this is an unimportant corner case and you are right to
 > dismiss it; I don't know.
 
-We're not trying to be all things to all people. I'd consider these "exact" math
-packages and treat them accordingly. If there is an abstract root, one can
-"easily" make a clone version that uses rounding if someone needs that.
+We're not trying to be all things to all people. I'd consider these "exact"
+math packages and treat them accordingly. If there is an abstract root, one
+can "easily" make a clone version that uses rounding if someone needs that.
 (Defining the rounding is hard, as you noted elsewhere.)
 
 > >> 6) Do we want functions to describe the mapping between Capacity
@@ -1085,3 +1089,94 @@
 
 ****************************************************************
 
+From: Bob Duff
+Sent: Sunday, January 28, 2018  11:29 AM
+
+> Steve Baird writes:
+> ...
+> > Questions/observations include:
+> 
+> 0) Should Big_Integer and (especially) Big_Rational be visibly tagged?
+
+Surely not.  I think we want to be competetive (efficiency-wise) with all
+sorts of other languages, and taggedness will destroy that.
+
+Let's not have another "tampering" fiasco.
+
+> If so, then we can use prefix notation on functions like Numerator and 
+> Denominator.
+
+I'm not a big fan of that feature, but if we want it, we should figure out
+how to do it for untagged types.
+
+>... We could also consider deriving both versions (usual and
+> bounded) from an abstract ancestor.
+
+Consider, ..., and reject.  ;-)
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Sunday, January 28, 2018  12:21 PM
+
+John Barnes wrote:
+
+  I wrote a bignum package in Ada 83 some 30 years ago
+ 
+Would you be able to let us see the spec for this?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, January 28, 2018  9:13 PM
+
+> > 0) Should Big_Integer and (especially) Big_Rational be
+> visibly tagged?
+> 
+> Surely not.  I think we want to be competetive
+> (efficiency-wise) with all sorts of other languages, and taggedness 
+> will destroy that.
+
+??? Tags (as opposed to controlled types) add almost no overhead, especially
+in a case like unbounded Bignum which probably will have to be controlled
+anyway. (The only overhead of a tagged type is initializing the tag in the
+object.) So long as one uses a single specific type, everything is statically
+bound and the cost is essentially the same as an untagged type (again,
+especially as the underlying specific type most likely will be tagged and
+certainly will be large).
+
+I wasn't suggesting that we define any class-wide operations other than
+representation conversion (which should be rarely used in any case).
+Class-wide operations are the only operations that add overhead.
+
+> Let's not have another "tampering" fiasco.
+
+I'm still waiting for an example program showing this supposed "fiasco". No
+one has ever submitted one to the ARG. We've essentially been asked to believe
+this issue by repeated assertion. (And most tampering checks can be done at
+compile-time, with sufficient will.)
+
+If there was a fiasco here, it was that the goals of the containers did not 
+include making them particularly fast. If they are then misused for
+high-performance code, one is going to get the expected disappointment.
+Perhaps we started with the wrong set of goals.
+
+> > If so, then we can use prefix notation on functions like Numerator 
+> > and Denominator.
+> 
+> I'm not a big fan of that feature, but if we want it, we should figure 
+> out how to do it for untagged types.
+
+We've already discussed that in a different e-mail thread. It seems dangerous.
+
+> >... We could also consider deriving both versions (usual and
+> > bounded) from an abstract ancestor.
+> 
+> Consider, ..., and reject.  ;-)
+
+Again, why? We have a request for a "universal" numeric type, and the only
+sane way to provide that is with dispatching. Probably, we'll just forget 
+that request, but it seems worth spending a bit of time to see if it makes
+sense.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent