Re: [fricas-devel] [RFC] new domain Pair, big changes for ALIST(AGG)/TABLE(AGG)

On 30 March 2017 at 07:57, oldk1331 wrote: > Hmm, looks like OpenAxiom has already implemented Pair in 2008: > > https://github.com/GabrielDosReis/open-axiom/blob/master/src/algebra/mkrecord.spad.pamphlet > Do you consider this an argument for inclusion of this domain in

Re: [fricas-devel] conjugate

On 29 March 2017 at 12:43, Bill Page <bill.p...@newsynthesis.org> wrote: > The following is an example of this kind of trouble that one can get > into in Maple. Very likely similar things appear in Mathematica, > Maxima, Sage, Sympy and other systems. > Here is what

Re: [fricas-devel] conjugate

The following is an example of this kind of trouble that one can get into in Maple. Very likely similar things appear in Mathematica, Maxima, Sage, Sympy and other systems. > diff(conjugate(x), x); _ x 2 abs(1, x) - - +

Re: [fricas-devel] conjugate

On 28 March 2017 at 17:44, Bill Page <bill.p...@newsynthesis.org> wrote: > > On Mar 28, 2017 4:25 PM, "Waldek Hebisch" <hebi...@math.uni.wroc.pl> wrote: > > Bill Page wrote: >> >> On 28 March 2017 at 15:36, Waldek Hebisch <hebi...@math.uni.wroc.pl

Re: [fricas-devel] conjugate

On 28 March 2017 at 15:36, Waldek Hebisch wrote: > > I would say that more worrying is that _no single number_ may > serve as derivative of 'conjugate'. Without further limitation that statement is incorrect. Could you please explain what you mean? > Keeping derivative

Re: [fricas-devel] conjugate

Sorry, obviously I meant my example to be: abs(x)^2 - x*conjugate(x) On 28 March 2017 at 14:55, Bill Page <bill.p...@newsynthesis.org> wrote: > On 28 March 2017 at 11:40, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: >> Bill Page wrote: >>> >>> Leav

Re: [fricas-devel] conjugate

part they do not affect anything in FriCAS that is already working well. On Mar 28, 2017 9:35 AM, "Waldek Hebisch" <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: > > > > To implement conjugate in Expression you must decide how to > > differentiate c

Re: [fricas-devel] conjugate

<hebi...@math.uni.wroc.pl> wrote: > I looked at old patch by Bill Page implementing 'conjugate' and > changing derivative of 'abs'. I understand that for Bill main > motivation was changed definition of derivative of 'abs'. > However, it is quite likely that this changed definition

Re: [fricas-devel] [PATCH] documentation for permgrps.spad

uld be nice if others could contribute and make it > better, rather than just reject it. > For sure. I just think that the .input files are a better place to keep it rather than the .spad sources. Bill Page. -- You received this message because you are subscribed to the Google Group

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

On 23 March 2017 at 13:09, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: >> >> On 22 March 2017 at 23:29, oldk1331 <oldk1...@gmail.com> wrote: >> >> BTW: For 'exp' using 'opex' as indicated in other messages >> >> i

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

On 22 March 2017 at 23:29, oldk1331 wrote: >> BTW: For 'exp' using 'opex' as indicated in other messages >> is reasonable. But I am sceptical about large scale >> attempt at fixining behaviour of other operators -- there >> are more tricky cases. > > This patch only fixes

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

?' > 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 Page <bill.p...@newsynthesis.org> wrote: >> On 21 March 2017 at 08:16, oldk1331 <oldk1.

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

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

[fricas-devel] Bug: Fix InputForm for paren

Type: InputForm (5) -> interpret % (5) (x + 1) Type: Expression(Integer) This bug affects other uses of InputForm such as making a 'function'. Bill Page. -- You received this message because you are sub

Re: [fricas-devel] Re: [open-axiom-devel] Algorithmic differentiation

tor that "undoes" 'paren'. On 20 March 2017 at 13:32, Bill Page <bill.p...@newsynthesis.org> wrote: > The problem is just the expansion of (1+x)^1. > > (1) -> )set message time on > > (1) -> g(x) == (1+x)^1 >

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

On 19 March 2017 at 05:41, oldk1331 wrote: > (1) -> simplify(exp) > >>> System error: >Cannot take first of an empty list > > > As you can see, such simple expression can > give an error. > > The bug happens because is?(exp, 'exp) returns > true, aka a variable named

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

On 19 March 2017 at 05:41, oldk1331 wrote: > > The name/symbol used for operator '^" is %power, > use such variable in expressions will causes trouble > for sure, that kind of names should not be used in > expressions. > I think that this practice of using different symbols

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

On 19 March 2017 at 05:41, oldk1331 wrote: > > The bug happens because is?(exp, 'exp) returns > true, aka a variable named exp is mistaken for > operator exp. > > First, function names can be used as variables > names, that won't change. > ... > But there are many usages of

Re: [fricas-devel] AssociationListAggregate and TableAggregate

On 17 March 2017 at 01:57, oldk1331 wrote: >> Well, we _define_ AssociationListAggregate as TableAggregate, >> that is _by definition_ we exclude one-to-many mappings. > > So, the author of ALAGG deliberately makes it to not resemble > association list of Lisp, but make ALAGG

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

How about (1) -> ucodeToString 8519 (1) "ⅇ" Type: String (2) -> ucodeToString 8520 (2) "ⅈ" Type: String On 15 March 2017 at 11:34, Ralf Hemmecke

Re: [fricas-devel] overload elt to treat space as multiplication (like MMA)

On 7 March 2017 at 06:59, Ralf Hemmecke wrote: >>> I personally prefer "f g" to mean function evaluation >>> instead of multiplication. > > Although, I've said that I am in general against omission of *, the > above is not a real argument, because. > > If f is of type A -> B

Re: [fricas-devel] overload elt to treat space as multiplication (like MMA)

On 6 March 2017 at 23:16, oldk1331 wrote: >> There are already many domains in which satisfying ELTABLE has the >> semantics of evaluation. Your suggestion to use it so that members of >> some domains act by multiplication could lead to some confusion. > > I'm not suggesting

Re: [fricas-devel] overload elt to treat space as multiplication (like MMA)

There are already many domains in which satisfying ELTABLE has the semantics of evaluation. Your suggestion to use it so that members of some domains act by multiplication could lead to some confusion. For example: (1) -> p:=monomial(1,1)$SUP(INT) (1) ?

Re: [fricas-devel] [discussion] UP and SUP convert to InputForm

It is relatively easy to add a function that appends missing type information to InputForm. For example: diff --git a/src/algebra/catdef.spad b/src/algebra/catdef.spad index ce919f6..2efbfca 100644 --- a/src/algebra/catdef.spad +++ b/src/algebra/catdef.spad @@ -1444,10 +1444,14 @@ SetCategory() :

Re: [fricas-devel] [discussion] UP and SUP convert to InputForm

On 28 February 2017 at 07:14, oldk1331 <oldk1...@gmail.com> wrote: > On Tue, Feb 28, 2017 at 8:06 PM, Bill Page <bill.p...@newsynthesis.org> wrote: >> What do you mean by "code printer"? I suppose suppose that you must >> mean something more than just

Re: [fricas-devel] [discussion] UP and SUP convert to InputForm

What do you mean by "code printer"? I suppose suppose that you must mean something more than just producing a string which when parsed and interpreted re-produces the give code? That is what InputForm provides. Which code? Just a function? Or an entire domain written in Spad? I don't think it

Re: [fricas-devel] [discussion] UP and SUP convert to InputForm

On 24 February 2017 at 01:47, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: >> This is the result when the interpreter fails >> >> (3) -> interpret(4::InputForm)$InputFormFunctions1(PF 5) >> >>An expression involving

Re: [fricas-devel] [discussion] UP and SUP convert to InputForm

Type: PrimeField(5) Also of interest is 'atType' and 'pretendType' in the same package. On 23 February 2017 at 13:33, Bill Page <bill.p...@newsynthesis.org> wrote: > This is the result when the interpreter fails > > (3) -> interpret(4::InputForm)$InputFormFunction

Re: [fricas-devel] [discussion] UP and SUP convert to InputForm

<fricas-devel@googlegroups.com> wrote: > Am Donnerstag, 23. Februar 2017 13:16:16 UTC+1 schrieb Bill Page: >> >> 'Martin R' wrote: >> > For the record: I always thought that InputForm would be intended to >> > provide >> > a means to obtain a construction of

Re: [fricas-devel] [discussion] UP and SUP convert to InputForm

'Martin R' wrote: > For the record: I always thought that InputForm would be intended to provide > a means to obtain a construction of an object. Put differently, converting > an object x to InputForm and evaluating the result should equal x. > The issue is the type of the object. InputForm

Re: [fricas-devel] [discussion] UP and SUP convert to InputForm

On 22 February 2017 at 20:04, oldk1331 wrote: > > I want to add a use case for InputForm: > treat InputForm as a special output form, after unparsing, > gives 1-d output that can be entered back to REPL. > It's like "literals" for other types. > It has always my opinion that

Re: [fricas-devel] fricas: trigonometric simplification.

e easily within FriCAS to provide a more symbolic front-end for example to more algebraic domains like Expression. Please pardon the expression but I think that resorting to Maxima for this sort of thing would be rather a "can of worms". Nonetheless personally I would be very interested in a

Re: [fricas-devel] fricas: trigonometric simplification.

rather strongly against this suggestion. Interoperability of these programs is already provided by systems like Sage. It seems to me that the strength of systems like FriCAS is specifically in inventing new wheels not avoiding same. Bill Page. -- You received this message because you are subscribed to th

[fricas-devel] Bug: The function not is not implemented in Expression(Integer)

es := [type] Commenting out the offending line solves the problem. I was pretty sure this used to work but I don't know what revision might have changed the behavior. So far as I can tell from the history in get this was in the code since at least 2007. Bill Page. -- You received this message b

Re: [fricas-devel] Symbolic (unevaluated) Expressions

Kurt, I have just pushed the changes necessary to make this all build from source. This forced a few name changes (avoiding * + and /\ in constructor names). On 12 February 2017 at 13:05, Kurt Pagani wrote: > Thank you, works fine! > One (unrelated) failure is: > >

Re: [fricas-devel] Symbolic (unevaluated) Expressions

I would be very happy to receive suggestions and questions. Thanks. Bill Page. On 10 February 2017 at 19:08, Kurt Pagani <nil...@gmail.com> wrote: > Am 10.02.2017 um 16:38 schrieb Bill Page: >> Oh and BTW, thanks very much for setting up a sensible testsuite. :) > > I have

Re: [fricas-devel] Comparable (smaller?) Expressions

Why is > (4) -> p+q > >(4) q + p ?? On 11 February 2017 at 13:02, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: >> >> I never noticed it before but now I find this behavior o

[fricas-devel] Comparable (smaller?) Expressions

I never noticed it before but now I find this behavior odd: (1) -> (p,q,r):EXPR INT Type: Void (2) -> smaller?(p,q) (2) true Type: Boolean (3) -> p*q (3) p

Re: [fricas-devel] Symbolic (unevaluated) Expressions

of "rc"). > > I had a look at the diff on github but got no clue where it might come from. > You will certainly find it in no time. > Kurt > > > Am 05.02.2017 um 05:05 schrieb Bill Page: >> The reason that i wrote this as _rule is because the interpreter seems >

Re: [fricas-devel] Symbolic (unevaluated) Expressions

Oh and BTW, thanks very much for setting up a sensible testsuite. :) With your permission I would like to add it to the development branch. If you have time I would be happy for a pull request or I could just push what you attached to the email. On 10 February 2017 at 10:19, Bill Page <bil

Re: [fricas-devel] FriCAS wikipedia page

On 5 February 2017 at 02:55, oldk1331 wrote: > It's recently created, don't know who created it, but > it's nice to have a dedicated wikipedia page for FriCAS. > > https://en.wikipedia.org/wiki/FriCAS > +1 It seems like a good start. Perhaps we could discuss here what might

Re: [fricas-devel] Symbolic (unevaluated) Expressions

The reason that i wrote this as _rule is because the interpreter seems to have a bug that coerces things to Expression Integer. Using the function call syntax seems to get around that and I also use a package call in order to be very specific if necessary. On 4 February 2017 at 18:06, Kurt

Re: [fricas-devel] Symbolic (unevaluated) Expressions

eger,Associative*) > (7) -> eq:= t+(r+t) = (t+r)+t > >(7) t + r + t = t + r + t >Type: Equation(Symbolic(Integer,Associative*)) > (8) -> test eq > >(8) false > Type

Re: [fricas-devel] Symbolic (unevaluated) Expressions

I have made quite a lot of progress on my original proposal to use the InputForm domain as a basis for the implementation of symbolic expressions that resemble the Expression domain but remain unsimplified except where specified or until specifically requested. See the experimental code here:

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

hat I was presuming in the first place as well, so I > naively "grepped" for the catchword in the sources. Do you have a clue where > it's implemented (interp?) and whether there is any run-time control over > it? > It seems that a change of a variable name already has a influen

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

I would put what Waldek said a little differently. FriCAS treats kernels in Expression in equivalence classes stored in a cache that is created dynamically. FriCAS chooses the first encountered kernel in each class as the representative of all kernels in a given class. It does not attempt to

Re: [fricas-devel] fricas: trigonometric simplification.

)) > expr := t1*cos(x3) + 5 + tan(q)*tan(w) + t2*w*cos(a)+ t1*t2*r3 > > rc rs expr -- voilà ;-) > > more below ... > > On Monday, 30 January 2017 15:45:50 UTC+1, Bill Page wrote: >> >> Why do you find it interesting? 'box' and 'paren' are just kernels >> wi

Re: [fricas-devel] fricas: trigonometric simplification.

Why do you find it interesting? 'box' and 'paren' are just kernels with no automatic simplifications. On output 'box' is invisible but 'paren' displays as parenthesis. As with all kernels in Expression the arguments of the kernel are themselves members of Expression (recursively). This seems to be

Re: [fricas-devel] [PATCH] simple changes to function "latex"

I think there is a potential in the 'latex' routines to produce a more "semantic" style of LaTeX output. See for example: https://www.researchgate.net/publication/216797904_Using_LaTeX_as_a_Semantic_Markup_Format and some discussion on this issue on the axiom-developer list

Re: [fricas-devel] Group domains in FriCAS

On 5 December 2016 at 12:31, Bill Page <bill.p...@newsynthesis.org> wrote: > > The collection "subgroups of the symmetric group of S" do not form a > group, rather they ARE groups in-and-of themselves. To be a Group a > domain needs to export some multiplication opera

Re: [fricas-devel] Group domains in FriCAS

On 5 December 2016 at 11:46, Martin Baker wrote: > My initial thoughts about group domains related to homotopy in FriCAS is > that there is a need for at least 4 group domains shown at each corner of > this square: > > PermutationGroup <-equivalent-> GroupPresentation

Re: [fricas-devel] Symbolic (unevaluated) Expressions

rieb Bill Page: >> On 15 November 2016 at 12:01, Kurt Pagani <nil...@gmail.com> wrote: >>> Am 15.11.2016 um 14:12 schrieb Bill Page: >> >> >>>> On 14 November 2016 at 21:39, Kurt Pagani <nil...@gmail.com> wrote: >>>>> This remind

Re: [fricas-devel] Symbolic (unevaluated) Expressions

On 15 November 2016 at 16:51, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: >> >> On 14 November 2016 at 23:59, oldk1331 <oldk1...@gmail.com> wrote: >> >> How about using List of EXPR as Rep? >> > >> > Second tho

Re: [fricas-devel] Symbolic (unevaluated) Expressions

On 14 November 2016 at 21:39, Kurt Pagani wrote: > This reminds me to > https://lists.nongnu.org/archive/html/axiom-developer/2009-06/msg2.html > > I've seen your symbolic.spad for the first time and it might be an approach > to a > topic which is haunting around for some

Re: [fricas-devel] Symbolic (unevaluated) Expressions

On 14 November 2016 at 21:35, oldk1331 wrote: > How about using List of EXPR as Rep? Then this "symbolic > expression" will be viewed as a sum of current EXPR, and > many operations can be done by "map". Just a thought. > I think that for an unevaluated expression we need a

[fricas-devel] Symbolic (unevaluated) Expressions

olic domain. I would be very interested in comments, criticism and suggestions. https://github.com/billpage/fricas/commit/62cc95b16fb7744700ccb04f16ad9ec9f4c0b95c.patch Thanks. Bill Page. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algeb

Re: [fricas-devel] [PATCH] More simplifications in GroupPresentation

On 12 November 2016 at 13:06, Martin Baker <ax87...@martinb.com> wrote: > On 12/11/16 17:37, Bill Page wrote: >> >> I think I know what you mean however in FriCAS % always represents a >> domain - not an element of a domain. In the category 'Group' % >> represents

Re: [fricas-devel] [PATCH] More simplifications in GroupPresentation

On 12 November 2016 at 06:23, Martin Baker wrote: > ... > In simpler terms: PermutationGroup and GroupPresentation are never going > to implement the category 'Group' because in PermutationGroup and > GroupPresentation % represents the whole group whereas in Group % >

Re: [fricas-devel] constructor function patch for tagged-Union

On 7 November 2016 at 21:04, Waldek Hebisch wrote: > > You want to treat Record and Union as duals, but in fact in > imperative languages Record and Union are almost the same: > both records and unions have some fields No. That is like saying that multiplication and

Re: [fricas-devel] constructor function patch for tagged-Union

On 7 November 2016 at 15:13, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: >> >> The following simple patch >> >> https://github.com/billpage/fricas/commit/dad89022088a2a9c410344d10b1cda06773a61f9.patch >> > ... > That works. H

Re: [fricas-devel] constructor function patch for tagged-Union

On 6 November 2016 at 18:50, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: >> >> The following simple patch >> >> https://github.com/billpage/fricas/commit/dad89022088a2a9c410344d10b1cda06773a61f9.patch >> >> adds value co

[fricas-devel] constructor function patch for tagged-Union

ns with signatures such as setelt! : (%,f1,Integer) -> Integer setelt! : (%,f2,Float) -> Float where apparently 'f1' and 'f2' serve as both type names and values is needlessly ad hoc and should ultimately be deprecated anyway. On 3 November 2016 at 23:19, Bill Page <bill.p...@newsynthes

Re: [fricas-devel] get type of object as a fricas object

On 31 October 2016 at 13:32, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: >> >> On 28 October 2016 at 22:16, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: >> > >> > BTW2: The desion goal of FriCAS typesystem was that ans

Re: [fricas-devel] [WIP] Functor, or "MapCategory"

Rather than solve the general problem of evaluation of type constructors qua functions, I think the particular problem in this thread can be better addressed by a relatively simple extension of the mechanism labelled '%' that allows self reference to "this domain". A few years ago I had a

Re: [fricas-devel] get type of object as a fricas object

On 31 October 2016 at 12:21, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: >> > >> > But I also wonder why 'typeOf(Integer)' is 'Type', i.e. that specific >> > category 'Type'. Why not 'Ring' or some other category that 'Integer' >> &

Re: [fricas-devel] get type of object as a fricas object

On 31 October 2016 at 09:21, Bill Page <bill.p...@newsynthesis.org> wrote: > ... > Yes, saying that 'Category' has no type, i.e. that 'typeOf(typeOf > Type)' should return 'Failed' seems more sensible to me. In that case > what FriCAS actually does is worse than what it a

Re: [fricas-devel] get type of object as a fricas object

On 30 October 2016 at 22:37, Kurt Pagani <nil...@gmail.com> wrote: > > Am 31.10.2016 um 02:42 schrieb Bill Page: >> On 30 October 2016 at 19:14, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: >>> ... >>> OTOH: >>&

Re: [fricas-devel] [WIP] Functor, or "MapCategory"

On 30 October 2016 at 19:40, Waldek Hebisch wrote: > > Before using a function Spad runtime first has to compute > types appearing in function signature. So before call to 'ap' > we have to compute 'A(S->S)' with 'A' replaced by 'AMaybe'. > The problem is that

Re: [fricas-devel] get type of object as a fricas object

On 30 October 2016 at 19:14, Waldek Hebisch wrote: > ... > OTOH: > > (2) -> typeOf(Integer) > >(2) Type >Type: Category > (3) -> typeOf(typeOf(Integer)) > >(3) Category >

Re: [fricas-devel] get type of object as a fricas object

hrenic to me. On 29 October 2016 at 09:51, Bill Page <bill.p...@newsynthesis.org> wrote: > Oh, OK sorry I should have read more carefully and tried exactly what you > wrote. > > (1) -> typeof(Integer) > >(1) Type >

Re: [fricas-devel] get type of object as a fricas object

) Internal Error The function typeof with signature hashcode is missing from domain TypePackage (3) -> typeof(SetCategor) Internal Error The function typeof with signature hashcode is missing from domain TypePackage On 29 October 2016 at 09:36, Bill Page <bill.p..

Re: [fricas-devel] get type of object as a fricas object

"dom can't" ??? dom does. On 28 October 2016 at 23:49, Kurt Pagani <nil...@gmail.com> wrote: > Not really, but if nothing else sameType?(Integer,Float) works, dom can't ;-) > > > Am 29.10.2016 um 04:54 schrieb Bill Page: >> Is that better than >> >

Re: [fricas-devel] get type of object as a fricas object

On 28 October 2016 at 22:16, Waldek Hebisch wrote: > > BTW2: The desion goal of FriCAS typesystem was that anwer to > questions like 'sameType?' should be mostly statically known, > without need for runtime tests (I write "mostly" because > Union-s require some testing).

Re: [fricas-devel] [WIP] Functor, or "MapCategory"

The following code compiles (requires bootStrapMode) and seems to work: -- )abbrev category APPL Applicative Applicative(S : Type, A: (Type->Type)) : Category == Type with pure: S -> A(S) ap: (A(S->S),A(S)) -> A(S) )boot $bootStrapMode := true )abbrev domain AMAYBE AMaybe AMaybe(S :

Re: [fricas-devel] [WIP] Functor, or "MapCategory"

g. categories in Sage or the work of Saul Youssef in Aldor. This is just giving a mathematically sound definition of the notion of mapping a function over some "container-like" object which turns out to have a very close relationship to the notion of functor in mathematical category theory. Bil

Re: [fricas-devel] [WIP] Functor, or "MapCategory"

On 24 October 2016 at 19:41, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: >> On 20 October 2016 at 06:16, oldk1331 <oldk1...@gmail.com> wrote: >> > First, the name. Yes, the name "Functor" may lead to >> > confusion, for e

Re: [fricas-devel] [WIP] Functor, or "MapCategory"

On 23 October 2016 at 08:20, oldk1331 wrote: >> Could you provide an example implementation of map for Functor(E) in >> AbelianMonoidRing? >> >> Given that over AbelianMonoidRing there are functions like >> >> f(a:R):(% -> %) == (x:%):% +-> a * x >> >> I do not see how this

Re: [fricas-devel] [WIP] Functor, or "MapCategory"

On 22 October 2016 at 02:31, oldk1331 wrote: >> I still don't like "Functor" as a name. > > That's still debatable, and which name do you prefer? > I think it is possible (may even desirable) to ignore the use of Functor in Haskell and instead focus directly on the connection

Re: [fricas-devel] [WIP] Functor, or "MapCategory"

On 22 October 2016 at 02:08, oldk1331 wrote: > Bill, I'm sorry that I give a bad example. > > About the axioms that "map" has to fullfill: > map(id, x) === xfor all x > map(f, map(g,x)) === map(compose(f,g), x)for all x, f, g > Yes, these are the "functor

Re: [fricas-devel] [WIP] Functor, or "MapCategory"

> ++ map docstring > > However such changes will not update the docstring > showed in HyperDoc. > > OpenAxiom just removes those documentation, which is > a loss of information. (See the OpenAxiom changes on > 2013-05-20, or commit 1316b335). > Why not include

Re: [fricas-devel] Haskell, Functor, Monad, Maybe

s). > > So don't be confused by the "partial" notion. Ah, OK that makes sense. I thought perhaps you meant something along this line ... https://www.reddit.com/r/haskell/comments/1bjfx9/partial_function_maybe/c98fd8h > > On 19 October 2016 at 04:40, Bill Page <bil

Re: [fricas-devel] Haskell, Functor, Monad, Maybe

On 17 October 2016 at 12:27, Kurt Pagani wrote: > ... On the other hand I'd rather like a "partial" monad instead of "maybe" > (which usually means a single terminal symbol "failed"), that is a product > type M(T)=T x Q, where Q is a monoid, such that the Kleisli composition >

Re: [fricas-devel] Haskell, Functor, Monad, Maybe

x : Monad" in package parameter. > Here is another rather long and related thread on this subject from 2011: https://groups.google.com/d/msg/fricas-devel/DEu215PYERg/m7SAlBDNofQJ Unfortunately it did not end in a complete resolution even in OpenAxiom. Perhaps now with your interest we c

Re: [fricas-devel] Haskell, Functor, Monad, Maybe

quot;. I think the usage of "Functor" in Haskell is in this case a better match. Concerning your hack for FunctorPackage and MonadPackage you might be interested in another OpenAxiom innovation implementing the "forall" universal quantifier which often eliminates the ne

Re: [fricas-devel] Haskell, Functor, Monad, Maybe

On 16 October 2016 at 22:12, oldk1331 wrote: > Use Functor category to abstract the 'map' function, > to reduce the number of ')display op map', what do > you think? > +1 -- You received this message because you are subscribed to the Google Groups "FriCAS - computer

Re: [fricas-devel] jupyter notebook

On 11 October 2016 at 20:16, Kurt Pagani wrote: >> >> Haven't gone back to look but I seem to remember parseAndEvalToString was >> important. It was a hack because doing it properly was going to require >> deeper >> changes in Axiom/Fricas/OpenAxiom at the time. >> >> Have you

Re: [fricas-devel] [PATCH] computation.spad Documentation Issues.

On 22 September 2016 at 05:25, Ralf Hemmecke wrote: > ... > And (maybe contrary to Waldek) I am not in favour of keeping hypertex > as a format. In fact, I don't believe that there is somewhere written > down document that defines the format of the ++ docstrings. I'd like > to

Re: [fricas-devel] 0.0^(0::NNI), 0.0^(0::INT), etc

On 13 September 2016 at 17:10, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: >> ... >> Are 0$DFLOAT and 1$DFLOAT really only approximate in FriCAS? >> In general I thought the most consistent approach to floats was to >> treat all (repr

Re: [fricas-devel] 0.0^(0::NNI), 0.0^(0::INT), etc

On 10 September 2016 at 08:38, Waldek Hebisch wrote: >> >> What's the right thing to do? >> >> (1) -> 0.0 ^ (0::NNI) >> >>(1) 1.0 >> Type: Float >> (2) -> 0.0 ^ (0::INT) >> >>>> Error detected

Re: [fricas-devel] discussion: "MetaCategory" for type propagation

Why not let MetaCatagory propogate all categories that satisfy the conditions? The only reason to pass more than one parameter is if the conditions depend on more than one parameter. I am not sure about the name MetaCatagory, though. Probably the name should reflect some specific metacatagorical

Re: [fricas-devel] discussion: "MetaCategory" for type propagation

No, MetaCatagory would have only one argiment R. Inside there would be many rules of the form if R has X On Sep 7, 2016 8:58 AM, "Ralf Hemmecke" wrote: > On 09/07/2016 02:41 PM, oldk1331 wrote: > > I propose a new category called "MetaCategory", which > > has all these

Re: [fricas-devel] hash of Float

At the risk of stating the obvious, it is always possible to implement hash: hash(x) = constant. The only question is how effective it is. On 29 August 2016 at 09:06, Waldek Hebisch wrote: > oldk1331 wrote: > >> Also, for domains like EXPR INT, is it possible to >>

Re: [fricas-devel] hash of Float

I think finding a good way to hash Float is important, not because of the domain Float itself but rather when Float is used in the construction of domains that one really might want to hash. E.g. Expression Float. I any case it should not be left unimplemented, rather it should at least default

Re: [fricas-devel] UnivariateTaylorSeries is Any?

Expression (8) ->(8) -> %.4 (8) 0 Type: SExpression What do you think? Bill. On 19 August 2016 at 08:38, Bill Page <bill.p...@newsynthesis.org> wrote: > Thank you Waldek. Now at least the magic is better h

Re: [fricas-devel] UnivariateTaylorSeries is Any?

, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: >> >> Sorry. Enough to correct the output of 'domainOf': >> >> (1) -> domainOf(taylor(1,x=-1)) >> >>(1) Univ

Re: [fricas-devel] UnivariateTaylorSeries is Any?

not produce a useful result for this example (3) -> typeOf(taylor(1,x=-1)) (3) Any On 18 August 2016 at 19:38, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > Bill Page wrote: >> >> Maybe enough of this "interpreter magic" is in the 'form2String' function. &g

Re: [fricas-devel] UnivariateTaylorSeries is Any?

lse + form2String(x.dm)$Lisp pretend OutputForm x = y == dx := dom x dy := dom y On 18 August 2016 at 19:06, Bill Page <bill.p...@newsynthesis.org> wrote: > Maybe enough of this "interpreter magic" is in the 'form2String' function. > > (1) -> )r

Re: [fricas-devel] UnivariateTaylorSeries is Any?

Maybe enough of this "interpreter magic" is in the 'form2String' function. (1) -> )r /home/wspage/typeof typeof(t:Any):OutputForm == if #(dom t)>1 then hconcat(destruct form2String(dom t)$Lisp :: List OutputForm) else form2String(dom t)$Lisp Function declaration typeof : Any ->

Re: [fricas-devel] UnivariateTaylorSeries is Any?

So, yes the actual type of ts is Any but do you mean that with )set message any on the interpreter hacks somehow manage to display the "domainOf" ts but that the operation 'domainOf' exported by Any fails to properly interpret the parameter value? (1) -> ts := taylor(x, x=1) (1) 1 + (x -

<    1   2   3   4   5   6   7   8   9   10   >