Remove VectorSpace?

[Waldek Hebisch]

Concering our category structure VectorSpace mathematicaly is
just a Module over a Field. In code VectorSpace adds two
extra signatures, but they seem to be inessential. Now
I have tried what happens when we remove VectorSpace
and it can be done with minimal changes, basicaly only
ExtensionField depends on added signatures and we can
add them in ExtensionField.

So, it seems that we should remove VectorSpace: it adds
almost nothing and is essentially unused. Any comments?

--
Waldek Hebisch

[Ralf Hemmecke]

On 2/16/20 4:40 PM, Waldek Hebisch wrote:
> Concering our category structure VectorSpace mathematicaly is
> just a Module over a Field. In code VectorSpace adds two
> extra signatures, but they seem to be inessential. Now
> I have tried what happens when we remove VectorSpace
> and it can be done with minimal changes, basicaly only
> ExtensionField depends on added signatures and we can
> add them in ExtensionField.

There other appearances here...

https://github.com/fricas/fricas/blob/master/src/doc/htex/ug13.htex#L703
https://github.com/fricas/fricas/blob/master/src/doc/htex/CARD.htex#L38

> So, it seems that we should remove VectorSpace: it adds
> almost nothing and is essentially unused. Any comments?

My feeling actually is that we should keep it, since the concept of
vector space is so much used in mathematics.

However, I don't care so much. The "/" signature is really inessential,
but I think "dimension" is somewhat more important. I haven't come
across such a situation, but it might be useful to ask whether a given
domain is a vector space, i.e., "if V has VectorSpace(X)".

If you remove VectorSpace, you should conditionally export dimension: %
-> CardinalNumber in Module(R). But maybe that's too early for
CardinalNumber to be seen during the bootstrapping process.

Ralf

[Kurt Pagani]

On 16.02.2020 16:40, Waldek Hebisch wrote:
...

>
> So, it seems that we should remove VectorSpace: it adds
> almost nothing and is essentially unused. Any comments?

I would agree in principle if Ralf didn't make a point: it's a widely known
concept whereas Module(F) is for the algebraist ;) But you're right, so as it
stands it's quite useless.
More important to me would be a (backward compat.) list keeping records of what
has been removed, so that "old code" can easily be compiled , e.g.


FreeAbelianGroup X ==> FreeModule(Integer,X)
VectorSpace X ==> Module X
...

[Waldek Hebisch]

On Sun, Feb 16, 2020 at 09:15:29PM +0100, Ralf Hemmecke wrote:
> On 2/16/20 4:40 PM, Waldek Hebisch wrote:
> > Concering our category structure VectorSpace mathematicaly is
> > just a Module over a Field. In code VectorSpace adds two
> > extra signatures, but they seem to be inessential. Now
> > I have tried what happens when we remove VectorSpace
> > and it can be done with minimal changes, basicaly only
> > ExtensionField depends on added signatures and we can
> > add them in ExtensionField.
>
> There other appearances here...
>
> https://github.com/fricas/fricas/blob/master/src/doc/htex/ug13.htex#L703
> https://github.com/fricas/fricas/blob/master/src/doc/htex/CARD.htex#L38
>

AFAICS those (and few otheres) are inessential uses, very easy to
remove.

> > So, it seems that we should remove VectorSpace: it adds
> > almost nothing and is essentially unused. Any comments?
>
> My feeling actually is that we should keep it, since the concept of
> vector space is so much used in mathematics.
>
> However, I don't care so much. The "/" signature is really inessential,
> but I think "dimension" is somewhat more important. I haven't come
> across such a situation, but it might be useful to ask whether a given
> domain is a vector space, i.e., "if V has VectorSpace(X)".
>
> If you remove VectorSpace, you should conditionally export dimension: %
> -> CardinalNumber in Module(R). But maybe that's too early for
> CardinalNumber to be seen during the bootstrapping process.

Actually, 'dimension' alone is of limited use. In finite
dimensional case one usually wants a basis and we have
good ways to provide basis (like FramedModule). Actually,
it would be rather unusual when one can compute dinension
and get finite value, but one can not easily give a basis.
So, in this sence current VectorSpace looks like bad
concept: it requres _one_ extra nontrival operation, but
omits a lot of other which would be needed in practical
computations.

More to the point, AFAICS 'dimension' requies extra structure
and we can not implement it for arbitrary vector space.
That is probably reason why VectorSpace had so little use:
you can implement 'dimension' only with extra structure,
and in such cases you have so much information that
'dimension' adds essentialy nothing.

--
Waldek Hebisch

[Kurt Pagani]

On 17.02.2020 16:44, Waldek Hebisch wrote:
> On Sun, Feb 16, 2020 at 09:15:29PM +0100, Ralf Hemmecke wrote:
>> On 2/16/20 4:40 PM, Waldek Hebisch wrote:

> Actually, 'dimension' alone is of limited use. In finite
> dimensional case one usually wants a basis and we have
> good ways to provide basis (like FramedModule).

May I ask why you used LeftAlgebra(R) in the implementation? A special reason?
It's natural of course to multiply from the left but it limits the use together
with other constructs (i.e. when providing a basis we somehow should be able to
form the tensor products, IMO):

(1) -> FramedModule Integer has FreeModuleCategory(Integer,Symbol)
(1) false

> Actually,
> it would be rather unusual when one can compute dinension
> and get finite value, but one can not easily give a basis.
> So, in this sence current VectorSpace looks like bad
> concept: it requres _one_ extra nontrival operation, but
> omits a lot of other which would be needed in practical
> computations.

Yes, admittedly true. I think FreeModule(R, S) is perfectly sufficient for most
applications (dimension related to #S). I guess nobody will go beyond aleph0.

[Ralf Hemmecke]

> More to the point, AFAICS 'dimension' requies extra structure
> and we can not implement it for arbitrary vector space.
> That is probably reason why VectorSpace had so little use:
> you can implement 'dimension' only with extra structure,
> and in such cases you have so much information that
> 'dimension' adds essentialy nothing.

As I said before, I don't insist on VectorSpace. It's just that it
should appear at least in the documentation and point people to
Module(R) and explain why FriCAS does not have vector space.

In fact, a bit related is also the domain Vector. I find it's name
totally misleading.

http://fricas.github.io/api/Vector

Vector(R) does not even require its coefficient domain to be of type
Field. Furthermore, it actually implements the union of R^n for all
natural numbers n.

I have no idea for a better name, but if I have two vectors and are not
always able to add them together (because they have different lengths)
then that feels strange.

Yes, actually Matrix is similar, but strangely enough for that domain,
I'm not so irritated.

Just my 2 cents.

Ralf

[Kurt Pagani]

Below are some 'losses' I encounter when compiling (older) code from other people:

OrderedFreeMonoid
FreeAbelianMonoidCategory
InnerFreeAbelianMonoid
FreeAbelianMonoid
FreeAbelianGroup
Monad was renamed to Magma
Magma was renamed to FreeMagma
lo => low
hi => high

VectorSpace ;)

Usually, some macros allow compilation without changes in the sources. There are
certainly not so many as I've thought, so it wouldn't justify a special
compatibility package (e.g. like in python2/3).

[Waldek Hebisch]

On Mon, Feb 17, 2020 at 05:14:11PM +0100, Kurt Pagani wrote:
> On 17.02.2020 16:44, Waldek Hebisch wrote:
> > On Sun, Feb 16, 2020 at 09:15:29PM +0100, Ralf Hemmecke wrote:
> >> On 2/16/20 4:40 PM, Waldek Hebisch wrote:
>
> > Actually, 'dimension' alone is of limited use. In finite
> > dimensional case one usually wants a basis and we have
> > good ways to provide basis (like FramedModule).
>
> May I ask why you used LeftAlgebra(R) in the implementation? A special reason?
> It's natural of course to multiply from the left but it limits the use together
> with other constructs (i.e. when providing a basis we somehow should be able to
> form the tensor products, IMO):
>
> (1) -> FramedModule Integer has FreeModuleCategory(Integer,Symbol)
> (1) false
>

FramedModule was intended for use in noncommutative contexts, so
one have to choose between left and right. Left seems more
natural, I to limit effort I did not provide right version.
Note that in context of say differential operators base
ring may be commutative, but we still need to distinguish
between left and right.

Concerning FreeModuleCategory, our concept of free module
requires additional features. It is not entirely clear
for me if FramedModule should have FreeModuleCategory

--
Waldek Hebisch

[Grégory Vanuxem]

hello,

For juniors. Just for them

That's all

cheers

__

Greg

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20200217165007.GD37879%40math.uni.wroc.pl.

[Waldek Hebisch]

Most changes are to clean up things are reduce confusion. If
something is useful enough to warrant a compatibility packge,
then in most cases it would be wiser not to remove it at all.
And that is purpose of discussion like this: are there good
reasons to keep things like the above (well, Monad and Magma
above are exceptions, we had to switch to better naming).

For example, in case of VectorSpace, part of cost of keeping it
is that documentation must then explan:

No, despite promising name VectorSpace is not right thing here,
you should use Module instead.

It is clearer to say:

There are not such thing as VectorSpace, in FriCAS you
use Module.

--
Waldek Hebisch

[Qian Yun]

Hi Waldek,

VectorSpace in src/algebra/exposed.lsp should also be removed.

Besides, there are a few more in src/doc/htex and src/interp/ax.boot.tex

- Qian

[Waldek Hebisch]

On Fri, Nov 20, 2020 at 03:10:46PM +0800, Qian Yun wrote:
> Hi Waldek,
>
> VectorSpace in src/algebra/exposed.lsp should also be removed.
>
> Besides, there are a few more in src/doc/htex and src/interp/ax.boot.tex

Thanks for info, now all traces of VectorSpace should be gone.

BTW: CliffordAlgebra used to be VectorSpace and export
'dimension'. For long time it does not export VectorSpace
so internal definition of 'dimension' is unused. I am
not sure if we should remove 'dimension' from CliffordAlgebra.
Or maybe declare that CliffordAlgebra is of FreeModuleCategory?

--
Waldek Hebisch