From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,24ac4e1c8cbfe3c X-Google-Attributes: gid103376,public From: Wes Groleau Subject: Re: Sums of cubes (was Re: histrionics) Date: 1999/09/27 Message-ID: <37EF9F5E.ADB1D7D@ftw.rsc.raytheon.com>#1/1 X-Deja-AN: 529928311 Content-Transfer-Encoding: 7bit References: <37D670CE.855F96BD@interact.net.au> <37D678E4.9867000B@interact.net.au> <37d74de9@eeyore.callnetuk.com> <7r8c60$b2q$1@nnrp1.deja.com> <7r9rkj$g75$1@nnrp1.deja.com> <7rcddd$bfd$1@nnrp1.deja.com> <37DECE9D.72D1E87E@mitre.org> <37EA8DEA.61D49E6A@mitre.org> <37EB958C.26DB4C97@ftw.rsc.raytheon.com> <37EC14A2.2289AAEB@mitre.org> X-Accept-Language: en,es,fr,pt Content-Type: text/plain; charset=us-ascii X-Complaints-To: news@icg.raytheon.com X-Trace: bos-service2.ext.raytheon.com 938450722 151.168.144.162 (Mon, 27 Sep 1999 11:45:22 CDT) Organization: Raytheon Company MIME-Version: 1.0 NNTP-Posting-Date: Mon, 27 Sep 1999 11:45:22 CDT Newsgroups: comp.lang.ada Date: 1999-09-27T00:00:00+00:00 List-Id: "Robert I. Eachus" wrote: > > Wes Groleau wrote: > > when Constraint_Error => > > null; -- If the sum gets a constraint error > > -- and the number didn't, it's not a match. > > -- In a block because we don't want an > > -- error on 9,999 to prevent checking 10,000 > > -- (I think Robert missed this detail.) > > Nope, the sum of cubes of 999 is 3*729 = 2187, the sum of cubes for > 9999 is > 2916, etc. If you were going for something like the tenth power it > would be an issue. Or if the package is instantiated with 0..1000 (for example). Without the handler for constraint_error, my version would stop at 99. (I should have used 99 in the comment.) Since Robert's version used non-generic integers, it did not have that problem. (i.e., I apologize for my false accusation.) Robert's version is undoubtedly more efficient, but mine is simpler. However, if you're doing five digits or less, either version will take longer to compile than to run. Six digits runs in ten seconds on a slow SPARC. Seven digits is runs under 2.5 minutes. So up to seven digits, the optimizing analysis takes longer than a very UNoptimized computation. But Robert's fact about 9999:2916 made me think: The largest possible sum-of-cubes for six digits is 6 * 9**3 = 4374 The smallest possible six-digit number is bigger than that. So it's pointless to go beyond five digits. Or is my math wrong? Took less than a minute to show with a spreadsheet that with power of you can stop at 2 3 digits 3 5 digits 4 5 digits 5 6 digits 6 7 digits 7 8 digits 8 9 digits 9 10 digits