I thank people for the discussing words on
http://www.botik.ru/pub/local/Mechveliani/basAlgPropos
I have found so far, the following concrete notices.
(1) Marcin Qrczak Kowalczyk <[EMAIL PROTECTED]> :
1.1. invalid arguments should be impossible to construct
if the validity can be checked at all
1.2. "I prefer minBound to looking at element under Just under
Just under tuple of osetBounds"
(there were others, but I had explained earlier why I do not
agree with them - S.Mechveliani)
(2) Tom Pledger :
insert a partial ordering class between Eq and Ord
Now, what can be done about this.
1.1. I am going to almost satisfy this by using the abstract data
types (never tried before). Just a small revision.
1.2. minBound can be added simply.
2.
basAlgPropos says
"class (Show a, Eq a) => Set a where ...
is introduced as a superclass for all algebra. It also provides
compare_m for the partial ordering (which, for example, can be
defined trivially).
"
Now, compare_m can be separated to
class Set a => PartialOrd a where
compare_m :: a -> a -> Maybe CompValue,
PartialOrd being a superclass for Ord
- if people would not object.
As to me, I do not see the real difference.
Reply to other, generic notices
-------------------------------
Ketil Malde <[EMAIL PROTECTED]> writes
>> How will it make Haskell more useful
>> from math-oriented application perspective?
> Without making it totally arcane for the non-math-orienteds! Having
> Num is nice, exactly since it's *not* rigidly defined. If you have
> function signatures with CommutativeGroup and LeftModule, people are
> going to drop off.
> OTOH, the mathematician will be very comfortable with functions
> defined over groups or rings or fields, and it is objectively the more
> accurate way to specify function signatures.
And for the non-mathematically minded users, there is no difference.
For example taking (*) from Num is not simpler than taking it from
Multiplicative, or maybe, from MulSemigroup.
-------------------
Tom Pledger writes
> In practice, it needs the support of some language features which are
> research topics in their own right, such as overlapping instances, and
> laws.
No.
If the Haskell language committee does not allow in Haskell-2
the overlapping instances, undecidable instances, extended Rules
possibility, domain conversion, and such things,
then the corresponding parts of basAlgPropos withdraw very simply
(and wait for future languages).
For the discussion, I suggest to recall of these additional features
only after the main minimal part of proposal is accepted
(for revision).
> I'm uncomfortable about using a Haskell class to represent algebraic
> groups. The reason is that group-ness is a property of a base set
> *and* a function, but an instance declaration in Haskell can only
> specify the type (i.e. the base set).
In any case, the Haskell language classes, instances and types cannot
represent fully the mathematical domains.
Neither can other algorithmic languages.
basAlgPropos does its best to express possibly more of what is needed.
---------------------------------------------
Jan Skibinski <[EMAIL PROTECTED]> writes
> Shouldn't we thus start with something more moderate,
> that does not offer a concrete solution as yet,
> but at least presents some framework for a serious
> discussion?
>
> I recently came again across a "wacko" (in the words
> of its author) 1998 article by Max Tegmark
> "Is the `theory of everything' merely the ultimate
> ensemble theory?":
> ftp.sns.ias.edu/pub/max/toe.ps.gz - USA
> [..]
> Interesting in itself, although highly controversial,
> the paper graphically sketches a portion of the hierarchy
> of matemathical structures (or rather a web) in its
> introduction. It refers to Mathematics Subject
> Classification from American Mathematical Society,
> www.ams.org/msc/
> [..]
Please, do not reinvent a wheel.
The main usable mathematical categories have become classic. And
they are named in the manuals on mathematics, starting from about
1940-1960. This is all settled. The words like Additive Group, Ring,
Field, and many others, mean the very same since at least 1960.
> That's why some sort of a big picture might hopefully
> help to clearly organize the process into several stages
> of the iteration loop:
Why do not you find a "big picture" in basAlgPropos - section
'in.h' ?
Also a reasonable "big picture" for the mathematical categories
(classes) can be found in the book on the Axiom system for computer
algebra
Jenks, R.D., Sutor, R.S., et al.
Axiom, the Scientific Computation System.
Springer-Verlag, New York-Heidelberg-Berlin (1992).
Jan Skibinski also welcomes extra explanation on the sense of the
algebraic classes in basAlgPropos and on the possible
implementation.
basAlgPropos contains quite a lot of comments and examples
accompanying the classes descriptions. Please, read the proposal.
On implementation of instances: mostly, it is obvious. Some of it is
given. And for the rest, rely, for example, on me.
In the DoCon program, there were done more complex things.
This worths discussing only after the proposal in accepted in its
minimum, in its principal part.
But if you ask a concrete question here, what does this mean such and
such concrete operation from Proposal, example of usage, then of
course, I would tell, and you would discuss further.
---------------------------------------------------
Jerzy Karczmarczuk <[EMAIL PROTECTED]> writes
> [..] So, in my opinion such
> initiatives as Docon of Sergey Mechveliani merit all our
> attention [..]
Thank you.
Only, please: let us deal now with basAlgPropos, not DoCon.
------------
basAlgPropos is simpler. It aims the Haskell standard library.
And DoCon is only a package for the snobby mathematicians.
> The "object-like" classification of math. structures *is not enough*.
>
> Not only some properties of operations, such as the
> commutativity cannot be expressed by such diagrams, but
> several links: subsumptions, implicit inheritance etc.
> will be always missing. For example:
>
> Any additive group *must* be a Module over integers.
> A Ring inherits twice a semi-group.
> A modular Ring with N generators for N prime becomes
> "miraculously" a Field.
> The ordering generates an algebraic structure.
>
> etc. In Axiom, Magma and MuPAD (and also GAP) there is
> plenty of dynamics, the "types" (categories, domains,
> axioms, hyla, callThemAsYouLike,...) combine the class
> approach, only *partially* resolved statically, with
> some constraint semantics.
>
> ===
> I believe that a modest approach is really what we need,
> but for me the modesty means - try to *apply* to concrete
> problems whatever you have, and if you miss something -
> CRY LOUD! (Perhaps in such a way I will see one day the
> possibility to use my own *IMPLICIT* fromInt or fromDouble
> conversion of constants, and not those inserted by the
> compiler "who" naively thinks that I use the standard
> preludes... /Hugs/)
This is all very true.
Two examples.
The domain of Z/(n) - integer residues modulo n,
should or should not have the instance of Field, depending on
whether n is a prime number. Z/(2) is a field, Z/(4) is not.
Before a program computed n and recognized its primality
(statically!?) it cannot solve whether the Field instance is correct
for the given domain Z/(n). Should we allow n to be a variable in
a program?
Similarly, has a program right to deal with the vector space of
variable dimension n ? It is very desirable. But the instances in
Haskell may be truly expressed for (,), (,,) and not for the tuple
of variable size n. And so on.
basAlgPropos suggests to allow these dynamic things, but not to
expect the static instances to express completely all the
mathematical meaning and all the questions of the mathematical
correctness. Something has to remain on the user program.
In particular, the user program computes n, its primality, and
acts with Z/(n) as with the Field. But if the primality test was
skipped (it may be expensive!), the result of the program may be
incorrect. There does not exist any full way-out from this, in other
algorithmic languages too.
On category theory
------------------
> Getting back to categories, they began to appear in math.
> physics as well, although I still remember when one of
> my professors many years ago told us publicly that there
> are some branches of mathematics which belong to a purely
> speculative layer of science/philosophy, and will *never*
> find any applications, for example the theory of categories,
> or non-classical logic.
>
> http://www.math.sunysb.edu/~kirillov/tensor/tensor.html
> http://math.nwu.edu/~getzler/conf97.html
basAlgPropos *ignores* the category theory, though, does not
contradict it.
It only may use the word `category' instead of `class', when deals
with some concrete mathematical categories.
It may say: "G is of the AddGroup category" - only this.
The class Functor of Haskell-98 also reflects certain simplest
notion from the Category theory.
As to the professor you mention, I agree with him.
Because a theory is something that helps to solve the actual tasks.
Recall the Euclidean geometry, Calculus by Newton & Leibniz, Group
theory.
Category "theory" is very different. Probably, nobody had solved any
real task using it which was hard to solve by other means.
I would say, there exists the Category language, that may be useful,
but not the theory. Though, I may mistake.
-------------------------------------------------------------------
This is the opinion shared among many valuable mathematicians, more
qualified than me.
-------------------------------------------------------------------
My aim in this passage is to warn the Haskellites about the danger
of overestimating the role of the category theory:
it may be useful, but do not expect it would become as fruitful as
other classic mathematical methods.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
