t;
>> It doesn't have much to do with GitHub, it's git that you need to know a
>> bit about.
>> GitHub is just a hosting platform for git repositories.
>>
>> HTH
>> Dima
>>
>>>
>>> --Nasser
>>>
>>> On Saturday, April 20,
I don't think it can be totally Lisp-agnostic:
> SBCL does not allow embedding in the way ECL does (It's Embeddable
> Common Lisp for a reason...)
>
> Dima
>
>
> >
> > Martin
> >
> > On Thursday 18 April 2024 at 23:53:10 UTC+2 Dima Pasechnik wrote:
> >
Dear all & especially Dima!
Here is a thread from a previous attempt that might be useful:
https://groups.google.com/g/fricas-devel/c/qYzrY-92Q2A/m/P49CneVKAQAJ
I think it would be best to start with an ECL interface, I would expect
this to be easier and would probably cover a lot of use
On Thursday 18 April 2024 at 23:53:10 UTC+2 Dima Pasechnik wrote:
On 18 April 2024 21:51:34 BST, 'Martin R' via FriCAS - computer algebra
system wrote:
>OK, I think I have to give up. The InputForm consists of 23 964 324
>atoms. I guess that there is no sensible way to transmit this,
e-size)
>>> 1073741824
>>> )version
>>> FriCAS 2022-07-16 compiled at Fr 12 Aug 2022 15:17:27 CEST
>>>
>>> I'm currently compiling the ECL version.
>>>
>>> Unfortunately, because of the MacOS problem (
>>> https://github.com/s
>> I'm currently compiling the ECL version.
>>
>> Unfortunately, because of the MacOS problem (
>> https://github.com/sagemath/sage/pull/37041) most sage users won't use
>> the newest FriCAS. So I'll first check whether that makes a difference.
>>
>> M
problem
(https://github.com/sagemath/sage/pull/37041) most sage users won't use the
newest FriCAS. So I'll first check whether that makes a difference.
Martin
On Thursday 18 April 2024 at 18:11:21 UTC+2 Waldek Hebisch wrote:
> On Thu, Apr 18, 2024 at 08:45:53AM -0700, 'Martin R' via Fri
I started to look into one of the problems
(https://github.com/sagemath/sage/issues/37813):
res := integrate((x^2+1)^(1/2)/(x^2+(x+(x^2+1)^(1/2))^(1/2)), x);
works nicely, but converting to InputForm (which I use to do the
translation to sage) fails. Is there a good reason for that - i.e., is
Given an authorative answer, it should not be hard to add that translation
to the sagemath-fricas interface. Just let me know.
Martin
On Wednesday 10 April 2024 at 09:16:15 UTC+2 Nasser M. Abbasi wrote:
>
> " Maple page says:
>
> Ei(a, z) = z^(a-1)*GAMMA(1-a, z)
>
> In FriCAS that would be
>
>
e one.
> >
> > On Mon, Feb 12, 2024 at 6:40 PM Waldek Hebisch wrote:
> >
> >> On Mon, Feb 12, 2024 at 07:02:39AM -0800, 'Martin R' via FriCAS -
> computer
> >> algebra system wrote:
> >>> Dima reports the following on
> >>> https://gith
Dima reports the following on
https://github.com/sagemath/sage/pull/37041#issuecomment-1938698041
Apparently, this is using ecl (using the standard SageMath setup).
Unfortunately, I cannot help except for reporting, because I do not have
access to a mac.
It would be wonderful if you could
I don't mind much. I think that FEseries is better than ADEseq.
Best wishes,
Martin
On Wednesday 27 December 2023 at 17:30:33 UTC+1 Waldek Hebisch wrote:
> On Tue, Dec 26, 2023 at 02:01:14PM -0800, 'Martin R' via FriCAS - computer
> algebra system wrote:
> > It would be nice if
25:24AM -0800, 'Martin R' via FriCAS - computer
> algebra system wrote:
> > Possibly the email address is outdated? I am at tuwien.ac.at.
>
> I see. I used yahoo.de address from your past messages to the group.
>
> > I agree that rootOfADE may be misleading, however, if you renam
rootOfADE because guessFE didn't exist at the time (I think) and to
make the connection to rootOfRec immediately visible.
Martin
On Sunday 24 December 2023 at 22:59:34 UTC+1 Waldek Hebisch wrote:
> On Sun, Dec 24, 2023 at 01:36:07PM -0800, 'Martin R' via FriCAS - computer
> algebra system
Thank you for notifying!
(May I ask for the reason of the change of name? Will rootOfRec also be
renamed? Disclaimer: I introduced these operators to FrICAS)
Best wishes,
Martin
On Sunday 24 December 2023 at 02:10:09 UTC+1 oldk1331 wrote:
> In Sagemath's FriCAS interface, there is:
>
>
Hi Nasser!
I cannot reproduce the AttributeError integrals - on my computer they
eventually fail with an ECL memory limit error.
I'm quite sure that the problem is the same as with the explicit roots -
there is no sagemath equivalent for fricas' implicit roots, which is
One way to run fricas online is https://sagecell.sagemath.org, you can run
your computations with fricas("foo"). Possibly the SageCell people would
be grateful for support. I don't know how hard it would be to have a
%%fricas marker that allows you to enter fricas code in full generality.
> During integration FriCAS tries as much as it can preserve structure of
user input.
I think that this is not true with respect to polynomials: these are always
expanded, right?
sage: fricas("(x+y)^5")
54 2 3 3 2 4 5
y + 5 x y + 10 x y + 10 x y + 5 x y + x
Apparently, the following should give 2:
(1) -> f := D(log(tan(%pi/2*tanh(x))), x)
(2) -> limit(f, x=%plusInfinity)
(2) "failed"
see https://trac.sagemath.org/ticket/34757
Best wishes,
Martin
--
You received this message because you are subscribed to the Google Groups
"FriCAS -
Very likely,
$ sage -i fricas
on the console works. If it doesn't, it may be easier to install fricas
separately, sage will then know how to use it.
On Monday, 26 September 2022 at 10:44:56 UTC+2 gex.fe...@gmail.com wrote:
> Hi, I'm a Mac user. I have arm64 architecture, so the MacBook with
I do not know how to take the result apart for further computations. What
you can do is "eval(result, n=17)". Also, there is "getEq$RECOP" which
gives you the equation of a recurrence.
The result is obtained by taking quotients and differences and then
applying interpolation to the resulting
The reason that the innermost terms (i.e., the factors in the product
indexed by p_5 in your output) are given as a recurrence rather than the
seemingly equivalent function f(p_5) = 1 is that they are in fact not
equivalent.
The recurrence (p - 1) f(p) + p - 1 = 0 is satisfied also by f(0) =
h.
>
> Dima
>
>
> On Tue, 23 Aug 2022, 15:22 Waldek Hebisch,
> wrote:
>
>> On Tue, Aug 23, 2022 at 05:55:29AM -0700, 'Martin R' via FriCAS -
>> computer algebra system wrote:
>> > If I understand correctly, FriCAS' result of integrate(1/(b*x^5+a), x)
If I understand correctly, FriCAS' result of integrate(1/(b*x^5+a), x)
contains some algebraic numbers with placeholders like %%G0. To convert
the result into a sage expression, these are substituted back.
Unfortunately, these expressions may be extremely large, and this effect
multiplies
Sorry for replying late.
modhpsol uses a randomized algorithm, trying to reconstruct the solution by
generating sufficiently many solutions modulo a prime number. However,
under certain circumstances, this does not work well - mostly, if the input
contains very many zeros. In this case,
The fix has nothing to d with FriCAS and is provided in the mentioned
ticket.
emanuel.c...@gmail.com schrieb am Sonntag, 23. Mai 2021 um 18:31:51 UTC+2:
> To whom it may concern (most notably Bill Page, which has written a part
> of this interface, seems to have been interested recently in
Such a domain exists and is called UnivariateFormalPowerSeries :-)
ra...@hemmecke.org schrieb am Montag, 22. Februar 2021 um 18:41:06 UTC+1:
> Oops... attachments are now there...
>
>
> Forwarded Message
> Subject: UnivariateTaylorSeries
> Date: Mon, 22 Feb 2021 18:38:49 +0100
Dear all, but especially Waldek!
I think that https://mathoverflow.net/questions/374089 deserves some input
from you!
All the best,
Martin
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group
I wrote a utility seriesSolve to (try to) compute the sequence given a
differential equation, but it is very ugly to use. Some (untested) examples
(possibly bitrotten):
f := operator 'f
SSOLVE ==> EXPRSOL(INT, EXPR INT, UFPS EXPR INT, UFPS SMPEXPR EXPR INT)
binTree := seriesSolve(-2*f z + 2*z +
I would like to have the patch proposed in
https://groups.google.com/forum/#!msg/fricas-devel/j-dy6TXiX9E/CG4JFGYeGgAJ in
the new release, fixing a bug in the InputForm of formal derivatives.
That would be great,
Martin
Am Freitag, 21. Februar 2020 17:04:57 UTC+1 schrieb Waldek Hebisch:
>
> I
Actually, this is a proper bug in FriCAS, because the translation of your
integral is
integrate((%i*a*tan(d*x + c) + a)*sec(d*x + c)^10, x)
(note the "%i" instead of "I", which is FriCAS' complex unity, "I" is just
any other variable for FriCAS)
The result of the above integral is
>>
FriCAS integration routines know dilog and in general seem to be able to
handle them. Howewer, we have
(1) -> ex := integrate(polylog(3, x), x)
(1)
log(- x + 1)
- x %iint(x,- ) + x polylog(3,x) + (- x + 1)log(- x + 1) + x
x
ping?
Am Montag, 4. November 2019 09:23:33 UTC+1 schrieb Martin R:
>
> Thank you! Unfortunately, I am still not clear on the difference. Is the
> following correct:
>
> EXPR INT assumes real variables and functions, and EXPR Complex INT is a
> hack?
>
> Martin
>
--
You received this message
Thank you! Unfortunately, I am still not clear on the difference. Is the
following correct:
EXPR INT assumes real variables and functions, and EXPR Complex INT is a
hack?
Martin
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system"
Maybe it would be worthwhile to contact
https://openreview.net/forum?id=S1eZYeHFDS
and check against FriCAS?
Martin
--
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
Dear all,
maintaining the sage-FriCAS interface, I recently ran into the problem of
converting expressions that contain the complex unit into FriCAS
expressions.
I vaguely recall that EXPR INT contains the complex numbers, by using
sqrt(-1), but I am not sure anymore. Hence:
1) What is the
I am grateful if you commit for me!
Martin
Am Donnerstag, 21. Februar 2019 18:03:29 UTC+1 schrieb Waldek Hebisch:
>
> Martin R wrote:
> >
> > directory-sep-char is gone. Therefore:
> >
> > diff --git a/contrib/emacs/fricas.el b/contrib/emacs/fricas.el
> > index 070b83ac..9c19b946 100644
>
Dear Waldek,
I'm afraid I cannot help much further. At first I thought that normalize
might expect that the dummy variables in
sum(a^k, a=1..k) and eval(sum(a^k, a=1..k), k=k-1) should be different, but
this doesn't help:
(1) -> ex := sum(a^k,a=1..k); ex2 := sum(a^(k-1),a=1..k-1);
Dear Kurt!
As far as I can see, eval, D, == and := are behaving exactly as specified.
With
f(x,y) == D(f(x,y),x)
the symbol "f" is a FriCAS function, and NOT a function in the usual
mathematical sense!
In particular, f(a,b) returns the expression (in the pre-calculus sense)
f_1(a,b),
first
directory-sep-char is gone. Therefore:
diff --git a/contrib/emacs/fricas.el b/contrib/emacs/fricas.el
index 070b83ac..9c19b946 100644
--- a/contrib/emacs/fricas.el
+++ b/contrib/emacs/fricas.el
@@ -688,7 +688,7 @@ See `comint-dynamic-complete-filename'. Returns t if
successful."
Here is a simplification of the problem:
(1) -> ex := sum(a^k,a=1..k); ex1 := ex/eval(ex, k=k-1);
Type:
Expression(Integer)
(2) -> )tr EFSTRUC )math
Packages traced:
ElementaryFunctionStructurePackage(Integer,Expression(
>
> Martin R wrote:
> >
> > The symbol is actually provided in the internal representation of diff.
>
> > That's why I added
> >
> > -- l is a triple [function at dummy variable, dummy variable, evaluated
> at]
>
> But are you sure we can reuse it? In the past such reuse lead
> to
The symbol is actually provided in the internal representation of diff.
That's why I added
-- l is a triple [function at dummy variable, dummy variable, evaluated at]
Martin
Am Montag, 18. Februar 2019 18:03:58 UTC+1 schrieb Waldek Hebisch:
>
> Martin R wrote:
>
> > Here is a proposed fix:
Hi Kurt!
I'm not sure I understand the problem. With the patch applied, I obtain:
(1) -> f:=operator 'f
(1) f
Type:
BasicOperator
(2) -> g(x,y) == D(f(x,y), x)
this is stranger than I thought at first:
(1) -> limit(sin(x)+erf(x+sqrt(-1)/2) + erf(x-sqrt(-1)/2), x=0)
(1) 0
Type:
Union(OrderedCompletion(Expression(Integer)),...)
so, apparently, the limit exists unconditionally, but adding the direction
makes FriCAS believe it
Here is a proposed fix:
diff --git a/src/algebra/fspace.spad b/src/algebra/fspace.spad
index 3e6d3dda..29031e32 100644
--- a/src/algebra/fspace.spad
+++ b/src/algebra/fspace.spad
@@ -593,37 +593,26 @@ FunctionSpace(R : Comparable) : Category ==
Definition where
error concat("Unknown
I am going to prepare a fix today...
Martin
--
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.
To
Hi there!
I'm afraid that there is a slight bug in the InputForm of formal
derivatives in 1.3.5.
I guess the problem is that evaluation does not commute with
differentiation.
Best wishes,
Martin
(1) -> f := operator 'f
(1) f
Very likely - thanks for spotting the mistake!
Martin
Am Samstag, 16. Februar 2019 22:23:16 UTC+1 schrieb Ralf Hemmecke:
>
> > what I am asking for now is something much simpler: could we have an
> ioHook
> > for these messages?
>
> I support an additional ioHook, but your patch does not seem
Dear all!
first of all, a big thank you for providing 1.3.5 and your cooperation
concerning InputForm! I sincerely hope that having more of FriCAS features
exposed in sage will sparkle also more interest in FriCAS itself,
especially where it shines!
Now the next question: recently, the
I am sorry, I think I wrote nonsense. After 'sage -i fricas' you can use
fricas from *within* sage, but I guess this doesn't really make sense.
Please excuse the noise,
Martin
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system"
"sage -i fricas" is enough as soon as sage 8.7 is out.
If you are willing to use the sage develop branch, then fricas 1.3.5 is in
fact already available.
Best wishes,
Martin
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system"
This arises in the computation of an integral:
(51) -> limit(sin(x)+erf(x+sqrt(-1)/2) + erf(x-sqrt(-1)/2), x=0, "right")
(51) "failed"
(52) -> limit(erf(x+sqrt(-1)/2) + erf(x-sqrt(-1)/2), x=0, "right")
(52) 0
Martin
--
You received this message because you are subscribed to the
I think I found something rather strange:
(1) -> sum(sum(a^k, a=1..k), k=1..n)
- log(%C)
>> Error detected within library code:
Hidden constant detected
Best,
Martin
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system"
Many many thanks!
I created https://trac.sagemath.org/ticket/25962 for the upgrade within
sagemath.
Martin
--
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,
>
> Well, in ComplexCategory asserting EuclideanDomain is a lie (true
> only in very special cases).
>
OK, thanks! (although I'm unable to come up with an example, it does
seem like it's too much too hope for - do you have an example?)
Many thanks,
Martin
--
You received this message
>
> Let me add that EuclideanDomain is a nice example of things
> going wrong: probably more than half of uses in original code
> were bugs. Several such buggy uses are now removed but I still
> work on removing some other...
>
I'd be very interested in a concrete example!
Sage's approach
Below is a patch...
diff --git a/src/algebra/pscat.spad b/src/algebra/pscat.spad
index 01ffdb1c..ca7dc970 100644
--- a/src/algebra/pscat.spad
+++ b/src/algebra/pscat.spad
@@ -197,6 +197,7 @@ UnivariateTaylorSeriesCategory(Coef) : Category ==
Definition where
++ When the coefficient ring
I have no account (or wouldn't know where), so please commit instead of me!
Thank you for your support!
Martin
--
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
patch attached. please check!
many thanks,
Martin
Am Freitag, 17. August 2018 16:32:42 UTC+2 schrieb Waldek Hebisch:
>
> Martin R wrote:
> >
> > Great!
> >
> > To which file should I add the tests?
> >
> > Am Donnerstag, 16. August 2018 17:08:29 UTC+2 schrieb Waldek Hebisch:
> > >
> >
Great!
To which file should I add the tests?
Am Donnerstag, 16. August 2018 17:08:29 UTC+2 schrieb Waldek Hebisch:
>
> Martin R wrote:
> > I'd like to propose two more conversions to InputForm, namely for
> > OrderedCompletion and OnePointCompletion.
> >
> > Comments welcome...
>
> Looks
Dear all,
I'd like to propose two more conversions to InputForm, namely for
OrderedCompletion and OnePointCompletion.
Comments welcome...
Martin
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this
>
> I gave you times on my machine in the post. The timings above are given
> by Nasser. What timing do you get?
>
(I replaced lines of output which are not interesting with "...". This is
on a Intel(R) Celeron(R) CPU N2940 @ 1.83GHz)
...
│ SageMath version 8.3.rc1, Release Date:
Am Mittwoch, 1. August 2018 14:15:56 UTC+2 schrieb Waldek Hebisch:
>
> Martin R wrote:
> >
> > If you post a concrete example, I can have a look. One thing is that
> sage
> > uses ecl, not sbcl. The other thing is that the size of the output
> might
> > affect the timing significantly.
If you post a concrete example, I can have a look. One thing is that sage
uses ecl, not sbcl. The other thing is that the size of the output might
affect the timing significantly.
Martin
Am Montag, 30. Juli 2018 22:32:48 UTC+2 schrieb Waldek Hebisch:
>
> BTW Martin, have you looked at times
For the moment I'd like to do something which is as little work on my side
as possible - so I'd rather avoid them.
(the real optimization will be to communicate not over strings but directly
- but not now)
Best,
Martin
Am Montag, 30. Juli 2018 12:17:08 UTC+2 schrieb Waldek Hebisch:
>
>
I now have the following. I couldn't find an equivalent of python's join
(in Common Lisp there is format, of course), which takes a string and a
list of strings, and puts the first between all the others...
comments very welcome!
Martin
sageprint(x:InputForm):String ==
atom? x =>
Dear all,
I was trying to turn an SExpression into a (compact) String. My final goal
is to try to avoid "unparse$InputForm" in the sage interface.
In particular, I would prefer a solution which does not contain any
unnecessary whitespace.
I know of
FORMAT('NIL, "~S", (-1/2)::INFORM)$Lisp
unfortunately, I was mistaken. It turns out that the extra parens are
quite problematic.
The problem is that the parser for symbolic expressions provided by sage
only allows function calls of the form f(a,b,c), with very few exceptions.
In particular, expressions of the form f(a, (b, c)) are
Fine with me!
--
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.
To post to this group, send email
Indeed, this also works. The only difference seems to be the additional
parentheses:
(3) -> unparse(sum(1/k, k=1..n)::INFORM)
(3) "sum(1/%H,equation(%H,(1..n)))"
Although inconvenient (are they necessary?), I think I can handle them.
Thanks for everything,
Martin
--
You received this
Nasser found the following interesting bug at
https://trac.sagemath.org/ticket/25905:
(1) -> f := (I*a*tan(d*x + c) + a)^3*tan(d*x + c)
(1)
3 34 2 3332
I a tan(d x + c) + 3 I a tan(d x + c) + 3 I a tan(d x + c)
+
3
Perhaps as follows? Besides, it seems that this was dead code before my
patch...
Martin
diff --git a/src/interp/format.boot b/src/interp/format.boot
index fc2de70..4748d9e 100644
--- a/src/interp/format.boot
+++ b/src/interp/format.boot
@@ -394,7 +394,7 @@ form2String1 u ==
lo :=
Thank you!
unfortunately, I just discovered a problem:
(18) -> unparse(sum(1/factorial(k), k=1..n+m)::INFORM)
>> Error detected within library code:
strsym: form is neither a string or symbol
I am trying to fix it...
Martin
--
You received this message because you are subscribed to
Dear Waldek,
Am Freitag, 20. Juli 2018 16:16:15 UTC+2 schrieb Waldek Hebisch:
>
> Martin R wrote:
> > Curiously, the InputForm of products and sums gets rid
> > of subscripted symbols automagically...
>
> Well, you use dummy variables in input form. Scripted symbols
> only appear in names
Dear all,
attached a patch. Curiously, the InputForm of products and sums gets rid
of subscripted symbols automagically...
all the best,
Martin
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this
Cool, thank you for the hints!
I'll check whether special casing atoms makes sense. Should I prepare a
pull request or a simple patch, and should I add testcases to a new file or
to an existing file.
Finally, do you prefer the current InputForm for sum and product (%defsum,
%defprod), which
some mods to make it compile...
)abbrev package RANGRAPH RandomGraph
RandomGraph(): Exports == Implementation where
Exports == with
randomGraph: () -> GraphImage
Implementation == add
randomGraph() ==
nHues ==> 27 -- hardcoded in FriCAS :(
I am sorry it took so long. Attached there is a patch which appears to
work well:
(1) -> (3^2)$OUTFORM
2
(1) 3
Type:
OutputForm
(2) -> (3^2)$OUTFORM::INFORM
(2) '(^ 3 2)
Thanks Waldek!
I am currently preparing a proper patch. I decided to try a few
approaches, so it won't be before tonight...
Martin
Am Dienstag, 10. Juli 2018 17:30:18 UTC+2 schrieb Waldek Hebisch:
>
> Martin R wrote:
> >
> > Dear all,
> >
> > as you may know, I am trying to improve the
Dear all!
I would like to make another effort to promote and implement clear
semantics for InputForm. As you may know, my motivation and use case for
this is the interoperability with sage.
As an aside, I am very happy to report that these efforts finally bear
fruit:
* FriCAS was recently
>
> Of course just submit a patch. Such as what you attached to your
> original message. :)
>
Help very much appreciated!
In your first message you wrote:
>
> ...
>
> > (53) -> f::INFORM
> >
> >(53)
> >(%defprod (+ (%defsum (/ 1 (+ %LW 2)) %LW (*01000s 10) 0 (+ %LX -
> 1)) 1)
Can I do anything to facilitate inclusion in FriCAS?
It would be relatively urgent, because it holds up other stuff and I cannot
see how to work around this. So I'd be extremely grateful if it would make
it into the next release.
Martin
--
You received this message because you are
Sorry, emails crossed...
Am Donnerstag, 5. Juli 2018 19:57:15 UTC+2 schrieb Ralf Hemmecke:
>
> >> Wouldn't it be wiser to add functions to Expression in order to
> >> decompose an element.
> >
> > No, not in the case of the Sage interface to FriCAS.
>
> Can you give a reason why?
>
> A
>
> I think that going via InputForm is not the right way to do such a
> conversion from FriCAS Expression(INT) into a Sage expression.
>
> Wouldn't it be wiser to add functions to Expression in order to
> decompose an element. There are already some such functions.
>
At least for the
Dear all,
as you may know, I am trying to improve the accessibility of FriCAS from
sage, since some people (including myself) value FriCAS strengths.
I wanted to add functionality to translate FriCAS' sums and products into
sage's, but ran into a stupid problem.
Basically, I use the unparsed
Hi integration gurus!
It seems to me that the integral of log(x)^(-t-1) is possibly incorrect:
(6) -> f := log(x)^(-t)
- t
(6) log(x)
Type:
Expression(Integer)
(7) -> r := integrate(f, x)
(7) cos(%pi t)Gamma(- t + 1,-
Well, the thing wich is not working is the translation back to sage. You
can do fricas.integrate(expression, var) to skip the translation back to
sage, but that's probably not so useful. It should not be too hard to
translate rootOf, once I know what it should translate to...
Martin
Am
Hi again,
what is the semantics of the InputForm of rootOf precisely? Is it as
follows:
(rootOf p v)
"defines" v to be one of (???) the roots of the polynomial p?
Isn't it important which root?
Martin
Am Montag, 18. Juni 2018 09:18:37 UTC+2 schrieb Martin R:
>
> You can use
>
> sage:
You can use
sage: fricas.setSimplifyDenomsFlag(fricas.true)
However, in the example below, you will hit another NotImplementedError:
rootOf has no translation to sage yet.
https://trac.sagemath.org/ticket/25597 might be necessary, I don't know.
Martin
Am Sonntag, 17. Juni 2018 14:54:19 UTC+2
On Sat, Oct 7, 2017 at 5:49 PM, 'Martin R' via FriCAS - computer
> algebra system <fricas...@googlegroups.com > wrote:
> > For some reason, that doesn't work. I can start fricas on the command
> line
> > with fricas -nosman, and in sage manually, but for some reason i
I am forwarding an observation by Eric Bray, concerned with making FriCAS
an optional (as opposed to experimental) package for sagemath. It would be
great if you could comment, ideally
on https://trac.sagemath.org/ticket/23847?replyto=35#comment, otherwise
here...
Weirdly, last time FriCAS
apparently I need:
* Linux
* Mac OS X
* Solaris SPARC 32-bit
Martin
--
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
Help needed!
to make fricas optional, I need to know:
* does FriCAS (the tarball from sourceforge) build on various architectures
and systems (32bits/64 bits, GNULinux/cygwin/OSX)
* how do I invoke the testsuite?
Martin
--
You received this message because you are subscribed to the Google
Hi there,
To clarify: FriCAS *was* an optional package for a long time. It was
downgraded to "experimental" because some doctests of the interface to sage
didn't work at a specific time, and all packages having this problem were
treated like that.
The difference between "experimental" and
>
>
> I am affraid that interpreter can treat '::' in this way.
> Write:
>
> x := coerce('x)@(TS FRAC POLY INT)
>
> to force choice of right coercion (and the same for y).
>
> Splendid! Thank you!
--
You received this message because you are subscribed to the Google Groups
"FriCAS -
I'm afraid I hit a bug. Is there a workaround?
(61) -> )se str cal 3
(61) -> x := 'x::TS FRAC INT; y := 'y::TS FRAC INT;
Type:
TaylorSeries(Fraction(Integer))
(62) -> ((1-2*(x+y))^(-1/2))::TS FRAC INT
(62)
3 2 3 2 5
It would make sense to have one function that produces a list l such that
"construct(l)@domain" produces the original thing.
Martin
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop
Because of limited time I can only make a rather short comment:
it is easiest to make the sage interface work with a representation (I used
InputForm) that allows you to recreate the object in FriCAS.
In other words, a domain "GeneralForm" that drops some of the information
is *not* useful.
no arXiv???
Am Donnerstag, 23. Februar 2017 17:11:16 UTC+1 schrieb Ralf Hemmecke:
>
> I just got notified that my article in the Journal of Symbolic
> Computation appeared online.
>
> http://dx.doi.org/10.1016/j.jsc.2017.02.001
>
> This is an article where I mention FriCAS. In fact, FriCAS
1 - 100 of 140 matches
Mail list logo
