Re: [fricas-devel] Re: New release

On Monday, 6 October 2014 03:00:03 UTC+2, Waldek Hebisch wrote: Right. I will commit the change. What name should I use in attribution line (email header just gives kfp, but we normally use full name)? For whatever reason the header showed the nickname - strangely enough, only for

Re: [fricas-devel] Re: New release

On Monday, 6 October 2014 04:29:54 UTC+2, Bill Page wrote: On 5 October 2014 20:59, Waldek Hebisch heb...@math.uni.wroc.pl javascript: wrote: kfp wrote: ... Finally, what's your opinion to the following matter? Extending DeRhamComplex with some functions like scalar product

Re: [fricas-devel] Re: New release

On Monday, 6 October 2014 04:29:54 UTC+2, Bill Page wrote: Bill, I have forgotten to mention that http://axiom-wiki.newsynthesis.org/ is down for several days. It's indispensable for a noob like me ;) Kurt -- You received this message because you are subscribed to the Google Groups

[fricas-devel] DeRhamComplex

domain. further comments between the lines ... On Monday, 6 October 2014 20:52:31 UTC+2, Bill Page wrote: On 5 October 2014 23:18, Kurt Pagani nil...@gmail.com javascript: wrote: On Monday, 6 October 2014 04:29:54 UTC+2, Bill Page wrote: On 5 October 2014 20:59, Waldek Hebisch

Re: [fricas-devel] DeRhamComplex

On Monday, 6 October 2014 23:57:34 UTC+2, Ralf Hemmecke wrote: On 10/06/2014 10:56 PM, Kurt Pagani wrote: I don't oppose to create a new domain, however, it would certainly be based on DERHAM as it contains 95% of the work necessary. I haven't looked too deeply into this subject

Re: [fricas-devel] DeRhamComplex

On Tuesday, 7 October 2014 05:36:26 UTC+2, Bill Page wrote: On 6 October 2014 21:59, Kurt Pagani nil...@gmail.com javascript: wrote: I opened a new thread for 'not to be off-topic'. didn't work, obviously :( Maybe someone can move this? Works for me. The subject is now: Re

Re: [fricas-devel] New release

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,

Re: [fricas-devel] Wiki

I'm going along with the foregoing post. I didn't know who maintains it, now I do. Thanks a lot. Kurt On Tuesday, 7 October 2014 16:54:14 UTC+2, Bill Page wrote: Thank you! Your efforts to keep the wiki available are greatly appreciated. On 7 October 2014 08:18, Waldek Hebisch

Re: [fricas-devel] DeRhamComplex

, Bill Page bill...@newsynthesis.org javascript: wrote: On 7 October 2014 12:13, Kurt Pagani nil...@gmail.com javascript: wrote: ... What I have in mind is first to complete this by functions like proj (projection on homogeneous parts, subspaces), push forward/pull back, interior

Re: [fricas-devel] DeRhamComplex

On Tuesday, 7 October 2014 19:15:32 UTC+2, Bill Page wrote: On 7 October 2014 12:13, Kurt Pagani nil...@gmail.com javascript: wrote: On Tuesday, 7 October 2014 05:36:26 UTC+2, Bill Page wrote: ... Your examples look good to me, except I would definitely prefer not to have

Re: [fricas-devel] DeRhamComplex

We need a mapping between manifolds, e.g. between the set of independent variables of one DFORM into the independent variables of another DFORM. My first thought is that maybe pullback and pushforward should be exports of a package that is parameterized by a list of expressions.

[fricas-devel] DeRhamComplex

Wouldn't that be easy? http://fricas.github.io/api/MonoidRing.html http://fricas.github.io/api/MonoidRing.html Maybe you'd have to implement k-chains as well with the help of http://fricas.github.io/api/FreeGroup.html http://fricas.github.io/api/FreeGroup.html It doesn't look too

Re: [fricas-devel] DeRhamComplex

On Sunday, 12 October 2014 20:32:50 UTC+2, Waldek Hebisch wrote: Kurt Pagani wrote: It was indeed not very difficult. A simplex can be represented most favourably as a matrix (rows = points of F) and FreeAbelianGroup will do the rest. I admit that I got lost in this thread

Re: [fricas-devel] DeRhamComplex

Meanwhile I have rather realized what you mean: citation: http://en.wikipedia.org/wiki/Abstract_simplicial_complex an *abstract simplicial complex* is a purely combinatorial description of the geometric notion of a simplicial complex http://en.wikipedia.org/wiki/Simplicial_complex, consisting

Re: [fricas-devel] New release

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

Re: [fricas-devel] log(exp(z))

Am 25.11.2014 um 20:05 schrieb Waldek Hebisch: Let me add that assumptions like exements of Expression(Integer) are real are in general unsound. Indeed. In case of log the assumption is frequently true and not making it would stop useful simplifications. However, I would rather move in

Re: [fricas-devel] real numbers

Am 26.11.2014 um 08:50 schrieb Ralf Hemmecke: On 11/26/2014 06:48 AM, Bill Page wrote: On 25 November 2014 at 16:29, Kurt Pagani nil...@gmail.com wrote: )abbrev domain RR Real ++ Description: The field of real numbers modelled as ++ domain Expression(Integer) + some extensions. Kurt

Re: [fricas-devel] real numbers

Am 26.11.2014 um 17:27 schrieb Bill Page: On 26 November 2014 at 02:50, Ralf Hemmecke r...@hemmecke.org wrote: ... Maybe, it's not new, but who would say that 2*\pi is real? Yes, of course. FriCAS already has a domain name Pi and a category named RealConstant with descendants of

Re: [fricas-devel] expression like domains

Am 01.12.2014 um 03:46 schrieb Waldek Hebisch: snip )abbrev domain RR Real ++ Description: The field of real numbers modelled as ++ domain Expression(Integer) + some extensions. Real : Exports == Implementation where snip Exports == FunctionSpace R with snip Implementation ==

Re: [fricas-devel] log(exp(z))

Sorry for being interfering, but I suppose there is some misunderstanding which also puzzles me by now. IMO both of you are right depending on the view. I believe that one point of confusion stems from the intepretation of x:T as x \in T (which I also find attractive by the way). However, FriCAS

Re: [fricas-devel] log(exp(z))

Am 06.12.2014 um 17:56 schrieb Bill Page: On 5 December 2014 at 23:16, Kurt Pagani nil...@gmail.com wrote: Sorry for being interfering, You are not interfering, you are participating. Thank you. but I suppose there is some misunderstanding which also puzzles me by now. IMO both of you

Re: [fricas-devel] documentation standards

I can't help commenting on these delicate matters: * The removal of Ralf's comments without discussion was certainly not the refined British attitude, however, it would be preposterous if it were the origin of a serious quarrel. One should talk this over and eventually it might be possible to

[fricas-devel] Re: New TexFormat

There are still some slips in TeXmacs and LaTeX output. See attachement (tm, tex and raw input in this order). 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

Re: [fricas-devel] CodeMirror editor .input file and SPAD mode highlighting.

interface to FricAS/Axiom at all ;) Unfortunately I'm involved in various projects which consume most of my time such that I had to pause doing FriCAS related stuff, however, this might change soon. Keep it up, it's worth it. Best regards Kurt Pagani Am 08.06.2015 um 00:49 schrieb Bill Page

Re: [fricas-devel] Linking (lisp) libraries to FriCAS?

That's very "ok" :) Unfortunately I have little time to contribute to this topic, but you know much more about these things anyway. I also had a glance over the FFI of OpenAxiom which Alfredo Portes posted recently here. Looks quite interesting but here too, I have to avoid frittering ;) I'll

Re: [fricas-devel] Linking (lisp) libraries to FriCAS?

Hello Bill, that's great. There is a lot in Lisp which is a "black spot" to me, especially this "multiple value" stuff. Since this also seems to be solved I think this could be a starting point. Thank you and best regards Kurt Am 26.10.2015 um 05:14 schrieb Bill Page: > Alasdair and Kurt, >

Re: [fricas-devel] Linking (lisp) libraries to FriCAS?

13 schrieb Alasdair McAndrew: > Just as an experiment I'm taking the quadpack.lisp file from the Maxima > distribution, to see if I can install it and have it working under FriCAS. > However, as a total Lisp newbie, I'm continuously stumped by trivial > errors. For example, quadpack.l

Re: [fricas-devel] Linking (lisp) libraries to FriCAS?

Hello Alasdair What I have completely forgotten to mention in the last post: In the fricas/contrib folder there is a file load-fricas.lisp which allows you to use FriCAS as a cl library itself. This way you can mix in any kind of library as long there is no interference to the "boot" package

Re: [fricas-devel] Linking (lisp) libraries to FriCAS?

LOL, Alisdair was right: cui honorem, honorem My humble contribution is common lore ... the back-breaking work lies before you :) Am 30.10.2015 um 02:02 schrieb Bill Page: > On 29 October 2015 at 18:56, Alasdair McAndrew wrote: >> >> A quick note: gsl.lisp and gsl.spad were

Re: [fricas-devel] New blog post about (Pan)Axiom

Very nice! IMHO you just hit the mark and I'm believing the foundation of "Scratchpad" is still outstanding, not only but also particularly with regard to the type system. As you already remarked it will take some time to get used to it, however, it certainly is worthwile. Kurt Am 05.11.2015 um

Re: [fricas-devel] When the iSPAD kernel in Jupyter freezes

- I'll try that. I've had a few occasions just now when I've > tried to abort a computation - which I can do - and I simply can't get the > kernel started again. > > -Alasdair > > On Friday, October 16, 2015 at 1:20:59 AM UTC+11, Kurt Pagani wrote: >> >> >>

Re: [fricas-devel] FriCAS in TeXmacs doesn't start HyperDoc, and

It seems that you have an outdated 0MQ version (<= 3.2). >> The zmq_ctx_new() function creates a new ØMQ context. >> This function replaces the deprecated function zmq_init(3). The kernel is independent of Python, however, the latest version requires Jupyter 4.x, i.e. one has to start the

Re: [fricas-devel] FriCAS in TeXmacs doesn't start HyperDoc, and

t stuff I've seen for a long time - and in > many ways provides the sort of (Axiom)FriCAS interface which I think could > greatly increase its popularity. > > Many thanks for your hard work! > > > > On Sun, Oct 11, 2015 at 10:38 AM, Kurt Pagani <nil...@gmail.com> wrote: &

Re: [fricas-devel] FriCAS in TeXmacs doesn't start HyperDoc, and

Jupyter development seems to be quite turbulent at the moment: from http://ipython.org/: > IPython is a growing project, with increasingly language-agnostic > components. IPython 3.x was the last monolithic release of IPython, > containing the notebook server, qtconsole, etc. As of IPython 4.0,

Re: [fricas-devel] FriCAS in TeXmacs doesn't start HyperDoc, and

what needs to be done... > > On Sun, Oct 11, 2015 at 9:26 AM, Kurt Pagani <nil...@gmail.com> wrote: > >> >> Jupyter development seems to be quite turbulent at the moment: >> >> >> from http://ipython.org/: >>> IPython is a growing project, with increa

Re: [fricas-devel] FriCAS in TeXmacs doesn't start HyperDoc, and

Bill, Am 11.10.2015 um 04:20 schrieb Bill Page: > On 10 October 2015 at 21:14, Kurt Pagani <nil...@gmail.com> wrote: >> ... >> At the moment the installation procedure is quite handy to develop but >> not yet robust enough for deployment which certainly would be no

Re: Fwd: Re: [fricas-devel] FriCAS in TeXmacs doesn't start HyperDoc, and

Hi Ralf, Am 11.10.2015 um 12:16 schrieb Ralf Hemmecke: > Hi Kurt, > >> At the moment the installation procedure is quite handy to develop but >> not yet robust enough for deployment which certainly would be not >> essential for SMC (you might oppose). But most unpleasant seems to me >> the long

Re: Fwd: Re: [fricas-devel] FriCAS in TeXmacs doesn't start HyperDoc, and

Am 11.10.2015 um 18:59 schrieb Bill Page: > On 11 October 2015 at 12:47, Kurt Pagani <nil...@gmail.com> wrote: >> >> Hi Ralf, >> >> Am 11.10.2015 um 12:16 schrieb Ralf Hemmecke: >> ... >>> Graphics is not my main concern at the moment.

Re: Fwd: Re: [fricas-devel] FriCAS in TeXmacs doesn't start HyperDoc, and

Have a look at the end of http://kfp.bitbucket.org/tmp/version-0-9-2.html : there the pop-up window is capapble of displaying one of the supported mime types (html, md, ...) At the moment it only displays the text of ")d op cmd", at least one can expand it by clicking on the "+". The API would

Re: Fwd: Re: [fricas-devel] FriCAS in TeXmacs doesn't start HyperDoc, and

Am 13.10.2015 um 02:29 schrieb Waldek Hebisch: ... >> then it might be easier to drop an anchor there. I'll try to locate the >> "emission", however, if you already know the location, please let me know. > > Actual sending is done via routines named 'sendI', etc. This is > done in view2D.spad

Re: Fwd: Re: [fricas-devel] FriCAS in TeXmacs doesn't start HyperDoc, and

> (not until March next year now), of putting up final year capstone projects > for our computing students. If you have any FriCAS projects, which are > computing based rather than mathematics based, let me know! > > -Alasdair > > On Tuesday, 13 October 2015 11:29:56 UTC+11,

Re: Fwd: Re: [fricas-devel] FriCAS in TeXmacs doesn't start HyperDoc, and

Am 12.10.2015 um 01:12 schrieb Waldek Hebisch: >> FriCAS/Axiom graphics requires an X server and that would be very >> awkward to include in a Jupyter kernel. > > Actually in principle graphics routines could be easily > retargeted. Namely, there is a set of primitive operations > which need

Re: [fricas-devel] Jupyter worksheets from FriCAS input files

ut?force=True > > It seems that the function definition > > dual2 a == > coefficient(a,[2,3])$Ext * i + _ > coefficient(a,[3,1])$Ext * j + _ > coefficient(a,[1,2])$Ext * k > > is not converted properly. > > Regards, > Bill Page. > > > > > >

Re: [fricas-devel] http://axiom-wiki.newsynthesis.org/ down

Once again ;) Am 16.09.2015 um 00:20 schrieb Dima Pasechnik: > Any chance this gets fixed? > Thanks, > 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

Re: [fricas-devel] Introduction to FriCAS/Axiom

Very nice! A link to Ralf's http://fricas.github.io/ in the "Online help" section seems indispensable to me (especially the API). Regarding Jupyter I've just started writing some documentation - that is documenting the features which are special in connection with FriCAS. May take some weeks ;)

Re: [fricas-devel] Windows - Building FriCAS 1.2.7 tarball on MinGW/MSYS/SBCL

Hi Grégory That's really good news. This means we might use FriCAS/Jupyter on Windows natively. There is mingw-64 (http://mingw-w64.org/doku.php) and SBCL x86-64, so a 64-bit version should be within reach, shouldn't it? Moreover it could even be possilbe to build a binary installer (e.g. using

Re: [fricas-devel] Windows - Building FriCAS 1.2.7 tarball on MinGW/MSYS/SBCL

t for Fricas at some point too). > > http://axiom-wiki.newsynthesis.org/images/WindowsInstaller.pdf > > Glad to see Gregory got it to build, it would be nice to create an updated > version. > > > On Fri, Dec 18, 2015 at 12:00 PM, Kurt Pagani <nil...@gmail.com> wrote: >

Re: [fricas-devel] Windows - Building FriCAS 1.2.7 tarball on MinGW/MSYS/SBCL

Am 18.12.2015 um 23:09 schrieb Grégory Vanuxem: > Hello, > > Frankly I do not know. Building FriCAS in a 64 bits environment is far from > me. From my point of view more work must be done. Maybe, but anyway it's not really a must ;) > > But I'll be happy if we can use FriCAS under Windows. In

[fricas-devel] Re: FriCAS under Jupyter on SMC

Am 24.11.2015 um 22:32 schrieb Bill Page: > Kurt, > > Sorry it has taken me some time to reply. I think what you have done > so far is great and I would like to get even this "pre-release" > version installed globally on SMC as soon as possible. No hurry for it. For a global install we need

Re: [fricas-devel] Running on a server?

e. don't use a binary version of FriCAS ;) Good luck Kurt > > cheers, > Alasdair > > On Wed, Nov 25, 2015 at 6:23 AM, Kurt Pagani <nil...@gmail.com> wrote: > >> >> Hi Alasdair, >> >> at the moment there are four possibilities to run fricas w/jupy

Re: [fricas-devel] Re: FriCAS under Jupyter on SMC

Bill, >> There >> is another graphics library (http://jsxgraph.uni-bayreuth.de/wp/) which >> looks quite interesting to me. It's pure JavaScript, therefore it could >> be generated from inside (spad or lisp) and would be independent from >> external tools. >> > > jsxgraph looks very promising!

Re: [fricas-devel] Running on a server?

Hi Alasdair, at the moment there are four possibilities to run fricas w/jupyter : 1. Docker: https://hub.docker.com/r/nilqed/ispad/ secure version, but quite old (2 month) 2. Docker: https://hub.docker.com/r/nilqed/fricas_jupyter/ no ssl, but current version (automated build) 3.

Re: [fricas-devel] Combinatorics in PanAxiom

Nice! Some of the functionality is already there, try for example: S5:=symmetricGroup([1,2,3,4,5]) -- or simply symmetricGroup(5) orbit(S5,[1,2,3,4,5]) [sign( coercePreimagesImages([[1,2,3,4,5],x])) for x in orbl] The nomenclature is indeed not very intuitional ;) Kurt Am 21.11.2015 um

Re: [fricas-devel] error from normalize, bug in ataneval efstruc.spad

Sorry, I forgot to include a link to the sources. You'll find it in the subfolders "doc" and "spad/{derham,dform}" of https://github.com/nilqed/fricas_input I haven't had the time yet to separate the stuff, so - unfortunately - one probably has to clone the whole repo (no claims btw). Am

Re: [fricas-devel] Re: bug fixes, improvements and documents for efstruc.spad

Am 01.06.2016 um 02:55 schrieb oldk1331: ... > https://github.com/fricas/fricas/commit/1676a69e1de7c17fb2b40fe0a1a124e6daf85923.patch > > This is the patch I want a discussion. Clearly, the > document of symFunc is a seriously mismatch with > its behaviour. In the patch I modified the

Re: [fricas-devel] SmithNormalForm

gt; > Martin B > > On 31/05/16 23:24, Waldek Hebisch wrote: >> Kurt Pagani wrote: >>> >>> (11) -> completeSmith(A)$SMNF >>> >>> (11) >>> +2 0 0 ++ 100 + +1 - >>> 2 - 2+ >>>

Re: [fricas-devel] Re: bug fixes, improvements and documents for efstruc.spad

Am 01.06.2016 um 04:56 schrieb oldk1331: > Yes, you are right, I've fixed symFunc to match its description. > > The next problem is to fix TANEXP accordingly, which I'll do > later. But now is the problem of document it: > > Take tanPIa for example, tanPIa returns a FRAC SUPR, > which has this

Re: [fricas-devel] SmithNormalForm

Hallo Martin I'm not aware of any examples/tutorials of http://fricas.github.io/api/SmithNormalForm.html, but it looks pretty straightforward. See e.g. here for a GAP impl: http://ljk.imag.fr/membres/Jean-Guillaume.Dumas/Publications/DHSW.pdf Of course, it were nice if you'd consider to share

Re: [fricas-devel] Drawing two plots together in jupyter/fricas?

Hello Alasdair Am 18.06.2016 um 11:09 schrieb Alasdair McAndrew: > So, I've got FriCAS running in jupyter (thanks Kurt - superb work!), and > I've compiled jupyter.spad to have the draw functions available. > Incidentally, why does this need to be done? Well, jupyter_fricas still is a

Re: [fricas-devel] Running fricas in jupyter: many errors

Hi Alasdair See: https://groups.google.com/forum/#!topic/fricas-devel/ltrhAkzrIYs There was a design change in 0MQ, i.e jupy versions > 4.0 won't work without a new pzmq. The steps below provide a temporary fix. Kurt == ... Therefore, if you want to fix it yourself, the following steps

Re: [fricas-devel] Jupyter worksheets from FriCAS input files

Hello Bill > When can we look forward to an update? :) This one (https://hub.docker.com/r/nilqed/ifricas/) is really outdated, I even suppose it's the old wrapper kernel written in Python. The current docker image corresponding to https://github.com/nilqed/fricas_jupyter is:

Re: [fricas-devel] Jupyter worksheets from FriCAS input files

Hello Bill Am 16.01.2016 um 15:32 schrieb Bill Page: > The following docker FAQ: > > > https://docs.docker.com/engine/misc/faq/#why-do-i-get-connection-reset-by-peer-when-making-a-request-to-a-service-running-in-a-container > > Suggests this is a common problem. Here is the solution: >

Re: [fricas-devel] Re: Introduction to FriCAS/Axiom

There is a nice MT on the subject: https://www.nada.kth.se/utbildning/grukth/exjobb/rapportlistor/2009/rapporter09/terelius_bjorn_09095.pdf and see this paper for current devlopments: http://arxiv.org/pdf/1305.1481.pdf BTW: numerics is to symbolics as classes are to instances ;) Kurt Am

Re: [fricas-devel] Jupyter worksheets from FriCAS input files

Am 18.01.2016 um 18:41 schrieb Bill Page: > As I understanding it, docker assigns ip addresses to containers in > the range 172.17.0.x with the host having address 172.17.0.1. These > are used to set up the port mappings, e.g. 443:. localhost in the > container is (usually) assigned

Re: [fricas-devel] Axiom wiki is back

Great, thank you! I really missed it. Kurt Am 09.02.2016 um 19:51 schrieb Waldek Hebisch: > Axiom wiki is back online. There was a disk crash, > Now disks are replaced and system restored. > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer

Re: [fricas-devel] Jupyter worksheets from FriCAS input files

Am 19.01.2016 um 19:53 schrieb Bill Page: > Oops, I just realized that OpenAxiom is in fact already on SMC. :) > > Version: OpenAxiom 1.5.0-2013-06-21 > Built on Sunday February 1, 2015 at 23:02:52 > > And the original Axiom is still there: > > Version: Axiom (August 2014) >

Re: [fricas-devel] Jupyter worksheets from FriCAS input files

Am 19.01.2016 um 18:51 schrieb Bill Page: > Actually it seems pretty clear but unfortunately ip is mentioned but > not explained anywhere in this article. I'm frequently using the excellent docker cheat sheet: https://github.com/wsargent/docker-cheat-sheet See section 'Network and

Re: [fricas-devel] Jupyter worksheets from FriCAS input files

Am 19.01.2016 um 19:31 schrieb Bill Page: > Kurt, > > Although this is the FriCAS email list, I have another question: To > what extent is this Jupyter kernel independent of FriCAS? For > example, how difficult would it be to set it up for OpenAxiom or the > original Axiom project? > In

Re: [fricas-devel] heap exhausted

Hi Ralf I'm frequently confronted with this SBCL specific error ... usually it's my bad - some recursion mistakes or bad design, so that increasing of "dynamic-space-size" isn't a remedy. However, I had cases where it worked indeed. You might edit the install.sh of fricas_jupyter where the core

[fricas-devel] Re: heap exhausted

Today I've tried to compile Fricas from SVN Rev. 1981 (first with --enable-aldor then wihout) whereby running into the "Heap exhausted, game over." error. Apparently I'm not the only one, e.g. https://bugs.launchpad.net/sbcl/+bug/1532253 Strange enough, I've succeeded to do the same with SBCL

Re: [fricas-devel] Re: heap exhausted

um 22:34 schrieb Andrey G. Grozin: > On Sun, 13 Mar 2016, Kurt Pagani wrote: >> Today I've tried to compile Fricas from SVN Rev. 1981 (first with >> --enable-aldor then wihout) whereby running into the "Heap >> exhausted, game over." error. Apparently I'm not t

Re: [fricas-devel] Additive Abelian Groups

Ralf, > Waldek is about to remove FreeAbelianGroup. I hope you meant FreeAbelianMonoid ? -- 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

Re: [fricas-devel] Additive Abelian Groups

[subscript(s,[j::OF]) for j in lo(r)..hi(r)]) add B:=OrderedVariableList [subscript(s,[j::OF]) for j in lo(r)..hi(r)] L:List(B):= enumerate()$B n:NNI:=#L Rep := FreeModule(R,B) Am 15.03.2016 um 16:37 schrieb Ralf Hemmecke: > On 03/15/2016 04:28 PM, Kurt Pagani wrote: >>>

Re: [fricas-devel] suppress input and output

I had the same question once ... the best I could achieve was myRead(s:String):Void == systemCommand "set output algebra off" systemCommand "set message type off" systemCommand "set message interponly off" -- more ... systemCommand concat["read ",s," )quiet"] systemCommand "set

Re: [fricas-devel] suppress input and output

est.input") Am 09.03.2016 um 07:38 schrieb Ralf Hemmecke: > On 03/09/2016 02:51 AM, Kurt Pagani wrote: >> systemCommand concat["read ",s," )quiet"] > > Ah... there is an option )quiet. I never thought of that. > Unfortunately, it still prints the inp

Re: [fricas-devel] PATCH : Windows - Building FriCAS 1.2.7 tarball on MinGW/MSYS/SBCL

Thanks to Grégory's patch compiling a native Windows version is as simple as usual, great :) It's surprisingly fast (sometimes *ten* times faster than the Cygwin version!), what caused me to create an installer (just in case there are other creatures (sometimes) working on Windows):

Re: [fricas-devel] DeRhamComplex

Hello Waldek I'd like to suggest a slightly modified version of DeRhamComplex for the following reasons: A) in the current version we cannot use non-atomic symbols: (1) -> X:=DERHAM(INT,[x[i] for i in 1..4]) (1) DeRhamComplex(Integer,[x[1],x[2],x[3],x[4]])

Re: [fricas-devel] New code

My attitude to this topic is ambivalent for the following reasons: 1) There is a great book "Combinatorial Algebraic Topology" by Dmitry Kozlov (http://www.informatik.uni-bremen.de/~dfk/) which gives a comprehensive and concise introduction of the theory Waldek has in mind: """ citation from the

Re: [fricas-devel] DeRhamComplex

Am 06.04.2016 um 00:21 schrieb Waldek Hebisch: > Kurt Pagani wrote: >> >> I'd like to suggest a slightly modified version of DeRhamComplex for the >> following reasons: >> >> A) in the current version we cannot use non-atomic symbols: >> >> (1) ->

[fricas-devel] Troubles with Complex ...

I have some problems with "Complex" (writing a DFT package and checking for "principal n-th root of unity"). To be short, the main problem seems to me that for positive integers n (especially odd ones, n=3 works, n=5 not) the expression exp(2*i*pi/n)^n is not recognized as "1", neither for

Re: [fricas-devel] Troubles with Complex ...

ot really a problem but I think that an unwarped user (used to purely symbolic systems for instance) might be surprised by these results. Kurt Am 04.03.2016 um 13:35 schrieb Waldek Hebisch: > Kurt Pagani wrote: >> >> I have some problems with "Complex" (writing a DFT package a

Re: [fricas-devel] Additive Abelian Groups

Am 27.03.2016 um 21:04 schrieb Waldek Hebisch: > > I will not rush removal of FreeAbelianGroup. AFAICS > FreeModule and IndexedDirectProductObject should be improved > to serve as replacement for FreeAbelianGroup. Also, > Comparable should propagate to more domains to > allow efficient

Re: [fricas-devel] Additive Abelian Groups

Hallo Martin I've been glancing over your code @github...algebraictopology.spad and I'm quite impressed how elaborate it is. Although I didn't perform any calculations yet, I can see that one can already solve some simple problems. I'm using an embedding of Kenzo at the moment --

Re: [fricas-devel] jupyter notebook

Hallo Ralf You have to use "jupyter notebook" to start the kernel. The executable "iSPAD" needs the kernel name as an argument (that's why the "NIL" error) and is not supposed to be called directly (unless you want to connect to an existing kernel). Best regards Kurt Am 11.05.2016 um 15:51

Re: [fricas-devel] jupyter notebook

oublemaker ... i have to start from scratch in a clean environment. Thank you Kurt Am 12.05.2016 um 00:45 schrieb Ralf Hemmecke: > On 05/11/2016 10:59 PM, Kurt Pagani wrote: >> Another point that's puzzling me is that you have an old kernel spec >> called "ispad" (the de

Re: [fricas-devel] jupyter notebook

Hello Ralf This time it wasn't SBCL to blame. Reverting to SBCL 1.2.6 showed the same behaviour. I could get the kernel working again by $ sudo pip uninstall jupyter-client $ sudo pip install jupyter-client==4.0 The errors apparently come from jupyter-client 4.2 (4.1 doesn't work as well). I

Re: [fricas-devel] jupyter notebook

Am 13.05.2016 um 08:02 schrieb Ralf Hemmecke: >>> It's a pity that with Xenial the installation becomes too >>> complicated. I've set up a docker image from ubuntu:xenial and installed everything from scratch (https://github.com/nilqed/fricas_docker/blob/master/Dockerfile:latest). After having

Re: [fricas-devel] jupyter notebook

> That's OK, but only holds for system administrators not for developers. > Otherwise we would still be sitting on trees and eat bananas. ;-) there are worse things :] > >> Sorry for the inconv-s Kurt > > Not your fault. Still, it would be good if I could test that iSPAD > behaves like AXIOMsys

Re: [fricas-devel] jupyter notebook

Am 12.05.2016 um 22:19 schrieb Ralf Hemmecke: > I must be doing something completely wrong. Now I am at the stage that > strting a fricas session in the notebook leads to (see below). Not at all. I suggest to exec ./install.sh in fricas_jupyter again (will build a new image). Also, deleting the

Re: [fricas-devel] jupyter notebook

Another point that's puzzling me is that you have an old kernel spec called "ispad" (the devel version form bitbuckt). Perhaps you should remove it ( /home/hemmecke/.local/share/jupyter/kernels/ispad) as it might interfere with "ifricas" which is the one that you installed. Also note that the

Re: [fricas-devel] compilation of fricas fails in ubuntu 16.04

Hi Ralf SBCL 1.3.0 is the last version that compiles FriCAS (Linux and Windows). Regarding newer versions, I tried it all up to 1.3.5 and it's just as Andrey reported. I'm also using Xenial: apt removing and installing 1.3.0 manually did it.

Re: [fricas-devel] compilation of fricas fails in ubuntu 16.04

http://permalink.gmane.org/gmane.lisp.steel-bank.general/4197 Maybe the issue is connected with (??): * enhancement: SB-EXT:DYNAMIC-SPACE-SIZE is now defined for cheneygc. Perhaps somebody is able to recognize what else could cause this behavior from the change notes below? changes in

Re: [fricas-devel] System error

That's really strange. Usually it is a simple error causing the message - although there is already sucb a mystery in this forum: https://groups.google.com/forum/#!topic/fricas-devel/JtQRoVaBlPc Did you edit .axiom.input recently? Anyway, we need more information ;) As Waldek suggested in the

Re: [fricas-devel] System error

Hallo Martin Am 15.04.2016 um 19:27 schrieb Martin Baker: >> Did you edit .axiom.input recently? > > Not aware of doing anything to this file, in fact I can't find it, where > should it be? > I believe this still is the standard file to personalize your FriCAS environment. E.g. mine looks

Re: [fricas-devel] Re: call for a new bug tracker

Am 16.07.2016 um 16:44 schrieb Martin Baker: > On 16/07/16 10:32, oldk1331 wrote: >> As I said before, I am neutral to svn=>git transit for now. >> >> Currently, I need an easy-to-use bug tracker, at least to track my > unmerged >> patches. >> >> So, to make an example, I'm using >

Re: [fricas-devel] validation of homology and homotopy code

Hello Martin You're certainly on track, however, as a believer in the KISS principle I'd say there is room for improvement. Since I'm mostly interested in homology I've not thoroughly tested the 'fundamentalGroup', yet some questions related to homotopy: * On

Re: [fricas-devel] validation of homology and homotopy code

Hello Martin Really amazing! I'll pull your code tomorrow (it's quite comprehensive on first sight) to do some tests. In an instant I'd suggest to compare with GAP or you'll find a lot of examples using the links below: *

[fricas-devel] Re: Todd-Coxeter

> Current (trunk with small improvenents): > > m11 w 182.19 using 14830 cosets > > HLT style: > > m11 w 0.12 sec using 47966 cosets > Amazing ;) The stakes are high now. I've tried the Men(n) function (Mennicke) from the Intro: )co permgrps )co gpresent )set mess time on -- Mennicke

Re: [fricas-devel] [PATCH] add coerce from PermutationGroup to GroupPresentation

Hi Martin Running the risk to give false alarm again, I can't compile gpresent.spad after your merge with trunk. Neither after removing the surplus paren on line 1467 : + relatorTables(state,rs)) On Tuesday, 31 January 2017 20:41:20 UTC+1, Kurt Pagani wrote: > > I pulled (fresh clone

Re: [fricas-devel] [BUG?] auto-simplification of atan

It's not easy to grasp when looking at the sequence below. I've tried to trace "atan" in the code but there are really weird ramifications. (2) -> atan((x^2*((-1)*x^4+1)^(1/2)+(x^3+x))/(((-1)*x^4+1)^(1/2)+((-1)*x^3+x))) ++ 2 | 4 3

  1   2   3   4   >