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