--- ai12s/ai12-0208-1.txt 2018/06/12 05:28:47 1.9 +++ ai12s/ai12-0208-1.txt 2018/06/15 00:37:45 1.10 @@ -1,4 +1,7 @@ -!standard A.20(0) 18-03-28 AI12-0208-1/02 +!standard A.5.5(0) 18-06-13 AI12-0208-1/03 +!standard A.5.6(0) +!standard A.5.7(0) +!standard A.5.8(0) !class Amendment 16-12-19 !status work item 16-12-19 !status received 16-09-27 @@ -30,7 +33,9 @@ The package Ada.Numerics.Big_Numbers has the following declaration: - package Ada.Numerics.Big_Numbers is + package Ada.Numerics.Big_Numbers + with Pure, Nonblocking + is type Number is Interface; function "=" (L, R : Number) return Boolean is abstract; @@ -53,27 +58,20 @@ function Max (L, R : Number) return Number is abstract; end Ada.Numerics.Big_Numbers; -[TBD: aspects specified for this package? Pure, Nonblocking, others? -Same question applies to other packages declared in later sections. -Would these aspects constrain implementations in undesirable ways?] - -[TBD: It would be nice to use subtypes in parameter profiles (e.g., -a Nonzero_Number subtype for second argument of "/", but this requires -AI12-0243 and the future of that AI is very uncertain.] +A.5.6 Big Integers -A.5.5.1 Big Integers - The package Ada.Numerics.Big_Numbers.Big_Integers has the following definition: - package Ada.Numerics.Big_Numbers.Big_Integers is + package Ada.Numerics.Big_Numbers.Big_Integers + with Preelaborate, Nonblocking + is type Big_Integer is new Number with private with Default_Initial_Condition => Big_Integer = 0, Integer_Literal => From_String; -[TBD: Remove Integer_Literal aspect spec if AI12-0249-1 not approved. -If Default_Initial_Condition AI12-0265-1 is approved and Integer_Literal AI is -not then replace "0" with "+0" in the condition and as needed in -subsequent conditions.] +[TBD: Remove Integer_Literal aspect spec if AI12-0249-1 not approved; +also replace "0" with "+0" in the default initial condition +and as needed in other conditions in order to get legal specs.] overriding function "=" (L, R : Big_Integer) return Boolean; overriding function "<" (L, R : Big_Integer) return Boolean; @@ -83,7 +81,7 @@ overriding function "+" (Arg : Integer) return Big_Integer; function To_Big_Integer (Arg : Integer) return Big_Integer renames "+"; - + subtype Big_Positive is Big_Integer with Dynamic_Predicate => Big_Positive > 0, Predicate_Failure => (raise Constraint_Error); @@ -91,14 +89,14 @@ subtype Big_Natural is Big_Integer with Dynamic_Predicate => Big_Natural >= 0, Predicate_Failure => (raise Constraint_Error); - - function In_Range (Arg, Lo, Hi : Big_Integer) return Boolean is - ((Lo <= Arg) and (Arg <= Hi)); -[TBD: In_Range formal parameter names. "Lo & Hi" vs. "Low & High"?] + function In_Range (Arg, Low, High : Big_Integer) return Boolean is + ((Low <= Arg) and (Arg <= High)); function To_Integer (Arg : Big_Integer) return Integer - with Pre => In_Range (Arg, Lo => +Integer'First, Hi => +Integer'Last) + with Pre => In_Range (Arg, + Low => +Integer'First, + High => +Integer'Last) or else (raise Constraint_Error); generic @@ -107,8 +105,8 @@ function To_Big_Integer (Arg : Int) return Big_Integer; function From_Big_Integer (Arg : Big_Integer) return Int with Pre => In_Range (Arg, - Lo => To_Big_Integer (Int'First), - Hi => To_Big_Integer (Int'Last)) + Low => To_Big_Integer (Int'First), + High => To_Big_Integer (Int'Last)) or else (raise Constraint_Error); end Signed_Conversions; @@ -118,8 +116,8 @@ function To_Big_Integer (Arg : Int) return Big_Integer; function From_Big_Integer (Arg : Big_Integer) return Int with Pre => In_Range (Arg, - Lo => To_Big_Integer (Int'First), - Hi => To_Big_Integer (Int'Last)) + Low => To_Big_Integer (Int'First), + High => To_Big_Integer (Int'Last)) or else (raise Constraint_Error); end Unsigned_Conversions; @@ -155,11 +153,12 @@ The other functions have their usual mathematical meanings. -[TBD: GCD should return Big_Positive, not Big_Integer, if AI12-0243 +[TBD: GCD should return Big_Positive, not Big_Integer, if AI12-0243-1 somehow allows this.] -A.5.5.1.1 Bounded Big Integers +A.5.7 Bounded Big Integers + An instance of the language-defined generic package Numerics.Big_Numbers.Bounded_Big_Integers provides a Big_Integer type and operations corresponding to those declared in @@ -171,10 +170,18 @@ generic Capacity : Natural; - package Ada.Numerics.Big_Numbers.Bounded_Big_Integers is + package Ada.Numerics.Big_Numbers.Bounded_Big_Integers + with Pure, Nonblocking + is <all the same visible declarations as those in Big_Numbers.Big_Integers, - including declaration of Bounded_Big_Integers.Big_Integer type> + including declaration of Bounded_Big_Integers.Big_Integer type; however + the partial view of Bounded_Big_Integers.Big_Integer type includes + a type invariant specification, + Type_Invariant => + In_Range (Bounded_Big_Integer, First, Last) + or else (raise Constraint_Error) + > function Last return Big_Integer is ((+256) ** Capacity); function First return Big_Integer is (-Last); @@ -187,13 +194,6 @@ would fail the test In_Range (R, First, Last). This includes the streaming operations Big_Integer'Read and Big_Integer'Input. -AARM Note: Roughly speaking, behavior is as if the type invariant for -Bounded_Big_Integer is - In_Range (Bounded_Big_Integer, First, Last) or else (raise Constraint_Error) -although that is not specified explicitly because that would -require introducing some awkward code in order to avoid infinite -recursion. - Implementation Requirements For each instance of Bounded_Big_Integers, the output generated by @@ -206,48 +206,48 @@ Implementation Advice The implementation of (an instance of) Bounded_Big_Integers should not -make use of controlled types or dynamic allocation. +make use of controlled types or dynamic allocation. [end of Implementation Advice] -The generic unit Ada.Numerics.Big_Numbers.Bounded_Big_Integers.Conversions +The generic unit Ada.Numerics.Big_Numbers.Conversions provides operations for converting between the Big_Integer types declared in Big_Numbers.Big_Integers and in an instance of Big_Numbers.Bounded_Big_Integers. -The generic package Ada.Numerics.Big_Numbers.Bounded_Big_Integers.Conversions +The generic package Ada.Numerics.Big_Numbers.Conversions has the following definition: with Ada.Numerics.Big_Numbers.Big_Integers; + with Ada.Numerics.Big_Numbers.Bounded_Big_Integers; generic - package Ada.Numerics.Big_Numbers.Bounded_Big_Integers.Conversions is + with package Bounded is new Bounded_Big_Integers (<>); + package Ada.Numerics.Big_Numbers.Conversions + with Preelaborate, Nonblocking + is function From_Unbounded - (Arg : Big_Integers.Big_Integer) return Big_Integer; + (Arg : Big_Integers.Big_Integer) return Bounded.Big_Integer; function To_Unbounded - (Arg : Big_Integer) return Big_Integers.Big_Integer; - end Ada.Numerics.Big_Numbers.Bounded_Big_Integers.Conversions; + (Arg : Bounded.Big_Integer) return Big_Integers.Big_Integer; + end Ada.Numerics.Big_Numbers.Conversions; -AARM Note:This unit is declared as a child unit because we don't want -Big_Integers to be in the closure of Bounded_Big_Integers. It is a generic -package because its parent cannot have a non-generic child unit. - -[TBD: This could be done differently by using a formal instance instead -of declaring the Conversions package as a child of Bounded_Big_Integers. -Would there be any advantage to this approach? The advantage of the -proposed approach is visibility of the private part, but it does seem -awkward to have a generic with no generic formals and no local state.] +A.5.8 Big Rationals -A.5.5.2 Big Rationals - The package Ada.Numerics.Big_Numbers.Big_Rationals has the following definition: with Ada.Numerics.Big_Numbers.Big_Integers; - package Ada.Numerics.Big_Numbers.Big_Rationals is + package Ada.Numerics.Big_Numbers.Big_Rationals + with Preelaborate, Nonblocking + is use Big_Integers; type Big_Rational is new Number with private Default_Initial_Condition => Big_Rational = 0.0, - Real_Literal => From_String; + Real_Literal => From_String, + Type_Invariant => (Big_Rational = 0.0) or else + (Greatest_Common_Divisor + (Numerator (Big_Rational), + Denominator (Big_Rational)) = 1); function "/" (Num, Den : Big_Integer) return Big_Rational with Pre => (Den /= 0) or else (raise Constraint_Error); @@ -287,10 +287,10 @@ propagated in error cases. The other functions have their usual mathematical meanings. -Any Big_Rational result R returned by any of these functions satisifies the +Any Big_Rational result R returned by any of these functions satisfies the condition (R = 0.0) or else - (Greatest_Common_Denominator (Numerator (R), Denominator (R)) = 1). + (Greatest_Common_Divisor (Numerator (R), Denominator (R)) = 1). AARM Note: No Bounded_Big_Rationals generic package is provided. @@ -1362,7 +1362,7 @@ > 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 @@ -1370,7 +1370,7 @@ Let's not have another "tampering" fiasco. -> If so, then we can use prefix notation on functions like Numerator and +> 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 @@ -1389,7 +1389,7 @@ 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? **************************************************************** @@ -1399,9 +1399,9 @@ > > 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 +> (efficiency-wise) with all sorts of other languages, and taggedness > will destroy that. ??? Tags (as opposed to controlled types) add almost no overhead, especially @@ -1423,26 +1423,26 @@ 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 +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 +> > 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 +> +> 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 +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. @@ -1451,7 +1451,7 @@ From: John Barnes Sent: Tuesday, January 30, 2018 4:22 AM -I am feverishly giving lectures on numbers at Oxford at the moment but I am +I am feverishly giving lectures on numbers at Oxford at the moment but I am trying to keep an eye on what the ARG is up to. Did you know that a new Mersenne prime was discovered on Boxing Day (26 @@ -1479,7 +1479,7 @@ -- Restructured using children--- n parent package +-- Types and No_Of_Places in parent package -- 20-10-06 @@ -1521,7 +1521,7 @@ function No_Of_Places(N: Number) return Integer is begin - if N.Length = 0 then + if N.Length = 0 then return 1; else return N.Length * Base_Exp; @@ -1772,16 +1772,16 @@ declare -- initialise limits and length of cycle Z_Index: Index; Y_Index: Index; - Initial_Z_Index: Index := Y.Length + 1; - Initial_Y_Index: Index := 1; - Cycle_Length: Index := 1; + Initial_Z_Index: Index := Y.Length + 1; + Initial_Y_Index: Index := 1; + Cycle_Length: Index := 1; begin Carry := 0; for I in 1 .. ZL loop Digit := Carry; Carry := 0; - Z_Index := Initial_Z_Index; - Y_Index := Initial_Y_Index; + Z_Index := Initial_Z_Index; + Y_Index := Initial_Y_Index; for J in 1 .. Cycle_Length loop if Digit > Base_Squared then Digit := Digit - Base_Squared; @@ -1942,13 +1942,13 @@ U0 := Double(U.D(I)); U.D(I) := Single(QD); QStart := QStart - 1; end loop; - + -- delete possible leading zero in quotient if U.D(HIQ) = 0 then QL := QL - 1; end if; - - -- copy remainder into place and scale + + -- copy remainder into place and scale -- top digit is in U0 still Digit := U0; for I in reverse 2 .. RL loop @@ -2290,7 +2290,7 @@ begin Div(X, Y, Q, R); if (X < Zero and Y > Zero) or (X > Zero and Y < Zero) then - R := R + Y; + R := R + Y; end if; return R; end "mod"; @@ -2380,7 +2380,7 @@ To_Integer(N, Result); return Result; end Integer_Of; - + end Numbers.Func; @@ -2449,7 +2449,7 @@ Is_Prime: Boolean; MM: Number(50); - Primes: array(1 .. Nop) of Integer := + Primes: array(1 .. Nop) of Integer := (3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59, 61,67,71,73,79,83,89,97,101,103,107,109,113,127); @@ -2462,7 +2462,7 @@ Is_Prime: out Boolean) is Two: Number(1); - M: Number(Mersenne.Max_Digits); + M: Number(Mersenne.Max_Digits); L, W, Quotient: Number(M.Max_Digits*2); begin To_Number(2, Two); @@ -2486,7 +2486,7 @@ S: String(1 .. 45); begin To_Text(X, S); - Put(S); + Put(S); end Put; begin @@ -2529,7 +2529,7 @@ Is_Prime: Boolean; LL, MM: Number; - Primes: array(1 .. Nop) of Integer := + Primes: array(1 .. Nop) of Integer := (3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59, 61,67,71,73,79,83,89,97,101,103,107,109,113,127); @@ -2543,7 +2543,7 @@ Is_Prime: out Boolean) is Two: constant Number := Make_Number(2); - M: constant Number := Two**Q - One; + M: constant Number := Two**Q - One; L: Number := Make_Number(4); begin for I in 1 .. Q-2 loop @@ -2600,7 +2600,7 @@ G, H: CNumber; XX, YY, QQ, ZZ: CNumber; Two: CNumber; - N: Cnumber; + N: Cnumber; Start, Stop: Integer; procedure GCD(X, Y: CNumber; Z: out CNumber) is @@ -2671,7 +2671,7 @@ Put(Z); New_Line(2); end Test7; - + **************************************************************** From: Jeff Cousins @@ -2724,20 +2724,20 @@ package body Squares is begin - + -- make Poss_Last_Digits array for I in 1 .. Square_Ten_Power loop Poss_Last_Digits(I*I mod Square_Ten_Power) := True; end loop; -end Squares; - +end Squares; + with Numbers.Func; use Numbers.Func; -- with Monitor; procedure Square_root(XX: in Number; Try: Number; X: out Number; R: out Number) is -- X is the largest X such that X*X + R equals XX with R >= zero - -- Try is initial guess + -- Try is initial guess K, KK: Number; DK: Number; Three: Number := Make_Number(3); @@ -2750,7 +2750,7 @@ if abs DK < Three then -- nearly there if XX < KK then K := XX/K; -- ensure K*K is less than XX - end if; + end if; exit; end if; -- do another iterate @@ -2763,7 +2763,7 @@ loop KK := K*K; -- Monitor.C2 := Monitor.C2 + 1; - if KK >= XX then + if KK >= XX then if KK = XX then X := K; R := Zero; return; end if; @@ -2795,8 +2795,8 @@ Last_Digits: Integer; Try: Number := One; Max_square : Number := (N/Min_Prime + Min_Prime)/ Two + Two; + - begin Square_Root(N, One, X, R); @@ -2858,11 +2858,11 @@ T_Start, T_End: Time; package Duration_IO is new Fixed_IO(Duration); use Duration_IO; -begin +begin Put_Line("Welcome to Fermat's method (multilength)"); loop <<Again>> - Begin + Begin New_Line; Put("Insert number N = "); Get(NN); exception @@ -2888,14 +2888,14 @@ if nN rem Make_number(4) = Make_Number(2) then - Put_Line("Algorithm fails on odd multiples of 2, so halving N"); + Put_Line("Algorithm fails on odd multiples of 2, so halving N"); NN := NN/Make_Number(2); Put("New N = "); Put(NN, 0); New_Line; end if; if NN = One then Put_Line("all factors removed"); else - + -- Monitor.C1 := 0; -- Monitor.C2 := 0; -- Monitor.C3 := 0; @@ -2957,7 +2957,7 @@ The types are tagged now and descended from a common interface type. This means that most parameter subtypes have to be first named subtypes. -This should not be considered an endorsement of this idea; we might (as Bob +This should not be considered an endorsement of this idea; we might (as Bob suggests) want these types to be untagged. It's just easier to see what this looks like and then have to imagine what the untagged version might be than the other way around. I agree with Randy's comments that taggedness by itself @@ -2977,7 +2977,7 @@ From: Randy Brukardt Sent: Thursday, March 1, 2018 9:49 PM -> I'm attaching some preliminary specs that reflect the feedback from +> I'm attaching some preliminary specs that reflect the feedback from > the last discussion of this set of predefined packages. ... > Comments? @@ -2996,23 +2996,23 @@ From: Steve Baird Sent: Sunday, March 4, 2018 1:00 AM -> Shouldn't this be some set of children of Ada.Numerics? These kinda +> Shouldn't this be some set of children of Ada.Numerics? These kinda > seem like numbers.;-) -> +> Good point. So the root package for this stuff becomes Ada.Numerics.Big_Numbers. -> You don't have the numeric literal definitions (see AI12-0249-1) -- -> that seems necessary for usability. (One wonders if the literals -> should be defined on g interface, which suggests that AI12-0249-1 +> You don't have the numeric literal definitions (see AI12-0249-1) -- +> that seems necessary for usability. (One wonders if the literals +> should be defined on g interface, which suggests that AI12-0249-1 > needs a bit of > extension.) We decided earlier that we didn't want that inter-AI dependency. -But I agree that if we we are willing to introduce that dependency then of +But I agree that if we we are willing to introduce that dependency then of course support for literals would make sense. Should it be conditional, as in "if AI12-0249 is approved, then this AI also @@ -3043,7 +3043,7 @@ Sent: Thursday, March 29, 2018 7:48 PM > Attached is proposed wording for this AI. -> +> > There are some TBDs interspersed. Here's a few thoughts: @@ -3150,39 +3150,39 @@ >> Attached is proposed wording for this AI. >> >> There are some TBDs interspersed. -> +> > Here's a few thoughts: -> +> >> [TBD: aspects specified for this package? Pure, Nonblocking, others? >> Same question applies to other packages declared in later sections. >> Would these aspects constrain implementations in undesirable ways?] -> +> > All of the packages should be nonblocking. I don't think any reasonable > implementation would need access to delay statements. ;-) -> +> Sounds good. > The interface package should be Pure (why not, it doesn't have any > implementation). The bounded package also should be pure (we do that for all > of the bounded forms elsewhere. -> +> > The others probably should be preelaborated (and the types having > preelaborable_initialization), lest we make it too hard to use the needed > dynamic allocation. -> +> Also sounds good. >> [TBD: It would be nice to use subtypes in parameter profiles (e.g., >> a Nonzero_Number subtype for second argument of "/", but this requires >> AI12-0243 and the future of that AI is very uncertain.] -> +> > You can always use a Pre'Class as an alternative to a subtype. It's not > quite as convenient, but it makes the same check, and presuming that > AI12-0112-1 stays are currently envisioned, that check would be suppressible > with "pragma Suppress (Numerics_Check);". -> +> Let's leave things as I originally proposed for now, with a possible revision if AI12-0243 is approved. @@ -3192,28 +3192,28 @@ > is >> not then replace "0" with "+0" in the condition and as needed in >> subsequent conditions.] -> +> > I put the AI number in here for Default_Initial_Condition. -> +> Thanks. >> [TBD: In_Range formal parameter names. "Lo & Hi" vs. "Low & High"?] -> +> > Ada usually doesn't use abbreviations, and saving one or two characters this > way isn't appealing. Use Low and High. -> +> You convinced me. Sounds good. >> A.5.5.1.1 Bounded Big Integers -> +> > Umm, please, no 5 level subclauses. Since there are currently no four level > items in the RM, we need to discuss that explicitly. I had to add a fourth > level for ASIS, but Ada only uses three levels. And the ACATS only uses two > levels in the annexes, which is already a problem for the containers (there > being only one set of sequence numbers for all of the containers tests). -> +> What would you suggest instead? @@ -3224,7 +3224,7 @@ >> although that is not specified explicitly because that would >> require introducing some awkward code in order to avoid infinite >> recursion. -> +> > Awkward code? Please explain. Type invariants are explicitly not enforced on > 'in' parameters of functions specifically to avoid infinite recursion in the > type invariant expression. You'd probably need a function for this purpose @@ -3236,23 +3236,23 @@ Ok, we can make this type invariant explicit. -> +> >> [TBD: This could be done differently by using a formal instance instead >> of declaring the Conversions package as a child of Bounded_Big_Integers. >> Would there be any advantage to this approach? The advantage of the >> proposed approach is visibility of the private part, but it does seem >> awkward to have a generic with no generic formals and no local state.] -> +> > Well, it would be easier to implement in Janus/Ada, where we never got > sprouting to work. But that's hardly a reason. I suspect it would be more > obvious what's going on than a generic child -- as a data point, all of the > extra operations of Ada.Strings.Bounded take formal packages rather than > being children -- but that may have been driven by other considerations. -> +> > One argument for making it a formal package is that this conversion package > really belongs to both big number packages -- it's somewhat artificial to > make it live in the hierarchy of one or the other. -> +> I don't see any real strong arguments one way or the other here (it would probably be ok to settle this one with a coin-flip) @@ -3263,17 +3263,17 @@ >> condition >> (R = 0.0) or else >> (Greatest_Common_Denominator (Numerator (R), Denominator (R)) = 1). -> +> > Arguably, that should be a postcondition, since the implementation isn't > required to check it (it it required to *pass* it). Then a separate rule > isn't needed. You'd probably want to declare a function with this meaning, > 'cause duplicating the above 2 dozen times would be annoying. -> +> Ok, let's make the postconditions explicit. >> AARM Note: No Bounded_Big_Rationals generic package is provided. -> +> > We've discussed why, but there needs to be a version of that discussion > either in this note or in the (sadly empty) !discussion section. Future > readers will be puzzled otherwise (including, most likely, us). @@ -3292,21 +3292,21 @@ ... > >> A.5.5.1.1 Bounded Big Integers -> > -> > Umm, please, no 5 level subclauses. Since there are currently no -> > four level items in the RM, we need to discuss that explicitly. I -> > had to add a fourth level for ASIS, but Ada only uses three levels. -> > And the ACATS only uses two levels in the annexes, which is already -> > a problem for the containers (there being only one set of sequence +> > +> > Umm, please, no 5 level subclauses. Since there are currently no +> > four level items in the RM, we need to discuss that explicitly. I +> > had to add a fourth level for ASIS, but Ada only uses three levels. +> > And the ACATS only uses two levels in the annexes, which is already +> > a problem for the containers (there being only one set of sequence > > numbers for all of the containers tests). -> +> > What would you suggest instead? There aren't any great answers here. If you want to keep these in with the other numerics packages, then I think -you need a flat organization: A.5.5 Big Integer Interface, A.5.6 Unbounded -Big Integers A.5.7 Bounded Big Integers etc. That's how the queues are +you need a flat organization: A.5.5 Big Integer Interface, A.5.6 Unbounded +Big Integers A.5.7 Bounded Big Integers etc. That's how the queues are organized, after all, they have the same issue. Alternatively, given that this is a substantial subsystem unto itself, you @@ -3316,7 +3316,7 @@ A.20.3 Bounded Big Integers etc. ... -> Do we want revised wording incorporating what we have discussed here +> Do we want revised wording incorporating what we have discussed here > for Lisbon? Always best to have the latest into the actual AI. Otherwise, we end up saying @@ -3340,10 +3340,10 @@ From: John Barnes Sent: Monday, June 11, 2018 2:00 AM -I thought I had recently is that it would be handy to have a subprogram that +I thought I had recently is that it would be handy to have a subprogram that did square root. Given input parameter x and two out parameters. For positive -x, It would return the largest integer whose square is not greater than the -parameter and a separate remainder. +x, It would return the largest integer whose square is not greater than the +parameter and a separate remainder. Could be a procedure or a function with the remainder as an out parameter. @@ -3354,17 +3354,76 @@ From: Randy Brukardt Sent: Monday, June 11, 2018 9:23 PM -Is there any particular reason that ought to be in the BigNum library rather -than a package implemented using BigNum? (I recall we have a bunch test +Is there any particular reason that ought to be in the BigNum library rather +than a package implemented using BigNum? (I recall we have a bunch test programs for the Janus/Ada UnivMath that do things like calculate square roots and E [until you run out memory!].) There doesn't appear to be any -implementation that would take special advantage of the implementation +implementation that would take special advantage of the implementation details of a BigNum. -One could imagine having the entire set of GEF operations available, but -those surely would want to be in a separate package to keep things -manageable. And defining that might be just too much work for Ada 2020 +One could imagine having the entire set of GEF operations available, but +those surely would want to be in a separate package to keep things +manageable. And defining that might be just too much work for Ada 2020 (only 9 months to go!) - + **************************************************************** +From: John Barnes +Sent: Tuesday, June 12, 2018 3:52 AM + +When I implemented sqrt for big integers I did indeed just use the normal +visible operations in the number package. However, it was slow and I just +wondered whether it could be speeded up by knowing the implementation details +and taking short cuts. However, I suppose it might apply to other maths ops as +well. Best solution might be to put such things in a child. We could leave +that to 2028 I suppose (I might not be around). I could ask the maths people +(NAG) at Oxford. One of the old Ada blokes from Alsys in Henley works for NAG. + +See you in Lisbon. + +**************************************************************** + +From: Steve Baird +Sent: Wednesday, June 13, 2018 6:37 PM + +>> Do we want revised wording incorporating what we have discussed here +>> for Lisbon? +> Always best to have the latest into the actual AI. + +I think the attached is just the result of incorporating what we discussed. +[This is version /03 of the AI - Editor.] + +The one exception is that I used a type invariant to express the idea that the +GCD of the numerator and denominator of a non-zero big real is always one. + +**************************************************************** + +From: Randy Brukardt +Sent: Thursday, June 14, 2018 7:13 PM + +> I think the attached is just the result of incorporating what we +> discussed. + +Looks good. I fixed a couple of typos (missing "-1" on AI numbers, missing +";" at the end of your new type invariant). + +Do we still need the text: + +Any Big_Rational result R returned by any of these functions satisifies the condition + (R = 0.0) or else + (Greatest_Common_Divisor (Numerator (R), Denominator (R)) = 1). + +since it is essentially just restating the Type_Invariant. (The spelling of +"satisfies" is interesting, too. ;-) + +> The one exception is that I used a type invariant to express the idea +> that the GCD of the numerator and denominator of a non-zero big real +> is always one. + +You would use the least used of the contracts. ;-) I note that the new +ObjectAda doesn't include Type_Invariants (and I don't have any plans to +implement them in Janus/Ada, either). But that's hardly a good reason to not +use something when it is appropriate. (I'd probably turn it into a +postcondition for Janus/Ada.) + +****************************************************************

Questions? Ask the ACAA Technical Agent