[fricas-devel] Aldor interface

on fricas-devel instead of being >> private? > > Probably. We are now discussing specific patches so it would be > better to do this in public. > > ---- Forwarded Message Subject: Re: Aldor interface Date: Wed, 18 Jul 2018 07:05:57 +0100 From:

Re: [fricas-devel] interoperability with sage again

> Should I prepare a pull request or a simple patch, Waldek is not in control of fricas.github.com, so only I will get notified by a pull request there. Thus, it's better to send a patch to the list or upload your stuff to github and send a URL of your patch (ending in ".patch") to fricas-devel.

[fricas-devel] fricas-commit

Hmmm... strange, fricas-com...@googlegroups.com seems to be unreliable. The latest commit-message there is r2494 although we are currently at r2496. But also the sourceforge mails seem to be unreliable. The latest I got was r2495 from FriCAS SVN repository Is sourceforge again having

Re: [fricas-devel] [BUG]: draw option unit == [a,b] ignored

> you must make sure that in the control panel you have "units on" and you > possibly have to scale the size of the window in order to have space for > tick labelling. Yes. No problem. Maybe I should add vp := draw(sin(11*x),x = 0..2*%pi,title == "Large and unit", unit==[0.2,0.2])

Re: [fricas-devel] [BUG]: draw option unit == [a,b] ignored

> IIC the user guide the draw option unit==[0.2,0.2] should add ticks to > the axes x and y, but I cannot see anything. > > Try eg: > > draw(sin(11*x),x = 0..2*%pi,toScale == true,title == "Drawn to scale") > draw(sin(11*x),x = 0..2*%pi,toScale == true,title == "Drawn to scale and > unit",

Re: [fricas-devel] Fricas on SPAD vs Fricas on Aldor?

On 07/10/2018 06:35 PM, Waldek Hebisch wrote: > Just a comment: current Spad compiler essentially imports every > domain that is sees: types of function arguments, type of value, > etc. This is creasy, because set of visible functions depends > on exact computation path taken in the compiler --

Re: [fricas-devel] FricasUG metapatch: palindromes and eirule

> -- > https://github.com/fricas/fricas/blob/master/src/doc/htex/ug06.htex#L2410 > REPLACE: > (s.i = s.j) and palAux?(s,i+1,i-1) > BY: > (s.i = s.j) and palAux?(s,i+1,j-1) > MOTIVATION: > IIUC, presently the function palAux? declare palindromes aggregates > having equal

Re: [fricas-devel] FricasUG metapatch: 7 and )set functions cache all all

> -- > https://github.com/fricas/fricas/blob/master/src/doc/htex/ug06.htex#L894 > REPLACE: > What is the value for \spad{n = 7}? > BY: > What is the value for \spad{n = 3}? > MOTIVATION: > The line below contains facto(3) Thanks. But

Re: [fricas-devel] interoperability with sage again

>> Wouldn't it be wiser to add functions to Expression in order to >> decompose an element. > > No, not in the case of the Sage interface to FriCAS. Can you give a reason why? A function that would enable to go step by step through an expression tree in FriCAS wouln't be such a bad idea even

Re: [fricas-devel] interoperability with sage again

Hi Martin, > (52) -> f := guess([reduce(*, [reduce(+, [1/k for k in 1..m], 0) for m in > 1..n], 1) for n in 0..10]).1 > > p - 1 > n - 111 > ++-++ --+ 1 >(52) | | > --- + 1 > | | --+s + 2 > p =

Re: [fricas-devel] addition of ExtendedPolynomialReduction

Now thinking about the "reductum(0)=0" assumption. I can easily remove it from my code (see below). tailReduce(x: X, basis: List X): X == empty? basis => x p: R := polynomial x -- We iterate over the non-leading terms of polynomial(x). r: R := 0 v: V :=

Re: [fricas-devel] addition of ExtendedPolynomialReduction

>> https://github.com/hemmecke/fricas/commit/1ea2f36f0a2bf8dd251cbb0fb6ab810b734d2c88.patch >> > > Looks good. However, comment: > > -- Reduce the non-leading terms of x (which is assumed to be non-zero). > > > looks

[fricas-devel] addition of ExtendedPolynomialReduction

Hello, I'm currently preparing an article that involves Gröbner basis computation and then finding the representation of some polynomial in terms of that Gröbner basis. Doing this in FriCAS, is, of course, easy, but I was unable to find that such an extended reduction is already implemented in

Re: [fricas-devel] Unexpected behavior of commas in singleton blocks {expression}

> weird feature... I have no idea how to explain this behaviour, but it is great that you report such "funny" functionality. I hope, some day, they all will be replaced by a clear (and simple) semantics. Ralf -- You received this message because you are subscribed to the Google Groups

[fricas-devel] Fricas init file

FriCAS init file At start-up, FriCAS can read an init file according to the following rules. First match counts. #. An environment variable ``FRICAS_INIT`` exists. #. If ``FriCAS_INIT`` is empty, then no init file is read. #. Otherwise, the content of ``FRICAS_INIT`` is

Re: [fricas-devel] Exposing formatters

On 06/11/2018 03:34 PM, Waldek Hebisch wrote: > I think that we should not expose MathMLFormat, ScriptFormulaFormat, > TexFormat and TexmacsFormat. AFAICS TexFormat1 has to be > exposed to fulfil its role, so probably should be exposed. Although my version of TexFormat can be used to adapt the

Re: [fricas-devel] [PATCH] misc cleanups

> ATM "func"/[args] notation has one big advantage: it does not create > an intermediate list. So it is more efficient than 'reduce(func, args)' > variant. Supporting it in compiler in a sense is almost trivial: > most of code is present anyway to support '[i for i in l]' construct. The syntax

Re: [fricas-devel] How to enter in multi-line mode?

> As far as I know only in input file with correct indentation. I also thought that this would work, but I remember that I had problems. So the usual way is, to put things in an .input file in the following way: foo(n) == (_ k := 0; _ for i in 1..n repeat (_ for j in 1..n repeat (_

Re: [fricas-devel] Factors of multivariate monomials with noncommutative variables

>> https://arxiv.org/abs/1706.01806 Oho... That paper cites FriCAS directly (obviously for computing a Gröbner basis). 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

Re: [fricas-devel] Easier way to write noncommutative polynomials, like in REDUCE

On 05/28/2018 08:53 AM, Marduk wrote: > Dear all, > > As the following example shows, when writing polynomials with noncommutative > variables one has to specify that the symbols belong to the list of NC > variables: > > ops := OVAR[A,B] > > ncomm := XDPOLY(ops, Integer) > > q : ncomm :=

Re: [fricas-devel] how to remove "failed"?

(5) -> remove(f, li10)$List(Union(IntegerMod(10),"failed")) (5) [1, 7, 3, 9] Type: List(Union(IntegerMod(10),"failed")) Obviously the interpreter is unable to automatically realise that it should also look inside the exports of

Re: [fricas-devel] Defining an operator that acts on multivariable polynomials

Hi Marduk, now it becomes a bit clearer to me what you want to achieve. I don't know whether you have already looked at http://axiom-wiki.newsynthesis.org/ExampleSkewPolynomial That is probably not exactly what you want, but maybe from there you can see how you can implement the type of

Re: [fricas-devel] Defining an operator that acts on multivariable polynomials

Hi Marduk and welcome to FriCAS. On 05/25/2018 10:53 PM, Marduk wrote: > Dear all, > > I am new to FriCAS, but I already read a large portion of the book. There > is something that > I have not been able to figure out and therefore I reach out for your help. > > I have the following

Re: [fricas-devel] )SET-tings

>> And if you like you can create more help pages of this kind at the >> axiom-wiki. > > Thanks for the kind invitation ... You know, I'm wondering if adding new > information there would help users or just increase the entropy of the > site (decreasing the probability for a user of recovering

Re: [fricas-devel] )SET-tings

Hi Riccardo, > Aside comment: > > I was looking for a list of the options and parameters for the system > command )set, which are not explicitly shown in the fricasUG. As far as > I understand using hyperdoc (...Settings) is the only way to see the > )set options/parameters/default for the user

Re: [fricas-devel] Re: Some questions about Fricas

Hi, Erik, I somehow feel in the same position as FriCAS. ;-) I don't know what the definition of the function m is. Ralf On 05/18/2018 10:04 PM, Erik Eidsvig wrote: > Is it possible to find the function value when x is a decimal number? > One of my attempts is under: > > (48) -> m(28) > >

Re: [fricas-devel] Some questions about Fricas

Hi, > How to I define the natural logarithm in FriCAS? It depends on what you mean. FriCAS deals with symbolics, so you can type. (7) -> exp(log x) (7) x Type: Expression(Integer) (9) -> log exp x (9) x So, obviously, log is the name of the natural

Re: [fricas-devel] Localizations

>> PS: I'm sure, you have also found fricas.github.io/api/Localize.html . >> That domain looked somehow weird to me. For a localization, I would >> expect a ring R and a multiplicative closed set S and then form >> S^(-1)R. Why Localize(M, R) wants R to be a CommutativeRing, is not >> completely

Re: [fricas-devel] Roots in finite fields

The first that comes to my mind in this respect is the Berlekamp algorithm. Grepping for it in FriCAS gave me http://fricas.github.io/api/FiniteFieldPolynomialPackage2 Is that what you wanted? Ralf On 05/13/2018 05:28 PM, Waldek Hebisch wrote: > It seems that we have no function to compute

Re: [fricas-devel] Localizations

> "samba" looks a lot like variations of Groebner bases advocated by > Mora. I wonder if "samba" is just a special case or a new variation > unknow before. Thanks for reading the article. Yes, samba is a "critical pair/completion" algorithm, but it's not a Gröbner basis that comes out. The

Re: [fricas-devel] Localizations

Hi Waldek, in general, I am, of course, for generalisations. Do you only want Z --> R:GcdDomain Q --> Fraction(R) ? What is your concrete application for such a generalisation? Do you have also other things in mind? I used it in my article

[fricas-devel] FriCAS status

>> Also I think it is better to use ALLOCATE-VECTOR-WITH-WIDETAG >> than ALLOCATE-VECTOR. > > We can not use ALLOCATE-VECTOR-WITH-WIDETAG because it is not > present in earlier versions of sbcl. Cannot this be conditionalized on the version of SBCL that FriCAS is compiled for? Ralf -- You

Re: [fricas-devel] Group presentation

>if m < 0 then >k := -m >else >k := m Why not k := if m < 0 then -m else m ? Isn't SPAD like Aldor in this case? The "if" construction has a value if both branches return something of the same type? Ralf -- You received this message because you are subscribed to the

Re: [fricas-devel] Group presentation

Waldek, why do you prefer > k := > m < 0 => -k > k instead of if m < 0 then k := -k ? Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from

Re: [fricas-devel] loops and iterate

> repeat > expression1 > condition1 => "iterate" > expression2 Yes, I've seen this, but instead of a string, I would really like a keyword for such cases. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.

[fricas-devel] loops and iterate

I don't know exactly where I would have to check. Aldor allows the keyword "iterate" to start the next iteration in the loop, see http://www.aldor.org/docs/aldorug.pdf page 56 How to do this in SPAD? Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS -

[fricas-devel] PolynomialRing has FreeModuleCategory

Is there anything that would speak against adding FreeModuleCategory(R, E) to the exports of PolynomialRing(R, E)? https://github.com/fricas/fricas/blob/master/src/algebra/poly.spad#L314 There are a few exports that also make sense in PolynomialRing. For example leadingSupport: % -> E

[fricas-devel] forcing PositiveInteger

In a SPAD program I have a construction like for k in n..1 by -1 | key?(k, t) repeat ... where P ==> PositiveInteger n: P key?: (P, T) -> Boolean unfortunately that does not compile. The compiler thinks that k is an Integer and gives me ** level 5 ** $x:= t $m:= (XHashTable

Re: [fricas-devel] About the github mirror

> I have commited my second patch, and svn took almost 1 minute > to finish. So it seems that it's a sourceforge server issue. But another issue on my side as well. I've updated master at github. You don't need to ask me to update. I see the sourceforge commit mails (if they arrive here at

Re: [fricas-devel] About the github mirror

Hi Qian, On 04/24/2018 04:31 AM, oldk1331 wrote: > Hi Ralf: > > One hour ago I made commit r2415, it showed this > on my terminal: > > Transmitting file data ...done > Committing transaction... > svn: E210002: Commit failed (details follow): > svn: E210002: Network

[fricas-devel] FriCAS contribution

> There is a lot of things in FriCAS that could be improved and > users _may_ have some benefit. But if we spend time on things > with marginal benefits we _surely_ will miss things with bigger > impact. That is true, but I think you miss the "fun factor". Every person has different preferences.

Re: [fricas-devel] AbelianMonoidRing vs MonoidRingCategory

>> We have the category AbelianMonoidRing and also there is >> MonoidRingCategory. Shouldn't at least one be a subcategory of the other? >> >> http://fricas.github.io/api/AbelianMonoidRing >> http://fricas.github.io/api/MonoidRingCategory > Well, this is another instance of 'monoid problem':

[fricas-devel] AbelianMonoidRing vs MonoidRingCategory

Shouldn't we clean up a bit? We have the category AbelianMonoidRing and also there is MonoidRingCategory. Shouldn't at least one be a subcategory of the other? http://fricas.github.io/api/AbelianMonoidRing http://fricas.github.io/api/MonoidRingCategory Additionally, the docstring for

Re: [fricas-devel] patches to fr.spad

On 04/16/2018 03:15 PM, Waldek Hebisch wrote: > AFAICS several patches make code more complicated, I am not > shure if we want such changes. In particular, while in > Factored exponents should be nonnegative it make perfect > mathematical sense to also have negative exponents. > To make things

Re: [fricas-devel] fricas_jupyter

Hi Kurt, to make it more complete on my Ubuntu 17.10 installation... root hemmecke:~#ldconfig -p | grep zmq libzmq.so.4 (libc6,x86-64) => /usr/local/lib/libzmq.so.4 libzmq.so (libc6,x86-64) => /usr/local/lib/libzmq.so I installed jupyter via pip3 install jupyter into a

Re: [fricas-devel] fricas_jupyter

H. even on my old (once working) installation, it's problematic. Maybe, the problem comes from previously having a lesser version of sbcl when I had a working iSPAD last time. Ralf == #!/bin/sh AXIOM=/home/hemmecke/software/lib/fricas/target/x86_64-linux-gnu export AXIOM

[fricas-devel] fricas_jupyter

Hi Kurt, what are the currently the instructions to install fricas_jupyter? I need it for Ubuntu 17.10. Thank you 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

[fricas-devel] extendedLLL

I propose the following extended version of LLL which also returns the transformation matrix. https://github.com/hemmecke/fricas/commit/f77a47af7b8a976d9ec7da8140f46c0902cef3c6.patch Opinions? May I commit? Ralf -- You received this message because you are subscribed to the Google Groups

Re: [fricas-devel] help with higher order functions needed

Well... after a little thought, I found a solution. See foo3! in attachment. Is this form (which would certainly work in Aldor) actually available in SPAD? foo1!(t : MI, n : NNI)( bm : MI, N : NNI, k : Z, j : Z, q : Z) : MI == for i in 1..n repeat

[fricas-devel] help with higher order functions needed

I cannot compile the attached code. Neither foo1! nor foo2!. How would I have to write it? Eventually, I would like to pass foo1!(t, n) as a parameter to another function. Ralf (1) -> )co /home/hemmecke/scratch/foo.spad Compiling FriCAS source code from file

Re: [fricas-devel] "has"

Adding to that... (2) -> Integer has with ( 0: () -> % ) Line 1: Integer has with ( 0: () -> % ) .A.B Error A: Missing mate. Error B: syntax error at top level Error B: Possibly missing a ) 3 error(s) parsing On 03/30/2018 09:10 PM, Prof. Dr. Johannes

Re: [fricas-devel] Re: FriCAS documentation and HyperDoc

> I just use tex4ht to convert Latex to HTML. I've done Aldor-Combinat with tex4ht. http://www.risc.jku.at/people/hemmecke/AldorCombinat/ Sorry, but the effort to produce such a website in the first place is not simply zero. And to be honest, it doesn't look quite impressive. Furthermore there

Re: [fricas-devel] [PATCH] avoid unnecessary allocation in DirectProduct

>> In fact, is it really clear that FriCAS accesses tmp0 from outside the >> function? If I'm not wrong, in Aldor you would have to declare > > I think it is common practice to use "free variable" because we > have lexical scope. > >> free tmp0; >> >> inside subtractIfCan. Oh, I'm not against

Re: [fricas-devel] [PATCH] avoid unnecessary allocation in DirectProduct

That will be fine until FriCAS allows inherent parellelism. I don't think we have too many places where parellel execution of commands will fail, but marking domain variables that are not "constant" like here https://github.com/fricas/fricas/blob/master/src/algebra/expr.spad#L1084 seems to me like

Re: [fricas-devel] bug in SparseUnivariateTaylorSeries

On 03/25/2018 11:37 AM, oldk1331 wrote: > On Sun, Mar 25, 2018 at 4:30 PM, Ralf Hemmecke <r...@hemmecke.org> wrote: >> What about a review of these patches? >> >> https://www.mail-archive.com/fricas-devel@googlegroups.com/msg12006.html >> >> ht

Re: [fricas-devel] make check

I'd be in favour if this. Would I have to adjust something at https://github.com/fricas/fricas/ so that travis-ci is automatically started? Ralf On 03/25/2018 08:46 AM, oldk1331 wrote: > Since we have 'make check' now, I propose to add the > travis-ci script to the repo: > > diff --git

Re: [fricas-devel] bug in SparseUnivariateTaylorSeries

What about a review of these patches? https://www.mail-archive.com/fricas-devel@googlegroups.com/msg12006.html https://github.com/hemmecke/fricas/commit/c7f72105e02a21b8bfdcff8f1284de5bf970d279.patch https://github.com/hemmecke/fricas/commit/b7c91e490ff915e26215ea3d4b2f0f9d956e38af.patch Thank

Re: [fricas-devel] VectorSpace

On 03/23/2018 05:21 PM, Waldek Hebisch wrote: > There is a problem in current algebra that FreeModule over field is > not a VectorSpace. Looking at resolution of this the simplest way > seem to be deletion of VectorSpace. Namely, VectorSpace adds one > signature that is 'dimension' that makes

Re: [fricas-devel] bug in SparseUnivariateTaylorSeries

cr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout. From 50e28e6426b57261c6289e03d68e017341acf7e0 Mon Sep 17 00:00:00 2001 From: Ra

Re: [fricas-devel] bug in SparseUnivariateTaylorSeries

Thank you, Qian, I wonder, how the origininal code can ever have worked. Furthermore, we can avoid nniToI st == delay empty? st => empty() term : Term := [(frst st).k, (frst st).c] concat(term, nniToI rst st) altogether. It is similar to coerce(uts : SUTS) == uts

[fricas-devel] bug in SparseUnivariateTaylorSeries

I would like to use the Sparse version of UnivariateLaurentSeries, but it's not working. :-( This is demonstrated on a slightly modified version of FriCAS, but not touching the series code. Ralf Checking for foreign routines AXIOM="/home/hemmecke/software/lib/fricas/target/x86_64-linux-gnu"

Re: [fricas-devel] Fricas as static library

> That seems quite a lot of work to do that. Linking dynamically Fricas and > my program through an API in LIPS that pipe the commands seems way less > work but that means that my program won't be standalone anymore. > I only need some symbolic manipulations on rational fractions and some >

Re: [fricas-devel] File removals

On 03/19/2018 03:13 PM, Waldek Hebisch wrote: > I propose to remove the following: > > 1) AFAICS text in src/interp/Makenotes.tex and in >src/interp/bookvol5.pamphlet is useless -- it is out of >date and mostly does not apply to current code. And from >the start it did not explain

Re: [fricas-devel] Announce: FriCAS 1.3.3 has been released

>> In GUESSPI.htex the output is simply to long. LaTeX seems not to be able >> to work properly on it. Since showing the actual input is not too >> relevant for the demonstration of guessPRec, i've simply suppressed the >> output of the first command. >> >> The problem in LLLRED.htex is that my

Re: [fricas-devel] exquo

> Of course logically 'exactQuotient' makes sense, but I am a bit > reluctant given that 'quo' has equivalent effect and for clarity > one can do > >exactQuotient(x, y) ==> x quo y Well, maybe currently not relevant, but apart from avoiding needless wrapping in Union or computing the

Re: [fricas-devel] Announce: FriCAS 1.3.3 has been released

On 03/17/2018 07:21 AM, oldk1331 wrote: > @Ralf, can you push the 1.3.3 tag Done. > to github and update the documentation site? Also done. But there are two issues. 1) It seems that it's as imperfect as for 1.3.2. I saw some sphinx problems that I have to fix. But the result is certainly as

[fricas-devel] exquo

FriCAS Integer implements exquo via INTEXQUO(x, y)$Lisp https://github.com/fricas/fricas/blob/master/src/algebra/integer.spad#L143 I have several places where I know from context that the division will not fail (I divide out a gcd). Wouldn't it make sense to expose INTEXQUO in Integer as

Re: [fricas-devel] Re: SF.net SVN: fricas:[2375] trunk/src/doc/htex/ug15.htex

On 03/12/2018 01:25 PM, Waldek Hebisch wrote: >> >> Hi Waldek, >> >> shouldn't you also mention commits 2327-2328 in the release notes? >> >> Ralf > > > Something like: > > Added 'gbasisExtend', changed interface to Groebner packages. > > ? r2328 Remove VarSet from NGroebnerPackage r2326

[fricas-devel] Re: SF.net SVN: fricas:[2375] trunk/src/doc/htex/ug15.htex

Hi Waldek, shouldn't you also mention commits 2327-2328 in the release notes? Ralf commit 7375ebafc584466fd2a7bdae36829332a3a019d7 Author: Ralf Hemmecke <r...@hemmecke.org> Date: Mon Jan 8 22:17:40 2018 + remove VarSet from NGroebnerPackage git-svn-id:

[fricas-devel] Re: SF.net SVN: fricas:[2374] trunk/src

Isn't "construct" that what Aldor calls "bracket"? Shouldn't somewhere be written that by syntactic sugar construct [a,b,c] can simply be written as [a, b, c] ? I guess, this was the reason for documenting it the way it was before this patch. Am I wrong? Ralf On 03/09/2018 02:15 PM,

Re: [fricas-devel] Re: sbcl-1.4.5 causes problems

On 03/05/2018 03:31 PM, Waldek Hebisch wrote: >> On 03/02/2018 02:14 PM, Waldek Hebisch wrote: >>> ATM Sourceforge seem to be in non-working state. I will look >>> at the problem when Sourceforge works again. >> >> If you worked with git, then a server-down wouldn't prevent you from >>

Re: [fricas-devel] Re: sbcl-1.4.5 causes problems

On 03/02/2018 06:44 PM, Grégory Vanuxem wrote: > I agree right now. > \begin{joke} > But the future is always strange. > \end{joke} I agree with the joke. So maybe svn becomes more powerful than git in the future. :-D Otherwise I don't see a reason to let imperfect tools prevent you from getting

Re: [fricas-devel] Re: sbcl-1.4.5 causes problems

On 03/02/2018 02:14 PM, Waldek Hebisch wrote: > ATM Sourceforge seem to be in non-working state. I will look > at the problem when Sourceforge works again. If you worked with git, then a server-down wouldn't prevent you from committing. You could always push later, when the server is up again.

[fricas-devel] Fwd: [fricas/fricas] debian packaging (#2)

Since github is not yet the official FriCAS repository, maybe not every has receive that message. Ralf Forwarded Message Subject:[fricas/fricas] debian packaging (#2) Date: Thu, 01 Mar 2018 10:44:31 + (UTC) From: Alex Reply-To:

Re: [fricas-devel] FriCAS status

On 02/22/2018 01:41 AM, oldk1331 wrote: >>> fix documentation in aggcat.spad: >>> >>> https://github.com/oldk1331/fricas/commit/2be927aabf94ca05be45444027c12ef5172cd122.patch >> AFAICS '==' in original was used to get valid Spad function definition. >> I am not sure if we want to replace this by

Re: [fricas-devel] FriCAS status

Although, I will probably try to make fricas_jupyter work for me with every local change to my git repository, I think it would be a nice thing to integrate a modern interface to FriCAS and make it available to a broader user base. Maybe in the first round we can declare it to be experimental.

Re: [fricas-devel] Impressions

> Your red scare was too effective :). Links and text changed. OK, I can take that red stuff away, if nobody complains. It would be enough if we claim that this is now the "official" adapted version of the Jenks & Sutor book for FriCAS with the addition "If you find inconsistencies, please send

Re: [fricas-devel] Impressions

On 02/18/2018 06:14 PM, Waldek Hebisch wrote: > I have now put extra text on documentation page to explain > that .pdf and .html are old. Of course it would be better > to have up-to-date version, but that requires appropriate > proces and developing it is more tricky than one time job. And why

Re: [fricas-devel] Impressions

Hi Ric, Thank you very much for this feedback. Don't worry, I don't take it personally, but appreciate it. And no matter how many hours you wasted before you thought of asking at the fricas-devel mailing list, yes you are right, the documentation is a big mess. I would really like to have it in

Re: [fricas-devel] Question on evaluation (2)

Hi Ric, welcome to FriCAS. On 02/05/2018 11:44 AM, riccardo.gu...@gmail.com wrote: > (As a sad aside, I must say that the current status of fricas installation & > language documentation is "sub-obtimal" We all know. And it's sad. But there are not too many developers that take enough care of

Re: [fricas-devel] leftRecip and rightRecip

On 02/02/2018 09:53 AM, Prof. Dr. Johannes Grabmeier privat wrote: > All general functions as leftRecip and rightRecip are superfluous as > soon we have a recip, associator is superfluous as soon we have an > associative structure, also it should not disappear. My suggestion to > help the novices

Re: [fricas-devel] leftRecip and rightRecip

On 02/01/2018 02:46 AM, oldk1331 wrote: > We can add default implementation of 'leftRecip', 'rightRecip' > to be 'recip' in Group. The patch https://github.com/hemmecke/fricas/commit/a9a7c7d72cdc2a7e3527a505c675ee3b09fcbb05

Re: [fricas-devel] how to access https://groups.google.com/forum/#!newtopic/fricas-devel from outside of google?

On 02/01/2018 03:57 PM, 'Nasser M. Abbasi' via FriCAS - computer algebra > I do not understand why Fricas set up a forum that can only be > accessed by loging to google. I can access all other usenet forums > from outside google except for Fricas. Do you know

[fricas-devel] leftRecip and rightRecip

Hi, obviously exports Algebra the functions leftRecip and rightRecip. But the only place where these functions are implemented is in ncalg.spad. (109) -> Fraction Integer has Algebra Integer (109) true Type: Boolean (110) -> x: Fraction Integer

Re: [fricas-devel] Latex code generated by FriCAS hang lulatex with amsmath and breq package

On 01/27/2018 08:13 PM, 'Nasser M. Abbasi' via FriCAS - computer algebra system wrote: > FYI; > > I think the Latex code generated by Fricas here might not be valid. But I am > not > sure. > > But it hangs Lualatex when I compile it and when I am using breqn package. > > Here it is > >

Re: [fricas-devel] how to remove equation number from )set output tex on

> Is there a way to configure it to remove the equation number? What you can do, is to let TeX expand \leqno(...) to nothing. Put the following into the prologue of your .tex document. \def\leqno#1){} Of course, that runs into problems if you use \leqno in other places of your document. If that

Re: [fricas-devel] not in Bits

Hi Qian, can you tell what makes this patch so special that one cannot simply say )read src/interp/property.lisp )read src/interp/parse.boot b/src/interp/parse.boot Thanks Ralf > This patch can't be loaded directly, you need to apply it then compile > from source. > > diff --git

Re: [fricas-devel] [PATCH] fix a bug in FreeGroup

I support the application of this patch and will commit it if I don't hear any complaints until tonight. In fact, (at least I know it from Aldor), the order of evaluation of the arguments is unspecified, so if in the case of clisp it is evaluating the second argument before the first, then this

Re: [fricas-devel] what RetractableTo should actually export

On 10/11/2017 06:30 AM, oldk1331 wrote: > Well, is 'coerce/retract' mentioned in category theory? Most probably not. It's just that these names are in FriCAS. It's more of a "fricas convention". >From your other mail I learned that you do not want to remove coerce/retract, but rather you would

Re: [fricas-devel] Maybe preview 2

Sorry for being late... > none : () -> % > none? : % -> Boolean > just : R -> % > just? : % -> Boolean > adjust : % -> R In fact, I don't quite understand Qian's argument. Although I previously opted for "coerce" and "retract", I never said that I would like Maybe(X) to be of category

Re: [fricas-devel] Maybe preview 2

On 10/09/2017 12:36 PM, oldk1331 wrote: >> List(X): NIL or a pointer to a record r >> where r holds a value of type X and a NIL pointer >> Record(x: X): NIL or a pointer to a value of type X >> >> So the List version stores an unnecessary NIL pointer together with a >> heap

Re: [fricas-devel] Maybe preview 2

On 10/09/2017 02:39 AM, oldk1331 wrote: > Let "Partial" stands for the global GENSYM() solution and "Maybe" > stands for the "Rep := List R" solution. > Then we still need to pick a default: what should 'subtractIfCan' return? In fact, I would choose the one that works faster and has minimal

Re: [fricas-devel] Maybe preview

On 10/08/2017 07:40 PM, Bill Page wrote: > On 8 October 2017 at 03:47, Ralf Hemmecke <r...@hemmecke.org> wrote: >> On 10/08/2017 05:55 AM, Bill Page wrote: >>> "Union(R,"failed")" on the other hand does seem to take about 80% >>> longer to u

Re: [fricas-devel] Maybe preview

On 10/08/2017 05:55 AM, Bill Page wrote: > "Union(R,"failed")" on the other hand does seem to take about 80% > longer to unwrap a value. I'm not a compiler expert (and I don't actually like Union(X,"failed") so much, but we can have Monad in FriCAS without changing the language. We can have Maybe

Re: [fricas-devel] Maybe preview

rce/retract (or some special compiler knowledge in order to claim that 1$NNI is an Integer. Internally they may have the same representation, but that does not count on the surface. Ralf On 10/05/2017 07:09 AM, Ralf Hemmecke wrote: > On 10/05/2017 02:32 AM, Bill Page wrote: >>> I t

Re: [fricas-devel] Maybe preview

On 10/05/2017 02:32 AM, Bill Page wrote: >> I think current situation is a good compromise. We can >> say in documentation that all instances of Maybe share >> a common value of failed(), and nested usage of Maybe >> is not recommended, Maybe should not be used as Rep >> itself but can be part of

Re: [fricas-devel] semicolon does not inhibit output

> So when you call 'parse("1");', it's like "1" is typed into REPL so > it got printed. Well. It is (at least) surprising. > I don't think this is a big problem, do you agree? With your scan-suggestions, I'm happy to throw away InputForm from my script. So I don't care anymore about this "bug".

Re: [fricas-devel] Maybe preview

On 09/28/2017 04:53 AM, oldk1331 wrote: >>> specify type. Like you can use >>> >>>x := wrap y >>> >>> instead of >>> >>>x : Maybe A_VERY_LONG_TYPE := coerce y one usually writes x := y :: SOME_TYPE so I wouldn't be against y :: Maybe(T) even if T is A_VERY_LONG_TYPE. As Bill said,

Re: [fricas-devel] Maybe preview

On 09/28/2017 11:43 AM, oldk1331 wrote: > Hmm, seems the inline optimization only works for Package, > not Domain. Any hints? Sorry, I've no idea about these internals, but it somewhat surprises me. Packages and domains are not really different, as I see it. It's only that in domains there are

[fricas-devel] FriCAS in Sage

Interesting. There are voices to make FriCAS an optional package in Sage. https://groups.google.com/forum/#!topic/sage-devel/cHkVjFt1pIY Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group

<    5   6   7   8   9   10   11   12   13   14   >