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

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

--- ai12s/ai12-0208-1.txt	2019/01/05 02:34:52	1.15
+++ ai12s/ai12-0208-1.txt	2019/01/08 06:27:03	1.16
@@ -4925,3 +4925,839 @@
 
 ****************************************************************
 
+From: John Barnes
+Sent: Monday, December 10, 2018   4:31 PM
+
+Reading some more BigNum. I hadn't expected to cover rationals as well as 
+integers but seems an interesting idea. 
+
+I see that the type invariant ensures that they are reduced so that the gcd 
+is always 1. In the type invariant it says (Big_Rational = 0.0) ...
+
+How does that 0.0 work?  I assume there is an AI that covers the use of 
+literals in that context that I have missed.
+
+And generally where does Is_Valid come from?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, December 10, 2018   5:30 PM
+
+Do you have to send this base64 stuff? See here:
+
+> DQpSZWFkaW5nIHNvbWUgbW9yZSBCaWdOdW0uIEkgaGFkbid0IGV4cGVjdGVkIHRvIGNvdmVyIHJh 
+> dGlvbmFscyBhcyB3ZWxsIGFzIGludGVnZXJzIGJ1dCBzZWVtcyBhbiBpbnRlcmVzdGluZyBpZGVh 
+> LiANCg0KSSBzZWUgdGhhdCB0aGUgdHlwZSBpbnZhcmlhbnQgZW5zdXJlcyB0aGF0IHRoZXkgYXJl 
+> IHJlZHVjZWQgc28gdGhhdCB0aGUgZ2NkIGlzIGFsd2F5cyAxLiBJbiB0aGUgdHlwZSBpbnZhcmlh 
+> bnQgaXQgc2F5cyAoQmlnX1JhdGlvbmFsID0gMC4wKSAuLi4NCg0KSG93IGRvZXMgdGhhdCAwLjAg 
+> d29yaz8gIEkgYXNzdW1lIHRoZXJlIGlzIGFuIEFJIHRoYXQgY292ZXJzIHRoZSB1c2Ugb2YgbGl0 
+> ZXJhbHMgaW4gdGhhdCBjb250ZXh0IHRoYXQgSSBoYXZlIG1pc3NlZC4NCg0KQW5kIGdlbm
+> VyYWxs eSB3aGVyZSBkb2VzIElzX1ZhbGlkIGNvbWUgZnJvbT8NCg0KSm9obg0K
+
+Anyway:
+
+> How does that 0.0 work?  I assume there is an AI that covers the use 
+> of literals in that context that I have missed.
+
+That's AI12-0249-1, User-defined literals.  And note the "Real_Literal => ..." 
+on the type decl.
+
+Randy, I suppose that should be "User-defined numeric literals",
+                                              ^^^^^^^ since we decided to split off:
+
+AI12-0295-1.TXT : !subject User-defined string literals 
+AI12-0296-1.TXT : !subject User-defined character and null literals
+
+> And generally where does Is_Valid come from?
+
+That's a function declared in the package.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, December 10, 2018   5:45 PM
+
+> Do you have to send this base64 stuff? See here:
+
+John will have to answer that, but I'll point out that when doing so, the 
+list footers get trashed, the messages get delayed (because of encoding 
+issues), and I've seen messages that show up blank in people's inboxes 
+(luckily, that hasn't happened yet with John's messages). So I hope he can 
+find a way to turn it off when sending to ARG.
+
+...
+> Randy, I suppose that should be "User-defined numeric literals",
+
+It was that for a while, but it seems to have disappeared in the posted 
+version. Not sure why (hopefully nothing else important disappeared - this 
+sometimes happens when I manage to open two copies of a file and put some of
+the mods in one copy and some in the other). I note that the clause title 
+remains "User-Defined Literals", as we did approve the string literals as well 
+(just in a separate AI).
+
+****************************************************************
+
+From: John Barnes
+Sent: Tuesday, December 11, 2018   5:08 AM
+
+>> How does that 0.0 work?  I assume there is an AI that covers the use 
+>> of literals in that context that I have missed.
+
+>That's AI12-0249-1, User-defined literals.  And note the "Real_Literal 
+>=> ..." on the type decl.
+
+I would expect the literal for a rational number to be something like 23/55. 
+And in this case 0/1 or just plain 0 rather than 0.0
+
+****************************************************************
+
+From: John Barnes
+Sent: Saturday, December 15, 2018   8:55 AM
+
+Hmm. But Real_Literal aspect says From_String so I would have expected "0.0".
+
+In any case it is surely asking for trouble to use a real_literal as a literal
+for a rational number. Is there not a way of expressing that the literal 
+should be of the form integer_literal/integer_literal?
+
+Sorry I have got years behind in following this largely because of 1) maths at 
+Oxford, 2) getting old, 3)Brexit.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, December 15, 2018  10:21 AM
+
+> Hmm. But Real_Literal aspect says From_String so I would have expected 
+> "0.0".
+
+Yes.
+
+> In any case it is surely asking for trouble to use a real_literal as a 
+> literal for a rational number.
+
+Why is that?  Every real_literal can be represented exactly as a Big_Integer, 
+so I don't see the "trouble".
+
+>... Is there not a way of expressing that  the literal should be of the 
+>form integer_literal/integer_literal?
+
+You can write 1/3, because of this:
+
+      function "/" (Num, Den : Valid_Big_Integer) return Valid_Big_Rational
+        with Pre => (Den /= 0) or else (raise Constraint_Error);
+
+But 1/3 is not a literal, it's two Big_Integer literals and a division.
+I think we'll train GNAT to evaluate that at compile time.
+
+We also have this:
+
+      function "/" (L, R : Valid_Big_Rational) return Valid_Big_Rational;
+
+which allows 1.0/3.0, or 123.456/7.89 .
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, December 15, 2018  10:30 AM
+
+Another suggestion:
+
+Change Ada.Numerics.Big_Numbers to Ada.Big_Numbers.
+I think "numerics" (short for "numerical analysis") generally implies 
+"floating point" in computer science.
+
+https://en.wikipedia.org/wiki/Numerical_analysis
+
+    Numerical analysis is the study of algorithms that use numerical
+    approximation (as opposed to general symbolic manipulations) for the
+    problems of mathematical analysis (as distinguished from discrete
+    mathematics).
+
+And a shorter name is better, given that Numerics doesn't add any readability
+benefit.
+
+****************************************************************
+
+From: John Barnes
+Sent: Saturday, December 15, 2018   10:49 AM
+
+I don't see Numerics as  being short for Numerical analysis at all. In any 
+event it is possibly rather narrow-minded to think that numerics implies 
+approximations. I see numerics as being about all sorts of numbers. And it 
+just depends upon the field one is working in. It could be a finite field say 
+integers mod 4. 
+
+No I prefer leaving the package name alone. That's OK.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, December 15, 2018  10:53 AM
+
+Should Big_Rats have an operation for throwing away some precision?  Like 
+Round X to the nearest multiple of Y.  Or maybe the rounding should be 
+relative to the magnitude of X, or something like that.
+
+The purpose would be to shrink the size (not in terms of magnitude, but in 
+terms of memory use).
+
+****************************************************************
+
+From: John Barnes
+Sent: Saturday, December 15, 2018  11:03 AM
+
+>> In any case it is surely asking for trouble to use a real_literal as 
+>> a literal for a rational number.
+
+>Why is that?  Every real_literal can be represented exactly as a Big_Integer,
+>so I don't see the "trouble".
+
+Yes but the real trouble is that every rational number cannot be represented 
+as a real_literal. Note that 5/7 can be represented as a real literal by 
+7#0.5#. Bur one cannot do it with say 15/17.
+
+>>... Is there not a way of expressing that  the literal should be of 
+>>the form integer_literal/integer_literal?
+
+> You can write 1/3, because of this:
+
+    <  function "/" (Num, Den : Valid_Big_Integer) return Valid_Big_Rational
+     <   with Pre => (Den /= 0) or else (raise Constraint_Error);
+
+> But 1/3 is not a literal, it's two Big_Integer literals and a division.
+> I think we'll train GNAT to evaluate that at compile time.
+
+I see 1/3 as the obvious  literal form of a rational number. 
+
+> We also have this:
+
+     > function "/" (L, R : Valid_Big_Rational) return Valid_Big_Rational;
+
+>which allows 1.0/3.0, or 123.456/7.89 .
+
+And that is really disgusting. As Bad as Brexit!!
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, December 15, 2018  11:56 AM
+
+> Yes but the real trouble is that every rational number cannot be 
+> represented as a real_literal.
+
+True.
+
+But that causes trouble for To_String (solved with the Fore/Aft/Exp kludgery).
+
+But when you write a literal in your program, you're going the other 
+direction, so it doesn't matter that it's impossible to write a literal for 
+every rational number.
+It still makes sense to write 1.234_567 instead of 1_234_567/1_000_000.
+
+Or did I count the zeros wrong?  ;-)
+
+> I see 1/3 as the obvious  literal form of a rational number. 
+
+You can think of it that way if you like, but it is not any form of literal 
+allowed by Ada syntax.
+
+We could allow quoted literals:
+
+    X := "1/3";
+
+but I don't see the point of that.
+
+It's analogous to the fact that -1 (meaning negative one) is not a literal in 
+Ada.  It's a call to the unary minus op, passing the literal 1.
+
+In any case, you're free to always use the "/" notation.
+
+> > We also have this:
+> 
+>      > function "/" (L, R : Valid_Big_Rational) return 
+> Valid_Big_Rational;
+> 
+> >which allows 1.0/3.0, or 123.456/7.89 .
+> 
+> And that is really disgusting. As Bad as Brexit!!
+
+Not THAT bad.
+
+But anyway, it doesn't matter:
+
+    Patient: "Doctor, it hurts when I write disgusting things."
+
+    Doctor: "So don't do that."
+
+Shirley, you don't object to being able to divide rational numbers in general:
+
+    P (X / Y);
+
+****************************************************************
+
+From: Ben Brosgol
+Sent: Saturday, December 15, 2018  11:16 AM
+
+As I recall the history, the child package name "Numerics" was chosen as a 
+compromise, to avoid an Anglo-American dust-up over "Maths" versus "Math" as
+the name :-). It had nothing to do with an implication of numerical analysis
+ / floating point.
+
+In any event I agree with John.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, December 15, 2018  11:40 AM
+
+> I don't see Numerics as  being short for Numerical analysis at all.
+
+This web site:
+
+https://scicomp.stackexchange.com/tags/numerics/synonyms
+
+says "numerics" is a synonym of "numerical analysis".
+
+This:
+
+https://scicomp.stackexchange.com/questions/tagged/numerics
+
+has a bunch of questions tagged "numerics".  I didn't look carefully, but 
+most/all seem to be about floating point.
+
+These:
+
+https://www5.in.tum.de/lehre/vorlesungen/parnum/WS17/lecture_1.pdf
+https://math.temple.edu/~queisser/numerics-scientific-computing.html
+
+seem to use "numerics" and "numerical methods" synonymously.
+Are not "numerical analysis" and "numerical methods"
+more or less the same thing?
+
+> ... In any event it is possibly rather narrow-minded to think that 
+> numerics implies approximations. I see numerics as being about all 
+> sorts of numbers. And it just depends upon the field one is working 
+> in. It could be a finite field say integers mod 4.
+> 
+> No I prefer leaving the package name alone. That's OK.
+
+But anyway, my main objection is that the name is too long.
+If we move Big_Numbers out of Numerics, that doesn't imply it's NOT numerics.
+After all, Integer and Float are in Standard, not Numerics.
+
+Another suggestion:
+
+Ada.Numerics.Big_Integers
+Ada.Numerics.Big_Rationals
+
+And get rid of Big_Numbers, and move its content into Numerics.
+
+P.S. The course "Combinatorial Analysis" at CMU was commonly referred to as 
+"Combinatorics".  It was also called "Combinatorture", because it was hard. 
+How can the study of counting be hard?  ;-)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, December 15, 2018  11:40 AM
+
+> As I recall the history, the child package name "Numerics" was chosen 
+> as a compromise, to avoid an Anglo-American dust-up over "Maths" 
+> versus "Math" as the name :-).
+
+I would have been happier with Maths.  ;-)
+
+>... It had nothing to do with an implication of  numerical analysis / 
+>floating point.
+> 
+> In any event I agree with John.
+
+An argument in your favor is Ada.Numerics.Discrete_Random.
+That's the ONLY one that is not all about floating point.
+
+Ada has a well-deserved reputation for verbosity.
+That's often a good thing, but here it's just noise.
+
+What about my second suggestion for shortening the names?
+
+P.S. I shall attempt to refrain from further bikeshedding.
+Maybe others will weigh in, or we can have a straw poll.
+
+****************************************************************
+
+From: Ben Brosgol
+Sent: Saturday, December 15, 2018  1:53 PM
+
+>> As I recall the history, the child package name "Numerics" was chosen 
+>> as a compromise, to avoid an Anglo-American dust-up over "Maths" 
+>> versus "Math" as the name :-).
+> 
+> I would have been happier with Maths.  ;
+
+That might have been a fair trade for the American culturally imperialistic
+"Initialize" and "Finalize" spellings :-)
+
+>> ... It had nothing to do with an implication of numerical analysis / 
+>> floating point.
+>>
+>> In any event I agree with John.
+> 
+> An argument in your favor is Ada.Numerics.Discrete_Random.
+> That's the ONLY one that is not all about floating point.
+
+...and seems sufficient to debunk the claim that Numerics means 
+floating-point.
+
+> 
+> Ada has a well-deserved reputation for verbosity.
+> That's often a good thing, but here it's just noise.
+
+It reflects the logical categorization.
+
+> 
+> What about my second suggestion for shortening the names?
+
+If there are future standard packages related to integer or discrete 
+arithmetic, should these also come in as immediate children of Ada?  I think
+that Ada.Numerics is the logical parent for bignums as well as any such future
+packages.
+
+> P.S. I shall attempt to refrain from further bikeshedding.
+
+Right, no sense bikeshedding. Instead let's rearrange the deck chairs on the 
+Titanic(*) :-)
+
+> Maybe others will weigh in, or we can have a straw poll.
+
+(*)
+http://www.newsbiscuit.com/2011/02/15/rearranging-titanics-deckchairs-would-have-saved-1500-lives-say-researchers/
+[I assume that this is tongue-in-cheek :-)]
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, December 16, 2018  12:14 AM
+
+...
+> Change Ada.Numerics.Big_Numbers to Ada.Big_Numbers.
+> I think "numerics" (short for "numerical analysis") generally implies 
+> "floating point" in computer science.
+...
+> And a shorter name is better, given that Numerics doesn't add any 
+> readability benefit.
+
+Ada has a tradition of having a small number of 2nd-level root packages, 
+with almost everything else built on top of that: Ada.Characters, 
+Ada.Strings, Ada.Containers. 
+
+(Aside: Ada 95 clearly messed up the IO packages here, there should have 
+been Ada.IO (contents of IO_Exceptions), with Ada.IO.Text, 
+Ada.IO.Sequential, Ada.IO.Direct, etc. The renames could have still used 
+the old names. I don't remember, perhaps this was proposed but rejected as
+a bridge too far at the time? The whole idea of child packages was new then, 
+it's kinda taken over since.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, December 16, 2018  12:19 AM
+
+...
+> Ada has a well-deserved reputation for verbosity.
+> That's often a good thing, but here it's just noise.
+
+Not necessarily. My model for suppressing language-defined preconditions is 
+that is available on a per-subsystem basis (we don't want too many of these 
+check names). "Big_Numbers" isn't important enough to be a subsystem by 
+itself, I would say.
+
+Besides, if there ever was a package that would be "used", it's Big_Integer.
+Even I would "use" that package (and I won't even "use"
+Ada.Strings.Unbounded). So the name is nearly irrelevant; I'd be more worried 
+about having to write Ada.Unchecked_Deallocation all over the place.
+(Which we already do...)
+
+****************************************************************
+
+From: John Barnes
+Sent: Saturday, December 15, 2018  11:16 AM
+
+>Should Big_Rats have an operation for throwing away some precision?
+
+I see the whole purpose of working with rationals to be precise. It wouldn't 
+make sense to me to throw accuracy away. Encryption/Decryption wouldn't work 
+if you chucked bits away.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, December 15, 2018  12:16 PM
+
+> I see the whole purpose of working with rationals to be precise.
+
+That's the main purpose.
+
+But you might want much-higher precision than the biggest floating-point type,
+but still not exact precision. If you can't throw away precision, repeated 
+calculations can use up memory without bound.
+
+> ...It wouldn't make sense to me to throw accuracy away. 
+> Encryption/Decryption wouldn't work if you chucked bits away.
+
+Encryption can use Big_Integers, not Big_Rationals.
+Here I'm talking only about Big_Rationals.
+
+Actually, encryption wants to use Bounded_Big_Integers, except it wants 
+modular arithmetic.  Hmm.  Maybe we should provide such (functions that take 
+a Modulus param).
+
+...which leads me to question:
+
+   - Bounded_Big_Integers is a generic package and takes a generic formal:
+        Capacity : Natural;
+
+I think we agreed Capacity should be a discrim.
+
+   - two additional visible expression functions are declared:
+      function Last return Valid_Big_Integer is ((+256) ** Capacity);
+      function First return Valid_Big_Integer is (-Last);
+
+Why 256?  You want it to have an array of word-sized super-digits, not 
+byte-sized ones.  And this is the first time Ada is biased against (say) 
+36-bit machines.
+
+   - the partial view of Bounded_Big_Integers.Big_Integer includes
+     a type invariant specification,
+       Type_Invariant =>
+          (if Is_Valid (Bounded_Big_Integer) then
+             In_Range (Bounded_Big_Integer, First, Last)
+             or else (raise Constraint_Error))
+
+How does that work?  You can't compute numbers bigger than Last (because they 
+can't be represented) and then check that they're <= Last.
+
+And there's confusion about the type name -- is it Big_Integer or 
+Bounded_Big_Integer?
+
+And doesn't Last check the invariant, causing infinite recursion?
+
+Lots of evidence here that we should standardize existing practice!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, December 16, 2018  12:36 AM
+
+> > I see the whole purpose of working with rationals to be precise.
+> 
+> That's the main purpose.
+> 
+> But you might want much-higher precision than the biggest 
+> floating-point type, but still not exact precision.
+> If you can't throw away precision, repeated calculations can use up 
+> memory without bound.
+
+Yes, of course, that's the nature of the beast. Which of course is why memory
+has to be reclaimed. (Big_Integer alone being almost never necessary these
+days with 64-bit integers being available.)
+
+And whatever you do to try to minimize the use of such memory also has a 
+substantial cost. There's no free lunch here.
+
+...
+> Lots of evidence here that we should standardize existing practice!
+
+Is there any existing practice that would actually be suitable for the Ada 
+runtime? Most of it is in garbage collected interpreted languages, and hardly
+any languages actually worry about tasking/parallel operation.
+
+An Ada language-defined library:
+   * cannot leak memory (at least not in the long run);
+   * must be task safe (operations on different objects have to work concurrently);
+   * has to have a bounded option without allocated memory use;
+   * has to be strongly typed;
+   * has to be implementable in Ada (ideally, verified by SPARK).
+
+I'd also add something about performance, but that can't be quantified anyway.
+
+****************************************************************
+
+From: John Barnes
+Sent: Sunday, December 16, 2018   4:05 AM
+
+Waking up in the night and fretting about Brexit I thought I agreed with Bob
+that we should drop  Numerics since the big numbers and rationals are exact 
+and all the Numerics stuff was about rough old floating point. Then Ben 
+pointed out that random numbers are in numerics. So stuff it.
+
+But do something about that horrid literal 0.0. It has absolutely no place in 
+a big number or rational package. Maybe the user defined literals need to be 
+revisited. Maybe we don't need literals for Rationals anyway. 
+
+And big numbers are typically very big in my view. If you look in my book Nice 
+Numbers on pages 31 and 32 you will find some fairly big numbers. They have 
+about 400 digits. They were done by my little Ada 95 package that I wrote a 
+long long time ago.
+
+****************************************************************
+
+From: John Barnes
+Sent: Sunday, December 16, 2018   4:13 AM
+
+PS
+
+And I really think we should have a procedure that does division and returns 
+both quotient and remainder in one go to save wasting time doing the job 
+twice.
+
+Also, as I mentioned before I would like square root returning the largest 
+integer whose square is less than or equal to the integer operand and also
+returns the remainder. It's easy to write crudely but there are probably short
+cuts that would be useful.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, December 16, 2018  11:41 AM
+
+> And I really think we should have a procedure that does division and returns
+> both quotient and remainder in one go to save wasting time doing the job 
+> twice.
+
+Hear, Hear! This has been dearly missing since day 1.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, December 16, 2018   1:50 PM
+
+> And I really think we should have a procedure that does division and 
+> returns both quotient and remainder in one go to save wasting time 
+> doing the job twice.
+
+Seems reasonable.
+
+> Also, as I mentioned before I would like square root returning the 
+> largest integer whose square is less than or equal to the integer 
+> operand and also returns the remainder. It's easy to write crudely but 
+> there are probably short cuts that would be useful.
+
+But that one seems pretty specialized.  What would one use it for?
+
+By the way, "floor of square root" was an example exercise at the SPARK 
+training course I attended years ago.  The parameter is 0..System.Max_Int,
+and it's a little tricky to avoid overflow (and get SPARK to prove that you
+avoided overflow).  Fun example.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, December 16, 2018   1:50 PM
+
+> ... My model for suppressing language-defined preconditions is that is 
+> available on a per-subsystem basis...
+
+Reasonable argument.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, December 16, 2018   1:51 PM
+
+> > Lots of evidence here that we should standardize existing practice!
+>
+> Is there any existing practice that would actually be suitable for the 
+> Ada runtime?
+
+Not yet.  ;-)
+
+I meant we should have first created some existing practice.
+And then maybe standardize it.
+
+If AdaCore is willing to implement Big_Numbers, then great.
+If they're not, then we're wasting our time designing its spec.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, December 16, 2018   1:50 PM
+
+> (Aside: Ada 95 clearly messed up the IO packages here, there should 
+> have been Ada.IO (contents of IO_Exceptions), with Ada.IO.Text, 
+> Ada.IO.Sequential, Ada.IO.Direct, etc. The renames could have still 
+> used the old names. I don't remember, perhaps this was proposed but 
+> rejected as a bridge too far at the time?
+
+I don't remember that being proposed.
+
+If I were designing the I/O stuff from scratch, I would separate Output from 
+Input.  They're not just flip sides of each other.
+
+>... The whole idea of child packages was new then,  it's kinda taken 
+>over since.)
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Sunday, December 16, 2018   4:27 PM
+
+> If AdaCore is willing to implement Big_Numbers, then great.
+> If they're not, then we're wasting our time designing its spec.
+
+Why do you refer to adacore in the third person :-)?
+I think the algorithms in unintp and urealp are an excellent starting point 
+anyway, Robert used every trick described in Knuth 2 to make them efficient.
+
+iím certainly eager to start the implementation of 2020.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, December 16, 2018   4:48 PM
+
+> Why do you refer to adacore in the third person :-)?
+
+Because I'm not AdaCore.  ;-)
+
+I'm an employee of AdaCore, and I'm not in a position to dictate which 2020 
+features AdaCore should implement when, and who should do the work.  I can 
+make recommendations to AdaCore management, of course.
+
+> I think the algorithms in unintp and urealp are an excellent starting 
+> point anyway, Robert used every trick described in Knuth 2 to make 
+> them efficient.
+
+Whoever implements it should look at those for sure, plus the codepeer 
+implementation, and the libadalang implementation, and libgmp, and probably 
+others.
+
+I'm happy to do that, and Steve has also expressed an interest, and you would 
+also be a good candidate. But I can't just go and do that without explicit 
+direction from AdaCore management.
+
+> iím certainly eager to start the implementation of 2020.
+
+Indeed.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Sunday, December 16, 2018   5:01 PM
+
+I thought that half the motivation for thus AI was that it was thought that 
+compilers had to have something similar internally anyway so implementation 
+wouldn't be too expensive?
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Sunday, December 16, 2018   9:38 PM
+
+indeed, every conforming Ada compiler needs such a facility to handle 
+universal integers and universal reals. so they are built into the front-ends 
+of these compilers.  Adapting them for run-time use will require some work, in
+particular to meet the  proposed requirements of storage management (no leaks? 
+very slow leaks?) but there is a good starting point. Incidentally, every 
+compiler is equipped to handle a conversion from standard floating-point 
+notation to rational internal representation, so I agree with John that this 
+should be provided in the new packages.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, December 17, 2018   2:05 AM
+
+> Also, as I mentioned before I would like square root returning the 
+> largest integer whose square is less than or equal to the integer 
+> operand and also returns the remainder. It's easy to write crudely but 
+> there are probably short cuts that would be useful.
+
+>But that one seems pretty specialized.  What would one use it for?
+
+For one thing Its used in Fermat's method for finding prime factors. See 
+Nice Numbers page 166. I make the students do it on my numbers course at 
+Oxford.
+
+>By the way, "floor of square root" was an example exercise at the SPARK 
+>training course I attended years ago.  The parameter is 0..System.Max_Int, 
+>and it's a little tricky to avoid overflow (and get SPARK 
+> to prove that you avoided overflow).  Fun example.
+
+There you are, important stuff.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, December 17, 2018   3:41 PM
+
+>>I thought that half the motivation for thus AI was that it was thought that 
+>>compilers had to have something similar internally anyway so implementation 
+>>wouldn't be too expensive?
+
+>indeed, every conforming Ada compiler needs such a facility to handle
+>universal integers and universal reals. so they are built into the front-ends
+>of these compilers.  Adapting them for run-time use will require some work,
+>in particular to meet the  proposed requirements of storage management (no 
+>leaks? very slow leaks?) but there is a good starting point.
+
+Right, but Bob's (unspoken) concern is that once we put these things into the 
+Standard library, some users are going to want to use them in ways that 
+require high performance. The version used in the compiler doesn't have any 
+significant performance concern: even if a multiply took 1/10 second, it 
+wouldn't noticeably change the compilation time for the vast majority of 
+units. There are just not that many static expressions to evaluate in most 
+units. Even if there are, any sane performance will do.
+
+OTOH, if someone wants to do complex calculations to 400 digits in real-time, 
+the performance could be a big deal. That's likely to lead to pressure on 
+implementers to spend extra effort on these packages and on how the compiler 
+uses them (perhaps special conversions).
+
+BTW, I don't see a problem with leaking (the Janus/Ada packages never leaked, 
+we couldn't afford to lose any memory). But the Janus/Ada packages (which were 
+designed for Ada 83) use limited types with an explicit deallocator call. And 
+in practice, most of the operations are done with procedure calls, to avoid 
+creating temporaries. Something like:
+
+         -- Find 'Base'Last for an integer type of Size:
+         declare
+            Temp : U_Int;
+         begin
+            Uconvert (Temp, 2);
+            Uexp (Temp, Integer(Size_in_Bits));
+            Uminus (Temp, U_ONE);
+            Uassign (Type_Rec.Last, Temp);
+            Udispose (Temp);
+         end;
+
+Of course, no one would want a package like this. But the counterpart would 
+be a controlled type and operator functions. While this would look good:
+
+          Type_Rec.Last := (2 ** Integer(Size_in_Bits)) - 1;
+         
+It would create and destroy a number of controlled temporaries, which would 
+likely be more expensive than the original version.
+
+One could mitigate that somewhat by using built-in compiler transformations 
+to the procedure form, but obviously that would put a lot of extra stress on
+the implementer. (And there has been a lot of resistance to doing that sort 
+of transformation for Reference/Constant_Reference.)
+
+So the best path forward isn't completely clear, even though compilers have 
+such implementations.
+
+>Incidentally, every compiler is equipped to handle a conversion from 
+>standard floating-point notation to rational internal representation, 
+>so I agree with John that this should be provided in the new packages.
+
+It *is* provided in the new packages, and John appeared to be arguing
+*against* providing it. That didn't make a lot of sense to me. Janus/Ada 
+doesn't, however, provide the conversion from rational to real notation 
+string (we of course do provide a conversion to 32 and 64 bit float values, 
+but we didn't need the strings outside of the calculator test program, so we
+didn't figure out how to do that).
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent