Re: [fricas-devel] New release

[Waldek Hebisch]

On Thu, Dec 07, 2023 at 09:19:51AM +0800, oldk1331 wrote:
> Hi Waldek, what's your holiday plan? I'll submit patches outside of
> that time frame.

I develop FriCAS inmy free time and expect to have more free time
during holidays...

-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/ZXZwYkW4T2Lrmgm3%40fricas.org.

Re: [fricas-devel] New release

[oldk1331]

Hi Waldek, what's your holiday plan? I'll submit patches outside of
that time frame.

- Qian

On Thu, Dec 7, 2023 at 8:43 AM Waldek Hebisch  wrote:
>
> I think that we should do new release early in January next year.
> I have rather long queue of thing "in making" and it will take
> long time to finish them.  But I think that we have valuable
> changes and should include what is ready intead of stretching
> release cycle.
>
> --
>   Waldek Hebisch
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/ZXEVKFK2_SQ_LucH%40fricas.org.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91BSd8QU8Zav%2B7C4DxzXZZ_Dnp_k7jhjjmyLCY-FxA4ig%40mail.gmail.com.

[fricas-devel] New release

[Waldek Hebisch]

I think that we should do new release early in January next year.
I have rather long queue of thing "in making" and it will take
long time to finish them.  But I think that we have valuable
changes and should include what is ready intead of stretching
release cycle.

-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/ZXEVKFK2_SQ_LucH%40fricas.org.

Re: [fricas-devel] New release

[Waldek Hebisch]

On Fri, Mar 06, 2020 at 09:25:54PM +0100, Kurt Pagani wrote:
> Good :)
> 
> BTW I compiled yesterday the current rev (fresh clone). I guess the version
> dates (2018) were already wrong in the last release (1.3.5 / 3 February 2019;
> according to https://en.wikipedia.org/wiki/FriCAS)? Or asked differently, is
> there a special policy?

Yes.  The policy is: in the mainline date is date of last modification
to configure.ac.  Release gets number and no date.

-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200307131919.GA36954%40math.uni.wroc.pl.

Re: [fricas-devel] New release

[Kurt Pagani]

Good :)

BTW I compiled yesterday the current rev (fresh clone). I guess the version
dates (2018) were already wrong in the last release (1.3.5 / 3 February 2019;
according to https://en.wikipedia.org/wiki/FriCAS)? Or asked differently, is
there a special policy?


   FriCAS Computer Algebra System
 Version: FriCAS 2018-03-10
   Timestamp: Thu Mar  5 20:11:13 CET 2020
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-


(1) -> )version
Value = "FriCAS 2018-03-10 compiled at Thu Mar  5 20:11:13 CET 2020"
(1) ->



On 06.03.2020 19:25, Waldek Hebisch wrote:
> Trunk is now closed for release.  In next days I will add
> release notes, create release branch and tarballs.
> 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/9237e83a-091f-3c6b-34e6-fb3cc611e41f%40gmail.com.

[fricas-devel] New release

[Waldek Hebisch]

Trunk is now closed for release.  In next days I will add
release notes, create release branch and tarballs.

-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200306182527.GA30127%40math.uni.wroc.pl.

Re: [fricas-devel] New release

[Waldek Hebisch]

On Mon, Mar 02, 2020 at 03:36:34AM +0100, Kurt Pagani wrote:
> On 29.02.2020 15:15, Waldek Hebisch wrote:
> 
> > The attached diff solves TeX problem in similar but I
> > think slightly better way.  
> 
> Indeed, perfect (tex_rev2620.pdf). Thanks!
> 
> It may also work for TeXmacs,
> > but that I did not test it.  In particular I do not know
> > if "" is the right TeXmacs sequence to get derivative sign.
> > 
> 
> Unfortunately, TeXmacs doesn't recognize  (tm_rev2620.pdf file).
> I use texmacs only with latex commands, i.e. I do not know many key bindings 
> and
> the like. It seems, however, that when entering "\prime" in TM, it doesn't 
> work
> either (unless sent via an ESC interface sequence). All I found so far:
> 
> http://www.texmacs.org/tmweb/manual/webman-math.en.html
> 3.Main mathematical constructs
>   Primes, subscripts and superscripts are created as follows:
>   Shortcut  Purpose
>   ' Primes
>   ??? Back-primes
> 
> Maybe one could define a macro in TM to define ? I've no clue at the 
> moment.

Well, it seems that the patch get rid of string qoutes (that was
regression due to change in OutputForm).  So I commited part of
the patch, but without '' part for Texmacs.  If anybody
knows how to send proper derivative sign to Texmacs please say
(or propose a patch).  Otherwise Texmacs interface will be back
at older behaviour, not great but IIRC no so bad either.

-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200302164630.GA4227%40math.uni.wroc.pl.

Re: [fricas-devel] New release

[Neven Sajko]

On Sat, 29 Feb 2020 at 17:38, Ralf Hemmecke  wrote:
>
> >> one need not be forced to use github/gitlab workflows of pull/merge
> >> requests. One can instead work with named branches.
> >
> > Well, for FriCAS traditional branches are of limited use.  My
> > main developement flow is interactive, compiling only edited
> > files and loading them, while if possible reusing test data
> > stored in the executing image.  In fact, for new code I prefer
> > interpreter where I can work out expressions on command line,
> > then wrap them in a function, gradualy function by function
> > growing the code.  Neither git nor svn help with this.
>
> Sorry to say, but you are wrong at least if you use git.
>
> Forget about the idea that "a commit is something that lives forever in
> the repository". You should rather consider git to be a database that
> you can freely modify.
>
> The "master" branch is usually used for "linear" development as you know
> it from svn trunk.
>
> When you do development locally, you say
>
>git checkout -b NEW-BRANCH-NAME
>
> and all commit you ever do on this branch is never seen by anyone else
> unless you push it somewhere. So you can commit after each function you
> add to the code. That are, let's say 20 commits. When everything works
> for you, you can now decide what to do with all thoses commits.
>
> 1) Merge your commit into the master branch.
>git checkout master
>git merge NEW-BRANCH-NAME
> 2) Rebase your changes on top of the new master branch in case
>the master branch has meanwhile progressed by commits from other
>people.
>git rebase master
># now "fast-forward" the master branch
>git checkout master
>git merge --ff-only NEW-BRANCH-NAME
> 3) You don't want other people to see you intermediate commits, i.e.,
>you want to put just one commit on top of master. So you squash all
>your 20 commits into just one.
>
>git rebase -i HEAD~21
>
>This brings you into an interaction with git where you can say what
>to do with the commits. Except for the first, you mark them as "fix".
>
>After that you do (1) or (2) from above.
>
> Later you say
> git branch -D NEW-BRANCH-NAME
> and your development branch is gone as if it has never existed.
>
> https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
>
> Why do you think that doesn't help? Because you do not want to use git
> locally for your own safety? It might happen that you develop two
> features at the same time. Working on different branches allows you to
> keep the feature commits separated without the need to open differnt
> working directories.
>
> >> The projects that stick to cvs or svn suffer, as cvs and svn are legacy
> >> tools, and forcing it on contributors is counterproductive.
> >
> > Well, I used cvs and svn was a definite progress compared to cvs.
> > Not so with git, at least for projects like FriCAS.  I understand
> > that there is familiarity factor, different tool feels clumsy
> > because it is different, regardless of objective features.  OTOH
> > which version control software is in use should not matter much
> > for contributors, main work is elsewere.
>
> Don't you think that some contributors feel like "oh they are still
> using git... uff that's not modern. Let's look somewhere else...".
>
> Of course, main work is somewhere else, but if the first hurdle is
> unnecessarily high, that's not good. I'm sure you are clever enough to
> learn git than it is for the younger generation to go back and learn svn.
>
> Ralf

Just to add to this message, git supports an interactive rebase history
editing feature. One runs, e.g., git rebase -i master (note the "-i"),
which lets do user select which commits should be edited, squashed,
reordered, etc.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAL%2BbK4PF-U1JhqA6%3DUh5kDkOvf9Gh_mSSxpEuSPqo6jDpysj7w%40mail.gmail.com.

Re: [fricas-devel] New release

[Bill Page]

On Sat, Feb 29, 2020 at 11:02 AM Dima Pasechnik  wrote:
> ...
> The projects that stick to cvs or svn suffer,
> as cvs and svn are legacy tools, and forcing
> it on contributors is counterproductive.
>

+1 for git. Please.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAC6x94T6_xJ_VM1V1Yy5eb7JVk1AuTMrsj%3DjiCoDoqGsRW6XKw%40mail.gmail.com.

Re: [fricas-devel] New release

[Ralf Hemmecke]

>> one need not be forced to use github/gitlab workflows of pull/merge
>> requests. One can instead work with named branches.
> 
> Well, for FriCAS traditional branches are of limited use.  My
> main developement flow is interactive, compiling only edited
> files and loading them, while if possible reusing test data
> stored in the executing image.  In fact, for new code I prefer
> interpreter where I can work out expressions on command line,
> then wrap them in a function, gradualy function by function
> growing the code.  Neither git nor svn help with this.

Sorry to say, but you are wrong at least if you use git.

Forget about the idea that "a commit is something that lives forever in
the repository". You should rather consider git to be a database that
you can freely modify.

The "master" branch is usually used for "linear" development as you know
it from svn trunk.

When you do development locally, you say

   git checkout -b NEW-BRANCH-NAME

and all commit you ever do on this branch is never seen by anyone else
unless you push it somewhere. So you can commit after each function you
add to the code. That are, let's say 20 commits. When everything works
for you, you can now decide what to do with all thoses commits.

1) Merge your commit into the master branch.
   git checkout master
   git merge NEW-BRANCH-NAME
2) Rebase your changes on top of the new master branch in case
   the master branch has meanwhile progressed by commits from other
   people.
   git rebase master
   # now "fast-forward" the master branch
   git checkout master
   git merge --ff-only NEW-BRANCH-NAME
3) You don't want other people to see you intermediate commits, i.e.,
   you want to put just one commit on top of master. So you squash all
   your 20 commits into just one.

   git rebase -i HEAD~21

   This brings you into an interaction with git where you can say what
   to do with the commits. Except for the first, you mark them as "fix".

   After that you do (1) or (2) from above.

Later you say
git branch -D NEW-BRANCH-NAME
and your development branch is gone as if it has never existed.

https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

Why do you think that doesn't help? Because you do not want to use git
locally for your own safety? It might happen that you develop two
features at the same time. Working on different branches allows you to
keep the feature commits separated without the need to open differnt
working directories.

>> The projects that stick to cvs or svn suffer, as cvs and svn are legacy
>> tools, and forcing it on contributors is counterproductive.
> 
> Well, I used cvs and svn was a definite progress compared to cvs.
> Not so with git, at least for projects like FriCAS.  I understand
> that there is familiarity factor, different tool feels clumsy
> because it is different, regardless of objective features.  OTOH
> which version control software is in use should not matter much
> for contributors, main work is elsewere.

Don't you think that some contributors feel like "oh they are still
using git... uff that's not modern. Let's look somewhere else...".

Of course, main work is somewhere else, but if the first hurdle is
unnecessarily high, that's not good. I'm sure you are clever enough to
learn git than it is for the younger generation to go back and learn svn.

Ralf

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/9e07d6ba-3e32-2fcd-49d5-e9da0db5bbab%40hemmecke.org.

Re: [fricas-devel] New release

[Dima Pasechnik]

On Sat, 29 Feb 2020, 09:51 Waldek Hebisch,  wrote:

> On Sat, Feb 29, 2020 at 11:01:45AM -0500, Dima Pasechnik wrote:
> > On Sat, 29 Feb 2020, 08:11 Waldek Hebisch, 
> wrote:
> >
> > > On Sat, Feb 29, 2020 at 03:48:43PM +0100, Ralf Hemmecke wrote:
> > > > > ATM master sources are in svn, so diff is better than pull request.
> > > >
> > > > When do we switch to git?
> > > >
> > >
> > > Well, some time ago I thought that I am almost ready for switch.
> > > But then Camm Maguire wrote "fetch this special gcl branch".
> > > Given branch name it worked, but without knowing the name
> > > I was unable to find it in gcl git repo.
> >
> >
> > saying "check out that very special commit"  from svn repo does not get
> one
> > far either.
> >
> > So either git
> > > allows you to create invisible branches,
> >
> >
> > git branch
> >
> > lets you list all the  branches on a repo.
> > Branch is basically a label for a well-behaved subset of commits, not
> much
> > more than that.
> > (there are also tags, something a bit different)
>
> So I thought.  But all my attempts to list the branch, of course
> starting form 'git branch' failed.  Yet knowing the name switch
> to the branch worked.
>

I gather that you switched to a "tag", i.e. a frozen branch (listed by "git
tag")
gcl git repo does not use branches, as far as I can tell,
it uses tags only (the difference is that branches are mutable, whereas
tags are not).

No wonder that

git branch

does not report anything interesting

dimpase@penguin:/tmp/gcl$ git branch
* master

whereas

there are quite a few tags:

dimpase@penguin:/tmp/gcl$ git tag | wc -l
175

e.g.
dimpase@penguin:/tmp/gcl$ git tag | grep list_order.21
list_order.21

and so one can do

dimpase@penguin:/tmp/gcl$ git checkout list_order.21
Note: checking out 'list_order.21'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b 

HEAD is now at 918026228 undef SGC on alpha for now




> > which I consider
> > > evil, or I my understanding of git is way below what is
> > > needed to effectivly use it.  I use git for less important
> > > projects, so I can survive using it.  But I feel that
> > > for me to use it for FriCAS developement is still too
> > > inefficient and risky.
> > >
> >
> > one need not be forced to use github/gitlab workflows of pull/merge
> > requests. One can instead work with named branches.
>
> Well, for FriCAS traditional branches are of limited use.  My
> main developement flow is interactive, compiling only edited
> files and loading them, while if possible reusing test data
> stored in the executing image.  In fact, for new code I prefer
> interpreter where I can work out expressions on command line,
> then wrap them in a function, gradualy function by function
> growing the code.  Neither git nor svn help with this.
>

git and other VCS are mostly for keeping track of the history of changes (I
presume you commit your code to master once in a while), and for
testing/merging work of
different people. It's pretty much orthogonal to developing code (unless
you/your collaborators work on different features, and
merging them as you go along - in this case branches are useful even
locally).

Another extremely useful feature of git is that's easy to set up automated
continuous integration
(you certainly don't want to wait for tests for all the different Lisp
compilers you support, if you want to check something, and this is very
easy with git repo hosted on GitHub or GitLab, you just push a commit
there, and
the builds and the tests are run automatically, somethething that doing
manually can take days if not weeks)



> > 
> >
> > The bottom line is that nowadays most people either never used svn, or
> > already forgot all about it.
> >
> > (yes, I did use svn for  a year in 1999 a lot, and for few more years
> later
> > too, a bit, but now it is a source of major annoyance if I need to use
> it,
> > it's like going back to Fortran 4 or punchcards).
> >
> > The projects that stick to cvs or svn suffer, as cvs and svn are legacy
> > tools, and forcing it on contributors is counterproductive.
>
> Well, I used cvs and svn was a definite progress compared to cvs.
> Not so with git, at least for projects like FriCAS.  I understand
> that there is familiarity factor, different tool feels clumsy
> because it is different, regardless of objective features.  OTOH
> which version control software is in use should not matter much
> for contributors, main work is elsewere.
>

svn is, however a major stubling block fo people who want to do an
occasional contribution, and
have no clue about svn, and it's not only to them, but to the project:
surely they can email a 

Re: [fricas-devel] New release

[Waldek Hebisch]

On Sat, Feb 29, 2020 at 11:01:45AM -0500, Dima Pasechnik wrote:
> On Sat, 29 Feb 2020, 08:11 Waldek Hebisch,  wrote:
> 
> > On Sat, Feb 29, 2020 at 03:48:43PM +0100, Ralf Hemmecke wrote:
> > > > ATM master sources are in svn, so diff is better than pull request.
> > >
> > > When do we switch to git?
> > >
> >
> > Well, some time ago I thought that I am almost ready for switch.
> > But then Camm Maguire wrote "fetch this special gcl branch".
> > Given branch name it worked, but without knowing the name
> > I was unable to find it in gcl git repo.
> 
> 
> saying "check out that very special commit"  from svn repo does not get one
> far either.
> 
> So either git
> > allows you to create invisible branches,
> 
> 
> git branch
> 
> lets you list all the  branches on a repo.
> Branch is basically a label for a well-behaved subset of commits, not much
> more than that.
> (there are also tags, something a bit different)

So I thought.  But all my attempts to list the branch, of course
starting form 'git branch' failed.  Yet knowing the name switch
to the branch worked.

> which I consider
> > evil, or I my understanding of git is way below what is
> > needed to effectivly use it.  I use git for less important
> > projects, so I can survive using it.  But I feel that
> > for me to use it for FriCAS developement is still too
> > inefficient and risky.
> >
> 
> one need not be forced to use github/gitlab workflows of pull/merge
> requests. One can instead work with named branches.

Well, for FriCAS traditional branches are of limited use.  My
main developement flow is interactive, compiling only edited
files and loading them, while if possible reusing test data
stored in the executing image.  In fact, for new code I prefer
interpreter where I can work out expressions on command line,
then wrap them in a function, gradualy function by function
growing the code.  Neither git nor svn help with this.

> 
> 
> The bottom line is that nowadays most people either never used svn, or
> already forgot all about it.
> 
> (yes, I did use svn for  a year in 1999 a lot, and for few more years later
> too, a bit, but now it is a source of major annoyance if I need to use it,
> it's like going back to Fortran 4 or punchcards).
> 
> The projects that stick to cvs or svn suffer, as cvs and svn are legacy
> tools, and forcing it on contributors is counterproductive.

Well, I used cvs and svn was a definite progress compared to cvs.
Not so with git, at least for projects like FriCAS.  I understand
that there is familiarity factor, different tool feels clumsy
because it is different, regardless of objective features.  OTOH
which version control software is in use should not matter much
for contributors, main work is elsewere.

-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200229165118.GA36920%40math.uni.wroc.pl.

Re: [fricas-devel] New release

[Dima Pasechnik]

On Sat, 29 Feb 2020, 08:11 Waldek Hebisch,  wrote:

> On Sat, Feb 29, 2020 at 03:48:43PM +0100, Ralf Hemmecke wrote:
> > > ATM master sources are in svn, so diff is better than pull request.
> >
> > When do we switch to git?
> >
>
> Well, some time ago I thought that I am almost ready for switch.
> But then Camm Maguire wrote "fetch this special gcl branch".
> Given branch name it worked, but without knowing the name
> I was unable to find it in gcl git repo.


saying "check out that very special commit"  from svn repo does not get one
far either.

So either git
> allows you to create invisible branches,


git branch

lets you list all the  branches on a repo.
Branch is basically a label for a well-behaved subset of commits, not much
more than that.
(there are also tags, something a bit different)


which I consider
> evil, or I my understanding of git is way below what is
> needed to effectivly use it.  I use git for less important
> projects, so I can survive using it.  But I feel that
> for me to use it for FriCAS developement is still too
> inefficient and risky.
>

one need not be forced to use github/gitlab workflows of pull/merge
requests. One can instead work with named branches.



The bottom line is that nowadays most people either never used svn, or
already forgot all about it.

(yes, I did use svn for  a year in 1999 a lot, and for few more years later
too, a bit, but now it is a source of major annoyance if I need to use it,
it's like going back to Fortran 4 or punchcards).

The projects that stick to cvs or svn suffer, as cvs and svn are legacy
tools, and forcing it on contributors is counterproductive.


Dima



> --
>   Waldek Hebisch
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/20200229151147.GA12206%40math.uni.wroc.pl
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAAWYfq3RSn5z665zbcfNbBuTAZXqkm%2BohWnb7g6GdHZxTrD%3D8Q%40mail.gmail.com.

Re: [fricas-devel] New release

[Waldek Hebisch]

On Sat, Feb 29, 2020 at 03:48:43PM +0100, Ralf Hemmecke wrote:
> > ATM master sources are in svn, so diff is better than pull request.
> 
> When do we switch to git?
>

Well, some time ago I thought that I am almost ready for switch.
But then Camm Maguire wrote "fetch this special gcl branch".
Given branch name it worked, but without knowing the name
I was unable to find it in gcl git repo.  So either git
allows you to create invisible branches, which I consider
evil, or I my understanding of git is way below what is
needed to effectivly use it.  I use git for less important
projects, so I can survive using it.  But I feel that
for me to use it for FriCAS developement is still too
inefficient and risky.
 
-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200229151147.GA12206%40math.uni.wroc.pl.

Re: [fricas-devel] New release

[Ralf Hemmecke]

> ATM master sources are in svn, so diff is better than pull request.

When do we switch to git?

Ralf

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/e23d1bb3-ecae-9a58-bd85-6adf4e361c84%40hemmecke.org.

Re: [fricas-devel] New release

[Waldek Hebisch]

On Fri, Feb 28, 2020 at 01:45:53PM -0800, Neven Sajko wrote:
> Waldek, Ralf; regarding my previous email, I should have mentioned that
> info about stack and heap limits and how to raise them should be
> documented better for users of Fricas. Probably should go into the
> INSTALL file. Do you want a Github pull request, or something?

ATM master sources are in svn, so diff is better than pull request.
And in case of INSTALL, if you have better wording in mind you
may just post relevant passage here.

-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200229143300.GD31425%40math.uni.wroc.pl.

Re: [fricas-devel] New release

[Waldek Hebisch]

On Fri, Feb 28, 2020 at 12:05:12AM +0100, Ralf Hemmecke wrote:
> On 2/27/20 10:41 PM, Kurt Pagani wrote:
> 
> The problem is not the conversion to TeX, but rather a strange way of
> storing that in OutputForm.
> 
> (12) -> (eq1 :: OutputForm) pretend SExpression
> 
>(12)  (= ((PRIME f ",,,") x) (^ x n))
> 
> Wouldn't it make more sense to store it as (PRIME f 3) and let the
> Formatter deal with how it is shown?

At first glance it looks attractive.  But currently higher derivative
use Roman numerals.  IMO decision between primes, roman numeral
and may be arabic is somewhat higher level and should be common to
all formatters.  To say the truth, calling roman convertion from
Boot code is somewhat awkward, so it is simpler to do this at
higher level.

> Here eq1::OutputForm does too much.
> In other words, I would be in favour of moving the code
> 
> add_prime(a : %, s : %) : % == convert [eform 'PRIME, a, s]
> prime(a, nn) == (s := new(nn, char ",");  add_prime(a, sform s))
> 
> away from OutputForm and simply say something like
> 
>prime(a, nn) ==
>   if a is of form (PRIME x n) then
>(PRIME x n+nn)
>   else
>(PRIME a nn)

Hmm, I am not sure what you mean here.  AFAICS you propose new
behaviour not present in current code.  And it looks that you
hardcode here associative property of PRIME.  This may be not
bad, but before writing such code it would be good to say
which transformation OutputForm can do and which are not allowed.
For example we may have "commutative and associative +" which
OutputForm may rearrange and looking the same "literal +"
which is considered non-commutative and non-associative.
Or maybe do it in different way, say via rigid and flexible
trees (OutputForm would be allowed to rearrange flexible tree,
but preseve tree structure of rigid ones).
 
-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200229142947.GC31425%40math.uni.wroc.pl.

Re: [fricas-devel] New release

[Waldek Hebisch]

On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:
> I'd like to point out two small issues. Would be great if one or the other 
> could
> be resolved in a next release:
> 
> -- The (TexFormat) output of derivatives of (univariate) functions looks ugly.
> Examples:
> - http://fricas-wiki.math.uni.wroc.pl/TexFormat0
> - http://fricas-wiki.math.uni.wroc.pl/DerivFunc
> 
> The same also holds for TeXmacs (see attached pdf).
> 
> Personally, I'm using a slightly hacked version of TexFormat:
> - http://fricas-wiki.math.uni.wroc.pl/TexFormat1
> Maybe someone has a better idea (op 'PRIME)?

The attached diff solves TeX problem in similar but I
think slightly better way.  It may also work for TeXmacs,
but that I did not test it.  In particular I do not know
if "" is the right TeXmacs sequence to get derivative sign.
-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200229141527.GB31425%40math.uni.wroc.pl.
Index: src/algebra/formula.spad
===
--- src/algebra/formula.spad	(revision 2620)
+++ src/algebra/formula.spad	(working copy)
@@ -253,7 +253,8 @@
   op = "PAREN" =>
 group parenthesize formatFormula(first args, minPrec)
   op = "PRIME" =>
-  formatSpecial("SUPERSUB", [first args, " "::E, second(args)], prec)
+  formatSpecial("SUPERSUB", [first args, empty()$E,
+ second(args)], prec)
   op = "OVERBAR" =>
 empty?(args) => ""
 group concat [formatFormula(first args, minPrec)," bar"]
Index: src/algebra/mathml.spad
===
--- src/algebra/mathml.spad	(revision 2620)
+++ src/algebra/mathml.spad	(working copy)
@@ -740,7 +740,7 @@
s := s""
if commaS = commaTest then
arg2 := message(s)
-formatSpecial('SUPERSUB, [first args, " "::E, arg2], prec)
+formatSpecial('SUPERSUB, [first args, empty()$E, arg2], prec)
 
 formatPlex(op : Sy, args : L E, prec : I) : S ==
 p : I := position(op, plexOps)
Index: src/algebra/tex.spad
===
--- src/algebra/tex.spad	(revision 2620)
+++ src/algebra/tex.spad	(working copy)
@@ -319,6 +319,27 @@
 parenthesize str ==
   concat ["\left( ",str," \right)"]
 
+format_prime(args : L E, prec : I) : S ==
+arg2 := second(args)
+narg2 :=
+string?(arg2) =>
+arg2s : S := string(arg2)
+c_char := char(",")
+every?(c +-> c = c_char, arg2s) =>
+prime_str := "\prime"
+n := #arg2s
+n = 1 => message(prime_str)
+res := new(n*#prime_str, char(" "))
+k := 1
+for i in 1..n repeat
+for j in 1..#prime_str repeat
+qsetelt!(res, k, qelt(prime_str, j))
+k := k + 1
+message(res)
+arg2
+arg2   
+formatSpecial('SUPERSUB, [first args, empty()$E, narg2], prec)
+
 formatSpecial(op : Sy, args : L E, prec : I) : S ==
 arg : E
 prescript : Boolean := false
@@ -352,7 +373,7 @@
 op = 'PAREN =>
 group parenthesize ungroup formatExpr(first args, minPrec)
 op = 'PRIME =>
-formatSpecial('SUPERSUB, [first args, " "::E, second(args)], prec)
+format_prime(args, prec)
 op = 'OVERBAR =>
 empty?(args) => ""
 group concat ["\overline ", formatExpr(first args, minPrec)]
Index: src/algebra/texmacs.spad
===
--- src/algebra/texmacs.spad	(revision 2620)
+++ src/algebra/texmacs.spad	(working copy)
@@ -998,6 +998,27 @@
 parenthesize str ==
   concat [" _"(_" ",str," _")_" "]
 
+format_prime(args : L E, prec : I) : S ==
+arg2 := second(args)
+narg2 :=
+string?(arg2) =>
+arg2s : S := string(arg2)
+c_char := char(",")
+every?(c +-> c = c_char, arg2s) =>
+prime_str := ""
+n := #arg2s
+n = 1 => message(prime_str)
+res := new(n*#prime_str, char(" "))
+k := 1
+for i in 1..n repeat
+for j in 1..#prime_str repeat
+qsetelt!(res, k, qelt(prime_str, j))
+k := k + 1
+ 

Re: [fricas-devel] New release

[Waldek Hebisch]

On Fri, Feb 28, 2020 at 07:40:22PM +0100, Kurt Pagani wrote:
> On 28.02.2020 17:58, Waldek Hebisch wrote:
> > On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:
> >>
> >> The second issue concerns big files (compile or read doesn't matter):
> >>
> >>
> >> --ECL
> >> -- (1) -> )r bigfile
> >> --
> >> --   >> System error:
> >> --   C-STACK overflow at size 1042432. Stack can probably be resized.
> >> -- Proceed with caution.
> >>
> >> --SBCL
> >> --  >> System error:
> >> --   Control stack exhausted (no more space for function call frames).
> >> -- This is probably due to heavily nested or infinitely recursive function
> >> -- calls, or a tail call that SBCL cannot or has not optimized away.
> >> --
> >> -- PROCEED WITH CAUTION.
> >>
> >> Example:
> >> - http://fricas-wiki.math.uni.wroc.pl/AWAIC
> > 
> > That one looks like sbcl bug: stack overflow is during lisp compilation.
> 
> Yes, ECL and ABCL the same/similar.

With ECL (using current stable release, that is 16.1.3) compilation
worked for me.  It took long time, 180s for spad and List to C compilation
and more than 10 minutes for C compilation.  And gcc produced
message that it run out of storage for variable tracking but
eventually produced object file.

> > 
> >> - attached bigfile.input (mostly comments, ~30k lines)
> >>

Should be fixed now.

> The strange thing is that the (compiled) AWAIC example
> (http://fricas-wiki.math.uni.wroc.pl/AWAIC) worked some years ago. 
> Unfortunately
> I can't remember which Fricas version. I found one old version only (1.2.7,
> 2016) and this one is able to read the bigile but cannot compile the AWAIC
> either.

AFAICS this is mostly Lisp compiler thing.  Compared to older version
sbcl significantly increased it memory use during compilation.
One possible option may be to lower optimization settings in
sbcl to profer compilation speed over code speed (after all, this
code is executed once per session...).

-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200229141105.GA31425%40math.uni.wroc.pl.

Re: [fricas-devel] New release

[Neven Sajko]

Waldek, Ralf; regarding my previous email, I should have mentioned that
info about stack and heap limits and how to raise them should be
documented better for users of Fricas. Probably should go into the
INSTALL file. Do you want a Github pull request, or something?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/a821ecc4-9e91-4ed4-bf63-3fd4b42f0dec%40googlegroups.com.

Re: [fricas-devel] New release

[Kurt Pagani]

Thanks for the hint. Actually this was discussed several times in the forum:

https://groups.google.com/forum/#!searchin/fricas-devel/dynamic-space-size%7Csort:date

Nevertheless this might be always an option, as a last resort ;)
If it could be fixed in the code, however, then it should be done.

BTW I wasn't aware of https://aur.archlinux.org/packages/?O=0=fricas
a fricas package. Very interesting!

https://aur.archlinux.org/packages/fricas/

This ought to be mentioned somewhere (@Ralf: maybe http://fricas.github.io/)



On 28.02.2020 22:28, Neven Sajko wrote:
>> The second issue concerns big files (compile or read doesn't matter):
>> ...
>> --SBCL
>> -- >> System error:
>> -- Control stack exhausted (no more space for function call frames).
>> -- This is probably due to heavily nested or infinitely recursive function
>> -- calls, or a tail call that SBCL cannot or has not optimized away.
> 
> SBCL imposes limits on stack and heap size. To configure them (increase
> the limits), run configure before compiling Fricas like this:
> 
> ./configure '--with-lisp=sbcl --control-stack-size 512 --dynamic-space-size 
> 6000'
> 
> This are, in fact, the exact options used in the Archlinux AUR package
> for Fricas.
> 
> Warning: these limits may be too high if Fricas runs on a system with
> limited memory. On the other hand one may want to use even greater
> limits if enough memory is available (e.g., on a server computer).
> 
> I guess similar adjustments may be possible for ECL.
> 
> -- 
> 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+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/d669ca75-c7c6-46da-a240-15b4f831e24b%40googlegroups.com
> .

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/41898b3c-0dc6-fbdd-925d-9b980e8172c0%40gmail.com.

Re: [fricas-devel] New release

[Neven Sajko]

> The second issue concerns big files (compile or read doesn't matter):
> ...
> --SBCL 
> -- >> System error: 
> -- Control stack exhausted (no more space for function call frames). 
> -- This is probably due to heavily nested or infinitely recursive 
function 
> -- calls, or a tail call that SBCL cannot or has not optimized away. 

SBCL imposes limits on stack and heap size. To configure them (increase
the limits), run configure before compiling Fricas like this:

./configure '--with-lisp=sbcl --control-stack-size 512 --dynamic-space-size 
6000'

This are, in fact, the exact options used in the Archlinux AUR package
for Fricas.

Warning: these limits may be too high if Fricas runs on a system with
limited memory. On the other hand one may want to use even greater
limits if enough memory is available (e.g., on a server computer).

I guess similar adjustments may be possible for ECL.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/d669ca75-c7c6-46da-a240-15b4f831e24b%40googlegroups.com.

Re: [fricas-devel] New release

[Kurt Pagani]

On 28.02.2020 17:58, Waldek Hebisch wrote:
> On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:
>>
>> The second issue concerns big files (compile or read doesn't matter):
>>
>>
>> --ECL
>> -- (1) -> )r bigfile
>> --
>> --   >> System error:
>> --   C-STACK overflow at size 1042432. Stack can probably be resized.
>> -- Proceed with caution.
>>
>> --SBCL
>> --  >> System error:
>> --   Control stack exhausted (no more space for function call frames).
>> -- This is probably due to heavily nested or infinitely recursive function
>> -- calls, or a tail call that SBCL cannot or has not optimized away.
>> --
>> -- PROCEED WITH CAUTION.
>>
>> Example:
>> - http://fricas-wiki.math.uni.wroc.pl/AWAIC
> 
> That one looks like sbcl bug: stack overflow is during lisp compilation.

Yes, ECL and ABCL the same/similar.

> 
>> - attached bigfile.input (mostly comments, ~30k lines)
>>
>> I'm wondering why reading a file uses recursion?
>  
> Recursion in general is reasonable.  

Dear me, nothing against recursion. I forgot the 'scanner', probably because one
is used to read the whole file into memory before preocessing nowadays (e.g.
Python).

> Our scanned uses too complicated
> method which usually keeps recursion depth low.  But on long
> streches of comments the method backfires and recursion depth
> is very high.  Adding some actual code (so distnce between executable
> lines is at most 5000) between comment makes problem go away,
> so it there is at least partial workaround.  Anyway, I was
> thinking about simplifyng scanner, but up to now "do not fix
> what is not broken" won.  Now I will have good excuse
> to work on it.  To say the truth I am more worried about
> releated problem: skiping long parts using ')if' and ')endif'
> also leads to crash...
> 

The strange thing is that the (compiled) AWAIC example
(http://fricas-wiki.math.uni.wroc.pl/AWAIC) worked some years ago. Unfortunately
I can't remember which Fricas version. I found one old version only (1.2.7,
2016) and this one is able to read the bigile but cannot compile the AWAIC
either. By the way, I thought it wouldn't matter whether comments or commands
are read, however, this seems not to be case, indeed (the snippet below creates
a file that runs with 100k lines without any problem at all). So mucht the more
I'm wondering why the AWAIC won't compile. It's certainly not a problem of
upmost priority, though.

---
N:=10
f:=open("bigfile2.input"::FileName,"output")$TextFile
writeLine!(f,"X:=[0 for i in 1.." string(N) "]")
for i in 1..N repeat
  writeLine!(f,"X." string(i) ":=random(" string(N) ")")
close!(f)
)q

---



(2) -> )r bigfile
x:=0


   (2)  0
 Type: NonNegativeInteger
(3) -> x

   (3)  0
 Type: NonNegativeInteger
(4) -> )lisp (lisp-implementation-version)

Value = "1.3.0"
(4) -> )lisp (lisp-implementation-type)

Value = "SBCL"

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/182cb7a7-7dca-d278-4e3d-3a52b70c84e0%40gmail.com.

Re: [fricas-devel] New release

[Waldek Hebisch]

On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:
> 
> The second issue concerns big files (compile or read doesn't matter):
> 
> 
> --ECL
> -- (1) -> )r bigfile
> --
> --   >> System error:
> --   C-STACK overflow at size 1042432. Stack can probably be resized.
> -- Proceed with caution.
> 
> --SBCL
> --  >> System error:
> --   Control stack exhausted (no more space for function call frames).
> -- This is probably due to heavily nested or infinitely recursive function
> -- calls, or a tail call that SBCL cannot or has not optimized away.
> --
> -- PROCEED WITH CAUTION.
> 
> Example:
> - http://fricas-wiki.math.uni.wroc.pl/AWAIC

That one looks like sbcl bug: stack overflow is during lisp compilation.

> - attached bigfile.input (mostly comments, ~30k lines)
>
> I'm wondering why reading a file uses recursion?
 
Recursion in general is reasonable.  Our scanned uses too complicated
method which usually keeps recursion depth low.  But on long
streches of comments the method backfires and recursion depth
is very high.  Adding some actual code (so distnce between executable
lines is at most 5000) between comment makes problem go away,
so it there is at least partial workaround.  Anyway, I was
thinking about simplifyng scanner, but up to now "do not fix
what is not broken" won.  Now I will have good excuse
to work on it.  To say the truth I am more worried about
releated problem: skiping long parts using ')if' and ')endif'
also leads to crash...

-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200228165849.GB17944%40math.uni.wroc.pl.

Re: [fricas-devel] New release

[Kurt Pagani]

> 
> The problem is not the conversion to TeX, but rather a strange way of
> storing that in OutputForm.
> 
> (12) -> (eq1 :: OutputForm) pretend SExpression
> 
>(12)  (= ((PRIME f ",,,") x) (^ x n))
> 

You're right, of course. The root of all evil (not all, though) in TEX is found
in OUTFORM. However, the line

https://github.com/fricas/fricas/blob/master/src/algebra/tex.spad @ line 354
op = 'PRIME =>
formatSpecial('SUPERSUB, [first args, " "::E, second(args)], prec)

makes it even worse. One might change " "::E to hspace(1), but the ugly ",,,"
will remain (I'd prefer ''' ;). In the console it looks ok.

> Wouldn't it make more sense to store it as (PRIME f 3) and let the
> Formatter deal with how it is shown? Here eq1::OutputForm does too much.
> In other words, I would be in favour of moving the code
> 
> add_prime(a : %, s : %) : % == convert [eform 'PRIME, a, s]
> prime(a, nn) == (s := new(nn, char ",");  add_prime(a, sform s))
> 
> away from OutputForm and simply say something like
> 
>prime(a, nn) ==
>   if a is of form (PRIME x n) then
>(PRIME x n+nn)
>   else
>(PRIME a nn)
> 
> Then i-output.boot or the various Formatters would have to deal with
> translating that s-expression into something nice.

Indeed, this would simplify the construction of a reasonable LaTeX string.
Moreover it could provide more flexibility (in TexFormat) for multivariate
functions as well (e.g. f_x, f_y instead of only f_{,1}, f_{,2}).

> 
> Ralf
> 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/1fb132e8-5dad-c1d0-f234-24382c521621%40gmail.com.

Re: [fricas-devel] New release

[Ralf Hemmecke]

On 2/27/20 10:41 PM, Kurt Pagani wrote:
> I'd like to point out two small issues. Would be great if one or the other 
> could
> be resolved in a next release:
> 
> -- The (TexFormat) output of derivatives of (univariate) functions looks ugly.
> Examples:
> - http://fricas-wiki.math.uni.wroc.pl/TexFormat0
> - http://fricas-wiki.math.uni.wroc.pl/DerivFunc

The problem is not the conversion to TeX, but rather a strange way of
storing that in OutputForm.

(12) -> (eq1 :: OutputForm) pretend SExpression

   (12)  (= ((PRIME f ",,,") x) (^ x n))

Wouldn't it make more sense to store it as (PRIME f 3) and let the
Formatter deal with how it is shown? Here eq1::OutputForm does too much.
In other words, I would be in favour of moving the code

add_prime(a : %, s : %) : % == convert [eform 'PRIME, a, s]
prime(a, nn) == (s := new(nn, char ",");  add_prime(a, sform s))

away from OutputForm and simply say something like

   prime(a, nn) ==
  if a is of form (PRIME x n) then
   (PRIME x n+nn)
  else
   (PRIME a nn)

Then i-output.boot or the various Formatters would have to deal with
translating that s-expression into something nice.

Ralf

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/894474ef-6987-878a-f065-0995043953aa%40hemmecke.org.

[fricas-devel] New release

[Waldek Hebisch]

I am thinking about new release.  To say the truth we have
quite long list of open bugs and it would be good to fix
some of them before release.  However there is long time
from last release, we have new code that should get more
use.  And most bugs probaly will require long time to fix.
For example several integration bugs should vanish if
we rewrite top level of integration routines, but seem
very hard to solve otherwise.  Similarly for limits.
I will write more about this in separate posts.

Concerning release, I would like to finish some features
that I started implementing and I have to fix a few
more bugs.  But I would like in two-three weeks to
have a cutoff (== only simple fixes or relase critical
bugs allowed before release) and then release (which
will take few days).

-- 
  Waldek Hebisch

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200221160446.GC2772%40math.uni.wroc.pl.

Re: [fricas-devel] New release

[Prof. Dr. Johannes Grabmeier FW]

ok seems that I have forgotten that  :-(

Am 11.09.15 um 09:34 schrieb Franz Lehner:
> Hello,
>
> On Fri, 11 Sep 2015, Prof. Dr. Johannes Grabmeier privat wrote:
>> also added a function monomialElements as partner of coefficients, which
>> was missing in MonoidRing.
> There is a function called 'support' which does exactly this IIUC.
>
> Franz

-- 
Mit freundlichen Grüßen

Johannes Grabmeier

Fraktionsvorsitzender 
FREIE WÄHLER, Stadtrat Deggendorf

Prof. Dr. Johannes Grabmeier
Köckstraße 1, D-94469 Deggendorf
Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756
Fax: +49-(0)-3224-192688

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Prof. Dr. Johannes Grabmeier privat]

Hallo Waldek,

here a two little improvements/enhancements:

I made CyclicGroup of category CommutativeStar and accordingly for
MonoidRing, if the Monoid has CommutativeStar, so we can e.g. compute
the determinant of a matrix over a group ring of the cyclic group. I
also added a function monomialElements as partner of coefficients, which
was missing in MonoidRing.

Please include in new release.


(1) -> )r testMRING.input
C := CyclicGroup(4, d)


   (1)  CyclicGroup(4,d)
   Type:
Type
C has CommutativeStar


   (2)  true
Type:
Boolean
RC := MonoidRing(Integer, C)


   (3)  MonoidRing(Integer,CyclicGroup(4,d))
   Type:
Type
RC has CommutativeStar


   (4)  true
Type:
Boolean
a : RC := reduce(+, [monomial(c,m)$RC for c in [-3,0,1,-1] for m in
enumerate()$C])


   32
   (5)  - d  + d  - 3
   Type:
MonoidRing(Integer,CyclicGroup(4,d))
monomialElements(a)


  3  2
   (6)  [d ,d ,1]
 Type:
List(CyclicGroup(4,d))
coefficients(a)


   (7)  [- 1,1,- 3]
  Type:
List(Integer)
m : Matrix RC := matrix [[1,a],[a^2,a-1]]


+32+
| 1   - d  + d  - 3|
   (8)  |  |
|  3 2   32|
+6d  - 5d  - 2d + 10  - d  + d  - 4+
   Type:
Matrix(MonoidRing(Integer,CyclicGroup(4,d)))
determinant m


   3  2
   (9)  29d  - 18d  - 17d + 29
   Type:
MonoidRing(Integer,CyclicGroup(4,d))
(10) ->


Am 09.09.15 um 03:25 schrieb Waldek Hebisch:
> I would like to do a new release in September.  There is still
> some time to include new code.  In about 10 days I would like
> to start release process (that is up to release allow only
> critical bugfixes).
>
>
> -- 
> Mit freundlichen Grüßen
>
> Johannes Grabmeier
>
> Prof. Dr. Johannes Grabmeier
> Köckstraße 1, D-94469 Deggendorf
> Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756
> Tel. +49-(0)-991-3615-141 (d),  Fax: +49-(0)-3224-192688

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
)abbrev category FINGRP FiniteGroup
++ Author: Franz Lehner
++ Date Created: 30.04.2008
++ Basic Functions:
++ Related Constructors:
++ Also See:
++ AMS Classifications:
++ Keywords:
++ References:
++ Description:
++ The category of finite groups.
FiniteGroup : Category == Join(Group, Finite) with
order : % -> Integer
++ \spad{order(x)} computes the order of the element $x$.
  add -- default
order x ==
k:Integer := 1
y:% := x
while not one? y repeat
k := k+1
y := y*x
k

)abbrev package FINGPKG FiniteGroupPackage
++ Author: Franz Lehner
++ Date Created: 02.01.2015
++ Date Last Updated:
++ Basic Functions:
++ Related Constructors:
++ Also See:
++ AMS Classifications:
++ Keywords:
++ References:
++ Description:
++ A package for permutation representations of finite groups.
FiniteGroupPackage(G:Join(Group, Finite)) : with
permutationRepresentation : G -> Permutation Integer
++ \spad{permutationRepresentation(x)} returns the permutation induced by x 
on \spad{enumerate()$G}
regularRepresentation : G -> Matrix Integer
++ \spad{regularRepresentation(x)} returns the matrix representation of the
++ permutation \spad{permutationRep(x)}
  == add
permutationRepresentation(x:G) : Permutation Integer ==
all : List G := enumerate()$G
n : Integer := (#all)::Integer
xall := [x*a for a in all]
k : Integer
preimag : List Integer := [k for k in 1..n]
imag : List Integer := [position(a, xall) for a in all]
p : Permutation Integer := coercePreimagesImages([preimag, imag])

regularRepresentation(x:G) : Matrix Integer ==
n : Integer := size()$G
permutationRepresentation(permutationRepresentation x, 
n)$(RepresentationPackage1 Integer)

)abbrev category FINGEN FinitelyGenerated
++ Author: Franz Lehner
++ Date Created: 30.04.2008
++ Date Last Updated:
++ Basic Functions:
++ Related Constructors:
++ Also See:
++ AMS Classifications:
++ Keywords:
++ References:
++ Description:
++ A category for finitely generated structures.
++ Exports a list of 

Re: [fricas-devel] New release

[Franz Lehner]

Hello,

On Fri, 11 Sep 2015, Prof. Dr. Johannes Grabmeier privat wrote:

also added a function monomialElements as partner of coefficients, which
was missing in MonoidRing.

There is a function called 'support' which does exactly this IIUC.

Franz

Re: [fricas-devel] New release

[Prof. Dr. Johannes Grabmeier privat]

no and yes:

a finite group is not necessarily commutative, I only changed the
CyclicGroup there!

MRING: Yes, we need CommutativeRing !


Am 11.09.15 um 15:07 schrieb Waldek Hebisch:
> Prof. Dr. Johanneas Grabmeier wrote:
>> here a two little improvements/enhancements:
>>
>> I made CyclicGroup of category CommutativeStar and accordingly for
>> MonoidRing, if the Monoid has CommutativeStar, so we can e.g. compute
>> the determinant of a matrix over a group ring of the cyclic group. I
>> also added a function monomialElements as partner of coefficients, which
>> was missing in MonoidRing.
> As Franz wrote we already have 'support'.  Concerning categories,
> do you mean the following:
>
> Index: src/algebra/discrgrp.spad
> ===
> --- src/algebra/discrgrp.spad   (revision 1941)
> +++ src/algebra/discrgrp.spad   (working copy)
> @@ -10,7 +10,7 @@
>  ++ References:
>  ++ Description:
>  ++ The category of finite groups.
> -FiniteGroup : Category == Join(Group, Finite) with
> +FiniteGroup : Category == Join(Group, CommutativeStar, Finite) with
>  order : % -> Integer
>  ++ \spad{order(x)} computes the order of the element $x$.
>add -- default
> Index: src/algebra/mring.spad
> ===
> --- src/algebra/mring.spad  (revision 1941)
> +++ src/algebra/mring.spad  (working copy)
> @@ -44,6 +44,8 @@
>  if R has CharacteristicZero then CharacteristicZero
>  if R has CharacteristicNonZero then CharacteristicNonZero
>  if R has CommutativeRing then Algebra(R)
> +if R has CommutativeRing and M has CommutativeStar then
> +  CommutativeRing
>  if (R has Finite and M has Finite) then Finite
>  if M has Comparable then
>FreeModuleCategory(R, M) 
>
>
> -- 
> Mit freundlichen Grüßen
>
> Johannes Grabmeier
>
> Prof. Dr. Johannes Grabmeier
> Köckstraße 1, D-94469 Deggendorf
> Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756
> Tel. +49-(0)-991-3615-141 (d),  Fax: +49-(0)-3224-192688

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

Prof. Dr. Johanneas Grabmeier wrote:
> 
> here a two little improvements/enhancements:
> 
> I made CyclicGroup of category CommutativeStar and accordingly for
> MonoidRing, if the Monoid has CommutativeStar, so we can e.g. compute
> the determinant of a matrix over a group ring of the cyclic group. I
> also added a function monomialElements as partner of coefficients, which
> was missing in MonoidRing.

As Franz wrote we already have 'support'.  Concerning categories,
do you mean the following:

Index: src/algebra/discrgrp.spad
===
--- src/algebra/discrgrp.spad   (revision 1941)
+++ src/algebra/discrgrp.spad   (working copy)
@@ -10,7 +10,7 @@
 ++ References:
 ++ Description:
 ++ The category of finite groups.
-FiniteGroup : Category == Join(Group, Finite) with
+FiniteGroup : Category == Join(Group, CommutativeStar, Finite) with
 order : % -> Integer
 ++ \spad{order(x)} computes the order of the element $x$.
   add -- default
Index: src/algebra/mring.spad
===
--- src/algebra/mring.spad  (revision 1941)
+++ src/algebra/mring.spad  (working copy)
@@ -44,6 +44,8 @@
 if R has CharacteristicZero then CharacteristicZero
 if R has CharacteristicNonZero then CharacteristicNonZero
 if R has CommutativeRing then Algebra(R)
+if R has CommutativeRing and M has CommutativeStar then
+  CommutativeRing
 if (R has Finite and M has Finite) then Finite
 if M has Comparable then
   FreeModuleCategory(R, M) 

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

Prof. Dr. Johanneas Grabmeier wrote:
> 
> no and yes:
> 
> a finite group is not necessarily commutative, I only changed the
> CyclicGroup there!
> 
> MRING: Yes, we need CommutativeRing !
> 

Yes, only cyclic group.  Commited now (I also changed infinite
cyclic group).

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Ralf Hemmecke]

On 09/09/2015 03:25 AM, Waldek Hebisch wrote:
> I would like to do a new release in September. 

Hi Waldek, hi Abhinav,

currently, the aldor compilation fails for at least two reasons.
1) generalization of the polynomial coefficient domain
2) lodof2.

I can probably fix (1) easily via adaptation of initlist.as, but (2)
seems to be a bit more involved.

The problem is here:

https://github.com/fricas/fricas/blob/master/src/algebra/lodof2.spad#L81

  SG ==> Record(point : Union(F, "infinity"), lpf : LL, dxt :
PositiveInteger)
  CB ==> Set SG

In Aldor, the Record type is not of type SetCategory. I wonder why the
SPAD compiler doesn't complain here, but probably Record is treated on a
special basis. Anyway, I think, we shouldn't silently accept that Record
is of type SetCategory.

Looking closer into the code, I think it would be OK to change the above
line to

  CB ==> List SG

and adjust the function ge_minimal accordingly.

Similarly, for

  GEM ==> Set Record(singularity : SG, fos : SP, mge : List US)

I don't see a deep reason to keep Set instead of List.

Comments?

Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

Ralf Hemmecke wrote:
> 
> 
> currently, the aldor compilation fails for at least two reasons.
> 1) generalization of the polynomial coefficient domain
> 2) lodof2.
> 
> I can probably fix (1) easily via adaptation of initlist.as, but (2)
> seems to be a bit more involved.
> 
> The problem is here:
> 
> https://github.com/fricas/fricas/blob/master/src/algebra/lodof2.spad#L81
> 
>   SG ==> Record(point : Union(F, "infinity"), lpf : LL, dxt :
> PositiveInteger)
>   CB ==> Set SG
> 
> In Aldor, the Record type is not of type SetCategory. I wonder why the
> SPAD compiler doesn't complain here, but probably Record is treated on a
> special basis. Anyway, I think, we shouldn't silently accept that Record
> is of type SetCategory.

If all fields have SetCategory, then record should have SetCategory
too.  Currently Spad cheats and unconditionally asserts SetCategory.
If Aldor unconditionally considers records to _not_ have
SetCategory, then this looks like serious limitation of Aldor.

> 
> Looking closer into the code, I think it would be OK to change the above
> line to
> 
>   CB ==> List SG
> 
> and adjust the function ge_minimal accordingly.
> 
> Similarly, for
> 
>   GEM ==> Set Record(singularity : SG, fos : SP, mge : List US)
> 
> I don't see a deep reason to keep Set instead of List.
> 
> Comments?

List looks better here. Set will do extra work trying to avoid
duplicates.  AFAICS both for our usage of CB and GEM duplicates
are impossible, so this should be easy to change.


-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Dima Pasechnik]

On Friday, 19 December 2014 19:06:42 UTC, Waldek Hebisch wrote:

 Dima Pasechnik wrote: 
  
  On Wednesday, 17 December 2014 16:00:03 UTC, Ralf Hemmecke wrote: 
   
Dima, in fact, it's not s easy with (La)TeX. It depends on how 
you see it. One way is that TeX (the program) is a compiler that 
translates the sources (i.e. .tex, .sty, and .bib, ... files -- 
which can count as the program sources since TeX is a programming 
language). Then the .dvi or .pdf file would be considered as the 
compiled form of the sources. With this point of view, Waldek is 
right. 

I don't get your point. There is no problem like this with GPL, and 
 I 
don't know why this was mentioned in the 1st place... Surely you can 
put out a software with a license saying that by using it you sell 
yourself into slavery, but this does not mean that something is 
 wrong 
with GPL... 
   
   I never said that something is wrong with GPL. Quite the contrary. I'd 
   like to have GPL for FriCAS. 
   
But I don't really think that most people thing that way. 
Unfortunately, there is no clear statement from the FSF about this. 
   
But also this is somehow a non-issue. If my published paper would 
be GPL then I have to provide the .tex and .sty files. So what? 
   
Why is that even mentioned? There are no GPL-licensed programs that 
tell you anything about copyright of the data you process with them. 
   
   Although, I somehow see it like you, it is not that easy with (La)TeX. 
   
   Let's try to make to other viewpoint clearer. There is TP (TeX the 
   program, i.e. the program that translates .tex+.sty into .dvi) and 
 there 
   is TL (the TeX language). All my .tex and .sty files are written in 
 the 
   TL. The TL is a programming language. TP is the compiler that 
 translates 
   my program (.tex + .sty) into binary form (.dvi). Now according to 
 GPL, 
   that would probably mean that if one .sty file is under GPL, the whole 
   .dvi is under GPL, so also all the respective .tex files that are used 
   to produce this .dvi are under GPL. 
   
  
  Your C, etc., programs also use *.h files, which might be under GPL 
 (e.g. 
  on Linux lots of them are). 
  This does not automatically put your own C program under GPL. 
  Cf e.g. http://lkml.iu.edu/hypermail/linux/kernel/0301.1/0362.html 
  
  Certainly, (La)TeX .sty files are macro files, just like .h files are. 
  So the fear that GPLed .sty files can infect, license-wise, 
  your own TeX files is unfounded. 

 Have you read the link you provide?  Key words are 'automatically' 
 and 'substantial'.  You can not assume that including GPL '.h' file 
 will automatically bring your program under GPL.  But as well 
 you can not assume that it will not.  


sure: they talk about copying parts of headers into your source, not
including them using C's #include or its equivalent.
It goes without saying that #include can include GPL'ed headers
in no-GPL code.

 

 They write: 'It would take 
 a substantial amount of code (coming from inline functions or macros   
   
 with substantial bodies) to do that'.  But in other context it 
 turned out that 'substantial' can be as little as 10 lines. 
 Header files are special: since normally they specify interface 
 to a library I read opinions that using _declarations_ from 
 header files is just fair use.  So if header contains no 
 executable code and no comments, then copyright on that 
 header is meaningless. 

 Also, look at Bison: FSF claims that if you use GML feature 
 than Bison output falls under GPL.   

 
IMHO this is no longer the case:
http://www.gnu.org/software/bison/manual/html_node/Conditions.html

 

 And it seems that 
 they do not make such claim in non-GML output only 
 because there are several competing programs, none 
 with such restriction.  To make it clearer: Bison output 
 essentially concatenates tables derived from your code 
 with skeleton code from Bison.  This could be argued 
 to be mere aggregation, but after compilation you 
 can not separate tables from what came from skeleton 
 and linking clause of GPL applies. 

 The whole disscussion started with 'fricasmath.sty' which is 
 rather small file.  It is quite possible that a court would 
 decide that 'fricasmath.sty' contains too little copywritable 
 material to count.  But in such case why bother with special 
 license?  So discussing license we should assume that it 
 is 'substantial'.  Lawyers may argue that for one reason or 
 another 'fricasmath.sty' affect (or not) status of document 
 using it.  But the point is that we have no _clear_ indication 
 that it will not.  Normally free projects use permissive 
 licenses in such case to avoid any doubts. 


 -- 
   Waldek Hebisch 
 heb...@math.uni.wroc.pl javascript: 


-- 
You received this message because you are subscribed to the Google Groups 
FriCAS - computer algebra system group.
To 

Re: [fricas-devel] New release

[Dima Pasechnik]

On Friday, 12 December 2014 23:52:55 UTC, Ralf Hemmecke wrote:

  1) Distributing binary + a patch without full sorces. 

 GPL does not forbid that. GPL only says that you have to make the 
 sources available in a form that they are normally build from. 
 But you don't have to distribute them together with the binary. 
 You don't even have to make them public, ither. The only thing you have 
 to do is to send somebody the source (for free) whoever wants to see them. 

 So if you have already the sources somewhere (for example at SF) and the 
 patch *is* the the form of source for this modified binary, then I see 
 nothing that would contradict the GPL if you put somewhere the original 
 source + the patch. 

 As Dima already said, nowadays there are so many free services. So 
 having the patch living in a branch of the source code repository is not 
 a big issue. 

 I'm anyway against binaries without their respective sources. 

  Or just courtesy binary for some archtecture. 

 If you can build such a binary and the next day you are hit by a bus, 
 who is going to provide such courtesy binary if there are no sources 
 available? 

  GPL requres to keep sorces for download on the server... 

 Yes. But FriCAS can be easily build from the repository via make. So 
 the only thing is to keep the sources in the repository and tell from 
 which version the binary was build and how. 

  2) One may wish to embed encryption key for classical cryptography 
   inside executable, distribute this executable to others so that 
  they can send enctypted messages to him.  This is not very secure 
  but give some protection and may be best thing available if public 
   key cryptography is not an option. 

  this sounds like a spyware application, ghm, ghm, ghm... 

 I also think that this is a non-issue for FriCAS. 

  However, GPL requires souces (with no obfuscation!), so extracting 
   encryption key becomes trivial. 

 That reminds me of security through obscurity. 
 http://en.wikipedia.org/wiki/Security_through_obscurity 

  3) There are GPL incompatible free licences.  Creating and 
  distributing combined programs is reasonable, but forbidden if 
  licences are incompatible 

 More clearly, distributing combined binary would be forbidden. But I 
 don't see that as a problem of the GPL. 
 If I look at the list 
 https://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses 
 and the respective list of compatible licenses above, I'd even claim 
 that being incompatible with GPL is rather a non-issue. In particular 
 for GPL3, they have taken measures to get more licenses compatible with 
 it. See for example Apache 2.0. 

  I do not know how careful you are.  I believe that normal folks 
  given clear statement of licence do not scan file looking for 
  another licence in the middle which gives different terms. 

 Before I redistribute I'm usually double careful. Of course, I also may 
 sometimes be wrong. But still I think that if people get something for 
 free, it's not unreasonable to ask them to at least follow the license 
 under which they get the stuff. 

 ad TeX style and GPL ... 

  This is not true: this is akin to saying that photos taken by a Canon 
  camera carry Canon copyright, or executables build by gcc are under 
  GPL. 

 Dima, 
 in fact, it's not s easy with (La)TeX. It depends on how you see it. 
 One way is that TeX (the program) is a compiler that translates the 
 sources (i.e. .tex, .sty, and .bib, ... files -- which can count as the 
 program sources since TeX is a programming language). Then the .dvi or 
 .pdf file would be considered as the compiled form of the sources. With 
 this point of view, Waldek is right.

I don't get your point. There is no problem like this with GPL, and I don't
know why this was mentioned in the 1st place...
Surely you can put out a software with a license saying that by using 
it you sell yourself into slavery, but this does not mean that something is
wrong with GPL...



 

 But I don't really think that most 
 people thing that way. Unfortunately, there is no clear statement from 
 the FSF about this. 

 But also this is somehow a non-issue. If my published paper would be GPL 
 then I have to provide the .tex and .sty files. So what? 


Why is that even mentioned? There are no GPL-licensed programs that tell 
you anything about
copyright of the data you process with them.

Dima

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Ralf Hemmecke]

 Dima, in fact, it's not s easy with (La)TeX. It depends on how
 you see it. One way is that TeX (the program) is a compiler that
 translates the sources (i.e. .tex, .sty, and .bib, ... files --
 which can count as the program sources since TeX is a programming
 language). Then the .dvi or .pdf file would be considered as the
 compiled form of the sources. With this point of view, Waldek is
 right.
 
 I don't get your point. There is no problem like this with GPL, and I
 don't know why this was mentioned in the 1st place... Surely you can
 put out a software with a license saying that by using it you sell
 yourself into slavery, but this does not mean that something is wrong
 with GPL...

I never said that something is wrong with GPL. Quite the contrary. I'd
like to have GPL for FriCAS.

 But I don't really think that most people thing that way.
 Unfortunately, there is no clear statement from the FSF about this.

 But also this is somehow a non-issue. If my published paper would
 be GPL then I have to provide the .tex and .sty files. So what?

 Why is that even mentioned? There are no GPL-licensed programs that
 tell you anything about copyright of the data you process with them.

Although, I somehow see it like you, it is not that easy with (La)TeX.

Let's try to make to other viewpoint clearer. There is TP (TeX the
program, i.e. the program that translates .tex+.sty into .dvi) and there
is TL (the TeX language). All my .tex and .sty files are written in the
TL. The TL is a programming language. TP is the compiler that translates
my program (.tex + .sty) into binary form (.dvi). Now according to GPL,
that would probably mean that if one .sty file is under GPL, the whole
.dvi is under GPL, so also all the respective .tex files that are used
to produce this .dvi are under GPL.

Not that like to take this point of view and it is somehow questionable
to consider a .dvi file as a (runnable) program, but it's a way of
seeing this situation.

Of course, I see it like you and wouldn't believe that the use of a
GPL'd .sty file would mean GPL for my .tex file(s) if I distribute the
.dvi. However, have you any argument against the above way of seeing the
situation?

It's just that I find it sometimes unpredictable how lawyers argue.
Just a funny story here. Sorry, it's only in German.
http://www.heise.de/newsticker/meldung/Uhrzeit-ablesen-beim-Autofahren-ist-verbotene-Handynutzung-2498870.html
I wonder what the judges had decided if the smartphone were smaller and
looked more like a watch.

Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

Ralf Hemmecke wrote:
 
 On 10/16/2014 03:28 PM, Waldek Hebisch wrote:

  OTOH GPL causes inconvenice (some reasonable things are forbidden by
  GPL).  At least for now BSD looks like better choice.
 
 Maybe BSD looks better for you, but what exactly is your fear with GPL?
 What are thoses reasonable things?

Few examples:

1) Distributing binary + a patch without full sorces.  Or just
courtesy binary for some archtecture.  This is reasonable to
save space in particular if original is widely available.  GPL
requres to keep sorces for download on the server...
2) One may wish to embed encryption key for classical cryptography
inside executable, distribute this executable to others so that
they can send enctypted messages to him.  This is not very
secure but give some protection and may be best thing available
if public key cryptography is not an option.  However, GPL
requires souces (with no obfuscation!), so extracting encryption
key becomes trivial.
3) There are GPL incompatible free licences.  Creating and
distributing combined programs is reasonable, but forbidden
if licences are incompatible

 
  The GPL license of fricasmath.sty does not have any impact 
  whatsoever on the rest of the FriCAS code.
 
  One thing is that putting GPL fragment inside a file in a driectory 
  when every other file uses BSD licence is misleading
 
 For this very reason the FSF suggests to put a license notice into every
 single file (which FriCAS has if I am not wrong).

Actually most files include licence, but this is confusing because
licence is at the end (so may be easily overlooked, as normal
practice is to put licencing clauses at the beginning).  Some
file (mostly that I wrote) rely on general licence statement.
IMO licence at the end is good to satisfy the letter (do not
remove copyright notes) but are almost useless for the purpose.
Licence text at the begining IMHO adds too much clutter to
sources so I prefer to omit it.

 
 I actually find it rather ignorant if some people ignore those license
 issues and just carelessly take whatever they can get on the Internet
 and publish it as their own. So I don't support careless people.

I do not know how careful you are.  I believe that normal folks
given clear statement of licence do not scan file looking for
another licence in the middle which gives different terms.

  Second, impact is much wider than you wrote.  AFAIU current legal 
  theory is that result of running TeX on a file including your style 
  file is derived work, so subject to GPL.  Given that the style file 
  is needed to use TeX output from FriCAS, this would mean that 
  including FriCAS output in a paper makes the paper GPL.
 
 Come on. TeX is a programming language. The text of the paper is data.
 Where in the GPL is written that the program under GPL makes the data
 GPL? Are you distributing your pictures that you produced by GIMP under GPL?
 
 http://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL
 
 I don't see that fricasmath.sty copies anything of it's program into the
 pdf or dvi file.

Well, TeX file is a _program_ which prescribes content and
(partially) appearence to the text.  TeX macros are programs
which are combined with user part and then compiled together
to produce final results.  In particular layout is largely
affected by macros.  Today you may say that fricasmath.sty
is too small to matter and copyright claim other it would
be probably dismissed.  But before it is dismissed a person
or small company may get bankrupt (in SCO vs. IBM the _real_
thing SCO had was of size fricasmath.sty)

 
 If you fear GPL, then I hope you have not (by accident) used any of those
 
 http://www.ctan.org/tex-archive/macros/latex/contrib/preview
 http://www.ctan.org/tex-archive/support/hyperlatex
 http://www.ctan.org/tex-archive/macros/latex/contrib/python
 http://www.ctan.org/tex-archive/macros/latex/contrib/eqnarray
 http://www.ctan.org/tex-archive/macros/latex/contrib/program
 http://www.ctan.org/tex-archive/macros/latex/contrib/dot2texi
 http://www.ctan.org/tex-archive/macros/latex/contrib/units
 http://www.ctan.org/tex-archive/macros/latex/contrib/classicthesis/
 

Well, (La)TeX licensing is a mess.  For one, old standard licence
of LaTeX packages is GPL incompatible (apparently they try to
make new licence GPL compatible, but I suspect that they still
carry packages with old licence), but IIRC typical binary
contains GPL-ed parts.  Since I not in business of distributing
LaTeX binaries I do not make much fuss about this (for the GPL parts
I know one can reasonably claim that copyright status of output
is not affected by them).

For FriCAS I would like to avoid such mess.  LaTeX got popular
in times when people had much looser approach to copyright.
But nowaday law is more restritive and in general stakes
are higher than in the past, so project which is too loose
in it copyright treatment has almost no chance to became
popular.

 PS: Maybe I should think about the license of both files 

Re: [fricas-devel] New release

[Kurt Pagani]

In section 6.21 of the 'book' we have:

This longer notation gives you patterns that the standard notation
won't handle. For example, the rule

rule %f(c * 'x) ==  c*%f(x)

means for all f and c, replace f(y) by c*f(x) when y is the product of c
and the explicit variable x.

This does not work unless %f is declared as BOP which is not what I
expected by the explanation above. Could it work the way I think it
should, g(y*x) - y*g(x) ?
Kurt

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Ralf Hemmecke]

On 10/16/2014 03:28 PM, Waldek Hebisch wrote:
 Well, GPL was not designed to extract benefits from other people. 
 Goal of GPL is to preserve freedom of software.

Right. I cannot force other people to give me their improvements.
But if they distribute anything, they have to distribute the source and
in particular give me the right to use and distribute their improvements.

 OTOH GPL causes inconvenice (some reasonable things are forbidden by
 GPL).  At least for now BSD looks like better choice.

Maybe BSD looks better for you, but what exactly is your fear with GPL?
What are thoses reasonable things?

 The GPL license of fricasmath.sty does not have any impact 
 whatsoever on the rest of the FriCAS code.

 One thing is that putting GPL fragment inside a file in a driectory 
 when every other file uses BSD licence is misleading

For this very reason the FSF suggests to put a license notice into every
single file (which FriCAS has if I am not wrong).

I actually find it rather ignorant if some people ignore those license
issues and just carelessly take whatever they can get on the Internet
and publish it as their own. So I don't support careless people.

 OTOH careful folks which have automats which scan files for
 copyright notices may think everything is GPL.

Oh well, there is some truth in it. There are many people who don't
understand that the GPL does not necessarily affect code that is
distributed alongside with it.

 Second, impact is much wider than you wrote.  AFAIU current legal 
 theory is that result of running TeX on a file including your style 
 file is derived work, so subject to GPL.  Given that the style file 
 is needed to use TeX output from FriCAS, this would mean that 
 including FriCAS output in a paper makes the paper GPL.

Come on. TeX is a programming language. The text of the paper is data.
Where in the GPL is written that the program under GPL makes the data
GPL? Are you distributing your pictures that you produced by GIMP under GPL?

http://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL

I don't see that fricasmath.sty copies anything of it's program into the
pdf or dvi file.

If you fear GPL, then I hope you have not (by accident) used any of those

http://www.ctan.org/tex-archive/macros/latex/contrib/preview
http://www.ctan.org/tex-archive/support/hyperlatex
http://www.ctan.org/tex-archive/macros/latex/contrib/python
http://www.ctan.org/tex-archive/macros/latex/contrib/eqnarray
http://www.ctan.org/tex-archive/macros/latex/contrib/program
http://www.ctan.org/tex-archive/macros/latex/contrib/dot2texi
http://www.ctan.org/tex-archive/macros/latex/contrib/units
http://www.ctan.org/tex-archive/macros/latex/contrib/classicthesis/

 IMHO you did too much work on tex.spad, instead of complete rewrite 
 incremental changes should give the same effect.

I don't think so. My tex.spad gives the user runtime flexibility. That
would have been impossible with incremental changes. In fact, the new
tex.spad is actually rather simple if one looks at it. The most
important things are listed in a table like structure. I hope that some
day I can also use that structure to improve the other output formatters.

 Certainly it would be easier to test and verify smaller change.

Maybe, but the old code was buggy. (Maybe mine is too.) But the test
suite covers quite a lot of cases. And it can easily be run with the old
code.

https://github.com/hemmecke/fricas/blob/tex-latex/src/input/textest.input

 Im just telling you that since I had little time for FriCAS it was
 much harder to find time to look at bigger piece than on few
 independent smaller pieces.

Well... I'm not really complaining, but it's just more fun to do
something if one sees other people appreciating it.

Ralf

PS: Maybe I should think about the license of both files fricas.sty and
fricasmath.sty. What's your opinion about LPPL 1.3+ ?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Ralf Hemmecke]

 What will be the impact on efricas and axiom-wiki of these changes?

There's a patch for efricas included. -- Since the previous
tex.spad+emacs connection did not have any line breaking mechanism, you
should see an improvement. I asked often enough, seemingly nobody tried.
I only care about the line breaking in the book. There it's not perfect,
but good enough. I don't care very much about efricas, because I'm not
using it with tex, but it should be an improvement.

axiom-wiki: I have no access to a copy of the current vm (and don't even
know where I would have to patch) --- No idea how this will work. But
since I had to patch efricas, there's certainly need to patch
mathaction, as well.

Documentation: There is a sufficiently big test suite. Run it through
the old and the new tex.spad and look at the differences. That will
probably tell you more than any explanation in words. Other things are
in the mail archive.

Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

Ralf Hemmecke wrote:
 
 On 10/12/2014 04:32 AM, Waldek Hebisch wrote:
  Ralf Hemmecke wrote:
 
  On 09/08/2014 01:27 AM, Waldek Hebisch wrote:
  If there is some code you want included in new release
  please speak up.
 
  I don't know whether it must be included, but there was
  https://www.mail-archive.com/fricas-devel@googlegroups.com/msg07524.html
 
  
  Technically this looks fine.  But why you create licence discontinuity
  by putting GPL inside provided macro file?
 
 I'd love to see FriCAS under GPL.
 
 When other people benefit from my code, I want others to also let me
 benefit from their code. That is best ensured by GPL.

Well, GPL was not designed to extract benefits from other
people.  Goal of GPL is to preserve freedom of software.
In case of FriCAS IMO danger is very small, so GPL
protection does not change much.  OTOH GPL causes inconvenice
(some reasonable things are forbidden by GPL).  At least
for now BSD looks like better choice.

 I actually thought of putting tex.spad under GPL, since there is
 basically no original code left. But that would have had more impact on
 the whole of FriCAS and I didn't want to raise the GPL question at the
 moment.
 
 The GPL license of fricasmath.sty does not have any impact whatsoever on
 the rest of the FriCAS code.

One thing is that putting GPL fragment inside a file in a driectory
when every other file uses BSD licence is misleading: careless folks
may end up using fragments of your code (say picked by grep) without
realising it is GPL.  OTOH careful folks which have automats which
scan files for copyright notices may think everything is GPL.
I am sure it was not you intent, but this may lead to confusion
about licence.

Second, impact is much wider than you wrote.  AFAIU current legal
theory is that result of running TeX on a file including your
style file is derived work, so subject to GPL.  Given that the
style file is needed to use TeX output from FriCAS, this would
mean that including FriCAS output in a paper makes the paper
GPL.  IMO that would go way too far.  For example, FSF in
similar sitations usually uses GPL but adds an explicit exception.
Adding an exception has its own troubles: FSF insists that all
code they distribute have copyright transferred to them, so
they can relicense or add exceptions at will.  But in cooperative
project where copyright stays with author (that is when there is
no explicit copyright transfer) relicensing is problematic at
best and may be impossible due to lack of contact with
copyright owners.  So even in otherwise GPL project it is
better to use permissive licence for things like fricasmath.sty.

 
 BTW, I currently included tensor.sty. I don't actually know whether you
 would like to have this in FriCAS.
 a) It is under the LaTeX Project Public License.
 b) Maybe to be complete, one should distribute also tensor.dtx.
 c) Maybe it should not distributed at all with FriCAS (but then
\ALTSUPERSUB would have to be implemented differently or it doesn't
work if the user doesn't have tensor.sty in his LaTeX installation.
Maybe add a test to configure.ac and tell the user how to install it.

I think it is reasonable to request user to separately fetch tensor.sty
(as long as we do not need \ALTSUPERSUB for bundled docs).

 I also require breqn.sty, but that seems to be in a standard TeXLive
 distribution nowadays.
 
 Since I am probably unable to work on cleaning up the tex.spad patch
 anyway within the next days, I don't think it will make it into the new
 release. It's a pity, but from the reaction on the mailing list, there
 doesn't seem to be a lot of interest in it.

I think there is interest.  To be more precise, I think that
improvement to TeX output and ability to generate book are
important.  IMHO you did too much work on tex.spad, instead
of complete rewrite incremental changes should give the
same effect.  Certainly it would be easier to test
and verify smaller change.  Since you are (almost) done
we will use your version.  Im just tellning you that
since I had little time for FriCAS it was much harder
to find time to look at bigger piece than on few
independent smaller pieces.  And other folks here
are busy too -- I think they will appreciate improvements
but have not time to look at code.

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Bill Page]

On 16 October 2014 02:01, Ralf Hemmecke r...@hemmecke.org wrote:
 What will be the impact on efricas and axiom-wiki of these changes?

 There's a patch for efricas included.

Great.

  -- Since the previous tex.spad+emacs connection did not have any
 line breaking mechanism, you should see an improvement.

right. From my point of view line breaking is a most important feature.

 I asked often enough, seemingly nobody tried.

Better to just assume that no one wished to comment.

 I only care about the line breaking in the book. There it's not perfect,
 but good enough.

Just good enough sounds rather discouraging.

 I don't care very much about efricas, because I'm not
 using it with tex, but it should be an improvement.


It is a pity that you state explicitly that you don't care very much
about efricas. That might not be very encouraging to people who
actually do use efricas.  But maybe you are right that the best way to
get comments from people who do use efricas is just to risk including
your changes in the distribution ...

 axiom-wiki: I have no access to a copy of the current vm (and don't even
 know where I would have to patch) --- No idea how this will work. But
 since I had to patch efricas, there's certainly need to patch
 mathaction, as well.

I will try to find the time to test this in the mathaction that I run locally.


 Documentation: There is a sufficiently big test suite. Run it through
 the old and the new tex.spad and look at the differences. That will
 probably tell you more than any explanation in words. Other things
 are in the mail archive.


I was hoping for a quick summary but maybe improved line breaking is
sufficient motivation.

Bill.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Ralf Hemmecke]

On 10/12/2014 04:32 AM, Waldek Hebisch wrote:
 Ralf Hemmecke wrote:

 On 09/08/2014 01:27 AM, Waldek Hebisch wrote:
 If there is some code you want included in new release
 please speak up.

 I don't know whether it must be included, but there was
 https://www.mail-archive.com/fricas-devel@googlegroups.com/msg07524.html

 
 Technically this looks fine.  But why you create licence discontinuity
 by putting GPL inside provided macro file?

I'd love to see FriCAS under GPL.

When other people benefit from my code, I want others to also let me
benefit from their code. That is best ensured by GPL.

I actually thought of putting tex.spad under GPL, since there is
basically no original code left. But that would have had more impact on
the whole of FriCAS and I didn't want to raise the GPL question at the
moment.

The GPL license of fricasmath.sty does not have any impact whatsoever on
the rest of the FriCAS code.

BTW, I currently included tensor.sty. I don't actually know whether you
would like to have this in FriCAS.
a) It is under the LaTeX Project Public License.
b) Maybe to be complete, one should distribute also tensor.dtx.
c) Maybe it should not distributed at all with FriCAS (but then
   \ALTSUPERSUB would have to be implemented differently or it doesn't
   work if the user doesn't have tensor.sty in his LaTeX installation.
   Maybe add a test to configure.ac and tell the user how to install it.

I also require breqn.sty, but that seems to be in a standard TeXLive
distribution nowadays.

Since I am probably unable to work on cleaning up the tex.spad patch
anyway within the next days, I don't think it will make it into the new
release. It's a pity, but from the reaction on the mailing list, there
doesn't seem to be a lot of interest in it.

Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Bill Page]

On 15 October 2014 17:39, Ralf Hemmecke r...@hemmecke.org wrote:
 On 10/12/2014 04:32 AM, Waldek Hebisch wrote:

 Technically this looks fine.  But why you create licence discontinuity
 by putting GPL inside provided macro file?

 I'd love to see FriCAS under GPL.


As much as support open source I am rather against specific license
discussions in general.  I would prefer it if the license situation
with FriCAS remained simple, permissive and clean.


 Since I am probably unable to work on cleaning up the tex.spad patch
 anyway within the next days, I don't think it will make it into the new
 release. It's a pity, but from the reaction on the mailing list, there
 doesn't seem to be a lot of interest in it.


In fact I am very interested in your new and improved tex.spad but I
have not had any time to play with it.  Is there a description
somewhere of what is fixed and what is improved over the old version?
What will be the impact on efricas and axiom-wiki of these changes?

Bill Page.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

Ralf Hemmecke wrote:
 
 On 09/08/2014 01:27 AM, Waldek Hebisch wrote:
  If there is some code you want included in new release
  please speak up.
 
 I don't know whether it must be included, but there was
 https://www.mail-archive.com/fricas-devel@googlegroups.com/msg07524.html
 

Technically this looks fine.  But why you create licence discontinuity
by putting GPL inside provided macro file?

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

kfp wrote:
 
 Concerning GnuDraw: I'm having endorsed Fricas to a lot of people of which 
 there are several cygwin users (mostly -nosman). The prize for endorsement 
 a software is you will be asked for this and that, and especially plotting 
 is a popular topic (a heritage of wxMaxima). To be short, I find GDRAW 
 useful and do not know of any other (reliable) way to get some graphics 
 (not HQ, I agree) for 'nosman's. It dates from 2008 as the header indicates 
 and it's by no means a 'hack'.

OK, I think there is enough need for inclusion.  The question now
is if version on MathAction is the current one (it was recently
updated)?

 Back to the point: why not including such kind of modules in the 'contrib' 
 folder under 'experimental, quarantine' or whatever so that users can 
 compile and load it themselves? At least it would be there when needed. 

I have mixed feelings about this.  Namely, ATM we have MathAction
for experimental code and anybody can grab code from there.
Granted, getting code from wiki pages has some problems (I click
edit and then cut and paste from edit window).  But should be
able to organize this better, in particular provide download
area for contributed code.

Concerning 'contrib' in distribution tarball: if code there is
build and tested then there is not much difference from having
it included.  This could change if we had a lot of contribs and
machinery to turn them on/off at configure time.  OTOH if
contribs were unmaintained, then bundling them with tarball
would give wrong impression.

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Bill Page]

On 7 October 2014 10:08, Waldek Hebisch hebi...@math.uni.wroc.pl wrote:
 kfp wrote:

 Concerning GnuDraw: I'm having endorsed Fricas to a lot of people of which
 there are several cygwin users (mostly -nosman). The prize for endorsement
 a software is you will be asked for this and that, and especially plotting
 is a popular topic (a heritage of wxMaxima). To be short, I find GDRAW
 useful and do not know of any other (reliable) way to get some graphics
 (not HQ, I agree) for 'nosman's. It dates from 2008 as the header indicates
 and it's by no means a 'hack'.

 OK, I think there is enough need for inclusion.  The question now
 is if version on MathAction is the current one (it was recently
 updated)?

Yes, I added a few more wrappers for the case of passing arrays of
values.  If someone misses them, I think there are a few more ways of
calling 'draw' that are not yet implemented in gnuDraw but the pattern
is the same.


 Back to the point: why not including such kind of modules in the 'contrib'
 folder under 'experimental, quarantine' or whatever so that users can
 compile and load it themselves? At least it would be there when needed.

 I have mixed feelings about this.  Namely, ATM we have MathAction
 for experimental code and anybody can grab code from there.
 Granted, getting code from wiki pages has some problems (I click
 edit and then cut and paste from edit window).  But should be
 able to organize this better, in particular provide download
 area for contributed code.

You can use this current hidden url

http://axiom-wiki.newsynthesis.org/SandBoxChoose/src

i.e. just add '.../src' to the end.  We could add a link somewhere on
the wiki page to make this possible with just 'one-click'.  I also
have a perl script somewhere that converts the '/src' form to and
executable '.input' file.

I very much like the idea of using MathAction for experimental code.
If there are small things we can do to make this easier I would be
happy to help with this.


 Concerning 'contrib' in distribution tarball: if code there is
 build and tested then there is not much difference from having
 it included.  This could change if we had a lot of contribs and
 machinery to turn them on/off at configure time.  OTOH if
 contribs were unmaintained, then bundling them with tarball
 would give wrong impression.


I also do not much like the idea of 'contrib'.

Bill Page.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Kurt Pagani]

On Tuesday, 7 October 2014 16:08:45 UTC+2, Waldek Hebisch wrote:

 kfp wrote: 
  
  Concerning GnuDraw: I'm having endorsed Fricas to a lot of people of 
 which 
  there are several cygwin users (mostly -nosman). The prize for 
 endorsement 
  a software is you will be asked for this and that, and especially 
 plotting 
  is a popular topic (a heritage of wxMaxima). To be short, I find GDRAW 
  useful and do not know of any other (reliable) way to get some graphics 
  (not HQ, I agree) for 'nosman's. It dates from 2008 as the header 
 indicates 
  and it's by no means a 'hack'. 

 OK, I think there is enough need for inclusion.  The question now 
 is if version on MathAction is the current one (it was recently 
 updated)? 
   

 Back to the point: why not including such kind of modules in the 
 'contrib' 
  folder under 'experimental, quarantine' or whatever so that users can 
  compile and load it themselves? At least it would be there when needed. 

 I have mixed feelings about this.  Namely, ATM we have MathAction 
 for experimental code and anybody can grab code from there. 
 Granted, getting code from wiki pages has some problems (I click 
 edit and then cut and paste from edit window).  But should be 
 able to organize this better, in particular provide download 
 area for contributed code. 


I didn't think of that. The wiki is a real treasure chest which I 
(re)discovered only recently and it will hardly be possible to include only 
a fraction of useful contribs.
 


 Concerning 'contrib' in distribution tarball: if code there is 
 build and tested then there is not much difference from having 
 it included.  This could change if we had a lot of contribs and 
 machinery to turn them on/off at configure time.  OTOH if 
 contribs were unmaintained, then bundling them with tarball 
 would give wrong impression. 


I admit it was a bit headily to propose as I'm aware of the nuisance of 
orphaned contrib folders.
 

 -- 
   Waldek Hebisch 
 heb...@math.uni.wroc.pl javascript: 


-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Bill Page]

I have committed my changes for the texmacs interface to svn.  I can
confirm that the full build works using SBCL 1.1.11-2.1.4-suse on
64-bit OpenSuse 13.1.  I have not tested on any non-unicode supporting
lisps.

One minor note:  I can to modify the 3rd line of '/usr/localbin/fricas' from:

AXIOM=${exec_prefix}/lib/fricas/target/x86_64-suse-linux

to:

AXIOM=${exec_prefix}/lib64/fricas/target/x86_64-suse-linux

Apparently configure still does not set the library/executable path
variable correctly on this platform.

Bill.


On 28 September 2014 05:40, Waldek Hebisch hebi...@math.uni.wroc.pl wrote:
 Bill Page wrote:

 I would like to include:

   1) my extensions to the TeXmacs output format to include the full
 set of symbols supported by TeXmacs
  
 https://github.com/billpage/fricas/commit/d93ead5f231ab6b29ba76ff60017fd6a9848b0e4#diff-0

 Looks OK.  Please commit (after making sure full build works).

 --
   Waldek Hebisch
 hebi...@math.uni.wroc.pl

 --
 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+unsubscr...@googlegroups.com.
 To post to this group, send email to fricas-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/fricas-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Ralf Hemmecke]

On 10/01/2014 04:40 PM, Bill Page wrote:
 I have committed my changes for the texmacs interface to svn.  I can
 confirm that the full build works using SBCL 1.1.11-2.1.4-suse on
 64-bit OpenSuse 13.1.  I have not tested on any non-unicode supporting
 lisps.
 
 One minor note:  I can to modify the 3rd line of '/usr/localbin/fricas' from:
 
 AXIOM=${exec_prefix}/lib/fricas/target/x86_64-suse-linux
 
 to:
 
 AXIOM=${exec_prefix}/lib64/fricas/target/x86_64-suse-linux
 
 Apparently configure still does not set the library/executable path
 variable correctly on this platform.

That's not a configure problem.

https://github.com/fricas/fricas/blob/master/Makefile.in#L151

I guess this line

echo AXIOM='$${exec_prefix}/lib/fricas/target/$(target)' 
'${COMMAND}'.tmp

should be changed into something like

echo AXIOM='${libdir}/fricas/target/$(target)'  '${COMMAND}'.tmp

But Waldek apperently wanted to be able to set FRICAS_PREFIX in order to
be able to override exec_prefix. I.e. using libdir in this place will
probably not be approved by Waldek.

Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

Bill Page wrote:
 
 I would like to include:
 
   1) my extensions to the TeXmacs output format to include the full
 set of symbols supported by TeXmacs
  
 https://github.com/billpage/fricas/commit/d93ead5f231ab6b29ba76ff60017fd6a9848b0e4#diff-0

Looks OK.  Please commit (after making sure full build works).

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Ralf Hemmecke]

On 09/28/2014 02:18 AM, Waldek Hebisch wrote:
 Look at https://github.com/hemmecke/fricas/commits/cyldec .

 If accepted, I'll squash the 4 commits into just one and add a ChangeLog
 entry.

 http://www.math.uni.wroc.pl/~hebisch/fricas/cyldec.spad
 http://www.math.uni.wroc.pl/~hebisch/fricas/cyldec.input
 http://www.math.uni.wroc.pl/~hebisch/fricas/cyldec.diff
 
 The the first goes into src/algebra, the second into
 src/input, the third is makefile diff.

Waldek,

I'd appreciate to add Rioboo's code with two commits (and with the URLs
that I've put at the top of the file). First commit would be the
original code as is and the second commit with all the modifications to
make it run in FriCAS and beautify it.

Otherwise it seems that you have only done minor changes to Rioboo's code.

I don't really understand why you mention multi-index in

+-- i) each polynomial p in S is a product of q^{\alpha_q} for q in B
+--where \alpha is a multiindex

That are different q's so what is the multiindex here?

Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Ralf Hemmecke]

On 09/28/2014 05:12 PM, Waldek Hebisch wrote:
 I'd appreciate to add Rioboo's code with two commits (and with the
 URLs that I've put at the top of the file). First commit would be
 the original code as is and the second commit with all the
 modifications to make it run in FriCAS and beautify it.

 I am against commiting non-working version.

As you wish. But then such a commit

https://github.com/hemmecke/fricas/commit/3cb96bb40dc9ee1cedac165a37fd8d7a8cd22dc3

- f : ((RUP,RUP) - Boolean) := (degree(#1) = degree(#2))
+ f : ((RUP,RUP) - Boolean) := (x, y) +- (degree(x) = degree(y))

would be enough to make Rioboo's code compiling in FriCAS.

 Such versions may cause trouble when one searches for wrong commit by
 bisection.

I agree, that we shouldn't have non-compiling code, although one can
tell git-bisect to ignore non-compiling versions.

I'd still prefer the references to Rioboo's original code and to his
statement about the license (which I've added here:

https://github.com/hemmecke/fricas/commit/d2e1cd4a0bf15e1550a6e9b3d11901b9ebef3473

http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00125.html
http://lists.nongnu.org/archive/html/axiom-developer/2014-09/msg00028.html
http://rioboo.free.fr/CadPub/
)

Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Bill Page]

On 20 September 2014 09:19, Waldek Hebisch hebi...@math.uni.wroc.pl wrote:

  But then you get something quite different than 'Expression'.

 Bill Page wrote:

 That is not clear to me.  I think it is (almost) the same.

 Some people say that mutivariate calculus is almost the
 same as univariate.  But there are significant differences.
 Having two Wirtinger derivatives we have bivariate calculus
 instead of univariate one.


OK, but we also have:

  D(f(z), conjugate(z)) = conjugate D(conjugate(f(z)),z)


 If we have a good conjugate function then we may define other
 nonholomorphic functions like

   real(x) = x/2 + conjugate(x)/2

 so assumptions are not needed.

 I do not understand why you say so assumptions are not needed.
 IMO one of main simplifications for 'real' is replacing
 'real(x)' by 'x' when 'x' is real.  Clearly assumptions
 make such simplification more powerful.


Assumptions are logical statements involving quantification, e.g. ∀ x
∈ Real. Extending FriCAS in this direction seems likely to me to meet
the same limitations and level of difficulty associated with theorem
proving systems.  Of course doing so would make it more powerful.  But
I think it is more in keeping with the algebraic approach to just
define real as

  x = conjugate(x)

  that it assumes that f(x) cannot be independent of x
 
  Which is fundamental assumption in 'Expression'.
 

 I am not convinced that it is fundamental

 Theoretical foundation of advanced expression manipulations
 is theory of differential fields (and rings).  There are
 multivariate extensions, but several results is univariate-only.


I am not convinced that it is really necessary to treat Wirtinger
derivatives as multivariate.



  Richardson theorem tells you that
  once you drop this assumption you no longer can have computable
  zero test (even modulo constants).

 My (probably limited) understanding is that Richardson's theorem
 forbids abs.  Note: abs is already in Expression.  I only want to add
 conjugate.

 Well, if you want proper handling already 'abs' is problematic.
 'conjugate' just adds a new method of defining 'abs'.  So why
 I do not oppose to 'abs'?  For 'abs' applied to real arguments
 there is a way to sidestep the problem.  Namely, 'abs(x)' is
 either 'x' or '-x' (with overlap when 'x' is 0).  So given
 expression containing 'abs' is equivalent to a alternative
 of finitely many cases, each case containing no 'abs'.

How do we know if an argument is real?  As you imply, we could
eliminate abs and just define conjugate.

  sqrt(x*conjugate(x))

 By
 Richardson in general we can not decide which case is the
 right one.  But for many problems doing computations
 simultaneously on all cases gives us conservative approximation.

Perhaps both cases are right?

 Also, when 'x' is not 0, then 'abs(x)/x' is a piecewise constant
 (its derivative is 0).  This means that problems with with 'abs'
 can be reduced to constants.

We do have

  D(sqrt(x*conjugate(x))/x, x) + D(sqrt(x*conjugate(x))/x, conjugate x)
  eval(%,conjugate(x)=x)

   0

  We still have problem with
 constants (that is expressions with derivative 0) containing
 'abs'.   But they are lessened by fact that we do almost no
 simplifications of 'abs' – in many calculations 'abs' behaves
 like undefined function.  There are gaps in this argument, and
 our implementation has no explicit treatment of cases (which
 may lead to problems with zero divisors).  However, there is
 reasonably clear way to eliminate exisiting unsoudness.

 This argument break down when we have 'abs' of complex argument.
 So currently using 'abs' of complex argument is potentially
 unsound (in principle can lead to wrong results).  Once
 we use first Wirtinger derivative as derivative of 'conjugate',
 to be consistent we need to use first Wirtinger derivative as
 a derivative of 'abs'.  But this is inconsistent with treatment
 of 'abs' as a real function.


I would like to replace abs with equivalent expression involving conjugate.

 Note1: Richardson theorem says that we can not have complete
 handling of 'abs' or 'conjugate'.

I don't think Richardson theorem says anything about 'conjugate'.

  What I wrote above about
 'abs' outlines one approach which is incomplete but computable.
 Similarly, for 'conjugate' we need to find incomplete, but
 computable approximation.


Can you show that handling of 'conjugate' is undecidable?


 Why do you say that it forbids conjugate.  Can you give a reference?

 Because we assume univariate setting (more precisely single
 derivative per variable).  To be more precise: there are
 no obvious problems with leaving derivative of 'conjugate'
 undefined.  But any definition of derivative leads to
 two independent derivatives per variable.


The two derivatives are related by 'conjugate'.

 
  Do you still think that all users always want
  'conjugate(log(x)) = log(conjugate(x))'?  I would say
  to perform this transformation we need apropriate
  assumptions.

 log 

Re: [fricas-devel] New release

[Waldek Hebisch]

Bill Page wrote:
 
 On 14 September 2014 18:18, Waldek Hebisch hebi...@math.uni.wroc.pl wrote:
 
   But once you have 'abs' and 'conjugate' in 'Expression' assumption
  that all functions are holomorphic is unsound.
 
 conjugate is sufficient since we want abs(x)=sqrt(x*conjugate(x)).
 
 We should not make the assumption that all functions are holomorphic.

Yes.

 
   So using only one Wirtinger derivative in 'Expression' is unsound.
 
 Thank you for explaining what you meant by unsound.
 
  To make it sound you need to handle _both_ derivatives.
 
 Yes.
 
  But then you get something quite different than 'Expression'.
 
 That is not clear to me.  I think it is (almost) the same.

Some people say that mutivariate calculus is almost the
same as univariate.  But there are significant differences.
Having two Wirtinger derivatives we have bivariate calculus
instead of univariate one.

 
  In Axiom
  spirit one could define new domain which uses Wirtinger
  derivatives (say special variant of 'Complex').
 
 You mean maybe that
 
Complex Expression Integer
 
 could export a symbolic conjugate and Wirtinger derivatives? This
 seems awkward to me.  Wouldn't we also need to redefine FunctionSpace?

Yes.

 
   Or
  we could follow M-s and use assumption system and
  runtime test to decide if we can use single Wirtinger
  derivative.
 
 No. I've used this and I don't like it.
 
 If we have a good conjugate function then we may define other
 nonholomorphic functions like
 
   real(x) = x/2 + conjugate(x)/2
 
 so assumptions are not needed.

I do not understand why you say so assumptions are not needed.
IMO one of main simplifications for 'real' is replacing
'real(x)' by 'x' when 'x' is real.  Clearly assumptions
make such simplification more powerful.
 
  that it assumes that f(x) cannot be independent of x
 
  Which is _fundamental_ assumption in 'Expression'.
 
 
 I am not convinced that it is fundamental

Theoretical foundation of advanced expression manipulations
is theory of differential fields (and rings).  There are
multivariate extensions, but several results is univariate-only.

  ...
  The example shows that normalize now normalizes expressions containing
  conjugate successfully, but of course more testing is needed.
 
  Correctness of 'normalize' is a theorem.  In particular, 'normalize'
  is a zero test modulo constants.  You dropped one of main
  assumption of this theorem.
 
 Which assumption specifically?

That we work with differential field with one derivative per
variable.

 
  Richardson theorem tells you that
  once you drop this assumption you no longer can have computable
  zero test (even modulo constants).
 
 My (probably limited) understanding is that Richardson's theorem
 forbids abs.  Note: abs is already in Expression.  I only want to add
 conjugate.

Well, if you want proper handling already 'abs' is problematic.
'conjugate' just adds a new method of defining 'abs'.  So why
I do not oppose to 'abs'?  For 'abs' applied to real arguments
there is a way to sidestep the problem.  Namely, 'abs(x)' is
either 'x' or '-x' (with overlap when 'x' is 0).  So given
expression containing 'abs' is equivalent to a alternative
of finitely many cases, each case containing no 'abs'.  By
Richardson in general we can not decide which case is the
right one.  But for many problems doing computations
simultaneously on all cases gives us conservative approximation.
Also, when 'x' is not 0, then 'abs(x)/x' is a piecewise constant
(its derivative is 0).  This means that problems with with 'abs'
can be reduced to constants.  We still have problem with
constants (that is expressions with derivative 0) containing
'abs'.   But they are lessened by fact that we do almost no
simplifications of 'abs' -- in many calculations 'abs' behaves
like undefined function.  There are gaps in this argument, and
our implementation has no explicit treatment of cases (which
may lead to problems with zero divisors).  However, there is
reasonably clear way to eliminate exisiting unsoudness.

This argument break down when we have 'abs' of complex argument.
So currently using 'abs' of complex argument is potentially
unsound (in principle can lead to wrong results).  Once
we use first Wirtinger derivative as derivative of 'conjugate',
to be consistent we need to use first Wirtinger derivative as
a derivative of 'abs'.  But this is inconsistent with treatment
of 'abs' as a real function.

Note1: Richardson theorem says that we can not have complete
handling of 'abs' or 'conjugate'.  What I wrote above about
'abs' outlines one approach which is incomplete but computable.
Similarely, for 'conjugate' we need to find incomplete, but
computable approximation.

Note2: if derivative of 'conjugate' is left undefined, there
are plausible arguments that this does not lead to wrong
results.

  But expression machinery to avoid Richardson theorem
  must make some restricions.  Current theory basically
  forbids 'conjugate'.  To admit conjugate we 

Re: [fricas-devel] New release

[Ralf Hemmecke]

Hi Waldek,

 ATM git is a burden for me:
 on my main machine I accidentaly deleted my old git
 installation and I hit problem installing new version.

You must have a fairly strange or old computer that a git installation
is problematic.

 So currently I need to pull repo to server and than
 transfer files to my developement machine.

Are you saying your development machine has no Internet access?

Github allows a unified diff form of a commit. See ...

http://chem-bla-ics.blogspot.co.at/2011/01/github-tip-download-commits-as-patches.html

Just adding .patch to a github commit URL and downloading the diff
with wget or curl probably gives you the respective diff you want.

Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Bill Page]

On 2014-09-13 10:40 AM, Waldek Hebisch hebi...@math.uni.wroc.pl wrote:

 Bill Page wrote:
 
  I made a preliminary change to ElementaryFunctionStructurePackage here:
 

  http://axiom-wiki.newsynthesis.org/SandBoxElementaryFunctionStructurePackage
 
  which avoids the  Hidden constant detected error.  The main idea is
  just to avoid differentiating conjugate by replacing it with a dummy
  placeholder:
  ...
  Maybe you see a better way?

 I think that this is wrong way.  Namely you take unsound
 default (that is make 'D(conjugate(x), x)' equal to 0)

To my knowledge Wirtinger calculus, which defines D(conjugate(x),x) =
0, is an accepted albeit infrequently taught part of complex analysis
so your comment made me feel a bit irritated.  Perhaps the fact that
you seem to consider it unsound reflects a lack of knowledge or some
unstated prejudice?  The fundamental notion is that x and conjugate(x)
are independent of each other.  Do you think that this is wrong?

 and then try to 'opt out' in places where is causes
 troubles.

I do not want to opt out anywhere.  The problem in EFSTRUC seems to be
that it assumes that f(x) cannot be independent of x which of course
is not true for conjugate..The preliminary change was only intended to
avoid the bug.

I took a look at the code in EFSTRUC more carefully.  Now in an
updated version of

http://axiom-wiki.newsynthesis.org/SandBoxElementaryFunctionStructurePackage

I have the following code:

-- total Wirtinger derivative allows expressions containing
conjugate to be normalized
-- Wirtinger derivatives:  wdiff(f,x) and wdiff(f,conjugate(x))
wdiff(ex:F,z:K):F ==
  
eval(differentiate(eval(ex,[z],[coerce('%conjugate)]),'%conjugate),[kernel('%conjugate)],[z::F])
totalDifferentiate(f:F,x:SY):F ==
wdiff(f,kernel(x))+wdiff(f,kernels(conjugate(coerce
x)$FunctionalSpecialFunction(R, F))(1) )

For holmorphic functions the total Wirtinger derivative (sum of both
Wirtinger derivatives) is equal to the usual derivative since
D(f(x),conjugate(x)) is 0.  For non-holomorphic functions like
conjugate itself, the result is not zero.

The example shows that normalize now normalizes expressions containing
conjugate successfully, but of course more testing is needed.

 IME this leads to long tail of bugs, when
 thing constantly break out in new ways.  Instead,
 'opt in' when transformations are applied only when known
 safe is much better.  I understand that using unsafe
 transforamations by default may look attractive, because
 they are fequently correct and systems using them looks
 smarter when tested on simple examples (safe system may
 easily miss possibility of applying a transformation).


I do not consider this unsafe, though of course there may be still
more places in FriCAS that do not handle conjugate properly by
default.

 Basicaly D(conjugate(x), x) = 0 or even
 'conjugate(log(x)) = log(conjugate(x))' are too unsafe to
 apply them by default.  Rather they should be done by
 separate functions, which are either explicitely
 requested by user or called when we know that needed
 assumptions are satisfied.


I am not aware of any assumptions that are needed.

Bill.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

Bill Page wrote:
 
 On 2014-09-13 10:40 AM, Waldek Hebisch hebi...@math.uni.wroc.pl wrote:
 
  I think that this is wrong way.  Namely you take unsound
  default (that is make 'D(conjugate(x), x)' equal to 0)
 
 To my knowledge Wirtinger calculus, which defines D(conjugate(x),x) =
 0, is an accepted albeit infrequently taught part of complex analysis
 so your comment made me feel a bit irritated.  Perhaps the fact that
 you seem to consider it unsound reflects a lack of knowledge or some
 unstated prejudice?  The fundamental notion is that x and conjugate(x)
 are independent of each other.  Do you think that this is wrong?

Let me explain: Wirtinger derivatives are fine.  But they form
effectively _bivariate_ calculus.  More precisely, instead
of one complex variable we have two derivatives build from
derivatives in two real variables.  'Expression' assumes
single derivative per variable.  Wirtinger derivatives have
nice feature that on holomorphic functions the second derivative
is zero and can be ignored, so on holomorphic functions one can
work as in univariate setting.  But once you have 'abs' and
'conjugate' in 'Expression' assumption that all functions
are holomorphic is unsound.  So using only one Wirtinger
derivative in 'Expression' is unsound.  To make it sound
you need to handle _both_ derivatives.  But then you get
something quite different than 'Expression'.  In Axiom
spirit one could define new domain which uses Wirtinger
derivatives (say special variant of 'Complex').  Or
we could follow M-s and use assumption system and
runtime test to decide if we can use single Wirtinger
derivative.  But in current 'Expression' single
derivative per variable is an axiom.

 
  and then try to 'opt out' in places where is causes
  troubles.
 
 I do not want to opt out anywhere.  The problem in EFSTRUC seems to be
 that it assumes that f(x) cannot be independent of x

Which is _fundamental_ assumption in 'Expression'.

 which of course
 is not true for conjugate..The preliminary change was only intended to
 avoid the bug.

 
 I took a look at the code in EFSTRUC more carefully.  Now in an
 updated version of
 
 http://axiom-wiki.newsynthesis.org/SandBoxElementaryFunctionStructurePackage
 
 I have the following code:
 
 -- total Wirtinger derivative allows expressions containing
 conjugate to be normalized
 -- Wirtinger derivatives:  wdiff(f,x) and wdiff(f,conjugate(x))
 wdiff(ex:F,z:K):F ==
   
 eval(differentiate(eval(ex,[z],[coerce('%conjugate)]),'%conjugate),[kernel('%conjugate)],[z::F])
 totalDifferentiate(f:F,x:SY):F ==
 wdiff(f,kernel(x))+wdiff(f,kernels(conjugate(coerce
 x)$FunctionalSpecialFunction(R, F))(1) )
 
 For holmorphic functions the total Wirtinger derivative (sum of both
 Wirtinger derivatives) is equal to the usual derivative since
 D(f(x),conjugate(x)) is 0.  For non-holomorphic functions like
 conjugate itself, the result is not zero.
 
 The example shows that normalize now normalizes expressions containing
 conjugate successfully, but of course more testing is needed.

Correctness of 'normalize' is a theorem.  In particular, 'normalize'
is a zero test modulo constants.  You dropped one of main
assumption of this theorem.  Richardson theorem tells you that
once you drop this assumption you no longer can have computable
zero test (even modulo constants).  So your modified
'normalize' is not correct if you demand it to be zero test.
It is open question what your 'normalize' is doing, maybe it
is good enough to perform interesting calculations.  But
I am affraid that that it is nontrivial work to check and
adapt other parts of Expression machinery.

Let me add that it is quite interesting what you managed
to do with 'conjugate'.  But 'D(conjugate(x)) = 0' brings
us unconfortanly close to uncomputable problems.  If
we could have 'D(conjugate(x)) = 0' and retain power of
current algortiths, that would be significant progress.
But expression machinery to avoid Richardson theorem
must make some restricions.  Current theory basically
forbids 'conjugate'.  To admit conjugate we need some
extra restrictions.  

  Basicaly D(conjugate(x), x) = 0 or even
  'conjugate(log(x)) = log(conjugate(x))' are too unsafe to
  apply them by default.  Rather they should be done by
  separate functions, which are either explicitely
  requested by user or called when we know that needed
  assumptions are satisfied.
 
 
 I am not aware of any assumptions that are needed.

Consider:

(3) - conjugate(log(complex(-1.0, 0)))

   (3)  - 3.1415926535_897932385 %i
 Type: Complex(Float)
(4) - log(conjugate(complex(-1.0, 0)))

   (4)  3.1415926535_897932385 %i
 Type: Complex(Float)

Do you still think that all users always want 
'conjugate(log(x)) = log(conjugate(x))'?  I would say
to perform this transformation we need apropriate
assumptions.

-- 
  Waldek Hebisch

Re: [fricas-devel] New release

[Bill Page]

On 14 September 2014 18:18, Waldek Hebisch hebi...@math.uni.wroc.pl wrote:

 ...
 Let me explain: Wirtinger derivatives are fine.  But they form
 effectively _bivariate_ calculus.  More precisely, instead
 of one complex variable we have two derivatives build from
 derivatives in two real variables.

It isn't necessary to take exactly this view.  There are two
derivatives but we do not need to think of them as built from real
variables.

  'Expression' assumes single derivative per variable.


  Wirtinger derivatives have
 nice feature that on holomorphic functions the second derivative
 is zero and can be ignored, so on holomorphic functions one can
 work as in univariate setting.

Yes.

  But once you have 'abs' and 'conjugate' in 'Expression' assumption
 that all functions are holomorphic is unsound.

conjugate is sufficient since we want abs(x)=sqrt(x*conjugate(x)).

We should not make the assumption that all functions are holomorphic.

  So using only one Wirtinger derivative in 'Expression' is unsound.

Thank you for explaining what you meant by unsound.

 To make it sound you need to handle _both_ derivatives.

Yes.

 But then you get something quite different than 'Expression'.

That is not clear to me.  I think it is (almost) the same.

 In Axiom
 spirit one could define new domain which uses Wirtinger
 derivatives (say special variant of 'Complex').

You mean maybe that

   Complex Expression Integer

could export a symbolic conjugate and Wirtinger derivatives? This
seems awkward to me.  Wouldn't we also need to redefine FunctionSpace?

  Or
 we could follow M-s and use assumption system and
 runtime test to decide if we can use single Wirtinger
 derivative.

No. I've used this and I don't like it.

If we have a good conjugate function then we may define other
nonholomorphic functions like

  real(x) = x/2 + conjugate(x)/2

so assumptions are not needed.

  But in current 'Expression' single
 derivative per variable is an axiom.


I am not convinced that it needs to be an axiom.


 I do not want to opt out anywhere.  The problem in EFSTRUC seems to be
 that it assumes that f(x) cannot be independent of x

 Which is _fundamental_ assumption in 'Expression'.


I am not convinced that it is fundamental

 ...
 The example shows that normalize now normalizes expressions containing
 conjugate successfully, but of course more testing is needed.

 Correctness of 'normalize' is a theorem.  In particular, 'normalize'
 is a zero test modulo constants.  You dropped one of main
 assumption of this theorem.

Which assumption specifically?

 Richardson theorem tells you that
 once you drop this assumption you no longer can have computable
 zero test (even modulo constants).

My (probably limited) understanding is that Richardson's theorem
forbids abs.  Note: abs is already in Expression.  I only want to add
conjugate.

  So your modified
 'normalize' is not correct if you demand it to be zero test.

I agree only that it remains to proven whether it is possible to
include conjugate.

 It is open question what your 'normalize' is doing, maybe it
 is good enough to perform interesting calculations.  But
 I am affraid that that it is nontrivial work to check and
 adapt other parts of Expression machinery.


OK.  I am willing to continue to try to check this and suggest changes
where necessary.

 Let me add that it is quite interesting what you managed
 to do with 'conjugate'.  But 'D(conjugate(x)) = 0' brings
 us unconfortanly close to uncomputable problems.  If
 we could have 'D(conjugate(x)) = 0' and retain power of
 current algortiths, that would be significant progress.

It seems to me that this should be one goal of FriCAS: to make
significant progress ...

 But expression machinery to avoid Richardson theorem
 must make some restricions.  Current theory basically
 forbids 'conjugate'.  To admit conjugate we need some
 extra restrictions.

Why do you say that it forbids conjugate.  Can you give a reference?


 I am not aware of any assumptions that are needed.

 Consider:

 (3) - conjugate(log(complex(-1.0, 0)))

(3)  - 3.1415926535_897932385 %i
  Type: Complex(Float)
 (4) - log(conjugate(complex(-1.0, 0)))

(4)  3.1415926535_897932385 %i
  Type: Complex(Float)

 Do you still think that all users always want
 'conjugate(log(x)) = log(conjugate(x))'?  I would say
 to perform this transformation we need apropriate
 assumptions.

log of negative number is multi-valued.  The result above is not any
worse than returning -2 for sqrt(4) or similar in the case of inverse
trig functions.

Bill.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to 

Re: [fricas-devel] New release

[Waldek Hebisch]

Bill Page wrote:
 
 I made a preliminary change to ElementaryFunctionStructurePackage here:
 
   http://axiom-wiki.newsynthesis.org/SandBoxElementaryFunctionStructurePackage
 
 which avoids the  Hidden constant detected error.  The main idea is
 just to avoid differentiating conjugate by replacing it with a dummy
 placeholder:
 
 opNotConj : BasicOperator := operator('%conjugate)$CommonOperators
 opConjugate : BasicOperator := operator('conjugate)$CommonOperators
 noConj(k:K):F ==
   is?(k,'conjugate) = kernel(opNotConj,argument k)::F
   k::F
 toConj(k:K):F ==
   is?(k,'%conjugate) = kernel(opConjugate,argument k)::F
   k::F
 -- avoid trying to differentiate conjugate
 safeDifferentiate(f:F,x:SY):F ==
 rmap(toConj,differentiate(rmap(noConj,f),x))
 
 Maybe you see a better way?

I think that this is wrong way.  Namely you take unsound
default (that is make 'D(conjugate(x), x)' equal to 0)
and then try to 'opt out' in places where is causes
troubles.  IME this leads to long tail of bugs, when
thing constantly break out in new ways.  Instead,
'opt in' when transformations are applied only when known
safe is much better.  I understand that using unsafe
transforamations by default may look attractive, because
they are fequently correct and systems using them looks
smarter when tested on simple examples (safe system may
easily miss possibility of applying a transformation).

Basicaly D(conjugate(x), x) = 0 or even
'conjugate(log(x)) = log(conjugate(x))' are too unsafe to
apply them by default.  Rather they should be done by
separate functions, which are either explicitely
requested by user or called when we know that needed
assumptions are satisfied.

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[kfp]

Hello Bill

On Saturday, 13 September 2014 06:24:21 UTC+2, Bill Page wrote:

 Kurt, 

 Thanks for the example output. I am glad that it works and maybe it is 
 still an argument to include gnuDraw in the next release even if we do 
 not extend the TeXmacs interface to use it easily. 


*By all means*. I wonder anyway why it's not yet included. 

 


 I have never tried it but I thought maybe you could use the TeXmacs 
 gnuplot plugin? 

 http://www.texmacs.org/tmdoc/plugins/gnuplot/gnuplot-main.en.html 


A valuable hint, thank you. It's using a shell script tm_gnuplot which 
utilizes the 'ps' command of TeXmacs, otherwise it works along the same 
lines, i,e. generating a temp postscript file.   

 

 Your serializer plugin looks interesting.  Are you suggesting that a 
 much enhanced version of 

   tmm(s:String):String == s 

 might be used as a kind of TeXmacs mathmode interpreter for FriCAS? 
 I.e. It sees int(a,b,f(x)dx) from TeXmacs, executes 

   integrate(f(x),x=a..b) 

 then sends the result back to TeXmacs to be rendered? 


Indeed. However, the problems are numerous: simple expressions work well by 
some string manipulations, yet one has to consider that the user might not 
like how 'dx' is represented, for example, so he could insert whitespace 
which arrives as 'd x'. Similar problems arise if one forgets the '*' in 
multiplication operations etc. (see the example pdf).
I suppose that one needs a grammar+parser in order to get more than a toy. 
Even nested integrals may be hard to deal without some minimal (context 
aware) rules. One positive feature of the plugin init files is that one can 
easily map the keywords, e.g.

(in@in )
(cap   @cap )
(cup   @cup )
(subset@subset )   

so that they are properly separated (e.g. otherwise \forall x \in S = 
forallxinS ;)
I really don't know what's the best solution, maybe a combination of a 
packrat grammar (as described in 5.3)  on the TM side and a transformer on 
Fricas side?

BTW is 
tm_eval(s:String):Any ==
   inpForm:=parse(s)$InputForm
   interpret(inpForm) 

the correct way to evaluate string commands? The completer gives a 
'interpretString', but I didn't find any information to that.

Kurt
  




 




-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.


exdefint.pdf
Description: Adobe PDF document

Re: [fricas-devel] New release

[Waldek Hebisch]

Bill Page wrote:
 
 Waldek,
 
 With the version of FriCAS on the wiki and the most recent code for
 FunctionalSpecialFunction I get what look to me to be reasonable
 results for your examples labelled with (1), (3), (3) and (3) below.
 
 See:
 
 http://axiom-wiki.newsynthesis.org/SandBoxFunctionalSpecialFunction#eq27


Well, the examples illustrate that we use derivatives in a lot
of places and would get errors if derivative gives error.  Note
that for

series(conjugate(x), x=1)

error is the correct answer.  Certainly any expansison (in
particular one which appears in wiki page) is wrong.
I am affraid that we need to trap 'conjugate' is series
expanders and signal error.

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

kfp wrote:
 
 On Saturday, 13 September 2014 06:24:21 UTC+2, Bill Page wrote:
 
  Kurt, 
 
  Thanks for the example output. I am glad that it works and maybe it is 
  still an argument to include gnuDraw in the next release even if we do 
  not extend the TeXmacs interface to use it easily. 
 
 
 *By all means*. I wonder anyway why it's not yet included. 
 

Let me explain what I include in FriCAS.  First, we
need to have appropriate licence for included code.
If author request inclusion, than it is resonable
to assume the he/she automaticaly gives the licence.
If we have code that is BSD licenced on the net,
then we can use it.  But otherwise we have a problem.
In particular, we can not use code if there is no
licence.

Next, there must be some need.  Sometime I see that
code is doing something interesting, sometimes
sombody writes that code is worth inculding.
But if there is no info I can easily overlook something.
Releated problem is description.  Surprisingly it
is rare to get concise, accurate and undenstandable
description what code is doing.  Too frequently there
is no description at all.  Sometimes there is stated
goal, but no explanation what actually is accomplished
(xyz will streamline your software developement --
what this actually means?).  Sometimes there are
only examples with no descrition, sometimes
description without examples.  Anyway I would like
to know what code is doing and that somebody actually
needs this.

Next, I need to know what should be included.  It is
less trivial than it may sould because code may
appear in different places: as an attachemt in the list,
on the wiki, as a tarball, in somebodys git repo.
In many cases there are multiple versions and I need
to know which one should be included.  Even I there
is a single version I need to know that this version
should be included and I am not overlooking something.

I normally try code before inclusion.  For this I need
to get runnable code.  If code modifies existing files
than diff is most convenient for me (I need to estimate
impact on existing code and diff is easyest way to do
this).  If code is entirely new than say bunch of .spad
files or a tarball are fine.  For trying it is good
to have some examples.  In general there is good to
have some instruction.  Let me add that normally I
have a slow link.  So pictures are generaly undesirable,
I routinely ignore videos.  Rich websites are a burden
as they need extra effort.  ATM git is a burden for me:
on my main machine I accidentaly deleted my old git
installation and I hit problem installing new version.
So currently I need to pull repo to server and than
transfer files to my developement machine.  I want
to evantually resolve problem with git, but just now
I prefer to spent time on FriCAS and not on git.

Also, I read at least part of code to get some confidence
that it is correct, readable  and can be modified if
needed.

When there are problem with code than some fixes are
in place.  If I am including code mined on the net
I normally do needed adjustment myself.  OTOH if the
author request inclusion I write about things I consider
problematic and expect the author to resolve them
(fix or explain me that they are not a problem).
If author tells me the he/she does not know, how
to solve a problem I may do this myself.  If
author does not respond problems may lead to (possibly
quite long) delay.

Now, coming to gnuDraw.  IIUC it uses gnuplot to produce
graphs.  I have used gnuplot in the past and I must admit
that for me FriCAS produced graphs looks nicer and were
easier to use.   There are several years till last time
when I used gnuplot so it may improved.  And I just
needed specific capabilities and did not look at other.
But given that before inclusion I want to have string
support from others that it is needed.  IIRC after
first proposal for using gnuplot there was not much
support.  Later few persons requested inclusion
so there seem to be enough support, but one request
lacked other info (up to now it was even not clear
what is requested).  And even today I do not see
really clear proposal...

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[kfp]

Waldek,

I'm terribly sorry provoking the necessity of your exposition. The 
infelicity of the expression  I wonder anyway why it's not yet included 
is obvious (by hindsight). Nevertheless, your statements are clear and 
comprehensible. Nobody wants trash code included. 
Concerning GnuDraw: I'm having endorsed Fricas to a lot of people of which 
there are several cygwin users (mostly -nosman). The prize for endorsement 
a software is you will be asked for this and that, and especially plotting 
is a popular topic (a heritage of wxMaxima). To be short, I find GDRAW 
useful and do not know of any other (reliable) way to get some graphics 
(not HQ, I agree) for 'nosman's. It dates from 2008 as the header indicates 
and it's by no means a 'hack'. Of course, whether to include it in the 
distribution or not is debatable becuase it does not contribute to Fricas' 
core business: 'math'. I also would take much more pleasure in having 
included a package like 'quantifier elimination' let's say. OTOH there are 
users who want to plot, wish nice frontends, perfect documentation and 
whatsoever. It would be a pity to say use this or that M*, it has the 
feature, would'nt it? 
Back to the point: why not including such kind of modules in the 'contrib' 
folder under 'experimental, quarantine' or whatever so that users can 
compile and load it themselves? At least it would be there when needed. 

Kurt

   

On Sunday, 14 September 2014 03:32:58 UTC+2, Waldek Hebisch wrote:

 kfp wrote: 
  
  On Saturday, 13 September 2014 06:24:21 UTC+2, Bill Page wrote: 
   
   Kurt, 
   
   Thanks for the example output. I am glad that it works and maybe it is 
   still an argument to include gnuDraw in the next release even if we do 
   not extend the TeXmacs interface to use it easily. 
   
  
  *By all means*. I wonder anyway why it's not yet included. 
  

 Let me explain what I include in FriCAS.  First, we 
 need to have appropriate licence for included code. 
 If author request inclusion, than it is resonable 
 to assume the he/she automaticaly gives the licence. 
 If we have code that is BSD licenced on the net, 
 then we can use it.  But otherwise we have a problem. 
 In particular, we can not use code if there is no 
 licence. 

 Next, there must be some need.  Sometime I see that 
 code is doing something interesting, sometimes 
 sombody writes that code is worth inculding. 
 But if there is no info I can easily overlook something. 
 Releated problem is description.  Surprisingly it 
 is rare to get concise, accurate and undenstandable 
 description what code is doing.  Too frequently there 
 is no description at all.  Sometimes there is stated 
 goal, but no explanation what actually is accomplished 
 (xyz will streamline your software developement -- 
 what this actually means?).  Sometimes there are 
 only examples with no descrition, sometimes 
 description without examples.  Anyway I would like 
 to know what code is doing and that somebody actually 
 needs this. 

 Next, I need to know what should be included.  It is 
 less trivial than it may sould because code may 
 appear in different places: as an attachemt in the list, 
 on the wiki, as a tarball, in somebodys git repo. 
 In many cases there are multiple versions and I need 
 to know which one should be included.  Even I there 
 is a single version I need to know that this version 
 should be included and I am not overlooking something. 

 I normally try code before inclusion.  For this I need 
 to get runnable code.  If code modifies existing files 
 than diff is most convenient for me (I need to estimate 
 impact on existing code and diff is easyest way to do 
 this).  If code is entirely new than say bunch of .spad 
 files or a tarball are fine.  For trying it is good 
 to have some examples.  In general there is good to 
 have some instruction.  Let me add that normally I 
 have a slow link.  So pictures are generaly undesirable, 
 I routinely ignore videos.  Rich websites are a burden 
 as they need extra effort.  ATM git is a burden for me: 
 on my main machine I accidentaly deleted my old git 
 installation and I hit problem installing new version. 
 So currently I need to pull repo to server and than 
 transfer files to my developement machine.  I want 
 to evantually resolve problem with git, but just now 
 I prefer to spent time on FriCAS and not on git. 

 Also, I read at least part of code to get some confidence 
 that it is correct, readable  and can be modified if 
 needed. 

 When there are problem with code than some fixes are 
 in place.  If I am including code mined on the net 
 I normally do needed adjustment myself.  OTOH if the 
 author request inclusion I write about things I consider 
 problematic and expect the author to resolve them 
 (fix or explain me that they are not a problem). 
 If author tells me the he/she does not know, how 
 to solve a problem I may do this myself.  If 
 author does not respond problems may lead to 

Re: [fricas-devel] New release

[Bill Page]

Kurt,

Could you send an example of your use of gnuDraw in TeXmacs?  Perhaps
we could encourage Waldek to include the gnuDraw code in the new
release.

Maybe we could somehow embed your tmcmd into the TeXmacs FriCAS interface.

Bill.

On 9 September 2014 06:51, kfp nil...@gmail.com wrote:


 On Tuesday, 9 September 2014 02:43:21 UTC+2, Bill Page wrote:

 On 6 September 2014 10:27, kfp nil...@gmail.com wrote:
 
  On Friday, 5 September 2014 23:28:22 UTC+2, Bill Page wrote:
 
  There is some GNUplot stuff here:
 
  http://axiom-wiki.newsynthesis.org/GnuDraw
 


 Why do you think that GnuDraw requires X?  If it does, then perhaps I
 am missing something. :)



 You are right (how stupid of me) it doesn't need X at all. The term
 'viewport manager' in the output snippet below let me assume that some
 window should pop up ;) Of course, output goes to the file specified and gp
 works fine. I'm glad that it works, it's much more sophisticated than the
 simple gnuplot function.

 Thanks and sorry for the confusion
 Kurt

  (8) - gnuDraw(%,z=-5..5,testfile1.dat,title==fun2)
Compiling function %I with type DoubleFloat - DoubleFloat
Graph data being transmitted to the viewport manager...
FriCAS2D data being transmitted to the viewport manager...




On 5 September 2014 17:15, kfp nil...@gmail.com wrote:

 Hi

 I glanced at the plotting capabilities of Fricas in order to provide some
 basic functionality for the 'kernel'. Naturally, I also searched this list
 for any hints as I try to avoid reinventing the wheel. After all the matter
 is quite confusing to me. Thus I dare asking some questions:

 a) Is there any strategy to refurbish graphics output?
 b) Is there any library which provides (file) output for some of the common
 plotting/viewing packages? E.g. GLE, Asymptote, Gnuplot, matplotlib,
 Paraview, jmol  ...
 For instance GLE and Asymptote provide nice ps output which could be
 automatically inserted into a frontend (IPy, TeXmacs). In TeXmacs it's even
 possible to receive 'ps' out of Fricas directly with the \x2ps:..\x5
 sequence. Therefore: is any of the current plotting routines able to give
 Postscript output to stdout?
 c) What is the state of the Plot() domain? The 'coerce' gives some output
 (e.g. =plot((x:DF +- x^2),1.0::DF..2.0::DF)@Plot), however, what was the
 purpose of this? Terminal graphics?

 I found some promising links in the thread: Re:[Axiom-mail] gnuplot on
 axiom-wiki , but the links seem to be dead. I read there that Bill Page had
 something in the direction of Gnuplot script output. This could be a
 starting point and I would be rather interested to use it in texmacs. The
 following two functions allow to insert graphics into tm while using the
 plugin, so a ready-to-use 'myplot' command could easily be patched up (not
 only for gnuplot).

 tmcmd(cmd:String):Void == print (concat [char 2,command:,cmd,char 5]);

 tm_inline_image(url:String):Void ==
options:= __ __ __ __ ))
q:=_
tmcmd(concat [(make-inline-image (list , q, url, q, options])


 Kurt


-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Bill Page]

Waldek,

With the version of FriCAS on the wiki and the most recent code for
FunctionalSpecialFunction I get what look to me to be reasonable
results for your examples labelled with (1), (3), (3) and (3) below.

See:

http://axiom-wiki.newsynthesis.org/SandBoxFunctionalSpecialFunction#eq27

Your example (24) still returns the library error: Hidden constant
detected.  Do you have any hints as to where I should look in the
source code?

Bill.

On 11 September 2014 22:23, Bill Page bill.p...@newsynthesis.org wrote:
 ...

 I would like to collect some examples of such errors.


 Thank you very much for these!


 With your current code:

 (24) - normalize(exp(conjugate(x)+x)+exp(x) + exp(conjugate(x)))
_

 Error detected within library code:
Hidden constant detected

 With derivative of 'conjugate' changes to error:

 (1) - integrate(exp(conjugate(y)*x), x)

 Error detected within library code:
differentiating conjugate

 (3) - normalize(exp(conjugate(y)*x)+exp(x))

 Error detected within library code:
differentiating conjugate

 (3) - limit(exp(conjugate(y)*x), x=%plusInfinity)

 Error detected within library code:
differentiating conjugate

 (3) - series(conjugate(x), x=1)


 Error detected within library code:
differentiating conjugate


 The last example produces a result using the version of FriCAS
 currently installed on the wiki.  Is it correct?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[kfp]

On Friday, 12 September 2014 16:26:07 UTC+2, Bill Page wrote:

 Kurt, 

 Could you send an example of your use of gnuDraw in TeXmacs?  Perhaps 
 we could encourage Waldek to include the gnuDraw code in the new 
 release. 

 Maybe we could somehow embed your tmcmd into the TeXmacs FriCAS interface. 

 Bill. 



I'm afraid it would be slightly premature as the sample Pdf shows ;) I have 
to figure out the missing options to place the image in a reasonable way 
(e.g. insert text-field or figure environment). The goal is to send high 
quality postscript to TeXmacs (using tm's ps command), ideally without 
using intermediate files or inserting images. I'm quite confident that this 
is possible (... maybe for the next release :) 
BTW while writing a serializer à la 
http://www.texmacs.org/joris/semedit/semedit.html I collected a lot of 
internal (mostly undocumented) scheme commands which permit controlling TM 
in almost every aspect with tmcmd. The code below, for instance, sends any 
mathematical input as  function tmm(math_input) to Fricas. It seems 
easier to me to parse and interpret the input by Fricas than by scheme 
procedures (e.g. fircas-input.scm). If one defines tmm(s:String):String == s, 
one can see how TM serializes by default. E.g. entering in math-mode \int_a^b 
f(x) dx sends int(a,b,f(x)dx) which is easily transformed to the 
corresponding Fricas command. To be short, this way I  got a pile of TM 
related functions which may be useful to the plugin. However, everything 
has yet to be thouroughly tested and polished before inclusion. 
   

(define (fricas-verbatim-serialize lan t)
  (import-from (utils plugins plugin-cmd))
  (with u (pre-serialize lan t)   
(string-append tmm(\ (escape-verbatim (texmacs-code u)) \)\n)))

(define (fricas-serialize lan t)
  (import-from (utils plugins plugin-cmd))
  (import-from (utils plugins plugin-convert))
  (with s (if (in-math?)
 (fricas-verbatim-serialize lan t) 
(verbatim-serialize lan t))
s))
  
(plugin-configure fricas
  (:require #t)
  (:initialize (fricas-initialize))
  (:launch fricas --texmacs)
  (:session Fricas)
  (:serializer ,fricas-serialize)
  ;(:commander ,fricas-command)
  (:tab-completion #t)
  (:scripts Fricas))


Kurt

 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.


gnudraw_sample.pdf
Description: Adobe PDF document

Re: [fricas-devel] New release

[Bill Page]

Kurt,

Thanks for the example output. I am glad that it works and maybe it is
still an argument to include gnuDraw in the next release even if we do
not extend the TeXmacs interface to use it easily.

I have never tried it but I thought maybe you could use the TeXmacs
gnuplot plugin?

http://www.texmacs.org/tmdoc/plugins/gnuplot/gnuplot-main.en.html

Your serializer plugin looks interesting.  Are you suggesting that a
much enhanced version of

  tmm(s:String):String == s

might be used as a kind of TeXmacs mathmode interpreter for FriCAS?
I.e. It sees int(a,b,f(x)dx) from TeXmacs, executes

  integrate(f(x),x=a..b)

then sends the result back to TeXmacs to be rendered?

Bill.

On 12 September 2014 23:52, kfp nil...@gmail.com wrote:


 On Friday, 12 September 2014 16:26:07 UTC+2, Bill Page wrote:

 Kurt,

 Could you send an example of your use of gnuDraw in TeXmacs?  Perhaps
 we could encourage Waldek to include the gnuDraw code in the new
 release.

 Maybe we could somehow embed your tmcmd into the TeXmacs FriCAS interface.

 Bill.



 I'm afraid it would be slightly premature as the sample Pdf shows ;) I have
 to figure out the missing options to place the image in a reasonable way
 (e.g. insert text-field or figure environment). The goal is to send high
 quality postscript to TeXmacs (using tm's ps command), ideally without using
 intermediate files or inserting images. I'm quite confident that this is
 possible (... maybe for the next release :)
 BTW while writing a serializer à la
 http://www.texmacs.org/joris/semedit/semedit.html I collected a lot of
 internal (mostly undocumented) scheme commands which permit controlling TM
 in almost every aspect with tmcmd. The code below, for instance, sends any
 mathematical input as  function tmm(math_input) to Fricas. It seems easier
 to me to parse and interpret the input by Fricas than by scheme procedures
 (e.g. fircas-input.scm). If one defines tmm(s:String):String == s, one can
 see how TM serializes by default. E.g. entering in math-mode \int_a^b f(x)
 dx sends int(a,b,f(x)dx) which is easily transformed to the corresponding
 Fricas command. To be short, this way I  got a pile of TM related functions
 which may be useful to the plugin. However, everything has yet to be
 thouroughly tested and polished before inclusion.


 (define (fricas-verbatim-serialize lan t)
   (import-from (utils plugins plugin-cmd))
   (with u (pre-serialize lan t)
 (string-append tmm(\ (escape-verbatim (texmacs-code u)) \)\n)))

 (define (fricas-serialize lan t)
   (import-from (utils plugins plugin-cmd))
   (import-from (utils plugins plugin-convert))
   (with s (if (in-math?)
  (fricas-verbatim-serialize lan t)
 (verbatim-serialize lan t))
 s))

 (plugin-configure fricas
   (:require #t)
   (:initialize (fricas-initialize))
   (:launch fricas --texmacs)
   (:session Fricas)
   (:serializer ,fricas-serialize)
   ;(:commander ,fricas-command)
   (:tab-completion #t)
   (:scripts Fricas))


 Kurt



 --
 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+unsubscr...@googlegroups.com.
 To post to this group, send email to fricas-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/fricas-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Bill Page]

I made a preliminary change to ElementaryFunctionStructurePackage here:

  http://axiom-wiki.newsynthesis.org/SandBoxElementaryFunctionStructurePackage

which avoids the  Hidden constant detected error.  The main idea is
just to avoid differentiating conjugate by replacing it with a dummy
placeholder:

opNotConj : BasicOperator := operator('%conjugate)$CommonOperators
opConjugate : BasicOperator := operator('conjugate)$CommonOperators
noConj(k:K):F ==
  is?(k,'conjugate) = kernel(opNotConj,argument k)::F
  k::F
toConj(k:K):F ==
  is?(k,'%conjugate) = kernel(opConjugate,argument k)::F
  k::F
-- avoid trying to differentiate conjugate
safeDifferentiate(f:F,x:SY):F ==
rmap(toConj,differentiate(rmap(noConj,f),x))

Maybe you see a better way?

Bill.

On 12 September 2014 20:40, Bill Page bill.p...@newsynthesis.org wrote:
 Waldek,

 With the version of FriCAS on the wiki and the most recent code for
 FunctionalSpecialFunction I get what look to me to be reasonable
 results for your examples labelled with (1), (3), (3) and (3) below.

 See:

 http://axiom-wiki.newsynthesis.org/SandBoxFunctionalSpecialFunction#eq27

 Your example (24) still returns the library error: Hidden constant
 detected.  Do you have any hints as to where I should look in the
 source code?

 Bill.

 On 11 September 2014 22:23, Bill Page bill.p...@newsynthesis.org wrote:
 ...

 I would like to collect some examples of such errors.


 Thank you very much for these!


 With your current code:

 (24) - normalize(exp(conjugate(x)+x)+exp(x) + exp(conjugate(x)))
_

 Error detected within library code:
Hidden constant detected

 With derivative of 'conjugate' changes to error:

 (1) - integrate(exp(conjugate(y)*x), x)

 Error detected within library code:
differentiating conjugate

 (3) - normalize(exp(conjugate(y)*x)+exp(x))

 Error detected within library code:
differentiating conjugate

 (3) - limit(exp(conjugate(y)*x), x=%plusInfinity)

 Error detected within library code:
differentiating conjugate

 (3) - series(conjugate(x), x=1)


 Error detected within library code:
differentiating conjugate


 The last example produces a result using the version of FriCAS
 currently installed on the wiki.  Is it correct?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

Bill Page wrote:

 On 8 September 2014 15:15, Waldek Hebisch hebi...@math.uni.wroc.pl wrote:
  Bill Page wrote:
 
  I would like to include:
 
2) my code for adding conjugate to special functions
http://axiom-wiki.newsynthesis.org/SandBoxFunctionalSpecialFunction
 
  Definitions you gave are debatable.  In particular
  'D(conjugate(x), x) = 0' may lead to troubles.  For example,
  'D(conjugate(conjugate(x)), x)' should be equal to 'D(x, x) = 1'
  regardless how we compute it.  Consider:
 
  y := operator 'y
  D(conjugate(y(x)), x)
 
  substituting 'conjugate(x)' for 'y(x)' and derivative of
  'conjugate(x)' for derivative of 'y(x)' should give derivative
  of 'conjugate(conjugate(x))'.
 
 
 The code that I wrote for conjugate assumes that operators always
 represent holomorphic functions, while conjugate itself is explicitly
 not holomorphic so a substitution such as you suggest does not make
 sense.

You clearly allow non-holomorphic arguments to conjugate, otherwise
'conjugate(conjugate(x))' would be illegal.  Rather, you assume
that conjugate will be always pushed onto variables/parameters
and that _in context of differentiation_ we will substitute
only holomorphic functions for variables.  But in other
context you allow non-holomorphic things.  Pushing conjugate
to variables in itself is debatable:

(14) - conjugate(log(-1))

 
   (14)  log(- 1)
Type: Expression(Integer)
(15) - eval(conjugate(log(x)), x = -1)

   (15)  log(- 1)
Type: Expression(Integer)

you get different result depending on when exactly we plug in
constant argument to logarithm.

You have:

(21) - conjugate(log(conjugate(x) + x))

 _
   (21)  log(x + x)
Type: Expression(Integer)

but when real part of x is negative we are on the conventional
branch cut of logarithm and some folks may be upset by such
simplification (not that unlike previous example where problem
set was of lower dimension here we have problem on open set).

 
 The reason that I wanted D(conjugate(x), x) = 0 is to have D
 correspond to the first Wirtinger derivative that I mentioned in
 another email chain.  It is not clear to me that this could result in
 nasty bugs.  Maybe this is possible in the cases where the chain rule
 is applied since in that case the conjugate Wirtinger derivative would
 be required.

But chain rule is applied automatically when computing derivatives.
Consider:

(13) - D(abs(x + conjugate(x)), x)

_
x + x
   (13)  ---
  _
 2abs(x + x)
Type: Expression(Integer)

complex (Wirtinger) derivative of the above is twice of the above.

 
  If what I wrote looks like nitpicking let me note that FriCAS
  blindly applies rather complex transformations.  For example
  during integration internal form is quite different than
  user input and final result.  Inconsistency in derivative
  rule will bring all kinds of nasty bugs.
 
  We probably can leave derivative of 'conjugate' unevaluated.
 
 Maybe only as a last resort.  (This is what Maple does.)

Actually, it seems that even leaving derivatives of conjugate
unevaluated we need to be careful.  Namely, given
a differential Ring R_0 and any formal operation f we can form
differential ring R_1 where f and all its derivative remain
unevaluated.  But we want to have _some_ simplification
so we divide R_1 by appropriate equivalence relation.
For the result to be a differential ring equivalence
classes should be cosets of a differential ideal, in
particular set of elements of R_1 equivalent to 0
should be a differential ideal.  So we need to make
sure that simplifications are consistent with
derivative.

  But even that needs some thought to make sure there are
  no inconsistency.  Signaling error would be safe from
  correctness point of view, but would significantly limit
  usefulness -- code handling expressions assumes that it
  can freely compute derivatives, so when dealing with
  'conjugate' we would routinely get errors deep inside
  library code.
 
 
 I would like to collect some examples of such errors.


With your current code:

(24) - normalize(exp(conjugate(x)+x)+exp(x) + exp(conjugate(x)))
   _
 
Error detected within library code:
   Hidden constant detected

With derivative of 'conjugate' changes to error:

(1) - integrate(exp(conjugate(y)*x), x)
 
Error detected within library code:
   differentiating conjugate

(3) - normalize(exp(conjugate(y)*x)+exp(x))
 
Error detected within library code:
   differentiating conjugate

(3) - limit(exp(conjugate(y)*x), x=%plusInfinity)
 
Error detected within library code:
   differentiating conjugate

(3) - series(conjugate(x), x=1)

 
Error detected within library code:
   differentiating conjugate

-- 
  Waldek 

Re: [fricas-devel] New release

[Bill Page]

Thanks Waldek. As usual I appreciate your thorough look at what I
wrote for conjugate.

On 11 September 2014 07:28, Waldek Hebisch hebi...@math.uni.wroc.pl wrote:
  Bill Page wrote:

 The code that I wrote for conjugate assumes that operators always
 represent holomorphic functions, while conjugate itself is explicitly
 not holomorphic so a substitution such as you suggest does not make
 sense.

 You clearly allow non-holomorphic arguments to conjugate, otherwise
 'conjugate(conjugate(x))' would be illegal.

Yes.  What I meant was the conjugate assumes the an *user-defined*
operator and *most* built-in functions are holomorphic.  conjugate
itself, as well as abs are non-holomorphic.  Maybe there are others?

 Rather, you assume
 that conjugate will be always pushed onto variables/parameters
 and that _in context of differentiation_ we will substitute
 only holomorphic functions for variables.

I assume that conjugate commutes with (most) other functions.

It is not my intention to make assumptions about what functions
(holomorphic or non-holomorphic) witll be substituted for variables.
Can you give me an example where I seem to be doing that?

  But in other
 context you allow non-holomorphic things.

I want to allow non-holomorphic things where ever possible.

 Pushing conjugate
 to variables in itself is debatable:

 (14) - conjugate(log(-1))

  
(14)  log(- 1)
 Type: Expression(Integer)
 (15) - eval(conjugate(log(x)), x = -1)

(15)  log(- 1)
 Type: Expression(Integer)

 you get different result depending on when exactly we plug in
 constant argument to logarithm.


This was an error in my code that I have fixed in the most recent
version on the wiki.

The new code in FunctionalSpecialFunction is the following:

evaluate(opconjugate, iiconjugate)$BasicOperatorFunctions1(F)
--
dconjugate(lo : List OF) : OF == overbar lo.1
display(opconjugate,dconjugate)
--
derivative(opconjugate, (x : F) : F +- 0)
--
iiconjugate(x:F):F ==
  is?(x, opconjugate) = argument(retract(x)@K)(1)
  is?(x, opabs) = x
  retractIfCan(x)@Union(Symbol, failed) case Symbol = iconjugate(x)
  x:=eval(x,kernels(x), _
map((k:Kernel F):F +- _
  ( (height(k)=0 or height(k)=1 and
retractIfCan(k::F)@Union(Symbol, failed) case Symbol)
=iconjugate(k::F);map(iiconjugate,k)), _
  kernels(x))$ListFunctions2(Kernel F,F))
  if R has conjugate : R - R then
x:=map(conjugate$R,numer x)::F / _
  map(conjugate$R,denom x)::F
  return x
--
iconjugate x ==
  zero? x = 0
  is?(x, opconjugate) = argument(retract(x)@K)(1)
  is?(x, opabs) = x
  kernel(opconjugate, x)
--
if R has abs : R - R then
  import from Polynomial R
  iiabs x ==
(r := retractIfCan(x)@Union(Fraction Polynomial R, failed))
  case failed = iabs x
f := r::Fraction Polynomial R
(a := retractIfCan(numer f)@Union(R, failed)) case failed or
  (b := retractIfCan(denom f)@Union(R,failed)) case failed = iabs x
abs(a::R)::F / abs(b::R)::F
else iiabs x == iabs x
--
iabs x ==
  zero? x = 0
  one? x = 1
  is?(x, opabs) = x
  is?(x, opconjugate) = kernel(opabs, argument(retract(x)@K)(1))
  if R has abs : R - R then
a := retractIfCan(x)@Union(R, failed)
a case R = abs(a::R)::F
  smaller?(x, 0) = kernel(opabs, -x)
  kernel(opabs, x)
--

I am still a little uncomfortable with how I wrote the recursion in
iiconjugate. In the most recent version I changed slightly how I use
height(k).  I did not realized that variables (symbols) and kernels
like log(-1) are both said to have height of 1 in the
expression/kernel tree structure..  Maybe there is a better way?

 You have:

 (21) - conjugate(log(conjugate(x) + x))
_
(21)  log(x + x)
 Type: Expression(Integer)

 but when real part of x is negative we are on the conventional
 branch cut of logarithm and some folks may be upset by such
 simplification (not that unlike previous example where problem
 set was of lower dimension here we have problem on open set).

I don't understand your comment.  If log is holomorphic I do not see a
problem with this result.  Could you explain?



 The reason that I wanted D(conjugate(x), x) = 0 is to have D
 correspond to the first Wirtinger derivative that I mentioned in
 another email chain.  It is not clear to me that this could result in
 nasty bugs.  Maybe this is possible in the cases where the chain rule
 is applied since in that case the conjugate Wirtinger derivative would
 be required.

 But chain rule is applied automatically when computing derivatives.

Yes, I admit that might be a problem.

 Consider:

 (13) - D(abs(x + conjugate(x)), x)

 _
 x + x
(13)  ---
   _

Re: [fricas-devel] New release

[Bill Page]

I would like to include:

  1) my extensions to the TeXmacs output format to include the full
set of symbols supported by TeXmacs
 
https://github.com/billpage/fricas/commit/d93ead5f231ab6b29ba76ff60017fd6a9848b0e4#diff-0

  2) my code for adding conjugate to special functions
  http://axiom-wiki.newsynthesis.org/SandBoxFunctionalSpecialFunction

I will try to bring my github repository up to date with both of these patches.


On 7 September 2014 19:27, Waldek Hebisch hebi...@math.uni.wroc.pl wrote:
 I think we should do a new release in September.  Actually,
 I planned to do release earlier, but real life severly
 limited time I can spend on FriCAS and slowed me down.

 If there is some code you want included in new release
 please speak up.

 --
   Waldek Hebisch
 hebi...@math.uni.wroc.pl

 --
 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+unsubscr...@googlegroups.com.
 To post to this group, send email to fricas-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/fricas-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

Bill Page wrote:
 
 I would like to include:
 
   2) my code for adding conjugate to special functions
   http://axiom-wiki.newsynthesis.org/SandBoxFunctionalSpecialFunction

Definitions you gave are debatable.  In particular
'D(conjugate(x), x) = 0' may lead to troubles.  For example,
'D(conjugate(conjugate(x)), x)' should be equal to 'D(x, x) = 1'
regardless how we compute it.  Consider:

y := operator 'y
D(conjugate(y(x)), x)

substituting 'conjugate(x)' for 'y(x)' and derivative of
'conjugate(x)' for derivative of 'y(x)' should give derivative
of 'conjugate(conjugate(x))'.

If what I wrote looks like nitpicking let me note that FriCAS
blindly applies rather complex transformations.  For example
during integration internal form is quite different than
user input and final result.  Inconsistency in derivative
rule will bring all kinds of nasty bugs.

We probably can leave derivative of 'conjugate' unevaluated.
But even that needs some thought to make sure there are
no inconsistency.  Signaling error would be safe from
correctness point of view, but would significantly limit
usefulness -- code handling expressions assumes that it
can freely compute derivatives, so when dealing with
'conjugate' we would routinely get errors deep inside
library code.

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Ralf Hemmecke]

On 09/08/2014 01:27 AM, Waldek Hebisch wrote:
 If there is some code you want included in new release
 please speak up.

I don't know whether it must be included, but there was
https://www.mail-archive.com/fricas-devel@googlegroups.com/msg07524.html

And in fact, on top of that is the generation of the AXIOM book (with
some new content that is fricas specific or was on NAGcdrom, but is not
in the printed version of the book).

https://github.com/hemmecke/fricas/commits/fricas-book

Although I would like to see this in a new release, there has not yet
been enough discussion/review to justify immediate commit. Naturally, I
think my TexFormat is much better, but I rather wait for comments.

In the same style as my TexFormat, it should be relatively easy to
produce a domain that outputs 1D instead of 2D format. Furthermore, I
believe also MathMLFormat and TexmacsFormat would benefit from the
greater flexibility I introduced in TexFormat.

I also have the code waiting that produces http://fricas.github.io/api/,
but I would have to work quite a bit to make a proper patch for
inclusion into FriCAS. So that can wait.

Well, and we should definitely get CAD into the new release. That code
is already waiting for years.

Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Bill Page]

Waldek,

Thanks for looking at this.

On 8 September 2014 15:15, Waldek Hebisch hebi...@math.uni.wroc.pl wrote:
 Bill Page wrote:

 I would like to include:

   2) my code for adding conjugate to special functions
   http://axiom-wiki.newsynthesis.org/SandBoxFunctionalSpecialFunction

 Definitions you gave are debatable.  In particular
 'D(conjugate(x), x) = 0' may lead to troubles.  For example,
 'D(conjugate(conjugate(x)), x)' should be equal to 'D(x, x) = 1'
 regardless how we compute it.  Consider:

 y := operator 'y
 D(conjugate(y(x)), x)

 substituting 'conjugate(x)' for 'y(x)' and derivative of
 'conjugate(x)' for derivative of 'y(x)' should give derivative
 of 'conjugate(conjugate(x))'.


The code that I wrote for conjugate assumes that operators always
represent holomorphic functions, while conjugate itself is explicitly
not holomorphic so a substitution such as you suggest does not make
sense.

The reason that I wanted D(conjugate(x), x) = 0 is to have D
correspond to the first Wirtinger derivative that I mentioned in
another email chain.  It is not clear to me that this could result in
nasty bugs.  Maybe this is possible in the cases where the chain rule
is applied since in that case the conjugate Wirtinger derivative would
be required.

 If what I wrote looks like nitpicking let me note that FriCAS
 blindly applies rather complex transformations.  For example
 during integration internal form is quite different than
 user input and final result.  Inconsistency in derivative
 rule will bring all kinds of nasty bugs.

 We probably can leave derivative of 'conjugate' unevaluated.

Maybe only as a last resort.  (This is what Maple does.)

 But even that needs some thought to make sure there are
 no inconsistency.  Signaling error would be safe from
 correctness point of view, but would significantly limit
 usefulness -- code handling expressions assumes that it
 can freely compute derivatives, so when dealing with
 'conjugate' we would routinely get errors deep inside
 library code.


I would like to collect some examples of such errors.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Ralf Hemmecke]

 If there is some code you want included in new release
 please speak up.

I've just put together the patch of Rioboo's CAD package.

I had to modify #1 to +- but otherwise no problem.

Look at https://github.com/hemmecke/fricas/commits/cyldec .

If accepted, I'll squash the 4 commits into just one and add a ChangeLog
entry.

Ralf


-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] New release

[Waldek Hebisch]

I think we should do a new release in September.  Actually,
I planned to do release earlier, but real life severly
limited time I can spend on FriCAS and slowed me down.

If there is some code you want included in new release
please speak up.

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] New release

[Waldek Hebisch]

Ralf Hemmecke wrote:
 
 For the non-free Aldor actually nothing changes, except that then FriCAS
 distributes the respective .as files. If things worked or didn't work
 before, the same happens with the patch.
 
 For the free Aldor we have seen the problem, but I haven't yet seen more
 issues that would justify that FriCAS would not be better of
 distributing these few .as files directly rather than modifying the
 downloading bits so that these .as files are downloaded from Pippijn's
 repo rather than from aldor.org (which I currently don't know whether it
 actually works).
 
 So all speaks for inclusion.
 
I would rather postpone including changes to Aldor interface.  I had
problems building Aldor from git repo (as reported on Aldor list).
It worked on test machine running Debian testing, but to the moment
it failed on other machines.  This probably can be fixed in few
days.  However, other things for release took longer than I
hoped but finally are ready.  So I would like to release without
extra delay.

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] New release

[Waldek Hebisch]

 can you take a look at my patch at
 https://github.com/hemmecke/fricas/commits/fricas-aldor-local
 ? I'm not yet sure whether to copy the aldor source directory structure
 or rather make it flat inside the fricas tree, but at least I'd like to
 hear a comment about this patch.

I took a quick look at the patch.  I do not understand what you mean
by copy the aldor source directory structure...?  If you mean the
few files needed for FriCAS-Aldor interface than definitely flat
is better.
 
 I would like to include this code even if it's not yet clear whether the
 new aldor compiler actually properly works together with fricas.
 However, by exposing it to the public it's easier to get feedback.

What you mean by properly works?  The problem you reported can
be reproduced using free Aldor from aldor.org.  I did not try
it with non-free Aldor, but given how small are differences
between non-free and free version I would expect the same
results.  OTOH if there are important things that used to
work but fail now, then this would be good reason to delay
merging it.

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[fricas-devel] New release

[Waldek Hebisch]

I plan new release is second half of September.  I would like
to include some new code so the exact date is still fluid.

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] New release

[Ralf Hemmecke]

 I would like to do a new release in June.

Seems like you want to postpone the documentation patches that I am
working on at the moment?

Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] New release

[Waldek Hebisch]

 
  I would like to do a new release in June.
 
 Seems like you want to postpone the documentation patches that I am
 working on at the moment?

My impresion was that the remaning problems can be fixed
very quicky.  I this wrong?
 
-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] New release

[Ralf Hemmecke]

 My impresion was that the remaning problems can be fixed
 very quicky.

Right.

The only problem I see is that I am the only person who looked over the
files. I've actually checked the differences carefully, but more eyes
would be better (of course).

I tend not to include the mobius stuff. mobius.input and the generated
picture only appears inside graphics.ht where there is a description of
how to use \spadviewport.

https://github.com/hemmecke/fricas/blob/htexdoc/src/hyper/pages/graphics.ht#L1224

I'm rather in favour of either removing that Stand-alone Viewport
section completely or use an already generated image in this place.

I'll also go over the src/hyper/pages/*.ht files. Many of them are now
redundant.

What I cannot do is to generate the whole AXIOM book. That is for later
if someone still wants a printed version. I think, transforming into
HTML serves the community much better than a PDF file. So I will rather
work on producing a web format of the documentation. But also that will
not be ready for the next release.

Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] New release

[Waldek Hebisch]

Ralf Hemmecke wrote:
 
 I tend not to include the mobius stuff. mobius.input and the generated
 picture only appears inside graphics.ht where there is a description of
 how to use \spadviewport.
 
 https://github.com/hemmecke/fricas/blob/htexdoc/src/hyper/pages/graphics.ht#L1224
 
 I'm rather in favour of either removing that Stand-alone Viewport
 section completely or use an already generated image in this place.

I am definitely against removing Stand-alone Viewport for such
a (non)reason.  Concerning using already generated image: I do
not like to keep generated files in svn, so I consider ability
to automatically generate mobius image to be important.  OTOH
currently we put generated image in release tarball and
create the image only from 'gphts' target.  I think this is
the right compromise.

 
 I'll also go over the src/hyper/pages/*.ht files. Many of them are now
 redundant.

I prefer to separate changes to build process and changes to
the content.  If there is no or very small change in content
then there is much easier to verify that build works OK
by diffing results with earlier versions.  Verifying content
changes is easier without noise caused by changes in build
process.

 What I cannot do is to generate the whole AXIOM book. That is for later
 if someone still wants a printed version. I think, transforming into
 HTML serves the community much better than a PDF file. So I will rather
 work on producing a web format of the documentation. But also that will
 not be ready for the next release.

I think it is worth looking at tex4ht.  I would rather avoid
tex4ht as a runtime dependency, but it could be useful for
generating .html version form .htex -- this could be done
when creating release tarball, so there would be no requirement
for tex4ht when building releases.

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] New release

[Ralf Hemmecke]

I've pushed a few more commits to my htexdoc branch.

5fd285c use ViewportPage1 instead of mobius
543677f transform \lispmemolink{X}{Y} to [X]
e4a7fe9 remove redundant .help files
9c102be remove unused .ht files
2eb8343 XVFB runs concurrently

 I am definitely against removing Stand-alone Viewport for such a
 (non)reason.

See commit 5fd285c.

The only problem now is that when I go to

Topics - Graphics - Old Framework - Viewports

and click on ViewButton in section Creating Viewport Buttons, the
console shows

(1) - viewAlone called with argc=2
viewAlone called with
argv[1]=/home/hemmecke/g/fricas-bisect/install/lib/fricas/target/x86_64-unknown-linux/bin/viewAlone
viewAlone called with
argv[2]=/home/hemmecke/g/fricas-bisect/install/lib/fricas/target/x86_64-unknown-linux/share/viewports/ViewportPage1
filename =
/home/hemmecke/g/fricas-bisect/install/lib/fricas/target/x86_64-unknown-linux/share/viewports/ViewportPage1.VIEW/data
viewType = 1
calling spoonView3D
viewAlone:
/home/hemmecke/g/fricas-bisect/fricas/src/graph/viewAlone/spoonComp.c:208:
makeView3DFromFileData: Assertion `fricas_sprintf_actual_size = 0 
fricas_sprintf_actual_size  fricas_sprintf_buffer_size' failed.

 I'll also go over the src/hyper/pages/*.ht files. Many of them are
 now redundant.

 I prefer to separate changes to build process and changes to the
 content.

Oh, I haven't made considerable changes to the content. Up to now it's
mainly fixing typos. I've backported your changes from the .ht files to
the .htex files. So the generated .ht files should basically be the same.

The real change would be to go over the two What's new sections.

Maybe the resulting files are not in the same directories, but filenames
should be the same.

 I think it is worth looking at tex4ht.

Yes and no. I've done aldor-combinat with tex4ht and know how it works,
but it's quite some work to make the pages look nice. I'm rather
thinking of pandoc. tex4ht would only be an intermediate solution. But I
would have to generate the .tex version first. However, the latter is
unrealistic until your release date.

 I would rather avoid tex4ht as a runtime dependency, but it could be
 useful for generating .html version form .htex -- this could be done 
 when creating release tarball, so there would be no requirement for
 tex4ht when building releases.

Are you insisting on HyperDoc? I'd rather be in favour of using pandoc
to make a one-time transformation from .htex (which is nearly .tex) into
.rst (restructured text). That is almost ASCII, so hopefully even
readable without webbrowser. From .rst it's easy to produce nicely
looking webpages via Sphinx.

My main usage of HyperDoc is the API browser. HyperDoc will still exist
for some more time, since I have not yet any idea to generate an API
documentation which even works on the fly as HyperDoc does now.

Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[fricas-devel] New release

[Waldek Hebisch]

I would like to do a new release in June.  ATM we have a few
open bugs -- they are mostly old problems that were recently
uncovered.  It would be nice to fix them.  Also second
part of Ei integration code (which should also handle
erf and incomplete gamma) is unfinished.  Still, I think
that we should not wait with release too long.  So,
I plan to include new code and fixes that can be done
in next few days, but then release what we have.
Tentatively, I would like to set cutoff at June 20.

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] New release

[someone]

   4.) Do we want to include the MatrixManipulation package into
   Fricas? I discovered that it's already part of Axiom.
  
   
  The package looks OK and is a worthy addition.  One remark: I would
  probably use 'rowMatrix' instead of 'aRow' and 'columnMatrix'
  instead of 'aColumn'.

Ok. I stayed as close as possible to the functions of the Matrix
domain where we have:

 row : (%,Integer) - Vector(R)
 column : (%,Integer) - Vector(R)

But I could not reuse these names because of name resolution.
I want row(...) to do the right thing w/o the need of
calling it like row(...)$MAMA(...).


 I will look at it.  My impression from your messages was that
 you want to work out some problems.

Right. Apart from the speed issues that I did not consider
to be very urgent there was at least one main point I'd like
to improve: the package constructor. This feels much to long
especially when one need to do package calling.

 MatrixManipulation(R: Field, Row: FiniteLinearAggregate(R), Col: 
FiniteLinearAggregate(R), M: MatrixCategory(R,Row,Col))

Actually, the current functions have only M as input/output type.
The R, Row, Col are solely used to define M. My attempt to build
something like:

 MatrixManipulation(M: MatrixCategory(R,Row,Col))

has failed so far. At some point I need to tell the details of M.
I'm not sure if it would even be possible to build:

 MatrixManipulation(M: MatrixLikeObjectThatAllowsExtractionOfSubrectangles)


 The package is now included in FriCAS.  I did the renames and
 modified a few functions to make them more efficient.

Thanks!

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] New release

[someone]

   I am planning new release.  It would be nice to release
   before Easter, but I would also like to looks at open
   bugs and fix some so beginning of April is more realistic.
  
  Some open questions or tasks for the new release:
  
  1.) What about these renamings:
- mrv_limit - mrvLimit or even limit (And many more inside
  the package)
- Pfaffian - pfaffian
  
  I sent to the list an (incomplete) Patch for these two some time
  ago.
 
 I do not want to change 'mrv_limit' to 'mrvLimit'.  In my
 experince it is easier to work with code if names are
 always spelled the same way. The 'mrvLimit' leads to varied
 spelling of 'limit': when alone it is 'limit' while in
 compounds it is 'Limit'.  For this reason I adopted
 'mrv_limit' convention for implementation names.

Ok. Thanks for explaining your view.

 I consider 'mrv_limit' as part of implementation of 'limit'.
 In the future 'mrv_limit' may replace current 'limit'
 and then we will probably change 'mrv_limit' to 'limit'.

I'm not sure if this is a good idea as mrv is powerful
but limited to a (although large) class of functions
where top-level limit could switch between several
algorithms covering different classes of functions.
(F.e. mrv can not really handle oscillatory expressions.)

 Concerning Pfaffian, I am not sure how much we want
 to enforce convention on exported names.  For example
 changing 'Gamma' to 'gamma' would be misleading and
 I would be stringly against such change.

Right, for some special functions we are never allowed
to change the name. Depending on the source [1], there is
a Si and a si which are different functions!

[1]: http://en.wikipedia.org/wiki/Trigonometric_integral

 Given that we will have exceptions anyway, when I noticed
 'Pfaffian' some time ago I decided that changing it
 is not worth the trouble.

Ok. Then let's forget about this.


  2.) Which fix do we use for the wrong values of Shi and Chi?
  I think you wanted to try another solution that what I suggested
  first. What is the state of this?
 
 AFAICS the wrong examples posted on the list are actually OK,
 that is difference between true and computed result is within
 error bounds (see my last message in the thread).  We should
 increase accuracy of those functions because for some other
 arguments error is slightly larger than promised.


Maybe one should interface to other libraries for numerics.
AFAIK Axiom can use GMP and related libraries for arbitrary
precision computations.

There is a really nice new library for ball arithmetics:

 http://fredrikj.net/arb/
 http://fredrikj.net/blog/

The most interesting point (beside being one of the fastest
libraries of its kind) is the rigorous error control.


  3.) What did we decide about the counting sorting algorithms I
  wrote?
  From my point of view they should be ready.
  
https://github.com/raoulb/fricas/tree/bubblesort
  
 
 As I wrote 'number of exchanges done by sort' is not
 well-defined and for this reason unlikely to be of
 wider use.  There is well-definded length function
 on permutation group which is somewhat similar to
 what you compute, but I would be surprised if
 your code computes length.

That can be and I'd be surprised too because I
did never consider this. The wideness of use
depends on how often one needs to compute the
sort + parity. I do not claim anything on this.

 So ATM, what you do looks at attempt to optimize
 cases when we need sort + parity of permutation.
 More precisely, it looks like premature optimization

I only need sort + parity, right. This is the best
and easiest way to compute that. At least I have
no better idea to come up with.

For the moment, I'll factor out the new code
into an own package. This way VectorAlgebra can
depend on it but it need not to be part of Fricas
and we could review this point later.

For VectorAlgebra any way to compute sort + parity
easily would be enough. (Maybe I should review the
proposals on wrapping around SortPackage.)


 Concerning merge sort: the default sort is merge
 sort, so we already have one implementation.

Sure, but not a counting one.


 BTW: AFAICS SortPackage is not used by any other part
 of algebra.  It is included because it is
 used as an example in chapter 11.7 of the Axiom
 book.

Well, this might be true but I think that Axiom
definitely should include generic sorting algorithms.
So SortPackage is a valid component in my view.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] New release

[Waldek Hebisch]

someone wrote:
 
   2.) Which fix do we use for the wrong values of Shi and Chi?
   I think you wanted to try another solution that what I suggested
   first. What is the state of this?
  
  AFAICS the wrong examples posted on the list are actually OK,
  that is difference between true and computed result is within
  error bounds (see my last message in the thread).  We should
  increase accuracy of those functions because for some other
  arguments error is slightly larger than promised.
 
 
 Maybe one should interface to other libraries for numerics.
 AFAIK Axiom can use GMP and related libraries for arbitrary
 precision computations.
 
 There is a really nice new library for ball arithmetics:
 
  http://fredrikj.net/arb/
  http://fredrikj.net/blog/
 
 The most interesting point (beside being one of the fastest
 libraries of its kind) is the rigorous error control.


Well, at first glance reusing work looks attractive.  However,
when I looked at existing codes I have found number of implemented
functions is limited (for example I do not know of any free code
outside of FriCAS implementing arbitrary precision Weierstrass
elliptic functions).  Some codes are numerically unstable
(elliptic functions in Reduce and at least older Maxima
elliptic functions).  There are restrictions on arguments:
I have found _no_ free implementation of incoplete Gamma function
for complex arguments.  Sometimes code only works for very
limited range of arguments.  So even _selecting_ functions to
link requires nontrivial work.  Then there is problem of
actual interfacing which typically requires data convertions,
and consequently limits performance at low precisions.

Once we have external parts complexity of the whole system
grows quite a lot: there are multiple languages and different
build systems.  Typically there is serious code bloat.
As a somewhat extreme example let me mention that few days
ago I built FriCAS on Gentoo.  I wanted to do this in
Gentoo way so I installed Gentoo 'noweb' package.
'noweb' is tiny, but it pulled more than 500 Mb of other
software.  So I prefer to be selective in what we link
to.  Basically we want establised standalone packages.
Currently we use GMP.  I plan to use BLAS and Lapack,
however ATM main blocker is limited availablity of
BLAS and Lapack and potential build problems when
they are not available as standard component.
Next thing probably would be fplll.

Concering rigorous precision, for Ci in Wikipedia notation
we have

Ci(x) = -Cin(x) + gamma + log(x)

we compute all term (including Cin(x)) with rigorous error
bounds.  But then there is cancellation between Cin and the
other terms.  So absolute precision is as expected, but
relative precision is worse.  ATM I do not know how much
effort spend on getting better precision.  In principle
we could detect cancellation and repeat computation at
higher precision.  But cancellation is a problem only
when Ci(x) is small (basically close to zeros).  If
we add such small number to someting else the precision
will be essentially wasted.

BTW, book Precise Numerical Methods by Aberth indicates
how to compute large class of functions with rigorous
error bound.  It would be not hard to implement such
method.  However, I have doubts about performance.  For
simple cases (and Ci almost surely is such a case)
performance at moderate precision will be OK.  But
I expect that in interesting case performance will
be so bad that they will be impossible to do in
reasonable time.  In other words getting rigorous
error bounds tends to be expensive, either in
computer time or in programmer time.  Interval
style arithmetic typically has significant overhead
maintaining error bounds and obtained bounds tends
to be pessimistic.  Conseqently, interval computation
usually are much slower than non-interval multiple
precision computations (which in turn are much slower
than machine floats).  AFAICS one way to speed up
interval computations is to have bigger blocks
with rigorous error estimates (inside block
computations would be done using non-interval
arithmetic).  Of course this requires effort.
FriCAS functions are step in such direction, for
functions that I implemented I did error analysis
and most functions should deliver results accurate
up to designed precision.  Of course there are bugs
(for example in earlier version of Gamma my error
estimates were too optimistic).  And there are
deliberate shotcuts (for example Beta and Ci).

 
  So ATM, what you do looks at attempt to optimize
  cases when we need sort + parity of permutation.
  More precisely, it looks like premature optimization
 
 I only need sort + parity, right. This is the best
 and easiest way to compute that. At least I have
 no better idea to come up with.

As I wrote parity is linear.  Good sorting algoritms
perform of order n*log(n) operations.  So it looks
better to compute parity separately then have
per operation overhead in sort.

More precisely, if you have permutation of integers

Re: [fricas-devel] New release

[Waldek Hebisch]

I wrote:
 
 someone wrote:
  
  4.) Do we want to include the MatrixManipulation package into Fricas?
  I discovered that it's already part of Axiom.
 
  
 The package looks OK and is a worthy addition.  One remark: I would
 probably use 'rowMatrix' instead of 'aRow' and 'columnMatrix' instead
 of 'aColumn'.

The package is now included in FriCAS.  I did the renames and
modified a few functions to make them more efficient.


-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] New release

[Waldek Hebisch]

I have now created release branch.
-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] New release

[someone]

 I am planning new release.  It would be nice to release
 before Easter, but I would also like to looks at open
 bugs and fix some so beginning of April is more realistic.

Some open questions or tasks for the new release:

1.) What about these renamings:
  - mrv_limit - mrvLimit or even limit (And many more inside the package)
  - Pfaffian - pfaffian

I sent to the list an (incomplete) Patch for these two some time ago.


2.) Which fix do we use for the wrong values of Shi and Chi?
I think you wanted to try another solution that what I suggested
first. What is the state of this?


3.) What did we decide about the counting sorting algorithms I wrote?
From my point of view they should be ready.

  https://github.com/raoulb/fricas/tree/bubblesort


4.) Do we want to include the MatrixManipulation package into Fricas?
I discovered that it's already part of Axiom.


The vector algebra code is clearly not ready yet.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[fricas-devel] New release

[Waldek Hebisch]

I am planning new release.  It would be nice to release
before Easter, but I would also like to looks at open
bugs and fix some so beginning of April is more realistic.

For the new release I think that we should should use
1.2.0 number.  Namely we have accumulated quite a lot
of additions in 1.1.x series so bumping middle number
is good for indicationg progress.  Second, compared
to 1.1.8 we have changes to parser and scanner which
seem to work quite well but may cause incompatibilities
so change of middle number is appropriate.


-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[fricas-devel] New release: known problems

[Ralf Hemmecke]

Maybe the INSTALL file should list under Known Problems.

  Aldor-FriCAS interface is not working.

Perhaps you even temporarily remove the --enable-aldor option from 
configure.ac.


Ralf

--
You received this message because you are subscribed to the Google Groups FriCAS - 
computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com.
To unsubscribe from this group, send email to 
fricas-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/fricas-devel?hl=en.

Re: [fricas-devel] New release: known problems

[Waldek Hebisch]

Ralf Hemmecke wrote:
 
 Maybe the INSTALL file should list under Known Problems.
 
Aldor-FriCAS interface is not working.
 
 Perhaps you even temporarily remove the --enable-aldor option from 
 configure.ac.


I would rather put the following in INSTALL.aldor:

Note: currently Aldor-FriCAS interface is not working.

I do not think we should remove --enable-aldor.

-- 
  Waldek Hebisch
hebi...@math.uni.wroc.pl 

-- 
You received this message because you are subscribed to the Google Groups 
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com.
To unsubscribe from this group, send email to 
fricas-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/fricas-devel?hl=en.

Re: [fricas-devel] New release: known problems

[Ralf Hemmecke]

I would rather put the following in INSTALL.aldor:

Note: currently Aldor-FriCAS interface is not working.

I do not think we should remove --enable-aldor


Fine with me. I just want to have it recorded that it's not working.

Ralf

--
You received this message because you are subscribed to the Google Groups FriCAS - 
computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com.
To unsubscribe from this group, send email to 
fricas-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/fricas-devel?hl=en.