RE: Bug-gmp digest, Vol 1 #196 - 4 msgs

[David T. Ashley]

Hi Kevin,

My responses are below.

Best regards, Dave.

-----Original Message-----
From: address@hidden [mailto:address@hidden Behalf Of
Kevin Ryde
Sent: Saturday, August 11, 2001 5:04 PM
To: address@hidden
Subject: Re: Bug-gmp digest, Vol 1 #196 - 4 msgs


Kim-Ee Yeoh <address@hidden> writes:
>
> > From: "David T. Ashley" <address@hidden>
> >
> > d)The sheer number of source files involved.
>
> A non-issue.  Breaking up the code into natural chunks actually helps
> understanding and maintaining the library.

The linker won't split up object files, hence one function per file,
so a program only gets what it actually uses.  (This is pretty
standard I think.)

** That explanation makes a lot of sense to me.  When I "ported" the
** GMP library to MSVC++, I made exactly three software modules out
** of it.  But I understand that traditionally, linkers won't extract
** or fail to extract anything smaller than an object module.  So
** I do understand this decision.  In my case, I don't care about
** memory and so forth, so I don't consider this constraint.
**
** Another possibility, however, might be to combine the sources into
** something on the order of 3-10 source files.  Then, one could
** arrange it with preprocessor directives so that one could either
** compile the whole thing as a unit or else just compile one function.
** In other words, assuming 30 functions in module, you could compile
** the thing 30 times, each time with different preprocessor flags set
** so that one just gets one function.
**
** The approach I recommend would have the following advantages:
**   a)Everything would be pretty much in the same place, with
**     far fewer files.
**   b)Certain things, like the GNU license statement and so forth,
**     would only be in one place.
**   c)The scheme would directly support guys who want to compile
**     into a small number of source modules or just one source module.
**
** I recognize that every scheme has disadvantages, and so you could
** probably find holes in my idea above.
**
** But the other poster's claim that the ideal way to modularize things
** is to package one function per source file is ... an idea that I disagree
** with.  Thank you for being honest and saying you are doing this
** to support the linker.
**
** I would say again that I think the best way to modularize things,
** ignoring issues of link granularity, is to provide one well-rounded
** abstraction per module.  The notion of the arbitrary integer is
** one abstraction, the notion of the rational number is another, etc.
** I do not think the scheme of one function per source file has any
** benefits other than to support the development tools and the
** granularity of the link operation.

> Sure, the code could do with more documentation, certainly on the
> technical aspects and reasons for a particular choice of algorithm.

The next release will have a chapter in the manual about the
algorithms used, and when and why.

As far as the sources go, it can only be emphasised that the code is
code and not a tutorial introduction to either multiprecision in
general, nor the particular algorithms.

** These statements also make a lot of sense to me.  Ultimately, one
** has to make some assumptions about the reader of the code, and
** these drive the type of documentation.
**
** One must nearly ALWAYS assume that any reader of a C deck under-
** stands the language, so comments like the following are definitely
** a waste of good electrons:
**
**  if (i)   /* If i is not zero */
**    i--;   /* Decrement i--make it one less than it was. */
**
** However, in the case of the GMP library, one must assume a little
** more about the readers than just knowledge of the C language.
** This gets into a very subjective issue.  In several of the places
** in the code, essentially one was making use of valid but non-traditional
** relationships.  What can one reasonably expect the reader to understand
** and not understand?  This is subjective.
**
** So, when I read a line of source code and don't understand it the first
** time, does this mean that the documentation is inadequate or that I
** don't have the expected background?  There is some subjectivity
** here.  Anyway, I'm glad you are adding some information to the
** manual.
**
** Please note that nothing in your response addressed several of my
** other issues, such as tabs in the source file, naming conventions,
** etc.
**
** Best regards, Dave.

_______________________________________________
Bug-gmp mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/bug-gmp