Re: [fricas-devel] storing value of a constant function, want recall / strange behaviour of Reference using a domain name like FIDETransposition

[oldk1331]

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 as follows:
>
>   if S has StepThrough then
>  init() == init()$S / 1$S
>
> my code says
>
> init(): % ==
>
> changes to
>
> init: % ==
>
> and
>
> init: ==
>
> both compile, but both do not change the wrong behaviour
>
> Are there semantic differences between
>
> f: constant -> %
>
> versus
>
> f: () -> %
>
>
> Am 22.01.24 um 15:25 schrieb Ralf Hemmecke:
> > I am not quite sure what the "constant" in this line actually means
> > (Is that documented somewhere?), but intuitively it might be the
> > sources of your "problem".
> >
> >
> https://github.com/fricas/fricas/blob/master/src/algebra/catdef.spad#L1498
> >
> >
> > Ralf
> >
> --
> Mit freundlichen Grüßen
>
> Johannes Grabmeier
>
> Prof. Dr. Johannes Grabmeier,
> Köckstraße 1, D-94469 Deggendorf
> Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756
> Fax: +49-(0)-991-2979592
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/3cb26dbf-3d60-47f4-9490-7b0a2b530e69%40grabmeier.net
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN916frH6W2u1JoS%3DBep-rA0woUpLTw3GQsx7LR9eUYiYaA%40mail.gmail.com.

Re: [fricas-devel] storing value of a constant function, want recall

[oldk1331]

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 fidepermutationsINIT
>
> one gets
>
> (1) -> n1()$FideTransposition
>
> (1)  1
> Type: NonNegativeInteger
> (2) -> n2()$FideTransposition
>
> (2)  1
> Type: NonNegativeInteger
> (3) -> n()$FideTransposition
>
> (3)  2
> Type: NonNegativeInteger
> (4) -> init()$FideTransposition
> init() called using oneToN1 = [1]
>
> (4)  [1]
> Type: FideTransposition
> (5) -> set(3,5)$FideTransposition
>
> (5)  [3, 5]
> Type: List(NonNegativeInteger)
> (6) -> n1()$FideTransposition
>
> (6)  3
> Type: NonNegativeInteger
> (7) -> n2()$FideTransposition
>
> (7)  5
> Type: NonNegativeInteger
> (8) -> n()$FideTransposition
>
> (8)  8
> Type: NonNegativeInteger
> (9) -> init()$FideTransposition
>
> (9)  [1]
> Type: FideTransposition
>
> expected answer is [1,2,3]
>
>
>
> Am 22.01.24 um 13:51 schrieb Qian Yun:
> >
> > On 1/22/24 20:46, Prof. Dr. Johannes Grabmeier wrote:
> >> Dear all,
> >>
> >> 1. following problem: I use Reference NNI to change internal values
> >> of a domain. A further constant function: init: () ->% depends of the
> >> changed values. It seems that FriCAS does not call the constant
> >> function again, but stores the old value of init(), then out of date.
> >> Non constant functions of course correctly use the changed values.
> >> How can I bring FriCAS to *call *and *evaluate* again the constant
> >> function with the updated values?
> >>
> >> 2. Another, very strange problem was noted:
> >>
> >> The referenced values where in a domain called
> >>
> >> )abbrev domain FIDETR FIDETransposition
> >>
> >> Believe me or not: the changing of the referenced values did not work!
> >>
> >> After long searching of the reasons I found: this depended on the
> >> name "FIDETransposition", i.e. the change to
> >>
> >> )abbrev domain FIDETR FideTransposition
> >>
> >> caused, that changing of referenced values work as expected! Can send
> >> an example, if someone is interested.
> >>
> >
> > Yes, examples please, otherwise it's hard to debug.
> >
> > Problem in 1 should not happen, because there are similar things in
> > FriCAS code base and they work well.  So please show me the example.
> >
> > - Qian
> >
> --
> Mit freundlichen Grüßen
>
> Johannes Grabmeier
>
> Prof. Dr. Johannes Grabmeier,
> Köckstraße 1, D-94469 Deggendorf
> Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756
> Fax: +49-(0)-991-2979592
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/76a5fc70-c37b-4502-9c5a-974a0d250d86%40grabmeier.net
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN93WUG2%3DnGb7CbUyMc1NTY9MZbj%2BwawAcRKdYLydrG%2B9cw%40mail.gmail.com.

Re: [fricas-devel] FriCAS 1.3.10 is released

[oldk1331]

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 --with-lisp="sbcl --dynamic-space-size 4096"
>
> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
> --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
> --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
> --localstatedir=/var/lib --datarootdir=/usr/share
> --docdir=/usr/share/doc/fricas-1.3.10
> --htmldir=/usr/share/doc/fricas-1.3.10/html --libdir=/usr/lib64
> --disable-aldor --with-lisp="sbcl --dynamic-space-size 4096" --with-x
> --with-gmp
> configure: error: unrecognized option: `--dynamic-space-size'
> Try `./configure --help' for more information
>
> Andrey
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/aa5cc496-fc3d-b77a-a66c-da597a81512e%40starnew.inp.nsk.su
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92vgLc4JufmEP%2BENNw%3DR7RpF1ww%2BhLfGRKri3WL-0hYrA%40mail.gmail.com.

Re: [fricas-devel] New release

[oldk1331]

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 finish them.  But I think that we have valuable
> changes and should include what is ready intead of stretching
> release cycle.
>
> --
>   Waldek Hebisch
>
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/ZXEVKFK2_SQ_LucH%40fricas.org.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91BSd8QU8Zav%2B7C4DxzXZZ_Dnp_k7jhjjmyLCY-FxA4ig%40mail.gmail.com.

Re: [fricas-devel] real? sqrt (-sqrt 2)

[oldk1331]

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 email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN90C4wJ5mT3ZkBii7viHCQuXKw6ChnhfaWp4%2BrETBFi7nQ%40mail.gmail.com.

Re: [fricas-devel] [PATCH] proper support for GMP on macOS

[oldk1331]

'--with-gmp-lib=' configure option works on build machine, and this patch
doesn't break it.

When binary is installed on user machine, you can't assume gmp is available
in that path.

So the only way is to bundle gmp as fallback.

- Qian

On Wed, Nov 8, 2023, 10:01 PM Waldek Hebisch  wrote:

> On Wed, Nov 08, 2023 at 08:28:22AM +0800, Qian Yun wrote:
> > Recently I found that CI built macOS binaries do not work out-of-box:
> > it complains libzstd missing because SBCL from Homebrew is built with
> > core-compression support.
> >
> > So I have changed to use upstream sbcl binary instead.
> >
> > The situation for gmp support is similar to windows: we can not assume
> > libgmp.dylib is present on system.
> >
> > So I changed CI to bundle gmp library, and changed code to load bundled
> > gmp library if there's no system gmp library.
>
> We alreay have '--with-gmp-lib=' configure option.  This option was
> added exactly to solve problem that you mention: we can not assume
> that Mac OSX has GMP library in a fixed location.  I am affraid that
> your patch below would break '--with-gmp-lib=' for people 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, while AFAIK it is used on Mac OSX.
>
> >
> > - Qian
> >
> >
> https://github.com/oldk1331/fricas/commit/dbc3a563caf892374782e808f790f5442620816f.patch
> >
> > diff --git a/.github/workflows/macOS.yml b/.github/workflows/macOS.yml
> > index 8439f76e..d4737664 100644
> > --- a/.github/workflows/macOS.yml
> > +++ b/.github/workflows/macOS.yml
> > @@ -19,14 +19,17 @@ jobs:
> >  - name: configure
> >run: |
> >  mkdir ../build && cd ../build
> > -../fricas/configure
> >
> --with-lisp=${GITHUB_WORKSPACE}/sbcl-${SBCL_VER}-x86-64-darwin/run-sbcl.sh
> > || cat config.log
> > +../fricas/configure
> >
> --with-lisp=${GITHUB_WORKSPACE}/sbcl-${SBCL_VER}-x86-64-darwin/run-sbcl.sh
> > --enable-gmp || cat config.log
> >  - name: make
> >run: cd ../build && make -j3
> >  - name: make check
> >run: cd ../build && make check -j3
> >  - name: Create artifact archives
> >run: |
> > -cd ../build && make dist-osx-dmg
> > +cd ../build
> > +make dist-macos
> > +cp -v `brew list gmp | grep libgmp.10.dylib`
> > FriCAS.app/Contents/Resources/usr/local/lib/fricas/target/*/lib/
> > +make dist-macos-dmg
> >  mv FriCAS.dmg ../fricas/FriCAS-macOS-x86_64-${{ github.sha
> }}.dmg
> >  - name: Upload macOS binary
> >uses: actions/upload-artifact@v3
> > diff --git a/Makefile.in b/Makefile.in
> > index 2961de19..c370d32b 100644
> > --- a/Makefile.in
> > +++ b/Makefile.in
> > @@ -247,7 +247,7 @@ ${DIST_TARBALL}: out-of-source-check lastBuildDate
> > dist-help dist-lisp dist-doc
> >
> >  dist: ${DIST_TARBALL}
> >
> > -dist-osx-dmg: out-of-source-check
> > +dist-macos: out-of-source-check
> > -rm -rf FriCAS.app FriCAS.dmg
> > ${MKDIR_P} FriCAS.app/Contents/{MacOS,Resources}
> > ${MAKE} DESTDIR=./FriCAS.app/Contents/Resources install-src
> > @@ -255,6 +255,8 @@ dist-osx-dmg: out-of-source-check
> > cp $(fricas_top_srcdir)/contrib/macos/Info.plist
> > ./FriCAS.app/Contents/
> > cp $(fricas_top_srcdir)/contrib/macos/appIcon.icns
> > ./FriCAS.app/Contents/Resources/
> > cc -framework CoreFoundation
> > $(fricas_top_srcdir)/contrib/macos/FriCAS.c -o
> > ./FriCAS.app/Contents/MacOS/FriCAS
> > +
> > +dist-macos-dmg:
> > hdiutil create -srcfolder FriCAS.app FriCAS.dmg
> >
> >  clean-distdir:
> > diff --git a/src/lisp/num_gmp.lisp b/src/lisp/num_gmp.lisp
> > index f4a022ad..212e9d40 100644
> > --- a/src/lisp/num_gmp.lisp
> > +++ b/src/lisp/num_gmp.lisp
> > @@ -838,11 +838,16 @@
> >  (sb-ext:lock-package "COMMON-LISP")))
> >
> >  (defun load-gmp-lib ()
> > -#-:WIN32 (ignore-errors (|quiet_load_alien| "libgmp.so") t)
> > -#+:WIN32 (if (ignore-errors (|quiet_load_alien| "libgmp-10.dll") t)
> > - t
> > - (ignore-errors (|quiet_load_alien|
> > - (BOOT::make-absolute-filename
> "/lib/libgmp-10.dll"))
> > t)))
> > +(setq system-gmp-name #+

Re: [fricas-devel] about sbcl-2.3.2 (package related) compile error

[oldk1331]

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 still existed issue on the Aldor side)
>
> What exactly do you mean here?
>
> At least I am relieved that your patch does seemingly not break the
> fricas-aldor interface.
>
> Ralf
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fricas-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/601f3797-8bfd-088d-a67e-9a1d1b68ad61%40hemmecke.org
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92z-YcU4WvOxiWaCpKws7wLQ%3DznufzWvSBHvWC_kBFbuQ%40mail.gmail.com.

[fricas-devel] Re: I get an when trying to make Fricas

[oldk1331]

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 free or 
corruption (!prev))
and if you check dmesg, there might be seg faults.  But seems that's not 
directly
linked with this error.

I think this is somewhat related with 
https://github.com/fricas/fricas/issues/57

The solution is same: remove "-n 0" from XVFB=... in configure and 
configure.ac

It is strange that we are still using "-n 0": first the help shows that it 
is deprecated
to use "-a" together with "-n"; second, it's easy to conflict with current 
DISPLAY
to use "0".

- Qian

On Thursday, October 27, 2022 at 7:42:07 AM UTC+8  wrote:

> Hi all,
> When trying to build Fricas, I get the following error when trying to make.
> My system is:
> Fedora 36
>
> Error:
> making explot2d.input
> parsing: ExPlot2DPolar
> writing:draw(sin(4*t/7),t = 0..14*%pi,coordinates == polar)
> Warning:  could not get the 9x15 font for messageFont
> Warning:  could not get the 8x13 font for buttonFont
> Warning:  could not get the 9x15 font for headerFont
> Warning:  could not get the 9x15 font for titleFont
> Warning:  could not get the 9x15 font for graphFont
> Warning:  could not get the 6x10 font for unitFont
> double free or corruption (!prev)
> parsing: ExPlot2DAlgebraic
> writing:draw(y^2 + y - (x^3 - x) = 0, x, y, range == [-2..2,-2..1])
> Warning:  could not get the 9x15 font for messageFont
> Warning:  could not get the 8x13 font for buttonFont
> Warning:  could not get the 9x15 font for headerFont
> Warning:  could not get the 9x15 font for titleFont
> Warning:  could not get the 9x15 font for graphFont
> Warning:  could not get the 6x10 font for unitFont
> parsing: ExPlot2DFunctions
> writing:draw(sin(tan(x)) - tan(sin(x)),x = 0..6)
> Warning:  could not get the 9x15 font for messageFont
> Warning:  could not get the 8x13 font for buttonFont
> Warning:  could not get the 9x15 font for headerFont
> Warning:  could not get the 9x15 font for titleFont
> Warning:  could not get the 9x15 font for graphFont
> Warning:  could not get the 6x10 font for unitFont
> parsing: ExPlot2DParametric
> writing:draw(curve(9 * sin(3*t/4),8 * sin(t)),t = -4*%pi..4*%pi)
> Warning:  could not get the 9x15 font for messageFont
> Warning:  could not get the 8x13 font for buttonFont
> Warning:  could not get the 9x15 font for headerFont
> Warning:  could not get the 9x15 font for titleFont
> Warning:  could not get the 9x15 font for graphFont
> Warning:  could not get the 6x10 font for unitFont
> /usr/bin/xvfb-run: line 186: kill: (375936) - No such process
> make[3]: *** [Makefile:689: explot2d.pht] Error 1
> make[3]: Leaving directory '/home/agnelo/Documents/Fricas/fr-build/src/doc'
> make[2]: *** [Makefile:772: copy-to-target] Error 2
> make[2]: Leaving directory '/home/agnelo/Documents/Fricas/fr-build/src/doc'
> make[1]: *** [Makefile:224: all-doc] Error 2
> make[1]: Leaving directory '/home/agnelo/Documents/Fricas/fr-build/src'
> make: *** [Makefile:250: all-src] Error 2
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/cdc8714a-0281-4af0-854d-0ed6cb1bd0ddn%40googlegroups.com.

Re: [fricas-devel] review request pr#93, pr#96

[oldk1331]

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 discussion.
> 
> Ralf
> 

Recently at least two of Waldek's reply to github is missing --
aka didn't show up on the web interface.  Consider he probably
only sent two dozens recently, the percentage is high.

Maybe we can have a github Bot to channel the communication,
I'll take a look at it.

- 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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/e4be9974-a101-be5d-b96d-76ba0dfc4412%40gmail.com.

Re: [fricas-devel] review request pr#93, pr#96

[oldk1331]

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 days ago and I hope to get reviews.
>>
>> https://github.com/fricas/fricas/pull/93
> 
> 93 looks OK.  ICARD has many problems so I was thinking if
> we should do some major fixup or just merge this one.
> But it is probably better just to merge this fix.
> 
>> https://github.com/fricas/fricas/pull/96
>>
>> For Paul's PR#96, I have verified his patch fixes the bug.
> 
> Hmm, AFAICS 96 is from you.  I wrote the following in comment
> section, but github apparently sent it to black hole:

Could you consider forwarding github replies to this list
in the future?

> I admit that it is not clear for me why you want this.  At least
> some of places that you want to modify comunicate with C code.
> And in C code all we have is FRICAS environment variable
> (we definitely do not have access to Lisp '$spadroot').
> 
> IIUC you wrote that passing environment variables on Mac OS is
> tricky.  Having some fallback is reasonable, but preferably
> this fallback should be in one place, at top of process tree.
> And once fallback is established it should be propagated
> down via environment.  My feeling is that in longer term
> is is better to learn how to propagate environment variables
> on Mac OS.  Otherwise, we risk that hacks which are reasonable
> as "point" solution spread out to many places creating
> hard to maintain mess.

The macOS environment variable passing issue is solved.

- 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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/89ca1aaa-5d05-f445-2bea-affe82e7187c%40gmail.com.

[fricas-devel] About ChangeLog Fwd: [fricas/fricas] prevent error message leakage in "ker2trigs" (PR #94)

[oldk1331]

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 ChangeLog entries after patch
review and before I commit it.

But I'd like to have a discussion about current ChangeLog policy.

Is manually updated ChangeLog still useful?
Is current git commit message good enough?
Shall we go for auto-generated ChangeLog from git commit before release?
Shall we go for a more informative commit message? (say kernel style)

- Qian

 Forwarded Message 
Subject:Re: [fricas/fricas] prevent error message leakage in
"ker2trigs" (PR #94)
Date:   Wed, 29 Jun 2022 02:58:07 -0700
From:   hebisch 
Reply-To:   fricas/fricas

To: fricas/fricas 
CC: Qian Yun , State change




On Tue, Jun 28, 2022 at 06:55:14PM -0700, Qian Yun wrote:
> Merged #94 into master.

When mereging please do not forget ChangeLog entries.

-- 
Waldek Hebisch

—
Reply to this email directly, view it on GitHub
, or
unsubscribe
.
You are receiving this because you modified the open/close state.Message
ID: 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/512b0ffe-7839-cb89-0442-2a06dc0e54b8%40gmail.com.

[fricas-devel] Re: Test; my recent posts were delayed (marked as spam)

[oldk1331]

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.
>
> And wonder if you meet this same issue.
>
> - 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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN90323%3DTVjpBUmPtnLFXMn3tAUUkGvNRaFO_OZJPhL5VYw%40mail.gmail.com.

[fricas-devel] Test; my recent posts were delayed (marked as spam)

[oldk1331]

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 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN93LRyFbbeLuxXOmz-PrMGDugqfmk_z43djuJ6Re0Vq6Hw%40mail.gmail.com.

Re: [fricas-devel] Is there a time frame for the next version of Fricas?

[oldk1331]

Hi Nasser:

Since you are building FriCAS from source,
so for next CAS integration tests, will you
use git version instead of 1.3.7?

- Qian

On Sat, May 14, 2022, 7:39 AM 'Nasser M. Abbasi' via FriCAS - computer
algebra system  wrote:

>
> >>>>
> Second, about the new patch. I wonder if you are running Sage
> on Windows or Linux? Is it easy to replace the FriCAS binary?
> Also, IIRC, the Sage compiles FriCAS with ecl instead of sbcl.
> Using sbcl may give a good performance boost. Also building
> with GMP may increase performance slightly. With better
> performance, we can expect less timeout results.
> >>>>>
>
> Hello Qian;
>
> When running CAS integration tests, I use Fricas build directly from
> sources outside of sagemath.
>
> Sources from
>
>
> https://sourceforge.net/projects/fricas/files/fricas/1.3.7/fricas-1.3.7-full.tar.bz2/download
>
> I run everything on Linux. Now using WSL 2.0 under windows 10 Linux
> subsystem
>
> ```
> >which fricas
> /usr/local/bin/fricas
> >fricas --version
> FriCAS 1.3.7
> based on sbcl 2.0.1.debian
> ```
>
> If I wanted to use Fricas that builds by sagemath, I would do, inside
> sagemath
>
> ./configure --enable-fricas
>
> And this gives when done the following
>  ```
> >which fricas
> /home/me/TMP/sage-9.6.rc4/local/bin/fricas
> >fricas --version
> FriCAS 1.3.7
> based on ecl 21.2.1
> ```
>
> So it is the first one above I will use for CAS integration tests. Not the
> version that comes with sagemath.
>
> I have to check if Fricas was build with GMP or not. I just followed the
> instructions to build fricas
> from source, and do not know now 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,
>>
>> First, so you are already starting a new process for each integral.
>> Then there's no problem of slow down caused by big kernel cache.
>>
>> Second, about the new patch. I wonder if you are running Sage
>> on Windows or Linux? Is it easy to replace the FriCAS binary?
>> Also, IIRC, the Sage compiles FriCAS with ecl instead of sbcl.
>> Using sbcl may give a good performance boost. Also building
>> with GMP may increase performance slightly. With better
>> performance, we can expect less timeout results.
>>
>> - Qian
>>
>> On 5/13/22 08:09, 'Nasser M. Abbasi' via FriCAS - computer algebra
>> system wrote:
>> > Hello  Qian;
>> >
>> > If I understand you, you are recommending that each call to integrate
>> > to Fricas from sagemath be done by first clearing all kernel cache in
>> > Fricas first?
>> >
>> > Well, it happens that this is what CAS integration test does. Because,
>> > sagemath
>> > does not have a direct way to do a timeout on an integrate call when
>> calling
>> > external CAS process (I need to look at their pexpect interface
>> > <https://groups.google.com/g/sage-devel/c/9_VdKmiu5Ts/m/mcUtUWOKAAAJ>
>> to
>> > see if
>> > that works with Fricas. I never used it before.
>> >
>> > So what CAS integration test does now is spawn a new process for each
>> > call to integrate
>> > and sets a timeout on the subprocess itself. This works.
>> >
>> > Here I show one sagemath script to test one integral. I also post the
>> > code for the script
>> > below and a link to it as well. If you have Sagemath and Fricas
>> > installed on your PC,
>> > then you can do
>> >
>> > ```
>> > >cd  CAS_integration_tests/
>> > >cd reports/
>> > >cd summer_2022/
>> > >sage ./test_one_integral_in_sage_direct.sage
>> > Test starting.
>> > after process start()..waiting to finish
>> > inside doTheIntegration integrand= sin(x)
>> > inside doTheIntegration x= x
>> > inside subprocess. integrate returned  -cos(x)
>> > process.join completed
>> > process completed in time. Read the result
>> > ['-cos(x)']
>> > finished, closing file
>> > ```
>> >
>> > The script test_one_integral_in_sage_direct.sage is
>> > ```
>> >
>> > #!/usr/bin/env sage
>> >
>> > #script to test one integral for Fricas, giac and maxima
>> > #spawns a process for each integral call, in order to do
>> > #timeout since sagemath does not direc

Re: [fricas-devel] future community collaboration tool (deprecating fricas-devel maillist)

[oldk1331]

>
>
> 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 know.
>

Hi Ralf, one way that I know to create Gmail account without phone number
(at least a few months ago) is that, create a new user in Android phone
(or Android VM, I presume).

- Best,
- 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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN90gxLYe%2B%3D4nSAR1VuM8jas0AL6Mpp4zZ6zUN72z7KjQxQ%40mail.gmail.com.

Re: [fricas-devel] hyperdoc fonts

[oldk1331]

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 install xfonts-100dpi
>
> without needing to reboot to have it working for Hyperdoc?
>
> Ralf
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fricas-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/12ce52d3-1108-89f9-0caa-66e9b88e3dc4%40hemmecke.org
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN93TB12KLUeNcxMFjk3gHjJMD53aw2qC2AEBouODbapGmw%40mail.gmail.com.

[fricas-devel] Re: package-call

[oldk1331]

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 newbie learning FriCAS and I have a question about 'package-calling' 
> a function.
>
> Exploring the library I've tried using riemannZeta, but the exposed 
> version seems to be a category (HyperDoc tells me that it comes from 
> SpecialFunctionCategory) so I guess that's why it doesn't get numerically 
> evaluated.
> The other version comes from an unexposed package 
> (FunctionalSpecialFunction), which I tried to package-call:
>
> riemannZeta(0.5+%i)$FSPECF(Complex(Float),Complex(Float))
>
> which has no valid type. The command ')d op riemannZeta' instructs me what 
> the parameters of FSPECF would be, but I obviously didn't understand.
>
> Generically, how to parametrize a more complex domain? Where to read to 
> understand what is needed? 
>
> Thank you!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/221f0fb5-c98c-4789-9eee-42d5b810c103n%40googlegroups.com.

Re: [fricas-devel] Help wnated: how to use )trace

[oldk1331]

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 qetaGrades
>
> Parameterized constructors traced:
>QETAMGP
>
> But then I get...
>
> (181) -> sspec := cofactInf(nn, rspec, m, t, idxs)
>   1 #(1 ((1 -1 -1)) NIL)
> 11 6
> (#1=(0 . 1) #2=(1 . 11)
>  #3=(1 . 2))
> #(3 4 0 6 0
>   #(#4=#:G439 #1#
> #2# #4#
> #4# #4# #3# #4#
> #(#(#(#(#(22
> ((11 -1 1))
>   NIL)
> 1 0
>
> #5=#2A((0 -1)
>
> (1 0))
>
> and there are many many MANY more line of output that I am not
> interested in. Looks like a description of the package itself.
> Would be perfectly enough, if I only see the "enter" and "leave"
> messages together with the function name.
>
> ")help trace" tells me that ")trace function" should actually do what I
> want, but FriCAS seemingly does not let activate it in an obvious way. :-(
>
> Well ")trace" is only for "developers, but even then it should get
> better documentation. Best with some working examples.
>
> Ralf
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fricas-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/6e8e7dc8-57f7-d6e7-3f90-6f310a6ad3b2%40hemmecke.org
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91af-bmjSe3pWvqfOEnhX_EK2B0rfTWRmB-98qi_3Y5fQ%40mail.gmail.com.

Re: [fricas-devel] Help wnated: how to use )trace

[oldk1331]

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) -> cuspToMatrix(cusp(0,1))
>
>+0  - 1+
> (167)  |  |
>+1   0 +
>
> (168) -> )trace cuspToMatrix
> cuspToMatrix is not a function
>
> Nothing is traced now.
>
> The description of ")help trace" suggests that I should add the complete
> internal name. But how to find out?
>
> The only thing I got to work was
>
> (168) -> )trace QEtaModularGammaPackage
>
> Parameterized constructors traced:
>QETAMGP
>
> The respective output shows
>
>   1
> which suggests the internal name, but otherwise the trace information is
> much to detailed to be useful in my case. And
>
> (168) -> )trace QEtaModularGammaPackage_.etaCofactorInfinity_,85
> QEtaModularGammaPackage.etaCofactorInfinity,85 is not a function
>
> Nothing is traced now.
>
> (168) -> )trace QEtaModularGammaPackage.etaCofactorInfinity_,85
>
> FriCAS does not understand the use of QEtaModularGammaPackage
>etaCofactorInfinity,85 here.
>
> So what exactly would I have to put after the )trace command to trace
> function f from package/domain/category C?
>
> Thank you in advance.
> Ralf
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fricas-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/d8f9ffbe-75f2-1298-d9e1-c5c1725f6fee%40hemmecke.org
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN905fiU9qU60VvypJXiMGQ%2BBMbY%2B9bYq0Kgvn0GwibeU6g%40mail.gmail.com.

Re: [fricas-devel] btscan2.boot query (is there a possible error in the code)

[oldk1331]

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 y)) ;; connects l2 to the end of l1
(rplacd x (cdr y)) ;; replace the end node of l1 by the end node of l2

;; now x is ((A B C D E K L M N O) O)

- Qian

On 9/26/21 23:12, Hill Strong wrote:
> 
> When looking at the function dqAppend found in the btscan2.boot file
> (given below)
> 
> dqAppend(x,y)==
>     if null x
>     then y
>     else if null y
>  then x
>  else
>   RPLACD (CDR x,CAR y)
>   RPLACD (x,    CDR y)
>   x
> what is the purpose of the line
> 
> RPLACD(CDR x,CAR y)
> 
> This appears to be entirely superfluous to the function. Is this
> correct? I have tried  these two lines in the interface on
> https://rextester.com/l/common_lisp_online_compiler with the following code
> 
> (setq l1 (list 'a 'b 'c 'd 'e))
> (print l1)
> (setq l2 (list 'k 'l 'm 'n 'o))
> (print l2)
> (rplacd (cdr l2) (car l1))
> (print l2)
> (rplacd l2 (cdr l1))
> (print l2)
> 
> and I get the results
> 
> (A B C D E)
> (K L M N O)
> (K L . A)
> (K B C D E)
> 
> Is this the expected results or is something else actually expected?
> 
> greetings
> 
> Hill Strong
> 
> -- 
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/ea73f865-45d0-4ad7-b600-859f9f7db9b7n%40googlegroups.com
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/2ac654f9-3111-072c-e599-b86bd4a7e01b%40gmail.com.

Re: [fricas-devel] release

[oldk1331]

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 solution
> proposed in more than a month, I think we should
> revert this change.
> --
>   Waldek Hebisch
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/20210621133639.GA13199%40math.uni.wroc.pl
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN907xrPv88hsjxeGHcpTDbn82XG_gftXbiW7ao77qsdqvA%40mail.gmail.com.

Re: [fricas-devel] changes to allow macOS packaging work again

[oldk1331]

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)"' >>
>> '${COMMAND}'.tmp ; \
>> + else \
>> +  echo FRICAS='"`dirname
>> $$0`/../$(fricas_lib)/fricas/target/$(target)"' >> '${COMMAND}'.tmp ; \
>> + fi \
>>  else \
>> echo FRICAS='"$(libdir)/fricas/target/$(target)"' \
>> >> '${COMMAND}'.tmp ; \
> 
> Hi Qian, I wonder why you wanted the 'dirname $$0' part?  It breaks
> internal 'fricas' script for its intended uses, in particular
> it causes problem reported by Gregory Vanuxem, that is failure
> of 'efricas'.  AFAICS you intended 'dirname $$0' part to be
> used only on Mac OS, but you need to double '$' for this.
> Doubling '$' fixes problem on other systems, but there remain
> question what 'dirname $$0' solves?  I think that even on
> Mac OS it does not work for internal 'fricas' script.
> 


Yes, you are right about the double '$' error.

About 'dirname $$0', that was intended to be used by DMG packaging.
Indeed it breaks traditional "make install" installation.  Let me find a
better solution.

- 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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/e7cbfbb5-2f0b-f99a-2a32-69876b2ccb55%40gmail.com.

Re: [fricas-devel] [windows] TMFORM and "spaces in PATH"

[oldk1331]

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 macro 'mk_DF' instead of using 'make_DF' function?
>
> Macro will always run at compile time, even in dumb compiler.
> Function may be delayed to runtime, at least partially defeating
> optimization.
>
> --
>   Waldek Hebisch
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/20210308162033.GA1217%40math.uni.wroc.pl
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN93QTce_DYJW-Hz8zhakS887cZ7qwdq6R7maT2%2B2b9Qw8Q%40mail.gmail.com.

Re: [fricas-devel] [windows] no sman on msys2/mingw64

[oldk1331]

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 strange memory
fault, which I'll look into later.  And right now, sman
from msys2 shell does not mix well with FriCASsys from
mingw64 shell.

I'll continue explore the possibility from "msys2 shell".

On 3/5/21 12:31 AM, Dima Pasechnik wrote:
> On Thu, Mar 4, 2021 at 4:26 PM Qian Yun  wrote:
>>
>> Wait a second, there are numerous packages on msys2/mingw64
>> that uses fork and pty, how does that happen?
> Could you point at any such package, with an URL?
>
> you probably mix it up with cygwin (which does support fork() etc)
>


On 3/5/21 1:18 AM, Waldek Hebisch wrote:
 >
 > IIUC msys uses (or maybe re-implements) Cygwin emulation
 > of fork and pty.  Fork is emulated in rather crude way
 > and tends to fail from time to time.  I did not look
 > how pty emulation works.
 >
 > My point was that we can with moderate effort avoid
 > use of fork.  ATM avoidning pty would be much more tricky.
 >

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92_byHEb3NNjDU9ZN2hG6EbFd8m7%2Bn%2B8t6GjWttKKoftw%40mail.gmail.com.

Re: [fricas-devel] CI failure, missing src/input/fftst.input

[oldk1331]

Hi Waldek,

The reason that your commit didn't trigger CI is that, you didn't verify
your github's linked email.

If you are doing this for privacy or other reasons, I fully understand.  If
not, would you mind to verify your github's email?

- Best,
- Qian

On Fri, Jan 29, 2021, 8:33 AM Waldek 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
>
> --
>   Waldek Hebisch
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/20210129003315.GA2309%40math.uni.wroc.pl
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92LgdLOR%3Du4_mPTGgU8XtdndmdvRNBMusmCstzcCoMnSA%40mail.gmail.com.

[fricas-devel] CI failure, missing src/input/fftst.input

[oldk1331]

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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91BMuDizDJwvpWcT3_6XsFEjdRm9ki3Tr_ei2kcBVPjtQ%40mail.gmail.com.

Re: [fricas-devel] github rebase

[oldk1331]

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
> Committer: oldk   2021-01-22 11:18:10
>
> or
>
> Author: Frédéric Chapoton   2021-01-22 11:11:51
> Committer: GitHub   2021-01-22 11:11:51
>
> Is it possible to use your usual git name and email for the Committer?
> Or doesn't let github enable us to select the committer?
> I would know how to set the committer locally, but on github? Doesn't it
> agree with your credentials?
>
> Ralf
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fricas-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/ca313964-8eff-c177-19f3-2ada8e73d350%40hemmecke.org
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91a5sSWo1ZFAnsW%3DqVKX1yrM7r5ce48oiDF4tWSew%2BY-g%40mail.gmail.com.

Re: [fricas-devel] Github PR merging strategy

[oldk1331]

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 receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN93e3CkvYsb%2BXbd6vb0qnPzX_HmcQhRFuO32WPf1M4r44A%40mail.gmail.com.

[fricas-devel] Github PR merging strategy

[oldk1331]

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 stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN90o8PfuJ3M0PAJqkxAFwH_7NwznyyPXxaDDB8UcqqFx6g%40mail.gmail.com.

Re: [fricas-devel] the issue of %iint generated by Fricas

[oldk1331]

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 b/src/algebra/integrat.spad
index bfcc8e0a..7d5e68d8 100644
--- a/src/algebra/integrat.spad
+++ b/src/algebra/integrat.spad
@@ -245,6 +245,33 @@
   not(member?(k, (tf := tower f))) then
k := find_int(k, tf)
   f := eval(f, [k], [v])
+  -- liint is a list of untranslated '%iint kernels.  If they are
+  -- parts of ekers, then we may solve them by recursion.
+  liint : List K := [k for k in otf | is?(operator k, '%iint) and
not member?(k, ekers)]
+  for k in reverse liint repeat
+  pos := position(ek +-> member?(k, tower(ek::F)), ekers)
+  if zero? pos then
+  error "integrate: untranslated %iint kernels"
+  ek := ekers.pos
+  ev := evals.pos
+  repeat
+  dek := D(ek::F, x)
+  -- assert the numerator of dek is a single kernel of '%iint
+  numKers := kernels numerator dek
+  if # numKers = 1 and is?(operator first numKers, '%iint) then
+  dev := D(ev, x)
+  coeff := 1/(first coefficients numer dek)::F
+  v := coeff * dev * denominator dek
+  if k::F = coeff * numerator dek then
+  f := eval(f, [k], [v])
+  break
+  else
+  ek := first numKers
+  ev := v
+  if not member?(k, tower(ek::F)) then break
+  else
+  -- print("currently can't handle this '%iint
kernel"::OutputForm)
+  break
   if not(empty? ltan) then
 ltemp := [tan2temp k for k in ltan]
 f := eval(f, ltan, [k::F for k in ltemp])

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/0700bb7c-d403-6cc5-5f55-cfb692a61835%40gmail.com.
diff --git a/src/algebra/integrat.spad b/src/algebra/integrat.spad
index bfcc8e0a..7d5e68d8 100644
--- a/src/algebra/integrat.spad
+++ b/src/algebra/integrat.spad
@@ -245,6 +245,33 @@ FunctionSpaceIntegration(R, F) : Exports == Implementation where
   not(member?(k, (tf := tower f))) then
k := find_int(k, tf)
   f := eval(f, [k], [v])
+  -- liint is a list of untranslated '%iint kernels.  If they are
+  -- parts of ekers, then we may solve them by recursion.
+  liint : List K := [k for k in otf | is?(operator k, '%iint) and not member?(k, ekers)]
+  for k in reverse liint repeat
+  pos := position(ek +-> member?(k, tower(ek::F)), ekers)
+  if zero? pos then
+  error "integrate: untranslated %iint kernels"
+  ek := ekers.pos
+  ev := evals.pos
+  repeat
+  dek := D(ek::F, x)
+  -- assert the numerator of dek is a single kernel of '%iint
+  numKers := kernels numerator dek
+  if # numKers = 1 and is?(operator first numKers, '%iint) then
+  dev := D(ev, x)
+  coeff := 1/(first coefficients numer dek)::F
+  v := coeff * dev * denominator dek
+  if k::F = coeff * numerator dek then
+  f := eval(f, [k], [v])
+  break
+  else
+  ek := first numKers
+  ev := v
+  if not member?(k, tower(ek::F)) then break
+  else
+  -- print("currently can't handle this '%iint kernel"::OutputForm)
+  break
   if not(empty? ltan) then
 ltemp := [tan2temp k for k in ltan]
 f := eval(f, ltan, [k::F for k in ltemp])

Re: [fricas-devel] the issue of %iint generated by Fricas

[oldk1331]

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
> is not intended to be visible to an enduser.
> 
> Ralf
> 

Hi Ralf,

Let the value of  %iint(v1,v2,...,vn,f1,f2,...,fn) be f,
then we have

D(f,v1)=f1
D(f,v2)=f2
...
D(f,vn)=fn

This can be seen from 'dviint' from liouv.spad.

If you trace 'postSubst' in 'integrat.spad', you can find
that these '%iint' are nested and can be solved recursively.

I already have some code to solve
integrate(polylog(3,x),x)
and
integrate(x^2*(a+b*log(c*x^n))*polylog(3,e*x),x)
But missing other corner cases which I don't know if we'll encounter later.

I'll post my code when I polish it more.

- 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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/c9fa9059-7d67-d8e0-abbb-571d9f73e12e%40gmail.com.

Re: [fricas-devel] the issue of %iint generated by Fricas

[oldk1331]

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 example variable 'a%b'
to latex output.


> > 2. As Waldek said, '%iint" should be used only internally.  But the
> > following workaround prints '%iint' as 'iint':
>
> What would that help? Whether it prints as %iint or iint, I still would
> not know how to interpret that FriCAS is returning. What does '%iint'
> stand for?
>
> Ralf
>

It solves Nasser's problem at hand...

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91FQt%3DkifJ7EVHNnvD3iGp2_JG_V0R1N3vbWPEO_Fa8UA%40mail.gmail.com.

Re: [fricas-devel] the issue of %iint generated by Fricas

[oldk1331]

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 a/src/algebra/liouv.spad b/src/algebra/liouv.spad
index 420845b9..c070ca28 100644
--- a/src/algebra/liouv.spad
+++ b/src/algebra/liouv.spad
@@ -221,6 +221,7 @@
 derivative(opli2, (z1 : F) : F +-> log(z1) / (1 - z1))
 derivative(opfis, (z1 : F) : F +-> sin(pi()*z1^2/(2::F)))
 derivative(opfic, (z1 : F) : F +-> cos(pi()*z1^2/(2::F)))
+display(opiint, (z1 : List O) : O +-> prefix('iint::O, z1))
 setProperty(opint, SPECIALEQUAL, eqint@((K, K) -> Boolean) pretend
None)
 setProperty(opint, SPECIALDIFF, dvint@((List F, SE) -> F) pretend None)
 setProperty(opiint, SPECIALDIFF, dviint@((List F, SE) -> F) pretend
None)


On 1/9/21 5:11 AM, 'Nasser M. Abbasi' via FriCAS - computer algebra
system wrote:
> Hello. I use sagemath to call fricas integrate as part of build the
> independent CAS integration tests.
> 
> I am not running the tests using sagemath 9.2 against Fricas 1.3.6
> 
> There are antiderivatives generated by Fricas which uses %iint.
> 
> This cause a problem when converted to Latex for the report.
> 
> Here is a bug report on this against sagemath 
> 
> https://ask.sagemath.org/question/48409/possible-invalid-latex-translation-from-fricas-result/
> 
> https://trac.sagemath.org/ticket/28630  
> 
> But not fixed yet and do not know when it will be fixed.
> 
> Is it possible that fricas not use %iint as that causes problem
> converting to Latex. 
> 
> Here is an example
> 
> sage: x,a,b,n=var('x a b n')
> sage: integrate(x^2*(a+b*log(c*x^n))*polylog(3,e*x),x, algorithm="fricas")
> -1/972*(4*(4*b*n - 3*a)*x^3*e^3 + 9*(3*b*n - 2*a)*x^2*e^2 + 36*(2*b*n -
> a)*x*e + 36*(3*b*n*x^3*e^3*log(x) + 3*b*x^3*e^3*log(c) - (2*b*n -
> 3*a)*x^3*e^3 - b*n)*%iint(x, -log(-x*e + 1)/x) - 36*((b*n - a)*x^3*e^3 -
> b*n + a)*log(-x*e + 1) - 6*(2*b*x^3*e^3 + 3*b*x^2*e^2 + 6*b*x*e -
> 6*(b*x^3*e^3 - b)*log(-x*e + 1))*log(c) - 6*(2*b*n*x^3*e^3 +
> 3*b*n*x^2*e^2 + 6*b*n*x*e - 6*(b*n*x^3*e^3 - b*n)*log(-x*e + 1))*log(x)
> - 108*(3*b*n*x^3*e^3*log(x) + 3*b*x^3*e^3*log(c) - (b*n -
> 3*a)*x^3*e^3)*polylog(3, x*e))*e^(-3)
> 
> After converting to Latex it gives (using sagemath latex command)
> 
> -\frac{4 \, {\left(4 \, b e^{3} n - 3 \, a e^{3}\right)} x^{3} + 9 \,
> {\left(3 \, b e^{2} n - 2 \, a e^{2}\right)} x^{2} + 36 \, {\left(2 \, b
> e n - a e\right)} x + 36 \, {\left(3 \, b e^{3} n x^{3}
> \log\left(x\right) + 3 \, b e^{3} x^{3} \log\left(c\right) - {\left(2 \,
> b e^{3} n - 3 \, a e^{3}\right)} x^{3} - b n\right)} {\rm %iint}\left(e,
> x, -\frac{\log\left(-e x + 1\right)}{e}, -\frac{\log\left(-e x +
> 1\right)}{x}\right) - 36 \, {\left({\left(b e^{3} n - a e^{3}\right)}
> x^{3} - b n + a\right)} \log\left(-e x + 1\right) - 6 \, {\left(2 \, b
> e^{3} x^{3} + 3 \, b e^{2} x^{2} + 6 \, b e x - 6 \, {\left(b e^{3}
> x^{3} - b\right)} \log\left(-e x + 1\right)\right)} \log\left(c\right) -
> 6 \, {\left(2 \, b e^{3} n x^{3} + 3 \, b e^{2} n x^{2} + 6 \, b e n x -
> 6 \, {\left(b e^{3} n x^{3} - b n\right)} \log\left(-e x +
> 1\right)\right)} \log\left(x\right) - 108 \, {\left(3 \, b e^{3} n x^{3}
> \log\left(x\right) + 3 \, b e^{3} x^{3} \log\left(c\right) - {\left(b
> e^{3} n - 3 \, a e^{3}\right)} x^{3}\right)} {\rm polylog}\left(3, e
> x\right)}{972 \, e^{3}}
> 
> And the above do not compile due to %iint, as % is treated as comment
> and all the latex after that is lost giving latex error.
> 
> Is there a way for FriCAS not to use %  in the output it generates? 
> Each time I have to edit the latex by hand and add \% everywhere they show
> 
> May be this is not possible, But I thought to just ask.
> 
> Thanks
> --Nasser

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/2266c422-5328-3c65-44f1-437fe7b22bca%40gmail.com.

[fricas-devel] Re: [BUG] another case of falsely claim an integral is not integrable

[oldk1331]

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 reason that "extendedEuclidean" gives wrong result is that
> something wrong happened earlier: there are expressions with
> the same appearance but have different kernel underneath.
>
> The creation of different kernels happens at "trigs2explogs"
> in "integrate" in integrat.spad.
>
> The definition of "trigs2explogs" seems alright, still it's
> unknown why the same input may produce different kernels.
>
> If we replace
>  gg := eval(gg0, tgg0, tgg1)
> in integrat.spad with
>  gg := trigs2explogs(gg0, [])
> then this bug disappears.  But I'm still not clear about the
> root cause of this bug.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91tvF4HV_qW4sVmkVSFptdqqjQHpDiHC%3DDeaXqY2bJXpA%40mail.gmail.com.

[fricas-devel] [PATCH] add GitHub Actions script

[oldk1331]

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:
branches: [ master ]

jobs:
  build:

runs-on: ubuntu-20.04

steps:
- uses: actions/checkout@v2
- name: install dependencies
  run: sudo apt-get install sbcl libxpm-dev
- name: configure
  run: ./configure --with-lisp=sbcl --with-gmp --with-x
- name: make
  run: make -j2 --output-sync
- name: make check
  run: make check -j2 --output-sync

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/83532d8d-1f99-a7fc-58be-e713e6519008%40gmail.com.

Re: [fricas-devel] Tips and tricks for building FriCAS in mingw64 on windows

[oldk1331]

Hi Greg,

Just to clarify, the credit of https://github.com/nilqed/fricas_w32
goes to Kurt Pagani.

- Qian

On 9/22/20 8:17 PM, Grégory Vanuxem wrote:
> Hello Qian, *,
> 
> Sorry I forgot to say thank you. I'm happy it works nice.
> 
> And yes it's the same installer. I looked at 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>> a écrit :
> 
> 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 script to build a self installer if Waldek and others
> > want a self installer for download.
> > It supports uninstallation via start menu or configuration panel
> > (registry key), icons in start menu etc.
> >
> > If you want you can test the installer and remove FriCAS easily, the
> > FriCAS self installer is available here:
> >
> 
> https://drive.google.com/file/d/1Ir7p6UF6O13QYh-bHqmwbwPTBr38Kn33/view?usp=sharing
> >
> > I would be happy if you can test it, though I need to update the
> > FriCAS version. I hesitate between a stable release or the lastest
> > GitHub version.
> >
> > I think it would be good to provide this type of installer to "a give
> > it a try" to Windows users even if it has no graphics nor hyperdoc.
> > If they like FriCAS or are more curious and they own Windows 10 they
> > can switch to a full FriCAS with graphics and Hyperdoc or only in
> > terminal mode on WSL 2. I wrote in the past two tutorials to build
> > FriCAS on WSL 2 with or without Xorg:
> > https://groups.google.com/g/fricas-devel/c/k-k0TNsn2ro/m/UUgmR0cPBQAJ
> > It explains also what is needed to be installed on MSYS2.
> >
> > Cheers,
> >
> > __
> > Greg

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/2e73c602-aab0-8cfb-5a91-0edcd67dce4e%40gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

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 relevant parts.
> >
> > Hi Waldek, I'm afraid you forget to include the attachment.
> >
> Oops, second time.
> --
>   Waldek Hebisch
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/20200909103047.GA39118%40math.uni.wroc.pl
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN90XS9-z%3DKfpdL%3DNQxs3oT_sPXBzF63DnZEusdsa2OHejQ%40mail.gmail.com.

Re: [fricas-devel] Documentation patches

[oldk1331]

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 more effectively.

Once this is merged, I'd like to improve this documentation
book more.

Best,
Qian

On 9/7/20 12:35 AM, Ralf Hemmecke wrote:
> BTW, note that for compiling the book you must have the following
> packages installed:
> 
> epsf
> verbatim
> hyperref
> color
> listings
> makeidx
> xparse
> tikz
> framed
> amsmath
> tensor
> mleftright
> 
> Ralf
> 

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/4abe41a3-6c8b-ec67-e8e3-dcd9e813ea1d%40gmail.com.

Re: [fricas-devel] Tips and tricks for building FriCAS in mingw64 on windows

[oldk1331]

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 script to build a self installer if Waldek and others
> want a self installer for download.
> It supports uninstallation via start menu or configuration panel
> (registry key), icons in start menu etc.
> 
> If you want you can test the installer and remove FriCAS easily, the
> FriCAS self installer is available here:
> https://drive.google.com/file/d/1Ir7p6UF6O13QYh-bHqmwbwPTBr38Kn33/view?usp=sharing
> 
> I would be happy if you can test it, though I need to update the
> FriCAS version. I hesitate between a stable release or the lastest
> GitHub version.
> 
> I think it would be good to provide this type of installer to "a give
> it a try" to Windows users even if it has no graphics nor hyperdoc.
> If they like FriCAS or are more curious and they own Windows 10 they
> can switch to a full FriCAS with graphics and Hyperdoc or only in
> terminal mode on WSL 2. I wrote in the past two tutorials to build
> FriCAS on WSL 2 with or without Xorg:
> https://groups.google.com/g/fricas-devel/c/k-k0TNsn2ro/m/UUgmR0cPBQAJ
> It explains also what is needed to be installed on MSYS2.
> 
> Cheers,
> 
> __
> Greg

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/807bc75c-3531-8fa1-2a75-5e5515b01196%40gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

> 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" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/c759384e-e6de-74ca-8a01-11d8c2128ad0%40gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

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
>> for newer gcc/glibc on other systems as well), so it
>> actually checks for buffer overflow in 'strcpy', so the
>> error message I described in the first mail still presents,
>> so we need to change sockio-c.c#929 to
>>
>> strncpy(server[1].addr.u_addr.sa_data, name, ??);
>>
>> I'm not sure about the struct layout here, which number
>> should be put there?
> 
> 30.  However, I think that attached patch is better.
> 

OK, I tested it and found 2 issues:

1. you need to change "open_server" as well.
2. the memset destroys the first 2 bits of the addr struct,
causing failure to "bind".

(BTW, isn't strncpy theoretically safer?)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/0418b271-0830-1a82-4d52-fe045aaf3eb9%40gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

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 lot of C code uses it.  So
>> I see no point of going in direction you propose.
>>
> 
> OK, I agree with your explanation now, please commit
> your solution.
> 
> - Qian
> 

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
for newer gcc/glibc on other systems as well), so it
actually checks for buffer overflow in 'strcpy', so the
error message I described in the first mail still presents,
so we need to change sockio-c.c#929 to

strncpy(server[1].addr.u_addr.sa_data, name, ??);

I'm not sure about the struct layout here, which number
should be put there?

- 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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/58afe5e0-ae20-a0cc-ecc2-2870454f5765%40gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

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 propose.
> 

OK, I agree with your explanation now, please commit
your solution.

- 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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/41c14c38-16b5-ffb3-9e7f-2f06d3a7f7f0%40gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

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 is 2^22, around 4 million.
> 
> I would not count too much on this limit.  I have heard that
> currently 32GB modules are resonably priced.  With such
> modules cheap 128 GB home machine is possible.  With
> multiprocessor (server) board 512GB should be easily
> available.  Such machines may support several million
> processes.  While demand for large number of true
> processes is probably low, IIUC Linux allocated thread
> identifiers from the same pool.  At least some folks
> tried to run with really large number of threads.  So
> I would expect that some people will increase the limit...
> 

With 512G memory and 4 million processes, so each process
can get 128K memory?  Besides, process creation is expensive,
it's never a good idea in practice to have so many process.

The linux kernel seems to indicate that each core can
support 1k processes, so 4M limit seems pretty
reasonable in a few decades.

Thread identifiers is different, see comment below.

So I believe my following patch is relatively simple
to address the original bug, and it is future-proof
for at least 20 years, and it's easily extendable
beyond that.

- Qian

diff --git a/src/lib/sockio-c.c b/src/lib/sockio-c.c
index 30e0eba5..e9d8a02e 100644
--- a/src/lib/sockio-c.c
+++ b/src/lib/sockio-c.c
@@ -857,9 +857,17 @@
 int
 make_server_name(char *name,char * base)
 {
+  /* Try to fit the contents of 'name' into char[14],
+ which is Sock::addr::u_addr::sa_data.
+ Normally 'base' is "/tmp/.x", so that leaves room
+ for 6 chars to put 'spad_server_number'/'SPADNUM',
+ which is the PID of sman.  So use hexadecimal to
+ represent PID.
+  */
   char *num;
+  int pid;
   if (spad_server_number != -1) {
-sprintf(name, "%s%d", base, spad_server_number);
+sprintf(name, "%s%x", base, spad_server_number);
 return 0;
   }
   num = getenv("SPADNUM");
@@ -869,7 +877,8 @@
 */
 return -1;
   }
-  sprintf(name, "%s%s", base, num);
+  pid = atoi(num);
+  sprintf(name, "%s%x", base, pid);
   return 0;
 }


=include/linux/threads.h
/*
 * A maximum of 4 million PIDs should be enough for a while.
 * [NOTE: PID/TIDs are limited to 2^30 ~= 1 billion, see FUTEX_TID_MASK.]
 */
#define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \
(sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))

/*
 * Define a minimum number of pids per cpu.  Heuristically based
 * on original pid max of 32k for 32 cpus.  Also, increase the
 * minimum settable value for pid_max on the running system based
 * on similar defaults.  See kernel/pid.c:pidmap_init() for details.
 */



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/15f1512c-9094-9272-0eee-ac7f92416f50%40gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

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:
> > Okay, I take a different approach and try
> > to workaround this problem in function
> > "make_server_name":
> >
> > diff --git a/src/lib/sockio-c.c b/src/lib/sockio-c.c
> > index 30e0eba5..a168129f 100644
> > --- a/src/lib/sockio-c.c
> > +++ b/src/lib/sockio-c.c
> > @@ -857,9 +857,21 @@
> >  int
> >  make_server_name(char *name,char * base)
> >  {
> > +  /* Try to fit the contents of 'name' into char[14],
> > + which is Sock::addr::u_addr::sa_data.
> > + Normally 'base' is "/tmp/.x", so that leaves room
> > + for 6 chars to put 'spad_server_number'/'SPADNUM',
> > + which is the PID of sman.  So use hexadecimal when
> > + the PID is over 10^6.
> > +  */
>
> Sorry, this is problematic:
>
> 1) 80 hexadecimal is 8388608, so two different numbers give
>the same name.  The whole point of using PID is to make
>sure there are no accidental collisions
> 2) Hexadecimal buys us only factor of about 16 in magnitude.
>Wait few years and this will be not enough (or may be
>insufficient even now).  In padding hack I made sure that
>we have place for 64-bit PID.
>
> One may have objections to padding hack, but practicaly it
> is more likely to work in long term than the proposal above.
>
> --
>   Waldek Hebisch
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/20200823120148.GA25524%40math.uni.wroc.pl
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92BotK_y%3DT2eYhV%2BHetXiwV5-bJFAGwoc3Fzaj47Orp_g%40mail.gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

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 approach and try
> > to workaround this problem in function
> > "make_server_name":
> >
> > diff --git a/src/lib/sockio-c.c b/src/lib/sockio-c.c
> > index 30e0eba5..a168129f 100644
> > --- a/src/lib/sockio-c.c
> > +++ b/src/lib/sockio-c.c
> > @@ -857,9 +857,21 @@
> >  int
> >  make_server_name(char *name,char * base)
> >  {
> > +  /* Try to fit the contents of 'name' into char[14],
> > + which is Sock::addr::u_addr::sa_data.
> > + Normally 'base' is "/tmp/.x", so that leaves room
> > + for 6 chars to put 'spad_server_number'/'SPADNUM',
> > + which is the PID of sman.  So use hexadecimal when
> > + the PID is over 10^6.
> > +  */
>
> Sorry, this is problematic:
>
> 1) 80 hexadecimal is 8388608, so two different numbers give
>the same name.  The whole point of using PID is to make
>sure there are no accidental collisions
> 2) Hexadecimal buys us only factor of about 16 in magnitude.
>Wait few years and this will be not enough (or may be
>insufficient even now).  In padding hack I made sure that
>we have place for 64-bit PID.
>
> One may have objections to padding hack, but practicaly it
> is more likely to work in long term than the proposal above.
>
> --
>   Waldek Hebisch
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/20200823120148.GA25524%40math.uni.wroc.pl
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91BHrHaW%2BXK5u%3Dc0NA_a2xpzwgOFS%2B3THoBsQ%3DaxV35Cw%40mail.gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

Okay, I take a different approach and try
to workaround this problem in function
"make_server_name":

diff --git a/src/lib/sockio-c.c b/src/lib/sockio-c.c
index 30e0eba5..a168129f 100644
--- a/src/lib/sockio-c.c
+++ b/src/lib/sockio-c.c
@@ -857,9 +857,21 @@
 int
 make_server_name(char *name,char * base)
 {
+  /* Try to fit the contents of 'name' into char[14],
+ which is Sock::addr::u_addr::sa_data.
+ Normally 'base' is "/tmp/.x", so that leaves room
+ for 6 chars to put 'spad_server_number'/'SPADNUM',
+ which is the PID of sman.  So use hexadecimal when
+ the PID is over 10^6.
+  */
   char *num;
+  int pid;
   if (spad_server_number != -1) {
-sprintf(name, "%s%d", base, spad_server_number);
+if (spad_server_number < 100){
+  sprintf(name, "%s%d", base, spad_server_number);
+} else {
+  sprintf(name, "%s%x", base, spad_server_number);
+}
 return 0;
   }
   num = getenv("SPADNUM");
@@ -869,7 +881,12 @@ make_server_name(char *name,char * base)
 */
 return -1;
   }
-  sprintf(name, "%s%s", base, num);
+  pid = atoi(num);
+  if (pid < 100) {
+sprintf(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 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 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/82f035d2-7280-dbaa-abe2-07dbe0d625a5%40gmail.com.
diff --git a/src/lib/sockio-c.c b/src/lib/sockio-c.c
index 30e0eba5..a168129f 100644
--- a/src/lib/sockio-c.c
+++ b/src/lib/sockio-c.c
@@ -857,9 +857,21 @@ close_socket(fricas_socket socket_num, char *name)
 int
 make_server_name(char *name,char * base)
 {
+  /* Try to fit the contents of 'name' into char[14],
+ which is Sock::addr::u_addr::sa_data.
+ Normally 'base' is "/tmp/.x", so that leaves room
+ for 6 chars to put 'spad_server_number'/'SPADNUM',
+ which is the PID of sman.  So use hexadecimal when
+ the PID is over 10^6.
+  */
   char *num;
+  int pid;
   if (spad_server_number != -1) {
-sprintf(name, "%s%d", base, spad_server_number);
+if (spad_server_number < 100){
+  sprintf(name, "%s%d", base, spad_server_number);
+} else {
+  sprintf(name, "%s%x", base, spad_server_number);
+}
 return 0;
   }
   num = getenv("SPADNUM");
@@ -869,7 +881,12 @@ make_server_name(char *name,char * base)
 */
 return -1;
   }
-  sprintf(name, "%s%s", base, num);
+  pid = atoi(num);
+  if (pid < 100) {
+sprintf(name, "%s%s", base, num);
+  } else {
+sprintf(name, "%s%x", base, pid);
+  }
   return 0;
 }
 

[fricas-devel] Tips and tricks for building FriCAS in mingw64 on windows

[oldk1331]

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 SBCL in a path that doesn't include spaces,
for example, "C:\SBCL\".

2. Use "MSYS2 MinGW 64-bit" instead of
"MSYS2 MSYS" from the windows start menu,
otherwise you will encounter errors with SBCL.

3. Default memory configuration is not enough
for SBCL to compile TMFORM.lsp, so you need something like:

./configure --with-lisp="/c/SBCL/sbcl.exe --dynamic-space-size 4000"

4. Anti-virus software may slow down the process,
so add "C:\msys64" to the exclusion path of
anti-virus software.

- 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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/9b3f264d-1598-b62f-f2b9-c55930574aa1%40gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

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 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/97c2cd42-8438-89d5-d631-91d7f31fa146%40gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

>
>
> > 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
> should fix problem that you reported.
>
>
I consider "adding unused field" a hack and I
prefer sockaddr_un.

In ideal world we should test on all supported systems.
> Practically, sockaddr_un is pretty standard Unix things,
> so once we get if working on Linux (that is there is
> no crude errors) what remains is Windows.  As I wrote,
> WSL is not a problem, and if Mingw works I would
> assume that there are no extra problem with Cygwin.
> However, IIUC 32-bit Mingw has differences compared
> to 64-bit one, so we should test on both.
>
>
Ok, I'll try to test sockaddr_un on mingw32
and mingw64 then.

BTW, win10 recently supports AF_UNIX natively.
Still on mingw I guess it translates the code somehow.

P.S, on mingw we don't have graphics, so the
only purpose of sman is to provide line editing (clef)?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92K5%2BnXhA8%2BZ0YqT%2BCefqMPbfdSA8YYYFABtZ7%3DB--d%3DQ%40mail.gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

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 platforms.  WSL emulates Linux, so
> it should be enough to treat it as Linux.  Mingw
> uses native Windows calls and AFAIK that is
> different from Linux.  In particular AFAIK
> instead of Unix domain sockets Windows has
> "local" sockets which offer similar functionality,
> but require somewhat different code.  But
> for deeper information one should look into
> Microsoft documentation.
>

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?


> Could you say what exacly you tried?  And have you
> any idea what was so slow?  In particular,
> at what stage build was when you interrupted it?
>

I'm using msys2.  The shell is extremely slow.
Probably due to anti-virus software (I can't
disable it, long story).  I gave up at ./configure,
it's 100x slower than Linux. I might try again in
VM some other time.


> BTW.  Some info I have is rather old.  But I am
> trying to keep old things working.  As I wrote,
> on Windows I depend on info from others.  Few
> days ago I got old Linux machine running.  Now
> I can say that current trunk builds with no
> problem on 32-bit Linux from about 2008 using
> sbcl 1.0.16.
>
> --
>   Waldek Hebisch
>

Well, sometimes "keep old things working"
hinders progress...

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN928D%2BnJPxQXh4ULY_H1NpPa2xDdM8R1rfgXPH2J5N7Trw%40mail.gmail.com.

Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

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 cleaner would be to use
> 'sockaddr_un' instead of 'sockaddr' (and include 'sys/un.h').
> But Windows needs different declarations.  Also, in 'sockio-c.c'
> theorticaly it would be safer to write:
>
>  (struct sockaddr *)([1].addr)
>
> instead of '[1].addr.u_addr'.
>
> --
>   Waldek Hebisch
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/20200729022152.GA38001%40math.uni.wroc.pl
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92y1nKKwsRT61VJDb9no9q-8nS_5%3DMomemBfdPyJ063rA%40mail.gmail.com.

[fricas-devel] an interesting bug, regarding sman (low level C stuff)

[oldk1331]

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
"/tmp/.i"+getpid(), so on my system PID is
over a million, causing buffer overflow
in strcpy.

I wonder what's the best way to solve this
issue, and other C-string buffer overflow
in our code base.

Best wishes,
- 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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/d3a82aed-c0f1-1540-978a-c1c901fdcfb7%40gmail.com.

Re: [fricas-devel] serious bug in integrate. Fails first time, OK second time. 1.3.6 version

[oldk1331]

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 detected in 'split' in MONOTOOL.  The actual error is
> in 'gcd': first 'gcd' returns wrong result, it gives 1 while
> polynomial has multiple factors.  The second 'gcd' looks is OK.
>
> It is not clear if change above introduced bug, it is more
> likely that it merely triggered already present bug.
>
> --
>   Waldek Hebisch
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/20200327152537.GA9372%40math.uni.wroc.pl
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN9026_6%2BiHTzp05mnyCWc%3Dc5WRDgJhJ11COH8kMZLd3p_g%40mail.gmail.com.

Re: [fricas-devel] serious bug in integrate. Fails first time, OK second time. 1.3.6 version

[oldk1331]

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 := monomials(up)

Don't know why though.

On 3/24/20 4:03 AM, 'Nasser M. Abbasi' via FriCAS - computer algebra
system wrote:
> Could someone please explain why this call to integrate fails first
> time, but works second time?
> 
> Running 1.3.6 on Linux Manjaro under Virtual box
> 
>>fricas
> Checking for foreign routines
> FRICAS="/usr/local/lib/fricas/target/x86_64-linux-gnu"
> spad-lib="/usr/local/lib/fricas/target/x86_64-linux-gnu/lib/libspad.so"
> foreign routines found
>                        FriCAS Computer Algebra System 
>                             Version: FriCAS 1.3.6
>                  Timestamp: Mon 09 Mar 2020 12:35:03 PM CDT
> 
> (1) -> setSimplifyDenomsFlag(true)       
> 
>    (1)  false
>                                                                 Type:
> Boolean
> (2) -> integrate((b*x + a)^(3/2)*(d*x + c)^(5/2)/x^7,x)
>  
>    >> Error detected within library code:
>    "failed" of mode
> Union(SparseUnivariatePolynomial(Expression(Integer)),"failed") cannot
> be coerced to mode SparseUnivariatePolynomial(Expression(Integer))
> 
> (2) -> integrate((b*x + a)^(3/2)*(d*x + c)^(5/2)/x^7,x)
> 
> 
> No error. Gives result ok second time.
> Thanks
> --Nasser
> 
> -- 
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/26d92ddd-56c9-4514-bb30-a05dd0a02ad4%40googlegroups.com
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/014fa155-d087-0ef3-fb94-67018e51f580%40gmail.com.

Re: [fricas-devel] Switching to Git

[oldk1331]

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 possible for master branch. It's doable for PR or if
we regularly merge from devel branch.  I think we can use master directly
though, with CI we can quickly discover problems and fix them.

I would anyway have to run a local build, because I have no idea how we
> can setup auto compilation libfricas.al, since that would require the
> installation of Aldor.
>
> Ralf
>

It should be possible to do aldor build on CI too, but that'll take a long
time right?  How long do you spend on such a test with aldor?

-- 
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/f30f55e0-104a-e1e2-0140-c54af3280802%40hemmecke.org
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92ME72VSPFp7VnX6%3D7VvqZhzXHtxOWbYEPtGKra8SRhFg%40mail.gmail.com.

Re: [fricas-devel] Re: FriCAS 1.3.6 is released

[oldk1331]

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
>
> https://github.com/sbcl/sbcl/commit/52a9f9bac0dad80d003f289450a8ddd8c37b86b6
> is the fix.
>
> If that is correct then sbcl 1.5.7 already contains the fix.
>
> Hope that helps.
>
> Ralf
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fricas-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/84699f82-7f8c-cdd1-ea0b-e61692125a1b%40hemmecke.org
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92rsQjiRd54%3Dc5wfjJ%2Bs2Q3SsazvKwwMi-VxGzSFqNEHw%40mail.gmail.com.

Re: [fricas-devel] Switching to Git

[oldk1331]

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 both at Sourceforge and at Github.
>
> My intent is to give write access to repository to people
> who had write access at Sourceforge.  I have sent
> Github invitations to I hope correct accounts.
>
> Consider Sourceforge SVN as read-only snapshot from the time
> of switch.  It will _not_ be updated and at some time in
> the future it may go away.
>
> --
>   Waldek Hebisch
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/20200320141102.GB5317%40math.uni.wroc.pl
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN93m45xbG028ktAoTUxBLgfVzysW2RmjmgTy_uw42sAurA%40mail.gmail.com.

Re: [fricas-devel] Re: fyi, new issue with FriCAS<->sagemath interface

[oldk1331]

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
> just any other variable for FriCAS)

Seems fixed in SVN repo? Though I'm not sure which commit fixed it.

(1) -> integrate((%i*a*tan(d*x + c) + a)*sec(d*x + c)^10, x)

   (1)
 %i d x + %i c 10 %i d x + %i c 8
   64512 %i a (%e )   + 53760 %i a (%e )
 +
 %i d x + %i c 6 %i d x + %i c 4
   30720 %i a (%e )  + 11520 %i a (%e )
 +
%i d x + %i c 2
   2560 %i a (%e )  + 256 %i a
  /
%i d x + %i c 20 %i d x + %i c 18
   315 d (%e )   + 3150 d (%e )
 +
  %i d x + %i c 16  %i d x + %i c 14
   14175 d (%e )   + 37800 d (%e )
 +
  %i d x + %i c 12  %i d x + %i c 10
   66150 d (%e )   + 79380 d (%e )
 +
  %i d x + %i c 8  %i d x + %i c 6
   66150 d (%e )  + 37800 d (%e )
 +
  %i d x + %i c 4 %i d x + %i c 2
   14175 d (%e )  + 3150 d (%e )  + 315 d
Type:
Union(Expression(Complex(Integer)),...)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/9f4e39f5-0e1f-e174-69a4-749b71709a1d%40gmail.com.

Re: [fricas-devel] Re: Fricas debian

[oldk1331]

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)
+;; do not embed sbcl/interpsys pathname into fasl files
+#+:sbcl(setf sb-ext:*runtime-pathname* nil)
 (compile-file f :output-file (relative-to-absolute output-file)))

 (defun fricas_compile_fasl (f output-file)


- Qian

On 1/10/20 12:21 AM, Ralf Hemmecke wrote:
>>> #!/tmp/hemmecke/[more stuff]/bin/interpsys --script
>>>
>>> as the first line?
>>
>> AFAIK this is feature of sbcl: you can make .fasl file executable
>> if you wish (and Lisp source were written in way so that it makes
>> sense).
> 
> OK, but these lines certainly make no sense in the installed system, the
> build directory will be gone.
> 
> As I understand Alex (CC to him) building the debian package chokes on
> these lines inthe sense that it produces lots of warnings like this
> 
> W: fricas: unusual-interpreter
> usr/lib/x86_64-linux-gnu/fricas/target/x86_64-pc-linux-gnu/algebra/YSTREAM.fasl
> #!/tmp/debian/fricas-1.3.5/build/x86_64-pc-linux-gnu/bin/interpsys
> 
> Alex, what is debuild actually checking so that these warnings appear?
> 
> Ralf
> 

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/7f0f63cd-1d18-f0d3-651b-61fad268568a%40gmail.com.

Re: [fricas-devel] Fwd: [fricas/fricas] debian packaging (#2)

[oldk1331]

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 strange,
can you post the config.log?

- Best wishes,
- Qian

On 1/8/20 3:49 PM, Ralf Hemmecke wrote:
> Hi FriCAS developers,
> 
> this is a forward from an issue at fricas.github.com related to debian
> packaging.
> 
> Ralf
> 
>  Forwarded Message 
> Subject: Re: [fricas/fricas] debian packaging (#2)
> Date: Tue, 07 Jan 2020 23:11:48 -0800
> From: Julien Puydt 
> Reply-To: fricas/fricas
> 
> To: fricas/fricas 
> CC: Subscribed 
> 
> Can fricas be built with ecl? In Debian we already use ecl for maxima
> and hence sagemath, so it would be simpler.
> 
> I tried to compile myself with --with-lisp=ecl, but the configure script
> errors out. I tried to compile with sbcl and the @ethz.ch Debian
> packaging, but there too the configure script errors out.
> 
> ("we" above because I'm one of the Debian Developer working on
> sagemath-related packages)
> 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/5b15633f-d693-56df-58d7-35dab0e32435%40gmail.com.

Re: [fricas-devel] Long time to find a definition or applicable library operation

[oldk1331]

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 helps.

- Qian

On 1/5/20 6:53 AM, Kurt Pagani wrote:
> I've been confronted with the following oddness when accidentally a
> wrong entry (i.e. 1 instead of a symbol) is used:
> 
> (1) -> foo(L:List Symbol):OutputForm == first [outputForm(s)$OutputForm
> for s in L]
> 
> (2) -> foo [a,b,c,1]
>    Compiling function foo with type List(Symbol) -> OutputForm
>    Conversion failed in the compiled user function foo .
> 
>    Cannot convert the value from type List(Polynomial(Integer)) to List
>   (Symbol) .
> 
> (4) -> foo [a,b,c,d,e,1]
>    Conversion failed in the compiled user function foo .
> 
>    Cannot convert the value from type List(Polynomial(Integer)) to List
>   (Symbol) .
> 
> (5) -> foo [a,b,c,d,e,f,1]
>    Conversion failed in the compiled user function foo .
> 
>    Cannot convert the value from type List(Polynomial(Integer)) to List
>   (Symbol) .
> 
> time needed grows exponentially with the length of the list !?
>  foo [a,b,c,d,e,f,g,1] hangs already ...
> 
> This is an isolated example. The same occurs whether compiled or
> interpreted (as below).
> What's going on?  
> 
> --- same
> 
> foo.spad
> )abbrev domain FOO foo
> foo() : Exports == Implementation where  
>   Exports == with   
>     mkfoo : Integer -> %
>     dsp: (%,List Symbol) -> OutputForm   
>   Implementation == Integer add
>     Rep := Integer 
>     mkfoo(x:Integer) == x@% 
>     dsp(x:%,il:List Symbol):OutputForm ==
>   l:List OutputForm := [outputForm(s)$OutputForm for s in il]
>   first l
> 
> Example: dsp(5,[a,b,c,d,s,r])
> 
> foo.input:
> dsp(x:Integer,il:List Symbol):OutputForm ==
>   l:List OutputForm := [outputForm(s)$OutputForm for s in il]
>   first l
> 
> Example: dsp(5,[a,b,c,d,5,5,t,s,r,s,s,s,s]) (killed after 1h)
> 
> Thanks
> Kurt
> 
> -- 
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/a9c97164-5fce-499b-a951-8cea68846b6f%40googlegroups.com
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/3df8914f-6e22-fc83-c121-244ef3a43dc3%40gmail.com.

Re: [fricas-devel] FiniteField(Extension)-Problem

[oldk1331]

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 to interpret the output.
> 
> I used what Qian suggested some time ago
> 
> )lisp (require :sb-sprof)
> )lisp (sb-sprof:start-profiling)
> -- fricas computation here
> coerce(c2)$F4
> )lisp (sb-sprof:stop-profiling)
> )lisp (sb-sprof:report)
> 
> But couldn't exactly make sense out of the output.
> As far as I can tell it just counts the number of times a certain
> function is called, but not the time it spents in a function.
> 
> Ralf
> 

The "Count" you see is not the number of times a certain
function is called, instead, the calling stack is interrupted
and examined periodically to see which function is being called:
so this is a statistical method to get how much time each
function is spending -- the time spent by a function is
proportional to the count it gets during those examination.

Also notice the difference between "Count" and "Total Count",
"Count" means how much time is spent by function body,
"Total Count" means how much time is spent by function body and
sub-function calls.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/88f219ba-2dac-4821-d14f-106eca991ebf%40gmail.com.

Re: [fricas-devel] Problem using record selectors

[oldk1331]

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.
> 
> )compile rec.spad
> 
> 
> (2) -> x := makeRec(2,3)
> 
>(2)  [a = 3, b = 2]
>  Type: MyRec
> (3) -> recA(x)
> 
>(3)  3
>  Type: PositiveInteger
> (4) -> a := 0
> 
>(4)  0
>  Type: NonNegativeInteger
> (5) -> recA(x)
> 
>(5)  3
>  Type: PositiveInteger
> 
> If you don't want to do this, you must wait for some smarter person that
> tells you how to define getA in order to refer to the right a.
> 
> I've found another workaround.
> 
> (1) -> Z ==> Integer
>   Type: Void
> (2) -> R ==> Record(a: Z, b: Z)
>   Type: Void
> (3) -> makeR(x:Integer, y:Integer):R == [x,y]
>Function declaration makeR : (Integer, Integer) -> Record(a: Integer
>   ,b: Integer) has been added to workspace.
>   Type: Void
> (4) -> aForGetA := 'a
> 
>(4)  a
>   Type: Variable(a)
> (5) -> getA(r:R):Integer == r.aForGetA
>Function declaration getA : Record(a: Integer,b: Integer) -> Integer
>   has been added to workspace.
>   Type: Void
> (6) -> r := makeR(3, 5)
>Compiling function makeR with type (Integer, Integer) -> Record(a:
>   Integer,b: Integer)
> 
>(6)  [a = 3, b = 5]
> Type: Record(a: Integer,b: Integer)
> (7) -> getA(r)
>Compiling function getA with type Record(a: Integer,b: Integer) ->
>   Integer
> 
>(7)  3
>   Type: PositiveInteger
> (8) -> a := 0
> 
>(8)  0
>   Type: NonNegativeInteger
> (9) -> getA r
> 
>(9)  3
> 
> 
> Ralf
> 

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/c7ad4964-91e5-6e64-9264-e8401424c09f%40gmail.com.

Re: [fricas-devel] difference between EXPR INT and EXPR Complex INT

[oldk1331]

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

Martin R wrote:
>
> 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
>  a tan(d x + c)
> Type:
> Expression(Integer)
> (2) -> F := integrate(f, x)
>
>(2)
>2  31   3 33
>(9 I  - 3)a log(-) + 2 I a tan(d x + c)
>2
>tan(d x + c)  + 1
>  +
>   2 32 3 3   3
3
>9 I a tan(d x + c)  + (- 6 I  + 18 I)a tan(d x + c) + (6 I  -
18 I)a
> d x
>   /
>  6 d
>  Type:
> Union(Expression(Integer),...)
> (3) -> D(eval(F, I =%i), x)-eval(f, I=%i)
>
>(3)  0
>Type:
> Expression(Complex(Integer))
> (4) -> F := integrate(eval(f, I=%i), x)
>
>>> System error:
>arithmetic error DIVISION-BY-ZERO signalled
> Operation was (/ -2 0).
>
> Any ideas?

This is old confusion between real and complex.  We create
Complex(Complex(Integer)) and loose.  It would be good to
clean this up.  AFAICS proper fix should not require much
code, but it is going to touch several domains and packages.
Basically, old code assumed that functions are real and
allowed complex functions only as a hack.  Current
'FunctionSpaceComplexIntegration' integrates _real_
function by passage to complex variables.  We need a
function to integrate _complex_ functions.

-- 
  Waldek Hebisch

-- 


On 11/3/19 2:55 AM, 'Martin R' via FriCAS - computer algebra system wrote:
> 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 difference between EXPR INT and EXPR Complex INT
> mathematically speaking?
> 2) Is it "correct" to use sqrt(-1) for the complex unit?
> 
> Thanks,
> 
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/41025454-9c01-4490-9002-56d424960ea9%40googlegroups.com
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/481cb793-6143-1ebd-edfb-492a8d03cdf2%40gmail.com.

Re: [fricas-devel] Cannot build FriCAS in VirtualBox (Debian 10, sbcl) SB-IMPL::SAVE-WITH-MULTIPLE- THREADS-ERROR

[oldk1331]

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
> > compilation succeeded.
> >
> > That doesn't, of course, deal with the actual bug, but as you suggested,
> > the best we can do is to report that problem to the sbcl developers.
>
>
> I did a git bisect, this bug is caused by sbcl commit
> c63557933adae1f6a46250056a8ba53bfb7ead02, I think this part
> is relevant:
>
> "Also move TUNE-IMAGE-FOR-DUMP into DEINIT so that any
> compiling caused by user code as a consequence of
> calling *save-hooks* is done first."
>
> See
>
> https://github.com/sbcl/sbcl/commit/c63557933adae1f6a46250056a8ba53bfb7ead02
> they move "(tune-image-for-dump)" inside "(deinit)",
> which is after "#+sb-thread (finalizer-thread-stop)".
>
> If we move "(tune-image-for-dump)" before
> "#+sb-thread (finalizer-thread-stop)", then there is no problem.
>
> This is very strange after all, and I will report to sbcl
> developers soon.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN929z7-v6UY1BPEp6%2BOh3b8M6%3DW58o9V68Z2JQK_TvkkpA%40mail.gmail.com.

Re: [fricas-devel] Cannot build FriCAS in VirtualBox (Debian 10, sbcl) SB-IMPL::SAVE-WITH-MULTIPLE- THREADS-ERROR

[oldk1331]

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 that problem to the sbcl developers.


I did a git bisect, this bug is caused by sbcl commit
c63557933adae1f6a46250056a8ba53bfb7ead02, I think this part
is relevant:

"Also move TUNE-IMAGE-FOR-DUMP into DEINIT so that any
compiling caused by user code as a consequence of
calling *save-hooks* is done first."

See
https://github.com/sbcl/sbcl/commit/c63557933adae1f6a46250056a8ba53bfb7ead02
they move "(tune-image-for-dump)" inside "(deinit)",
which is after "#+sb-thread (finalizer-thread-stop)".

If we move "(tune-image-for-dump)" before
"#+sb-thread (finalizer-thread-stop)", then there is no problem.

This is very strange after all, and I will report to sbcl
developers soon.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/0e9dff55-b49e-f7d6-f39e-a94dfee7fb86%40gmail.com.

Re: [fricas-devel] Cannot build FriCAS in VirtualBox (Debian 10, sbcl) SB-IMPL::SAVE-WITH-MULTIPLE- THREADS-ERROR

[oldk1331]

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 Linux distros.
2. This bug is not related with virtualbox, it also happens on QEMU.
3. This bug happens when the virtual machine has only 1 CPU.
(I suspect it also happens on real 1 core machine.)
4. This bug happens since SBCL 1.4.14. Older versions are fine.

So something related with threads in SBCL during 1.4.13~1.4.14
got wrong.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/900c7596-5118-35c0-bf4d-29f95811c82c%40gmail.com.

Re: [fricas-devel] Cannot build FriCAS in VirtualBox (Debian 10, sbcl) SB-IMPL::SAVE-WITH-MULTIPLE- THREADS-ERROR

[oldk1331]

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
Other threads:
  #,..
So it is running in SLIME (inside emacs).

>From Nasser's original post, it shows
  Other thread:
#
Which is strange and should be a different matter than SLIME.

Hi Ralf, what does your error log shows?

Somehow I wonder this bug is related with VirtualBox?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/586df3fa-d14a-c132-09dd-5e1315ccef41%40gmail.com.

Re: [fricas-devel] Hot to implement a binary operation "->"?

[oldk1331]

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 can at least use them in prefix form, but
that's ugly.

> Any ideas / workarounds?
> 

I think a workaround should be using ">>", "<<", or even "/\" "\/",
they seem to be supported by the scanner and parser.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/1d6ed09e-0c96-892b-c103-2a9332226970%40gmail.com.

Re: [fricas-devel] [PATCH] misc cleanup: use 'concat' instead of '"append"/'

[oldk1331]

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.
>>
>> Also I don't like to have special grammar to do things can
>> be done by normal grammar.
> 
> I am affraid the classic answer is appropriate here
> "it is a feature, not a bug".
> 
> Expanding on it a bit: it is usual that syntactic choices
> cause some disagreement.  From my point of view this is
> useful shortcut for frequently occuring operation.

We already have an useful shortcut for this frequently
occurring pattern (the reduce pattern): function "reduce".

> It does not significantly increase complexity of the
> parser and beside parser we need smal amount of extra
> code.  So from implementation point of view it is
> cheap feature.  I so no reason to remove it.

I think it's bad design to have special grammar do things
that normal function can do.

> @Ralf: this construct kowns about identity for several
> popular operations, so in such case works also for empty
> lists.  Of course, it would be nicer to do this in more
> systematic way.

It's also a bad design to hard-code extra knowledge into
compiler.

>> This patch replaces '"append"/' with normal function call
>> 'concat : List % -> %', it's simpler and faster.
>>
> 
> Well, simpler is debatable.  Faster is useful if speed
> matters.

For common usage, we already have "gcd : List(%) -> %"
defined as "gcd(l : List %) == reduce(gcd, l, 0, 1)".
now comparing the following:

"gcd"/[f(i) for i in l]
gcd [f(i) for i in l]

At least it is 3 characters simpler and less confusing.

>>
>> If you agree, I plan to replace other usage of '"func"/' by
>> normal function calls.
>>
>> grep '"[a-zA-Z]*" */' *spad   shows 135 usage of such grammar,
>> only uses function max/min/setUnion/and/or/gcd/lcm.
> 
> Well, as I wrote I think that "op"/... is a useful feature.
> And it is useful to have some test cases for features.
> So I would like to keep some (preferaby most) of uses of
> this construct.
> 

I propose I only do the cleanup for "concat", "gcd" , "lcm"
for now, because they already have signature "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 it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/59772f28-32e6-2452-4dea-525838e77069%40gmail.com.

[fricas-devel] [PATCH] misc cleanup: use 'concat' instead of '"append"/'

[oldk1331]

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 simpler and faster.

If you agree, I plan to replace other usage of '"func"/' by
normal function calls.

grep '"[a-zA-Z]*" */' *spad   shows 135 usage of such grammar,
only uses function max/min/setUnion/and/or/gcd/lcm.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN936cx4UgYvxjpdf97pmgsx0%3Djcidp4Pb7RCooOb%3DA6UHQ%40mail.gmail.com.
diff --git a/src/algebra/algfunc.spad b/src/algebra/algfunc.spad
index 89d80d30..625752f5 100644
--- a/src/algebra/algfunc.spad
+++ b/src/algebra/algfunc.spad
@@ -127,7 +127,7 @@ AlgebraicallyClosedField() : Category == Join(Field, RadicalCategory) with
   h := last decompList
   g := leftFactorIfCan(p, h) :: SUP
   groots := allroots(g, y, fn)
-  "append"/[allroots(h-r::SUP, y, fn) for r in groots]
+  concat [allroots(h-r::SUP, y, fn) for r in groots]
   ans := []$List(%)
   while not ground? p repeat
 alpha := assign(x := new(y)$Symbol, fn(p, x))
diff --git a/src/algebra/cycles.spad b/src/algebra/cycles.spad
index 0452fcd7..5759892e 100644
--- a/src/algebra/cycles.spad
+++ b/src/algebra/cycles.spad
@@ -119,8 +119,7 @@ CycleIndicators : Exports == Implementation where
 divisors : I -> L I
 divisors n ==
   b := factorList(n :: FR)
-  c := concat(1,"append"/
- [[a.factor^j for j in 1..a.exponent] for a in b])
+  c := concat(1, concat [[a.factor^j for j in 1..a.exponent] for a in b])
   if #(b) = 1 then c else concat(n, c)
 
 ss : (I, I) -> SPOL RN
diff --git a/src/algebra/cyldec.spad b/src/algebra/cyldec.spad
index 160f9b60..d11f67e5 100644
--- a/src/algebra/cyldec.spad
+++ b/src/algebra/cyldec.spad
@@ -155,7 +155,8 @@ SimpleCell(TheField, ThePols) : PUB == PRIV where
  lp1 := gcdBasis(lp)$PACK
  empty?(lp1) => [pointToCell(0, true, var)]
  b := ("max" / [ boundOfCauchy(p)$VARS for p in lp1])::TheField
- l := "append" / [allRootsOf(makeSUP(unitCanonical(p))) for p in lp1]
+ l : List TheField :=
+ concat [allRootsOf(makeSUP(unitCanonical(p))) for p in lp1]
  l := sort(l)
  l1 := separate(l, -b, b)
  res : List(%) := [pointToCell(first(l1), true, var)]
diff --git a/src/algebra/galfact.spad b/src/algebra/galfact.spad
index 6d2761be..049e9634 100644
--- a/src/algebra/galfact.spad
+++ b/src/algebra/galfact.spad
@@ -775,7 +775,7 @@ GaloisGroupFactorizer(UP) : Exports == Implementation where
   lrf := cf::LR
   dh := degree(lrf.right)
   d1 := divideSet(d, dh)
-  "append"/[ henselfact(g(lrf.right), false,
+  concat [ henselfact(g(lrf.right), false,
sel_set(d, degree(g), dh)) for g in
  henselfact(lrf.left, true, d1) ]
 
diff --git a/src/algebra/gpgcd.spad b/src/algebra/gpgcd.spad
index 87d8c274..bf4ac1f2 100644
--- a/src/algebra/gpgcd.spad
+++ b/src/algebra/gpgcd.spad
@@ -245,7 +245,7 @@ GeneralPolynomialGcdPackage(E, OV, R, P) : C == T where
lr := [ randomR() for vv in lv]
  ans
   variables(p1 : SUPP) ==
-removeDuplicates ("concat"/[variables u for u in coefficients p1])
+removeDuplicates concat [variables u for u in coefficients p1]
   gcdTrivial(p1 : SUPP, p2 : SUPP) ==
 -- p1 is non-zero, but has degree zero
 -- p2 is non-zero
diff --git a/src/algebra/moddfact.spad b/src/algebra/moddfact.spad
index ec371e80..94c26b37 100644
--- a/src/algebra/moddfact.spad
+++ b/src/algebra/moddfact.spad
@@ -114,7 +114,7 @@ ModularDistinctDegreeFactorizer(U) : C == T where
   [[(dd.factor)::U, dd.degree]$UDDRecord for dd in ans]$UDDList
 
 sepfact(factList) ==
-  "append"/[sepFact1(f) for f in factList]
+  concat [sepFact1(f) for f in factList]
 
 separateFactors(uddList, q) ==
   ans := sepfact [[reduce(udd.factor, q), udd.degree]$DDRecord for
diff --git a/src/algebra/multpoly.spad b/src/algebra/multpoly.spad
index 20d02c21..4755769e 100644
--- a/src/algebra/multpoly.spad
+++ b/src/algebra/multpoly.spad
@@ -524,7 +524,7 @@ SparseMultivariatePolynomial(R : Join(SemiRng, AbelianMonoid),
 
   coefficients p ==
 p case R => list(p :: R)$List(R)
-"append"/[coefficients(p1)$% for p1 in coefficients(p.ts)]
+concat [coefficients(p1)$% for p1 in coefficients(p.ts)]
 
   retract(p : %) : R ==
 p case R => p :: R
diff --git a/src/algebra/numsolve.spad 

Re: [fricas-devel] FriCAS - Debian Package

[oldk1331]

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 community.
> Are there any current attempts to get FriCAS into Debian? I would like
> to start packaging if you find it promising. Please let me know any
> obstacles or other things i should know regards licensing, community
> hurdles, etc. and if you recommend to start this project.
> 
> Best,
> Siegfried Köstlmeier


Your attempt to package for FriCAS is welcomed.  Are you a Debian
developer?  There were attempts before, as you can see the deleted
"debian/" directory from git history.  I think the problems in
the past was no upstream Debian developers was willing to maintain it.

Best,
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/bc3b2561-aaa6-8830-1b71-54d9b35cc616%40gmail.com.

Re: [fricas-devel] [PATCH] patches for MRING

[oldk1331]

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
> would be better to do some measurements and compare speed
> of old code and your new one.

You are right, old code is about 4 times faster than mine
for MRING(INT,FreeMonoid(INT)).  (after work around the
compiler bug in 'concat!')

So I'll change for "not (M has OrderedMonoid)" only.

>> The third patch does some cleanup for MRING.

What's your opinion on the third patch?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91ohV5woUPaNUW7fp1e%3DPVUPbpc0DrDfrG%2B3p%2BgDe4wbw%40mail.gmail.com.

[fricas-devel] PositiveInteger should have OrderedMonoid

[oldk1331]

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 integers.
-PositiveInteger : Join(OrderedAbelianSemiGroup, Monoid, CommutativeStar,
+PositiveInteger : Join(OrderedAbelianSemiGroup, OrderedMonoid,
CommutativeStar,
ConvertibleTo InputForm) with
 gcd : (%, %) -> %
   ++ gcd(a, b) computes the greatest common divisor of two

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN93TqzAOYXfyet4%2BBoNXLwXY8x4SsZJRVDpBh-iU%2BtEGvg%40mail.gmail.com.

[fricas-devel] [BUG] compiler bug regarding "=>" in loop

[oldk1331]

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
"incExitLevel" in "parseIf".

Example:

)abbrev package TEST Test
Test() : Exp == Imp where
  Exp == with
test1 : List Integer -> Integer
  Imp == add
test1 l ==
  n := 0
  while not empty? l repeat
-- 1+1 -- uncomment this line to workaround this bug
first l = 3 =>
  n := n + 1
  l := rest l
  n

= -- should return 4 instead of 1
(1) -> test1 [3,3,3,3]

   (1)  1

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92Rbc%2BUrRKR76-D0ijvNqt1OaipWkyMhM5uxNgXN2q8mg%40mail.gmail.com.

[fricas-devel] [PATCH] patches for MRING

[oldk1331]

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 algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91PfWw_bZdJE7tU-qF%2BfEkQU7ani74rbWs%3DsfmxF0a-mQ%40mail.gmail.com.
diff --git a/src/algebra/mring.spad b/src/algebra/mring.spad
index a4900be7..74bd09fc 100644
--- a/src/algebra/mring.spad
+++ b/src/algebra/mring.spad
@@ -96,8 +96,7 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
   r = 0 => empty()
   [[m, r]]
 
-monomial?(x) ==
-#(rep(x)) <= 1
+monomial?(x) == empty? x or empty? rest x
 
 if (R has Finite and M has Finite) then
   size() == size()$R ^ size()$M
@@ -140,7 +139,8 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
 
 0   == empty()
 1   == [[1, 1]]
---terms a == (copy a) pretend List(Term)
+zero? a == empty? a
+one? a == size?(a, 1) and one?(a.first.Cf) and one?(a.first.Mn)
 terms a == copy rep a
 monomials a == [[t] for t in a]
 coefficients a  == [t.Cf for t in a]
@@ -158,19 +158,23 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
then
 (r : R) * (a : %) ==
   r = 0 => 0
+  one? r => a
   [[t.Mn, r*t.Cf] for t in a]
else
 (r : R) * (a : %) ==
   r = 0 => 0
+  one? r => a
   [[t.Mn, rt] for t in a | (rt := r*t.Cf) ~= 0]
 if R has noZeroDivisors
then
 (n : Integer) * (a : %) ==
   n = 0 => 0
+  n = 1 => a
   [[t.Mn, n*t.Cf] for t in a]
else
 (n : Integer) * (a : %) ==
   n = 0 => 0
+  n = 1 => a
   [[t.Mn, nt] for t in a | (nt := n*t.Cf) ~= 0]
 map(f, a)   == [[t.Mn, ft] for t in a | (ft := f(t.Cf)) ~= 0]
 numberOfMonomials a == #a
@@ -186,11 +190,9 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
 if R has noZeroDivisors then
   if M has Group then
 recip a ==
-  lt := terms a
-  #lt ~= 1 => "failed"
-  (u := recip lt.first.Cf) case "failed" => "failed"
-  --(u::R) * inv lt.first.Mn
-  monomial((u::R), inv lt.first.Mn)$%
+  not size?(a, 1) => "failed"
+  (u := recip a.first.Cf) case "failed" => "failed"
+  monomial((u::R), inv a.first.Mn)
   else
 recip a ==
   #a ~= 1 or a.first.Mn ~= 1 => "failed"
@@ -213,7 +215,7 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
 leadingSupport a== (empty? a => 1; a.first.Mn)
 leadingMonomial a==
 empty? rep a => error "empty support"
-monomial((first rep a).Cf, (first rep a).Mn)
+[first a]
 
 leadingTerm a==
 empty? a => error "empty support"
@@ -269,6 +271,8 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
 true
 
 a + b ==
+zero? a => b
+zero? b => a
 repa:Rep := rep a
 repb:Rep := rep b
 res : Rep := empty()
@@ -297,11 +301,13 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
 construct! concat! [[[ta.Mn*tb.Mn, ta.Cf*tb.Cf]$Term
 for tb in b] for ta in a]
 
-else -- M hasn't OrderedSet
+else -- M hasn't Comparable
 -- Terms are stored in random order.
   a = b ==
 #a ~= #b => false
-set(a pretend List(Term)) =$Set(Term) set(b pretend List(Term))
+for t in a repeat
+not member?(t, b) => return false
+true
 
   coefficient(a, m) ==
 for t in a repeat
diff --git a/src/algebra/mring.spad b/src/algebra/mring.spad
index 0a1e9704..a4900be7 100644
--- a/src/algebra/mring.spad
+++ b/src/algebra/mring.spad
@@ -229,8 +229,8 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
 
 termless(t1:Term, t2:Term):Boolean == smaller?(t1.k, t2.k)
 
-construct(x : List Term) : % ==
-xs : List Term := sort(termless, x)
+construct!(x : List 

[fricas-devel] Re: [PATCHv2] cleanup "*" in MRING

[oldk1331]

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
>             for tb in b] for ta in a]
> 
> we collect all the terms and let "construct" do the heavy lifting.
> See my updated patch.

There is a serious problem in "construct" though, it may
modify the content of a "Term":

   t1.c:= t1.c+t2.c

We should create new cells instead of reusing old ones.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/1c778eff-ed74-6845-d347-b0ef84b9853b%40gmail.com.

[fricas-devel] [PATCHv2] cleanup "*" in MRING

[oldk1331]

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" do the heavy lifting.
See my updated patch.

It's possible to do better though, for OrderedMonoid, we can do a
k-way merge, but we don't have such algorithm at hand.

My patch should already make this function much faster by
skipping allocation of temporary result of "+".

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92Dn0Mb5OKZqA3Ckf68qMjmFUnHBomY_5FVAib3XgrWhQ%40mail.gmail.com.
diff --git a/src/algebra/mring.spad b/src/algebra/mring.spad
index 7fd7244a..bc216576 100644
--- a/src/algebra/mring.spad
+++ b/src/algebra/mring.spad
@@ -229,8 +229,8 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
 
 termless(t1:Term, t2:Term):Boolean == smaller?(t1.k, t2.k)
 
-construct(x : List Term) : % ==
-xs : List Term := sort(termless, x)
+construct!(x : List Term) : % ==
+xs : List Term := sort!(termless, x)
 res : List Term := empty()
 -- find duplicates
 while not empty? xs repeat
@@ -246,6 +246,8 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
 res := cons (t1, res)
 res
 
+construct(x : List Term) : % == construct! copy x
+
 if R has CommutativeRing then
 f : M -> R
 x : %
@@ -285,59 +287,10 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
 if smaller?(t.Mn, m) then return 0
 0
 
-
-if M has OrderedMonoid then
-
--- we use that multiplying an ordered list of monoid elements
--- by a single element respects the ordering
-
-  if R has noZeroDivisors then
-a : % * b : % ==
-  +/[[[ta.Mn*tb.Mn, ta.Cf*tb.Cf]$Term
-for tb in b ] for ta in reverse a]
-  else
-a : % * b : % ==
-  +/[[[ta.Mn*tb.Mn, r]$Term
-for tb in b | not zero?(r := ta.Cf*tb.Cf)]
-  for ta in reverse a]
-else -- M hasn't OrderedMonoid
-
--- we cannot assume that mutiplying an ordered list of
--- monoid elements by a single element respects the ordering:
--- we have to order and to collect equal terms
-  ge : (Term, Term) -> Boolean
-  ge(s, t) == not smaller? (s.Mn, t.Mn)
-
-  sortAndAdd : List Term -> List Term
-  sortAndAdd(liTe) ==  -- assume liTe not empty
-liTe := sort(ge, liTe)
-m : M :=  (first liTe).Mn
-cf : R := (first liTe).Cf
-res : List Term := []
-for te in rest liTe repeat
-  if m = te.Mn then
-cf := cf + te.Cf
-  else
-if not zero? cf then res := cons([m, cf]$Term, res)
-m := te.Mn
-cf := te.Cf
-if not zero? cf then res := cons([m, cf]$Term, res)
-reverse res
-
-
-  if R has noZeroDivisors then
-a : % * b : % ==
-  zero? a => a
-  zero? b => b  -- avoid calling sortAndAdd with []
-  +/[sortAndAdd [[ta.Mn*tb.Mn, ta.Cf*tb.Cf]$Term
-for tb in b ] for ta in reverse a]
-  else
-a : % * b : % ==
-  zero? a => a
-  zero? b => b  -- avoid calling sortAndAdd with []
-  +/[sortAndAdd [[ta.Mn*tb.Mn, r]$Term
-for tb in b | not zero?(r := ta.Cf*tb.Cf)]
-  for ta in reverse a]
+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]
 
 
 else -- M hasn't OrderedSet

Re: [fricas-devel] [PATCH] cleanup "*" in MRING

[oldk1331]

"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 "construct" carefully eliminate terms with zero coefficient?
>
> 'construct' for MonoidRing is should eliminate terms with zero
> coefficients, but IIUC it is quite slow.  You called 'construct!'
> which seem to be defiend only for aggregates.  For aggregates
> eliminating zero coefficients would be incorrect...
>
> --
>   Waldek Hebisch
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/E1hqJFL-0001SC-NR%40hera.math.uni.wroc.pl
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN90t2aTwiB-yArJnCkApg02cSuZXvmGcd%2BMM6jMyyL_T-A%40mail.gmail.com.

Re: [fricas-devel] [PATCH] cleanup "*" in MRING

[oldk1331]

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 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!".
>
> It is not clear for me that we can do this.  Existing code
> is quite careful to eliminate terms with zero coefficient.
> In your code it is not clear if/how this is done.
>
> --
>   Waldek Hebisch
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/E1hqHkK-TH-Oe%40hera.math.uni.wroc.pl
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN927u187_A%2BaXJiJMWSndjbYAgBNKRQoS4VeY4GQHDhaGA%40mail.gmail.com.

[fricas-devel] Re: [PATCH] add 'concat! : List % -> %' in URAGG

[oldk1331]

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 email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN93pXyw%2BGVN1-z236wzCH3PrLKqG4dqM-wFnGxDJOD6Axw%40mail.gmail.com.
diff --git a/src/algebra/aggcat.spad b/src/algebra/aggcat.spad
index 57b07e1f..b91bfbd4 100644
--- a/src/algebra/aggcat.spad
+++ b/src/algebra/aggcat.spad
@@ -1367,6 +1367,12 @@ UnaryRecursiveAggregate(S : Type) : Category == RecursiveAggregate S with
   concat! : (%, S) -> %
 ++ concat!(u, x) destructively adds element x to the end of u.
 ++ Note: \spad{concat!(a, x) = concat!(a, [x])}.
+  concat! : List % -> %
+++ concat!(lu), where \spad{lu} is a list of aggregates
+++ \spad{[a, b, ..., c]}, returns a single aggregate consisting
+++ of the elements of \spad{a} followed by those of \spad{b}
+++ followed ... by the elements of \spad{c}.  This function may
+++ destructively modify the aggregates in \spad{lu}.
   cycleSplit! : % -> %
 ++ cycleSplit!(u) splits the aggregate by dropping off the cycle.
 ++ The value returned is the cycle entry, or empty() if none exists.
@@ -1561,6 +1567,17 @@ UnaryRecursiveAggregate(S : Type) : Category == RecursiveAggregate S with
   setelt!(x,  "rest", a) == setrest!(x, a)
   concat(x : %, y : %) == concat!(copy x, y)
 
+  concat!(lu : List %) ==
+  while not empty? lu and empty? first lu repeat lu := rest lu
+  empty? lu => empty()
+  res := first lu
+  t := tail res
+  for u in rest lu repeat
+  not empty? u =>
+  setrest!(t, u)
+  t := tail t
+  res
+
   -- The qxxx variants are for speed.  If we do not care about
   -- speed the regular ones will do.
 

[fricas-devel] [PATCH] cleanup "*" in MRING

[oldk1331]

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 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92wyNrqgAzZbPkR4qPzs8L5dgTHXPZWJtG0DQ34Nxysbw%40mail.gmail.com.
diff --git a/src/algebra/mring.spad b/src/algebra/mring.spad
index 930f7321..4092362c 100644
--- a/src/algebra/mring.spad
+++ b/src/algebra/mring.spad
@@ -229,8 +229,8 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
 
 termless(t1:Term, t2:Term):Boolean == smaller?(t1.k, t2.k)
 
-construct(x : List Term) : % ==
-xs : List Term := sort(termless, x)
+construct!(x : List Term) : % ==
+xs : List Term := sort!(termless, x)
 res : List Term := empty()
 -- find duplicates
 while not empty? xs repeat
@@ -246,6 +246,8 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
 res := cons (t1, res)
 res
 
+construct(x : List Term) : % == construct! copy x
+
 if R has CommutativeRing then
 f : M -> R
 x : %
@@ -302,42 +304,16 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
   for ta in reverse a]
 else -- M hasn't OrderedMonoid
 
--- we cannot assume that mutiplying an ordered list of
+-- we cannot assume that multiplying an ordered list of
 -- monoid elements by a single element respects the ordering:
--- we have to order and to collect equal terms
-  ge : (Term, Term) -> Boolean
-  ge(s, t) == not smaller? (s.Mn, t.Mn)
-
-  sortAndAdd : List Term -> List Term
-  sortAndAdd(liTe) ==  -- assume liTe not empty
-liTe := sort(ge, liTe)
-m : M :=  (first liTe).Mn
-cf : R := (first liTe).Cf
-res : List Term := []
-for te in rest liTe repeat
-  if m = te.Mn then
-cf := cf + te.Cf
-  else
-if not zero? cf then res := cons([m, cf]$Term, res)
-m := te.Mn
-cf := te.Cf
-if not zero? cf then res := cons([m, cf]$Term, res)
-reverse res
-
+-- we have to order and to collect equal terms using 'construct',
+-- and it can also handle the ZeroDivisors case.
 
-  if R has noZeroDivisors then
 a : % * b : % ==
   zero? a => a
-  zero? b => b  -- avoid calling sortAndAdd with []
-  +/[sortAndAdd [[ta.Mn*tb.Mn, ta.Cf*tb.Cf]$Term
-for tb in b ] for ta in reverse a]
-  else
-a : % * b : % ==
-  zero? a => a
-  zero? b => b  -- avoid calling sortAndAdd with []
-  +/[sortAndAdd [[ta.Mn*tb.Mn, r]$Term
-for tb in b | not zero?(r := ta.Cf*tb.Cf)]
-  for ta in reverse a]
+  zero? b => b
+  construct! concat! [[[ta.Mn*tb.Mn, ta.Cf*tb.Cf]$Term
+for tb in b] for ta in a]
 
 
 else -- M hasn't OrderedSet

[fricas-devel] [PATCH] add 'concat! : List % -> %' in URAGG

[oldk1331]

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.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN93_s5Czp2q4htm45FuawwDxZLrWRtVJb6k--xJ0%2BRCX9g%40mail.gmail.com.
diff --git a/src/algebra/aggcat.spad b/src/algebra/aggcat.spad
index 23a785db..73678bf7 100644
--- a/src/algebra/aggcat.spad
+++ b/src/algebra/aggcat.spad
@@ -1381,6 +1381,12 @@ UnaryRecursiveAggregate(S : Type) : Category == Join(RecursiveAggregate S,
   concat! : (%, S) -> %
 ++ concat!(u, x) destructively adds element x to the end of u.
 ++ Note: \spad{concat!(a, x) = concat!(a, [x])}.
+  concat! : List % -> %
+++ concat!(lu), where \spad{lu} is a list of aggregates
+++ \spad{[a, b, ..., c]}, returns a single aggregate consisting
+++ of the elements of \spad{a} followed by those of \spad{b}
+++ followed ... by the elements of \spad{c}.  This function may
+++ destructively modify the aggregates in \spad{lu}.
   cycleSplit! : % -> %
 ++ cycleSplit!(u) splits the aggregate by dropping off the cycle.
 ++ The value returned is the cycle entry, or empty() if none exists.
@@ -1635,6 +1641,15 @@ UnaryRecursiveAggregate(S : Type) : Category == Join(RecursiveAggregate S,
   setelt!(x,  "rest", a) == setrest!(x, a)
   concat(x : %, y : %) == concat!(copy x, y)
 
+  concat!(lu : List %) ==
+  empty? lu => empty()
+  res := first lu
+  t := tail res
+  for u in rest lu repeat
+  setrest!(t, u)
+  t := tail t
+  res
+
   -- The qxxx variants are for speed.  If we do not care about
   -- speed the regular ones will do.
 

[fricas-devel] [PATCH] optimize "+" in MRING when Comparable

[oldk1331]

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 email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91TUUrLy52msTZXCAhzB71p5godbow49hwogTyx1xK2RQ%40mail.gmail.com.
diff --git a/src/algebra/mring.spad b/src/algebra/mring.spad
index 4092362c..8d76157e 100644
--- a/src/algebra/mring.spad
+++ b/src/algebra/mring.spad
@@ -273,13 +273,13 @@ MonoidRing(R : Ring, M : Monoid) : MonoidRingCategory(R, M) == MRdefinition wher
   ta:Term := first repa; tb:Term := first repb
   ra:Rep := rest repa;  rb:Rep := rest repb
   res :=
-smaller?(tb.Mn, ta.Mn)  => (repa := ra; concat!(res, ta))
-smaller?(ta.Mn, tb.Mn) => (repb := rb; concat!(res, tb))
+smaller?(tb.Mn, ta.Mn) => (repa := ra; concat(ta, res))
+smaller?(ta.Mn, tb.Mn) => (repb := rb; concat(tb, res))
 repa := ra; repb := rb
 not zero?(r := ta.Cf + tb.Cf) =>
-concat!(res, [ta.Mn, r])
+concat([ta.Mn, r], res)
 res
-per concat!(res, concat(repa, repb))
+per concat!(reverse! res, if empty? repa then repb else repa)
 
 coefficient(a, m) ==
 for t in a repeat

Re: [fricas-devel] Wayland and no X

[oldk1331]

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 Hemmecke wrote:
> Does someone know whether Wayland without an X server is problematic for
> FriCAS?
> 
> Ralf
> 

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/886de96c-92e9-d9ae-4de9-6a27375760eb%40gmail.com.

[fricas-devel] [PATCH] remove "NegativeInteger"

[oldk1331]

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 @@
   INTEGERP x =>
 x=0 => $NonNegativeInteger
 x>0 => $PositiveInteger
-true => $NegativeInteger
+$Integer
   FLOATP x => $DoubleFloat
   nil

diff --git a/src/interp/property.lisp b/src/interp/property.lisp
index e5a81329..b48233fd 100644
--- a/src/interp/property.lisp
+++ b/src/interp/property.lisp
@@ -261,7 +261,6 @@
 (MAKEPROP '|Integer| '|Subsets|
   '((|PositiveInteger| . (|>| * 0))
 (|NonNegativeInteger| . (|>=| * 0))
-(|NegativeInteger| . (|<| * 0))
 (|SingleInteger| . (SINTP *))
 ))

diff --git a/src/interp/setq.lisp b/src/interp/setq.lisp
index 7b785d24..7a049d17 100644
--- a/src/interp/setq.lisp
+++ b/src/interp/setq.lisp
@@ -340,7 +340,6 @@

 (SETQ |$Integer| '(|Integer|))
 (SETQ |$ComplexInteger| (LIST '|Complex| |$Integer|))
-(SETQ |$NegativeInteger| '(|NegativeInteger|))
 (SETQ |$NonNegativeInteger| '(|NonNegativeInteger|))
 (SETQ |$PositiveInteger| '(|PositiveInteger|))
 (SETQ |$RationalNumber| '(|Fraction| (|Integer|)))

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91eZeERJDw%3D3rcCes4xvr0%2BNh4Q%2BBGMzk5LgBp72washQ%40mail.gmail.com.

[fricas-devel] [PATCH] remove Reference for Domain local variables

[oldk1331]

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 unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92i6o3jCsmskSQdDEd3pT-ceXBv0BNTQeJ1%2BUmtKqrf4g%40mail.gmail.com.
diff --git a/src/algebra/algext.spad b/src/algebra/algext.spad
index e6bbe188..7dee485a 100644
--- a/src/algebra/algext.spad
+++ b/src/algebra/algext.spad
@@ -35,9 +35,9 @@ SimpleAlgebraicExtension(R : CommutativeRing,
 d   := degree M
 d1  := subtractIfCan(d, 1)::NonNegativeInteger
 discmat : Matrix(R) := zero(d, d)
-nodiscmat? : Reference(Boolean) := ref true
-disc : Reference(R) := ref 0
-nodisc? : Reference(Boolean) := ref true
+nodiscmat? : Boolean := true
+disc : R := 0
+nodisc? : Boolean := true
 bsis := [monomial(1, i)$Rep for i in 0..d1]$Vector(Rep)
 
 if R has Finite then
@@ -104,20 +104,20 @@ SimpleAlgebraicExtension(R : CommutativeRing,
 map(lift, v)$VectorFunctions2(%, UP))
 
 discriminant() ==
-  if nodisc?() then mkDisc false
-  disc()
+  if nodisc? then mkDisc false
+  disc
 
 mkDisc b ==
-  nodisc?() := b
-  disc() := discriminant M
+  nodisc? := b
+  disc := discriminant M
   void
 
 traceMatrix() ==
-  if nodiscmat?() then mkDiscMat false
+  if nodiscmat? then mkDiscMat false
   discmat
 
 mkDiscMat b ==
-  nodiscmat?() := b
+  nodiscmat? := b
   mr := minRowIndex discmat; mc := minColIndex discmat
   for i in 0..d1 repeat
 for j in 0..d1 repeat
diff --git a/src/algebra/any.spad b/src/algebra/any.spad
index 8a5b00d6..69730ef6 100644
--- a/src/algebra/any.spad
+++ b/src/algebra/any.spad
@@ -85,7 +85,7 @@ Any() : SetCategory with
  == add
  Rep := Record(dm : SExpression, ob : None)
 
- printTypeInOutputP : Reference(Boolean) := ref false
+ printTypeInOutputP : Boolean := false
 
  obj x  == x.ob
  dom x  == x.dm
@@ -107,13 +107,13 @@ Any() : SetCategory with
   list('OutputForm)$List(Symbol))$Lisp
 
  showTypeInOutput(b : Boolean) : String ==
-  printTypeInOutputP := ref b
+  printTypeInOutputP := b
   b=> "Type of object will be displayed in output of a member of Any"
   "Type of object will not be displayed in output of a member of Any"
 
  coerce(x) : OutputForm ==
  obj1 : OutputForm := objectOf x
- not deref printTypeInOutputP => obj1
+ not printTypeInOutputP => obj1
  dom1 :=
  p : SExpression := prefix2String(devaluate(x.dm)$Lisp)$Lisp
  atom?(p) => list(p pretend OutputForm)$List(OutputForm)
diff --git a/src/algebra/card.spad b/src/algebra/card.spad
index 112a6c02..cf4b7399 100644
--- a/src/algebra/card.spad
+++ b/src/algebra/card.spad
@@ -76,7 +76,7 @@ CardinalNumber : Join(OrderedSet, AbelianMonoid, Monoid,
 Rep := Record(order : Integer, ival : Integer)
 import from Integer
 
-GCHypothesis : Reference(Boolean) := ref false
+GCHypothesis : Boolean := false
 
 -- Creation
 0   == [FINord, 0]
@@ -124,7 +124,7 @@ CardinalNumber : Join(OrderedSet, AbelianMonoid, Monoid,
 [FINord, x.ival^(y.ival)::NNI]
 x = 0 => 0
 x = 1 => 1
-GCHypothesis() => [max(x.order-1, y.order) + 1, DUMMYval]
+GCHypothesis => [max(x.order-1, y.order) + 1, DUMMYval]
 error "Transfinite exponentiation only implemented under GCH"
 
 finite? x== x.order = FINord
@@ -139,8 +139,8 @@ CardinalNumber : Join(OrderedSet, AbelianMonoid, Monoid,
   "failed"
 
 -- State manipulation
-generalizedContinuumHypothesisAssumed?() == GCHypothesis()
-generalizedContinuumHypothesisAssumed b == (GCHypothesis() := b)
+generalizedContinuumHypothesisAssumed?() == GCHypothesis
+generalizedContinuumHypothesisAssumed b == GCHypothesis := b
 
 --Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
 --All rights reserved.
diff --git a/src/algebra/curve.spad b/src/algebra/curve.spad
index 8a5762f1..c200b0e0 100644
--- a/src/algebra/curve.spad
+++ b/src/algebra/curve.spad
@@ -575,7 +575,7 @@ RadicalFunctionField(F, UP, UPUP, radicnd, n) : Exports == Impl where
   UP2 ==> SparseUnivariatePolynomial UP
   REC ==> Record(factor : UP, exponent : N)
   MOD ==> monomial(1, n)$UPUP - radicnd::UPUP
-  INIT ==> if (deref brandNew?) then startUp false
+  INIT ==> if brandNew? then startUp false
 
   Exports ==> FunctionFieldCategory(F, UP, UPUP)
 
@@ -597,9 +597,9 @@ RadicalFunctionField(F, UP, UPUP, 

[fricas-devel] [PATCH] move "first(x, n)" from STAGG to URAGG

[oldk1331]

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 it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91HYc0MXxQofoOx9xyqMx-hNTC4b-n2G0hySzRZr1e1qA%40mail.gmail.com.
diff --git a/src/algebra/aggcat.spad b/src/algebra/aggcat.spad
index 2a057cb8..01ffaaba 100644
--- a/src/algebra/aggcat.spad
+++ b/src/algebra/aggcat.spad
@@ -1420,6 +1420,18 @@ UnaryRecursiveAggregate(S : Type) : Category == RecursiveAggregate S with
   cyclic? x   == not empty? x and not empty? findCycle x
   last x  == first tail x
 
+  first(x, n) ==
+  l : List S := []
+  for i in 1..n repeat
+  empty? x => error "Index out of range"
+  l := concat(first x, l)
+  x := rest x
+  res : % := empty()
+  while not empty? l repeat
+  res := concat(first l, res)
+  l := rest l
+  res
+
   nodes x ==
   l := empty()$List(%)
   while not empty? x repeat
@@ -1616,15 +1628,8 @@ StreamAggregate(S : Type) : Category ==
 
import from Integer
 
-   c2 : (%, %) -> S
-
explicitlyFinite? x == not cyclic? x
possiblyInfinite? x == cyclic? x
-   first(x, n) == construct [c2(x, x := rest x) for i in 1..n]
-
-   c2(x, r) ==
-   empty? x => error "Index out of range"
-   first x
 
elt(x : %, i : Integer) ==
i := i - minIndex x
diff --git a/src/algebra/list.spad b/src/algebra/list.spad
index 7f382a03..e3d19e51 100644
--- a/src/algebra/list.spad
+++ b/src/algebra/list.spad
@@ -100,6 +100,14 @@ List(S : Type) : Exports == Implementation where
   minIndex x  == LISTMININDEX
   maxIndex x  == # x
 
+  first(x, n) ==
+  l : % := empty()
+  for i in 1..n repeat
+  empty? x => error "Index out of range"
+  l := concat(first x, l)
+  x := rest x
+  reverse! l
+
   rest(x, n) ==
  for i in 1..n repeat
 if empty? x then error "index out of range"

[fricas-devel] [PATCH] "#" is only defined for finiteAggregate

[oldk1331]

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)
   empty? l and zero? i

-  #x ==
-  for k in 0.. while not empty? x repeat
-  k = cycleMax and cyclic? x => error "cyclic list"
-  x := rest x
-  k
-
   tail x ==
   empty? x => error "empty list"
   y := rest x
@@ -1521,6 +1515,12 @@
   x

   if % has finiteAggregate then
+  # x ==
+  for k in 0.. while not empty? x repeat
+  k = cycleMax and cyclic? x => error "cyclic list"
+  x := rest x
+  k
+
   last(x, n) ==
   xn := x
   for i in 1..n repeat

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN91DFKYQJJ-0rgSM7L8Ryw47t4OQRSFdebS8xT%3DChHrwwA%40mail.gmail.com.

[fricas-devel] [PATCH] misc cleanup some C files

[oldk1331]

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 emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92YUU2cg910%3Dru%2B86Gu%2BBOdPZg%3DRCuOKhAwGp%2BGUmbk%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/hyper/Makefile.in b/src/hyper/Makefile.in
index 584a9215..0967dede 100644
--- a/src/hyper/Makefile.in
+++ b/src/hyper/Makefile.in
@@ -5,8 +5,6 @@ bin_PROGRAMS = htadd hypertex spadbuf hthits ex2ht
 # this is where to put the various commands
 OUTLIB=	$(fricas_target_libdir)
 
-HTADD=$(fricas_target_bindir)/htadd
-
 BITMAPS = mouse11.bitmap mouse11.mask sdown3d.bitmap sdown3dpr.bitmap \
 	sdown.bitmap sup3d.bitmap sup3dpr.bitmap sup.bitmap ht_icon
 
diff --git a/src/hyper/hyper.h b/src/hyper/hyper.h
index 7ce6fc3e..4be93e1c 100644
--- a/src/hyper/hyper.h
+++ b/src/hyper/hyper.h
@@ -75,7 +75,6 @@ struct group_item;
 #define Footer3
 #define Title 4
 
-#ifndef HTADD
 extern int MenuServerOpened;
 
 /* These are all the colors one can use in HyperDoc. */
@@ -108,9 +107,6 @@ extern XFontStruct  *gActiveFont,
 *gTtFont;
 
 
-#endif
-
-
 /** I am implementing a state node stack, this is the structure I store **/
 
 typedef struct state_node {
@@ -124,10 +120,8 @@ typedef struct state_node {
  struct state_node *next;
 } StateNode;
 
-#ifndef HTADD
 /** pointer to the top of the state node graph **/
 extern StateNode *top_state_node;
-#endif
 
 
 /* structure for a hyper text link */
@@ -401,7 +395,6 @@ extern HDWindow *gParentWindow;   /* the parent window. The one that
 extern HyperLink *quitLink; /** a special link to the protected quit page **/
 
 
-#ifndef HTADD
 /* From hyper.c */
 extern int  gXScreenNumber;
 extern Display *gXDisplay;
@@ -439,7 +432,6 @@ extern int need_scroll_up_button;
 extern int scrolling;
 extern int need_scroll_down_button;
 extern int space_width;
-#endif
 
 /* Here are some of the functions and constants declared and needed in
   htadd.c**/
diff --git a/src/hyper/lex.c b/src/hyper/lex.c
index dafc0a2a..a2000372 100644
--- a/src/hyper/lex.c
+++ b/src/hyper/lex.c
@@ -317,10 +317,8 @@ AGAIN:
 last_command = cmd = get_int(spad_socket);
 if (cmd == EndOfPage)
 return EOF;
-#ifndef HTADD
 if (cmd == SpadError)
 spad_error_handler();
-#endif
 }
 read_again = get_string_buf(spad_socket, sock_buf, 1023);
 /* this will be null if this is the last time*/
@@ -815,7 +813,6 @@ get_expected_token(int type)
 }
 
 
-#ifndef HTADD
 static void
 spad_error_handler(void)
 {
@@ -843,7 +840,6 @@ reset_connection(void)
 connect_spad();
 }
 }
-#endif
 
 
 /* returns true if spad is currently computing */
diff --git a/src/include/nagman.H1 b/src/include/nagman.H1
deleted file mode 100644
index 1d98e035..
--- a/src/include/nagman.H1
+++ /dev/null
@@ -1,7 +0,0 @@
-extern void main(int argc, char * * argv);
-#ifdef _NAGMAN_C
-static void term(int sig);
-static long size_of_file(char * filename);
-static void rpcloop(void);
-static void catchSignals(void);
-#endif

Re: [fricas-devel] [BUG] bug in "pairsum" causes wrong integration result

[oldk1331]

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+-+
>--+x\|a  - 8 %E
>>   %E log()
>--+4+-+
> 4 \|a
>  4096 %E  - a = 0
>+
>4+-+
>--+x\|a  - 8 %F
>>   %F log()
>--+4+-+
> 4 \|a
>  4096 %F  + a = 0
>  Type:
Union(Expression(Integer),...)
>
> Unfortunatly, this causes troubles for definite integrator.
> Basically, we need to teach 'limit' how to handle 'rootSum'.
>

Shouldn't we try to simplify 'rootSum' with coefficients like
"%E^4 +- a = 0"?

-- 
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 to fricas-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN90BM0-ucsS-NAhPNSZEzNRHycfTK5MLyqsmbiiknrO97Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] [BUG] bug in "pairsum" causes wrong integration result

[oldk1331]

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 obviously incorrect.

Also
in1724a:=integrate(-z^2/(z^2-1)*(1-(I*z)^(1/2))^(1/2), z)
is wrong, although its return value is not 0.


The problem happens in "pairsum" in irexpand.spad.

This "pairsum" function tries to avoid cases like both
x^(1/n) and (-x)^(1/n) (where n is even) appears in result.

Take "integrate(a^(1/4)/(x^8-1),x)" for example, in order to
solve "?^4+a/4096" appeared in
"split internalIntegrate(a^(1/4)/(x^8-1),x)",
"lg2func" uses "zeroOf" to introduce (-a)^(1/4) which causes
"pairsum" to return empty result.

I suggest:

1. Add a warning/error in "pairsum" when it tries to return empty.
2. We can handle cases like "?^4+a" "?^4+a*?^2+b" in "lg2func" better.

-- 
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 to fricas-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN93UMzAehRuyyMFbp8afRXf%3DBsbKpKF2Jbnkrd7kb9r86Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] error building fricas 1.3.5-2 on Linux

[oldk1331]

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 fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN92a2Yu83VBxwN7-aAGWX0k0dfMcx9NGAvRsuFxs4kvq7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] [PATCH] fix a C bug in hyperdoc

[oldk1331]

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 eb[128];
 token_name(token.type);
-sprintf(eb, "Unexpected Token %s\n", eb);
+sprintf(eb, "Unexpected Token %s\n", ebuffer);
 htperror(eb, HTCONDNODE);
 }
 break;

-- 
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 to fricas-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/41b92c49-f32a-d90a-a338-ec4dd8e876bc%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] [PATCH] remove default value for $AXIOM

[oldk1331]

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) {
-fprintf(stderr,
-"Build_db_filename: Defaulting on $AXIOM\n");
-SPAD = (char *) def_spad;
+fprintf(stderr, "build_db_filename: $AXIOM is empty\n");
+exit(-1);
 }
 sprintf(dbfilename, "%s/share/hypertex/pages/%s", SPAD,
db_file_name);
 sprintf(path, "%s/share/hypertex/pages", SPAD);
diff --git a/src/hyper/hyper.h b/src/hyper/hyper.h
index fcfffd2a..7ce6fc3e 100644
--- a/src/hyper/hyper.h
+++ b/src/hyper/hyper.h
@@ -447,7 +447,6 @@
 #define NoChar   -
 #define temp_dir "/tmp/"
 #define db_file_name "ht.db"
-#define def_spad "/usr/local/fricas"


 /* Types of HyperDoc pages */
diff --git a/src/hyper/spadint.c b/src/hyper/spadint.c
index 9ca1208e..da460309 100644
--- a/src/hyper/spadint.c
+++ b/src/hyper/spadint.c
@@ -190,7 +190,8 @@

 SPAD = (char *) getenv("AXIOM");
 if (SPAD == NULL) {
-sprintf(SPAD, "/spad/mnt/rios");
+fprintf(stderr, "start_user_buffer: $AXIOM is empty\n");
+exit(-1);
 }
 sprintf(spadbuf, "%s/lib/spadbuf", SPAD);
 sprintf(complfile, "%s/lib/command.list", 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 it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/2db4e727-d949-edae-2079-4e9a64767758%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Compile fail for an old spad file

[oldk1331]

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:
> 
> )compile ORESUS.spad
>  
>    Compiling FriCAS source code from file 
>       /Users/lxj/Dropbox/SourceCode/MyProjects/ORESUS/test/ORESUS.spad 
>       using old system compiler.
>    ORESUS abbreviates domain UnivariateSkewSeries 
> 
>    initializing NRLIB ORESUS for UnivariateSkewSeries 
>    compiling into NRLIB ORESUS 
>    compiling exported coerce : R -> $
> ** comp fails at level 2 with expression: **
> error in function coerce 
> 
> (|construct| | << | (|::| (|construct| |r|) (|Stream| R)) | >> | 0
>              (|::| 0 (|OrderedCompletion| (|Integer|
> ** level 2  **
> $x:= (:: (construct r) (Stream R))
> $m:= R
> $f:=
> |r| # #) (|copy| #) (|setelt!| #) (|lo| #) ...)))
>  
> I'm pretty sure this file could be compiled before. It seems FriCAS has
> a lot of changes  
> over time. 
> 
> So any suggestions on how to fix it?
> 
> The spad file is attached.
> 
> Thanks in advance!
> 
> BR
> XJ
> 
> -- 
> 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 to fricas-devel@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/a3104bc3-77ba-4223-ae47-f04c4ba39adc%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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 to fricas-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/0bc96f67-7d9b-0f65-66a4-d4f9b76388c5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
-- Univariate Skew Series Domain

)abb domain ORESUS UnivariateSkewSeries

B   ==> Boolean
I   ==> Integer
NNI ==> NonNegativeInteger
INF ==> OrderedCompletion I
Sy  ==> Symbol
LS  ==> List Sy
PC  ==> UnivariatePolynomial(Var,R) 
BOP ==> BasicOperator
OUT ==> OutputForm
LC  ==> List R
SC  ==> Stream R
FI  ==> Fraction(Integer)

SLen ==> _$streamCount$Lisp
SMin ==> minIndex([1$R]::SC)


UnivariateSkewSeries(R:Ring, Var:Symbol, sigma:Automorphism R, 
invsigma:Automorphism R, delta: R -> R) : Exports == Implementation where

Exports == Join(Ring, BiModule(R, R)) with

coerce : (R) -> %
++ \axiom{coerce(r)} converts an element of 
++ \axiom{Ring} into a skew series.

series: (SC,I) -> %
++ \axiom{series(sc,n)} generates a skew 
++ series of order \axiom{n} from a stream 
++ \axiom{sc} of coefficients.

series: (LC,I) -> %
++ \axiom{series(lc,n)} generates a skew 
++ series of order \axiom{n} from a list 
++ \axiom{lc} of coefficients.

series: (SC,I,INF) -> %
++ \axiom{series(cs, m, n)} generate skew
++ series by explicitly indicating the lowest
++ order.

pos: % -> %
++ \axiom{pos(s)} computes the non-negative
++ part of the skew series \axiom{s}

neg : % -> %

++ \axiom{neg(s)} computes the negative part 
++ of the skew series \axiom{s}.  

order: (%) -> I
++ \axiom{order(s)} returns the highest 
++ exponent index occuring in \axiom{s}.

lowestOrder: (%) -> INF
++ \axiom{lowestOrder(s)} returns the lowest
++ exponent index occuring in \axiom{s}.

coefficient: (%, I) -> R
++ \axiom{coefficient(s,i)} returns the 
++ coefficient of a specific exponent 
++ \axiom{DOp^i}.

coefficients: (%) -> SC
++ \axiom{coefficients(s)} returns the stream 
++ of the coefficients of a skew series \axiom{s}.

leadingCoefficient: (%) -> R
++ \axiom{leadingCoefficient(s)} returns the 
++ highest order exponent's coefficient of a
++ skew series \axiom{s}

0: constant -> %
++ 

[fricas-devel] [PATCH] fix an error in hyperdoc

[oldk1331]

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}")

Clearly it should be "htSayList".

diff --git a/src/interp/ht-root.boot b/src/interp/ht-root.boot
index 44339a4b..8b70a42b 100644
--- a/src/interp/ht-root.boot
+++ b/src/interp/ht-root.boot
@@ -89,10 +89,10 @@
   htMakePage '((domainConditions (isDomain INT (Integer
   htMakePage  [['bcStrings,[5,STRINGIMAGE val,name,'INT]]]
 class = 'STRING =>
-  htSay('"{\em ",val,'"}\space{1}")
+  htSayList ['"{\em ", val, '"}\space{1}"]
 for x in options repeat
   val = x or val = true and x = 'on or null val and x = 'off =>
-htSay('"{\em ",x,'"}\space{1}")
+htSayList ['"{\em ", x, '"}\space{1}"]
   htMakePage [['bcLispLinks,[x,'"
",'htSetSystemVariable,[variable,x
   fn(t,al,firstTime) ==
 atom t => al

-- 
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 to fricas-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN93PaBpE%3DkhUibSJNur6zcOc6PgVQCEk%3DpoESS4_NL54HA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Re: [PATCH] move implementation from IndexedList to List; cleanup

[oldk1331]

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 attached 2 patches tries to simplify and cleanup domain
> IndexedList and List.
>
> First patch, it moves almost all functions from IndexedList to
> List.  Because these functions are not related with index at all.
>
> Second patch, it removes many usage of Lisp function call by
> SPAD function call.  This will not harm performance, because
> in domain List we can do inline optimization (we can't inline
> in IndexedList).  There is also a benefit that these function
> call will be type checked.

-- 
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 to fricas-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN90-DzR-mg4OWJb91iyJhG%2BERAhJ3YbC1y3o5%3D3ojODWgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] [PATCH] fix output of "vconcat([])$OUTFORM"

[oldk1331]

(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
+++ b/src/interp/i-output.boot
@@ -2034,6 +2034,7 @@
   WIDTH u.1 + aggwidth CDDR u

 vconcatapp(u, x, y, d) ==
+  null rest u => d
   w := vConcatWidth u
   y := y + superspan u.1 + 1
   for a in rest u repeat
@@ -2058,8 +2059,10 @@
   APP('")",x,y,d)

 vConcatSub u ==
+  null rest u => 0
   subspan u.1 + +/[height a for a in CDDR u]
 vConcatSuper u ==
+  null rest u => 0
   superspan u.1
 vConcatWidth u ==
   w := 0

-- 
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 to fricas-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAGBJN90Z61eijssqKVGhnZy-4Qo11UYOf5UXg4uFR%2BLU2Az4oA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.