Discussion:
a modern Computer Algebra System (CAS) for classic Slackware 32bit
(too old to reply)
Per Christensen
2021-03-28 02:28:13 UTC
Permalink
In 1617 the Scottish nobleman and hobby mathematician John Napier of
Edinburgh invented a twist of the abacus, the Napier Bones.
With a set of 10 square bones (or rods) of wood engraved with a system
of numbers and enclosed in a carrying case complex calculations
(especially multiplication and division) could be done in a fast and
reliable way .
In another effort to simplify computing Napier later discovered the
logarithmic function immediately being tabulated by the Oxford
mathematician Henry Briggs and further refined by the London professor
Gûnther in many types of sliding rulers (e.g. for calculating projectile
trajectories).
Napiers discovery was something of a leap and Briggs to Napier expressed
his astonishment - ”why nobody else found it out before, when, now being
known, it appears so easy”.
Tables and sliding rulers now ruled (sic!) among architects, engineers
and in latin-schools until numeric, even programmable calculators became
reasonable in the mid 1970's (say half of a students monthly expenses :)).
Symboloc math (read calculus) still had to be done by hand for another
decade until calculators type the TI89 entered the market, able to
integrate and solve differential equations.
And now in 2021 we are offered powerful Computer Algebra Systems for
free, where e.g. Xcas/Giac (1.7) run beautiful on classic 32bit Slackware.
It is written by the french mathematician M. Bernard Parisse and M.
Renee De Graeve is author of an English 1000 page manual.For 32 bit
Xcas/Giac must be compiled from source according to the "Install" advisory.
Personal comments is: math apps. need the basic 100Mb TeXLive
SlackBuild. The present PARI build and installs fine, MFPR and MPFI do
it as well, the FLTK SlackBuild is great, for speedy computation
Atlas3.8, Lapack3.6 and BLAS3.6 is installed on my system, ntl-10.5.0
was configured with $ ./configure NTL_GMP_LIP=on, and static libraries
(libclicquer.a and libnauty.a) was build from compiled .o files with the
ar command (e.g ar res libnauty.a *.o) and copied to usr/local/lib. The
corresponding header files had to be copied to directories
/usr/local/include/nauty respectively /usr/local/include/clicquer.
In the end ranlib (indexing) must be applied to the static libraries,
and ldconfig executed to make Slackware reckognize the new libraries.
Well - an evenings work - and centuries of collected mathematical
knowledge to explore at your fingertips!
root
2021-03-28 14:19:44 UTC
Permalink
Per Christensen <***@gmail.com> wrote:

/snip/

Why not provide some links, first to the 1000 page manual,
and then next to sources. Why is the package limited
to 32 bit Slack?
Per Christensen
2021-03-28 19:45:12 UTC
Permalink
Post by root
/snip/
Why not provide some links, first to the 1000 page manual,
and then next to sources. Why is the package limited
to 32 bit Slack?
Here links:

Manual: https://www-fourier.ujf-grenoble.fr/~parisse/giac/cascmd_en.pdf
Source: https://www-fourier.ujf-grenoble.fr/~parisse/giac/giac_stable.tgz
GLPK: http://ftp.gnu.org/gnu/glpk/
PARI 2.13: https://pari.math.u-bordeaux.fr/
NTL 10.5.0: https://libntl.org/download.html
ECM: http://ecm.gforge.inria.fr/
MPFI 1.5.4: https://gforge.inria.fr/projects/mpfi/
MPFR 3.1.6: https://gforge.inria.fr/projects/mpfr/
nauty 27r1: https://pallini.di.uniroma1.it/
clicquer 1.21: https://users.aalto.fi/~pat/cliquer.html
FLTK: https://slackbuilds.org/repository/14.2/libraries/fltk/
TeXLive: https://slackbuilds.org/repository/14.2/office/texlive/

Slackware 14.2 32bit packages (may already be installed in your system):
atlas-3.8.3-i486-2salix
(http://ftp.nluug.nl/os/Linux/distr/salix/i486/extra-14.2/)
blas-3.6.0-i586-1gv
lapack-3.6.0-i586-1gv
gmp-6.1.1-i586-1
curl-7.74.0-i586-1_slack14.2
readline-6.3-i586-2
libsamplerate-0.1.8-i486-1

Should be no problems building a (probably much faster) 64bit GIAC on
Slackware 64
King Beowulf
2021-03-28 21:33:44 UTC
Permalink
On Sun, 28 Mar 2021 04:28:13 +0200, Per Christensen wrote:

---snip---
Post by Per Christensen
And now in 2021 we are offered powerful Computer Algebra Systems for
free, where e.g. Xcas/Giac (1.7) run beautiful on classic 32bit
Slackware. It is written by the french mathematician M. Bernard Parisse
and M.
--- snip---

Why not just head over to https://www.slackbuilds.org for a variety of CAS
package build scripts - listed with dependencies and mo fiddling with
libraries needed?

scilab
sage
smath-studio
mathomatic
maxima
cadabra2
reduce-algebra

to name a few, targeting general mathematics or also engineering etc. A
nice feature chart is here:

https://en.wikipedia.org/wiki/List_of_computer_algebra_systems

Perhaps provide a submission for Slackbuilds.org?
Per Christensen
2021-03-29 11:51:41 UTC
Permalink
Post by King Beowulf
---snip
Why not just head over to https://www.slackbuilds.org for a variety of CAS
package build scripts - listed with dependencies and mo fiddling with
libraries needed?
scilab
sage
smath-studio
mathomatic
maxima
cadabra2
reduce-algebra
to name a few, targeting general mathematics or also engineering etc. A
https://en.wikipedia.org/wiki/List_of_computer_algebra_systems
Perhaps provide a submission for Slackbuilds.org?
---snip
Thank you for suggestions :) I will take a look on cadabra2 and
mathomatic - never heard of them!

For further info: here a comparison of the speed of math apps. when
calculating very large numbers in the console:

Python3 65534**65534 15 sec. on a 10 year old laptop with 2GB RAM
GIAC 65534^65534 0.03 sec.
Maxima 65534^65534; 19 sec.
PARI 65534^65534 approximately also 0.03 sec.
R and Octave do not handle these big numbers (might do if extra packages
loaded?).

I guess the "quality" or "exactness" of Xcas is comparable to e.g. Maxima.
GIAC (the library) will interface with python via giacpy and could be of
use if handling "big data", meteorology, climate modelling?
Eli the Bearded
2021-03-29 16:53:26 UTC
Permalink
Post by Per Christensen
For further info: here a comparison of the speed of math apps. when
Python3 65534**65534 15 sec. on a 10 year old laptop with 2GB RAM
GIAC 65534^65534 0.03 sec.
Maxima 65534^65534; 19 sec.
PARI 65534^65534 approximately also 0.03 sec.
R and Octave do not handle these big numbers (might do if extra packages
loaded?).
Locally, bc takes me 3 seconds, but it's a different device than you are
using. Why didn't you try bc or dc?

$ echo 65534^65534 | time bc | wc
4642 4642 324926

real 0m2.99s
[...]
$ echo 65534 65534 ^p | time dc | wc
4575 4575 324792

real 0m2.80s
[...]

(Traditionally basic calculator, bc, was a non-Polish notation front end
to desktop calculator, dc, but I think they are completely separate
programs in Gnu-land. Both, here, format the output similarly, but use
a different line length, so more overhead for backslash-newline wrapping.)

Elijah
------
uses bc much more frequently than dc
Per Christensen
2021-03-29 21:34:01 UTC
Permalink
Post by Eli the Bearded
-----
Locally, bc takes me 3 seconds, but it's a different device than you are
using. Why didn't you try bc or dc?
-------
(Traditionally basic calculator, bc, was a non-Polish notation front end
to desktop calculator, dc, but I think they are completely separate
programs in Gnu-land.
-----
That was interesting! Polish notation (with the operand in the end) was
used in my study friend's expensive HP-65 calculator in the 1970's.He
mostly used it for playing a sort of moon-landing game.
On my computer I get the same result as you in 0:08.69 repectively
0:08.74 seconds
Henrik Carlqvist
2021-03-30 05:28:14 UTC
Permalink
Post by Eli the Bearded
$ echo 65534^65534 | time bc | wc
4642 4642 324926
My guress is that bc needs more time to print the long result than to
calculate the long result. That theory can be made probable by comparing
at the time needed for wc:

bash-4.3$ echo "65534^65534" | time bc | wc
2.57user 0.00system 0:02.58elapsed 99%CPU (0avgtext+0avgdata
12960maxresident)k
0inputs+0outputs (0major+659minor)pagefaults 0swaps
4642 4642 324926
bash-4.3$ echo "65534^65534" | bc | time wc
4642 4642 324926
0.00user 0.00system 0:02.57elapsed 0%CPU (0avgtext+0avgdata
5824maxresident)k
0inputs+0outputs (0major+74minor)pagefaults 0swaps
bash-4.3$

So wc needs almost exactly as much time as bc and wc is only handling the
text.

regards Henrik
Eli the Bearded
2021-03-30 16:40:09 UTC
Permalink
In alt.os.linux.slackware,
Post by Henrik Carlqvist
Post by Eli the Bearded
$ echo 65534^65534 | time bc | wc
4642 4642 324926
My guress is that bc needs more time to print the long result than to
calculate the long result. That theory can be made probable by comparing
A good theory, but no. A better way to test it is to have bc calculate
the value and silently store it.

$ echo j=65534^65534 | time bc

real 0m2.99s
user 0m2.92s
sys 0m0.01s

No output from bc, still three seconds.

Elijah
------
with dc just leave out the 'p'rint command
Rich
2021-03-30 18:05:18 UTC
Permalink
Post by Eli the Bearded
In alt.os.linux.slackware,
Post by Henrik Carlqvist
Post by Eli the Bearded
$ echo 65534^65534 | time bc | wc
4642 4642 324926
My guress is that bc needs more time to print the long result than to
calculate the long result. That theory can be made probable by comparing
A good theory, but no. A better way to test it is to have bc calculate
the value and silently store it.
$ echo j=65534^65534 | time bc
real 0m2.99s
user 0m2.92s
sys 0m0.01s
No output from bc, still three seconds.
Watch the bc process while it is spending the three seconds computing
the result.

You can watch its memory growing.

Most of the time is going to the actual work of computing the result
(the result is a very large number) and a small amount to allocating
the memory necessary to store the internal representation bc uses for
the result.
gamo
2021-04-15 01:15:24 UTC
Permalink
$ echo j=65534^65534 | time bc
real 0m2.99s
user 0m2.92s
sys 0m0.01s
time echo 65534^65534 | gp

real 0m0,023s
user 0m0,024s
sys 0m0,001s

where gp is the nice calculator from PARI
--
http://gamo.sdf-eu.org/
perl -E 'say "Code could contain bugsh";'
Eli the Bearded
2021-04-15 18:14:39 UTC
Permalink
Post by gamo
$ echo j=65534^65534 | time bc
real 0m2.99s
time echo 65534^65534 | gp
real 0m0,023s
user 0m0,024s
sys 0m0,001s
where gp is the nice calculator from PARI
Yeah, PARI was on the list of initially timed tools in Per Christensen's
post with message-id <6061c3f3$0$669$***@news.sunsite.dk>. I was
responding with common tools he missed. Christensen's time for PARI was
0.03 seconds, in-line with your numbers and much higher than bc and dc.
The chief advantage of bc / dc is the likelihood that it is already
intstalled.

Elijah
------
the Maxima and Python3 numbers Christensen had were terrible

Loading...