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

Re: [fricas-devel] Maybe type

On 09/26/2017 01:53 PM, oldk1331 wrote: >> I would rather add a function retractable?: % -> Boolean that does >> exactly such a check and transform the specification into: > > Errr... Wouldn't that be something like retractIfCan : % -> Maybe R > > Which is a total function. Of course you can

Re: [fricas-devel] Maybe type

On 09/26/2017 12:27 PM, oldk1331 wrote: >> Really? Yes, it can, but it is a matter of specification. If you declare >> that retract(x) is only applicable if not(failed?(x)) holds, then there >> is no need for an additional error checking. Such error checking would >> only be a safety net, but not

Re: [fricas-devel] Maybe type

On 09/26/2017 11:10 AM, oldk1331 wrote: > Bill, I changed my mind about retractIfCan/RetractableTo, so Bill, > Ralf and me should on the same page. > About 'coerce : R -> Maybe R', this auto-coercion only works at > interpreter, right? Yes. > So when writing Spad, one should explicitly use

Re: [fricas-devel] Maybe type

On 09/26/2017 03:48 AM, oldk1331 wrote: > I tried to replace 'subtractIfCan' as a starter. It turns out more > difficult than I thought. > > https://github.com/oldk1332/fricas/commit/36c1e89856fdd0b634993cc0d202f5fcfd2818ef > > The change itself is not difficult, but there are many compile

Re: [fricas-devel] Maybe type

On 09/25/2017 07:45 PM, Waldek Hebisch wrote: > - there are things like Union("OK", "failed", "all_bad") in the > codebase. Of course those unions can not be replaced by Maybe. You union looks pretty much like Aldor's Enumeration type and as long as there is no XXX type with additional tags,

Re: [fricas-devel] Semantics of _ and ".." and Boolean functions

On 09/24/2017 08:59 PM, Prof. Dr. Johannes Grabmeier privat wrote: > )abbrev category BFC BooleanFunctionCategory > BooleanFunctionCategory(): Category == BasicType with > "not" : % -> % > _and : (%, %) -> % > nand : (%, %) -> % > _or : (%, %) -> % > xor : (%, %) -> % >

Re: [fricas-devel] DisjunctiveNormalForm

Addon: You can use it in the following way. The argument of DisjunctiveNormalForm is the type of the things that are between the /\ and /\ an ~ operators. )compile api.spad (1) -> DNF==>DisjunctiveNormalForm(Symbol) Type: Void

[fricas-devel] DisjunctiveNormalForm

On 09/19/2017 02:48 PM, Prof. Dr. Johannes Grabmeier privat wrote: > code is a lot of stuff, have basically more or less rewritten and generalized > the polynomials. I cannot help with your code, but I've already written a disjunctive normalform (without taking polynomials as a basis).

Re: [fricas-devel] Maybe type

> 3. There is a problem for "Union", there is this common idiom: > > a := xxxIfCan(xxx) > a case "failed" => xxx > a::A_VERY_LONG_TYPE If I am not completely wrong then there is code in the comiler that allows to simly write a insteat of a::A_VERY_LONG_TYPE. In other words, the compiler

Re: [fricas-devel] Control stack exhausted

On 09/18/2017 12:33 PM, oldk1331 wrote: > totalDegree: > > https://github.com/fricas/fricas/blob/master/src/algebra/gdpoly.spad#L43 Oh. Thanks. In on my working branch, I have removed exactly that function. Funny. Everything still compiles without it. totalDegree p == zero? p

Re: [fricas-devel] Control stack exhausted

On 09/18/2017 12:05 PM, oldk1331 wrote: > Another place to speed up: > > About 10% time is spent on 'totalDegree' of GDMP, > >totalDegree p == > zero? p => 0 > "max"/[reduce("+",(t.k)::(Vector NNI), 0) for t in p] > > t.k is of type E which has category

Re: [fricas-devel] Maybe type

> Since data in Lisp is already tagged, we can always prevent > unnecessary memory allocation, for Integer, we can use NIL > to indicate failure, Really? The (lisp) integer 0 and NIL are distinguishable? Does that work for all implementations of lisp? I would bet that this is an implementation

Re: [fricas-devel] more exports for CancellationAbelianMonoid

On 09/18/2017 01:13 AM, oldk1331 wrote: > Hmm, your following approach seems like to alloc this memory > on stack instead of heap, and potentially do the computation twice. Yes. Double computation *is* a problem, especially when the function canSubtract?$R (on the coefficients is more time

Re: [fricas-devel] Maybe type

On 09/18/2017 01:19 AM, oldk1331 wrote: > I think the compiler treat SubDomain and its argument specially, > it only handles INT/NNI/PI, so I suggest you to not use SubDomain. I don't know how the compiler treats SubDomain, but I find it logically questionable. Think about a domain T that is an

[fricas-devel] Maybe type

On 09/15/2017 04:23 AM, oldk1331 wrote: > 2. subtractIfCan for NNI is very wasteful, the return type > Union("failed", NNI) takes 3 times the space than NNI. > (type Maybe doesn't have this problem, but that's a different topic) Can you elaborate on this Maybe type and why it doesn't have that

Re: [fricas-devel] Control stack exhausted

On 09/15/2017 08:58 AM, oldk1331 wrote: > A bigger concern is, to avoid unnecessarily alloc memory, > I do the '<' or 'subtractIfCan' computation twice. I wonder > if it's a good tradeoff in general. It is good tradeoff in this case. Yes. Interestingly, when I rewrote your initial patch by using

Re: [fricas-devel] Control stack exhausted

On 09/15/2017 04:23 AM, oldk1331 wrote: > I reviewed the patch, it's good Thanks for the review. I'll push my patch tonight. > I then took a profile, to my surprise, almost 30% time is spent on > |DIRPROD;subtractIfCan;2$U;17| and |NNI;subtractIfCan;2$U;4|, > see the 'subtractIfCan' calls in

Re: [fricas-devel] Control stack exhausted

com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout. From 8bc1e6b6b6a444a9dfcca921fc337395ffac6347 Mon Sep 17 00:00:00 2001 From: Ralf Hemmecke <r...@hemmecke.org> Date: Wed, 13 Sep 2017 23:26:13 +0200 Subject:

Re: [fricas-devel] Please help: wierd bug with library loading

On 09/11/2017 07:18 PM, Waldek Hebisch wrote: >>> So, if my analysis is correct, we should automatically >>> load XXXCAT- when ')lib XXXCAT' is issued. >> >> Let's see what Waldek says. But I would appreciate that the default >> package is automatically loaded if the category is loaded via )lib. >

Re: [fricas-devel] Please help: wierd bug with library loading

On 09/08/2017 04:52 AM, oldk1331 wrote: > I might find something: > > The FooCat category comes with a default implementation > of function etaQuotientIdealGenerators, so the compiler > generates a "dummy domain" for that, "FOOCAT-". > > If you add ")lib FOOCAT-", then there's no problem. THANK

[fricas-devel] Please help: wierd bug with library loading

Hello (in particular Waldek), while trying to run my code I ran into a terrible bug. Obviously, loading a library into a session is NOT the same as compiling it in that session. Well, the particular problem here is perhaps that etaQuotientIdealGenerators is defined in the category FooCat from

Re: [fricas-devel] help needed

On 08/20/2017 11:11 AM, Prof. Dr. Johannes Grabmeier privat wrote: > Hallo Ralph, > > you abbreviated a package and implemented a category: Dear Johannes, dear Qian, thank you for pointing out such a stupid mistake. Well, yet another reason why )abbrev should go away. Ralf -- You received

Re: [fricas-devel] Category abbrevs vs Error message

> Well, in *.spad file, you can't use abbreviations, but I use abbreviations > in REPL and find it convenient, some Domain/Package names are really long. That could be solved also by a FRICAS_INIT file and a file fricasabbrevs.input where all the current abbreviations are provided by a list of

Re: [fricas-devel] help needed

On 08/20/2017 08:33 AM, oldk1331 wrote: > Did you upload the wrong attachment? Oh, indeed. Here the right one. 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

[fricas-devel] help needed

Can somebody tell me why the following file does not compile? (1) -> )co foo.spad Compiling FriCAS source code from file /home/hemmecke/backup/git/fricas/eta/foo.spad using old system compiler. FOO abbreviates package Foo

[fricas-devel] help needed

Can somebody tell me why the following file does not compile? (1) -> )co foo.spad Compiling FriCAS source code from file /home/hemmecke/backup/git/fricas/eta/foo.spad using old system compiler. FOO abbreviates package Foo

[fricas-devel] Category abbrevs vs Error message

Hello... it seems that for categories with default implementations there should be an error message, that says that their abbreviation can only be 7 (instead of 8) characters. Much better would it be, if this restriction is removed completely. It's no longer corresponding to the filesystems of

[fricas-devel] recursive new? (Problem with garbage collection?)

What exactly does that mean (see below)? I wouldn't expect that garbage collection is started when this is the first command in a session. And why would garbage collection fail here? I'd be happy if I could control the amount of heap that is available for FriCAS, if FriCAS doesn't itself claims

Re: [fricas-devel] URAGG should have Collection

On 08/16/2017 02:03 PM, oldk1331 wrote: > (7) -> URAGG INT has Collection INT > >(7) false > > From documentation of Collection: > > ++ A collection is a homogeneous aggregate which can be built from a > ++ list of members. The operation used to build the aggregate is > ++ generically

Re: [fricas-devel] Macports port for Fricas

On 08/14/2017 10:14 AM, Piet van Oostrum wrote: > oldk1331 writes: > >> Hi Piet, "MAYBE_VIEWPORTS=viewports" has no effect on release tarball, >> it's only useful in SVN trunk version, so you can remove that. >> > Are you sure? > When I run 'make viewports', it copies

Re: [fricas-devel] Problems with GMP on Mac OS

> I compiled without pre-generated lisp files (with 'make PREGENERATED=') > because of the previous patch to elemntry.spad. The compile took some 10 > hours on my MacBook Pro. 10 hours? I run the build with sbcl and make -j8 (on i7 2720QM. It takes (including the build of the fricas-aldor

Re: [fricas-devel] Future of FriCAS

On 07/24/2017 11:49 AM, oldk1331 wrote: >> TeXmacs once had/has an interface to FriCAS. > TeXmacs plugin is usable. One feature is that you can select > part of the output and use that as input. The problem with TeXmacs is that every time I try to use it, it feels slow and sometimes not working

[fricas-devel] No -- comments in system commands lines

Oooops... (1) -> )co qfunct.spad -- This is a compilation call. >> Error detected within library code: Strange argument to pathname Maybe it is natural to let lines starting with ")" follow a different rule, but I didn't know that comments are not allowed. Unfortunately, it's hard to

Re: [fricas-devel] The Mathematica Kernel: Issues in the Design and Implementation

On 07/20/2017 02:15 PM, oldk1331 wrote: > I read the pdf, it covers a lot of topics, but I don't think > it talks much about "how to build big system" (how to deal with > complexity). I like in particular this sentence from page 36 of

[fricas-devel] The Mathematica Kernel: Issues in the Design and Implementation

I wonder how much the FriCAS design with categories and domain and packages, prevents at least some of the issues from Daniel Lichtblau The Mathematica Kernel: Issues in the Design and Implementation http://library.wolfram.com/infocenter/Conferences/7518/ Ralf -- You received this message

Re: [fricas-devel] Problems with GMP on Mac OS

On 07/20/2017 11:23 AM, Piet van Oostrum wrote: > Ralf Hemmecke wrote: > >> * --enable-gmp=no would not build without GMP. > > There are three negations in the above line. Do you perhaps mean: * > --enable-gmp=no would build without GMP. Of course. > The interesting

Re: [fricas-devel] Problems with GMP on Mac OS

On 07/20/2017 09:49 AM, Piet van Oostrum wrote: > Well, GCC uses --with-gmp. I don't think you can be more 'GNUish' than GCC. ... > I would suggest to use the same system, and keep --enable-gmp for backwards > compatibility. Yes. * configure should test for availability of gmp libraries and

Re: [fricas-devel] Problems with GMP on Mac OS

On 07/19/2017 11:39 PM, Waldek Hebisch wrote: > Piet van Oostrum wrote: >> >> I have a working solution now with configure options >> --with-gmp=/dir/where/gmp, or alternatively, >> --with-gmp-include=/dir/where/gmp/include --with-gmp-lib=/dir/where/gmp/lib >> I think this is the cleanest

Re: [fricas-devel] what's the intention of 'elt : (%, List Integer) -> %' in SExpression

On 07/19/2017 11:56 AM, oldk1331 wrote: > The documentation says: > > elt : (%, List Integer) -> % > ++ elt((a1, ..., an), [i1, ..., im]) returns \spad{(a_i1, ..., > a_im)}. > > Which means to 'select parts of first argument'. > > The implementation is: > >

Re: [fricas-devel] Problems with GMP on Mac OS

On 07/18/2017 06:46 PM, Piet van Oostrum wrote: > I have applied this patch, but, unfortunately, it doesn't solve the timing > problem. > > numeric(%e, 100); takes 0.3 sec when preceded by numeric(%e, 1) > but 130 sec if given as the first expression. I don't know for certain, but I fear

Re: [fricas-devel] [PATCH] change the return type of factorList to be more readable

On 07/11/2017 03:06 AM, oldk1331 wrote: > https://github.com/oldk1331/fricas/commit/00cfe02e02c742f6659c240ac2b16b5af0ab40a3.patch > > This patch changes the return type of 'factorList' from > List(Record(flg: Union(...), fctr: R, xpnt: Integer)) > to > List(Record(flag: Union(...), factor: R,

Re: [fricas-devel] generate User Guide book from *.htex sources

On 07/14/2017 10:53 AM, oldk1331 wrote: > It should be documented somewhere, clearly it should be in the user > guide book. Maybe FAQ also? Oh, yes. FAQ would be a good place for FRICAS_INIT. We even have an outdated version there. :-(

Re: [fricas-devel] generate User Guide book from *.htex sources

On 07/12/2017 05:51 AM, oldk1331 wrote: > Some comments on the code: > > 1. respect FRICAS_INITFILE : Oh. Thanks. Since I don't have an init file, I don't experienced any problem so far. Well, currently, I'm probably anyway the only person who uses it. However, that brings me to the idea that

Re: [fricas-devel] generate User Guide book from *.htex sources

On 07/10/2017 11:24 AM, oldk1331 wrote: > It seems that the User Guide book (Jenks & Sutor) > was written in TeX, then in order to use it in HyperDoc, > it was rewritten/modified into src/doc/htex/ug*.htex . > > So it is possible ro recreate the User Guide pdf from > these htex sources, am I

Re: [fricas-devel] [PATCH] typos and documentation fix

On 07/08/2017 04:42 AM, oldk1331 wrote: > https://github.com/oldk1331/fricas/commit/d466ccb5f228b5b416755aef01c0029cf7fe6421.patch > > > Off topic a little: > > Waldek, I know you are busy, so if someone else on this > list reviews this patch, then you can apply it directly, right? That patch

Re: [fricas-devel] IntegerLocalizedAtPrime

On 07/06/2017 06:12 PM, Waldek Hebisch wrote: > oldk1331 wrote: >> >>> In contrast to PrimeField, I haven't introduced an "Inner..." package. >>> In fact, I don't understand why InnerPrimeField is necessary for that >>> prime trick. >> >> Indeed, I think we can merge InnerPrimeField and

Re: [fricas-devel] IntegerLocalizedAtPrime

On 07/03/2017 08:47 AM, oldk1331 wrote: > Also, those macro definitions should be defined after ")abbrev", > because I think 'scripts/unpack_file' will cut them off. Oh yes, thank you. I've renamed from locint to intlocp to make it similar to the )abbr name INTLOCP. Also thanks for the Makefile

[fricas-devel] IntegerLocalizedAtPrime

groups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout. >From 0b4e61a062658a4b9d26315dfd471253c4a6a564 Mon Sep 17 00:00:00 2001 From: Ralf Hemmecke <r...@hemmecke.org> Date: Mon, 3 Jul 2017 01:15:48 +0200

[fricas-devel] LLLReduction gram_step(!)

Hi Waldek, even if this is only an unexported function, wouldn't it be better follow the FriCAS naming convention if it were called "gram_step!" (with exlamation mark) instead of just "gram_step"? https://github.com/fricas/fricas/blob/master/src/algebra/lll.spad#L26 Ralf -- You received this

[fricas-devel] PolynomialCategoryLifting

Hi Waldek, I still have this question from Feb 2016 in my queue. https://www.mail-archive.com/fricas-devel@googlegroups.com/msg08905.html Any opinion? Can I remove the requirement "SetCategory" from PolynomialCategoryLifting and commit? Ralf -- You received this message because you are

Re: [fricas-devel] Bug in groebnerFactorize

On 05/28/2017 06:09 PM, Waldek Hebisch wrote: > There is GBEUCLID... Wow... how could I have missed this? But good to know, since that package also relies on VarSet in Dpol. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system"

Re: [fricas-devel] Bug in groebnerFactorize

On 05/24/2017 06:59 PM, Bill Page wrote: > On 22 May 2017 at 13:01, Waldek Hebisch wrote: >> There is a simple trick to make this about 10-20 time faster: >> clear denominator and use coefficients in the ring. If I am not completely wrong, it is even mentioned in the

Re: [fricas-devel] gcd in fraction fields

On 05/23/2017 05:14 PM, Waldek Hebisch wrote: > So it is probably better to have a separate function, say > 'fractionGcd'. If at all, I'd be in favour of such a new function fractionGcd. However, my question is whether it is really worth implementing a new function. Yes, it's convenient, but any

Re: [fricas-devel] [PATCH] change signature of simplify$SIMPAN

On 05/21/2017 12:54 PM, oldk1331 wrote: > Ralf, I agree with you. I think it is better to move this function into > domain AlgebraicNumber. Well... SimplifyAlgebraicNumberConvertPackage() : with simplify : AlgebraicNumber -> Expression(Integer) ++ simplify(an) applies simplifications

Re: [fricas-devel] [PATCH] change signature of simplify$SIMPAN

On 05/21/2017 04:41 AM, oldk1331 wrote: > I change the signature of simplify$SIMPAN, from > 'AlgebraicNumber -> Expression Integer' to 'AN->AN', > also I use 'pretend' because the Rep of AN is EXPR(INT). > > All tests passed. > https://travis-ci.org/oldk1331/fricas/builds/234447057 > >

Re: [fricas-devel] Bug in groebnerFactorize

On 05/15/2017 07:30 PM, Bill Page wrote: > I think the factor of 1000 in the difference in the time required to > compute the Groebner basis suggests that Singular is probably using a > different algorithm to produce this result - maybe something like > choosing a more favorable term order and

Re: [fricas-devel] [RFC] remove cyclic structure from Stream

On 05/15/2017 12:28 PM, oldk1331 wrote: > The advantages are: > 1. Simpler code, higher performance, no need to detect cycles. > 2. The code will match the specification. Now we claim to support > cyclic structure but we don't, that's a bug, but fixing that will decrease > performance. After

[fricas-devel] GcdDomain (gcd and lcm docstrings)

Look at the docstrings in GcdDomain. I think, we can do better. gcd : (%, %) -> % ++ gcd(x, y) returns the greatest common divisor of x and y. lcm : (%, %) -> % ++ lcm(x, y) returns the least common multiple of x and y. In particular, it is not clearly

Re: [fricas-devel] gcd in fraction fields

On 05/14/2017 07:22 PM, Bill Page wrote: > Algebraically some choices are better than others. In particular it > seems desirable that > > Q := Fraction R > gcd(n,m) = retract gcd(n::Q, m::Q) > > for all n and m in R. Why? As a mathematician, I wouldn't expect that. And as a computer

Re: [fricas-devel] gcd in fraction fields

On 05/13/2017 07:13 PM, Bill Page wrote: > By default Fraction always returns a gcd of 1. > > (1) -> gcd(1/3,1/4) > >(1) 1 > Type: Fraction(Integer) > > But gcd is well defined provided that the underlying domain has GcdDomain. > +

Re: [fricas-devel] github mirror tag 1.3.2

> Ralf, it seems that you created and deleted tag 1.3.2 on > github mirror, why is that? Oh. Thanks. I had set the tag on the wrong local repository and forgot that the "syng" repo does a "git push --mirror". :-( Sorry. Is fixed now. Ralf -- You received this message because you are subscribed

Re: [fricas-devel] copy of AssociationList

On 05/03/2017 08:49 AM, oldk1331 wrote: >> Oh, maybe I didn't express myself well enough. The line >> >> map(f, l) == map!(f, copy l) >> >> is an implementation detail. It's a good default, but if the context >> (speed or violation of some conventions) give rise to another >> implementation that

Re: [fricas-devel] Re: [PATCH] fix 'construct' and '=' for AssociationList

On 05/03/2017 04:08 AM, oldk1331 wrote: > The construct is wrong: > > +construct l == ref l > > That causes shared structure, and 'ref copy l' will not work either. > This problem is coupled with the other thread "copy of AssociationList". > > Namely, we should implement 'deep copy' of

Re: [fricas-devel] copy of AssociationList

On 05/03/2017 01:53 AM, oldk1331 wrote: >> I would accept map(foo!, L) with a destructive function foo! to modify L >> in-place, but + isn't such a function. >> >> I think that is not a problem of the representation of AssociationList, >> but rather a problem with the implementation of map. > >

Re: [fricas-devel] copy of AssociationList

On 05/02/2017 11:58 AM, oldk1331 wrote: > I saw this in an old email from Martin Rubey in 2008, > titled "Bug in ALIST?": > > (90) -> A := construct([[1, 10], [2, 20]]$List Record(key: INT, entry: > INT))$ALIST(INT, INT) > >(90) table(2= 20,1= 10) >

Re: [fricas-devel] [RFC] split cyclic data structure into its own category

On 04/26/2017 08:00 PM, Waldek Hebisch wrote: > oldk1331 wrote: >> >> It will be a big change so it will get into next release >> if this idea get approved. Before that, I'd like some >> comments first. >> >> There are data structure categories that explicitly supports >> cyclic data structure,

Re: [fricas-devel] Question about nested functions

Can you avoid HTML in you mail? I find it unnecessarily hard to search for your answer in your mails. Remove quoted text that is not relevant for your answer. Thanks. > Why does the compilation say "old system compiler"? Because Aldor was supposed to be the new compiler back in the days when NAG

Re: [fricas-devel] Question about nested functions

1) If I'm not wrong then local function definitions don't work in the interpreter. 2) For this particular example, you don't need a local function. Or do you see the parameter l used somewhere in leng_aux? 3) Writing generic code is not usually done with Any. Rather you should consider writing a

Re: [fricas-devel] Questions about use of aldor under fricas

> Thanks for the valuable information. The only thing I noticed was > that the function sieve conflicts with FriCas, so renaming it sieve2 > works ok. Could you comment on when to use the include files aldor > aldorio axiom axiom.as ? If you want to use Aldor with FriCAS,

Re: [fricas-devel] Questions about use of aldor under fricas

On 04/21/2017 09:04 PM, Doug Telford wrote: > 1. Is there documentaion about using aldor under fricas? Unfortunately, the answer is more or less: no. > How much of the aldor user's guide is applicable? Aldor is a programming language. It comes with basically 3 libraries. 1) axllib 2) libaldor

Re: [fricas-devel] T and _|_ in Boolean

On 04/19/2017 11:28 AM, oldk1331 wrote: > Now T and _|_ are implemented in Boolean, but it's > tricky to call them: > > (8) -> ___|__()$Boolean > >(8) false > Type: Boolean > > That's a lot of escape char I'm pretty sure that

Re: [fricas-devel] aldor compilation fails

On 04/09/2017 07:17 PM, Waldek Hebisch wrote: > So 'PositiveInteger' seem to come from the code above. Clearly we > need smarter version of 'axFormatType'. As quick fix something like > > > INTEGERP typeform => > typeform = 0 => > ['RestrictTo,

Re: [fricas-devel] YAQ (Yet Another Question)--Feature?

Hi Raymond, If you know what your coefficients are and what operations you want to perform with series, you can also do it in this way. (2) -> C==>UnivariatePolynomial('a, Integer) Type: Void (3) -> K==>Fraction C

Re: [fricas-devel] Is rational/rational?/rationalIfCan useful?

On 04/14/2017 02:10 PM, oldk1331 wrote: > There are 8 rational/rational?/rationalIfCan, all > of them are defined under > "if R has IntegerNumberSystem then ..." > > And seems these functions are not used in other places. > > They are basicly wrappers over >retractIfCan : % ->

Re: [fricas-devel] Simple symbolic >,<,=>conditional?

On 04/12/2017 07:12 PM, Raymond wrote: > I hate to be a pest but I have looked around and apparently don't understand > some conditional/typing. > For instance after > n : PI > we get. > > (9) -> if (n>-3) then true else false > > n is declared as being in PositiveInteger but has not been

Re: [fricas-devel] aldor compilation fails

On 04/09/2017 07:17 PM, Waldek Hebisch wrote: > Ralf Hemmecke wrote: >> >> Hi, >> >> I just wanted to report that the fricas-aldor interface compilation >> fails with trunk at the moment. >> >> The reason is most probably in b

[fricas-devel] aldor compilation fails

Hi, I just wanted to report that the fricas-aldor interface compilation fails with trunk at the moment. The reason is most probably in bezout.spad if R has CommutativeRing then subresultants : (UP, UP) -> IndexedVector(UP, 0) Somehow the corresponding lines in the generated .ap file

Re: [fricas-devel] About src/input tests

On 04/06/2017 02:06 PM, oldk1331 wrote: > The exit code of "make" in src/input should indicate > whether the tests are passed or failed. > > Are there better methods than add a test.sh in src/scripts: Do you know: https://github.com/fricas/fricas/commit/1aeb7648fa832ae78b54741c25cbeea21a85cef6

Re: [fricas-devel] Re: About Travis CI

On 04/04/2017 06:33 PM, Waldek Hebisch wrote: > oldk1331 wrote: >> >> I mean, if Waldek don't want to include this travis CI script for now, >> you can set up a branch that does travis CI testing. > > I is not clear for me what actually we gain from travis CI.a new branch on > top of > My

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