The "constant" can cause the compiler to cache the result and return it
directly next time, IIRC.
- Qian
On Mon, Jan 22, 2024, 10:39 PM Prof. Dr. Johannes Grabmeier <
johan...@grabmeier.net> wrote:
> thanks, the rare instance of code for init() in the system, e.g. in
> QuotienFieldCategory is
Because init() uses oneToN1 which is a variable that is initialized only
once when the Domain is created.
Try to make oneToN1 into a function.
- Qian
On Mon, Jan 22, 2024, 10:11 PM Prof. Dr. Johannes Grabmeier <
johan...@grabmeier.net> wrote:
> example to 1.:
>
> after
>
> )co iml
>
> )co
Looks like a bash quoting problem. You may need to escape the quotes.
BTW, the default is 1GB. I usually test with 4GB. Not sure what the minimal
is.
- Qian
On Wed, Jan 10, 2024, 10:41 PM Andrey G. Grozin
wrote:
> On Wed, 10 Jan 2024, Qian Yun wrote:
> > You can build with
> >./configure
Hi Waldek, what's your holiday plan? I'll submit patches outside of
that time frame.
- Qian
On Thu, Dec 7, 2023 at 8:43 AM Waldek Hebisch wrote:
>
> I think that we should do new release early in January next year.
> I have rather long queue of thing "in making" and it will take
> long time to
Then is there a way to specify the algebraic number
which square is 2 and is near +1.41421?
- Qian
--
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
who
> need it. It would be better just to use '--with-gmp-lib=', so that
> it works for everybody.
>
> BTW: Probably it would be better to use '--with-gmp-lib=' also on
> Windows, but I am not sure if anybody used '--with-gmp-lib=' on
> Windows, w
As Waldek said in the github comment:
"IIRC redefined 'in-package' was added for Aldor. I do not know
if Aldor still need it."
Aldor generates non-standard Lisp -- "in-package" with :use keyword.
- Qian
On Sun, Mar 5, 2023, 9:14 PM Ralf Hemmecke wrote:
> > So, what we intend to do: (due to
Hi,
I can reproduce this error on Fedora 36 desktop.
Just to make sure, did you build fricas in desktop or in (remote) console?
I assume you are building under desktop and you can see the drawings popup.
But that is not expected.
As you can see in the log, there's possible memory fault (double
On 6/30/22 00:09, Ralf Hemmecke wrote:
>> Could you consider forwarding github replies to this list
>> in the future?
>
> I don't understand. In my case github sends me a mail to my mailbox. I
> can simply reply to that mail and it ends up in the github message queue
> of the particular
On 6/29/22 23:05, Waldek Hebisch wrote:
> On Wed, Jun 29, 2022 at 10:00:21PM +0800, Qian Yun wrote:
>> I don't know if these 2 patches reached Waldek's mailbox or otherwise.
>>
>> (BTW, lynx can browse through https://github.com/fricas/fricas/pulls
>> to see open PRs.)
>>
>> They were submitted 10
I'd like to discuss about the status of ChangeLog.
I don't like to include ChangeLog recently because my patches
are reviewed in undetermined order, with ChangeLog entries in
the patch, it will surely get merge/rebase conflict. Also the
date would be inaccurate.
Of course I can manually add
OK, so no problem this time.
On Wed, May 18, 2022, 9:32 AM oldk1331 wrote:
> This is a test email.
>
> My last two posts were delayed, because
> google marked them as spam and Ralf
> moderates them and released them.
>
> Let's see if this one will have the same issue.
>
This is a test email.
My last two posts were delayed, because
google marked them as spam and Ralf
moderates them and released them.
Let's see if this one will have the same issue.
And wonder if you meet this same issue.
- Qian
--
You received this message because you are subscribed to the
how to check if Fricas was build with GMP
> or not. But next
> time I build Fricas from source I look to see if there is an option for
> this.
>
> Thanks.
>
> --Nasser
>
>
> On Friday, May 13, 2022 at 2:33:30 PM UTC-5 oldk1331 wrote:
>
>> Hi Nasser,
&
>
>
> Well, Bill, try to setup a new google account. I had a discussion with
> Waldek some time ago and was surprised that (maybe from 2022 on) I am no
> longer able to create a google or gmail account without providing a
> phone number. If you know how one could do this, I'd be interested to
I wonder if this is what you need:
xset fp rehash
- Qian
On Sat, Apr 23, 2022, 1:25 PM Ralf Hemmecke wrote:
> > xfonts-100dpi
>
> In fact, when I realized the messages, I did install that, but without
> rebooting the VM, it took no effect. :-(
>
> Now it's working, but can
>
> sudo apt
Hi,
(I didn't receive this message in mailbox, strange...)
I searched through source files, and found that riemannZeta
is purely symbolic, you can not evaluate it numerically at all.
- Best,
- Qian
On Sunday, April 17, 2022 at 3:21:13 AM UTC+8 rafaelan...@gmail.com wrote:
> Hey guys
>
> I'm a
Oops, to avoid "garbage" output, try this instead:
)trace DOMAIN )ops FUNCTION )math
I remembered these extra options are in ")help" documentation... Looks
like it needs improvement.
- Qian
On Fri, Feb 4, 2022, 8:12 PM Ralf Hemmecke wrote:
> (181) -> )trace QEtaModularGammaPackage )ops
The usage should be:
)trace DOMAIN )ops FUNCTION
Does this work in your case?
- Qian
On Fri, Feb 4, 2022, 2:45 PM Ralf Hemmecke wrote:
> I have programmed a function f in some package P, how exactly can I
> trace that function. In my case
>
> )trace f
>
> does not work.
>
> (167) ->
Hi,
The arguments (x,y) to dqAppend are "double ended queue",
implemented as "head-tail linked list",
note that the car and cdr of x/y have shared cons cell,
for example:
(setq l1 '(a b c d e))
(setq x (cons l1 (last l1)))
(setq l2 '(k l m n o))
(setq y (cons l2 (last l2)))
(rplacd (cdr x) (car
Sorry about that, please revert and fix can come in later release.
- Qian
On Mon, Jun 21, 2021, 9:36 PM Waldek Hebisch
wrote:
> ATM we have one blocking problem: after change to 'fricas'
> script internal 'fricas' script and consequently 'efricas'
> no longer works. Since tere was no better
On 5/4/21 3:26 AM, Waldek Hebisch wrote:
> On Thu, Mar 18, 2021 at 07:49:49PM +0800, Qian Yun wrote:
>> + if test $(uname -s) != "Darwin" ; then \
>^^
> $$(uname -s)
>> + echo
>> FRICAS='"$${exec_prefix}/$(fricas_lib)/fricas/target/$(target)"' >>
>>
But this macro only expands to this function call, it does not do
computation at compile time.
On Tue, Mar 9, 2021, 12:20 AM Waldek Hebisch
wrote:
> On Mon, Mar 08, 2021 at 11:00:22PM +0800, Qian Yun wrote:
> > This patch tested OK, and I only have one small question:
> >
> > Why define the
THANK YOU both, Dima and Waldek.
Now I understand the difference between "msys2 shell" and
"mingw 64bit shell".
Indeed, in "msys2 shell", there are "fork". (They partly
re-implement cygwin?).
So, in "msys2 shell", we can build sman successfully.
But when building algebra, SBCL encounters
Hebisch
wrote:
> On Fri, Jan 29, 2021 at 08:12:22AM +0800, oldk1331 wrote:
> > Hi Waldek,
> >
> > Did you forget to commit this file in your last commit?
>
> Oops, you are right. I now pushed the missing file.
>
> Thanks
>
> --
>
Hi Waldek,
Did you forget to commit this file in your last commit?
- Qian
--
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
Hi Ralf,
I have changed my github profile name and set email privacy to public, I
guess that will do the trick.
- Qian
On Sat, Jan 23, 2021, 1:14 AM Ralf Hemmecke wrote:
> Hi Qian,
>
> when I look at the recent commits, I see something like
>
> Author: Frédéric Chapoton 2021-01-21 10:59:13
Hi Waldek and Ralf,
I have already used github webpage's rebase button, works nicely. I'll
continue to do so in the future.
- Qian
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop
Hi Waldek,
Which is your preferred way of merging PR?
Merge directly or rebase?
I prefer rebase because I like linear history.
- Qian
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and
The patch is as following or see the attachment.
This code only solves the case like
%iint(x,c1*%iint(c2*%iint(c3*%iint(...)/f3(x))/f2(x))/f1(x))
Which is the case we encountered.
I'm not aware about other integrals it can't handle, yet.
- Qian
diff --git a/src/algebra/integrat.spad
On 1/9/21 8:24 PM, Ralf Hemmecke wrote:
> But what is the meaning of
>
> log(- e x + 1) log(- e x + 1)
> %iint(e,x,- --,- --)
> ex
>
> ? It would be good to know (and best specified in the code) even if it
On Sat, Jan 9, 2021, 7:24 PM Ralf Hemmecke wrote:
> Hi Qian,
>
> > 1. Maybe Sage should be able to automatically escape '%' in its 'latex'
> > command.
>
> I don't think that is an option if %iint was not meant to be visible to
> an enduser.
I mean it's a Sage bug that it can't translate for
Hi, my thoughts are:
1. Maybe Sage should be able to automatically escape '%' in its 'latex'
command.
When using FriCAS to generate latex, it returns '\%' directly.
2. As Waldek said, '%iint" should be used only internally. But the
following workaround prints '%iint' as 'iint':
diff --git
Almost sure it is bug when adding new kernel in cache, in function
"enterInCache".
On Fri, Dec 4, 2020, 6:11 PM Qian Yun wrote:
>
> > Tracing shows the computation diverge at "extendedEuclidean" in
> > "normalHermiteIntegrate" of TranscendentalHermiteIntegration in
> > intrf.spad.
>
> The
Hi all,
I would like to add the following file in our repo to start CI from now on.
Comments and ideas are welcome, I'll consider to add them on
top of this in the future.
- Qian
.github/workflows/ci.yml
name: FriCAS CI
on:
push:
branches: [ master ]
pull_request:
your build file after your
> mail and yes it's the same installer file type. Yours is more
> complicated but same spirit.
>
> Some changes that I wanted in my life explain that.
>
> Sorry again
>
>
> Le mer. 9 sept. 2020 à 12:13, oldk1331 <mailto:oldk1...@gmail.com&g
I tested, it works fine, please commit.
On Wed, Sep 9, 2020, 6:30 PM Waldek Hebisch
wrote:
> On Wed, Sep 09, 2020 at 06:08:32PM +0800, oldk1331 wrote:
> >
> > > What about the attached patch. It skips 'memset' which seem
> > > to be not needed at all and cleans up
Hi Ralf,
I compiled the book successfully, it works like a charm!
One comment: to enable pdf hyperlink, you need to use
"latex" to compile the source twice.
Also, can you explain more about your thought behind
commit "compile user guide into book.tex", so that I
can catch up to it and review it
Hi Greg,
I tried your exe on Windows 10 and it works very well.
I guess your installer works similar with
https://github.com/nilqed/fricas_w32 .
I agree it's a good idea to provide a windows binary without
graphics, it'll enable more people to give FriCAS a try.
Best,
Qian
> BTW I own a NSIS
> What about the attached patch. It skips 'memset' which seem
> to be not needed at all and cleans up relevant parts.
Hi Waldek, I'm afraid you forget to include the attachment.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system"
On 8/30/20 9:51 PM, Waldek Hebisch wrote:
> On Sun, Aug 30, 2020 at 08:39:32PM +0800, oldk1331 wrote:
>>
>> Hi Waldek,
>>
>> Your commit e68c2a3e doesn't work out of box on my system:
>>
>> The gcc or glibc on my system is hardened (might be true
>>
On 8/28/20 11:23 PM, oldk1331 wrote:
> On 8/28/20 9:35 PM, Waldek Hebisch wrote:
>> the hack I proposed is not nice, it is similar to
>> hacks that are probably in use in similar contexts:
>> C compiler have to tolerate access beyond declared
>> size to struct because
On 8/28/20 9:35 PM, Waldek Hebisch wrote:
> the hack I proposed is not nice, it is similar to
> hacks that are probably in use in similar contexts:
> C compiler have to tolerate access beyond declared
> size to struct because lot of C code uses it. So
> I see no point of going in direction you
On 8/24/20 12:35 AM, Waldek Hebisch wrote:
> On Sun, Aug 23, 2020 at 10:04:29PM +0800, oldk1331 wrote:
>> Actually we can stick to hexadecimal for pid
>> less than 1 million as well.
>>
>> Current possible max pid is defined by PID_MAX_LIMIT in kernel,
>> which
Actually we can stick to hexadecimal for pid
less than 1 million as well.
Current possible max pid is defined by PID_MAX_LIMIT in kernel,
which is 2^22, around 4 million.
On Sun, Aug 23, 2020, 8:01 PM Waldek Hebisch
wrote:
> On Sat, Aug 22, 2020 at 10:41:50PM +0800, oldk1331 wrote:
> >
How about encoding PID with 0-9a-zA-Z or some
other hash method?
If you agree with this approach, I can get to implement it.
On Sun, Aug 23, 2020, 8:01 PM Waldek Hebisch
wrote:
> On Sat, Aug 22, 2020 at 10:41:50PM +0800, oldk1331 wrote:
> > Okay, I take a different approac
printf(name, "%s%s", base, num);
+ } else {
+sprintf(name, "%s%x", base, pid);
+ }
return 0;
}
On 8/19/20 4:15 PM, oldk1331 wrote:
> On 8/10/20 11:38 AM, oldk1331 wrote:
>> Ok, I'll try to test sockaddr_un on mingw32
>> and mingw64 then.
>
> I t
Although I have built FriCAS in mingw64 before,
I encounter many small obstacles this time,
so I decide to document them here for future reference.
In addition to http://www.math.uni.wroc.pl/~hebisch/fricas/windows.txt
Tips and tricks for building FriCAS in mingw64 on windows are:
1. Install
On 8/10/20 11:38 AM, oldk1331 wrote:
> Ok, I'll try to test sockaddr_un on mingw32
> and mingw64 then.
I tested in mingw64 on windows, apparently
we use winsock2.h and there's no direct
support for sockaddr_un.
Let me explore other options.
- Qian
--
You received this message becau
>
>
> > I mean, if I can build fricas in mingw with this
> > patch (sockaddr_un) successfully, then can this
> > patch be merged? Aka which platform should
> > I test for breakage?
>
> What you mean by "this patch". The patch I posted
> (adding unused field) should not break anything and
>
On Sat, Aug 8, 2020, 9:02 PM Waldek Hebisch
wrote:
> On Sat, Aug 08, 2020 at 04:59:27PM +0800, oldk1331 wrote:
> > Why do you think Windows needs different
> > declarations? Aren't we using cygwin/mingw?
>
> For that issue Cygwin, WSL and mingw are really
> different
Why do you think Windows needs different
declarations? Aren't we using cygwin/mingw?
BTW, what's our support status for windows?
Cygwin or mingw or WSL? I tried to build with
Msys2 today, but it's really a bad experience,
very slow, I gave up after 2 hours.
> should work. On Linux theoreticaly
Hi all,
Today suddenly I can't launch FriCAS, it
shows "*** buffer overflow detected ***:
terminated Aborted".
After some debugging, I found that sman
calls function "open_server" in
sockio-c.c#929:
strcpy(server[1].addr.u_addr.sa_data, name);
"sa_data" is char[14], and "name" is
Yes, you are right, when I was comparing function call traces from the diff,
the first call difference (in the wrong version) is that the argument to
'map' is 1
instead of an expression.
So this diff should exposed a bug.
On Fri, Mar 27, 2020, 11:25 PM Waldek Hebisch
wrote:
>
> Error is
Thanks for your report.
This bug is a regression between 1.3.5 and 1.3.6.
It's introduced in r2586
(https://github.com/fricas/fricas/commit/aac3e2ecbb4e34f5cfa473f19c9333623d86).
If I do following change the bug goes away:
- ml := reverse(monomials(up))
+ ml :=
On Sat, Mar 21, 2020, 1:51 AM Ralf Hemmecke wrote:
>
> Concerning CI, Qian, do you know how to setup the system github-ci so
> that a push does not succeed if fricas does not compile? I.e., commits
> to master of the official repo should only be OK if the build is OK.
>
I don't think that's
Guess we'd better blacklist these faulty sbcl versions in configure.ac as
well.
On Sat, Mar 21, 2020, 10:15 PM Ralf Hemmecke wrote:
> I don't remember what version it was. I now have sbcl 1.5.8. I think, I
> did not upgrade SBCL (not sure),
>
> It looks like this
>
>
Hi, what's your opinion on CI and bug tracker (in github)?
On Fri, Mar 20, 2020, 10:11 PM Waldek Hebisch
wrote:
> Fricas is now using Git. Former mirror at Github is
> now official repository:
>
> https://github.com/fricas/fricas
>
> For now homepage is still at Sourceforge. Release will
> be
On 1/20/20 5:44 AM, 'Martin R' via FriCAS - computer algebra system wrote:
> 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
Hi Ralf, following patch can disable this "#!":
diff --git a/src/lisp/fricas-lisp.lisp b/src/lisp/fricas-lisp.lisp
index ed9201da..a42e9dd9 100644
--- a/src/lisp/fricas-lisp.lisp
+++ b/src/lisp/fricas-lisp.lisp
@@ -993,6 +993,8 @@
#-(or :ecl :poplog)
(defun fricas_compile_file (f output-file)
I recently compiled fricas with ecl-16.1.3 and ecl-git-HEAD
(ecl is about to release a new version), both are fine.
Still, compiling fricas with ecl consumes much more time compared with sbcl
and the resulting binary will run slower.
But "configure script errors out" on both ecl and sbcl is
You can see what is happening by
")set message bottom on".
It seems to try various type conversions (involving polynomial types)
and fail eventually.
There are other places where a correct program needs long time to type
check.
In that case, adding additional explicit type hints/conversion
On 11/19/19 5:49 AM, Ralf Hemmecke wrote:
>> To answer question "what/why takes time" use profiler. sbcl
>> profiler shows that time is spent in factorizer.
>
> Thank you. I think that helps me to continue.
>
> Still I would be interested in how exactly I would have use the profiler
> and how
Hi, another workaround I discovered is to use anonymous function:
getA := (r:R):INT +-> r.a
On 11/10/19 8:52 PM, Ralf Hemmecke wrote:
> Hello Paul,
>
> I'm not a compiler developer, but if you are not afraid of writing a
> short spad program, then you can get around it, see attachment.
>
>
Hi Martin, an old email from Waldek on this subject:
Forwarded Message
Subject: Re: [fricas-devel] interesting error in integration
Date: Tue, 24 Jul 2018 00:12:30 +0200 (CEST)
From: Waldek Hebisch
Reply-To: fricas-devel@googlegroups.com
To: fricas-devel@googlegroups.com
Fixed in sbcl master now.
On Wed, Sep 18, 2019, 2:57 PM oldk1331 wrote:
> On 9/18/19 2:50 PM, Ralf Hemmecke wrote:
> > Hi Qian,
> >
> > you are a hero. THANK YOU!!!
> >
> > I've now increased the number of processors of the VM to 4 and the
> > comp
On 9/18/19 2:50 PM, Ralf Hemmecke wrote:
> Hi Qian,
>
> you are a hero. THANK YOU!!!
>
> I've now increased the number of processors of the VM to 4 and the
> compilation succeeded.
>
> That doesn't, of course, deal with the actual bug, but as you suggested,
> the best we can do is to report
On 9/17/19 7:37 PM, Ralf Hemmecke wrote:
> Hi Qian,
>
> it's as unreliable as before. It seems that it depends on the time on my
> virtualbox. When I try to compile now, it goes over that problematic step.
>
I tried locally on my machine, here are my findings:
1. This bug is not related with
On 9/17/19 6:01 PM, Ralf Hemmecke wrote:
> It seems that this thread is relevant for FriCAS.
>
> https://stackoverflow.com/questions/4777/sbcl-building-a-standalone-executable
>
> Maybe our build process has to be more careful of how to save the image.
>
> Ralf
>
In your link it shows
On 8/21/19 2:01 PM, Prof. Dr. Johannes Grabmeier privat wrote:
> would like to have a binary operation -> (or something similar, e.g. =>,
> ==>, -->". How to handle this properly with all these special meanings?
I think "=>" "==>" "->" is built-in grammar, so you can't use them.
As for "-->" you
On 8/10/19 2:17 AM, Waldek Hebisch wrote:
> oldk1331 wrote::
>>
>> I don't like the grammar that uses
>>
>> "func"/list1
>>
>> to do
>>
>> reduce(func, list1)
>>
>>
>> First, this is a strange grammar.
>&g
I don't like the grammar that uses
"func"/list1
to do
reduce(func, list1)
First, this is a strange grammar.
Also I don't like to have special grammar to do things can
be done by normal grammar.
This patch replaces '"append"/' with normal function call
'concat : List % -> %', it's
On 7/31/19 5:27 PM, Siegfried Köstlmeier wrote:
> Dear FriCAS Group,
>
> FriCAS is up to now not available as a Debian package. Although
> installation from source is quite easy - i think official .deb packages
> increase both acceptance and the scope of new potential users within the
> GNU/Linux
On 7/27/19 6:32 PM, Waldek Hebisch wrote:
> oldk1331 wrote:
>> The second patch uses "construct" to greatly simplify "*" in MRING.
>
> When M is ordered old code tries to minimize need for sorting.
> It is hard to see if this really gains some speed but it
>
I think PositiveInteger satisfy the definition of OrderedMonoid,
so I propose following change.
--- a/src/algebra/integer.spad
+++ b/src/algebra/integer.spad
@@ -259,7 +259,7 @@
++ Keywords: positive integer
++ Description: \spadtype{PositiveInteger} provides functions for
++ positive
My code for 'concat!' in r2591 is correct, but it runs
incorrectly, because there is a compiler bug.
Specifically, this bug happens when there is a single "=>"
expression inside a loop. This bug causes the loop to only
run once.
After some debugging, I'm not sure if this bug happens in
The first patch fixes the problem that "construct" may modify
its argument subtly.
The second patch uses "construct" to greatly simplify "*" in MRING.
The third patch does some cleanup for MRING.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer
On 7/25/19 7:51 PM, oldk1331 wrote:
> Actually, it's not necessary to treat differently for
> OrderedMonoid/noZeroDivisors. We can simply have
>
> a : % * b : % ==
> zero? a or zero? b => 0
> construct! concat! [[[ta.Mn*tb.Mn, ta.Cf*tb.Cf]$Term
>
Actually, it's not necessary to treat differently for
OrderedMonoid/noZeroDivisors. We can simply have
a : % * b : % ==
zero? a or zero? b => 0
construct! concat! [[[ta.Mn*tb.Mn, ta.Cf*tb.Cf]$Term
for tb in b] for ta in a]
we collect all the terms and let
"construct" is not slow, it just sorts its argument
and scans it once. "construct!" just skips one
copy. They are faster than "sortAndAdd" or "+".
On Wed, Jul 24, 2019, 11:32 PM Waldek Hebisch
wrote:
> oldk1331 wrote:
> >
> > Isn't &quo
Isn't "construct" carefully eliminate terms with zero coefficient?
On Wed, Jul 24, 2019, 9:56 PM Waldek Hebisch
wrote:
> oldk1331 wrote:
> >
> > The local function "sortAndAdd" is almost the same as
> > "construct", but less efficient: it cr
There's a bug: it gives error when the first aggregate
in the list is empty, see my updated version.
--
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
The local function "sortAndAdd" is almost the same as
"construct", but less efficient: it creates new "Term"
instead of using existing ones.
Also, the usage of "+" in "*" can also be omitted:
we can use the newly added "concat!" and pass the whole
list to "construct!".
--
You received this
We already have 'concat : List % -> %', and it's equally
useful to have its destructive counterpart, for long lists,
this version can save many many copies.
Although 'concat : List % -> %' is exported in LNAGG,
I believe that the proper place for
'concat/concat! : List % -> %' should be in URAGG.
Clearly, the usage of using "concat!" to add an element to
the end of a list is extremely inefficient.
--
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
HyperDoc can not work in pure Wayland.
I just tried with "weston", when launching fricas, it shows
(HyperDoc) Cannot connect to the X11 server!
Because the "DISPLAY" environment variable is not defined;
of course the command line part of fricas works as usual.
On 7/23/19 1:31 PM, Ralf
This type "NegativeInteger" is only referenced in compiler
and not used anymore, I think it's safe to remove.
diff --git a/src/interp/compiler.boot b/src/interp/compiler.boot
index 8aba6f5c..ef05461b 100644
--- a/src/interp/compiler.boot
+++ b/src/interp/compiler.boot
@@ -341,7 +341,7 @@
There is no need to use Reference for Domain local variables,
they can be used directly in functions. So remove the usage
of Reference for consistency and less verbosity.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To
This patch move the implementation of "first(x, n)" from
STAGG to URAGG; also add a specialized version for List.
--
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
Function "#" is defined when "% has finiteAggregate", and the
implementation should also fall under this condition, so I fixed
this for URAGG:
--- a/src/algebra/aggcat.spad
+++ b/src/algebra/aggcat.spad
@@ -1466,12 +1466,6 @@
while not empty? l and i > 0 repeat (l := rest l; i := i - 1)
In the attachment, I removed src/include/nagman.H1 and
C macro "HTADD" and Makefile variable "HTADD", they are
all unused.
--
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
On 7/14/19 9:26 PM, Waldek Hebisch wrote:
> Real bug above is that we can not expand terms separately.
> Concerning "pairsum": it should go away. I with attached
> patch I get:
>
> (1) -> integrate(a^(1/4)/(x^8-1),x)
>
>(1)
>4+-+
>--+
Some faulty integration:
integrate(a^(1/4)/(x^8-1),x)
-- following examples are from mapleok.input
in1867a:=integrate(1/(z^2-1)*(1-(I*z)^(1/2))^(1/2), z)
in1869a:=integrate(1/(z^2-1)*(1-1/(I*z)^(1/2))^(1/2), z)
in1870a:=integrate(1/(z^2-1)/(1+(I*z)^(1/2))^(1/2), z)
They are returning 0, which is
Hi, I installed Manjaro and run "yay - S fricas", it builds successfully.
Can you try again?
--
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
The function "token_name" modifies global variable "ebuffer"
to contain information about "token.id", so clearly it intends
to print out "ebuffer" instead of "eb".
--- a/src/hyper/parse-types.c
+++ b/src/hyper/parse-types.c
@@ -157,7 +157,7 @@ parse_condnode(void)
{
char
Remove those hard coded default value for $AXIOM.
diff --git a/src/hyper/htadd.c b/src/hyper/htadd.c
index 3b4c1e6b..a63cffd1 100644
--- a/src/hyper/htadd.c
+++ b/src/hyper/htadd.c
@@ -211,9 +211,8 @@
if (flag & System) {
SPAD = (char *) getenv("AXIOM");
if (SPAD == NULL) {
This is mostly due to change r2093 "Remove unsound structure
from completions", so OrderedCompletion doesn't have many
signatures anymore, especially 0$INF.
I patched your file in attachment.
On 6/5/19 9:25 AM, Xiaojun wrote:
> Hi!
>
> I'm trying to compile an old spad file but get an error:
>
When you set ")set hyperdoc fullscreen on", then in hyperdoc,
click "Settings -> Settings", you will see the error page,
and in terminal:
(1) ->
>> System error:
invalid number of arguments: 3
By backtrace , it happens in "htSystemVariables":
(|htSay| "{\\em " |break| "}\\space{1}")
Hi all, can we review these two patches please?
The original thread and attachments are in:
https://groups.google.com/forum/#!msg/fricas-devel/XtVQA0xxES4/g_8MbobFBgAJ
On 12/18/18 6:28 PM, oldk1331 wrote:
> I tried to make this change over a year ago, now I'll try again.
>
> The a
(1) -> vconcat([])$OUTFORM
>> System error:
The index 1 is too large.
The problem is that the code doesn't check for this corner case.
diff --git a/src/interp/i-output.boot b/src/interp/i-output.boot
index 044d6041..d4c5047a 100644
--- a/src/interp/i-output.boot
+++
1 - 100 of 1198 matches
Mail list logo
