On Apr 12, 9:44 pm, parisse <[EMAIL PROTECTED]> wrote:
Hi,
> > 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.
>
> Well, I don't see why it is a concern since giac can be relicensed to
> version 2.
Sure, I was just pointing out that not everybody prefers the GPL V3.
> > > 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.
>
> This is the developer doc I plan to write someday, but it is currently
> not a main priority.
>
Sure, I understand that and since it is your time it is your call how
you allocate your resources. But it would make it much easier for us
to wrap the library if documentation existed.
>
> > 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.
>
> I believed that you would appreciate to see other developers focus on
> the aspects you do not want to develop themselves, like integration
> which BTW is far more than just implementing the Risch algorithm.
For use integration == Risch and limits == Grunt, they are not to be
taken literally.
> If you don't see any interest on integrating giac in sage, fine,
That is not what is the case here. There is certainly interest, but it
is no longer "easy" to get into Sage. We support or intend to support
different platforms than you run on and it is a concern that your code
runs on it. Since factorization is something essential it should not
be taken lightly and since I am the person who in the end will have to
deal a lot with those issues I am concerned because I have been burned
way to often during the last six months.
> as I
> said earlier I do not *need* sage, of course I would appreciate
> feedback from their users, but I can continue my way expanding giac
> and integrating the same libraries into giac (as sage does) and
> certainly I will not loose anymore time justifying me here when I read
> the ton of some of your next comments, like:
>
> > 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]:
Well, that reflects my personal opinion and around here we prefer to
be honest. After discussing GIAC in IRC right after your original post
I waited a while for somebody else to jump into the discussion and/or
volunteer to do some work. That didn't happen, so instead of just
ignoring you I wrote my honest opinion on things. Email certainly
isn't the best medium for discussion between people who don't know
each other and I had no intention of offending you personally or say
bad things about your code.
> >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
>
> Integration into sage would certainly help!
William did look at GIAC way back before he selected Maxima for Sage
years ago. One of the issues was build support. Another one was that
it didn't seem to have a large community. Not much seems to have
changed in that regard. So if you start providing things like a devel
mailing list, a public svn/hg/git it would give people a chance to
become involved. There are plenty of people around here who lurk and
might have taken a look at GIAC as a consequence of this discussion.
> > * unsatisfying documentation
>
> The focus in on xcas user documentation
>
> > * unkown build issues:
>
> of course, since they are unknown. Note however that it is ported to
> mac os and win and arm linux and wince.
Ok, arm support is good.
> > * unknown memory leak issues [Did you ever run valgrind? If not I
> > would highly recommend it]
>
> yes
Good.
> > * unknown portability issues: Sun Forte, MSVC, alignment problems,
> > endianess issues,
>
> see arm port. I never cared about sun or msvc.
Well, hear I would have really preferred to hear something like "I am
glad to integrate changes you might provide".
> > * 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.
>
> You would be surprised by the number of bugs that are caught by
> definite integration. Giac is certainly not bugfree but it can be and
> begins to be used as an alternative to maple.
Sure, but with any complex system changes on one end can cause
potential issues in other places. When we upgraded Maxima to 5.14.0 it
started getting certain limits wrong. I am sure they tested, but an
extensive test suite is important from my experience and our review
policy *mandates* doctests for any patch to be merged. I am not
implying your code is buggy, I am just saying that I would prefer a
large test suite because that is how we caught numerous build issues
in for example eclib.
> >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. ;)
>
> That is not the way I see collaboration. I will not do all the work
> myself.
Sure, the idea behind Sage is collaboration, but somebody has to get
the ball rolling. And that is usually the developer behind the code or
a Sage person who is interested in the functionality. Since nobody has
stepped up so far [that might change] the ball is in your court.
> >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.
>
> Obviously factorization depends on all the basic algorithms like gcd,
> polynomials etc. and it can not be isolated easily. And if it's the
> only thing you would be interested in giac, then there is indeed no
> need to continue this discussion :-)
I know that, but as Singular shows with libfactory it can be done. I
don't consider this discussion to be not worth your time. If you
consider that certain other features of GIAC are better than anything
else in Sage we need to know about them. It is your code, so you
should be able to tell us what to look at. I.e. a solver of non-linear
systems would also be interesting.
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
-~----------~----~----~----~------~----~------~--~---
