Re: [fricas-devel] Re: Bug: Fix InputForm for paren

> As mentioned, InputForm is used in making functions. For example > > If we use the previous patch to provide a good InputForm, then we can write: > > (1) -> function(paren(x+1)^1,'f,x) > >(1) f > Type: Symbol > (2) ->

Re: [fricas-devel] T and _|_ : how to use them

> For me it looks as another > aspect of "monoid problem": in various context there > is strong mathematical tradition to use specific > symbols with different symbols in different context. > FriCAS domains have fixed operation names so it > is hard to fit all traditions. Are you suggesting that

Re: [fricas-devel] T and _|_ : how to use them

oldk1331 wrote: > > Also, _|_ can't be called, maybe FriCAS lexer don't recognize it? Due to escaping rules you need ugly form: (13) -> ___|__ (13) _|_ Type: Variable(_|_) (14) -> ___|__()$Boolean Internal Error The function

Re: [fricas-devel] T and _|_ : how to use them

Martin Baker wrtoe: > > On 21/03/17 07:43, Ralf Hemmecke wrote: > > On 03/21/2017 08:34 AM, Martin Baker wrote: > >> In ILogic T and _|_ are required as top and bottom of lattice. > >> > >> In Boolean I guess they should give true and false? > > > > Certainly, because these are the only values in

Re: [fricas-devel] Re: fricas.github.io

Am 21.03.2017 um 23:52 schrieb Ralf Hemmecke: > ... > Nevertheless, I somehow tend to open a branch on top of my mathjax > branch and create respective Makefile.in entries to automate the > creation of the respective .rst file(s). That was the goal from the beginning. > > Obviously, it might

Re: [fricas-devel] Re: fricas.github.io

On 03/21/2017 09:53 PM, Kurt Pagani wrote: > I've committed some minor changes (https://bitbucket.org/kfp/rh_book) > and added ug01. That looks like good work. It helps me a lot to understand the direction in which this is going. > Now most of the math output is ok. Some changes to ug01.tex were

Re: [fricas-devel] simplify(exp) gives error

No function is being overriden here. It is always possible to call any function unambiguously by "package calling" it. isOp?(x,'exp)$F and/or in some cases also specifying a result type. However I do agree that my proposed patch is minimal in the sense of keeping some old bit rot in place.

Re: [fricas-devel] simplify(exp) gives error

Overwrite a function is not good, *maybe* someplaces want original definition. The correct way is not to let 'is?' do everything, the correct way should be passing a correct Operator typed argument to 'is?'. Although this way will introduce more changes. On Tue, Mar 21, 2017 at 8:48 PM, Bill

Re: [fricas-devel] simplify(exp) gives error

On 21 March 2017 at 08:16, oldk1331 wrote: > OK, it seems that your patch is OK, but I don't think > redefining 'is?' is a good idea, better to write a function > or macro: > OPERATOR sym ==> operator(operator(sym)$CommonOperators)$F > Why? -- You received this message

Re: [fricas-devel] simplify(exp) gives error

OK, it seems that your patch is OK, but I don't think redefining 'is?' is a good idea, better to write a function or macro: OPERATOR sym ==> operator(operator(sym)$CommonOperators)$F -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system"

Re: [fricas-devel] simplify(exp) gives error

On 20 March 2017 at 23:16, oldk1331 wrote: >> isExpt does not check for the exponential operator. It is looking for >> exponents as in x^2 > > I meant isExpt(xxx, 'exp). That is used in combfunc.spad. > > Bill: > > Yes, the COMMONOP approach is the approach I hoped, > but

Re: [fricas-devel] T and _|_ : how to use them

On 03/21/2017 11:50 AM, Martin Baker wrote: > Yes, but Boolean can only return true or false, there is only confusion > in logics where variable/proposition names can also be returned. Look at what I have done to help with the evaluation of the the signature conditions.

Re: [fricas-devel] T and _|_ : how to use them

> Yes, its in BoundedJoinSemilattice and I thought it was > implemented in ILogic, I don't know if it got lost? I suspect > at some stage _|_() got changed to logicF() in ILogic but > not in BoundedJoinSemilattice? Your are not sure? In that case, simply rename '_|_' to logicF or bottom and

Re: [fricas-devel] T and _|_ : how to use them

On 21/03/17 09:23, oldk1331 wrote: Martin, I noticed that in logic.spad, _|_ is used zero times in code, it only appears in comment and docs. So _|_ is actually not implemented, right? Yes, its in BoundedJoinSemilattice and I thought it was implemented in ILogic, I don't know if it got lost?

Re: [fricas-devel] T and _|_ : how to use them

Martin, I noticed that in logic.spad, _|_ is used zero times in code, it only appears in comment and docs. So _|_ is actually not implemented, right? > Yes, in a ideal world (and I agree existing code is not ideal) > I think that T and _|_ (or unicode equivalent) should be used > for both input

Re: [fricas-devel] T and _|_ : how to use them

On 21/03/17 08:35, Ralf Hemmecke wrote: On 03/21/2017 09:26 AM, Martin Baker wrote: What I'm trying to say is that in, say, intuitionistic logic we have variables (in the mathematical sense - can range over all values). For example, proposition("a") here: (1) -> proposition("a") /\ logicT()

Re: [fricas-devel] T and _|_ : how to use them

On 03/21/2017 09:26 AM, Martin Baker wrote: > What I'm trying to say is that in, say, intuitionistic logic we have > variables (in the mathematical sense - can range over all values). For > example, proposition("a") here: > > (1) -> proposition("a") /\ logicT() > > (1) a >

Re: [fricas-devel] T and _|_ : how to use them

> 'T' conflict with lisp symbol 'T'? I cannot belief that the original developers haven't taken care of that case. Would be strange if in SPAD the use of the identifier T were restricted. > Also, _|_ can't be called, maybe FriCAS lexer don't recognize it? Personally, I don't like _|_ very much.

Re: [fricas-devel] T and _|_ : how to use them

On 21/03/17 07:43, Ralf Hemmecke wrote: On 03/21/2017 08:34 AM, Martin Baker wrote: In ILogic T and _|_ are required as top and bottom of lattice. In Boolean I guess they should give true and false? Certainly, because these are the only values in Boolean. I think its only when logic

Re: [fricas-devel] T and _|_ : how to use them

I meant how to call these two functions? Besides, ")dis op T" doesn't return this signature, maybe 'T' conflict with lisp symbol 'T'? Also, _|_ can't be called, maybe FriCAS lexer don't recognize it? If so, change their name to top/bottom is more appropriate. -- You received this message

Re: [fricas-devel] T and _|_ : how to use them

On 03/21/2017 08:34 AM, Martin Baker wrote: > In ILogic T and _|_ are required as top and bottom of lattice. > > In Boolean I guess they should give true and false? Certainly, because these are the only values in Boolean. > I think its only when logic becomes algebraised (when we have symbols >

Re: [fricas-devel] T and _|_ : how to use them

On 21/03/17 03:21, oldk1331 wrote: T and _|_ is exported from category Logic and domain Boolean, are they intended to be used by user? (1) -> T()$Boolean The function T is not implemented in Boolean . (1) -> __|__()$Boolean The function _ is not implemented in Boolean . In ILogic T