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

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

--- ai12s/ai12-0208-1.txt	2018/12/07 03:37:05	1.13
+++ ai12s/ai12-0208-1.txt	2018/12/07 07:01:28	1.14
@@ -3777,3 +3777,404 @@
 "AI12-011". Also fixed.
 
 ****************************************************************
+
+From: Jeff Cousins
+Sent: Monday, December  3, 2018  2:22 PM
+
+Looks good to me.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, December  2, 2018  1:32 PM
+
+> ...
+> Upon rereading, I wonder whether we should delete the Width parameters 
+> from the From_String functions. Do those make sense for a function 
+> that is passed a String (as opposed to reading characters from a 
+> file)?
+
+If you look at the "Get" functions in Text_IO that get from a string, they 
+do omit the Width parameters, so it would seem we would be justified in 
+omitting them here as well.  In general, the length of the string provides 
+the value of the Width parameter for operations that operate on strings.  
+However, if the operation *returns* a String rather fills in a String provided
+as an OUT parameter, there is no Length, for for conversion *to* a string, 
+some sort of Width might be useful, but note that 'Image doesn't provide that.
+
+> If we decide to do this, then we should also delete the mention of 
+> Width in the accompanying text for Big_Rationals (but not in the 
+> corresponding text for Big_Integers) because with this change there 
+> will no longer be any subprograms in the Big_Rationals spec that take 
+> a Width parameter.
+
+Makes sense.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, December  3, 2018  2:09 PM
+
+I should read this one carefully. But what should I read? The AI on the 
+database seems a bit old.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Monday, December  3, 2018  2:25 PM
+
+Look at the v4 attached to Steveís last e-mail.
+
+Hopefully Iíve attached it.
+
+****************************************************************
+
+From: John Barnes
+Sent: Tuesday, December  4, 2018  1:56 AM
+
+OK Got it. I assumed the AI had been updated. This is the text for the 
+uncluttered AARM
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Monday, December  3, 2018  11:36 PM
+
+>       function "+" (Arg : Integer) return Valid_Big_Integer;
+>       function To_Big_Integer (Arg : Integer) return Valid_Big_Integer
+>         renames "+";
+
+Wouldn't it be more logical to have these the other way round? i.e.:
+       function To_Big_Integer  (Arg : Integer) return
+            Valid_Big_Integer;
+       function "+" (Arg : Integer) return Valid_Big_Integer
+         renames To_Big_Integer;
+
+Better have "+" as a shorthand for To_Big_Integer rather than To_Big_Integer 
+as a "longhand" for "+"...
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, December  4, 2018  6:14 AM
+
+I agree.  It doesn't make any difference to the compiler, but it might make 
+a difference to tools such as debuggers, and it does seem more logical.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Tuesday, December  4, 2018  9:22 AM
+
+That seems a good point to me, thanks JP.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, December  4, 2018  6:43 AM
+
+Good point, JP.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, December  4, 2018  11:11 AM
+
+Sounds good to me.
+
+****************************************************************
+
+From: John Barnes
+Sent: Tuesday, December  4, 2018  11:33 AM
+
+And to me. 
+
+****************************************************************
+
+From: John Barnes
+Sent: Wednesday, December  5, 2018  4:30 AM
+
+I just started to read this in detail. Gosh Ada has lots of things now that 
+I don't remember.
+
+But a minor point first.
+
+A5.5 says The package Ada.Numerics.Big_Numbers has the following declaration:
+
+But A5.6 says The package Ada.Numerics.Big_Numbers.Big_Integers has the 
+following definition:
+
+Why definition and not declaration?
+
+Same in A.5.8 for Big_Integers.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, December  5, 2018  1:33 PM
+
+The RM is not consistent about the wording introducing language-defined 
+packages.
+
+I found 58 "has the following declaration" and 33 "language-defined package 
+exits". There's also some that don't use any words at all or aren't 
+consistent.
+
+OTOH, I didn't find any "has the following definition", except for the ones 
+I added last night. So that must have been a mis-read on my part. And clearly,
+the ones in AI12-0208-1 are also wrong - should be "declaration".
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, December  6, 2018  2:05 PM
+
+> The attached is intended to include the corrections you suggested 
+> except for the stuff about deferred
+
+Thanks, Steve.
+
+Comments on the attached AI12-0208.v4.txt: [Editor's note: This attachment 
+is /06 of the AI, despite the name.]
+
+>    package Ada.Numerics.Big_Numbers.Big_Integers
+>       with Preelaborate, Nonblocking
+>    is
+>       type Big_Integer is private with
+>         Default_Initial_Condition => not Is_Valid (Big_Integer),
+>         Integer_Literal => From_String,
+>         Put_Image => Put_Image;
+>
+>       function Is_Valid (Arg : Big_Integer) return Boolean;
+>
+>       subtype Valid_Big_Integer is Big_Integer
+>         with Dynamic_Predicate => Is_Valid (Valid_Big_Integer),
+>              Predicate_Failure => (raise Constraint_Error);
+
+I expect Valid_Big_Integer will be used far more commonly than Big_Integer. 
+(That's true in the code in the package spec, and for client code.)  
+Furthermore, an invalid Big_Integer is not an integer at all.  Therefore 
+I suggest name changes:
+
+    Big_Integer --> Optional_Big_Integer
+    Valid_Big_Integer --> Big_Integer
+
+We don't say "Valid_Big_Positive" etc, so Valid_Big_Integer seems inconsistent 
+and a bit weird.
+
+Same for Big_Rats.
+
+> Implementation Requirements
+>   No storage associated with a Big_Integer object shall be lost upon
+>   assignment or scope exit.
+
+The CodePeer implementation of big ints doesn't do that
+-- it leaks very slowly in practice, and that has proven to work well. I fear 
+it's the only efficient way to do it, unless you have garbage collection.
+
+>    - Bounded_Big_Integers is a generic package and takes a generic formal:
+>         Capacity : Natural;
+
+I question making Capacity a generic formal. I think it should be a 
+discriminant. It seems to me the primary use of Bounded_Big_Integers will be 
+to implement Big_Integers, and that only works if you can have various-sized 
+Bounded_Big_Integers all of the same type.
+
+Yes, I know that means assignment statements won't work "right".  Too bad.  
+We can provide a Copy procedure.
+
+We made this mistake with Bounded_Strings, and they're a huge pain to use 
+because of that.
+
+>    with Ada.Numerics.Big_Numbers.Big_Integers;
+>    with Ada.Numerics.Big_Numbers.Bounded_Big_Integers;
+>    generic
+>       with package Bounded is new Bounded_Big_Integers (<>);
+
+This seems pretty heavy, syntactically.  See above about discrims.
+
+>    package Ada.Numerics.Big_Numbers.Conversions
+
+>       function "+" (Arg : Integer) return Valid_Big_Rational is
+>         ((+Arg) / 1);
+
+Seems like you want a conversion from Big_Int to Big_Rat.
+But probably not called "+".
+
+>       generic
+>          type Num is digits <>;
+>       package Float_Conversions is
+>          function To_Big_Rational (Arg : Num) return Valid_Big_Rational;
+>
+>          function From_Big_Rational (Arg : Valid_Big_Rational) return Num
+>            with Pre => In_Range (Arg,
+>                                  Low  => To_Big_Rational (Num'First),
+>                                  High => To_Big_Rational (Num'Last))
+>                        or else (raise Constraint_Error);
+>       end Float_Conversions;
+
+Should we have conversions to/from fixed point?
+
+>       function To_String (Arg  : Valid_Big_Rational;
+>                           Fore : Field := 2;
+>                           Aft  : Field := 3;
+>                           Exp  : Field := 0) return String
+>          with Post => To_String'Result'First = 1;
+>       function From_String (Arg   : String;
+>                             Width : Field := 0) return Valid_Big_Rational;
+>
+>       function To_Quotient_String (Arg : Valid_Big_Rational) return String is
+>         (To_String (Numerator (Arg)) & " /" & To_String (Denominator (Arg)));
+
+Why is there an extra blank before "/" but not after?
+It says about that To_String for Big_Int doesn't put the annoying blank, by default.
+
+>       function "**" (L : Valid_Big_Rational; R : Integer)
+>         return Valid_Big_Rational;
+
+How about another "**" that takes a Big_Int?
+
+> [TBD: Is Constraint_Error the exception we want on the 
+> Predicate_Failure aspect specs for Valid_Big_Integer and 
+> Valid_Big_Rational?]
+
+OK with me.  I don't much caare.
+
+> [TBD: do we want a Fixed_Conversions generic package analogous to 
+> Float_Conversions?]
+
+Ah, I asked that above.  I'd say probably yes.
+
+> [TBD: the range check on From_Big_Rational is slightly too tight.
+> For example,
+>     X : IEEE_Float32 :=
+>       IEEE_Float32 (IEEE_Float64'Succ (IEEE_Float64 
+> (IEEE_Float32'Last))); does not overflow but the corresponding 
+> conversion using From_Big_Rational would fail the range check. Do we 
+> care?]
+
+I don't know.
+
+> This section, or at least the AARM note, is intended to follow the 
+> structure of the analogous wording for  AI12-011 (contracts for 
+> containers).
+>
+> Add after 11.5(23):
+>
+> Big_Number_Check
+>
+> Perform the checks associated with Pre, Static_Predicate, 
+> Dynamic_Predicate, or Type_Invariant aspect specifications occuring in 
+> the visible part of package Ada.Big_Numbers or of any of its descendants.
+>
+> [TBD: Include Static_Predicate in this list just for completeness, 
+> even though it happens that there are no Static_Predicate 
+> specifications in these units?]
+
+Either way is OK with me.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December  6, 2018  9:21 PM
+
+> We don't say "Valid_Big_Positive" etc, so Valid_Big_Integer seems 
+> inconsistent and a bit weird.
+
+I note that we discussed these names in Lexington and decided on these
+exactly:
+
+  Tucker suggests that the names would be Big_Integer and Valid_Big_Integer. This
+  seems consistent with existing languages. Bob says he can live with that (and
+  he will complain about it).
+
+I suppose this comment qualifies. :-)
+
+> Same for Big_Rats.
+> 
+> > Implementation Requirements
+> >   No storage associated with a Big_Integer object shall be lost upon
+> >   assignment or scope exit.
+> 
+> The CodePeer implementation of big ints doesn't do that
+> -- it leaks very slowly in practice, and that has proven to work well. 
+> I fear it's the only efficient way to do it, unless you have garbage 
+> collection.
+
+I don't believe that there is any efficient implementation of unbounded 
+Big_Integers for Ada. Any implementation like the one you described in 
+Lexington (and above) would have to use a global level of indirection to deal 
+with oversize objects (modern Oses scramble address spaces, so no assumptions 
+can be made about the location of anything), and that would be a problem for 
+multitasking (since you'd be accessing a global data structure).
+You'd have to use some form of locking (at a minimum via atomic objects), and 
+that would also sap performance. Moreover, for a 32-bit implementation like 
+Janus/Ada, you're going to have a lot of memory used that way -- it's not a 
+*slow* storage leak.
+
+If you need critical performance, you'll have to use the bounded form.
+
+> >    - Bounded_Big_Integers is a generic package and takes a generic formal:
+> >         Capacity : Natural;
+> 
+> I question making Capacity a generic formal. I think it should be a 
+> discriminant. It seems to me the primary use of Bounded_Big_Integers 
+> will be to implement Big_Integers, and that only works if you can have 
+> various-sized Bounded_Big_Integers all of the same type.
+
+Agreed. This is a discriminant for the bounded containers for this reason.
+
+...
+> > [TBD: do we want a Fixed_Conversions generic package analogous to 
+> > Float_Conversions?]
+> 
+> Ah, I asked that above.  I'd say probably yes.
+
+I'd say no, because accuracy requirements seem to be major problem for such 
+conversions. I know that Steve has shown that one can always get the right 
+answer using essentially a binary search of model intervals, but that seems to
+be more of a thought experiment than a real implementation technique (it would
+use thousands of big rational operations).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, December  6, 2018  9:33 PM
+
+> I'd say no, because accuracy requirements seem to be major problem for such
+> conversions. I know that Steve has shown that one can always get the right
+> answer using essentially a binary search of model intervals, but that seems
+> to be more of a thought experiment than a real implementation technique (it
+> would use thousands of big rational operations).
+
+I believe there is a well documented mechanism for doing this properly. 
+AdaMagic does the right thing here.  I'd be happy to provide the algorithm.
+It is based on the notion of "continued fractions" I believe.  I recently 
+analyzed supporting fixed point in our code generator for Simulink, and wrote 
+up the algorithms in a short document.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December  6, 2018  9:51 PM
+
+>I believe there is a well documented mechanism for doing this properly.
+
+Maybe, but if I don't know it, it might as well not exist. (I'd have no idea
+how to Google for such a thing, as one has no idea of what it is called.)
+
+>AdaMagic does the right thing here.  I'd be happy to provide the algorithm.
+>It is based on the notion of "continued fractions" I believe.  I 
+>recently analyzed supporting fixed point in our code generator for 
+>Simulink, and wrote up the algorithms in a short document.
+
+I have the additional problem of having to do it in a shared generic. It is
+completely impossible to make completely accurate conversions to universal 
+fixed in that environment, so the algorithm has to use only integers and the
+(base of the) target fixed point type. (In general, universal fixed 
+conversions are inaccurate, see Annex G, so any truly usage algorithm for Ada
+has to avoid anything like that; it's not 100% a problem with shared generics.
+That rules out fixed-fixed multiplies and divides. Not sure if that is 
+possible.)
+
+****************************************************************

Questions? Ask the ACAA Technical Agent