Re: project euler 26

[Ben Bacarisse <ben.usenet@bsb.me.uk>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 2023-09-10 03:20, Ben Bacarisse wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On 2023-09-09 02:25, Ben Bacarisse wrote:
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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.