Re: project euler 26

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2023-09-10 21:22, Ben Bacarisse wrote:
> "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?

Yes, in the direction of numeric problem space. Universal finding 
maximum is another problem space, e.g. a container library design etc.

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

And this is exactly wrong. You should think about whether storing 
represents an issue, e.g. in terms of performance and/or space. If it 
does you should consider suitable implementation of storage that 
provides required overall performance of needed operations, like 
insertion, search, cleaning up etc.

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

You do not need *any* container. You need a container, just one.

>> [...]
>>> 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.

The best design is plain loop.

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

My understanding was that you wanted to see how to use the Ada standard 
library containers with generics.

Generic programming in Ada (programming in terms of sets of types) is a 
huge, almost infinite topic. One should be rather specific.

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

There are more than one way to skin a cat in Ada. You can choose one 
drawer in the Ada toolbox and feel comfortable with what it provides all 
your life.

"Ada way" among Ada users rather refers to an approach to software 
engineering in general. Like upfront specification, separation and 
careful design of interfaces, modular design, problem space driven 
choice of types, earliest possible error detection etc.

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

I am not aware of any substantial contributions since Cardelli etc. 
Recently designed languages represent a pitiful mess of old wrong ideas 
in an ongoing competition to create something more flawed than K&R C...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de