--- 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