Re: [fricas-devel] friCAS API: weird eval signature?
Thank you, Riccardo, yes, that must be a bug in my api.spad. I'll try to take care of it in the next release. Ralf On 09/18/2018 07:09 AM, oldk1331 wrote: > Yes, I agree that there are parenthesis missing in FriCAS API > (fricas.github.io/api). > -- 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 https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] friCAS API: weird eval signature?
Yes, I agree that there are parenthesis missing in FriCAS API (fricas.github.io/api). -- 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 https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] Fwd: The free field in FriCAS :-)
On 09/17/2018 09:41 AM, Bill Page wrote: I still think a comprehensive testsuite for FDALG and related domains would be a valuable addition. Bill Page. Try this: https://github.com/ray-rogers/NC-FDA-testing Constructive suggestions appreciated; or just ask for rewrite privleges. I left a _small_ residual for dual test; ignore it. If anybody would like a separate report file for test results, it's easy to add. As it is: look in test.log for closing "]]" for formatted returns/results. Do read README.txt Ray -- 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 https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[fricas-devel] friCAS API: weird eval signature?
Hi to all. This is mainly for Ralf.
In
http://fricas.github.io/api/FunctionSpace.html#l-function-space
I read:
eval: (%, List Symbol, List NonNegativeInteger, List List % -> %) -> % if R has
Ring
eval(x, [s1, ..., sm], [n1, ..., nm], [f1, ..., fm])
replaces every si(a1, ..., an)^ni in x by fi(a1, ..., an) for any a1, …, am.
Now, if function application without parentheses is right associating (ie 'f g
x = f(g(x)')
I parse
List List % -> %
above as
( List (List %) ) -> %
or
List( List (% -> %) )
depending on the binding strength of '->'.
(Guess is the former case, ie '->' is weaker than function application.)
But in
https://github.com/hemmecke/fricas/blob/master-hemmecke/src/algebra/fspace.spad#L494
I see:
eval : (%, List SY, List N, List(List % -> %)) -> %
++ eval(x, [s1, ..., sm], [n1, ..., nm], [f1, ..., fm]) replaces
++ every \spad{si(a1, ..., an)^ni} in x by \spad{fi(a1, ..., an)}
++ for any a1, ..., am.
which seems to suggest that the correct parsing is different from the previous
two, ie:
List( List(%) -> % )
Am I missing something or there is a real problem?
Riccardo
--
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 https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] Greek letters in Symbol
Ability to produce greek symbols is interesting. Having them as default would be bad: - AFAICS current default is choosen to minimize chance of conflict with user symbols. Nicer version have bigger chance of conflict. - In some setups non-asci symbols may not work (for example data go between systems that do not agree on encoding) -- 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 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.
Re: [fricas-devel] Defining a rewrite rule when calculation is failing
Slawomir Kolodynski wrote: > > I am trying to figure out a way to tell FriCAS that > limit(erf(sqrt(c)*x),x=%plusInfinity) is 1 (say, I know that c>0). > To do that I define a rule: > > limerf := rule limit(erf(sqrt(c)*x),x=%plusInfinity) == 1 > > However, when I try to apply the rule: > > limerf(limit(erf(sqrt(c)*x),x=%plusInfinity)) > > I get > > Cannot find a definition or applicable library operation named > limerf with argument type(s) >failed > > It looks like FriCAS first tries to evaluate the argument of the rule (and > gets "failed"), then tries to match the rule pattern to the result. > Is there a way to prevent the rule to evaluate its argument before pattern > matching? Or I am doing something wrong here? In FriCAS 'limit' is an operation, not an expression. The same with '=' (which produces equation, not an expression). There is also problem with types: '%plusInfinity' is not an expression. To get something in your spirit one needs to work with expressions: lim := operator 'lim limerf := rule lim(erf(sqrt(c)*x),infinity) == 1 OTOH if purpose is stricly to compute limit, than you can do e1 := eval(erf(sqrt(c)*x), sqrt(c) = d^2) limit(e1, x=%plusInfinity) If you need to undo the substitution in part of expression you can do more complicated thing: (1) -> pos := operator 'pos (1) pos Type: BasicOperator (2) -> e1 := eval(erf(sqrt(c)*x), sqrt(c) = pos(sqrt(c))^2) +-+ 2 (2) erf(x pos(\|c ) ) Type: Expression(Integer) (3) -> limit(e1, x=%plusInfinity) (3) 1 Type: Union(OrderedCompletion(Expression(Integer)),...) (4) -> eI := Expression(Integer) (4) Expression(Integer) Type: Type (5) -> eval(e1, [name(pos)], [2], [(x : eI) : eI +-> x]) +-+ (5) erf(x\|c ) Type: Expression(Integer) -- 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 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.
Re: [fricas-devel] Fwd: The free field in FriCAS :-)
On Mon, Sep 17, 2018 at 9:10 AM Ray wrote: > .. > There are two forms of factoring programs. I have a test harness > to both; separately right now. > In order to try things out: > Using Konrad Schrempf's method you can do something like this > x19:FDA :=(z+1)*(z+2)*(x-2); +++The declaration is not optional > factor(x19)::List(XDP) > --- Or more surprising to me, but proves there is no cheating: > aa:FDA := (x^6-1)*(x^6+1) > factor(aa)::List(XDP) > --- > --- For Bill Page's solution > x19:XDP :=(z+1)*(z+2)*(x-2); +++The declaration is not optional > factor(x19)::List(XDP) > aa:XDP :=(x^4-1) > factor(aa)::List(XDP) ; +++ The "List(XDP)" is not needed but I put it in > --- for uniformity. The x^6-1 causes a stack error in lisp. > --- Total bytes allocated=1072031360 > --- Dynamic-space-size bytes =1073741824 > --- Except as a short reference we should probably not use the phrase "Bill Page's solution". According to Konrad the algorithm currently implemented in XDPOLYF1 originates from a suggestion by Daniel Smertnig. The original version was coded by Konrad as a "exercise". I just improved the coding a little. Its main purpose is mostly educational and as a potential aid in further developing/testing Konrad's ALS work. Now that the ALS coding includes a complete factoring implementation, the actual "production" version of XDPOLYF1 should just be re-written as a wrapper to FDALG. Rewriting XDPOLYF1 would serve to answer some of Ralf's "usability" comments. It is probably true however the FDALG itself could be "cleaned up" a little to seem a less developer-oriented. > I will send the git hub addresses for the testing if you want; > I promise to put up Schrempf's test fixture on git hub today. > It has improvements in reporting but there is something I want > to add later. I still think a comprehensive testsuite for FDALG and related domains would be a valuable addition. 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 https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] Fwd: The free field in FriCAS :-)
On 09/17/2018 02:21 AM, Ralf Hemmecke wrote: Hi Konrad, First of all, thanks to all who worked on https://github.com/billpage/ncpoly. It's always nice to see new research entering FriCAS. I admit that I haven't followed the fdalg discussion very deeply, but reading your documentation is not very helpful. What is the audience for https://github.com/billpage/ncpoly/blob/master/fdalg_20180907.pdf ? Is Section 2 really relevant if I just want to compute with elements in a free field? Wouldn't I just want to construct some (non-commutative) polynomials and then "divide" them similar to the commutative case. I would think that as a user I first must learn how to get the basic things done before going into detail of how it is implemented. Why not starting with "Let f be the non-commutative polynomial x - x*y*x. In the following we compute its inverse f^(-1)." And then you demonstrate how this can be done and explain how the different parts of the output are to be interpreted. Furthermore, I haven't seen that you ever specified that you write a dot instead of 0 in your matrices. The example f=(x-xyx)^(-1) (on page 2) it would certainly be helpful, if you explained how one constructs the entries of A. At the beginning of page 4 I then read "g_11 : FDA := x+x*y*x". Why now + instead of the - in f? Only a few naive comments... Ralf On 09/17/2018 05:02 AM, Bill Page wrote: On Fri, Sep 7, 2018 at 12:24 PM Konrad Schrempf wrote: ... For Bill: If it helps to support further discussions, please put the code on github (maybe including the mini-documentation). I guess that it will take a while to include it in standard FriCAS. Just tell me if you need a formal declaration for the distribution. Is there something important I forgot? Some months ago I just claimed that FriCAS will be the first computer algebra system being able to work with elements in the universal field of fractions of a free associative algebra. Now you can convince yourself. I guess that it takes a while to get used to working with linear representations (admissible linear systems). For small polynomials that really looks like an overkill. But for the example on page 15 one could see the beauty of Cohn's theory. You should try p_43^-1 ... -- Documentation: https://github.com/billpage/ncpoly/blob/master/fdalg_20180907.pdf Source code: https://github.com/billpage/ncpoly Comments appreciated. There are two forms of factoring programs. I have a test harness to both; separately right now. In order to try things out: Using Konrad Schrempf's method you can do something like this x19:FDA :=(z+1)*(z+2)*(x-2); +++The declaration is not optional factor(x19)::List(XDP) --- Or more surprising to me, but proves there is no cheating: aa:FDA := (x^6-1)*(x^6+1) factor(aa)::List(XDP) --- --- For Bill Page's solution x19:XDP :=(z+1)*(z+2)*(x-2); +++The declaration is not optional factor(x19)::List(XDP) aa:XDP :=(x^4-1) factor(aa)::List(XDP) ; +++ The "List(XDP)" is not needed but I put it in --- for uniformity. The x^6-1 causes a stack error in lisp. --- Total bytes allocated = 1072031360 --- Dynamic-space-size bytes = 1073741824 --- I will send the git hub addresses for the testing if you want; I promise to put up Schrempf's test fixture on git hub today. It has improvements in reporting but there is something I want to add later. My intent was to merge the two methods in the sense that the declaration aa:XDP :=(x^4-1) aa:FDA :=(x^4-1) will select which factorization algorithm to use. Schrempf's algorithm is more extensive in theory (and in fact handles (x^6-1) more effectively). Page's algorithm is understandable (in fact I implemented an alternate program using the same idea) but has less mathematical background. It's basically "divide and conquer" ; but seems to work except when it doesn't. Since there didn't seem to be interest in my doing the merge I halted on it and started looking into Schrempf's theory. If anybody is interested I will go back to the coding and update Page's test output; my work on Schrempf's testing has certain refinements. Ray -- 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 https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] Greek letters in Symbol
On 09/17/2018 09:13 AM, Prof. Dr. Johannes Grabmeier privat wrote: > I have extended Symbol to easily create Greek letters and think about > suggesting a change of the default (algebra) genererators > in finite fields from %A, %B to α, β. Any counter arguments? As far as I understand, you want to use newGreek() in place of new() in FiniteField. Personally, I would be in favour of such a change, however, I think FriCAS should be conservative in the sense that the current behaviour should not change and one would have to explicitly turn on (off) greek letters if symbols are auto-generated in finite fields. So somehow I tend to agree on your earlier suggestion with FiniteFieldSymbol(p, n, somesymbol), although the name is not perfect. Maybe one can rely on the fact that FriCAS allows to distinguish between a 2 argument and 3 argument domain constructor. H... I've never tested that. To me the line )abbrev domain FF FiniteField seems troublesome then. 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 https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[fricas-devel] Greek letters in Symbol
I have extended Symbol to easily create Greek letters and think about
suggesting a change of the default (algebra) genererators
in finite fields from %A, %B to α, β. Any counter arguments?
(64) -> newGreek()$Symbol
(64) α
Type: Symbol
(65) -> newGreek()$Symbol
(65) β
Type: Symbol
(66) -> newGreek()$Symbol
(66) γ
Type: Symbol
(67) -> new()$Symbol
(67) %A
Type: Symbol
(68) -> new()$Symbol
(68) %B
Type: Symbol
(69) -> new()$Symbol
(69) %C
Type: Symbol
(70) -> newGreek()$Symbol
(70) δ
Type: Symbol
(71) -> resetNew()$Symbol
Type: Void
(72) -> new()$Symbol
(72) %A
Type: Symbol
(73) -> newGreek()$Symbol
(73) ε
Type: Symbol
(74) -> resetNewGreek()$Symbol
Type: Void
(75) -> newGreek()$Symbol
(75) α
--
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)-32224-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 https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
)abbrev domain SYMBOL Symbol
++ Author: Stephen Watt
++ Date Created: 1986
++ Date Last Updated: 17.09.2018 J. Grabmeier
++ Description:
++ Basic and scripted symbols. Extended to easily created Greek letters as
symbols.
++ Keywords: symbol.
Symbol() : Exports == Implementation where
L ==> List OutputForm
Scripts ==> Record(sub : L, sup : L, presup : L, presub : L, args : L)
Exports ==> Join(OrderedSet, ConvertibleTo InputForm, OpenMath,
ConvertibleTo Symbol,
ConvertibleTo Pattern Integer, ConvertibleTo Pattern Float,
PatternMatchable Integer, PatternMatchable Float) with
new : () -> %
++ new() returns a new symbol whose name starts with %.
newGreek : () -> %
++ newGreek() returns the next greek character.
new : % -> %
++ new(s) returns a new symbol whose name starts with %s.
resetNew : () -> Void
++ resetNew() resets the internals counters that new() and
++ new(s) use to return distinct symbols every time.
resetNewGreek : () -> Void
++ resetNewGreek() resets the internals counters that newGreek()
++ use to return distinct symbols every time.
coerce : String -> %
++ coerce(s) converts the string s to a symbol.
name : % -> %
++ name(s) returns s without its scripts.
scripted? : % -> Boolean
++ scripted?(s) is true if s has been given any scripts.
scripts : % -> Scripts
++ scripts(s) returns all the scripts of s.
script : (%, List L) -> %
++ script(s, [a, b, c, d, e]) returns s with subscripts a,
++ superscripts b, pre-superscripts c, pre-subscripts d,
++ and argument-scripts e. Omitted components are taken to be empty.
++ For example, \spad{script(s, [a, b, c])} is equivalent to
++ \spad{script(s, [a, b, c, [], []])}.
script : (%, Scripts) -> %
++ script(s, [a, b, c, d, e]) returns s with subscripts a,
++ superscripts b, pre-superscripts c, pre-subscripts d,
++ and argument-scripts e.
subscript : (%, L) -> %
++ subscript(s, [a1, ..., an]) returns s
++ subscripted by \spad{[a1, ..., an]}.
superscript : (%, L) -> %
++ superscript(s, [a1, ..., an]) returns s
++ superscripted by \spad{[a1, ..., an]}.
argscript : (%, L) -> %
++ argscript(s, [a1, ..., an]) returns s
++ arg-scripted by \spad{[a1, ..., an]}.
elt : (%, L) -> %
++ elt(s, [a1, ..., an]) or s([a1, ..., an]) returns s subscripted by
\spad{[a1, ..., an]}.
string : % -> String
++ string(s)
Re: [fricas-devel] Fwd: The free field in FriCAS :-)
Hi Konrad, First of all, thanks to all who worked on https://github.com/billpage/ncpoly. It's always nice to see new research entering FriCAS. I admit that I haven't followed the fdalg discussion very deeply, but reading your documentation is not very helpful. What is the audience for https://github.com/billpage/ncpoly/blob/master/fdalg_20180907.pdf ? Is Section 2 really relevant if I just want to compute with elements in a free field? Wouldn't I just want to construct some (non-commutative) polynomials and then "divide" them similar to the commutative case. I would think that as a user I first must learn how to get the basic things done before going into detail of how it is implemented. Why not starting with "Let f be the non-commutative polynomial x - x*y*x. In the following we compute its inverse f^(-1)." And then you demonstrate how this can be done and explain how the different parts of the output are to be interpreted. Furthermore, I haven't seen that you ever specified that you write a dot instead of 0 in your matrices. The example f=(x-xyx)^(-1) (on page 2) it would certainly be helpful, if you explained how one constructs the entries of A. At the beginning of page 4 I then read "g_11 : FDA := x+x*y*x". Why now + instead of the - in f? Only a few naive comments... Ralf On 09/17/2018 05:02 AM, Bill Page wrote: > On Fri, Sep 7, 2018 at 12:24 PM Konrad Schrempf wrote: > ... > For Bill: If it helps to support further discussions, please put the > code on github (maybe including the mini-documentation). I guess that > it will take a while to include it in standard FriCAS. Just tell me if > you need a formal declaration for the distribution. > > Is there something important I forgot? Some months ago I just claimed > that FriCAS will be the first computer algebra system being able to > work with elements in the universal field of fractions of a free > associative algebra. Now you can convince yourself. I guess that it > takes a while to get used to working with linear representations > (admissible linear systems). For small polynomials that really looks > like an overkill. But for the example on page 15 one could see the > beauty of Cohn's theory. You should try p_43^-1 ... > > -- > > Documentation: > https://github.com/billpage/ncpoly/blob/master/fdalg_20180907.pdf > > Source code: https://github.com/billpage/ncpoly > > Comments appreciated. > -- 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 https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
