Re: project euler 26

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

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

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

Noted!  I will try to guess what generalisations you might approve of
in future :-)

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

In Ada.  It works well in some other languages for reasons I'll explain
just below.

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

Yes, in Ada.  Since I can't use universal algorithms, it pays to decide
all this first because changes will be costly.  But in some other
languages I can try various schemes and measure or profile to see what
time/space trade-offs there are between different designs.  This is
easiest when I don't have to worry about all the changes that simply
switching from, say, a list to an array will incur.

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

Yes, in Ada.  The cost of changing a design is going to be
non-negligible, so we must make sure you get it right before too much
code is written.

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

Yes, in Ada.

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

Well that's what it turned out to be.  At first I did not know that
built-in types like arrays can't be covered in the same way.

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

Sorry.  I was hoping that generalising from a range to an array or some
other container would not be the huge topic it turned out to be.

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

Yes, I remember the 80s!  It's rare to have specifications that don't
change these days.  And general remarks like "problem space driven
choice of types" apply to all languages.  What matters is what types the
language offers, and what the interfaces to those types are.

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

Forgive me, but that does not appear to be a well-informed option.  You
may be bang up to date as far as research into programming language type
systems is concerned, but that reply does no read as if it were written
by someone who is.

-- 
Ben.