Found it, it is r1809, or
https://github.com/fricas/fricas/commit/d400d8b480a6a6a006224e573b8b6f8ba00143ed#diff-d19c92e750823c21e6ec814d559cd225
Commit message: Fix a thinko
index f8be367..f5bd960 100644
--- a/src/algebra/intalg.spad
+++ b/src/algebra/intalg.spad
@@ -300,7 +300,7 @@
The integral causing this bug is from here:
http://12000.org/my_notes/CAS_integration_tests/test_cases/hearn/resu28.htm#280
t:=sqrt(1-5*x-5*x^2)/sqrt(1-x-x^2)
f:=(1+2*x)/x/(1+x)/(2+x)*t
integrate(f, x)
returns unevaluated results, meaning it does not have an elementary result,
On Wednesday, October 28, 2015 at 11:16:10 AM UTC+8, Alasdair wrote:
>
> Better FriCAS in a console:
>
> (1) Download and install rlwrap
> (2) put the attached file somewhere in your path and make it executable
> (this is a copy of the "rmaxima" command with very slight changes)
> (3) run
I encountered the same bug described in:
https://groups.google.com/d/msg/fricas-devel/hHd9C1aY30U/UxZeg1gNkcEJ
Namely, the simplest case is:
(1) -> radicalSolve([y-x])
(1) [[y= y]]
Type:
List(List(Equation(Expression(Integer
(2) -> radicalSolve([y-x=0])
> BTW, a few examples which shows that it not obvious what
> proposed simplification should do:
>
> exp(log(x)*log(y)) ==> x^log(y) ???
> exp(b*(log(x) + log(y)) ==> (xy)^b or x^by^b ???
> exp(b*atanh(x)) ==> ((1 + x)/(1 - x))^(b/2) ???
> exp(a*b) ==> exp(a)^b ???
At least we can safely
So, the right behaviour for 'radicalSolve([y-x])' and
'radicalSolve([y-x=0])' is they should call
'radicalSolve([y-x], [y, x])', which has a implementation
bug. We should based on these behaviour to fix their
documentation and implementation?
--
You received this message because you are
> On Tuesday, November 17, 2015 at 8:39:55 AM UTC+8, Alasdair wrote:
>
> intm(xs,a,b)==
> g:=(x:Float):Float+->mult(xs)
> return(numeric(integrate(g(x),x=a..b)))
Your description and example is not very clear to me. It seems like
that you would like to "do numerical integration of the
The first place you should check is The Axiom Book
(Jenks and Sutor), see the GRAPHICS chapter.
Colors are provided by Domain COLOR, see ')show COLOR'
for its operations. Namely, red(), yellow(), green(), blue(), +, *.
See also ')show PALETTE'.
As for 'draw', pass 'pointColor==red()',
The bug
is:
q := simplify
(3^(1/2)*3^(1/3)*3^(1/6))
returns
Another integration bug may related to
r1156:
f2:=
1/(x^3+3*x^2+3*x)/(x^3+3*x^2+3*x+3)^(1/3)
integrate(f2,
x)
The bug also happens in the function bellow that:
delete!(x : %, i : UniversalSegment(Integer))
==
(l := lo i) < (m := minIndex x) => error "index out of
range"
This bug also happens in the function before delete!:
remove!(f : S -> Boolean, x : %)
==
while not empty? x and f first x repeat x := rest
x
> Looks good. Can you provide real name to put in commit
> message?
Thank you for accepting this patch, you can put "Qian Yun"
in the commit message.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from
OK, after some debugging, I have made a patch:
--- a/src/algebra/manip.spad
+++ b/src/algebra/manip.spad
@@ -349,7 +349,7 @@ AlgebraicManipulations(R, F) : Exports ==
Implementation where
rootKerSimp(op, x, n) == inroot(op, x, n)
-- l is a list of nth-roots, returns a list of records
tanint is no longer used in intpar.spad, or anywhere.
It can be safely removed.
--
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
I believe this simplification is missing in Fricas, where should
we implement it? In simplifyExp in manip.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 receiving emails from
You can try:
reduce(+, [a[n]*x^n for n in 0..10])
10 9 8 7 6 5 4 3 2
a x + a x + a x + a x + a x + a x + a x + a x + a x + a x + a
10 9 8 7 6 5 4 3 2 1 0
> and then the command
>
> )sh Bad
> fails with an "index error".
Bill, see my other thread:
"index out of range" error when ')dis op integrate'
at https://groups.google.com/d/msg/fricas-devel/MxMggEnkef0/lay5VBecEgAJ
At least you can ')sh Bad' without error now.
--
You received this
"index out of range" error happens when
')dis op integrate' or ')show UnivariateFormalPowerSeries'
This bug is introduced in r1860, or
https://github.com/fricas/fricas/commit/ef870e58d134d640e6bf47a1a58f8e8ecbbb44aa
Revert part of this commit in trunk can fix this bug, I have narrow it down
to:
> Does it handle the following?
>
> r1 := sqrt(x)
> r2 := x^(2/3)
> r3 := x^(3/4)
> r12 := x^(1/12)
> simplify(r1*r2*r3*r12)
> --
> Waldek Hebisch
>
No, it does not. I make a change in the patch:
--- a/src/algebra/manip.spad
+++ b/src/algebra/manip.spad
There is theorem that "Every principal ideal domain is a unique
factorization domain."
But in Fricas, "PrincipalIdealDomain has UniqueFactorizationDomain", or
"PID has UFD",
returns false.
In catdef.spad, we can find PID and UFD are both constructed from GcdDomain:
(comments removed)
On Monday, October 12, 2015 at 8:14:12 PM UTC+8, jg wrote:
>
> No!
>
> unitsKnown is a property which a concrete implementation of a Monoid
> shares or does not share!
> See, what is written in the definition of this attribute:
>
> )abbrev category ATUNIKN unitsKnown
> ++ Description:
> ++ The
First, I find that
Group() : Category == Join(Monoid, unitsKnown) with ...
But, shouldn't Monoid have unitsKnown, either?
If ture, shouldn't
recip : % -> Union(%,"failed")
move into unitsKnown?
--
You received this message because you are subscribed to the Google Groups
"FriCAS -
FYI, there is also an Emacs extension axiom-environment [1], which is
very nice and it has Org-mode support: ob-axiom.
The Risch algorithm implemented in FriCAS is still incomplete, there are a
few holes
in the mixed algebraic-transcendental case.
There is a right parenthesis missing in "(12)
> Could you enlarge on the Risch algorithm? I always assumed that Axiom
> had a complete implementation, but if not I'd want to be put right.
First, according to my research, the theory of integration, aka Risch
algorithm,
is still not complete.
Although Risch published his "algorithm" around
I never run FriCAS on OSX either, but according to your description,
he should check the value of shell variable "AXIOM", and it should be
set by "export AXIOM=prefix/FriCAS.app/Contents/Resources/".
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer
He should probably check the "AXIOM" written in file
FriCAS.app/Contents/Resources/bin/fricas
and fix it.
--
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
The default values are defined in src/hyper/hyper.h:
#if defined(RTplatform) || defined(PS2platform) || defined(RIOSplatform) ||
defined(AIX370platform)
#define RmFontDefault "Rom14"
#define TtFontDefault "Erg14"
#define ActiveFontDefault "Bld14"
#define fricas_font_default
Thanks for your informative replies, Waldek Hebisch.
I have a question related about Risch algorithm and its
implementation in FriCAS.
I asked my math professor about Risch algorithm before,
he never heard of it and he seemed to not care about it,
because "numerical methods are enough, nobody
Nope, that only works in one place, better put the
ENV var in top level:
diff --git a/Makefile.in b/Makefile.in
index d30f52b..16376c5 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -17,6 +17,7 @@ FRICAS_SRC_TARGETS = all-algebra all-asq all-axiomsys
all-book all-boot \
all-lib all-lisp
The default window size is really small, I changed it
to 1000x600, which is not large either. What value
do you think is a better default?
diff --git a/src/hyper/initx.c b/src/hyper/initx.c
index 5950f89..d640869 100644
--- a/src/hyper/initx.c
+++ b/src/hyper/initx.c
@@ -276,5 +276,5 @@
interpsys doesn't accept command line options, so
I make this change by using environment variable.
diff --git a/src/algebra/Makefile.in b/src/algebra/Makefile.in
index fbdde26..86deaf4 100644
--- a/src/algebra/Makefile.in
+++ b/src/algebra/Makefile.in
@@ -428,7 +428,8 @@ stamp-db: $(patsubst %,
> In X environment default is supposed to be easily
> changable by the user in .Xdefaults. It is probably
> better to make sure that this works and document
> how to do this.
I think .Xdefaults is obsolete, people use .Xresources
nowadays.
I tested and in ~/.Xresources, these values works
The default behaviour of "SquareMatrix(n, FRAC INT) * INT"
is to treat the INT as DirectProduct and return DirectProduct:
y := [[1,2],[3,4]];
Type:
List(List(PositiveInteger))
y::SQMATRIX(2,FRAC INT)*1
(2) [3,7]
minRowIndex returns INT, but one of subMatrix's signature is:
[1] (D1,List(PositiveInteger),List(PositiveInteger)) -> D1
That means subMatrix can't take matrices that with negative
index. One way is to fix subMatrix to let it take LIST INT
as arguments, but I want to go with the other way.
I
> in i-funsel.boot
>
> https://github.com/fricas/fricas/blob/master/src/interp/i-funsel.boot#L629
That's an interesting finding, where the magic of priority of type
lifting is.
> Perhaps it was an
> experiment inherited with the original Axiom source?
At least not in the open source Axiom, I
This is some kind of a milestone, right?
Congratulations to the hard working FriCAS development team!
--
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
OK, I'll fix subMatrix to allow LIST INT, I'm doing that,
which means almost all signatures in mama.spad
need fixing.
Meanwhile, new problems:
rows(A:M, lst:LI) : M ==
nc := ncols(A)
nc = 0 => zero(#lst, nc)$M
Should we allow matrix that have zero rows or zero columns?
You beat me to it :)
However, the bug caused by arbitrary indexed matrix is
still there:
diff --git a/src/algebra/mama.spad b/src/algebra/mama.spad
index 33a6a32..9dd7a38 100644
--- a/src/algebra/mama.spad
+++ b/src/algebra/mama.spad
@@ -114,7 +114,7 @@
rows(A : M, lst : LI) : M ==
I'm a little confused: don't you think this is a bug in interpreter,
of the part doing automatic type lifting? And should be fixed
there?
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and
I have a few questions.
After remove "a = b == trueEqual((a-b)::Rep, 0::Rep)"
from AlgebraicNumber, where does the default implementation
of = come from?
I would like to see '(sqrt(6) = sqrt(2)*sqrt(3))@Boolean' remains
true, I also want to know why 'sqrt(2)*sqrt(3)' doesn't return
sqrt(6)
> Other than TYPE, no domain has zero operation exported, I think?
I think that's still true, meanwhile lots of categories export zero
operation:
e.g. shallowlyMutable.
The patch works for those categories too.
diff --git a/src/interp/i-syscmd.boot b/src/interp/i-syscmd.boot
index
>From last discussion, I think you should use at least 3GB heap,
try "--dynamic-space-size 3000" or more.
--
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
> I don't understand. I do not see a "fricas native breaking domains".
What I meant is that I remember Waldek said he wanted such
domains as a solution.
So, the reason your latex output mode is not commited is that
texbreak is used on wiki and we won't break it?
Summing-up:
1. tex + texbreak.
I'm glad that now I have keep up with the whole discussion.
> I don't think that this is the task of FriCAS. Where would you break a
> TeX-Equation?
Where would breqn or other systems break a (no tex here) equation?
texbreak can break axiom's subset tex equation,
breqn can break latex
- > Long lines aren't broken.
-
- FriCAS don't have support for automatically breaking long equations, and
- I doubt other CASs can. That means, if a result looks messy in terminal,
- it will be messy in other output backends.
-
- For this particular integration, complexIntegration gives a
The old discussion is here:
https://groups.google.com/d/msg/fricas-devel/gZVOu2R9K8s/fQertUJn8c0J
(4) -> unparse((1..3)::INFORM)
(4) "1..3$Segment(Integer())"
Type:
String
Mine fix is:
index b582869..877f181 100644
---
I wrote one for you. Apply the following patch and it should be ok.
But like I said before, I breqn hangs on "integrate(sqrt(x^2+1)/(x^4+1),
x)".
"(x+y+z)^10" works fine for me.
--- fricas.el
+++ fricas.el
@@ -165,4 +165,5 @@
(defvar fricas-TeX-preamble (concat "\\documentclass{article}"
FYI, add "\\Large" after "\\begin{preview}" to make math font bigger.
--
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
This is an interesting bug.
Minimal example to recreate this bug:
(1) -> u := sqrt(2*tan(x))
┌───┐
(1) \│2tan(x)
Type:
Expression(Integer)
(2) -> f := atan(u+1+sqrt(1+(u+1)^2))-atan(u-1+sqrt(1+(u-1)^2))
(2)
> Our solvers transform
> system of equations into triangular form. If system is zero
> dimensional (has finite number of solutions) than current
> method works OK. We have problem in case of higher dimensional
> solution set.
I noticed that too, 'triangularSystems' uses 'groebSolve'
I find this when I am debugging the bigger issue with radicalRoots,
but I will post about that later when I'm finished.
(125) -> radicalRoots([z],[y,x])
(125) []
Type:
List(List(Expression(Integer)))
The answer is correct, but it's not returned from
The bug is:
(1) -> radicalSolve([x-y],[x,y])
(1) [[x= x]]
Type:
List(List(Equation(Expression(Integer
(2) -> radicalRoots([x-y],[x,y])
(2) [[x]]
Type:
List(List(Expression(Integer)))
(3) -> solve([x-y],[x,y])
> This is what imaxima (maxima running in Emacs) does, and it works pretty
well.
Sorry, I don't know about such things before.
This is an interesting feature to have. There were discussions about breqn,
I will look into them later.
--
You received this message because you are subscribed to
> Well, with '$tryRecompileArguments := true' all files should
> compile, but compilation may be quite slow
Yes, a few domains that set $tryRecompileArguments to nil is
extremely slow when compiling.
> But if you want to compile
> file containing multiple constructors than adding
>
> Second, can the dependencies discovered by differentiation
> be fully utilized? e.g, if D(f,x)=0, can we get the simplified f
> without variable x? If not, at least a heuristic version can be
> written relatively easily.
>From D(f, x)=0 to compute f, is equal to, for example,
Waldek:
I don't understand, with patch in mail, don't
you have to cut and save it first, before you
apply it? I thought it would be easier to
fetch patch directly from github using wget.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra
Negative integer number should be considered as "atom" in parsing,
so the prefix representation of INFROM "(^ - 1 (/ 1 2))" is OK, the problem
is inside unparse:
unparse x ==
atom?(s : % := unparseInputForm(x)$Lisp) => strsym s
concat [strsym a for a in destruct s]
Yes, you are right, I've fixed symFunc to match its description.
The next problem is to fix TANEXP accordingly, which I'll do
later. But now is the problem of document it:
Take tanPIa for example, tanPIa returns a FRAC SUPR,
which has this property:
tan(n*x)=tanPIa(n)(tan x)
tanNa is a
https://github.com/fricas/fricas/commit/9b62873dfb986f9b5f909254f31a0f4fa2b05421.patch
fix symFunc to match its document
fix TANEXP which depends on symFunc
I didn't find a proof or a webpage containing the
algorithm/equation used by fricas, which I would
like to add such a link into comment.
https://github.com/fricas/fricas/commit/18bc5c48fb5ed0d5ae46fc6065f133822d44f6ee.patch
fix a local function's signature, white space cleanup
https://github.com/fricas/fricas/commit/714ea60f49193fb1013f0a378522bda5977625b7.patch
improve package SymmetricFunctions
Additional inforamtion: source code of triangularSystems is:
triangularSystems(lf : L F, lv : L SE) : L L P R ==
empty? lv => empty()
empty? lf => empty()
...
empty()$List(List something) is [] and is not equal to list [].
--
You received this message
I don't understand what you mean...
> The empty() after the => sign is (if there is no bug) interpreted as an
> element of L(L P R).
The empty() element of L(L P R) is "[]", not "List []" aka "[[]]".
Thus "parRes= list []" is never going to be true. I just added
a printing expression after
The attachment patch contains a few typos I fixed,
or you can see them here:
https://github.com/oldk1331/fricas/commit/4528e2285834492f7b2a11f55d563260fd8813b7.patch
Apart from that, there's a pair of missing quotes should be
added in configure.ac, in case fricas_lisp contains parameters.
diff
And I noticed that footnote in efstruc.spad and other
related files are outdated. Should it be removed or
updated?
--
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
> Namely, eventually we want
> to convert Boot files to Spad.
Out of curiosity, I want to ask:
I remembered about the thread about rewrite interp/ in spad
from long time ago, so this is still a thing? But no roadmap,
no ETA?
I think make fricas bootstrap itself is very interesting, and
https://github.com/oldk1331/fricas/commit/7eb402cfc06a4a1f07903f63889c895b6be1.patch
typo fix for doc/ config* Makenotes.tex
A related question: the various *.tex files in FriCAS source tree
are seriously outdated, some of them can be deleted, some of
them may still contain important
https://github.com/oldk1331/fricas/commit/65ccdd6b1100b877572657448c7eb632dffeb357.patch
typo fix for README/FAQ/INSTALL
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop
> it is best to return answers from
> main branch of code. Extra branches are for cases which are
> inconvenient to treat on main branch. In this case it seems
> that extra branch for empty list is not needed at all...
Well, in this case, empty list is kind of a special case, and
I didn't experience this failure before, only recently, because
I added "outputSpacing 0;" into ~/.fricas.input recently.
No matter what, during build process, interpsys/AXIOMsys
should not read ~/.fricas.input. And FriCAS should have a
command line option to disable load user init file at start
> So, the problem is in unparseInputForm.
Ah, thank you for pointing that out.
So, in src/interp/format.boot,
unparseInputForm calls ...
form2String1 calls
binop2String calls ...
powerOrParen calls ...
appOrParen
The patch is following:
index b582869..7e16e1c 100644
---
> I'm not sure if this patch creates unnecessary parenthesis elsewhere.
One change I noticed is "unparse(( t-1 )::INFORM)", it used to be
"t+-1", after patch it's "t+(-1)", is it a bug that it doesn't return "t-1"?
--
You received this message because you are subscribed to the Google Groups
OK, I get it now. You can commit the parts you feel
comfortable, and I will following the standard in the
future.
--
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
So, this is how I summarize it:
1. Short patch, ready to commit: post it in mail.
2. Long patch, ready to commit: post in attachment or post
with a link to the patch that can be directly downloaded.
But if there a is a long patch (set) needs discussion and
refinement, hence needs to be
First, thanks for your informative response, I learn a lot
from it and other messages you posted before. I want
to know if you can put "appropriate portion" of your mail
into comments of source code, to document the limitation
of current code, so people who stumble into source code
can get
Would you mind if I put patches (commits) to a branch on github
in the future?
--
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
One example is that you can not compile efstruc.spad twice,
the second compilation gives error that makes no sense.
(not posting it here)
This have something to do with $tryRecompileArguments.
It seems that it improves compilation speed, and used in
a dozen packages.
I don't know what's the
To Martin:
> As far as I remember, efricas does support latex.
Yes, the latex support works, the problem is breaking long equations.
And to Ralf:
I see your long discussions over past few years, so what's current
status? We still have a disagreement about texbreak, breqn, or
fricas native
I was looking at polynomial remainder sequence related parts
of FriCAS, and I find there are some improvement space.
I'll use PRS for "polynomial remainder sequence", not to be
confused with package PseudoRemainderSequence.
1. PRS parts in FriCAS:
package PRS in prs.spadby Ducos Lionel
Can we exit FriCAS by press Ctrl-D in terminal?
If not, where can we add it, sman or clef or
somthing else?
--
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,
https://github.com/oldk1331/fricas/commit/feb5c243a471ce24dc1e614b923129be58607cd0.patch
add missing function hash for Tree,
add missing function hash, map, distance for BinaryTreeCategory,
where distance is copied from Tree.
diff --git a/src/algebra/tree.spad b/src/algebra/tree.spad
index
> At first glance I can not see if it is wrong or not: it depends
> on intent of original writer. I suspect that the intention was
> to use this code only for sparse sets.
See the patch that changes Rep of BinaryTree in the other
thread, I think the intention here was for this BinaryTree
> As long as you limit yourself to simple cases like
> roots of rational numbers this can be made to work.
> I do not see how could you generalize this to
> roots of arbitrary polynomials which are handled
> by current AlgebraicNumber.
This change is fine for me. We can add simplification
AC_SUBST doesn't work either, config/var-def.mk
is the right place to go.
I also add a AC_MSG_CHECKING in configure.ac.
Waldek, if this FRICAS_INITFILE is accepted,
src/doc/htex/ug04.htex also needs updating.
Also, there should be an entry for .fricas.input in FAQ.
diff --git
You are right about the space consumption:
(1) -> y := binarySearchTree [3,2,6,4,5,1]
(1) [[1,2,.],3,[[.,4,5],6,.]]
Type:
BinarySearchTree(PositiveInteger)
(2) -> y pretend SEX
(2) ((0 3 (0 2 (0 1))) (0 6 (0 4) (0 5)))
See previous discussion here:
https://groups.google.com/d/msg/fricas-devel/rgwdpoPQHEA/ZCwDQIEtn5MJ
The objections discussed in previous thread that
)savesystem should be removed is:
1. ECL doesn't support it.
2. problems with frames.
But I find a really useful use case for )savesystem:
Not familiar with autotools, but configure.ac is a
better place to export ENV var than Makefile.in?
FRICAS_NOINIT="yes"
AC_SUBST(FRICAS_NOINIT)
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group
> The argument for evalDomainOpPred is complicated
> ( htpProperty(htPage,'domname) ), I don't know how to fix this problem
> further.
Oops, the argument for evalDomainOpPred is not complicated
at all, it's just (eval '(|List| (|Type|))) .
But still, this bug took me a long time to fix.
First,
Compared with previous thread, I've rebased and added a few new fixes.
https://github.com/oldk1331/fricas/commit/827b326b44b6dd736e56051ec073b7d123d9c836.patch
typo fixes.
https://github.com/oldk1331/fricas/commit/4154e620f7d2cded77df760ed037be802bec718f.patch
documentation fixes.
diff --git
For the first one, it's a tiny bit more efficient, and it's indeed
a special case and deserve a special check.
For the second one, other functions' signature are written
twice, it's inconsistent to just remove for findQRelation.
--
You received this message because you are subscribed to the
> similar problem, how to interrupt a running computation in FriCAS 1.2.6 ?
> (vs. FriCAS-1.2.6-x86_64-macos10.6.tar.xz)
You mean Ctrl-C doesn't work on Mac OS X?
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To
Currently the Rep of Queue is List, thus enqueue! an
element into the end of list is O(n) not O(1):
(1) -> )time on
(1) -> x := queue (new(1000,1)$List Integer);
Type:
Queue(Integer)
Time: 0.00 (IN) + 2.10
(56) -> PositiveInteger has KONVERT(INFORM)
(56) false
Type:
Boolean
(57) -> queue([1,2,3])::INFORM
Cannot convert the value from type Queue(PositiveInteger) to
InputForm .
(57) -> queue([1,2,-3])::INFORM
(57)
> changes order in which map processes elements. AFAICS classic version
> which keeps pointer to the last element does not have this problem.
I don't understand, what do you mean? what pointer?
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer
OK, so you think map should process from the first to the last?
Previous Rep doesn't have a pointer to the end, right?
You agree with this change mostly, right?
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe
One more discussion about the map:
In Scheme, (map f ls) doesn't specify the order,
f should be functional (non-destructive, no IO), thus
the order doesn't matter. And it also opens the gate
for parallel map optimization. On the other hand,
(for-each f ls) follows the order and f considered
Interesting question: should map on Dequeue follow
a order? If yes, then from top to bottom or the other
way around?
--
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
OK, I got what you meaning: speed regression.
I'm not familiar with the test stuff, so I want to ask:
I think src/input/ doesn't support speed comparison,
so you compare *.output with previous ones manually?
--
You received this message because you are subscribed to the Google Groups
"FriCAS
One reason I didn't think of )library is that
)help didn't show it, fricas 1.1.3 shows:
Other help topics
Available help topics are:
abbreviations assignment
I tested with TeXmacs after this modification, it works fine.
BTW, there are two one-liner patch that we've discussed,
can you commit them:
index c836157..3e6be5f 100644
--- a/src/algebra/solverad.spad
+++ b/src/algebra/solverad.spad
@@ -221,5 +221,5 @@
radicalRoots(lp : L RF, lv : L
1 - 100 of 1198 matches
Mail list logo
