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

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 Of course it's possible to have a Functor(E) for AbelianMonoidRing(R,E), it may not "make sense", but it is

[fricas-devel] [BUG] ")show ListPackage" displays "T$" instead of "T"

(1) -> )show ListPackage ListPackage(T$: BasicType) is a package constructor Abbreviation for ListPackage is LISTPKG This constructor is not exposed in this frame. ─── Operations shiftLeft : List(T$) -> List(T$) cartesian :

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

> It seems to me that the name 'Functor' is fine from the point of view > of established usage in Haskell and other similar programming > languages. > > Also the name 'Functorial' is good from the point of view of > mathematical category theory. > > The use of 'Functor' to refer to type

[fricas-devel] Re: Re: FriCAS web interface failure

Any updates? Well, the site's error message changed. And Martin asked again in sci.math.symbolic. -- 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

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

About abstracting the signature 'map : (S->S,%)->%' into a category, there are 2 problems so far: > - Functor is quite loaded name and may lead to confusion. > Something like 'MapCategory2' seem to fit better existing > naming scheme. > - What documentatin do you propose for the 'map'

Re: [fricas-devel] [PATCH] add a new interface for partialFraction;

> ATM I am undecided. I am not sure if changing 'up' to 'UP' is > really an improvement. OTOH there are several uses of 'pretend'... I think types should all be capitalized, and changing UP to a macro is better. As for the usage of pretend, the whole PartialFractionPackage still looks

Re: [fricas-devel] Re: Viewports, Draw

> I'm trying to map draw options to frontend specific options. Most > but colors are easy. Is there a package or example how to convert Color, > Palette to something comprehensible (to me), e.g. RGB? Seems there should be a more sophisticated Color domain. For now since the colors are predefined,

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

> 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 evaluates the two programs in sequence and combines their > Q >

Re: [fricas-devel] [PATCH] add a new interface for partialFraction; doc fix

Any update on this patch? On Thu, Oct 13, 2016 at 8:58 PM, oldk1331 <oldk1...@gmail.com> wrote: > A little more misc fixes and improvements for pfr.spad: > > https://github.com/oldk1332/fricas/commit/57f913c588bbdb970f50305ccb72e912586fcb2b.patch > > It's not included in the

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

> Rather than Haskell per se, personally I am most interested in > the "category theory" approach summarized in Martin's email, therefore > I prefer the alternative definition of monads as a domain satisfying > Functor > > map :: (a -> b) -> M a -> M b > > with these two additional

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

On Mon, Oct 17, 2016 at 3:53 PM, Ralf Hemmecke wrote: >>> Functor is quite loaded name and may lead to confusion. >> >> Yes, the name is a problem. OpenAxiom uses "Functorial". >> But I think Functor is fine, given the context that Haskell is >> using this name. > > BTW, in

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

> We have more than 50 packages named '*Functions2' which > implement 'map' between two domains. I am not suggesting replace those packages that deals with more than two domains. I'm talking about map : (S->S, %) -> % , where % has a parameter S There are about 15 map signatures like this.

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

Bill, you were in the previous Monad discussion thread, what do you think of the Monad this time? -- 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

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

Use Functor category to abstract the 'map' function, to reduce the number of ')display op map', what do you think? -- 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

Re: [fricas-devel] Re: [BUG] r1976: Remove argumentless 'random'; pfo.spad

> AFAICS code using FSRED has design problem: due to random > choice we may reduce denominator to 0. I believe that > in such case we should restart computations using different > reduction. But current code just signals error (which is > definitely wrong). Yes, that should be the correct

Re: [fricas-devel] random from IntegerNumberSystem

> Current definition means that for positive n you get exactly n > values, each with probablility 1/n. Your proposed change would > break this nice relationship. For people who can not read > between lines we could add phrase: 'Error if n <= 0.'. Then the signature for random will be awkward:

[fricas-devel] random from IntegerNumberSystem

The document says: random : % -> % ++ random(n) creates a random element from 0 to \spad{n-1}. That is good if n is positive. What if n is negative? (2) -> random(-5) >> System error: Argument is neither a positive integer nor a positive float: -5 Also this definition can't

[fricas-devel] Re: [BUG] r1976: Remove argumentless 'random'; pfo.spad

> 1) The default value for nn is incorrect, and nn is not > updated after being used in K2Z. > > Actually, I think argumentless 'random' is a good idea. I misunderstood a little, my point is: 1) The default value of nn should not be 1. 2) We should use "1+random(nn)" in this case to avoid 0. --

[fricas-devel] [BUG] r1976: Remove argumentless 'random'; pfo.spad

I discovered this bug while I am digging another one: Martin's orignal integral: integrate((a + b*x)/((3 + x^2)*(1 - x^2)^(1/3)), x) fails. However integrate(1/((3 + x^2)*(1 - x^2)^(1/3)), x) succeeds while integrate(a/((3 + x^2)*(1 - x^2)^(1/3)), x) fails: (1) -> integrate(a/((3 + x^2)*(1 -

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

> You seem to want to use '>>' to convert functions from > T to Union(T, "failed") into functions from > Union(T, "failed") to Union(T, "failed"). No, it doesn't create new functions, just "combine" them. Say we want to apply a series of functions, first f, then g: x:INT, f:INT->INT, g:INT->INT

[fricas-devel] Fwd: Re: FriCAS web interface failure

This is from sci.math.symbolic, today: === Sadly, I am now finding that the FriCAS web interface refuses to respond after I submitted a pseudo-elliptic integral mentioned in a post of Sat, 20 Aug 2016 08:46:09 +0200 to another thread earlier today while forgetting to invoke

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

There's a long thread in 2011 talking about monad, but that discussion is not very clear and not what I am going to talk about. https://groups.google.com/d/msg/fricas-devel/UCFkQGgOOf0/oj9-FygocVgJ The motivation get me into this topic is simple: In OpenAxiom, I see there's a Maybe domain instead

Re: [fricas-devel] [PATCH] add a new interface for partialFraction; doc fix

A little more misc fixes and improvements for pfr.spad: https://github.com/oldk1332/fricas/commit/57f913c588bbdb970f50305ccb72e912586fcb2b.patch It's not included in the patch, but maybe it's better to replace "nil()" with "[]"? -- You received this message because you are subscribed to the

Re: [fricas-devel] [PATCH] add a new interface for partialFraction; doc fix

Updated patch: https://github.com/oldk1332/fricas/commit/b0fb558ecee4b387d45b7c210841003ebc832bb6.patch > It seems that we can add new funtion directly to PartialFraction, > without creating a new package. Fixed. > I am doing such things in lazy way: if looking at code there > may be doubt

Re: [fricas-devel] partialFraction is awkward

> Well, Spad compiler is supposed to accept program only when it > can deduce that the program is type correct. If Spad compiler > can not see that program is valid it should reject it. That's a good guideline for compiler. I'm assuming there's a lacking ability to assert:

Re: [fricas-devel] partialFraction is awkward

> Looks like compiler bug... For F : EuclideanDomain -- instead of Field UP : UnivariatePolynomialCategory F PFUP ==> PartialFraction(UP) I think it's impossible for compiler to assert if PFUP is valid, aka if "UP has EuclideanDomain" is true. I think compiler can't do that kind of check

Re: [fricas-devel] comments style for mathematical algorithms

https://github.com/oldk1332/fricas/commit/bcbcd7c3c6a604f025fbfcf1920d6c242893650c.patch documentation for subSylvesterMatrix = Since first edition of Symbolic Integration I: Transcendental Functions is available on archive.org, I'm using that as reference. -- You received this message

[fricas-devel] [PATCH] add a new interface for partialFraction; doc fix

https://github.com/oldk1332/fricas/commit/a7e1be2d9bbf176d8b97aa0e4d8d382417ada1b6.patch Futhermore, I want to remove the "global type declaration" of a,b,r,n in PartialFraction, opinions? After this patch, some examples: (1) -> partialFraction(1/18) 14 (1) ─ - ──

Re: [fricas-devel] partialFraction is awkward

> BTW, what do you think of adding > partialFraction(f:Fraction R) == partialFraction(numer f, factor denom f) > for R:UFD ? It should be R:Join(EuclideanDomain, UniqueFactorizationDomain) -- You received this message because you are subscribed to the Google Groups "FriCAS - computer

Re: [fricas-devel] partialFraction is awkward

> Looks like compiler bug... I'll document it in my bugtracker, and I'll try to solve this one. BTW, what do you think of adding partialFraction(f:Fraction R) == partialFraction(numer f, factor denom f) for R:UFD ? -- You received this message because you are subscribed to the Google

Re: [fricas-devel] [PATCH] allow "~" in )read )compile for SBCL

I can live with current situation, or apply this patch on my local machine. > ideally we would do all file access via system interfaces > avoiding Lisp functions. What's your opinion on using a lisp library, like cl-fad? http://weitz.de/cl-fad/ -- You received this message because you are

Re: [fricas-devel] partialFraction is awkward

> The problem here is that to have partial fraction decomposition UP > must be an EuclideanDomain. This happens if F is a Field, but > not if F is general EuclideanDomain. Yes, that's a stupid mistake. But I wonder why we can compile the wrong version without mistakes? -- You received this

Re: [fricas-devel] [PATCH] allow "~" in )read )compile for SBCL

> '~' is a shell convention. Our file access functions should > not prevent accessing file or directiory named '~'. > Nor should they require some strange quoting (which is > the case with shell). That's an odd choice. I think '~' is part of POSIX standard? Yes, in IO part, lisp and unix don't

Re: [fricas-devel] comments style for mathematical algorithms

> https://archive.org/details/ComputerAlgebraAndSymbolicComputation That book, actually I have a quote from that: We use a procedure style of programming that corresponds most closely to the programming structures and style of the Maple, Mathematica, and MuPAD systems and, to a lesser degree, to

Re: [fricas-devel] interesting video on the Fortress language

This is a recent video, so I didn't check for duplicate. Your link is from 8 years ago, that's interesting... > It's a pity that Fortress is no longer actively developed. Or is it? Seems it stoped 5 years ago. Guy Steel says he hopes some of Fortress's good ideas live in other languages in the

[fricas-devel] interesting video on the Fortress language

https://www.youtube.com/watch?v=EZD3Scuv02g The talker is Guy Steele, you may know him from his work on Scheme, Common Lisp, Java. Fortress in a lot of ways is similar to Spad, has similar things of Spad's Category. Some aspects of Fortress is even more strict than Spad. There's also some

Re: [fricas-devel] partialFraction is awkward

Just like the documentation of PartialFraction said: "For a general euclidean domain, it is not known how to factor the denominator." I think "partialFraction f == partialFraction(numer f, factor denom f)" is good enough for "UPOLYC(R:PFECAT)". Also the change for intden.spad should be OK: diff

[fricas-devel] comments style for mathematical algorithms

I'm making a standalone thread for this topic. > I would like to add some comments for subSylvesterMatrix, > I'd prefer add a reference to the book which this algorithm > is based on, like "-- Page 20, Definition 1.4.2, Symbolic > Integration Transcendental Functions, second edition", > instead

Re: [fricas-devel] [PATCH] fix an indexing bug in bezout.spad

> What bug are you fixing? First I thought that you corrected > problem with non-one based indexing. Yes, the original "maxC-minC-2*j" and "maxC-minC+1-i-j" is incorrect. There's another problem as your test shows: The minIndex of Row is minColIndex! The patch of patch is here: diff --git

Re: [fricas-devel] fricas_w32 : Hope for Windows 10 Users

> I've been thinking of it frequently. From time to time I try to compile it > using > Mingw64 (x86_64 Msys) or even Cygwin64 (x86_64 Cygwin). How did that go? Not successful? -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system"

Re: [fricas-devel] fricas_w32 : Hope for Windows 10 Users

Kurt, off topic a little, what do you think of a 64bit windows binary? > I was beeing imprecise above: I mean: can this "Linux subsystem" call > native Windows binaries? I know that it can run most Linux binaries. > The point is if it is an isolated sandbox or if it integrates with > Windows?

Re: [fricas-devel] Fwd: Shutter :: ltx2sxl

> with --enable-sixel-graphics (configure). Oops, I compiled xterm with "--enable-sixel", which is what https://github.com/saitoha/libsixel said. Now I compile it with "--enable-sixel-graphics" and it works. I guess you should open an issue for https://github.com/saitoha/libsixel . -- You

Re: [fricas-devel] Fwd: Shutter :: ltx2sxl

I still can't make xterm work, I configured .Xresources and xrdb it. But mlterm works well. It's really nice and interesting to have such things in terminal. (although I'll prefer emacs myself :) -- You received this message because you are subscribed to the Google Groups "FriCAS - computer

Re: [fricas-devel] Fwd: Shutter :: ltx2sxl

> Oh, apparently I've misdirected that mail. :) I thought you want to integrate this with FriCAS, to have image result of LaTeX output in terminal ... I used "xterm -ti vt340" and I got nothing. I'll try mlterm. -- You received this message because you are subscribed to the Google Groups

Re: [fricas-devel] Fwd: Shutter :: ltx2sxl

This is very interesting, however I can not make in work on xterm. I will try other terminals later. Which terminal are you using? -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop

Re: [fricas-devel] IndexedList

> Using list rarely is "optimal" from point of view of speed. When inseration is frequent, list is much better than array. Sparse polynomials use list instead of array. > I would much more encourage people to use profiler > and optimize code which is responsible for most of runtime. That's the

Re: [fricas-devel] IndexedList

> Indexing on list has it good uses and we should not forbid > it because abuse may lead to slow programs. We can still have "elt" from elsewhere, like EltableAggregate. In C++, for std::list, they have "advance", instead of "ls[n]". > Well, I against tying complexity to types. Types will not >

[fricas-devel] should TableAggregate be finiteAggregate?

Should TableAggregate be finiteAggregate? Most domains export TableAggregate also export finiteAggregate, except for GeneralSparseTable, but that should export finiteAggregate too. I don't think there's infinite table, just like there's no infinite list. So TableAggregate should like

Re: [fricas-devel] IndexedList

> I would even suggest we do the same, domains that export > IndexedAggregate must have constant time elt(%, n). More arguments to support this change: Currently LinearAggregate has IndexedAggregate, and LinearAggregate exports leftTrim/rightTrim which are implemented using indexing. So for

Re: [fricas-devel] IndexedList

> IndexedList is useful if somebody wants to port code which > uses differernt indexing. My point is, for List, one should not use index to get its element, because it's O(n) to do index. In C++, std::list does not have operator[], "all STL sequences that support operator[] should do it in

Re: [fricas-devel] [PATCH] make new$List faster

> Also, there is tricky balance > between speed and code size: for rarely executed code > the main cost is reading it from RAM and evicting > from cache more useful code. That can negate gains > from faster execution. Well, MAKELIST$Lisp is surely most RAM efficient and fastest. I want to know

Re: [fricas-devel] [PATCH] make new$List faster

> BTW: 'new' for lists exists mainly because of generic > interface. However normally after 'new' aggregate > is modified. In case of lists in almost all cases it > will be more efficient to create list in incremental way > using desired values instead of modification. You do have a point, I

Re: [fricas-devel] [PATCH] make new$List faster

I tested with "a := new(2*10^7,2)$List INT;", and before each call, I do a ")lisp (SB-EXT:GC)" to avoid GC during benchmarking. MAKELIST takes 0.29~0.33s, the loop takes 0.34~0.39s. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system"

Re: [fricas-devel] [PATCH] make new$List faster

> What is gain from this compared to: > > new(n, e) == [e for i in 1..n] It doesn't compile: compiling exported new : (NonNegativeInteger,S) -> $ ** comp fails at level 1 with expression: ** error in function new ((COLLECT (STEP |i| 1 1 |n|) |e|)) ** level 1 ** $x:=

[fricas-devel] [PATCH] make new$List faster

new$List calls Lisp function directly, instead of repeatedly calling "concat". This change and the previous map! change probably should go into IndexedList, but I really think we should remove IndexedList : 1. It's not used anywhere beside List. (And probably nobody uses it.) 2. Unlike arrays,

Re: [fricas-devel] [PATCH] use SVREF for 1-d array/vector

So only apply the change on array1.spad then? One finaly reason to use SVREF: according to https://sourceforge.net/p/sbcl/mailman/message/30609918/ it's 100x faster to compile SVREF than AREF. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer

Re: [fricas-devel] [PATCH] use SVREF for 1-d array/vector

> - We probaly should be testing speed after doing: > > )lisp (proclaim '(optimize (speed 3) (safety 0))) I can't believe that this is not the default! Adding it to my ~/.fricas.init . > Spad compiler normally only inlines operations > from list of selected domains. The list > is kept in Boot

Re: [fricas-devel] repeat map! definition in List makes it much faster

> My policy concerning optimizations was mostly reactive. > I look at profile data and try to eliminate expensive > part. This is List, the most basic data structure used everywhere in FriCAS, it's worth to optimize List whenever possible. > Spreading out copies in different places makes it

[fricas-devel] Re: QCDR is slower than CDR for SBCL

My bad, change the loop a little and it shows no difference: a0 := new(N,1)$List(Integer) for j in 1..N repeat for i in 1..1000 repeat QCDR(a0)$Lisp a0:=QCDR(a0)$Lisp -- You received this message because you are subscribed to the Google Groups "FriCAS - computer

Re: [fricas-devel] [PATCH] use SVREF for 1-d array/vector

This patch shows little impact on ECL, both barray0(10^6) and barray1(10^7) take around 0.64s. Is this patch good to go? -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving

Re: [fricas-devel] IARRAY1 based on PrimitiveArray

You are right, inheriting from PrimitiveArray isn't very useful. > Concerning map/map!: if we care about speed of them then we > need specialized version. But I am not sure if we care. Why not care about its performance? map! in IndexedAggregate uses indices(), which returns a List, costs much

[fricas-devel] IARRAY1 based on PrimitiveArray

I see this change in openaxiom, https://github.com/GabrielDosReis/open-axiom/commit/67f8ca75d03aad7f041d8650ddca4d4cd0b71371 It seems reasonable, but instead of remove map/map!, we should move it into PrimitiveArray. (BTW, map/map! in PrimitiveArray is from IndexedAggregate, much slower than

Re: [fricas-devel] Re: repeat map! definition in List makes it much faster

I think in this case Spad compiler can't do much about it: It generates a SPADCALL in general cases for "rest", and generates an inlined "CDR" for List. So the repeat of defination is unavoidable. (See the arrays, there's map! in OneDimensionalArrayAggregate, but those array domains repeat the

Re: [fricas-devel] FriCAS failed to build with ECL-16.1.2

> For me it works fine. Slightly strange is extension .cxx, looks > like your ECL is compiling things as C++. My version compiles > as C. Yes, after disable cxx support for ECL, it builds without this error. I'll find out if we can detect this case in configure. -- You received this message

Re: [fricas-devel] parallel build (make -j4) fails with clozurecl

It is strange. BTW, there's "Fatal error in "lisp" : Stack overflow on temp stack." buried in the error message. You can give one last try: build it in RAM-disk, it's a long shot though. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra

Re: [fricas-devel] parallel build (make -j4) fails with clozurecl

Add "all-boot" after "all-graph" makes it work ("make -j10" also works, I mean, past this src/boot stage). Don't know why: diff --git a/src/Makefile.in b/src/Makefile.in index 8dba991..95e419d 100644 --- a/src/Makefile.in +++ b/src/Makefile.in @@ -57,7 +57,7 @@ cd input && ${MAKE}

Re: [fricas-devel] parallel build (make -j4) fails with clozurecl

(src/lib), it went into different directories. make[2]: Leaving directory '/ssd/oldk1331/tmp/fricas/src/lib' cd lisp && make all-lisp ../config/mkinstalldirs /ssd/oldk1331/tmp/fricas/target/x86_64-unknown-linux/bin cd graph && make ../config/mkinstalldirs /ssd/oldk1331/tmp/fric

Re: [fricas-devel] partialFraction is awkward

> BTW: There is also PartialFractionUtilities package in 'intden.spad'. > ATM it is not general purpose: it exports what is needed by integrator. I think it only requires EUCDOM instead of Field in PartialFractionUtilities. I would like to have a partialFraction defined like this in

[fricas-devel] parallel build (make -j4) fails with clozurecl

ring read of memory address #x7FF8A79A5668 .. hundreds of the same line Fatal error in "lisp" : Fault during read of memory address #x7FF8A79A566Unrecoverable stack overflow. ? for help [13450] Clozure CL kernel debugger: /ssd/oldk1331/tmp/fricas2/src/scripts/build_helper: line 12: 13450

Re: [fricas-devel] [PATCH] use SVREF for 1-d array/vector

For clozurecl, barray0(10^6) is 1.20s (before), 0.51s (after). barray1(10^7) is 0.34s (before), 0.34s (after). No gain from "AREF to SVREF" change, but 5x faster than sbcl. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.

[fricas-devel] FriCAS failed to build with ECL-16.1.2

The build stops when compiling src/lisp/fricas-lisp.lisp, caused by those "fricas-foreign-call". Maybe because the FFI interface of ECL is changed? The error message is: ;;; End of Pass 1.In file included from /usr/include/ecl/ecl.h:82:0, from /usr/include/ecl/ecl-cmp.h:29,

Re: [fricas-devel] [PATCH] use SVREF for 1-d array/vector

"for" loop in REPL is insanely slow, shows no difference. Is this benchmark good enough? )abbrev package BENCH1 Bench1 Bench1() : Exp == Impl where Exp == with barray0 : PositiveInteger -> Void barray1 : PositiveInteger -> Void bvector0 : PositiveInteger -> Void

[fricas-devel] partialFraction is awkward

partialFraction from Domain PartialFraction(R) is: (R, Factored R) -> % It's not easy to use, so in PartialFractionPackage(R), there are wrappers: partialFraction : (Fraction Polynomial R, Symbol) -> Any It deals with POLY, not UPOLYC; and because of that, it can't determinate return type

Re: [fricas-devel] 3 misc fixes

I wonder what's the reason to support such old sbcl? To support hardware other than x86? -- 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

Re: [fricas-devel] [PATCH] doc fix and misc simplification in float.spad

My point is, base 2 and IEEE format can make sure DFLOAT in FriCAS is hardware accelerated, like MachineInteger, U32Vector, etc. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop

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

> For exact exponsnts it should give 1. One more fix for ^(DFLOAT, FRAC INT) : diff --git a/src/algebra/sf.spad b/src/algebra/sf.spad index 28af4bb..b7e5cf3 100644 --- a/src/algebra/sf.spad +++ b/src/algebra/sf.spad @@ -613,7 +613,7 @@ x : % ^ r : Fraction Integer == zero? x => -

[fricas-devel] 3 misc fixes

Backported from openaxiom. 1. Ring already has Monoid 2. OrderedRing already has abs 3. sb-ext:quit is deprecated for a long time diff --git a/src/algebra/catdef.spad b/src/algebra/catdef.spad index 5a7b371..ce919f6 100644 --- a/src/algebra/catdef.spad +++ b/src/algebra/catdef.spad @@ -1061,7

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

What's the right thing to do? (1) -> 0.0 ^ (0::NNI) (1) 1.0 Type: Float (2) -> 0.0 ^ (0::INT) >> Error detected within library code: 0^0 is undefined (2) -> (0.0::DFLOAT) ^ (0::INT) (2) 1.0

[fricas-devel] [PATCH] use SVREF for 1-d array/vector

https://github.com/oldk1332/fricas/commit/2a16e6ac7739f15a4b77f5908b6f4ae299680008.patch use SVREF for 1-d array/vector -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving

Re: [fricas-devel] [PATCH] doc fix and misc simplification in float.spad

Just checked, sbcl, clisp, gcl, ecl all return 2 for float-radix. Maybe we should check float-radix and :IEEE-FLOATING-POINT in *FEATURES* in configure script. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe

Re: [fricas-devel] [PATCH] doc fix and misc simplification in float.spad

> Note that 68 bit accuracy corresponds to 20 decimal digits, so > current doc is correct in this aspect. OK, I mistake "bits()" for "digits()". I found that documentation for "precision()" is vague: In sf.spad: precision : () -> PositiveInteger ++ precision() returns the precision in

[fricas-devel] [PATCH] doc fix and misc simplification in float.spad

https://github.com/oldk1332/fricas/commit/4bb7c14831c51fdc0bc46a9dc6742f16e8be0926.patch doc fix and misc simplification in float.spad -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop

[fricas-devel] [PATCH} backport fixes on tree.spad from openaxiom

https://github.com/oldk1332/fricas/commit/29b56342a3f58cf0555e6048f9a04c7a18fcfb1e.patch backport fixes on tree.spad from openaxiom In Domain Tree: fix bug of map! remove global type declaration remove unnecessary type predicate remove unnecessary return BTW, the Changelog entries of

Re: [fricas-devel] commit message format

> Commit messages with a subject line and a clear explanation of the WHY > in the following lines are *much better*. I agree with that. I guess people get lazy sometimes :( I'll do better in the future. -- You received this message because you are subscribed to the Google Groups "FriCAS -

Re: [fricas-devel] Silent dependencies and array packs

> Possibly. Theoretically QVELT should be very fast, but > in the past test showed that QREFELT is faster, so we > use it when speed matter. The difference between QVELT and QREFELT is a fixnum declaration, but that doesn't make a difference in my benchmark. > Note that 1-based cases uses

Re: [fricas-devel] [PATCH] fix "make clean", especially for src/doc/

The reason I start this patch is after "make clean", I do a "git status", and have many files undeleted, especially under src/doc/ . The reason to add "-f" is because, especially in src/algebra, without "-f", it will generate hundreds lines of warning: "rm: cannot remove 'xxx.spad': No such file

[fricas-devel] [PATCH] fix "make clean", especially for src/doc/

https://github.com/oldk1332/fricas/commit/3530cc35f6ad8ae4a09861690eb309e58bee5b6f.patch fix "make clean", especially for src/doc/ -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop

Re: [fricas-devel] changes on vector.spad in openaxiom

So, only remove "if R has OrderedRing then OrderedRing" and add "if R has AbelianGroup then AbelianGroup" then? (what about those semi/nonassociative-group/ring, it's a mess.) -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.

Re: [fricas-devel] changes on vector.spad in openaxiom

Yes, you are right, definitely not OrderedRing. -- 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.

Re: [fricas-devel] Silent dependencies and array packs

I read CLTL2 chapters about arrays, so: In common lisp, vector is 1-d array. And quote: "svref may be faster than aref" So there's no reason to use ELT in array1.spad. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To

[fricas-devel] changes on vector.spad in openaxiom

https://github.com/GabrielDosReis/open-axiom/commit/cffd2746785e6b40b8d4f2b44ab0b4a936cd6f24#diff-acc6991b17dbbd44b4000f0b427a5712 https://github.com/GabrielDosReis/open-axiom/commit/1bfecf3e58163305cb5753caab462ed57d0d67fc#diff-acc6991b17dbbd44b4000f0b427a5712 I don't quite understand the

Re: [fricas-devel] Silent dependencies and array packs

OK, the '<' specialization for INT/NNI/PI instead of SPADCALL speed things up a lot. Now, I removed the comparison to benchmark only array indexing performance: x < y == print("<"::OutputForm) for i in 0..(dim - 1) repeat a

Re: [fricas-devel] Interpreter type reconstruction

> also gives Polynomial(Integer). So you have to add several > coercions and for user it is not clear where to add them. The reason may be that interpreter treats POLY specially, and those rules don't play well with new NSMP. Do you have plans to fix this situation? -- You received this

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

Second thought: this idea itself is an ugly hack anyway: Take the Product example: You can't enumerate all the categories. This "type propagation" thing has to be done in compiler. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system"

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

> Record and Mapping does not propagate properties like > this. Yes, Record is basic data structure, unlike Product which has semantic meaning. I think Mapping should have some of type propagation: Mapping(A:Type,B:AbelianSemiGroup) is a AbelianSemiGroup too. > 1) DirectProductCategory has one

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

> Why not let MetaCatagory propogate all categories that satisfy the conditions? Which conditions? All of them? Well, there are cases that "R has X, but % doesn't has X". By the way, the example I gave compiles (with little tweak), but seems have serious run time problems. -- You received

Re: [fricas-devel] Silent dependencies and array packs

Some observations: 1. In this case, types other than INT/NNI/PI can use QREFELT instead of qelt and gain speed? (test with FRAC INT, 15% faster) 2. In qelt/elt of Vector/ARRAY1, we can use QREFELT instead of ELT? 3. Old question again: is it useful to support arbitrary indexed array? (no

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

Hmmm, Ralf may be right, we still need an additional argument to limit which categories to propagate, that makes the definition of "MetaCategory" impossible? Don't know if following works... MetaCategory(R : Type, Range : Type) : Category == add if R has X and Range has X then X

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

In DirectProductCategory there are many "if R has X then X", and in domain Product, there are many "if A has X and B has X then X". And this situation can be found elsewhere: for example, Record, or a category "Mapping" that exports functions that can operate on functions. I propose a new

[fricas-devel] [PATCH] fix compare for DirectProduct(dim:NNI, PositiveInteger)

https://github.com/oldk1332/fricas/commit/a1aef4aeba6092a5525d70e772e75a1e182957b7.patch 1. remove QLESSP, without it, generate exact same code. 2. add "if R has OrderedSet then OrderedSet" in DirectProductCategory, to make DirectProduct(2, PI) has exports of '<'. 3. allow those speed hacks for

<    4   5   6   7   8   9   10   11   12   >