On Apr 12, 8:52 am, parisse <[EMAIL PROTECTED]> wrote:
Hi,
> ;; This buffer is for notes you don't want to save, and for Lisp
> evaluation.
> ;; If you want to create a file, visit that file with C-x C-f,
> ;; then enter the text in that file's own buffer.
Emacs people ;)
> > You can disable the X component of GIAC, so that isn't too much of a
> > problem. But the fact that it isn't cleanly separate is something I
> > would consider non-optimal.
>
> The main reason is that it is not a top level priority to do a proper
> splitting. And for example readrgb is using the FLTK images library.
> But as you say, it can be compiled without X.
>
>
>
> > Aside from that we did discuss GIAC again in IRC a couple days ago
> > [some people did look at it in the past and it has come up in the
> > past] and there were a couple comments [my recollection, not some
> > official statement]:
>
> > * Any standard component of Sage for now has to be GPL V2+
> > compatible. GIAC seems to be GPL V3[+] now
>
> This should not be a problem. I can switch back to v2. But the normal
> way should be that v2 softwares go to v3.
Nope, it isn't. After initially switching to GPL V3+ we have decided
to remain at GPL V2+ for now. Since we have discussed this quite
extensively in the past here is no need to rehash this here. I don't
need another drawn out licensing discussion.
> > * The code is sparingly commented and seems to conform to its own
> > coding style. We specifically looked at the Risch code and also
> > infrastructure like vecteur - this is really a big issue since dealing
> > with sparingly documented code in the past had proven to be a huge
> > pain in case we had to fix bugs
>
> I believe that someone looking at someone else code will always find
> it difficult (unless they worked together),
Well, I can see if documentation is available or not. The giac code
isn't particularly hard to read o understand, but it is quite
different to extend the code without spending some time with it.
> I find it hard myself to
> read other people code. I certainly do not pretend to comment it
> perfectly (and I don't plan to make a detailled description of the
> math behind),
That isn't really the problem. I just don't want to spend reading code
all over the library to drill down to one local problem.
> I do so that I can fix bug myself using gdb. Sometimes
> in the future, I'll certainly have to make some documentation for
> programmers, but I'll move it as a priority only if I'm sure active
> developers are using giac.
This is certainly a chicken/egg problem. I did revisit risch.[cc|h]
and vecteur.[cc|h] and rish.cc was better commented than I did
remember. But what I am missing is doxygen style documentation of
input and output parameters.
> > * It is unclear that a ten time speedup over the current code is
> > worth dealing with 150k lines of code. It is another polynomial class
> > to deal with in coercion, build issues and so on. If it were "Magma"
> > speed that probably would be something we would be willing to live
> > with ;)
>
> The current bottleneck which explains at least a part of the speed
> difference with magma is sparse multivariate division, I'm going to
> improve it and I'll update my benchmarks. Now, I want to emphasize
> that giac is not just another polynomial library.
Sure, we are aware of that.
> It is a full-
> featured CAS that sage could call as a library (unlike other CAS where
> most probably communication is handled by text streams).
Yes, we agree here, too, but we are only interested in factorization
here at the moment. Otherwise everything else seems to be covered by
other components in Sage.
> > * The code doesn't seem to have MSVC support and due to its size the
> > size/benefit ratio doesn't look good. Since I will likely end up
> > porting the code I am not too excited to have to deal with another
> > 150k lines of code.
>
> I don't see any interest to have MSVC support myself,
Since I and some other people are porting Sage to MSVC I prefer to not
add to my workload unless there is a good reason to do so. Adding 150k
lines of code with unknown problems and keeping that code working and
running without any interest from upstream is far from an ideal
situation. The effort to replace Maxima with something else not
written in lisp is precisely routed in there, not because I dislike
lisp and/or Maxima. It is just a pain to support lisp. And since its
performance is far from stellar it will result in a faster and smaller
Sage.
> giac/xcas is
> ported on windows with cygwin. I bet however that it is easier to port
> code to another compiler than to implement, test and fix again the
> algorithms :-)
Well, I tend to disagree on that: Porting the code is only a small
part of the effort. And it isn't only a port to MSVC, it is also
porting to Sun's Forte Compiler and potentially other compilers down
the road. We are interested in only a small part of the functionality
and giac has been looked at in the past [that discuss has happened
face to face at Sage Days or in IRC] and we never came to the
conclusion that it was worth the effort [i.e. the cost was not worth
the effort]:
* Gary Funrnish has been working on Symbolics for the last four
months and is funded over the summer via an REU to finish that work.
Parts of that code might even make it into a 3.x release before Dev1.
By the end of the summer we will likely have a Risch implementation
and since Gruntz is implemented in sympy we plan to use that. Should
sympy not get their ass in gear soon I am sure that somebody will port
those 2000 lines of code to our symbolics framework
* Mike Hansen and two students from the Singular team are currently
working on the gcd issues of Singular. Since a fast gcd is essential
to some of the things Mike is doing he is certainly motivated to solve
that problem. I am not sure what the status of the students is, but I
wouldn't be surprised if their work makes it into the next main
Singular release this fall.
So, that leaves mv-factorization. I am not expert on this and I am
sure that if people like Bill Hart say that it is a hard problem to
get right and fast I am sure it will take quite some effort to get it
done. giac has potential problems [please correct me if I am wrong]:
* a low busfactor, i.e. few if not one active developer
* no really visible developer community
* no public CVS or version control system
* unsatisfying documentation
* unkown build issues: Ask for example John Cremona what happened
when his eclib code got merged in Sage. We did discover quite a number
of issues with NTL as well as newer compilers which took a while to
fix. And that was with a codebase 20 years old that has been used
quite intense by a number of people in the field. It took month to get
all of this sorted out, not because John is a bad coder [he is stellar
in my book], but because when you write code you only hit the bugs
that show up with your particular combination of tool chain and env.
Once you throw the code into the wild different things tend to
happen.
* unknown memory leak issues [Did you ever run valgrind? If not I
would highly recommend it]
* unknown portability issues: Sun Forte, MSVC, alignment problems,
endianess issues, i.e. I could point to a number of issues in
libSingular on Solaris for example or in symmetrica on Sparc or PPC
and I am sure you get the idea.
* unknown number of external library users: I am not away of anybody
external using giac as a library. From my experience with libSingular
I am not too optimistic that we will not run into a number of issues
here. Look at #2822: PolyBoRi is designed as a library to be used from
Python. But I spend about two days chasing down some issue that was
caused by the way we use the library.
* small test suite: it seems that there are only the files in $GIAC/
check to do some testing. It is only a handful of files compared to
52,000 doctests in Sage. Are the files in doc/dxcas used for testing?
And from past experience Sage's doctests have caught issues in
components used by Sage that were either not caught by their own
testsuite or nor at all since the project didn't have any automated
testing at all.
* murky licensing situation - see below
The unknows would all have to be evaluated before I would give my "+1"
on integration and since nobody at the moment is jumping up and down
to do the evaluation and integration work I am skeptical on the
prospects. Since I am doing the port and the Solaris as well as MSVC
port of Sage is considered to be of ultimate strategic value my
opinion in that department does count. I am sure all of the issues
above can be overcame [in case they do exist], but I am not going to
work on any of this unless factorization becomes more important than
the ports. And I don't see that happening because certain institutions
are paying me to port to Solaris and Windows. And if one pays for the
band that person decides what music is played.
So: What should you do? Start with an optional or experimental spkg
and prove me wrong. ;)
> > * there are CoCoALib leftover files in the src directory, namely Tmp*
> > - I am sure this is an oversight.
>
> These files are not part of libcocoa.a (I did not recheck since the
> last time I downloaded cocoa),
No, they are not. They *used* to be part of CoCoALib [up to 0.98.1 I
believe], but the file has been removed early on in the 0.99.x series.
But the file is not part of CoCoALib 0.99.12 which relicensed the
library to GPL V3 only. from GPL V2 only. But the copyright reads:
// Copyright (c) 2006 Stefan Kaspar
// This file is part of the source of CoCoALib, the CoCoA Library.
// CoCoALib is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License (version 3)
// as published by the Free Software Foundation. A copy of the full
// licence may be found in the file COPYING in this directory.
Since Stefan Kaspar sits in the office next to mine I am certain that
I would be aware of a license change. The current file looks like the
following:
// This file is part of the source of ApCoCoALib, the ApCoCoA Library.
//
// Copyright (c) ApCoCoA Project (Prof. Dr. Martin Kreuzer, Uni
Passau)
//
// Author: 2006, 2007 Stefan Kaspar
//
// Visit http://apcocoa.org/ for more information regarding ApCoCoA
// and ApCoCoALib.
// Visit http://www.apcocoa.org/wiki/ApCoCoA:KnownIssues for bugs,
problems
// and known issues.
//
// ApCoCoALib is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License (version 2 or
later)
// as published by the Free Software Foundation. A copy of the full
// licence may be found in the file COPYING in this directory.
Five months ago this it was:
// Copyright (c) 2006, 2007 Stefan Kaspar
//
// Visit http://apcocoa.org/ for more information regarding ApCoCoA
// and ApCoCoALib.
// visit http://www.apcocoa.org/wiki/ApCoCoA:KnownIssues for bugs,
problems
// and known issues.
//
// ApCoCoALib is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License (version 2 or
later)
// as published by the Free Software Foundation. A copy of the full
// licence may be found in the file COPYING in this directory.
And three months before that it was:
// Copyright (c) 2006, 2007 Stefan Kaspar
//
// Visit http://apcocoa.org/ for more information regarding ApCoCoA
// and ApCoCoALib.
// visit http://www.apcocoa.org/wiki/ApCoCoA:KnownIssues for bugs,
problems
// and known issues.
//
// ApCoCoALib is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License (version 2)
// as published by the Free Software Foundation. A copy of the full
// licence may be found in the file COPYING in this directory.
The current CoCoALib 0.99.5 does not contain any FGLM related file.
So I am quite curious where a GPL V3 only TmpFFLM.c (the same applies
to LESystemSolver. [CH], too) is coming from. I did work closely with
the CoCoA team for 3+ years and have beyond 150 patches in CoCoA as
well as CoCoALib, so I am quite familiar with the people as well as
the code. Since the CoCoA Team does not own the copyright on those
files (they are part of ApCoCoALib) they cannot relicense those files.
> but they are required for the F5
> implementation in cocoa. This F5 is not used by default inside giac,
> it seems slower than cocoa standard reduction algorithm which is used
> (if CoCoA is detected), so that giac has a correct Groebner basis
> implementation. I'll certainly try to build a link to singular when
> I'll have some time (I didn't try before since it was not linkable as
> a library).
>
> > * It is likely that improved algorithms will need fast linear algebra
> > or some other goodies and writing interfaces to GIAC if we already
> > have them in Sage seems of little benefit to us.
>
> I believe that the main advantage for sage would be to use giac as an
> alternative for maxima for calculus, and that would be useful for giac
> since the number of users would grow. I'm working on the efficiency of
> the basic algorithm of giac (like polynomial arithmetic but also
> linear algebra, like determinant over the integers) mainly because
> they are required for that. They could be used inside sage until a
> better alternative is ready (and people could choose to implement new
> functions first instead). I'm also interested to use sage components
> to improve giac if possible, like I did with pari, ntl, cocoa (would
> you for example implement polynomial arithmetic so that it could be
> used from C++?).
Well, fast Symbolics is already being implemented and quite far
already. The gcd situation is also being looked at. That leaves
factorization and a ten time speedup is probably not enough of an
incentive now to get giac into Sage right now. It might be different
in the future, but from my perspective the "rapid growth phase" where
Sage did integrate huge external projects with a ot of overlap with
existing functionality into the standard distribution did end with
ATLAS. What is now being merged is usually small, specialized
libraries that do a couple things and do those particularly well. If
factorization could be broken out from giac in a reasonably small
package (like factory in Singular) we might have something to discuss,
but as a whole I do not see this as a good fit.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
