From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Ben Bacarisse Newsgroups: comp.lang.ada Subject: Re: project euler 26 Date: Sun, 10 Sep 2023 20:22:54 +0100 Organization: A noiseless patient Spider Message-ID: <87bke9kf3l.fsf@bsb.me.uk> References: <878r9mudvj.fsf@bsb.me.uk> <87a5u1u1yv.fsf@bsb.me.uk> <8734ztttpc.fsf@bsb.me.uk> <87fs3ssl6v.fsf@bsb.me.uk> <87a5u0rts0.fsf@bsb.me.uk> <87jzt3qqlb.fsf@bsb.me.uk> <87o7ieq3ne.fsf@bsb.me.uk> <8734zpo3fz.fsf@bsb.me.uk> <87a5twmbum.fsf@bsb.me.uk> <87tts2kenf.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="871ee901e005cd01e5d2484bc26cd51b"; logging-data="736452"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/P+PXSZMblJT9gjdT1oAgrBehbiocRhrI=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Cancel-Lock: sha1:f+YSfhqt0Kj/bXr3SqNmfljOb6U= sha1:8vSVa0xbnOFm04bhGjI7e7n6mEM= X-BSB-Auth: 1.2f43a201864bbcaf24a0.20230910202254BST.87bke9kf3l.fsf@bsb.me.uk Xref: news.eternal-september.org comp.lang.ada:65637 List-Id: "Dmitry A. Kazakov" writes: > On 2023-09-10 03:20, Ben Bacarisse wrote: >> "Dmitry A. Kazakov" writes: >> >>> On 2023-09-09 02:25, Ben Bacarisse wrote: >>>> "Dmitry A. Kazakov" writes: >>>>> As I said you think in a wrong direction of abstracting the language >>>>> "finding maximum" rather than the problem space, e.g. generalization to >>>>> other bases, other mathematical structures etc. >>>> Generalising to an arbitrary base is local to the function that finds >>>> the answer for one element. It's an entirely separate axis of >>>> generalisation to that of where the elements come from. >>>> It's interesting to me that you consider one simply wrong and the other >>>> natural. >>> >>> Because one is a software design artifact and another is the result of >>> problem space analysis. >> Which one the wrong one? > > None automatically is. The point is avoiding overdesigning a numeric > puzzle. Ah, I thought your criticise was intended to be general -- that "abstracting the language 'finding maximum' rather than the problem space" was always wrong, but it seems you meant only in the case of a puzzle like this. Numeric puzzles like this should only be generalised in a few "approved" directions? Obviously I disagree. I would probably not bother doing this sort of puzzle if it did not spark thoughts that go well beyond getting the answer and a few obvious variation like using a different base. Because I am interested in programming languages in general I always solve such puzzles in more than one language so I can see how well they express the algorithms involved. Since prime numbers are crucial here, I had already tried a couple of prime sieves in one of my solutions. In that Ada solution, I would probably have to store the primes somewhere and maximise over that. That's what got me thinking about a general "maximise F over X" function because if Ada had a simple way to do that, I could try various ways to write the sieve -- the primes might end up in an array, a set or a map, and it would make no difference to the rest of the code. But the conclusion seems to be that maximising over any container is just too simple to be worth making it a reusable component in Ada. And even then it would not (as far as I can tell) work for native arrays. > [...] >> This is probably the closest we can get to a universal solution. >> Vectors don't have a Key function but I am sure I could find out what >> should be provided there. > > Vector has To_Index for Key. > > In general, note that Ada does not require you to use any library. I > personally dislike cursors in particular because of their "functional" > style. I prefer plain element position and loop iteration of ordered > structures. A container library based on this paradigm would use other > generic abstraction. > > Furthermore, I prefer dynamic polymorphism of tagged types over parametric > one of generics. Therefore to me Maximum_At should rather be a class-wide > or primitive operation than a generic. I was looking for whatever design you thought best, since you know Ada infinitely better that I do. It would be a shame if something I said has ended up causing you to propose solutions you don't think are the best ones for this example. > In Ada you have freedom to choose your way, which also massively reduces > universality of any abstraction, which will never apply universally. That's a strange remark. You have to do things the Ada way. The freedom is only in choosing how to combine the specific tools in Ada's toolbox, and Ada also constrains how the tools can be combined. This is true for any programming language. None of then give you the freedom choose your way unless your way already aligns with what it permitted! > I would like to have means to deal with this problem by means of ad-hoc > supertypes, but that will never happen due to lack of interest in reworking > the language type system and because in "Dark Ages" there is virtually no > research on fundamental language construction topics. I don't believe that to be the case. I can believe that there is little research into overhauling Ada's type system, but not in general. -- Ben.