Re: [fricas-devel] GPT4 and computer algebra

[Bill Page]

Another example:

https://www.nature.com/articles/s41586-023-06747-5

On Wed, Jan 17, 2024 at 10:56 AM Waldek Hebisch  wrote:

> …
> One more thing: early in history of AI there was Eliza.
> It was simple pattern matcher clearly having no inteligence,
> yet it was able to fool some humans to belive that they
> communicate with other human (ok, at least for some time).
> Some people take this to consider all solved AI problems
> as kind of fake and show that the problem was not about
> inteligence.  But IMO there is different possiblity: that
> all our inteligence is "fake" in similar vein.  In other
> words, we do not solve general problem but use tricks which
> happen to work in real life.  Or to put it differently,
> we may be much more limited than we imagine.  Eliza clearly
> shows that we can be easily fooled into assuming that
> something has much more abilities than it really has
> (and "something" may be really "we").


+1

I strongly agree with your point in parenthesis above.  It seems to me that
the current generation of AI tells us more about the actual capabilities of
human beings and the nature of intelligence than it does about the
limitations of computer systems.



>

-- 
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/CAC6x94RH1y4a_-BtJVkEDFS2B-d65SUbesP%3Dx93g5bKwX8oMjA%40mail.gmail.com.

Re: Fwd: [fricas-devel] Extentions to symbols and strings

[Bill Page]

On Sun, 26 Nov 2023 at 09:15, Waldek Hebisch  wrote:
>
> Attached is code defining Greek symbols organized as a package.
>
> Note: ucodeToString takes Unicode code point as argument, so
> I had to decrease all character codes by 1 (index used in
> original code adds 1).
>
> Extra remark: Some capital Greek letters look exactly the
> same as roman letters.  They are needed when one wants
> actual Greek text, but one probably should not use them
> in math.  For this reason some capital Greek letters
> were/are excluded from TeX.  I think it makes sense to
> exclude them.
>

-1 No, I think you should keep them.  Whether Greek versus Roman characters
look the same depends on the presentation layer, i.e. what fonts are used
to render the final result. The same thing applies to other homoglyph
characters in other language, e.g. Latin and Cryllic. It is often of
interest to use different font sets for different languages appearing in
the same document. TeX should not be considered as a de facto standard.

-- 
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/CAC6x94RXur0tD2Dxi87OTP%3D4WmxJaBCiSZR%3DaowoHzT7YMH-4w%40mail.gmail.com.

Re: [fricas-devel] FriCAS banner

[Bill Page]

Note that in English one would normally write: "built with" (past tense,
irregular) instead of "build with"

On Sat, Nov 25, 2023, 5:34 PM Waldek Hebisch,  wrote:

> I have now added detecte Lisp flavour and version to the
> banner, like:
>
>Version: FriCAS 2023-06-17 build with sbcl 2.2.9.debian
>
> --
>   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/ZWJ2hT5n__xXlWNJ%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/CAC6x94Tt01T-jBq0mr-h7u8NfZaNM3gAheuxBibFL97FWYWO9w%40mail.gmail.com.

Re: [fricas-devel] a limit failure

[Bill Page]

(1) -> f:=differentiate(complexNormalize(log(tan(%pi/2*tanh(x,x);

Type:
Expression(Integer)
(2) -> output lines(formatExpression(f)$Format1D).1

(-8*%pi*(%e^x)^2*%e^((%pi*sqrt(-1)*(%e^x)^2+(-%pi)*sqrt(-1))/((%e^x)^2+1)))/(

(sqrt(-1)*(%e^x)^4+2*sqrt(-1)*(%e^x)^2+sqrt(-1))*(%e^((%pi*sqrt(-1)*(%e^x)^2+

(-%pi)*sqrt(-1))/((%e^x)^2+1)))^2+(-sqrt(-1))*(%e^x)^4+-2*sqrt(-1)*(%e^x)^2-s
  qrt(-1))
   Type:
Void
(3) -> limit(f,x=%plusInfinity)

   (3)  2
  Type:
Union(OrderedCompletion(Expression(Integer)),...)

On Wed, 23 Nov 2022 at 12:48, Waldek Hebisch 
wrote:

> On Wed, Nov 23, 2022 at 05:21:42PM +0800, Qian Yun wrote:
> > FYI, it can be correctly solved by "mrv_limit" which uses Gruntz
> > algorithm.  However I don't know why this code path is not enabled
> > for this function.  (see "is_exp_log" in limitps.spad).
> >
> > - Qian
> >
> > (1) -> )expose MrvLimitPackage
> >MrvLimitPackage is now explicitly exposed in frame frame1
> > (1) -> f := D(log(tan(%pi/2*tanh(x))), x);
> >
> > Type:
> > Expression(Integer)
> > (2) -> mrv_limit(f, x=%plusInfinity)
> >
> >(2)  2
>
> This is due to 'tan'.  Termination of Gruntz algorithm depends
> on having exp-log function, for trigonometric functions
> Gruntz may fail.  This is easy case, but ATM we have no way
> to distinguish it from problematic cases.
>
> --
>   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/20221123174757.GA25181%40fricas.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/CAC6x94SGNmRxdACtiyWpUAqCTJJ72pAdo6jWJadyewpBVnSi7w%40mail.gmail.com.

Re: [fricas-devel] is there an official Fricas icon?

[Bill Page]

>From FriCAS wiki

   http://fricas-wiki.math.uni.wroc.pl/FrontPage

there is a variant of the original Axiom icon.

On Sat, 20 Aug 2022 at 10:13, Ralf Hemmecke  wrote:
>
>  > But what I really think is that a real logo, a figure, a drawing etc.
>  > should be used with the name of FriCAS (in the logo eventually or
>  > below).
>
> Right.
>
> I think we should call for a little competition. ;-)
> Anyone interested? Let's collect some ideas.
> See attachment.
>
> 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/2325fe2c-ea32-d919-c407-55992960ac08%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/CAC6x94TDRU%2B%3DCCGX0Mf3qwTmXQqrVnQT2Vzx3PU5r4cF_m0%3DMQ%40mail.gmail.com.

[fricas-devel] fricas0 and clasp

[Bill Page]

On Sun, 3 Jul 2022 at 06:38, Qian Yun  wrote:
>
> I find the idea of pure lisp build of FriCAS very interesting and
> useful.  I did some improvement of Kurt's fricas0 at
> https://github.com/oldk1331/fricas0
>
> The biggest advantage is that you can start FriCAS quickly and
> do computation right away.
> ...

Clasp is a new implementation of Lisp based on LLVM similar to the way
that ABCL is based on the Java VM.

https://github.com/clasp-developers/clasp

I was interested to see whether Clasp could run fricas0 since one of
the selling points for Clasp is the ability to directly and easily
link with c++ libraries. Apparently Clasp can run maxima. See

https://github.com/clasp-developers/clasp/wiki/How-to-run-maxima-in-clasp

Building Clasp from source is quite time consuming so I ran Clasp
using the pre-compiled docker image:

wspage@strix:~$ docker run -it ghcr.io/clasp-developers/clasp:latest
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.

app@48e1623454d5:~$ git clone https://github.com/oldk1331/fricas0.git
Cloning into 'fricas0'...
remote: Enumerating objects: 5550, done.
remote: Counting objects: 100% (1531/1531), done.
remote: Compressing objects: 100% (926/926), done.
remote: Total 5550 (delta 1024), reused 657 (delta 603), pack-reused 4019
Receiving objects: 100% (5550/5550), 23.91 MiB | 1.83 MiB/s, done.
Resolving deltas: 100% (4484/4484), done.

app@48e1623454d5:~$ cd fricas0

app@48e1623454d5:~/fricas0$ clasp --load fricas
Starting cclasp-boehmprecise-1.0.0-313-gea5c624d9-cst ... loading image...
Loading resource file /home/app/.clasprc
; caught STYLE-WARNING:
;   The variable OPTIONS is defined but never used.
; at unknown location
;
;
; compilation unit finished
;   caught 1 STYLE-WARNING condition
;
; caught STYLE-WARNING:
;   The variable CORE-IMAGE is defined but never used.
; at unknown location
;
; caught STYLE-WARNING:
;   The variable RESTART is defined but never used.
; at unknown location
;
;
; compilation unit finished
;   caught 2 STYLE-WARNING conditions
;
; caught STYLE-WARNING:
;   Undefined function EXIT-WITH-STATUS
; at unknown location
;
;
; compilation unit finished
;   caught 1 STYLE-WARNING condition
;
; caught STYLE-WARNING:
;   The variable VAR-NAME is defined but never used.
; at unknown location
;
;
; compilation unit finished
;   caught 1 STYLE-WARNING condition
;
; caught STYLE-WARNING:
;   The variable S is defined but never used.
; at unknown location
;
;
; compilation unit finished
;   caught 1 STYLE-WARNING condition
;
; caught WARNING:
;   Undefined variable |writeablep|
; at unknown location
;
; caught WARNING:
;   Undefined variable INT
; at unknown location
;
; caught WARNING:
;   Undefined variable C-STRING
; at unknown location
;
; caught STYLE-WARNING:
;   Undefined function FILENAME
; at unknown location
;
; caught STYLE-WARNING:
;   Undefined function FRICAS-FOREIGN-CALL
; at unknown location
;
;
; compilation unit finished
;   caught 3 WARNING conditions
;   caught 2 STYLE-WARNING conditions
;

Condition of type: UNBOUND-VARIABLE
The variable FRICAS-LISP:|writeablep| is unbound.
No restarts available.

Top level in: #.



But the result is an error when FriCAS tries to call an external
routine via FFI. I don't know much about this except that after a
quick search of the FriCAS mailing list suggests that a apparently
similar problem involving |writeablep was reported at one point with
ECL The resolution of the problem had something to do with implicit
declarations and external function calls.

https://github.com/fricas/fricas/issues/59

Does anyone have any suggestions on what to try?

Bill Page.

-- 
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/CAC6x94SW2KHPmrvJHb7vtdqHv2DiK%3D_VzO0hJLFpCBSNvfg1Yw%40mail.gmail.com.

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

[Bill Page]

Sorry, I forgot you also wanted to know which Linux.

wspage@ASUS:~/Desktop$ uname -r
5.4.0-120-generic
wspage@ASUS:~/Desktop$ cat /etc/os-release
NAME="Linux Mint"
VERSION="20.3 (Una)"
ID=linuxmint
ID_LIKE=ubuntu
PRETTY_NAME="Linux Mint 20.3"
VERSION_ID="20.3"
HOME_URL="https://www.linuxmint.com/;
SUPPORT_URL="https://forums.linuxmint.com/;
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/;
PRIVACY_POLICY_URL="https://www.linuxmint.com/;
VERSION_CODENAME=una
UBUNTU_CODENAME=focal

On Fri, 17 Jun 2022 at 12:19, Bill Page  wrote:
>
> When I do this
>
> wspage@ASUS:~/Desktop$ echo 100 | sudo tee /proc/sys/kernel/ns_last_pid
>
> and then run fricas I get
>
> wspage@ASUS:~/Desktop$ fricas
>
> debugger invoked on a SIMPLE-ERROR in thread
> #:
>   Error opening shared object "libssl.so.1.0.0":
>   libssl.so.1.0.0: cannot open shared object file: No such file or directory.
>
> Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
>   0: [CONTINUE   ] Skip this shared object and continue.
>   1: [RETRY  ] Retry loading this shared object.
>   2: [CHANGE-PATHNAME] Specify a different pathname to load the shared
> object from.
>   3: [ABORT  ] Exit from the current thread.
>
> (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME
> #P"libssl.so.1.0.0" :NAMESTRING "libssl.so.1.0.0" :HANDLE NIL
> :DONT-SAVE NIL))
> 0] (HyperDoc) Error opening FriCAS server. Retrying ...
> (HyperDoc) Couldn't connect to FriCAS server!
> (HyperDoc) Couldn't connect to FriCAS server!
> ^C
> ^C does not break out of the loop and the session appears hung. So ...
> ^Z
> [1]+  Stopped fricas
> wspage@ASUS:~/Desktop$ kill %1
>
> On Fri, 17 Jun 2022 at 08:59, Qian Yun  wrote:
> >
> > Hello everyone,
> >
> > I would like to know if your system is affected as well.
> > You can simply bump your system's next PID by:
> >
> >  echo 100 | sudo tee /proc/sys/kernel/ns_last_pid
> >
> > Run "fricas" and see if it has buffer overflow error message.
> >
> > If you do have such error message, please reply this email
> > with your Linux distro's version.
> >
> > If you do not have problem, you can reply if you like.
> >
> > - Thanks,
> > - Qian
> >
> > On 6/17/22 20:46, Qian Yun wrote:
> > > And we do not propagate CFLAGS properly, so we can not
> > > use "make CFLAGS=-D_FORTIFY_SOURCE=1" to slip in this
> > > workaround.
> > >
> > > - Qian
> > >
> > > On 6/13/22 23:03, Qian Yun wrote:
> > >> Hi Waldek,
> > >>
> > >> The original problem still exists:
> > >>
> > >> I can still get
> > >>  "*** buffer overflow detected ***: terminated"
> > >> when PID goes over 1 million.
> > >>
> > >> That's because on my system GCC has auto hardening feature.
> > >> (This feature should be popular on other distros as well.)
> > >> To be precise, GCC automatically compiles with
> > >> "-D_FORTIFY_SOURCE=2".  This is adding runtime checks
> > >> that gives this particular error.
> > >>
> > >> Turning it down to "-D_FORTIFY_SOURCE=1" can prevent
> > >> this problem.
> > >>
> > >> However, I still think using "0-9a-z" to encode socket
> > >> address is a better solution.
> > >>
> > >> - Qian
> > >>
> > >> On 9/9/20 18:30, 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.
> >
> > --
> > 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/c7fcd63a-e746-bbf0-3a4a-160efe4dc485%40gmail.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/CAC6x94T4w-SzMmNsaR3CgMo%3DA8kxLY8S1REF41oz27tJ2VMz%3Dg%40mail.gmail.com.

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

[Bill Page]

When I do this

wspage@ASUS:~/Desktop$ echo 100 | sudo tee /proc/sys/kernel/ns_last_pid

and then run fricas I get

wspage@ASUS:~/Desktop$ fricas

debugger invoked on a SIMPLE-ERROR in thread
#:
  Error opening shared object "libssl.so.1.0.0":
  libssl.so.1.0.0: cannot open shared object file: No such file or directory.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE   ] Skip this shared object and continue.
  1: [RETRY  ] Retry loading this shared object.
  2: [CHANGE-PATHNAME] Specify a different pathname to load the shared
object from.
  3: [ABORT  ] Exit from the current thread.

(SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME
#P"libssl.so.1.0.0" :NAMESTRING "libssl.so.1.0.0" :HANDLE NIL
:DONT-SAVE NIL))
0] (HyperDoc) Error opening FriCAS server. Retrying ...
(HyperDoc) Couldn't connect to FriCAS server!
(HyperDoc) Couldn't connect to FriCAS server!
^C
^C does not break out of the loop and the session appears hung. So ...
^Z
[1]+  Stopped fricas
wspage@ASUS:~/Desktop$ kill %1

On Fri, 17 Jun 2022 at 08:59, Qian Yun  wrote:
>
> Hello everyone,
>
> I would like to know if your system is affected as well.
> You can simply bump your system's next PID by:
>
>  echo 100 | sudo tee /proc/sys/kernel/ns_last_pid
>
> Run "fricas" and see if it has buffer overflow error message.
>
> If you do have such error message, please reply this email
> with your Linux distro's version.
>
> If you do not have problem, you can reply if you like.
>
> - Thanks,
> - Qian
>
> On 6/17/22 20:46, Qian Yun wrote:
> > And we do not propagate CFLAGS properly, so we can not
> > use "make CFLAGS=-D_FORTIFY_SOURCE=1" to slip in this
> > workaround.
> >
> > - Qian
> >
> > On 6/13/22 23:03, Qian Yun wrote:
> >> Hi Waldek,
> >>
> >> The original problem still exists:
> >>
> >> I can still get
> >>  "*** buffer overflow detected ***: terminated"
> >> when PID goes over 1 million.
> >>
> >> That's because on my system GCC has auto hardening feature.
> >> (This feature should be popular on other distros as well.)
> >> To be precise, GCC automatically compiles with
> >> "-D_FORTIFY_SOURCE=2".  This is adding runtime checks
> >> that gives this particular error.
> >>
> >> Turning it down to "-D_FORTIFY_SOURCE=1" can prevent
> >> this problem.
> >>
> >> However, I still think using "0-9a-z" to encode socket
> >> address is a better solution.
> >>
> >> - Qian
> >>
> >> On 9/9/20 18:30, 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.
>
> --
> 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/c7fcd63a-e746-bbf0-3a4a-160efe4dc485%40gmail.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/CAC6x94QGqVdu4H%2BTMexbHUGZ9eGspx-mkU831O8x4HB1CyTRyQ%40mail.gmail.com.

Re: [fricas-devel] FriCAS + jFriCAS

[Bill Page]

On Mon, 2 May 2022 at 15:28, Ralf Hemmecke  wrote:
>
> Hi Bill,
>
> thank you for your feedback.
>
> On 02.05.22 18:55, Bill Page wrote:
> > Ralf,
> >
> > Thanks for this. I tried your installation procedure on my "Linux Mint
> > 19.3 Tricia base: Ubuntu 18.04 bionic"  system and everything seemed
> > to work fine except the installation of JupyText.
> >
> > After performing the steps in
> >* (optional) Install JupyText
> > when I run
> >jfricas $FDIR/foo.input
> > or even just
> >jfricas
> > I get the error message:
> > [C 12:38:09.008 NotebookApp] Bad config encountered during initialization:
> > [C 12:38:09.008 NotebookApp] The 'contents_manager_class' trait of
> >  instance
> > must be a type, but 'jupytext.TextFileContentsManager' could not be
> > imported
> >
> > When I checked the config file:
> >xed $HOME/.jupyter/jupyter_notebook_config.py
> > I noticed that the installation command
> > --
> > 3. Make Jupytext available.
> >
> > sed -i 's|^# *c.NotebookApp.contents_manager_class
> > =.*|c.NotebookApp.contents_manager_class =
> > "jupytext.TextFileContentsManager"|;s|^#
> > *c.NotebookApp.use_redirect_file = .*|c.NotebookApp.use_redirect_file
> > = False|' $HOME/.jupyter/jupyter_notebook_config.py
> > --
> > failed to add the line
> >c.NotebookApp.use_redirect_file = False
> > presumably because the file did not previously contain any line like
> ># *c.NotebookApp.use_redirect_file = .*
>
> Oh... in your case jupyter_notebook_config.py was probably existing.

I do not know. I did not check first. Instead I just ran
  jupyter notebook --generate-config
It did not prompt for Overwrite [y/N]. But I just re-ran this and I
now get a prompt so maybe it did not exist before.

wspage@desktop:~$ FDIR=$HOME/fricas
wspage@desktop:~$ source $FDIR/venv/jfricas/bin/activate
(jfricas) wspage@desktop:~$ jupyter notebook --generate-config
Overwrite /home/wspage/.jupyter/jupyter_notebook_config.py with
default config? [y/N]y
Writing default config to: /home/wspage/.jupyter/jupyter_notebook_config.py
(jfricas) wspage@desktop:~$

After re-creating the config file I tried running

(jfricas) wspage@desktop:~$ jfricas $FDIR/foo.input
[I 15:39:56.185 NotebookApp] Serving notebooks from local directory:
/home/wspage/fricas
[I 15:39:56.185 NotebookApp] 0 active kernels
[I 15:39:56.185 NotebookApp] The Jupyter Notebook is running at:
[I 15:39:56.185 NotebookApp]
http://localhost:/?token=c5c300794e7855ba2e9e1d32a372041518f27089419dcef2
[I 15:39:56.185 NotebookApp] Use Control-C to stop this server and
shut down all kernels (twice to skip confirmation).
[C 15:39:56.186 NotebookApp]

Copy/paste this URL into your browser when you connect for the first time,
to login with a token:

http://localhost:/?token=c5c300794e7855ba2e9e1d32a372041518f27089419dcef2
Opening in existing browser session.
[I 15:39:56.407 NotebookApp] Accepting one-time-token-authenticated
connection from 127.0.0.1
[I 15:39:56.409 NotebookApp] 302 GET
/notebooks/foo.input?token=8e615b4584b8a40575df4f1e176fd07aec2bb0759a9678d1
(127.0.0.1) 2.81ms
[1923:1923:0100/00.497003:ERROR:sandbox_linux.cc(378)]
InitializeSandbox() called with multiple threads in process
gpu-process.
--

But nothing happens. I do not see anything in my browser. But I can
see that Jupyter is running if I enter
  http://localhost:/?token=c5c300794e7855ba2e9e1d32a372041518f27089419dcef2
in the browser. If I logout and then exit (control-C) the Jupyter
session in the terminal, then

The Jupyter Notebook is running at:
http://localhost:/?token=c5c300794e7855ba2e9e1d32a372041518f27089419dcef2
Shutdown this notebook server (y/[n])? y
[C 15:44:10.548 NotebookApp] Shutdown confirmed
[I 15:44:10.549 NotebookApp] Shutting down 0 kernels
(jfricas) wspage@desktop:~$ jfricas
[I 15:44:31.826 NotebookApp] Serving notebooks from local directory:
/home/wspage
[I 15:44:31.826 NotebookApp] 0 active kernels
[I 15:44:31.826 NotebookApp] The Jupyter Notebook is running at:
[I 15:44:31.826 NotebookApp]
http://localhost:/?token=ae4481782fec549879e4ac2ed811328753aa618b148768dc
[I 15:44:31.826 NotebookApp] Use Control-C to stop this server and
shut down all kernels (twice to skip confirmation).
[C 15:44:31.827 NotebookApp]

Copy/paste this URL into your browser when you connect for the first time,
to login with a token:

http://localhost:/?token=ae4481782fec549879e4ac2ed811328753aa618b148768dc
[I 15:44:32.036 NotebookApp] Accepting one-time-token-authenticated
connection from 127.0.0.1
Opening in existing browser session.
[2284:2284:0502/154432.061548:ERROR:broker_posix.cc(43)] Invalid node
channel message
[2279:2279:0100/00.128409:ERROR:sandbox_linux.cc(378)]
InitializeSandbox()

Re: [fricas-devel] FriCAS + jFriCAS

[Bill Page]

Ralf,

Thanks for this. I tried your installation procedure on my "Linux Mint
19.3 Tricia base: Ubuntu 18.04 bionic"  system and everything seemed
to work fine except the installation of JupyText.

After performing the steps in
  * (optional) Install JupyText
when I run
  jfricas $FDIR/foo.input
or even just
  jfricas
I get the error message:
[C 12:38:09.008 NotebookApp] Bad config encountered during initialization:
[C 12:38:09.008 NotebookApp] The 'contents_manager_class' trait of
 instance
must be a type, but 'jupytext.TextFileContentsManager' could not be
imported

When I checked the config file:
  xed $HOME/.jupyter/jupyter_notebook_config.py
I noticed that the installation command
--
3. Make Jupytext available.

sed -i 's|^# *c.NotebookApp.contents_manager_class
=.*|c.NotebookApp.contents_manager_class =
"jupytext.TextFileContentsManager"|;s|^#
*c.NotebookApp.use_redirect_file = .*|c.NotebookApp.use_redirect_file
= False|' $HOME/.jupyter/jupyter_notebook_config.py
--
failed to add the line
  c.NotebookApp.use_redirect_file = False
presumably because the file did not previously contain any line like
  # *c.NotebookApp.use_redirect_file = .*

Adding the line manually did not help.

In any case I guess jupyter is really complaining about
"jupytext.TextFileContentsManager". Commenting this line out allows
jfricas to start again but obviously
  jfricas $FDIR/foo.input
still does not work.

Regards,
Bill.

On Sun, 1 May 2022 at 16:22, Ralf Hemmecke  wrote:
>
> Hello,
>
> unfortunately there were some issues at
> https://github.com/fricas/jfricas/issues
> claiming that jfricas didn't work although it worked perfectly for myself.
>
> Kurt figured out that there were compatibility problems with the
> webserver hunchentoot (that was loaded when jfricas started) and the
> SBCL version on which the current 1,3,7 release is based on.
>
> After quite some discussion and many wasted hours in finding a simple
> way for a user to make jFriCAS work, I decided that the simplest method
> is to put hunchentoot into the FRICASsys image and distribute it
> together with FriCAS. The main goal was to make it simple for a user.
>
> I have now compiled a binary FriCAS distribution that includes
> hunchentoot and that works together with jfricas (no no -- not from PyPI).
>
> I would like to ask the community to give feedback to
>
> http://hemmecke.org/fricas/dist/1.3.7/
>
> any (un)successful feedback is welcome.
>
> Ralf (with quite a lot of help from Kurt and 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/8e7a57bb-42d4-3ab8-ccd4-8b03eca37090%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/CAC6x94Ro0ijJYPUPuZYdp8emX1VTyb-%3Dd1UM%2BXafFHcve-7tmA%40mail.gmail.com.

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

[Bill Page]

I haven't done this is a long time but you could try sending an email like this:
---
To: 
Subject: subscribe
subscribe
---

On Mon, 25 Apr 2022 at 20:48, 'Nasser M. Abbasi' via FriCAS - computer
algebra system  wrote:
>
> May be someone can explain how to subscribe to 
> https://groups.google.com/g/fricas-devel  via email, or by using 
> nntp.aioe.org?  Since Fricas does NOT show up as newsgroup on  nntp.aioe.org. 
>  I have to login to google each time to post here.  (but had to create a 
> google account to do this).
>
> But for say sci.math.symbolic, I can access it from 
> news://nntp.aioe.org:119/sci.math.symbolic  via my email reader (thunderbird) 
> via nntp.aioe.org and hence I do not need to login to google to read and 
> write to  sci.math.symbolic new group. It will be nice to do the same here.
>
> May be someone can explain, easy to follow step by step, how one can read and 
> write here without having to login to google first?
>
> On Monday, April 25, 2022 at 7:15:06 PM UTC-5 oldk1331 wrote:
>>>
>>>
>>> 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/d67b42bd-612e-4645-875f-888a5d7d9ed4n%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/CAC6x94Q9WMCRo096vg4UJ7UQeux%2B%2BV0_wjEetFyHP6-Tbpa1fg%40mail.gmail.com.

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

[Bill Page]

On Sun, 24 Apr 2022 at 23:48, Qian Yun  wrote:
>
> Hello everyone on fricas-devel:
>
> You may have noticed that Waldek has not posted on fricas-devel
> for a while now.  He has replied to GitHub issues in the mean
> time however.
>
> So I asked him privately via email, and he replied that he can't
> reply/receive to fricas-devel, because Google wants cell number.
>

This seems extremely odd to me. Perhaps there is just some confusion
on how to use Google Groups. I never (well, almost never) use Google
Groups directly. All postings on the FriCAS group are sent to me by
simple email (such as this one) and my replies (such as this one) are
sent to the FriCAS group as an email. I have used the FriCAS group
this way since the beginning. So I am seriously confused if someone
claims "Google wants cell number". I never gave Google my cell number.
So far as I know this isn't even necessary if you actually have a
gmail account. Rather, it is perhaps an option in this case if you
want to use 2-factor authentication.

> And with his permission, I'm asking community members for opinions
> that which tool share we use instead.
>

Although of course I want Waldek to participate in the FriCAS group
but it seems strange to me if Waldek is the only user experiencing
this problem. Perhaps it can be resolved just by accessing the group
in a different way, i.e. by email.

> To quote Waldek's opinion:
>
>  > ATM I am not sure what is better.  One possiblity is to
>  > set up our own mail server.  I could do this on the
>  > same machine as wiki.  Of course we could use GitHub
>  > mail.  However, it is not clear what folks on the list
>  > want.  For me old plain e-mail is preferable and also
>  > I would like sensible publicaly visible archive.
>
> Personally I prefer GitHub.  Waldek replies with:
>
>  > Well, GitHub web interface mangles code which is IMO serious problem.
>  > That is why I wrote "sensible publicaly visible archive", AFAICS
>  > GitHub does not qualify as "sensible" here.
>
> But I think GitHub uses markdown, and  code block should solve it.
>

GitHub would be fine with me if this is really necessary. But I think
it is also very common to use GitHub with the 2-factor authentication
option (at least I do) in which case a cell phone will usually also be
involved.

> So, members of fricas community, let your opinions be heard,
> and hopefully a satisfying decision will be made based on that.
>

Thank you for your effort to resolve the problem!

> - 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/25f37615-32ea-1ca5-5204-83a81ee3e0b2%40gmail.com.

You can notice above the postscript that Google Groups adds when
sending group postings by email. I never use the link to "view this
discussion on the web".

Regards,
Bill Page.

-- 
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/CAC6x94RPA%2BB9ML_SWCt6gtyDrw0HAi0rnEp-fVqTbkhrj1QaZg%40mail.gmail.com.

Re: [fricas-devel] solve.particular

[Bill Page]

Do not use _ at the end of the first line.

fsol(a: List LZ, b: LZ): LZ ==
  x := solve(a :: SquareMatrix(3, F), b :: VF).particular
  if x case VF then x :: LZ else [0,0,0] :: LZ

On Wed, Dec 1, 2021 at 2:25 PM Sid Andal  wrote:

>
> The following file contains:
>
>  mysolv.input 
>
> F := PF 13
>
> VF ==> Vector F
> LZ ==> List Integer
>
> fsol(a: List LZ, b: LZ): LZ ==_
>   x := solve(a :: SquareMatrix(3, F), b :: VF).particular
>   if x case VF then x :: LZ else [0,0,0] :: LZ
>
>  End of mysolv.input
>
>
> The following run outputs an error:
>
>
> (1) -> )r mysolv
> F := PF 13
>
>
>(1)  PrimeField(13)
>
> VF ==> Vector F
>
> LZ ==> List Integer
>
>
> fsol(a: List LZ, b: LZ): LZ ==_
>   x := solve(a :: SquareMatrix(3, F), b :: VF).particular
>   if x case VF then x :: LZ else [0,0,0] :: LZ
>
>Function declaration fsol : (List(List(Integer)), List(Integer)) ->
>   List(Integer) has been added to workspace.
> (5) ->
> (5) -> fsol([[1,2,3],[5,7,9],[11,2,8]],[4,0,3])
>
>case is only used for Unions and the object on the left-hand side
>   does not belong to a union.
>
> (5) ->
>
>
> Isn't solve.particular of Union type?
>
> --
> 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/6a2be781-10a4-42a3-a13e-11d0f72071c7n%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/CAC6x94TDLAWLW4RjFjZ4c9Mm3rLAvYkoy8hno8mSEcUF2%3DRcDA%40mail.gmail.com.

Re: [fricas-devel] output file type....

[Bill Page]

On Thu, Nov 25, 2021 at 12:14 PM Sid Andal  wrote:

> The question was very clear and self explanatoryI asked how to output
> a string into a file without the leading "1." and without the double quotes.
>

(1) -> )sys cat test.input
f : TextFile := open("test.out", "output")
writeLine!(f, unparse([1,2,3,4,5,6,7,8]::InputForm))
writeLine!(f, "0123456789")
close!(f)
(1) -> )r test
f : TextFile := open("test.out", "output")


   (1)  "test.out"
   Type:
TextFile
writeLine!(f, unparse([1,2,3,4,5,6,7,8]::InputForm))


   (2)  "[1,2,3,4,5,6,7,8]"
 Type:
String
writeLine!(f, "0123456789")


   (3)  "0123456789"
 Type:
String
close!(f)


   (4)  "test.out"
   Type:
TextFile
(5) -> )sys cat test.out
[1,2,3,4,5,6,7,8]
0123456789
(5) ->

-- 
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/CAC6x94RVg9uAnQL5dGbrWZks%3Dgcuwa-dQHCjpH%2BatHdoEMhH8A%40mail.gmail.com.

[fricas-devel] Fwd: Cron /home/page/spin

[Bill Page]

Hello Waldek,

For several days now I have been receiving error message emails such
as the following.  This seems to be caused by some configuration error
on the fricas-wiki website: fricas.math.uni.wroc.pl.  The server
should no longer be referring to "newsynthesis.org". Could you please
correct the problem?

Thanks.

Bill Page.

PS. I am sorry to send this to the email list but several earlier
messages sent to Waldek's personal email address have so far gone
unanswered.

-- Forwarded message -
From: Cron Daemon 
Date: Mon, Oct 18, 2021 at 9:19 PM
Subject: Cron  /home/page/spin
To: 


/bin/sh: /home/page/spin: not found

---

Delivered-To: bill.p...@newsynthesis.org
Received: by 2002:a05:6520:4388:b0:14a:738c:d4ba with SMTP id ed8csp60286lkb;
Mon, 18 Oct 2021 18:19:15 -0700 (PDT)
X-Google-Smtp-Source:
ABdhPJxNH3DqwDFBlCAiMIHLv7TLnGBxyMBWJLWdxWWU5AkBnzQp91Ed8LRgyP1W7dtyjLlZscND
X-Received: by 2002:a2e:b054:: with SMTP id d20mr3347025ljl.507.1634606355222;
Mon, 18 Oct 2021 18:19:15 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1634606355; cv=pass;
d=google.com; s=arc-20160816;
b=XSXj5N8T/zl+xxkKqNflAH2a+i90XAJIE0fIQqV/dm83QMdLZ5a0ac6/D3KlFZh4z6
 HCzv5IaUQX0Khwo26V98s/zlRCytBqUpMMM/SqaGtekRcB7PpuHFlRxPTRmM4gwS97Iq
 CbjgsD8Ds4dKihwt0zegZKh70MuzwFG0zBk68RuojGo2RzLwH9FFtlw1XRv2V8y7OPYD
 StYTQ3BKJY4CM8fEw2lywdkt8RWBhIujvEQNlYYk8RrAc3uBkHgbkveylEabPXZsh02A
 K0DGlDw+ANlMtoyNZHVYqCEA2NjkWe5/VS52u0OvOz/LuyoNn4GVTMto+crwtNbobIPr
 mqCg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=arc-20160816;
h=delivered-to:message-id:date:subject:to:from;
bh=c3/Y96Yk1PMssJ4Ch/8mEgyWerhSBGAi91s9Al4TDpw=;
b=dIKVgaTo/PjuzaMJ7cM+zHm5g6QQYkqXUIeiKHGzt6tQg7oFXU+a0+QcSIUzx05P/T
 glH1sX4RqrN8x7YSqTUjV8KA/gZAobe8NTCgBzEsYjj/Jl2jS+0d2yDu42Kmcq43mrF2
 BfPz215/DvTCzZgHSCnmniwnqruutMnVNYE+dzggZz4Wi7c6m2BveI1oytDImL7JweDk
 QHVtpn/sKAmuawen4aTFS0huZeEnYEU9oJifP7kqH5NodoeZYQChK/qybp9pLK03MieQ
 pP7KWuKgO5M9IH8h5du5lqkpU+gZ+3uYCMYk1mqUlBzXbDEHv/leWiUbRr8NxyA6XWHb
 ELxA==
ARC-Authentication-Results: i=2; mx.google.com;
   arc=pass (i=1);
   spf=neutral (google.com: 209.85.208.200 is neither permitted
nor denied by best guess record for domain of r...@newsynthesis.org)
smtp.mailfrom=r...@newsynthesis.org
Return-Path: 
Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com.
[209.85.208.200])
by mx.google.com with ESMTPS id m16si27190057lfg.537.2021.10.18.18.19.14
for 
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Mon, 18 Oct 2021 18:19:15 -0700 (PDT)
Received-SPF: neutral (google.com: 209.85.208.200 is neither permitted
nor denied by best guess record for domain of r...@newsynthesis.org)
client-ip=209.85.208.200;
Authentication-Results: mx.google.com;
   arc=pass (i=1);
   spf=neutral (google.com: 209.85.208.200 is neither permitted
nor denied by best guess record for domain of r...@newsynthesis.org)
smtp.mailfrom=r...@newsynthesis.org
Received: by mail-lj1-f200.google.com with SMTP id
k12-20020a2ea26c00b00210f22d4769so324051ljm.4
for ; Mon, 18 Oct 2021 18:19:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-original-authentication-results:x-gm-message-state:from:to
 :subject:date:message-id:delivered-to;
bh=c3/Y96Yk1PMssJ4Ch/8mEgyWerhSBGAi91s9Al4TDpw=;
b=WVW2mR0ox5/750/0eNdEiesbEx0O/0XQ03AQu2cX/QtzKimCImzPQnNkpdMKtTOjv5
 9TVibk8UwyZZl7EOiTO792LiqPzLc0ZKz+/B5iRk6xjYapDTV1gLkQ8NNcEGYLlzrtav
 3u6klsK6PaUJq/sFJIQ6lDyk7FSndP9N8v1dHYixWP6Oe0ZOe6rXem/RWh7iQHrciDP/
 +Wdh79wB2/SjPDMnm1uU6LlqQAmIAO1trqgLq4n87l7xO2lqvWBxAt/B//G7+IuR1729
 wVFIQh2DG+BeuIWaU2Ef9sBhVYo/TFbOvjdlB9fEcOj6MyK9pnZbzjstrhZxaEJ+8PKP
 klnw==
X-Original-Authentication-Results: mx.google.com;
   spf=neutral (google.com: 156.17.86.1 is neither permitted nor
denied by best guess record for domain of r...@newsynthesis.org)
smtp.mailfrom=r...@newsynthesis.org
X-Gm-Message-State:
AOAM532oozseGMdoNc5zFMgjmcmRLrdB45Xl3/uOwWu0FTwrPvnpJFki
Gd7MBI0GR2fwM2hh+KBuRX4qNvHBwFbSuBAa+dyQpTFctk3zovXzm6NntcG2WBdv5DQnzetlUfw
hRa4E7Jb60Us/G5Tie2JtnmjmZdCPgX2QpxJWeiT/VUwq8l7Oen3U
X-Received: by 2002:a05:6512:30f:: with SMTP id
t15mr3096182lfp.64.1634606354571;
Mon, 18 Oct 2021 18:19:14 -0700 (PDT)
X-Received: by 2002:a05:6512:30f:: with SMTP id
t15mr3096164lfp.64.1634606354273;
Mon, 18 Oct 2021 18:19:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1634606354; cv=none;
d=google.com; s=arc-20160816;
b=b/luXN4iBauptIej+l/3IpHNaD/O/G1NpEDkeYOzzQ9ki6HRl+e1dgb0qn2YzC7zzi
 hEE8ersqzG7LNRbgUSjU/09pptoVZhq3f6hSoB4VuSTmlHemyffUmm9qsJoImkD5HuJY
 mA46WT0c20tFuZzq6BG/MSSmTQAH0MHqnvzjanFk3hAtW9TzqVQM1r3CpBj2LesgAREV
 Afm+7B7wc

Re: [fricas-devel] Simplest way to create Symbols in Spad?

[Bill Page]

You might find the following useful:

(1) -> name(xx)

   (1)  xx
 Type:
Symbol
(2) -> new()

   (2)  %A
 Type:
Symbol
(3) -> new()

   (3)  %B
 Type:
Symbol


On Thu, Aug 5, 2021 at 7:15 AM Waldek Hebisch 
wrote:

> On Thu, Aug 05, 2021 at 10:18:43AM +, Neven Sajko wrote:
> > Hello,
> >
> > I know that I can create a Symbol like so:
> > "n"::Symbol
> >
> > But is there a simpler way, like there is for strings (just "n", with
> > the double quotes).
>
> In Spad just use 'x, that is single quote before x.  In interpreter
> I am affraid that you must use coercion...
>
> --
>   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/20210805111507.GB10149%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/CAC6x94Qz45QiyyvYdy9RaYEcODNgjCCHH51Dp5D24aaMedK3Hg%40mail.gmail.com.

Re: [fricas-devel] Troubles with kernels

[Bill Page]

Waldek wrote:

> It still uses order to find positions in kernel cache.

Although order is at least to some extent arbitrary, it is still
necessary for the ordering to be consistent during a session to
satisfy category 'Comparable'.

On Thu, Aug 26, 2021 at 5:22 AM Qian Yun  wrote:
>
> Most time spent on Kernel should be in "linearSearch".
> And since Kernel doesn't have order, I wonder if it is possible to
> using some kind of hashtable to store all cached kernels.

Of course hash and order are not compatible but it might be possible
to maintain a duplicate cache.

-- 
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/CAC6x94SOm_TzE5VnmfaiHgG37YMQHrH8D_m3myw2wz%2BbjAux7w%40mail.gmail.com.

Re: [fricas-devel] latex symbols in fmtmathjax

[Bill Page]

On Mon, May 3, 2021 at 1:19 PM Kurt Pagani  wrote:
>
> On 03.05.2021 18:09, Bill Page wrote:
> > If it is necessary to consider alternatives, then I think one other approach
> > would be to export a function that sets a "presentation" property on a 
> > Symbol
> > and then make use of that property (if it exists) and if the flag is set in
> > FormatMathJax. The benefit then might be that a formatter would have a 
> > choice as
> > to whether to use the presentation property string or not.
>
> Do you think of something like setProperty/display in BOP?
> https://fricas.github.io/api/BasicOperator.html

Yes, but probably a new property just to specify an alternate
presentation for a particular symbol. Perhaps there could be several
such alternatives of interest to different formatters. But if no
relevant property exists or if for some reason it might be undesirable
in a certain context then the fall back would be to just treat it the
way it is done now.

Of course more sophisticated things are possible. For example it might
be nice to have some way to pass (sub/super/...)-scripts to the
frontend formatter for substitution into a LaTeX snippet, i.e. like
arguments to a macro.

> Or have I completely misread your suggestion?
>
> I've been using the those methods for some time, e.g.
> f:=operator 'f
> display(f,o+->F)
> f [x,y,z] -> F
> properties f -> table(%display = NONE)
>
> in order to suppress the arguments (enhancing readibility of large formulas),
> however, it's not exatly brilliant :( - you'll notice that as soon as you need
> derivatives.
>

This sounds like another very good idea that should be polished up a
little and included in FriCAS.

> @Waldek
> > it is not something
> > localized but in principle has very wide scope.
>
> Admitted, however, what's wrong with this? It concerns MathJax only, and a
> sin(a) remains as is unless you define another representation for "a" - 
> strictly
> speaking, it's more like a substitution.
>

I can see that the current proposal might be undesirable if the same
worksheet is to be presented in another format, e.g. a worksheet
prepared in jfricas but later you want to use it in TeXmacs.

-- 
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/CAC6x94Qh7TU7Spkyef5tv0LKDfdOgtj06d%3Dm%3D%3DYWgZ-2ETUyqw%40mail.gmail.com.

Re: [fricas-devel] latex symbols in fmtmathjax

[Bill Page]

If it is necessary to consider alternatives, then I think one other
approach would be to export a function that sets a "presentation" property
on a Symbol and then make use of that property (if it exists) and if the
flag is set in FormatMathJax. The benefit then might be that a formatter
would have a choice as to whether to use the presentation property string
or not.

On Sun, May 2, 2021 at 3:02 PM Waldek Hebisch 
wrote:

> On Sun, May 02, 2021 at 11:29:44AM -0400, Bill Page wrote:
> > Ralf's proposed patch for FormatMathJax allows much more than just
> support
> > of Unicode-like symbols. There are many cases when one might want to use
> a
> > small but otherwise arbitrary LaTeX fragment as a more sophisticated way
> to
> > represent some symbol.
>
> That part of reason why I view it as problematic: it is not something
> localized but in principle has very wide scope.
> --
>   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/20210502190206.GA32321%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/CAC6x94TT56jftJRj-9Tc0Cn_tut9LYyTVUYiektzTxv8nQnJTA%40mail.gmail.com.

Re: [fricas-devel] latex symbols in fmtmathjax

[Bill Page]

Ralf's proposed patch for FormatMathJax allows much more than just support
of Unicode-like symbols. There are many cases when one might want to use a
small but otherwise arbitrary LaTeX fragment as a more sophisticated way to
represent some symbol.

On Sun, May 2, 2021 at 10:00 AM Ralf Hemmecke  wrote:

> Waldek,
>
> Your message was not clear whether or not you want me to commit this to
> FriCAS.
>
> On 02.05.21 04:22, Waldek Hebisch wrote:
> > That breaks normal rules:
>
> Sorry, I haven't seen any documented rules about this.
>
> > OutputForm is supposed to give equivalent
> > output for all formatters.
>
> You've just made this up, right? What is the definition of "equivalent"?
> Is 훿 and \delta equivalent?
>
> > This proposal would create "LaTeX only"
> > OutputForm, which is quite undesirable.
>
> Wrong. It never touches anything in OutputForm, only in FormatMathJax.
> And most importantly it doesn't break anything since a user must switch
> this feature on to work.
>
> > Ideally, we would have single set of rules working for everywone.
>
> Ideally Unicode was invented 100 years ago and OutputForm would not have
> been primarily written to deal with the output of 2D-ASCII math.
>
> > ATM it seems that we need some compromises to provide desired
> > features.
>
> Yes, that is why I wrote this extension.
>
> > However, this "direct LaTeX" way seem much less clean
> > than say recoding Greek letters as LaTeX escapes.  To say the
> > truth, in longer run teaching LaTeX to correctly handle Greek
> > letters seem more desirable.  In my case the following seem
> > to work:
> >
> > \usepackage[utf8x]{inputenc}
> > \def\textalpha{\alpha}
>
> Of course, the usual "works for me" is not convincing.
>
> I took some characters from
> https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode
>
> Works fine in FriCAS
>
> (1) -> delta := "훿"::Symbol; NN := "퓝"::Symbol; DD:="픻"::Symbol;Symbol;
> Type: Symbol
> (2) -> sin(DD+delta+NN)
>
>(2)  sin(훿 + 픻 + 퓝)
> Type: Expression(Integer)
>
> and works perfectly in jFriCAS.
> When I copy the output form the Jupyter notebook, it gives me
>
> \sin\left(훿+픻+퓝\right)
>
> which is fine for lualatex, but not for pdflatex neither with utf8 nor
> utf8x. See attached LaTeX file.
>
> pdflatex -interaction=nonstopmode foo.tex
>
> The utf8x package builds on the ucs package and a quick search reveals
> that this is incompatible with biblatex.
> Search ucs in the documentation of https://www.ctan.org/pkg/biblatex .)
> I wouldn't want to sacrifice biblatex just for having a delta in FriCAS
> output.
>
> As you can see in the attachement your
> \def\textdelta{\delta}
> only helps partially.
>
> I don't know why it would be such a bad idea to make the life of our
> users easy.
> Furthermore, I am happy to remove that stuff from FormatMathJax, if we
> enter an ideal world and everyone is using a unicode-aware LaTeX.
>
> 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/daeb853d-5874-03e2-d2b7-17e5c1e9418b%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/CAC6x94QpFrbjC%3DGfSrZvPEwg1Awi2%2BnA0awktz9wSqAAUeT-PA%40mail.gmail.com.

Re: [fricas-devel] latex symbols in fmtmathjax

[Bill Page]

On Sat, May 1, 2021 at 8:29 AM Ralf Hemmecke  wrote:

> ...
> After this patch a symbol name that starts with \ is directly handed to
> the output unaltered so that it can be interpreted by MathJax.
>
>
+1


> Comments are welcome.
>
> If I do not hear something, I will commit it next Tuesday.
>
>
> https://github.com/hemmecke/fricas/commit/a584d857a623be6be35bd5641cc1a584b22adcad
>
> 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/CAC6x94RCsCO5GUHCo4k54RV_whBk4fY-8RZ54-gkp8MCQT9r8w%40mail.gmail.com.

Re: [fricas-devel] INSTALL

[Bill Page]

On Mon, Apr 19, 2021 at 3:26 PM Waldek Hebisch  wrote:
>
> On Mon, Apr 19, 2021 at 08:33:02AM +0200, Ralf Hemmecke wrote:
> > ...
> > I definitely want install.rst on the web and showing a plain text file
> > on an otherwise sphinx-generated site would look very unprofessional.
>
> .rst pretending to be plain text is at least as unprofessional.
>

-1

I disagree. Reading .rst in a text editor looks much better to me than
most people's "plain text" and of course it looks even better on a web
site or in a pdf document.

-- 
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/CAC6x94TiS%2B1vyh0d_NvLj9jDOv7OUo6c6vWx39VPC-N-RkEy2A%40mail.gmail.com.

Re: [fricas-devel] Re: HyperDoc and API

[Bill Page]

On Tue, Mar 23, 2021 at 2:01 PM Ralf Hemmecke  wrote:
>
> > Now, if we could only include the Jupyter interface in the
> > FriCAS distribution
>
> Well, yes, but, although I would like to see this offered, doing it
> the pip way or via installation from the github repo, is easy
> enough for early adopters to install the jfricas jupyter kernel.
>

Well yes easy but ... First, doing it this way makes it almost
invisible except if we actually start actively discussing it here.
Second, as I recall (correct me if I am wrong) this means that a
specific binary SBCL-based version of FriCAS is installed with a
Lisp-level library for Jupyter kernel support.  In order to add it to
the FriCAS distribution I presume that this would have to be extended
to support a wider range of Lisps and hopefully packaged in a way that
at least the interface part was distributed with FriCAS. Of course
Jupyter itself would have to be loaded in whatever way was standard
for the Jupyter user and then the kernel from the FriCAS distribution
appropriately installed. This would be closer to the way that we
support TeXmacs.

> I must admit that I would like some people to work with it, but
> to propose it for everyday use, it is maybe a bit early. I see in
> particular problems when using mathjax with big output. Sure
> one can always switch to ordinary algebra output, but mathjax
> looks better. Unfortunately, mathjax takes quite some time to
> render.
>

How easy would it be to try KaTeX? https://katex.org/ Maybe someone
has already tried this?

> > and decide on a way to render graphics (See previous discussion
> > with Kurt.) then we would have a viable web-based user interface
> > for FriCAS.
>
> I hope that some day Kurt has enough time to come up with a new
> graphics framework that even works in jupyter.
>

It seems to me that Kurt has already experimented with several options
and that his opinion was that we should just pick one of these and run
with it.

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAC6x94S7gyQ%3DnkyFYgt9-8bYkYCupbW3vV9OW3Q-EngOH3MGTQ%40mail.gmail.com.

Re: [fricas-devel] Re: HyperDoc and API

[Bill Page]

On Tue, Mar 23, 2021 at 3:57 AM Ralf Hemmecke  wrote:
>
> On 23.03.21 02:31, Bill Page wrote:
> > So now I have a link on my desktop that starts a local copy of the
> > api. Great.
>
> Great. It look as if I got a first user for this feature. ;-)
> Thanks for taking the pain to go through the compilation.
>

Now, if we could only include the Jupyter interface in the FriCAS
distribution and decide on a way to render graphics (See previous
discussion with Kurt.) then we would have a viable web-based user
interface for FriCAS.

-- 
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/CAC6x94Q-bBHeyuD2V5b-AeuFM6Ob1gGjkgK7fXx2V%3D795GhLug%40mail.gmail.com.

[fricas-devel] Re: HyperDoc and API

[Bill Page]

OK, after enabling postscript generation in ImageMagick, loading some
missing TeXLive packages and installing Sphinx 'make localdoc'
succeeded. I am able to access the result from

$ firefox file:///home/wspage/fricas-build/src/doc/html/index.html

So now I have a link on my desktop that starts a local copy of the api. Great.

Now, to answer an earlier question: Apparently search is supported
through some local javascript. As a result what I have seems to look
and work exactly the same way as the online version. And I am able to
access my locally stored source code. So all is good so far.

Thanks.

-- 
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/CAC6x94Q0McbMAHvSiTyM_kX%3DRGdFHYjsnyYJXKLp%2BgtB-ez3Cg%40mail.gmail.com.

[fricas-devel] Re: HyperDoc and API

[Bill Page]

On Mon, Mar 22, 2021 at 9:59 AM Bill Page  wrote:
> ...
> I will attempt to build the api locally and let you know what I find.
>
> Thanks.

On Mar 19, 2021, 6:01 PM Ralf Hemmecke wrote:

> Bill Page wrote:
> > HyperDoc: almost every time I use FriCAS. I do often wish
> > that the HyperDoc interface looked more up to date. On the
> > other hand I do not much like to have to work online with
> > http://fricas.github.io Maybe I would use it more if it was
> > bundled into the FriCAS distribution somehow.

> Bundled with the distribution, I cannot promise. But what I can
> say is that when you compile FriCAS and say
>
> cd /path/to/build-dir/src/doc
> make localdoc
>
> it will produce that what is on fricas.github.io on your local
> machine. (even the book). And the links there are such that
> you (almost) never need the web.
>
> See
> https://github.com/fricas/fricas/blob/master/src/doc/Makefile.in#L75

My first observation is that on my system (Linux Mint 19.2) 'make
localdoc' almost immediately returns a security error:
...
cp /home/wspage/fricas-master/src/doc/ps/h-matxref.ps h-matxref.ps
cp /home/wspage/fricas-master/src/doc/ps/h-root.ps h-root.ps
make -f pics.mk pics
make[2]: Entering directory '/home/wspage/fricas-build/src/doc'
convert ugNewIntroGraphicsPage1.VIEW/image.xpm bessintr.ps
convert-im6.q16hdri: not authorized `bessintr.ps' @
error/constitute.c/WriteImage/1037.
pics.mk:3: recipe for target 'bessintr.ps' failed
...

This is due to an apparently well known change to ImageMagick to
prevent creation of postscript files and some other things by default.
Do you know if there is an alternative to 'convert' for this
conversion that would avoid having to change the security options?

See for example:
https://askubuntu.com/questions/1127260/imagemagick-convert-not-allowed

-- 
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/CAC6x94S3Et_GXq0MEh9hE6hO1m_2qUxZHM8LjrJEiLEcWmMrnQ%40mail.gmail.com.

[fricas-devel] Re: HyperDoc and API

[Bill Page]

On Sun, Mar 21, 2021 at 10:29 AM Ralf Hemmecke  wrote:
>
> On 21.03.21 15:00, Bill Page wrote:
> > On Sun, Mar 21, 2021 at 8:25 AM Ralf Hemmecke 
> > wrote:
> >> ... The only thing (in my eyes) that HyperDoc can do and
> >> http://fricas.github.io/api does not provide, is showing
> >> "which domain/package/category implements a certain
> >> function".
> >
> > Yes, exactly. HyperDoc allows "easy" navigation in the rather
> > complex lattice of categories, domains and functions of the
> > FriCAS library.
>
> May I ask what you mean by this. Suppose you have
> http://fricas.github.io/api locally on your computer.
> What would you miss?
>

Admittedly, my resistance is largely due to a lack of familiarity. By
default HyperDoc starts automatically when you start FriCAS so it
seems like part of FriCAS.  http://fricas.github.io/api on the other
hand is an external program.  Maybe an option like

  $ fricas -api

that automatically disabled HyperDoc and started a local copy of the
api would help.

Typically I would start with searching for a function or a domain. The
online search at http://fricas.github.io/api seems OK although I
probably not have used it enough yet to know if there are any
limitations. How is search provided if I have it locally on my
computer?

> And I would like to clarify. When I wrote about "which
> domain/package/category implementa certain function",
> I did not mean which domain *exports* this function, but
> rather what is the domain, that has the source code for
> the respective functionality. You know with inheritance
> from domains and category defaults, that can sometimes
> be hard to find out if you browse through the source files.
> I am not sure that you above mean the same.
>

Thank you for the clarification. Yes that is important.

> > The user interface level of HyperDoc could be entirely replaced
> > by a conventional browser but the navigation of the internal
> > FriCAS dynamic type database still requires some sort of
> > backend.
>
> Well, in fact, fricas.github.io/api tries to do exactly that, only
> that it is static. That is however not a very big problem. One
> can compile the API stuff of private .spad files in the same way
> and the hyperlinks would correctly point into the FriCAS API
> if they are not part of the new package/domain/categories.
>
> So what exactly would you miss?
>

I will attempt to build the api locally and let you know what I find.

Thanks.

-- 
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/CAC6x94S%2BKT8-EWriDXGUW9P2RsRgFoN5Rd-UtOVpEZZH8embLg%40mail.gmail.com.

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

[Bill Page]

On Sun, Mar 21, 2021 at 1:51 PM Ralf Hemmecke  wrote:

> ...
> We should rather say that it is OK to just fork FriCAS and try own
> ideas and come back and convince the main developers to include
> new (better) code if it is ready and removes some deficiencies of
> FriCAS.

I think this is an inadequate response for most potential developers.
Of course it is OK to fork - FriCAS is an open source project. But
this is like telling someone to "go away and not come back until you
have something more interesting to say ." Visibility _within_ the
project is important. There has to be some way to be more welcoming
and encourage "off-trunk" development - maybe the more frequent
creation of development branches within the FriCAS repository?

-- 
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/CAC6x94QF0Dtf%2B6r0k89e35Jx3bcG3Co-MbQ5n0hBhp41w0qeMg%40mail.gmail.com.

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

[Bill Page]

On Sun, Mar 21, 2021 at 8:25 AM Ralf Hemmecke  wrote:
> ...
> The only thing (in my eyes) that HyperDoc can do
> and http://fricas.github.io/api does not provide, is
> showing "which domain/package/category implements
> a certain function".

Yes, exactly. HyperDoc allows "easy" navigation in the rather complex
lattice of categories, domains and functions of the FriCAS library. I
find this a critically important feature of FriCAS. Without it I would
feel like I was lost, even though of course it is always possible to
"read the source code" and search through (often somewhat dubious)
documentation.

> Admittedly, that is a very useful feature, but that
> should/could rather be available from  the FriCAS
> command line.

I disagree strongly. Navigating the type hierarchy is something that
is ideal for a web browser-like interface. That is what HyperDoc
is/was all about. The word "hyper" is exactly from this early (1970's
?) vision of what web browsers would later become.

> I actually don't like to start an X programm
> (HyperDoc) only to find out about which domain
> implements some function.
>

That is exactly the reason why I use HyperDoc in almost every FriCAS session.

> If this feature is provided in another way, then we could
> slowly let HyperDoc rest in peace.
>

The user interface level of HyperDoc could be entirely replaced by a
conventional browser but the navigation of the internal FriCAS dynamic
type database still requires some sort of backend.

Bill Page.

-- 
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/CAC6x94TAHtxhe4YSQ%3DpoT64oYF-wE6UyzPYSqkxuk8WrxZE%3DBA%40mail.gmail.com.

Re: [fricas-devel] X11 and graphics

[Bill Page]

On Fri, Mar 19, 2021 at 5:07 PM Ralf Hemmecke  wrote:

>
> Actually, I would be interested in a poll that asks how many of
> our users ever use the graphics facilities of FriCAS. A similar
> poll for the use of HyperDoc would also be fine.
> Someone here on the list who would answer these questions?
>

Graphics: almost 0. Even if it did look nice I probably would not
use it often. Maybe that is just because of the kinds of things for
which I use FriCAS.

HyperDoc: almost every time I use FriCAS. I do often wish
that the HyperDoc interface looked more up to date. On the
other hand I do not much like to have to work online with
http://fricas.github.io Maybe I would use it more if it was
bundled into the FriCAS distribution somehow.

-- 
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/CAC6x94SyJn2v9UcVBnKxABH0HJvFDW9z5mDmcTrzuHndceZppQ%40mail.gmail.com.

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

[Bill Page]

On Sun, Dec 6, 2020 at 4:59 AM Ralf Hemmecke  wrote:
> >> ...
> >> ATM our handling of kernel cache is unsound.  Basicaly, kernel
> >> cache assumes order and in fact there are no consistent order
> >> on kernels.
>
> Why does Kernel need an order at all?
>

Ordering for kernels is important from the point of view of the use of
simplification and canonical form to determine equality. Most other
computational definitions of equality require much greater effort. In
general this is undecidable but it is desirable that any method
"almost work" in as large and important a subclass of expressions as
possible.

> Wouldn't it be an option to do kernel caching via XHashTable?
>

I tried using XHashTable to replace binary search while also
maintaining an ordering a few years ago. I did not see any performance
benefit.

> No, I have no deep insight. It's just a thought.
>

This problem has a long history and how it is treated in different
computer algebra systems is one of those fundamental things that
distinguishes them. I think that what Waldek is suggesting amounts to
trying to push the problem of defining canonical forms back to where
sub-expressions are generated. This sounds like a good strategy to me
but obviously not a complete solution.

Bill.

-- 
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/CAC6x94QxZCUOhGenU2A0ZN%2BSiBxJp6i%3Dy%2BwgsRXJkktO-ELA_g%40mail.gmail.com.

Re: [fricas-devel] Possible compiler bug: "Cannot coerce" error while trying to use ^ on Float and Integer arguments

[Bill Page]

The elements of DirectProduct are intended to be immutable
mathematical values, i.e a "tuple" in a n-tuple product, not a data
container.

On Sat, Oct 31, 2020 at 9:29 AM Neven Sajko  wrote:
>
> Thank you for your insight, Bill.
>
> Does somebody know why does DirectProduct not have setelt! and qsetelt! ?
>
> Thanks,
> Neven

-- 
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/CAC6x94QhWqY3dCj7HB4J%2BoRW0bMTzFEbjMB21k5W4uCTNAt61g%40mail.gmail.com.

Re: [fricas-devel] Why are inflexible data structure lengths not always encoded in the type?

[Bill Page]

On Fri, Oct 30, 2020 at 12:46 PM Martin Baker  wrote:
>
> On 29/10/2020 21:10, Neven Sajko wrote:
> > My guess would be that it would be better if Vector's constructor
> > had a length parameter, because that would enable greater type
> > safety (i.e. I couldn't pass a Vector of the wrong length to a
> > function).
>
> For me one of the great advantages of static types is that more
> errors are found at compile time rather than runtime. When we
> combine this with dependent types it means that we can detect,
> for example, attempts to add vectors of different lengths at compile
> time rather than runtime.
>

In my opinion the static type system of FriCAS (as inherited from
Axiom) is more about enabling ubiquitous polymorphism (function
overloading) than it is about program correctness. In FriCAS the
intended result type as well as the type and number of arguments are
used to disambiguate function calls. This is an important part of
generic programming in FriCAS.

It seems to me that program correctness in FriCAS is usually addressed
at a higher level by "contract and design" rather than "simple" type
correctness. By that I mean that we try to see our specific
programming goals as an instance of something a little more generic
and possibly already existing, i.e. belonging to a particular category
in the FriCAS sense. If nothing close enough exists then we might
start by defining such categories. Then we implement one or more
domains that satisfy these categories by representing it using
existing domains a little lower down in the type heterarchy which
ultimately depends on something built-in (or supplied by the
underlying Lisp). I think this model better fits FriCAS objective as a
high level mathematical computer *algebra* system based on abstract
algebra. I think this purely algebraic approach is largely in contrast
to the logic proof-theoretic approach that you discuss below.

> ...
> So far we have just considered + which is relatively simple because all
> we have to do is check that all types are the same. However when we are
> working with different length vectors in the same signature we move up
> to a higher complexity. For example consider concat:
>
> concat : ((VectorFL Double x), (VectorFL Double y)) -> (VectorFL
> Double (x + y))
>
> Here we can't use % because each vector has a different length. We need
> to check that the length of the result is the sum of the lengths of the
> two operands. This sort of thing may not be needed much for vectors but
> when we go to matrices it is more important. For example when we are
> multiplying two matrices the operands can have different dimensions
> provided the number of rows in one is the same as the number of columns
> in the other.
>
> The Idris language can handle all these sort of things very simply
> without any extra syntax.
>
> So my conclusion from this (unless you tell me otherwise) is that
> Axiom/FriCAS needs a more powerful type system (like Idris) to be able
> to do this sort of thing simply.
>
> 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/CAC6x94TS05s_DnaimYQHgnqGFPeLxZAsYr15_zEDM1R6YGCZMA%40mail.gmail.com.

Re: [fricas-devel] Possible compiler bug: "Cannot coerce" error while trying to use ^ on Float and Integer arguments

[Bill Page]

Two problems: First, unlike the interpreter, SPAD does not have
multiple assignment. The error message about "compColon" is the
compiler's poor way of trying to say that. Secondly, the DirectProduct
domain does not have a direction coercion from (...) tuple, List or
other similar domain. You need to explicitly call the 'directProduct'
function to create an instance.  It would probably be better if
DirectProduct exported a suitable function called 'construct'.

wspage@desktop:~/Downloads$ diff -au lab1.spad 'lab1(1).spad'
--- lab1.spad2020-10-30 17:20:50.432221061 -0400
+++ lab1(1).spad2020-10-30 17:20:18.928826110 -0400
@@ -20,8 +20,10 @@
 zero? n => a.1
 n = 1   => a.2
 n = 2   => a.3
-(c1, c2, c3): Float := (x.1+x.2+x.3,
-(x.1*x.2+x.2*x.3+x.3*x.1), x.1*x.2*x.3)
+c1: Float := x.1+x.2+x.3
+c2: Float := -(x.1*x.2+x.2*x.3+x.3*x.1)
+c3: Float := x.1*x.2*x.3
 for i in 3..n repeat
 b: D := a
-a := (b.2, b.3, c1*b.3 + c2*b.2 + c3*b.1)
+a := directProduct([b.2, b.3, c1*b.3 + c2*b.2 + c3*b.1])
 a.3

On Fri, Oct 30, 2020 at 1:29 PM Neven Sajko  wrote:
>
> Hmm, I tried to implement lab1method2 with iteration with a for loop
> instead of with recursion, but now Fricas tells me this:
>
> Internal Error
> Unexpected error in call to system function compColon
>
> The package is again attached.
>
> Thank you,
> Neven
>
> --
> 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/CAL%2BbK4M_BMeYA197K9YAKJvDVvXf705smyyk-Mwc%3D%2BQ4oF7G5w%40mail.gmail.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/CAC6x94Rrb1EU3Vd5Rwr1D8%2B9FTNETN8ZZMjuhtpNk_KT6feERg%40mail.gmail.com.

Re: [fricas-devel] Why are inflexible data structure lengths not always encoded in the type?

[Bill Page]

Checkout the DirectProduct domain. Granted, this name might not be so obvious.

In a computer algebra system like FriCAS the name "Vector" should
probably be reserved for something with specific mathematical
properties. e.g. as in differential geometry.
But I think that there are some good arguments that the current
implementation of the Vector domain is also less than satisfactory
from this point of view.

There is another group of domains that specifically support various
types of "array" data structures. (Although none of them as far as I
know are fixed length structures.)

On Thu, Oct 29, 2020 at 5:10 PM Neven Sajko  wrote:
>
> Hello,
>
> While I am slowly learning Fricas, I noticed a pattern (or the lack of
> it) that struck me as odd. Namely, some data structure types of fixed
> size have constructors which take a parameter to define the size as
> part of the type (e.g., SquareMatrix), while others (like Vector) do
> not take a parameter that specifies the data structure's fixed length.
>
> Is this an oversight or a product of an intentional decision? Is it
> beneficial or detrimental? Is this important at all?
>
> My guess would be that it would be better if Vector's constructor had
> a length parameter, because that would enable greater type safety
> (i.e. I couldn't pass a Vector of the wrong length to a function).
>
> Is there a way to define a function that takes a Vector of length 3 as
> input, so the input argument's length would be checked by Fricas
> automatically when calling the function?
>
> Thank you,
> Neven Sajko
>
> --
> 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/CAL%2BbK4Pnw5ZrdEmwrpAY2Ocj9LiDSayNg9mgrZBESGjh%2BWL%3DAw%40mail.gmail.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/CAC6x94Q-_7b57vEVuKMCnRYzSDW%2BEF16X0vjJiOy2wfhFyX%3DfA%40mail.gmail.com.

Re: [fricas-devel] FriCAS and TeXmacs update

[Bill Page]

Thanks for taking the bait! :-)

On Thu, Oct 29, 2020 at 12:11 PM Kurt Pagani  wrote:
> ...
> https://fricas.github.io/api/GnuDraw.html?highlight=gnudraw
>
> It seems to be the only method at the moment (besides the built-in "draw")
> that can reliably produce graphics using fricas data. It is easy to use it in
> TeXmacs. One has to define a small function which calls gnuplot and
> inserts the picture into TM (there is a package TexmacsSupport @
> https://github.com/nilqed/spadlib/tree/master/tmspt (file src/tmspt.spad)
> which may help to show how it might go (see test_gnudraw.pdf), i.e.
> one has to combine the commands into a function ...
>

I greatly appreciate the hints and examples.

> ...
> Probably the Gnuplot plugin of TeXmacs could be called from within the
> fricas plugin (the scheme commands are known), however, it seems more
> simple to me using GnuDraw and insert produced png/ps or whatever than
> using another plugin.

Maybe you are right. I just seems a bit messy to have to use a
temporary file to communicate.

> >
> > I think Kurt and Ralf are/were thinking of something like this for the
> > FriCAS Jupyter interface.
>
> We were (actually still are), but Ralf thought, it's better to start
> without graphics in the first release. He's certainly right, as there
> still is the agony of choice and lack of a reliable link to produce
> data from fricas objects.
> ...
> My favourite still is GLE (BSD, c code, only QGLE is LGPL). Provides
> really HQ (eps,pdf,...), or LaTeX/PGF/TikZ (GeoGebra, for instance,
> can export PGF).
>
> https://kfp.bitbucket.io/tmp/GLE.html
>

Looks great to me.

> You see, there are a lot of prototypes in the pipeline, however,
> without an initial impetus/decision which system to use (lcd) it
> might take ages ...
>

Let me at least add my strong encouragement for this addition to jfricas.

>
> BTW, I also find the "draw commands" not very flexible. It would be
> easy to slightly modify the draw and view2/3.spad files (as I did 4y
> ago according github;) in order to use one of the plot packages
> mentioned, but then you're sticked to those few methods/parameters.
> IMO a free format like )gnuplot or  )mplot should be used if one
> needs more than a toy.
> https://github.com/nilqed/fricas_input/tree/master/spad/draw
>

By )gnuplot are you suggesting a new command in FriCAS with this name?

Is your idea to provide tools in FriCAS just to generate package
independent data and then call an external package with the
desired options/functionality to actually produce the graphics?

Bill.

-- 
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/CAC6x94RdiSkaSJx2Uou0w33wBEt3OoUrvMC3LGMVF5-fsv6L2Q%40mail.gmail.com.

Re: [fricas-devel] FriCAS and TeXmacs update

[Bill Page]

On Wed, Oct 28, 2020 at 11:56 AM Kostas Oikonomou
 wrote:
>
> To answer your questions, I am not a very sophisticated Fricas
> user, so I don't write SPAD code.

:) Well, you are already using FriCAS so I would say that you are
rather sophisticated!

The SPAD compiler is frustrating by modern standards but the language
itself is quite straightforward, albeit a bit overly pedantic,
compared to the interpreter. I think most people could easily learn to
program in SPAD from a few basic examples.

> But, more importantly, TeXmacs is not really a programmer's editor
> like Emacs. It is an editor for scientific (technical) documents.

What I had in mind is perhaps little like the literate programming
ideal that was promulgated by the original Axiom parent project (and
still in use there). I never liked the idea much when it came to
maintaining existing Axiom system code but it still makes sense to me
in the case of the activity of scientific application programming
itself.

>  (Nevertheless, it knows how to typeset fragments of many
> programming languages so they look good when included in
> a document. By "programming languages" we also mean
> computer algebra systems.)

I agree.

> So for writing SPAD code I would use Emacs, or some other
> IDE, if you prefer.

Wel, OK.  There are valid arguments however that code and
documentation really belong together, especially in the case of
research.

What I had in mind perhaps could be done in TeXmacs by inventing a new
FriCAS session type just for the compiler. The main difference would
be that the contents of a SPAD session would be compiled instead of
being interpreted.

>
> With respect to including graphics in a document, there
> is a sophisticated interface that handles eps, pdf, png.
> You can access it by the button with the picture of a tree
> in the second row of the buttons at the top of the window.

Hmm, FriCAS does have some preliminary support for the generation of
GNUplot input data. I wonder if that could be used together with the
GNU plot plugin for TeXmacs - or some other similar graphics plugin?

I think Kurt and Ralf are/were thinking of something like this for the
FriCAS Jupyter interface.

Bill Page.

-- 
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/CAC6x94T5mMCHLbJgDpw88N_V5zvteBx3pg7BgE9gndruCoZWZg%40mail.gmail.com.

[fricas-devel] FriCAS and TeXmacs update

[Bill Page]

Kostas,

Thank you for the link to the updated Linux binaries for TeXmacs.
After some initial testing I think things seem to have improved
significantly since the last time I used TeXmacs and FriCAS together a
few years ago. TeXmacs seems more reliable and more responsive than it
did back then. I had no problem accessing FriCAS immediately after
installing TeXmacs and Greek characters and other special symbols
worked as expected. I will probably try using this combination for my
next FriCAS project.

I have a couple of questions. Do you also use TeXmacs to edit SPAD
code? If so, do you have any "best practices" advice about editing,
compiling and running custom SPAD code in this environment? Second, is
there some way to embed FriCAS-generated graphics/plots into TeXmacs
documents?

Maybe this is a good time to put a little more emphasis on this
alternative user interface for FriCAS.

Bill Page.

On Mon, Oct 26, 2020 at 6:43 PM Kostas Oikonomou
 wrote:
>
> Thanks to everyone who helped resolve this problem.
>
> As an aside, if anyone wants to try the latest TeXmacs, there are
> *static* binaries for Linux now available, which should make the
> installation painless:
>
> http://www.texmacs.org/tmweb/download/linux.en.html
>
> (There seem to be static binaries for MacOS and Windows as well.)
>
>  Kostas

-- 
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/CAC6x94RbmvjTmXmutPq80dWRWcDgj7SozsnkH%2BTJ7kn4_n9JNg%40mail.gmail.com.

Re: [fricas-devel] FriCAS 1.3.6 problem with greek symbols (Was "problem with TeXmacs interface")

[Bill Page]

On Fri, Oct 23, 2020 at 6:20 PM Kostas Oikonomou
 wrote:

> ...
> How do you actually type the 'α'?   I switch my keyboard to Greek layout.
>

I just cut-and-paste from the email.  I also use a desktop app called
"Character Map" which is more general but more awkward.

Can I assume that you successfully use Greek with other applications?
E.g. In the system text editor?

Maybe the actual version of Linux that you are using is relevant?

Sorry that I can't be much more help.

-- 
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/CAC6x94Qn6hbgXc_%2BkXOmJ31OXUVdQsfUfM667Bw%3DQkwV-dyrig%40mail.gmail.com.

Re: [fricas-devel] FriCAS 1.3.6 problem with greek symbols (Was "problem with TeXmacs interface")

[Bill Page]

I am now using fricas built from git master today

(1) -> )version
Value = "FriCAS 2020-04-23 compiled at Thu Oct 22 20:23:50 EDT 2020"

I also tried fricas with the -rl option as suggested by Ralf.  After
installing the rlwrap program

wspage@desktop:~$ rlwrap --version
rlwrap 0.43

$ fricas -rl

worked perfectly for me - including command line editing with Greek characters.

I am running Linux Mint 18.3 on my desktop.

You might want to check the locale setting on your computer. I have

$ wspage@desktop:~$ locale
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="en_CA.UTF-8"
LC_NUMERIC="en_CA.UTF-8"
LC_TIME="en_CA.UTF-8"
LC_COLLATE="en_CA.UTF-8"
LC_MONETARY="en_CA.UTF-8"
LC_MESSAGES="en_CA.UTF-8"
LC_PAPER="en_CA.UTF-8"
LC_NAME="en_CA.UTF-8"
LC_ADDRESS="en_CA.UTF-8"
LC_TELEPHONE="en_CA.UTF-8"
LC_MEASUREMENT="en_CA.UTF-8"
LC_IDENTIFICATION="en_CA.UTF-8"
LC_ALL=

You should probably have something similar regarding UTF-8 but
probably different language.

Bill.

On Thu, Oct 22, 2020 at 7:08 PM Kostas Oikonomou
 wrote:
>
> Thank you Bill and Ralph.
> Ok, I went back to 1.3.6.  But I still see a problem:
>
> $ fricas -noclef
> Checking for foreign routines
> FRICAS="/usr/local/lib/fricas/target/amd64-portbld-freebsd12.1"
> spad-lib="/usr/local/lib/fricas/target/amd64-portbld-freebsd12.1/lib/libspad.so"
> foreign routines found
> openServer result 0
> FriCAS Computer Algebra System
>  Version: FriCAS 1.3.6
> Timestamp: Sat Jul 11 03:10:07 UTC 2020
> -
> Issue )copyright to view copyright notices.
> Issue )summary for a summary of useful system commands.
> Issue )quit to leave FriCAS and return to shell.
> -
>
>
> (1) -> α
>Line   1: α
> .AB
>Error  A: Improper syntax.
>Error  B: The character #\PLUS-MINUS_SIGN is not an FriCAS character.
> 2 error(s) parsing
>
> (1) ->
>
> Bill, are you using 1.3.6?
>
> I also tried
>
> fricas -clefprog rlwrap
>
> but this never even prints out a prompt.
>
>  Kostas
>
> On 10/22/20 3:19 PM, Ralf Hemmecke wrote:
> > On 10/22/20 8:39 PM, Bill Page wrote:
> >> Try starting fricas like this:
> >>
> >> $ fricas -noclef
> >>
> >> Doing this avoids the command line problem for me.
> > Indeed. CLEF is the problem.
> >
> > Just edit your fricas script. Edit the one in your PATH if you do not
> > want to recompile fricas.
> >
> >> "clef" is the old Axiom alternative to readline and is still used by
> >> default. Of course without clef (and without building FriCAS especially to
> >> support readline) you lose the usual command line editing.
> > But in the master branch is now the -rl option. If you have rlwrap
> > installed on your computer, then "fricas -rl" will choose readline
> > instead of clef and you have full editing features.
> >
> >> I am not sure if the TeXmacs interface already avoids using clef or not. If
> >> not then I think it should. I vaguely recall that it used to use the
> >> -nosman option which also implies -noclef and -noht. Sorry, I don't have
> >> TeXmacs installed on this desktop system any more or I would try it.
> > It doesn't use -nosman, but basically it does, because it calls
> > FRICASsys directly. But I am not sure whether that actually means that
> > it doesn't use clef.
> >
> > https://github.com/fricas/fricas/blob/master/src/etc/fricas#L102
> >
> > Anyway, maybe replacing
> >
> > if [ "$*" = "-texmacs" ] ; then
> >  exec "$FRICAS/bin/FRICASsys" -- -eval "$algebra_off" -eval
> > "$markers" -eval "$texmacs_on"
> > fi
> >
> > by
> >
> > if [ "$*" = "-texmacs" ] ; then
> >  exec "rlwrap $FRICAS/bin/FRICASsys" -- -eval "$algebra_off" -eval
> > "$markers" -eval "$texmacs_on"
> > fi
> >
> > just works. (I haven't tested that!)
> >
> > 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/7c3f7917-0c42-8b2c-9054-0e1f22948276%40gmail.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/CAC6x94QTeNX%2B8FNBx7Ksi9cJAB%3DjhmUktqupWR0ywv9XV4bgFA%40mail.gmail.com.

Re: [fricas-devel] FriCAS 1.3.6 problem with greek symbols (Was "problem with TeXmacs interface")

[Bill Page]

On Thu, Oct 22, 2020 at 3:19 PM Ralf Hemmecke  wrote:
>
> It doesn't use -nosman, but basically it does, because it calls
> FRICASsys directly. But I am not sure whether that actually
> means that it doesn't use clef.
>

In that case it definitely does not use clef.

>
> https://github.com/fricas/fricas/blob/master/src/etc/fricas#L102
>
> Anyway, maybe replacing
>
> if [ "$*" = "-texmacs" ] ; then
> exec "$FRICAS/bin/FRICASsys" -- -eval "$algebra_off" -eval
> "$markers" -eval "$texmacs_on"
> fi
>
> by
>
> if [ "$*" = "-texmacs" ] ; then
> exec "rlwrap $FRICAS/bin/FRICASsys" -- -eval "$algebra_off" -eval
> "$markers" -eval "$texmacs_on"
> fi
>
> just works. (I haven't tested that!)

I do not see why texmacs would require readline for the interface with fricas.

-- 
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/CAC6x94RiYdVRiWQH-0ewPQd-Lxm13CHCZugnB8SvEUajDNhsNA%40mail.gmail.com.

Re: [fricas-devel] FriCAS 1.3.6 problem with greek symbols (Was "problem with TeXmacs interface")

[Bill Page]

Try starting fricas like this:

$ fricas -noclef

Doing this avoids the command line problem for me.

"clef" is the old Axiom alternative to readline and is still used by
default. Of course without clef (and without building FriCAS especially to
support readline) you lose the usual command line editing.

I am not sure if the TeXmacs interface already avoids using clef or not. If
not then I think it should. I vaguely recall that it used to use the
-nosman option which also implies -noclef and -noht. Sorry, I don't have
TeXmacs installed on this desktop system any more or I would try it.


On Thu, Oct 22, 2020 at 12:14 PM Kostas Oikonomou <
kostas.oikonomo...@gmail.com> wrote:

> Hi Ralf,
>
> Thanks for responding.  It may be that the master branch fixes (part) of
> the problem.
> Meanwhile I reverted to 1.3.5, which has this behavior:
>
>
> (1) -> f(x) == c*x^2
> Type: Void
> (2) ->f(α))
> Compiling function f with type Variable(α) -> Polynomial(Integer)
>
>2
> (2)  c α
>  Type:
> Polynomial(Integer)
> (3) -αα
>
> (3)  α
> Type:
> Variable(α)
>
>
>  Kostas
>
> On 10/22/20 11:02 AM, Ralf Hemmecke wrote:
> > Hello Kostas,
> >
> > thanks for reporting.
> >
> > I simply typed one α and FriCAS is showing a double α on the input line.
> > Strange.
> >
> > (3) ->αα
> >
> > (3)  α
> >   Type: Variable(α)
> >
> > But I cannot confirm your second problem.
> >
> >
> > (7) -> f(x)==c*x^2
> >Type: Void
> > (8) ->f(α))
> > Compiling function f with type Variable(α) -> Polynomial(Integer)
> >
> > 2
> > (8)  c α
> >Type: Polynomial(Integer)
> >
> > So there is somehow a problem with printing unicode characters, but on
> > the INPUT not OUTPUT line. Still strange, but I don't yet know where the
> > input is REPRINTED.
> >
> > Ralf
> >
> > PS: Oh I am working with
> >
> > (9) -> )version
> >
> > Value = "FriCAS 99b0ed3ba53afbba57169283e803b2009020047d compiled at Sun
> > Oct  4 17:43:38 CEST 2020"
> >
> > So maybe your problem appears in 1.3.6, but not in the current master
> > branch.
> >
> > 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/7a67572d-fe20-4fd1-c15a-50ac605f7e11%40gmail.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/CAC6x94R%3DFSmtf5FgZDsi7wo%3DahP%3DBj5wq6j%3D3y1npyhAt%3DaP6Q%40mail.gmail.com.

Re: [fricas-devel] ReplaceAll in FriCAS

[Bill Page]

(1) -> v:=operator('v)

   (1)  v
  Type:
BasicOperator
(2) -> m*a=-m*g-k*v(t)

   (2)  a m = - k v(t) - g m
  Type:
Equation(Expression(Integer))
(3) -> subst(%% 2, a=differentiate(v(t),t))

   ,
   (3)  m v (t) = - k v(t) - g m

  Type:
Equation(Expression(Integer))


On Sun, Jul 26, 2020 at 11:33 AM Roustam Shaitan  wrote:

> Hello,
>
> In Wolfram Mathematica it's possible to transform an equation with
> ReplaceAll (/.):
>
> In[1]m*a==-m*g-k*v[t]
> Out[1] am=-gm-kv(t)
>
> In[2]%1 /. a->v'[t]
> Out[2] mv'(t)=-gm-kv(t)
>
> How to do the same in FriCAS? With rules? Can I apply them to equations
> and not just expressions?
>
> Thank you.
>
> Roustam
>
> --
> 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/cb3d38f1-b665-4a50-9687-4d07e8a0eb75o%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/CAC6x94SY7CYM7gmduXyAAyOoVYsqvLF%3D%2BmQ%3DCObu6mhdnwsXrQ%40mail.gmail.com.

Re: [fricas-devel] Switching to Git

[Bill Page]

On Fri, Mar 20, 2020 at 12:24 PM oldk1331  wrote:
>
> Hi, what's your opinion on CI and bug tracker (in github)?
>

+1 and +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/CAC6x94RNHmgdH59g5%2B4%2B3iOe6jOUUg%2BZAfw8tu33u2wzQkfn0w%40mail.gmail.com.

Re: [fricas-devel] Switching to Git

[Bill Page]

On Fri, Mar 20, 2020 at 10:11 AM Waldek Hebisch
 wrote:
>
> Fricas is now using Git.  Former mirror at Github is
> now official repository:
>
> https://github.com/fricas/fricas
>

Great. 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/CAC6x94R11mwsXQ-QVv17EJ5txhV4W16qXVLfdpe1cEcoO-gm4A%40mail.gmail.com.

Re: [fricas-devel] Using fricas from other programs

[Bill Page]

To ensure that the last line of output is written to the file you
should include the following two commands at the end of the input
file:

)set output algebra console
)quit

On Tue, Mar 10, 2020 at 8:11 PM Bill Page  wrote:
...
> )cd /tmp
> )set output algebra on
> )set output algebra fricasComputationsForGo
> cbrt(1.1)
> erfc(1.2)
> log1p(1.3)
...

-- 
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/CAC6x94SJELUqNPbKkTXHtd46AsLh%3DDRT%3DfP-r4L_QSev4Fmbzw%40mail.gmail.com.

Re: [fricas-devel] Using fricas from other programs

[Bill Page]

Perhaps you meant to write:

)set output algebra off
)set history off
)set messages prompt none
)set messages startup off
)set messages type off
)set messages any off
digits 1
outputFloating 25
outputSpacing 0
cbrt: (Float) -> Float
erfc: (Float) -> Float
log1p: (Float) -> Float
cbrt(x)  == (nthRoot(x, 3))
erfc(x)  == (1 - erf(x))
log1p(x) == (log(1 + x))
)cd /tmp
)set output algebra on
)set output algebra fricasComputationsForGo
cbrt(1.1)
erfc(1.2)
log1p(1.3)
--

I.e.

)set output algebra on
before you do the computations.

This works for me.


On Tue, Mar 10, 2020 at 7:28 PM Neven Sajko  wrote:
> ...
> I tried writing to a file, but I think I hit a Fricas bug. I have the 
> following
> .fricas.input now:
>
> )set output algebra off
> )set history off
> )set messages prompt none
> )set messages startup off
> )set messages type off
> )set messages any off
> digits 1
> outputFloating 25
> outputSpacing 0
> cbrt: (Float) -> Float
> erfc: (Float) -> Float
> log1p: (Float) -> Float
> cbrt(x)  == (nthRoot(x, 3))
> erfc(x)  == (1 - erf(x))
> log1p(x) == (log(1 + x))
> cbrt(1.1)
> erfc(1.2)
> log1p(1.3)
> )cd /tmp
> )set output algebra on
> )set output algebra fricasComputationsForGo
>
> But the algebra output is not being written to
> /tmp/fricasComputationsForGo.spout, or anywhere else I see, for that
> matter! The file instead just contains this, referring to itself:
>
>Algebra output will be written to file
>   /tmp/fricasComputationsForGo.spout .
>
> Thanks,
> Neven Sajko
>
> --
> 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/CAL%2BbK4NuYowQ_OUeSsuMkR%3DV_03WaZE7oTQ4cvthqiGS1%3DrTvw%40mail.gmail.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/CAC6x94TEjgiqr3xcWLE6jn%3DTnrxVO22AwFmb0mLctvnGAeeTyg%40mail.gmail.com.

Re: [fricas-devel] New release

[Bill Page]

On Sat, Feb 29, 2020 at 11:02 AM Dima Pasechnik  wrote:
> ...
> The projects that stick to cvs or svn suffer,
> as cvs and svn are legacy tools, and forcing
> it on contributors is counterproductive.
>

+1 for git. Please.

-- 
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/CAC6x94T6_xJ_VM1V1Yy5eb7JVk1AuTMrsj%3DjiCoDoqGsRW6XKw%40mail.gmail.com.

[fricas-devel] clicking on Origins in Hyperdoc generates debug message

[Bill Page]

There is a debugging message generated when one browses an operation
in hyperdoc and then clicks on Origins.  The output is a Lisp
s-expression generated by the following line in
src/interp/br-op1.boot:

359  SAY(["dbGatherData", data])

https://github.com/fricas/fricas/blob/a78b8135fab09455b0a2e8263a1386c181195e8c/src/interp/br-op1.boot#L359

-- 
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/CAC6x94Q%2BLha2U2-K0t_C-LsMbQXZFgp9BdZ2hcmudgkGDccm6g%40mail.gmail.com.

Re: [fricas-devel] ARRAY2 enhanced

[Bill Page]

On Mon, Nov 11, 2019 at 4:53 PM Ralf Hemmecke  wrote:
>
> On 11/4/19 11:24 PM, Prof. Dr. Johannes Grabmeier privat wrote:
> > Hi all,
> > I have enhanved TwoDimensionalArray to include arithmetic for block
> > matrices and have an operation array2 (similar to matrix for Matrix) for
> > easy creation of two-dimensional array and would suggest to include this
> > into the next version:
>
> I guess the background of this is relatively clear. FriCAS currently
> forbids the creation of Matrix(Matrix Integer).
>
> (15) -> A := matrix([[A11, A12],[A21, A22]])$Matrix(Matrix Integer)
>
>Matrix(Matrix(Integer)) is not a valid type.
>

Yes. Currently MatrixCategory expects R:AbelianMonoid as a parameter.
But a domain that exports MatrixCategory itself is not an
AbelianMonoid because MatrixCategory does not provide 0 as the unique
identity (there are many possible zero matrices of different
dimensions).

As far as I can see MatrixCategory requires 0 only for rather
technical reasons involving the initialization of the ARRAY2
representation. So in principle it should be possible to change
MatrixCategory to require only R:AbelianSemiGroup and then to also
export AbelianSemiGroup.  This would enable constructions such as the
above.

> You basically suggest to get around this problem, but extending
> TwoDimensionalArray.
>
> What application do you have in mind?
>
> Why I would be against this extension is that TwoDimensionaArray is a
> data structure domain, i.e., no algebraic operations.
>

+1 I am also against this for the same reason.

> Your operations should live in an "algebraic" domain. But even then I
> see problems, because + and * will be partial functions (much as in
> Matrix(Matrix Integer) if it were possible).
>
> A good motivation for your extensions would help to consider them for
> FriCAS.
>

I have done some preliminary experiments using AbelianSemiGroup but it
seems a little more difficult than I thought since apparently a few
other domains are affected by the change. If there is some interest in
this I could try a little harder to get this to work.

Bill.

-- 
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/CAC6x94TROoOn77gLXE0A5AbmszZgL3AZt0U6VyEhCH1jCSP19Q%40mail.gmail.com.

Re: [fricas-devel] Announce: FriCAS 1.3.5 has been released

[Bill Page]

On Sun, Feb 3, 2019 at 11:09 AM Waldek Hebisch  wrote:
> ...
> Notable changes (compared to version 1.3.4):
>
> - Added free noncommutative field.
> - Added factorization in free algebra.
> - Improved coercion to InputForm.
> ...
> - Fixed input form of formal derivatives.
> - Fixed coercion of polynomials to patterns.
> - Fixed comparison with signed floating point zero.
>  ...

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 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/CAC6x94Tb2td3e7StCYVWxd2w%2B2HMEMBGxmQ4tH50OdGjnSv3Gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Bug?

[Bill Page]

On Wed, Jan 30, 2019 at 5:58 AM oldk1331  wrote:
>
> On 1/30/19 5:13 PM, Ralf Hemmecke wrote:
> ...
> > In fact, it keeps confusing me.
> >
> > In Aldor, if write something like
> >
> >   foo: % == [1, empty()]
> >   bar(): % == [1, empty()]
> >
> > then in the use of bar() I would expect a new allocation every time
> > bar() is used. But not so for foo. In Aldor bar is a function but foo is
> > a constant (no function call).
>
> I think "foo" and "bar" are the same: the empty parentheses can be omitted.
> They are both functions with no arguments.
>
> The thing matters is that "1" is declared as:
>
> 1 : constant -> %
>
> That makes sure function body of "1" is called only once.
>
> So in
>
> foo1 : () -> %
> foo2 : constant -> %
>
> the function body of "foo1" will run many times and the function body of 
> "foo2"
> will run only once.  I didn't know this distinction before...
>

Thank you! I think this distinction is clear and important.

-- 
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/CAC6x94T4eufFtLdfVgSACjABVhW4WPNza2dDtpwFrAgqC%2BEySQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Bug: HyperDoc fails to display exports of XPOLY

[Bill Page]

In a recent version of FriCAS ih HyperDoc click Browse, enter XPOLY
and click Constructors, then click Exports. HyperDoc displays:

  "For some reason the page you tried to link to cannot be formatted."

On the console the following output appears:

(1) ->
   >> System error:
   The value
  T
is not of type
  LIST

Note: All other options work as expected, also repeating the above
steps using XDPOLY (or any other domain I tried) instead of XPOLY
works as expected.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Noncommutative factorization

[Bill Page]

Waldek,

On Sat, Nov 10, 2018 at 12:02 PM you wrote:
>
> One update to what I wrote before.  In
>
> J. P. Bell, A. Heinle, and V. Levandovskyy,
> On Noncommutative Finite Factorization Domains,
> Trans. Amer. Math. Soc. 369 (2017), 2675-2695
>
> there is proof of finite number of factorizations.
>
> I have now implemented the lift part of Davenport-Caruso method.
> ...

Since the number of factorizations of a non-commutative polynomial
over a unique factorization domain is finite but not unique there may
be some applications where it maybe interesting to know more than one
or even all possible factorizations. Your current implementation
produces just one factorization. Do you see any opportunity to extend
the Davenport-Caruso method to produce multiple factorizations or a
complete enumeration of factorizations?

I did some experiments with the xdpolyf1 factorizer to produce such
multiple factorizations. This was relatively easy since the solution
algorithm (with the "pruning" heuristic) naturally produces
factorizations in which either the left factor or right factor at each
step has a minimum number of terms. By alternately choosing to
minimize first the right factor and then the left factor it is
possible to explore alternate factorizations. I did not get so far as
to attempt to prove completeness.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Noncommutative factorization

[Bill Page]

That looks great!

As a performance test I tried this:

(79) -> h2323:=((h2*h3*h2*h3)^2);

Type: 
XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Fraction(Integer))
   Time: 0.00 (IN) + 2.71 (EV) + 0.00 (OT) = 2.71 sec
(80) -> dc_fact h2323

   (80)
   [- y x + x y, - z y x + z x y + y z x - y x z - x z y + x y z, - y x + x y,
- z y x + z x y + y z x - y x z - x z y + x y z, - y x + x y,
- z y x + z x y + y z x - y x z - x z y + x y z, - y x + x y,
- z y x + z x y + y z x - y x z - x z y + x y z]
Type: 
List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Fraction(Integer)))
   Time: 0.00 (IN) + 315.56 (EV) + 0.13 (OT) = 315.69 sec

Although you have already pointed out that this code is not yet
optimized I think it is interesting to compare this with Konrad's
program that produces the following result on  the same problem:

(54) -> h2323:=((h2*h3*h2*h3)^2);

Type: 
FreeDivisionAlgebra(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Fraction(Integer))
   Time: 0.00 (IN) + 0.37 (EV) + 0.00 (OT) = 0.37 sec
(55) -> map(x+->x::XDP,factor h2323)

   (55)
   [y x - x y, z y x - z x y - y z x + y x z + x z y - x y z, - y x + x y,
- z y x + z x y + y z x - y x z - x z y + x y z, y x - x y,
z y x - z x y - y z x + y x z + x z y - x y z, - y x + x y,
- z y x + z x y + y z x - y x z - x z y + x y z]
Type: 
List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Fraction(Integer)))
 Time: 0.00 (IN) + 25.45 (EV) + 0.01 (OT) = 25.46 sec

---

On Mon, Nov 12, 2018 at 4:09 PM Waldek Hebisch  wrote:
>
> ...
> Thanks for testcases (this one and from other post).  I overlooked
> a case when lift equation has unique solution, but the simple
> method used by 'dc_fact1' found wrong one.  Now those cases
> are hanlded like cases with non-unique solution and passed to
> 'solve' to sort out.  New version at:
>
> http://www.math.uni.wroc.pl/~hebisch/fricas/dcfact3.input
>
> --

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Noncommutative factorization

[Bill Page]

> > On Sat, Nov 10, 2018 at 12:02 PM Waldek Hebisch
> >  wrote:
> > ...
> > >
> > > I have now implemented the lift part of Davenport-Caruso method.
> > > You fetch code at:
> > >
> > > http://www.math.uni.wroc.pl/~hebisch/fricas/dcfact2.input
> > > http://www.math.uni.wroc.pl/~hebisch/fricas/nc_ini04c.input
> > >
> > > As before, dcfact2.input is an actual routine, nc_ini04c.input
> > > set up needed types.
> ...

Here is a more minimal example of the problem:

(86) -> h3 := x*y*z - x*z*y + z*x*y

   (86)  z x y - x z y + x y z
Type: 
XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Fraction(Integer))
   Time: 0.00 (EV) + 0.00 (OT) = 0.00 sec
(87) -> dc_fact(h3*(1+y))

   22
   (87)  [z x y - x z y + x y z + z x y  - x z y  + x y z y]
Type: 
List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Fraction(Integer)))
   Time: 0.00 (EV) + 0.00 (OT) = 0.00 sec

The xdpolyf1 code gives the following result:

(96) -> factor(h3*(1+y))

   (96)  [z x y - x z y + x y z, 1 + y]
Type: 
List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Integer))
   Time: 0.14 (EV) + 0.00 (OT) = 0.14 sec

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Noncommutative factorization

[Bill Page]

On Sat, Nov 10, 2018 at 9:08 PM Bill Page  wrote:
>
> On Sat, Nov 10, 2018 at 12:02 PM Waldek Hebisch
>  wrote:
> ...
> >
> > I have now implemented the lift part of Davenport-Caruso method.
> > You fetch code at:
> >
> > http://www.math.uni.wroc.pl/~hebisch/fricas/dcfact2.input
> > http://www.math.uni.wroc.pl/~hebisch/fricas/nc_ini04c.input
> >
> > As before, dcfact2.input is an actual routine, nc_ini04c.input
> > set up needed types.
...
>
> This looks very promising however I did find this apparent failure:
>
> (82) -> h3
>
>(82)  - z y x + z x y + y z x - y x z - x z y + x y z
> Type: 
> XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Fraction(Integer))
>Time: 0.00 (OT) = 0.00 sec
> (83) -> dc_fact((3+x*z*y)*h3)
>
>(83)
>[
>- 3 z y x + 3 z x y + 3 y z x - 3 y x z - 3 x z y + 3 x y z - x z y z 
> y x
>  +
>   2   2
>x z y z x y + x z y z x - x z y x z - x z y x z y + x z y x y z
>  ]
> Type: 
> List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Fraction(Integer)))
>Time: 0.00 (OT) = 0.00 sec

For comparison here is the output of Konrad Schrempf's program:

(1) -> )r nc_ini14.input
...
(52) -> h3 := x*y*z - x*z*y + z*x*y - z*y*x + y*z*x - y*x*z

   (52)
   AGGSET
  +1  - x  - z   0   - y   000 ++ 0 +
  |||   |
  |10z00y0 || 0 |
  |||   |
  | 1   - x   0y00 || 0 |
  |||   |
  |  1000y || 0 |
  ||s = |   |
  |   1   - z  - x   0 || 0 |
  |||   |
  |10x || 0 |
  |||   |
  | 1   - z|| 0 |
  |||   |
  +  1 ++- 1+
  ,
   MR
  ,
   - z y x + z x y + y z x - y x z - x z y + x y z
Type: 
FreeDivisionAlgebra(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Fraction(Integer))
   Time: 0.00 (IN) + 0.03 (EV) + 0.01 (OT) = 0.04 sec
(53) -> map(x+->x::XDP,factor((3+x*z*y)*h3))

   (53)  [3 + x z y, - z y x + z x y + y z x - y x z - x z y + x y z]
Type: 
List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Fraction(Integer)))
   Time: 0.00 (IN) + 0.16 (EV) + 0.01 (OT) = 0.17 sec

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Noncommutative factorization

[Bill Page]

On Sat, Nov 10, 2018 at 12:02 PM Waldek Hebisch
 wrote:
...
>
> I have now implemented the lift part of Davenport-Caruso method.
> You fetch code at:
>
> http://www.math.uni.wroc.pl/~hebisch/fricas/dcfact2.input
> http://www.math.uni.wroc.pl/~hebisch/fricas/nc_ini04c.input
>
> As before, dcfact2.input is an actual routine, nc_ini04c.input
> set up needed types.
>
> You can try things like:
>
> dc_fact(((x*z - z*x)^2 - 2)*((x*z - z*x)^2 - 3)*((x*z - z*x)^2 - 5))
>
> The idea is like in Caruso preprint, but code differs -- I coded
> what follows by working out solutions to lift equations.
>
> The code is unoptimized, for example for homogeneous polynomials
> it runs the whole lift, while we know that the factorization must
> be homogeneous...  Also, code introduces extra parameters
> when there is overlap between leading monomials of top factors,
> while in many cases this parameter could be immediately eliminated.
> Still, it seem to work quite a bit faster than xdpolyf1.spad.
>
> --

This looks very promising however I did find this apparent failure:

(82) -> h3

   (82)  - z y x + z x y + y z x - y x z - x z y + x y z
Type: 
XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Fraction(Integer))
   Time: 0.00 (OT) = 0.00 sec
(83) -> dc_fact((3+x*z*y)*h3)

   (83)
   [
   - 3 z y x + 3 z x y + 3 y z x - 3 y x z - 3 x z y + 3 x y z - x z y z y x
 +
  2   2
   x z y z x y + x z y z x - x z y x z - x z y x z y + x z y x y z
 ]
Type: 
List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Fraction(Integer)))
   Time: 0.00 (OT) = 0.00 sec

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Noncommutative factorization

[Bill Page]

Surprisingly a non-homogeneous polynomial of the same degree works OK

(69) -> factor((h3+1)*(h3+1))

   (69)
   [1 - z y x + z x y + y z x - y x z - x z y + x y z,
1 - z y x + z x y + y z x - y x z - x z y + x y z]
Type: 
List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Integer))
 Time: 0.00 (IN) + 15.93 (EV) + 0.03 (OT) = 15.96 sec

but as Waldek noted 'factor(h3*h3)' does not complete in reasonable time.

On Wed, Nov 7, 2018 at 8:55 AM Bill Page  wrote:
>
> On Wed, Nov 7, 2018 at 8:37 AM Ray  wrote:
> > ...
> > So homo_fact((x^2-y^2)^2)
> > would succeed?
> >
>
> Yes.
>
> (66) -> homo_fact((x^2-y^2)^2)
>
>  22 22
>(66)  [- y  + x , - y  + x ]
> Type: 
> List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Integer))
>   Time: 0 sec

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Noncommutative factorization

[Bill Page]

On Wed, Nov 7, 2018 at 8:37 AM Ray  wrote:
> ...
> So homo_fact((x^2-y^2)^2)
> would succeed?
>

Yes.

(66) -> homo_fact((x^2-y^2)^2)

 22 22
   (66)  [- y  + x , - y  + x ]
Type: 
List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Integer))
  Time: 0 sec

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Noncommutative factorization

[Bill Page]

On Tue, Nov 6, 2018 at 5:32 PM Bill Page  wrote:
>
> On Tue, Nov 6, 2018 at 8:35 AM Waldek Hebisch  
> wrote:
>
> > Since nobody seems to be interested in coding Davenport method
> > I did that.
> ...
> (111) -> homo_fact((x^2-1)^2)
>
>   24
>(111)  [1 - 2 x  + x ]
> Type: 
> List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Integer))
>Time: 0.00 (IN) + 0.00 (OT) = 0.00 sec

Yes I see that this is not a homogeneous polynomial so Davenport's
algorithm does not handle it correctly.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Noncommutative factorization

[Bill Page]

On Tue, Nov 6, 2018 at 8:35 AM Waldek Hebisch  wrote:
>
> > earlier patch.  Here is a revised patch that corrects this problem.
> > (Only one additional change at the  beginning.)
>
> I have tried:
>
> h3 := x*y*z - x*z*y + z*x*y - z*y*x + y*z*x - y*x*z
> factor(h3*h3)
>
> and after about hour I did not get answer.
>

Yes. This is a good example where the heuristic fails.

> Since nobody seems to be interested in coding Davenport method
> I did that.  At
>
> http://www.math.uni.wroc.pl/~hebisch/fricas/dcfact.input
> http://www.math.uni.wroc.pl/~hebisch/fricas/nc_ini04b.input
>
> dcfact.input is actual routine.  nc_ini04b.input defines needed
> types.  With that things like
>
> h2 := x*y - y*x
> homo_fact(h2*h3*h2*h3*h2)
>
> work.
>

Thanks, that is very nice. And it is impressively fast on all the
examples I tried. However it did find this example where homo_fact
fails to find a factorization:

(110) -> factor((x^2-1)^2)

   (110)  [1 - x, 1 - x, 1 + x, 1 + x]
Type: 
List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Integer))
   Time: 0.44 (EV) + 0.01 (OT) = 0.45 sec
(111) -> homo_fact((x^2-1)^2)

  24
   (111)  [1 - 2 x  + x ]
Type: 
List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Integer))
   Time: 0.00 (IN) + 0.00 (OT) = 0.00 sec

--

It is also interesting to compare the results obtained by Konrad
Schrempf's algorithm. (Start with 'nc_ini14.input' from the ncpoly
repository.)

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Noncommutative factorization

[Bill Page]

On Sun, Nov 4, 2018 at 8:03 AM Waldek Hebisch  wrote:
...
> 
> > enough.  The following patch corrects this problem:
>
> Before the patch
>
> f101 := (x*z - z*x)^2 - 2
>
> was immediately recognized as irreducible.  With the patch I did not
> get answer for several minutes (may be I am not patient enough?).
> Similarly
>
> f102 := (x*z + z*x)^2 - 2
>
> and
>
> f103 := (x^2 + x + z)^2 - 2
>

Thanks again for these great test cases. There was an error in the
'bisect' function that caused an infinite loop triggered by the
earlier patch.  Here is a revised patch that corrects this problem.
(Only one additional change at the  beginning.)

---

diff --git a/xdpolyf1.spad b/xdpolyf1.spad
index d91cf4a..cc88597 100644
--- a/xdpolyf1.spad
+++ b/xdpolyf1.spad
@@ -75,7 +75,7 @@ XDistributedPolynomialFunctions1(ALPHABET:List
Symbol, F:Join(IntegralDomain,Gcd
   remove(0,map((x:G):G+->eval(x,z)$RF,e))

 bisect(z:List Equation G, e:List G):List Equation G ==
-  if #z<2 then return z
+  if #z<2 then return []
   z1 := first(z,#z quo 2)
   if groebner(map(numer,eval(e,z)))~=[1] then return z1
   z1 := last(z,#z quo 2)
@@ -145,16 +145,25 @@ XDistributedPolynomialFunctions1(ALPHABET:List
Symbol, F:Join(IntegralDomain,Gcd

   else
 s0: List Equation G := []
-while empty? s0 for fp in v repeat
-  --output("try: ", fp::OutputForm)
-  s := solve(e1,remove(fp,v))$SystemSolvePackage(F)
-  while empty? s0 for s1 in s repeat
-m := map(explicit, s1)
-if #s1>0 and reduce(_and$Boolean, m) then s0:=s1
---output("s0: ",s0::OutputForm)
-
-if empty? s0 then
-  return [p]
+while empty? s0 repeat
+  while empty? s0 for fp in v repeat
+--output("try: ", fp::OutputForm)
+if not groebner(map(numer,e1))=[1] then
+  s := solve(e1,remove(fp,v))$SystemSolvePackage(F)
+  while empty? s0 for s1 in s repeat
+m := map(explicit, s1)
+if #s1>0 and reduce(_and$Boolean, m) then s0:=s1
+  --output("s0: ",s0::OutputForm)
+
+  if empty? s0 then
+if empty? lz then
+  return [p]
+else
+  -- try harder!
+  lz := bisect(lz,e)
+  e1 := eval(e,lz)
+  v := members set(concat map(variables, e1))$Set(Symbol)
+
 sz := concat(lz,s0)

 -- choose a parameter value to make G retractable to F

---

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Sandbox-download?

[Bill Page]

You could try  'Mathaction2Input' described very briefly here:

   http://axiom-wiki.newsynthesis.org/FriCASContributions

This script converts the source text of a mathaction (FriCAS Wiki)
page containing text, FriCAS interpreter commands, SPAD, and Aldor
library code to a form that can be directly input to FriCAS. Example:

  $ curl http://wiki.axiom-developer.org/SandBoxTest2/src | \
 ./mathaction2input > test2.input

(Click on Tangle to get the Python script.)

On Wed, Oct 31, 2018 at 1:10 PM Ray  wrote:
>
> I made a silly mistake and corrected my sandbox page without having a
> source copy.
> Is there a way to download the Sandbox page as a *.input file, aside
> from manually cut/paste?
>
> RayR

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Noncommutative factorization

[Bill Page]

On Wed, Oct 24, 2018 at 5:05 PM Waldek Hebisch  wrote:
>
> If you could find solution _in the fraction field_ then
> the method would be fine.  However, in general finding
> rational solutions to polynomial system of equations is
> uncomputable.

Can you suggest a reference? I could not find this result (well
known?) after a quick search.

> Groebner bases decide if there are solutions in
> algebraic closure, but you may have algebraic
> solutions without rational solutions.  If you say that
> you can find out if there is rational solution
> (= factorization) you should better justify this and
> explain what special properties of system you use.
>

Yes, that would be nice. Unfortunately SystemSolvePackage in FriCAS
does not make any explicit claim about completeness. But it does refer
to the method of triangular systems.

The only special property that I can think of is that the equations in
the system are at most quadratic. I do not know if that is sufficient.
Another thing is that we are only interested in finding at least one
explicit solution (if it exists).  We do not need to know all
solutions.

> Classical factorization methods (in commutative case)
> avoid uncomputability by recombining algebraic factors.
> If you do not want recombination you should say how
> you avoid uncomputability.
>

I agree.

> To be clear: your code apparently makes some
> assumptions. Both theory (uncomputablity in general
> case) an practice suggest that those assumptions may
> fail unless we can prove them.

OK.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Noncommutative factorization

[Bill Page]

> On 10/22/18 9:55 AM, Waldek Hebisch wrote:
> > I looked at noncommutative factorization code and AFAICS
> > 'xdpolyf1.spad' has serious problem.  One example is:
> >
> > (58) -> factor((x^2 - 2)*(y - 1)*(x - 1))
> >
> >  22 32
> >(58)  [- 2 + 2 y + 2 x - 2 y x + x  - x y - x  + x y x]
> > Type: 
> > List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Integer))
> >
> > that is '(x^2 - 2)*(y - 1)*(x - 1)' is treated as irreducible.
> >

Thank you for this example.  As noted in the source code the purpose
of the heuristic for finding variables that can be set to zero is to
provide a shortcut that makes the solution more efficient for larger
systems of equations but this heuristic can sometimes fail to produce
a consistent set of equations.  This is solved by considering
successively smaller subsets of variables that might be set to zero.
Your example triggers a case where the existing code fails to try hard
enough.  The following patch corrects this problem:

~/ncpoly$ git diff
diff --git a/xdpolyf1.spad b/xdpolyf1.spad
index d91cf4a..dc1d002 100644
--- a/xdpolyf1.spad
+++ b/xdpolyf1.spad
@@ -145,16 +145,24 @@ XDistributedPolynomialFunctions1(ALPHABET:List
Symbol, F:Join(IntegralDomain,Gcd

   else
 s0: List Equation G := []
-while empty? s0 for fp in v repeat
-  --output("try: ", fp::OutputForm)
-  s := solve(e1,remove(fp,v))$SystemSolvePackage(F)
-  while empty? s0 for s1 in s repeat
-m := map(explicit, s1)
-if #s1>0 and reduce(_and$Boolean, m) then s0:=s1
---output("s0: ",s0::OutputForm)
-
-if empty? s0 then
-  return [p]
+while empty? s0 repeat
+  while empty? s0 for fp in v repeat
+--output("try: ", fp::OutputForm)
+s := solve(e1,remove(fp,v))$SystemSolvePackage(F)
+while empty? s0 for s1 in s repeat
+  m := map(explicit, s1)
+  if #s1>0 and reduce(_and$Boolean, m) then s0:=s1
+  --output("s0: ",s0::OutputForm)
+
+  if empty? s0 then
+if empty? lz then
+  return [p]
+else
+  -- try harder!
+  lz := bisect(lz,e)
+  e1 := eval(e,lz)
+  v := members set(concat map(variables, e1))$Set(Symbol)
+
 sz := concat(lz,s0)

 -- choose a parameter value to make G retractable to F

with the following result:

(45) -> factor((x^2 - 2)*(y - 1)*(x - 1))

   2
   (45)  [2 - x , 1 - y, - 1 + x]
Type: 
List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Integer))
   Time: 0.00 (IN) + 0.09 (EV) + 0.01 (OT) = 0.10 sec

> > More generally, factorization via equation solving directly
> > gives absolute factorization, that is factorization over algebraic
> > closure of base field.  To get factorization over base field
> > one needs to recombine factors.

I am not convinced that this is the case.

> > IIUC 'xdpolyf1.spad' tries
> > various tricks to avoid algebraic extentions, but this is
> > very unlikely to work in general.
> >

The tricks in xdpolyf1 having nothing to do with avoiding algebraic
extensions. radicalSolve is only called if the base ring has
RadicalCategory, otherwise SystemSolvePackage only looks for solutions
in fraction field and xdpolyf1 lifts that solution to the base ring.

Are you claiming that this does not provide the most general
factorization in the base ring? Are you suggesting that if one looked
for factorizations over the algebraic closure and then recombined some
factors it might be possible to general polynomials over the base ring
that are not considered when directly solving the factorization
equations over the fraction field?

On Tue, Oct 23, 2018 at 6:47 PM Ray  wrote:

> I tried this on my saved version (part of a test -harness) and it works
> correctly.
> Here is the result
> (52) -> aa:=(x^2 - 2)*(y - 1)*(x - 1)
>
> 22 32
>(52)  - 2 + 2 y + 2 x - 2 y x + x  - x y - x  + x y x
> Type:
> XDistributedPolynomial(OrderedVariableList([x,y,z]),Fraction(MultivariatePolynomial([a,b,c,d,e],Integer)))
> (53) -> factor(aa)
>
>  2
>(53)  [- 2 + x , 1 - y, 1 - x]
> Type:
> List(XDistributedPolynomial(OrderedVariableList([x,y,z]),Fraction(MultivariatePolynomial([a,b,c,d,e],Integer
> --

Note that you are not using the same polynomial base ring as Waldek,
i.e. Fraction(MultivariatePolynomial([a,b,c,d,e],Integer))) versus
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 post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more 

Re: [fricas-devel] Giving a name to a part of an expression

[Bill Page]

Maybe this would help:

http://axiom-wiki.newsynthesis.org/ManipulatingExpressions

On Mon, Oct 1, 2018 at 2:01 PM Slawomir Kolodynski  wrote:
>
> Thank you for looking into this.
>
> >Instead, various routines analyze structure of expressions using lower level 
> >operations.
>
> Could you give some examples of those lower level operations? Pattern 
> matching and rewrite rules seem very useful to me , but I am ok with doing 
> lower level operations if those fail. I know about numerator, denominator and 
>  monomials so for example I can do
>
> e1 := (y-m)*x/s
> (monomials numerator e1)(1)
>
> to get x*y
>
> However when I try to do something similar with
>
> e2 := (y-m)*sqrt(x)/s
> numerator e2
>
> to get (y-m)*sqrt(x), I don't know how then to extract the components of this 
> product. Also, I could not find a way to extract an argument of a function, 
> for example if I have an expression
>
> sin(a*x+b)
>
> how to get the "a*x+b" part?
> Thanks,
>
> Slawomir
>

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Fwd: The free field in FriCAS :-)

[Bill Page]

On Mon, Sep 17, 2018 at 9:10 AM Ray  wrote:
> ..
> There are two forms of factoring programs.  I have a test harness
> to both; separately right now.
> In order to try things out:
> Using Konrad Schrempf's method you can do something like this
> x19:FDA :=(z+1)*(z+2)*(x-2);  +++The declaration is not optional
> factor(x19)::List(XDP)
> --- Or more surprising to me, but proves there is no cheating:
> aa:FDA := (x^6-1)*(x^6+1)
> factor(aa)::List(XDP)
> ---
> --- For Bill Page's solution
> x19:XDP :=(z+1)*(z+2)*(x-2);  +++The declaration is not optional
> factor(x19)::List(XDP)
> aa:XDP :=(x^4-1)
> factor(aa)::List(XDP) ; +++ The "List(XDP)" is not needed but I put it in
> --- for uniformity.  The x^6-1 causes a stack error in lisp.
> ---   Total bytes allocated=1072031360
> ---   Dynamic-space-size bytes =1073741824
> ---

Except as a short reference we should probably not use the phrase
"Bill Page's solution". According to Konrad the algorithm currently
implemented in XDPOLYF1 originates from a suggestion by Daniel
Smertnig. The original version was coded by Konrad as a "exercise". I
just improved the coding a little. Its main purpose is mostly
educational and as a potential aid in further developing/testing
Konrad's ALS work. Now that the ALS coding includes a complete
factoring implementation, the actual "production" version of XDPOLYF1
should just be re-written as a wrapper to FDALG.

Rewriting XDPOLYF1 would serve to answer some of Ralf's "usability"
comments. It is probably true however the FDALG itself could be
"cleaned up" a little to seem a less developer-oriented.

> I will send the git hub addresses for the testing if you want;
> I promise to put up Schrempf's test fixture on git hub today.
> It has improvements in reporting but there is something I want
> to add later.

I still think a comprehensive testsuite for FDALG and related domains
would be a valuable addition.

Bill Page.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Fwd: The free field in FriCAS :-)

[Bill Page]

On Fri, Sep 7, 2018 at 12:24 PM Konrad Schrempf wrote:
...
For Bill: If it helps to support further discussions, please put the
code on github (maybe including the mini-documentation). I guess that
it will take a while to include it in standard FriCAS. Just tell me if
you need a formal declaration for the distribution.

Is there something important I forgot? Some months ago I just claimed
that FriCAS will be the first computer algebra system being able to
work with elements in the universal field of fractions of a free
associative algebra. Now you can convince yourself. I guess that it
takes a while to get used to working with linear representations
(admissible linear systems). For small polynomials that really looks
like an overkill. But for the example on page 15 one could see the
beauty of Cohn's theory. You should try p_43^-1 ...

--

Documentation: https://github.com/billpage/ncpoly/blob/master/fdalg_20180907.pdf

Source code: https://github.com/billpage/ncpoly

Comments appreciated.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Re: -0$DFLOAT ~= 0$DFLOAT causes bug in rowEchelon

[Bill Page]

The following patch makes equality in DFLOAT conform to the IEEE 754
standard concerning equality:

"According to the IEEE 754 standard, negative zero and positive zero
should compare as equal with the usual (numerical) comparison
operators, like the == operators of C and Java. "

https://github.com/billpage/fricas/commit/cfd3150613557acfb5a7986c6561b3ee84f09727
https://github.com/billpage/fricas/commit/cfd3150613557acfb5a7986c6561b3ee84f09727.patch
--
>From cfd3150613557acfb5a7986c6561b3ee84f09727 Mon Sep 17 00:00:00 2001
From: Bill Page 
Date: Sun, 16 Sep 2018 14:57:29 -0400
Subject: [PATCH] Use EQUALP for =

---
 src/lisp/primitives.lisp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/lisp/primitives.lisp b/src/lisp/primitives.lisp
index 1b3017e4..7aed05df 100644
--- a/src/lisp/primitives.lisp
+++ b/src/lisp/primitives.lisp
@@ -284,7 +284,8 @@
 (progn
 (defmacro |less_DF| (x y) `(< (the double-float ,x)
  (the double-float ,y)))
-(defmacro |eql_DF| (x y) `(EQL (the double-float ,x)
+;; use EQUALP (or maybe just = ??) to be consistent with zero?_DF
+(defmacro |eql_DF| (x y) `(EQUALP (the double-float ,x)
  (the double-float ,y)))
 (defmacro |expt_DF_I| (x y) `(EXPT (the double-float ,x)
  (the integer ,y)))
--

This fixes the problem reported by Konrad. 'norm-out' does not find
any regressions.


On Sat, Sep 15, 2018 at 1:30 PM Bill Page  wrote:
>
> Konrad Schrempf reports the following bug:
>
> (1) -> A := matrix([[0]])$Matrix(DFLOAT)
>
>(1)  [0.0]
> Type: Matrix(DoubleFloat)
> (2) -> rowEchelon(A)
>
>(2)  [0.0]
> Type: Matrix(DoubleFloat)
> (3) -> A := matrix([[-0$DFLOAT]])
>
>(3)  [-0.0]
> Type: Matrix(DoubleFloat)
>
> (4) -> rowEchelon(A)
>
>>> Error detected within library code:
>not invertible
>
> (5) -> zero?(-0$DFLOAT)
>
>(5)  true
> Type: Boolean
> (6) -> zero?(0$DFLOAT)
>
>(6)  true
> Type: Boolean
> (7) -> (-0$DFLOAT ~= 0$DFLOAT)@Boolean
>
>(7)  true

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] -0$DFLOAT ~= 0$DFLOAT causes bug in rowEchelon

[Bill Page]

Konrad Schrempf reports the following bug:

(1) -> A := matrix([[0]])$Matrix(DFLOAT)

   (1)  [0.0]
Type: Matrix(DoubleFloat)
(2) -> rowEchelon(A)

   (2)  [0.0]
Type: Matrix(DoubleFloat)
(3) -> A := matrix([[-0$DFLOAT]])

   (3)  [-0.0]
Type: Matrix(DoubleFloat)

(4) -> rowEchelon(A)

   >> Error detected within library code:
   not invertible

(5) -> zero?(-0$DFLOAT)

   (5)  true
Type: Boolean
(6) -> zero?(0$DFLOAT)

   (6)  true
Type: Boolean
(7) -> (-0$DFLOAT ~= 0$DFLOAT)@Boolean

   (7)  true

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] XDistributedPolynomialFunctions1 - factor

[Bill Page]

I have cc'd this to the FriCAS list in hopes of getting more feedback.

On Wed, Jul 18, 2018 at 3:19 PM, Raymond Rogers
 wrote:
> Finally got back to this.  Success and (3*x*y+5*y*x)^3 takes
> almost  exactly the same amount of time with your process and
> mine.
> Some organization questions.

> 1) I downloaded the ncpoly package from github and there seems to be a wide
> discrepancy between nc_ini04.input between the two; so I used your attached
> one.  The attached works fine.

> 2) The xdpoly_fact.input had a XDP assignment p_1 before function
>definition but I just commented it out.

No problem. This is just temporary initialization for test/development
anyway. We really need a proper testsuite-style input file to include
in the distribution.

> 3) I can't
> )trace factor
> I presume that this buried some way.

?? buried ??  I almost never use )trace so maybe this isn't quite what
you meant. First note that in this case 'factor' is not exported by a
domain but rather it is a function/operator exported by the package
called XDPOLYF1.

This seems to work:

(45) -> )trace XDPOLYF1 )ops factor

   Packages traced:
  XDistributedPolynomialFunctions1([x,y,z,w,x1,x2,x3,x4,x5],
Integer)
   Parameterized constructors traced:
  XDPOLYF1

(45) -> factor f10
 1exit  XDistributedPolynomialFunctions1.factor,142 : #1=(1 . 1)
   #2=(2 . 1))
  . -1)
 (NIL . 1))
2 . 1) #1#) . 1)
 (NIL . 2))
(((#2# (3 . 1)) . -1)
 (NIL . 3))
3 . 1) #2#) . -1)
 (NIL . 2))
(((#1# (3 . 1)) . -1)
 (NIL . 1)))

   (45)  [1 - x y, 2 + y x, 3 - y z, 2 - z y, 1 - x z]
Type: 
List(XDistributedPolynomial(OrderedVariableList([x,y,z,w,x1,x2,x3,x4,x5]),Integer))
   Time: 0.70 (EV) = 0.70 sec
(46) ->


> Should I write a factor wrapper
> factor_1 (probably three lines) to use trace timing although that
> won't allow me to peek inside but I don't particularly want to if it
> works.

I am not sure. You might be able to get better advice from other
people who are more familiar with using the )trace facilities.

> 4) Your f10 seems to have a problem; have you resolved it or do
> you think it's intrinsic?

The main limitation has to do with the total number of equations (>> 1000).

> I keep hoping to think of some trick to get my extended
> polynomial and things like f10 under control.
>  "no joy in Mudville"
>

The code that I committed yesterday to ncpoly on github yesterday
contains a heuristic that allows the f10 example to be computed in a
few seconds. It seems that using this technique it is possible to
factor dense non-commutative polynomials up to at least degree 10.
Some sparse polynomials of higher degree also work but it seems easy
generate examples that fail or take too long (> 5 minutes).

> Finally, my mind pulled up some references from the distant past:
> Integral Matrices by Morris Newman and my Generating Function work.
> It amazing how similar the equations and procedures are to Konrad's
> references.
> Unfortunately Morris's relevant development seems concentrated on
> commutative Principal Ideal Rings whereas the nc_poly theory is based
> on noncommunative Principal Ideal Rings (which I really hope is proved
> somewhere in the references).
> In any case I will get back to the test harness construction shortly.
> Probably not for a couple of days, I am going to try out using a SSD
> and usually manage to expand an hours worth of work to days.  I'll
> see.
>

As I see it, the xdpoly stuff is mostly separate from Konrad's ncpoly
domain but it may be useful for testing and as a benchmark.

> Are you going to push your recent coding to github?
>

See:

https://github.com/billpage/ncpoly/blob/master/xdpolyf1.spad

Please pull the new version.  I have also included a lot more comments
in the code.  I would be happy to receive comments and questions.

Bill Page.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] )trace )stats reset -- abort s xx.input?

[Bill Page]

On Sun, Jul 15, 2018 at 6:37 PM, Bill Page  wrote:
>
> It seems that UNTRACE-2 was replaced by untrace2 in this commit
>
> https://github.com/fricas/fricas/commit/546108f1b65acadc38fc7d243b1b29770b6a770a
>
> https://github.com/fricas/fricas/blame/546108f1b65acadc38fc7d243b1b29770b6a770a/src/interp/trace.boot#L387
>
> but apparently this reference to UNTRACE-2 was missed.
>
>
> On Sun, Jul 15, 2018 at 5:31 PM, Raymond Rogers  
> wrote:
>>
>> Found the call to UNTRACE-2
>> Overall examining make.lst is pretty depressing.  If nobody is going to fix 
>> (or explain) this then I will try  another lisp.

I don't think there is anything wrong with your lisp or with your
compiled version of FriCAS.

Here is a patch for the UNTRACE-2 problem:

--

diff --git a/src/interp/slam.boot b/src/interp/slam.boot
index 3787ae0d..26208d5b 100644
--- a/src/interp/slam.boot
+++ b/src/interp/slam.boot
@@ -288,7 +288,7 @@ mkCacheVec(op,nam,kind,resetCode,countCode) ==
 clearCache x ==
   get(x,'localModemap,$e) or get(x,'mapBody,$e) =>
 for [map,:sub] in $mapSubNameAlist repeat
-  map=x => _/UNTRACE_-2(sub,NIL)
+  map=x => untrace2(sub,[])
 $e:= putHist(x,'localModemap,nil,$e)
 $e:= putHist(x,'mapBody,nil,$e)
 $e:= putHist(x,'localVars,nil,$e)

--

You did not say specifically what you did to cause the error message
(maybe something like ')clear completely' or something like that?) so
I could not verify the fix.  But at least it no longer issues that
message.

>> ..
>> It would seem that whatever decides to compile functions missed this call.

It was just an oversight.

>> Other uncompiled functions from make.lst
>>
>> ; compilation unit finished
>> ;   Undefined functions:
>> ; /UNTRACE-2 COPY EQSUBSTLIST GENVAR HKEYS INTERNL LASSOC LIST2REFVEC 
>> MKQ |NRTisRecurrenceRelation| SETDIFFERENCE STRINGIMAGE |bright| 
>> |compQuietly| |eval| |get| |keyedSystemError| 
>> |makeInternalMapMinivectorName| |mkAuxiliaryName| |mkCacheName| |pp| |put| 
>> |putHist| |sayBrightlyI| |sayKeyedMsg| |startTimingProcess| 
>> |stopTimingProcess| |substitute| |throwKeyedMsg| |timedOptimization|
>> ;   Undefined variables:
>> ; |$InteractiveMode| |$TriangleVariableList| |$cacheAlist| |$cacheCount| 
>> |$compileRecurrence| |$compiledOpNameList| |$compilingInputFile| |$e| 
>> |$failed| |$functorDependencyAlist| |$mapSubNameAlist| |$minivector| 
>> |$minivectorCode| |$minivectorNames| |$reportCompilation|
>> ;   caught 19 WARNING conditions
>> ;   caught 46 STYLE-WARNING conditions
>> ;   printed 3 notes
>>

As far as I can see only the first one was really a missing function.
The others are just defined in other source files.

> ...
>> On 07/15/2018 12:12 AM, oldk1331 wrote:
>>>
>>> It seems this function is indeed undefined, so not a lisp problem.
>>> Can you describe how to trigger this error?
>>>

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] )trace )stats reset -- abort s xx.input?

[Bill Page]

It seems that UNTRACE-2 was replaced by untrace2 in this commit

https://github.com/fricas/fricas/commit/546108f1b65acadc38fc7d243b1b29770b6a770a

https://github.com/fricas/fricas/blame/546108f1b65acadc38fc7d243b1b29770b6a770a/src/interp/trace.boot#L387

but apparently this reference to UNTRACE-2 was missed.


On Sun, Jul 15, 2018 at 5:31 PM, Raymond Rogers 
wrote:

> Found the call to UNTRACE-2
> Overall examining make.lst is pretty depressing.  If nobody is going to
> fix (or explain) this then I will try  another lisp.
> Of course,
>
> -
> Fricas 1.3.4
>
> sbcl 1.4.5
>
> 
> src/interp/slam.clisp: ((EQUAL |map| |x|) (IDENTITY
> (/UNTRACE-2 |sub| NIL)))
> Context:
>
> clearCache x ==
>   get(x,'localModemap,$e) or get(x,'mapBody,$e) =>
> for [map,:sub] in $mapSubNameAlist repeat
>   map=x => _/UNTRACE_-2(sub,NIL)
> $e:= putHist(x,'localModemap,nil,$e)
> $e:= putHist(x,'mapBody,nil,$e)
> $e:= putHist(x,'localVars,nil,$e)
> sayKeyedMsg("S2IX0007",[x])
>
> It would seem that whatever decides to compile functions missed this call.
> Other uncompiled functions from make.lst
>
> ; compilation unit finished
> ;   Undefined functions:
> ; /UNTRACE-2 COPY EQSUBSTLIST GENVAR HKEYS INTERNL LASSOC LIST2REFVEC
> MKQ |NRTisRecurrenceRelation| SETDIFFERENCE STRINGIMAGE |bright|
> |compQuietly| |eval| |get| |keyedSystemError| |makeInternalMapMinivectorName|
> |mkAuxiliaryName| |mkCacheName| |pp| |put| |putHist| |sayBrightlyI|
> |sayKeyedMsg| |startTimingProcess| |stopTimingProcess| |substitute|
> |throwKeyedMsg| |timedOptimization|
> ;   Undefined variables:
> ; |$InteractiveMode| |$TriangleVariableList| |$cacheAlist|
> |$cacheCount| |$compileRecurrence| |$compiledOpNameList|
> |$compilingInputFile| |$e| |$failed| |$functorDependencyAlist|
> |$mapSubNameAlist| |$minivector| |$minivectorCode| |$minivectorNames|
> |$reportCompilation|
> ;   caught 19 WARNING conditions
> ;   caught 46 STYLE-WARNING conditions
> ;   printed 3 notes
>
>
>
>
> Ray
>
>
>
> On 07/15/2018 12:12 AM, oldk1331 wrote:
>
>> On Sun, Jul 15, 2018 at 10:58 AM, Raymond Rogers
>>  wrote:
>>
>>> Hi, Since there is a certain flakiness that occurs in my system.  I
>>> decided
>>> to check the installation.  The compile configuration picked up sbcl
>>> 1.4.5;
>>> but I get this error during program runs involving tracing:
>>>
 System error:
>
 The function BOOT::/UNTRACE-2 is undefined.
>>>
>>> I recompiled and have the make file output, and, in fact, it has
>>> UNTRACE-2
>>> as undefined.  Does this indicate I have a bad lisp or some such?
>>>
>> It seems this function is indeed undefined, so not a lisp problem.
>> Can you describe how to trigger this error?
>>
>>
>>
> --
> 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.
> Visit this group at https://groups.google.com/group/fricas-devel.
> 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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] first and last are "BOTH a variable and a literal"

[Bill Page]

On Thu, Jul 12, 2018 at 8:00 AM, Bill Page  wrote:

> Actually the message "Semantic Errors" occurs 35 times during a
> normal successful build of FriCAS. Many but not all of these are
> due to something being "BOTH a variable and a literal". Clearly
> these are not really "errors". At most this might be just a helpful
> warning but I cannot see any situation in SPAD where treating
> something as both a variable and a literal ...

could cause a problem.

> In fact it is not really clear what might be
> meant by this message.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] first and last are "BOTH a variable and a literal"

[Bill Page]

Actually the message "Semantic Errors" occurs 35 times during a normal
successful build of FriCAS. Many but not all of these are due to
something being "BOTH a variable and a literal". Clearly these are not
really "errors". At most this might be just a helpful warning but I
cannot see any situation in SPAD where treating something as both a
variable and a literal. In fact it is not really clear what might be
meant by this message.

According to the build log there are 56 instances of using a symbol as
both a variable and a literal:

 algebraicGcd2:  pss1 is BOTH a variable and a literal
 algebraicGcd3a:  pss1 is BOTH a variable and a literal
 coerce:  arrows is BOTH a variable and a literal
 common:  contents is BOTH a variable and a literal
 common:  name is BOTH a variable and a literal
 createSceneArrow:  en is BOTH a variable and a literal
 createSceneArrow:  mode is BOTH a variable and a literal
 createSceneArrow:  offset is BOTH a variable and a literal
 createSceneArrow:  size is BOTH a variable and a literal
 createSceneArrows:  mode is BOTH a variable and a literal
 createSceneArrows:  size is BOTH a variable and a literal
 createSceneArrow:  st is BOTH a variable and a literal
 createSceneLine:  en is BOTH a variable and a literal
 createSceneLine:  st is BOTH a variable and a literal
 createSceneNamedPoints:  np is BOTH a variable and a literal
 ddfact:  degree is BOTH a variable and a literal
 ddFact:  degree is BOTH a variable and a literal
 ddfactor:  degree is BOTH a variable and a literal
 do_poly_integer0:  pss1 is BOTH a variable and a literal
 eval:  a is BOTH a variable and a literal
 eval_and_solve:  pss1 is BOTH a variable and a literal
 eval:  b is BOTH a variable and a literal
 eval:  c is BOTH a variable and a literal
 eval:  d is BOTH a variable and a literal
 factorUP:  x is BOTH a variable and a literal
 factor:  x is BOTH a variable and a literal
 factor:  y is BOTH a variable and a literal
 finitePoset:  struct1 is BOTH a variable and a literal
 FloatingPointSystem: struct1 is BOTH a variable and a literal
 forLoop:  body is BOTH a variable and a literal
 gen_exp:  x is BOTH a variable and a literal
 gen_exp:  y is BOTH a variable and a literal
 HANKP: rels is BOTH a variable and a literal
 inferFromRelations:  rels is BOTH a variable and a literal
 jacobi2polypq :  a is BOTH a variable and a literal
 jacobi2polypq :  b is BOTH a variable and a literal
 jacobi2polypq : c is BOTH a variable and a literal
 jacobi2polypq : d is BOTH a variable and a literal
 lift_rightfactor:  x is BOTH a variable and a literal
 listream_coefsop:  x is BOTH a variable and a literal
 monomials1:  c is BOTH a variable and a literal
 monomials1:  k is BOTH a variable and a literal
 mul is BOTH a variable and a literal
 orientedFacet:  mul is BOTH a variable and a literal
 proportional?:  a is BOTH a variable and a literal
 proportional?:  b is BOTH a variable and a literal
 proportional?:  c is BOTH a variable and a literal
 proportional?:  d is BOTH a variable and a literal
 ramification_of:  x is BOTH a variable and a literal
 reducedSystem:  vec is BOTH a variable and a literal
 relatorTables:  rels is BOTH a variable and a literal
 separateFactors:  degree is BOTH a variable and a literal
 sepFact1:  degree is BOTH a variable and a literal
 sepfact:  degree is BOTH a variable and a literal
 validate:  last is BOTH a variable and a literal
 xmlAttribute:  value is BOTH a variable and a literal

--

These function names before the : above are not so useful but it would
have been a bit difficult to extract actual file names from the grep.
Anyway, the point is that if these really are not errors, then the
compiler should not flag them as such.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] first and last are "BOTH a variable and a literal"

[Bill Page]

On Wed, Jul 11, 2018 at 4:14 PM, Raymond Rogers
 wrote:
> On 07/11/2018 03:15 PM, Bill Page wrote:
> ...
> If I replace 'first' with a different name e.g. 'first2' and 'last'
> with 'last2' then there are no such errors. So far as I know
> 'first' and 'last' are not reserved words in spad.
>

It seems like 'first' and 'last' are imported as literals from the
List domain where they are used in 'elt' to provide the notation
'x.first' and 'x.last'. These are exactly equivalent to the functions
'first x' and 'last x' also exported by List.

> In other contexts "first" and "last" are list operators, getting
> the first and last item; or in some cases a pointer.  They work
> as operators  in fricas.

Yes of course. These are operators that are exported by the List
domain constructor.  The List domain constructor also exports another
other called 'elt' which can also be denoted by just a '.'. 'x.last'
is exactly equivalent to 'elt(x,last)'.

> I would avoid trying to use them as literals

FriCAS already uses them as literals. In my code I did not use them as
literals but I did define new functions with the same name. This
triggered the error message because I also use variables of type
'List'.

> and think they should be reserved and defined.

I disagree.

> Personally I wouldn't trust "overloading" them either.

Why? FriCAS does this extensively.

> Basically I think that they come down (up?) from Lisp.
>

No, that is not the case.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] first and last are "BOTH a variable and a literal"

[Bill Page]

If I use the names 'first' and 'last' in a spad file I get a message:

   Semantic Errors:
  [1]  last is BOTH a variable and a literal
  [2]  first is BOTH a variable and a literal
  ...

What does this mean? In spite of the "semantic error" the code
compiles and runs as expected.

If I replace 'first' with a different name e.g. 'first2' and 'last'
with 'last2' then there are no such errors. So far as I know 'first'
and 'last' are not reserved words in 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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Intepreter: type declaration ignored in == AND: BOOT::|sayFunctionDeps| is undefined.

[Bill Page]

On Wed, Jul 11, 2018 at 9:53 AM, Riccardo GUIDA
 wrote:
>
> Hi, thanks for the feedback.
>

Actually, thank you for the feedback.

>
> [Bill]> Although this terminology is used in a few places,
>
> "... a few places"? Well, I would say "almost everywhere":
> Jenks Sutor vol 0, hyperdoc, fricasUG, mathaction ...
>

OK, point taken.

>
> A mystery is that according to the interpreter messages there are
> "interpreter functions" and "interpreter rules", so one might wonder if
>there are different, undocumented syntaxes and semantics:
> ...

Yes, probably. The FriCAS interpreter and the SPAD compiler, not to
mention the Aldor compiler, where all written by different people at
different times during the original Axiom research project at IBM.
There is a tendency to approach the interpreter as if it were just a
read-eval-print loop for the compiler but as you have seen this is not
the case. Rather, what happened is that these rather different systems
where "interfaced" in what the developers hoped was a more-or-less
seamless way.

>
> ... I'm starting to believe that the only way for a user to grasp how
> the interpreter works in many cases is to (learn boot & lisp and)
> read the source files ... quite time consuming task ... sigh ...
>

I think it is almost universally agreed among the FriCAS developers
and many users that the interpreter has many flaws and was written in
a manner that does not encourage incremental improvements. There has
been a long expressed desire to re-write the interpreter in SPAD (or
maybe Aldor) but there has also been a persistent lack of resources in
the open source project.

>
>
> I'm also disturbed by the fact that a (fool) user can happily
> hide a library operation like +. I would have preferred to be
> obliged to write something like
>
> IAmNotInsaneAndIReallyWantToRedefine(_+)
>
> before being able to redefine.
>

Agreed. In fact the library operation is not hidden as such

(1) -> (1+1)==3
   Type: Void
(2) -> (1+1)$Integer

   (2)  2
Type: Integer

But the interpreter rule does take precedence over any library
function of the same name. I think it might be better if it was
necessary for the user to explicitly state a preference.

>
> [ric]> (2) -> y:Integer == 1
>
> [Oldk1331]> This is a strange way to input in FriCAS,
> it actually defined a rule for ':'
>

This should be considered a bug in the interpreter.

> Well, I had the (unwise) idea of approaching FriCAS by
> first reading the whole AldorUG, so my test was Aldor-inspired [1]
>

I presume that you expected

  y:Integer == 1

and

  y:Integer
  y == 1

to produce the same results. But the rule is that things on the left
hand side of == are not evaluated - not even the apparent declaration
: !! Probably this should not be the case for :. Instead it should at
least evaluate declarations on the left and return the symbol before
evaluating the rule.

To some extent Aldor was intended to fix what was wrong with the SPAD
compiler, but you should consider it even farther from the interpreter
than 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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Intepreter: type declaration ignored in == AND: BOOT::|sayFunctionDeps| is undefined.

[Bill Page]

On Tue, Jul 10, 2018 at 11:51 AM, Riccardo GUIDA
 wrote:
>
> Command line interpreter: I realize that type declaration is ignored
> in delayed assignment == even for variables (see [1] for a similar
> behavior for functions)
>
> Same behavior from .input file.
>

Although this terminology is used in a few places, I do not think it
is correct to call == delayed assignment. Rather it only represents
kind of function definition via matching (which granted, does involve
some form of delayed assignment). More specifically in the interpreter
== defines a "rule". In the case of ==, : is an operator like any
other. E.g.

(1) -> (x+y) == 3
   Type: Void
(2) -> (x:Integer) == 4
   Type: Void
(3) -> )display value +
   Definition:   + (x, y) == 3
(3) -> )display value :
   Definition:   : (x, Integer) == 4
(3) -> x+y
   Compiling function + with type (Variable(x), Variable(y)) ->
  PositiveInteger

   (3)  3
Type: PositiveInteger
(4) -> x:Integer
   Type: Void

Only the last result is a bit anomalous. One might have expected the
value 4 but without the == the interpreter is treating this like a
declaration rather than an expression.

As illustrated in the users guide, this sort of matching in the
interpreter is useful for defining functions by cases etc. But I think
it can produce rather surprising and unexpected effects. E.g.

(4) -> 1+1 == 3
   Type: Void
(5) -> 1+1
   Compiling function + with type (PositiveInteger, PositiveInteger)
   -> PositiveInteger

   (5)  3
Type: PositiveInteger

(6) -> 1+2

   The function + is not defined for the given argument(s).

This is very unlike the semantics implemented implemented in the
library compiler.  In spite of this, the interpreter does otherwise
manage to interface with the FriCAS library quite well.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Re: InputForm again

[Bill Page]

On Mon, Jul 9, 2018 at 7:57 AM, 'Martin R' via FriCAS - computer
algebra system  wrote:
> I should add: I am well aware that I asked this question before,
> for example in
>
> https://groups.google.com/forum/#!topicsearchin/fricas-devel/inputform/fricas-devel/EDdvs1MaJNA
>
> but the answers back then were not really helpful.
>

After reviewing that thread I find that I did and still do agree with
your approach.

> Thus, given the renewed interest on the sage side, I am simply hoping
> that opinions changed.  Of course, I would do the work. I only want to
> avoid to do the work and then get a "no" afterwards.
>

I am willing to help, although as usual time is limited.  The
difficulty of course is that this is not just a simple addition of
some independent domain/package to FriCAS. It actually affects nearly
all domains is the system. Still it might be more desired by some
other developers to avoid changes to InputForm as such and create such
an independent domain specifically for exchange with external systems,
say: ExternalForm. But still this would affect all other domains to
provide a coercion to ExternalForm.

It would be nice if there were some way to add a default
implementation of some conversion to ExternalForm to a category such
as SetCategory or BasicType that would automatically filter down to
all the underlying domains but right now I cannot think of anyway to
do this. Of course all values in FriCAS are Lisp values. Maybe
something is possible at this level? How well would it work to export
raw Lisp values for every domain? Just thinking out loud ...

> I guess, an alternative might be a friendly (!)  "fork".
>

Anyone can declare a fork. For example this happens by design every
time someone clones a repository in github. But the real issue is
maintenance and commitment. Usually both of these are insufficient for
real collaboration to grow.  If the purpose is a fork specifically for
some flavor of FriCAS/Axiom in Sage maybe this is possible since Sage
has potentially a much larger user/developer base. But frankly, I have
not seen any evidence of that much interest in FriCAS among Sage
users. Perhaps you are aware of other working going on behind the
scenes.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] interoperability with sage again

[Bill Page]

On Sat, Jul 7, 2018 at 6:00 AM, 'Martin R' via FriCAS - computer
algebra system  wrote:
> Can I do anything to facilitate inclusion in FriCAS?
>

Of course just submit a patch. Such as what you attached to your
original message. :)

> It would be relatively urgent, because it holds up other stuff and I cannot
> see how to work around this.  So I'd be extremely grateful if it would make
> it into the next release.
>

In your first message you wrote:

...

> (53) -> f::INFORM
>
>(53)
>(%defprod  (+ (%defsum (/ 1 (+ %LW 2)) %LW (*01000s 10) 0 (+ %LX - 1)) 1)
> %LX  (*01000p 11)  0  (+ n - 1))
>   Type:
> InputForm
>
> As you can see, the summation variables have subscripts.  However,
> the string representation of the InputForm of scripted symbols does
> not allow to reproduce the symbol.

Although I am very much in favor of improving the coding for
InputForm, I note what you wrote above is strictly speaking not true.

(*01000s 10) and (*01000p 11)

do contain all the information you need to reconstruct the s_{10} and
p_{11} subscripts. Could process *01000s as a function that takes one
argument 10 and produces a subscripted symbol s, etc.  In the past I
have done this in FriCAS internally when wanting to interpret
InputForm expressions.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] interpreter (command line): syntax of "rule"

[Bill Page]

On Thu, Jul 5, 2018 at 12:20 PM, Riccardo GUIDA
 wrote:
> Hi
>
> I do not understand how the syntax
>
> rule sin(x) == x  -- see (1) below
>
> is accommodated to fit in the signature
> (EXPR(INT), EXPR(INT)) -> RULE(INT,INT,EXPR(INT))
> see fricas message below
>
> In other words: in (1) I do not see a call to a function "rule" of two
> parameters, rule(f,g): what's happening? Is this an interpreter (command
> line) language construct that has nothing to do with standard function call
> of type  rule(f,g)?
>
> Can one rewrite (1) as an equivalent function call rule(f,g) for some f,g?

The syntax in (1) is a little bit of interpreter "magic".  It is just
sugar for (2)

(1) -> rule sin(x) == x

   (1)  sin(x) == x
   Type: RewriteRule(Integer,Integer,Expression(Integer))
(2) -> _rule(sin('x),'x)

   (2)  sin(x) == x
   Type: RewriteRule(Integer,Integer,Expression(Integer))

The escape symbel _ is necessary in order to defeat the magic.

See also some other possibly useful functions in the RewriteRule,
Ruleset and Pattern domains. Eg,

(3) -> )sh RewriteRule
 RewriteRule(Base: SetCategory,R:
Join(Ring,PatternMatchable(Base),Comparable,ConvertibleTo(Pattern(Base))),F:
Join(FunctionSpace(R),PatternMatchable(Base),ConvertibleTo(Pattern(Base
is a domain constructor
 Abbreviation for RewriteRule is RULE
 This constructor is exposed in this frame.
--- Operations 

 ?=? : (%, %) -> Boolean   coerce : Equation(F) -> %
 coerce : % -> OutputForm  ?.? : (%, F) -> F
 hash : % -> SingleInteger latex : % -> String
 lhs : % -> F  pattern : % -> Pattern(Base)
 retract : % -> Equation(F)rhs : % -> F
 rule : (F, F, List(Symbol)) -> %  rule : (F, F) -> %
 ?~=? : (%, %) -> Boolean
 elt : (%, F, PositiveInteger) -> F
 hashUpdate! : (HashState, %) -> HashState
 quotedOperators : % -> List(Symbol)
 retractIfCan : % -> Union(Equation(F),"failed")
 suchThat : (%, List(Symbol), (List(F) -> Boolean)) -> %

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] interoperability with sage again

[Bill Page]

On Thu, Jul 5, 2018 at 11:31 AM, Ralf Hemmecke  wrote:
>
> I think that going via InputForm is not the right way to do such a
> conversion from FriCAS Expression(INT) into a Sage expression.
>

I disagree.

> Wouldn't it be wiser to add functions to Expression in order to
> decompose an element.

No, not in the case of the Sage interface to FriCAS.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] interoperability with sage again

[Bill Page]

On Thu, Jul 5, 2018 at 11:17 AM, 'Martin R' via FriCAS - computer
algebra system  wrote:
>
> Would it be possible to change that to something like the following
> (WARNING: only lightly tested!).

+1

> Two comments:
>
> 1) The scripts are of type OutputForm, but there is no way to get an
> InputForm from an OutputForm.  So the below will not work always, but only
> when the input is reasonable.  In fact
> interpret convert subscript('s, [z^2]) works...
>
> 2) There seems to be a problem when the subscript has a value.  For example,
> x := subscript('s, ['x^2]) produces an error about cons'ing InputForm with
> InputForm.  Not sure what's happening there.
>
> Best wishes,
>
> Martin
>
> Code:
>
> convert(s: Symbol): InputForm ==
> not scripted? s => convert(name s)$InputForm
>
> ls := scripts s
> A: List InputForm := [e pretend InputForm for e in ls.sub]
> B: List InputForm := [e pretend InputForm for e in ls.sup]
> C: List InputForm := [e pretend InputForm for e in ls.presup]
> D: List InputForm := [e pretend InputForm for e in ls.presub]
> E: List InputForm := [e pretend InputForm for e in ls.args]
> a: InputForm := convert('script)
> b: InputForm := convert name s
> c: InputForm := cons(convert('construct), [cons(convert('construct), e)
> for e in [A, B, C, D, E]])
> convert([a, b, c])
>
> --

I think this is a very good idea.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] E has (1:( ) -> E) does not work

[Bill Page]

Maybe like this:

(1) -> Integer has Zero:()->Integer

   (1)  true
Type: Boolean
(2) -> Integer has One:()->Integer

   (2)  true
Type: Boolean


As I recall 0 is just a pretty way to write Zero and 1 is just a
pretty way to write One.

On Thu, Jul 5, 2018 at 11:07 AM, Prof. Dr. Johannes Grabmeier privat
 wrote:
> What is the proper way to qualify a type E to have a constant or a
> function with no variables?
> Other functions work well, here are examples from the algebra code.
>
>
> if R has imaginary : () -> R then
>
> if SMPF has _*: (NonNegativeInteger, SMPF) -> SMPF
>
> if Coef has "*": (Expon,Coef) -> Coef then
>
> Was not aware that both "*" and _* are allowed for infix functions.
>
>
>
> 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
> Tel. +49-(0)-991-3615-141 (d),  Fax: +49-(0)-32224-192688
>
> --
> 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.
> Visit this group at https://groups.google.com/group/fricas-devel.
> 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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] ncpoly -- "map" problem

[Bill Page]

On Mon, Jul 2, 2018 at 10:20 PM, Raymond Rogers
 wrote:
> Bill,  Okay that works.
> Newbie question: why?  I thought I was specifying the incoming data type.

You have already specified the incoming (and outgoing) data type by writing:

  factor_test : (XDP,LIST(NCP))-> BOOLEAN

Note: BOOLEAN is the "abbreviation" of the actual domain name Boolean.

But alternatively you could just include the types in the function definition:

  factor_test(x:XDP , y:LIST(NCP)):Boolean  ==

But you must use : not :: on the parameter. Double colon means "coerce
to type", it does not specify the type of a variable or parameter.

> Thanks for the more extensive response earlier; although at this stage
> "commit" makes me laugh :)
> I will try github.
>

Think "commitment" when you read "commit". :)

Bill.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] ncpoly -- "map" problem

[Bill Page]

Raymond,

Sorry for the delayed response. Perhaps you have already discovered
the solution.

The line:

  factor_test(x::XDP , y::LIST(NCP))  ==

should actually read:

  factor_test(x , y)  ==

--

Bill Page.

On Wed, Jun 20, 2018 at 1:35 PM, Raymond Rogers
 wrote:
> If anybody is running the ncpoly/non-commuting code:
> While familiarizing myself with the coding and theory, I have run into a
> simple syntax problem.
> I have attached the changed files and the problem code is in (?)
> test.input
> The function factor_test() stalls on the "map()" line; whereas when I do the
> same things manually
>
> #map(rank,f_12)
> for i in 1..n repeat m:=m*(fct_12(i)::XDP)
>
> works fine.
>
> In particular
> -- Factor test
> --
> --
> factor_test : (XDP,LIST(NCP))-> BOOLEAN
> factor_test(x::XDP , y::LIST(NCP))  ==
>  m:=1::XDP;
>  n:=#map(rank,y)
>  for i in 1..n repeat m:=m*(y(i)::XDP)
>  test(x = m)
> --
> Which was supposed to automate the checking in the prior last line of
> test.input
>
> test(p_12 :: XDP = fct_12(1)::XDP * fct_12(2)::XDP)
>
> to allow variable problem sizes
> like so
>
> factor_test(p_12::XDP,fct_12::LIST(NCP))
>
>
> --
> 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.
> Visit this group at https://groups.google.com/group/fricas-devel.
> 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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Re: ncpoly test harness

[Bill Page]

Raymond,

I am sorry that it has taken me so long to get back to this project.
My only excuse is that summer is finally here in Canada and there seem
to many other things that occupy my attention. I am of course still
very interested and enthusiastic about this work.

On Sat, Jun 23, 2018 at 2:09 PM, Raymond Rogers
 wrote:
>
> 1) Your change of header for symbolic coefficients seems to work great!

The point is of course that the F may be any Field that you choose,
including rational functions over some other alphabet. This other
alphabet then represents parameters.

Actually, I find it a bit unnatural that NCPOLY expects a Field.
Usually polynomials are defined over just a ring.  Maybe this is just
carried over from the original focus on free non-commutative fields.
I will look closer at that. @Konrad: Any comments?

> 2) Attached is a tar collection that I think implements a test fixture for
> running NCP test sequences.

Thank you. I have added your code as the initial commit to a new
branch named 'raymond' at

https://github.com/billpage/ncpoly/tree/raymond

I would encourage you to continue development using git/github and
especially to use github issues to document problems and to make
suggestions.

https://github.com/billpage/ncpoly/issues

If you have any problems or questions about using github just let me
know.  If you want you can still send changes to me and I can put them
in the repository for you but it is not a hard thing to do yourself
once you get started. I do find the integrated github comment and
issue system to be very useful to keep track of what is going on when
collaborating with others.

> 3)nc_ini03-a.input is a hashed up collection of what I think is needed.
>I will take out the commented sections if you agree.

OK. One advantage of using version control like git is that you can
always see older versions when you want to so you don't need to keep
many historical comments in the source.

> 4) I  would like you to look at the README to see if it makes sense.  I do
> know, you probably don't need it.

It looks good to me.  For convenience I might suggest changing it from
.txt to .md to provide some minimal formatting.  I can do that if you
like.

> 5) I will start adding tests and cleaning things up if there are
> no corrections and everybody agrees (fat chance :-) ).

At the moment "everybody" is a rather small group :) so I think you
can proceed as you like.

> 6) Missing is an output that collects pass/fail in a nice format.
> Examples/suggestions please.
>

I strongly suggest that you take a look at the Unittest package. Here
is a good example: 'fricas/src/input/integ.input'.  Running

  (1) -> )r fricas/src/input/integ.input

produces:

...
   =
   Testsuite: integ
 failed (total): 0 (383)

   =
   testsuite | testcases: failed (total) | tests: failed (total)
   integ   0   (383)   0  (1144)
   =
   File summary.
   unexpected failures: 0
   expected failures: 12
   unexpected passes: 0
   total tests: 1144
--

If we could use what you have so far and incorporate it into a
Testsuite like this I think that would be great!

> Of course I welcome anybody who wants to try it.
> If there is no interest I will just drop the whole testing thing,

I hope you don't decide to do that. Testing is often more important
that writing the original code itself.

> and look at including inverse() and other more interesting things.
>

But by all means let's also continue to do more interesting things. :-)

Bill.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Re: TEXmacs as interface

[Bill Page]

On Sun, Jul 1, 2018 at 4:55 PM, Kurt Pagani  wrote:
> ...
> I've attached my config in a pdf, maybe it will help you to find the error.

Kurt,

I took a quick look at you config file but haven't had a chance yet to
compare it to the one distributed with FriCAS.  Have you made many
improvements and/or extensions?  If so, it would be nice to get these
into the distribution.

Thanks.

Bill.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [fricas-devel] unique Value of Void

[Bill Page]

On Sat, Jun 30, 2018 at 11:30 AM, Waldek Hebisch
 wrote:
> Bill Page wrote:
>> >
>> > Well, advantage is consistency with rules.
>> >
>>
>> Could you site specifically what rule is being violated?
>
> The one that Ricardo was asking about: that 'if' always works,
> but for one armed 'if' you get Void as a type.
>
>> ...
>> In fact the Spad compiler does not always do what I had hoped. For
>> example compiling the following function using Spad:
>>
>>   f(x:Integer):PositiveInteger == if x<1 then 1
>>
>> --
>>
>> (1) -> f(0)
>>
>>(1)  1
>> Type: PositiveInteger
>> (2) -> f(1)
>>Internal Error
>>Interpreter code generation failed for expression(|f| 1)
>
> The message looks fishy.  Do you really used _Spad_ function here?

Yes, here is the exact code that I compiled:

-- file: one-armed.spad
)abbrev domain TEST Test
Test(): with
test1: ()->Integer
test2: ()->Void
f:Integer -> PositiveInteger
g:Integer -> PositiveInteger
h:Integer -> PositiveInteger
  == add
z:Integer := 1
test1() ==
  A := if z<2 then 1
  return A
test2() ==
  B := if 2<1 then 1
  return B

f(x:Integer):PositiveInteger == if x<1 then 1
g(x:Integer):PositiveInteger == coerce((if x<1 then 1 else
void()$Void)::Union(Void,PositiveInteger))
h(x:Integer):PositiveInteger == g(x)+1
--

This is the result:

(1) -> )co one-armed
   Compiling FriCAS source code from file /home/wspage/one-armed.spad
  using old system compiler.
   TEST abbreviates domain Test
...
  Test is now explicitly exposed in frame frame1
   Test will be automatically loaded when needed from
  /home/wspage/TEST.NRLIB/TEST

(1) -> f(0)

   (1)  1
Type: PositiveInteger
(2) -> f(1)
   Internal Error
   Interpreter code generation failed for expression(|f| 1)

(2) -> g(0)

   (2)  1
Type: PositiveInteger
(3) -> g(1)

   >> Error detected within library code:
   "()" of mode Union(Void,PositiveInteger) cannot be coerced to mode
PositiveInteger

(3) -> h(0)

   (3)  2
Type: PositiveInteger
(4) -> h(1)

   >> Error detected within library code:
   "()" of mode Union(Void,PositiveInteger) cannot be coerced to mode
PositiveInteger

(4) ->

> The message looks like coming from interpreter and given
> Spad function of correct type interpreter should just blindly
> call it.
>

Yes, I thought so too.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [fricas-devel] unique Value of Void

[Bill Page]

On Sat, Jun 30, 2018 at 9:40 AM, Waldek Hebisch
 wrote:
>>
>> On Fri, Jun 29, 2018 at 11:22 AM, Waldek Hebisch
>>  wrote:
>> > On command line interpreter evaluates things so can use actual
>> > values to guess what would be useful.
>>
> Bill Page wrote:
>> Yes, one should expect that the interpreter would try harder to
>> guess reasonable types in order to relieve the user of (some)
>> of this responsibility.
>>
>> > In the process it breaks several normal rules.
>> >
>> > Try:
>> >
>> > f(x) == if (x > 1) then 1
>> >Type: 
>> > Void
>> >   Time: 0 
>> > sec
>> > (7) -> f(2)
>> >Compiling function f with type PositiveInteger -> Void
>> >Type: 
>> > Void
>> >Time: 0.02 (OT) = 0.02 
>> > sec
>> > (8) -> f(0)
>> >Compiling function f with type NonNegativeInteger -> Void
>> >Type: 
>> > Void
>> >Time: 0.01 (OT) = 0.01 
>> > sec
>> >
>> > In both cases you now get Void.
>>
>> Clearly this is a very poor (though technically correct) guess as
>> to what the user might have wanted.
>
> Maybe I should say more: compiling a function interpreter can
> _not_ use value, the function has to work for any value of
> argument, so in compiled function interpreter has to obey rules.

OK. I understand the distinction.

> In command line expression interpreter can use values.
> Sometime you get message that compilation failed, and
> that function will be interpreted.  In such case interpreter
> uses similar rules as on command line.  However, for serious
> computation such cases should be avoided because assigning
> types takes quite a lot of time.  In compiled functions this is
> done once per type, when interpreting type assignment is
> re-done on every execution of a statement.
>

Yes. There is a system command:

  )set function compile off/on  (on by default)

which is described as

  compile  compile, don't just define function bodies

but when I set function compile off, I still got the following result:

(1) -> )set function compile off
(1) -> f2(x : Integer) : Integer == if (x > 1) then 1
   Function declaration f2 : Integer -> Integer has been added to
  workspace.
   Type: Void
(2) -> f2(2)
   Compiling function f2 with type Integer -> Integer
   Conversion failed in the compiled user function f2 .

   Cannot convert the value from type Void to Integer .

--

Does this option still work? Perhaps my expectation was wrong.

>> ...
>> I cannot see any advantage in having this behavior in the
>> interpreter.
>
> Well, advantage is consistency with rules.
>

Could you site specifically what rule is being violated?

>> I think the interpreter should be changed to do the same
>> thing as the Spad compiler. The function should attempt to coerce
>> the result of the if-then expression
>>
>>   if (x > 1) then 1
>>
>> to Integer.  Of course this might cause an error for certain values
>> of x but the user is not likely to be surprised by this.
>
> Well, there are folks that want static checking, that is no type
> errors at runtime.  They prefer Void as a result type.  And
> there are folks who want to bend the rules.  IMO some sloppines
> on command line is OK.  But already for "interpreter" functions
> stricter type rules may be beneficial.
>
> Of course, having more relaxed rule in Spad compiler and stricter
> rule in intepreter is counterintuitive.  The only explanation I
> see is that original authors decided to change rules.  Remember
> that Spad is "old compiler" and compiler included in intepreter
> is "new compiler".
>

In fact the Spad compiler does not always do what I had hoped. For
example compiling the following function using Spad:

  f(x:Integer):PositiveInteger == if x<1 then 1

--

(1) -> f(0)

   (1)  1
Type: PositiveInteger
(2) -> f(1)
   Internal Error
   Interpreter code generation failed for expression(|f| 1)

--

This is a rather unexpected and obscure errror message. However it is
possible to compile explicit code such as:

  g(x:Integer):PositiveInteger == coerce((if x<1 then

Re: Re: [fricas-devel] unique Value of Void

[Bill Page]

On Fri, Jun 29, 2018 at 11:22 AM, Waldek Hebisch
 wrote:
> Riccardo GUIDA wrote:
>> ...
>> 3) The user is puzzled because
>
> The command line is not representative of FriCAS language.

In my opinion it should be (almost) representative of FriCAS language (SPAD).

> On command line interpreter evaluates things so can use actual values
> to guess what would be useful.

Yes, one should expect that the interpreter would try harder to guess
reasonable types in order to relieve the user of (some) of this
responsibility.

> In the process it breaks several normal rules.
>
> Try:
>
> f(x) == if (x > 1) then 1
>Type: Void
>   Time: 0 sec
> (7) -> f(2)
>Compiling function f with type PositiveInteger -> Void
>Type: Void
>Time: 0.02 (OT) = 0.02 sec
> (8) -> f(0)
>Compiling function f with type NonNegativeInteger -> Void
>Type: Void
>Time: 0.01 (OT) = 0.01 sec
>
> In both cases you now get Void.

Clearly this is a very poor (though technically correct) guess as to
what the user might have wanted.

> Unlike Spad compiler trying to declare type does not change the result:
>
> (9) -> f2(x : Integer) : Integer == if (x > 1) then 1
>Function declaration f2 : Integer -> Integer has been added to
>   workspace.
>Type: Void
>   Time: 0 sec
> (10) -> f2(2)
>Compiling function f2 with type Integer -> Integer
>Conversion failed in the compiled user function f2 .
>
>Cannot convert the value from type Void to Integer .
>
> (10) -> f2(0)
>Conversion failed in the compiled user function f2 .
>
>Cannot convert the value from type Void to Integer .
>

I cannot see any advantage in having this behavior in the
interpreter.I think the interpreter should be changed to do the same
thing as the Spad compiler. The function should attempt to coerce the
result of the if-then expression

  if (x > 1) then 1

to Integer.  Of course this might cause an error for certain values of
x but the user is not likely to be surprised by this.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [fricas-devel] unique Value of Void

[Bill Page]

On Fri, Jun 29, 2018 at 10:10 AM, Riccardo GUIDA
 wrote:
>
> Thanks for your clarifications Bill.
>

Thank you for asking the question.

>
> Just to say that my original question to Ralf was a much more low
> level quest for clarifications in the user guide:
>

OK. I think I understand your motivation and Ralf's concerns about clarity.

Let me try to annotate the quoted section with my interpretation:

> 1) A user reads:
>
> section 5.3 pag 149
> "An if-then-else expression always returns a value.

I think this is clear.

> If the else clause is missing then the entire expression
> returns the unique value of Void.

I agree that this sentence is either confusing or wrong. I would
suggest the following:

If the else clause is missing but the if condition is false then the
value of the if-then expression is the unique value of Void.

> If both clauses are present, the type of the value returned by if is obtained
> by resolving the types of the values of the two clauses. See Section 2.10
> on page 109 for more information." (Check also the boxed text above this
> statement.)
>

I suppose that the key issue is what might be meant by "resolving the
types". My interpretation is that that although both an if-then-else
expression and an if-then expression "always return a value", the
actual type is indeterminate and depends on knowing the types of both
clauses, i.e. the type of the then-part and the type of the (possibly
missing) else-part. But in the appropriate context the compiler (and
in principle the interpreter) are able to determine an appropriate for
the result.

> 2) The user does not really understand the statement and, if he is
> motivated, tries to experiment:
>
> (1) -> if 1>2 then 1   -- here he expects Void
>Type:
> Void

OK.

> (2) -> if 2>1 then 1  -- here he expects Void but gets PositiveInteger
>
>(2)  1
> Type: PositiveInteger


I can see that a naive interpretation of the statement in the guide
might lead to this expectation. But given a clear understanding of the
Void domain, it should be obvious that such a result could not be
useful.

> (3) -> if 2>1 then 1 else [1,2,3] -- here he expects common supertype, but
> which one?
>
>(3)  1
> Type: PositiveInteger


So, to this user "resolving the type" seems to imply the existence of
a supertype. In fact such a supertype does exist in FriCAS (Union) and
given that the statement in the guide is not so clear this is
certainly a reasonable expectation but I do not think that it is
actually implied.

> (4) -> if 1>2 then 1 else [1,2,3] --  here he expects common supertype,
> which  one?
>
>(4)  [1, 2, 3]
>   Type:
> List(PositiveInteger)
>

If we provide a bit more type information then the users expectations
can be met.

(1) -> A:Union(PositiveInteger, List PositiveInteger) := if 2>1 then 1
else [1,2,3]

   (1)  1
 Type: Union(PositiveInteger,...)
(2) -> A:Union(PositiveInteger, List PositiveInteger) := if 1>2 then 1
else [1,2,3]

   (2)  [1, 2, 3]
   Type: Union(List(PositiveInteger),...)


> 3) The user is puzzled because
>
> * in (2) below he gets Type: Positive Integer not Type: Void
> * in (3) and (4) below he sees 2 different types and not a "common
> supertype"
>

Yes I see how this is possible.

>
> From your explanations now I understand that there are a lot of
> hidden coercion in the game and that what is said in the user
> guide does not contradict the experiments. But I feel it would be
> helpful to have some clarifying information in the user guide not
> after page 149. Writing "the unique value of Void" is not of help
> because what is not evident is the fact that "every value can be
> coerced to Void". I realize now that this is said at pag 763,
> sec 9.87 (in my version of FricasUG), but at least a footnote in
> page 149 would have helped.
>

I think an important though somewhat less technical addition to the
user guide concerning the meaning and use of the Void and Exit domains
would indeed be quite useful.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] unique Value of Void

[Bill Page]

On Wed, Jun 27, 2018 at 5:15 PM, Ralf Hemmecke  wrote:
> Ricardo made me aware that the formulations in
> http://fricas.github.io/book.pdf Section 5.3 maybe a bit confusing to
> new users.
>
> We all know that Void is the type used in situations where there is
> no value.

No that is not correct. 'void()$Void' is the value that is used when
"no value is needed". To say that no value is needed is not the same
as there being no value. Perhaps it would be better to say that "no
specific value is needed" - in other words we do not care about the
actual value. But by definition the 'Void' domain does have just one
value. 'Void' is the "unit type" (terminal object in the categorical
model of FriCAS the type system). In most type systems it would also
be the "empty tuple" () or what Aldor would call an empty 'Cross'
product. ('Tuple' in FriCAS actually means something else.)

>From the source code for Void:

++ Description:
++   This type is used when no value is needed, e.g., in the
++   \spad{then} part of a one armed \spad{if}.
++   All values can be coerced to type Void.  Once a value has
++   been coerced to Void, it cannot be recovered.

Oldk suggested the following addition

+++   \spadtype{Void} implements the unit type in type theory.
+++   It allows only one value thus can hold no information.
+++   Void is used in the \spad{then} part of a one armed \spad{if}.

It might be misleading to say that a domain that has only one value
can hold no information. E.g.

(4) -> C:Union(Void,PositiveInteger):=2

   (4)  2
 Type: Union(PositiveInteger,...)
(5) -> C case Void

   (5)  false
Type: Boolean

>However the Book says on page 149:
>
>   If the else clause is missing then the entire expression returns the
>   unique value of Void.
>
> Uh? So Void doesn't mean "no value"?

No, it does not mean "no value". It means that we do not care what value.

'Exit' is the domain in FriCAS that has no value. 'Exit' is the "zero
type" (initial object in the categorical model).

>
> Even more funny then is this
>
> (1) -> A := if 1<2 then 1
>
>(1)  1
> Type: PositiveInteger
> (2) -> A
>
>(2)  1
> Type: PositiveInteger
> (3) -> B := if 2<1 then 1
>
>You cannot assign an object of type Void to any identifier, (in
>   particular, ??? ).
>
> (3) -> 3::Void
>  Type: Void
> (4) -> C := 3::Void
>
>You cannot assign an object of type Void to any identifier, (in
>   particular, ??? ).
>

The implementation in the interpreter is wrong. B and C should both
contain the same 'void()' value.

> So the Book uses the word "value" with different meanings.

In this instance the book is correct.

> The value with type Void cannot be used any further, i.e.,
> is not assignable to any identifier.
>

No. There should be no problem handling the value of 'Void' in the
same way as any other value (provided that it is type-correct).

> Furthermore, (1) does not behave as described, because
> "if 1<2 then 1" should be of type Void and not of type
> PositiveInteger.
>
> It's understandable that FriCAS chooses to return 1 in case (1),
> because otherwise it wouldn't be intuitive for a user. I'm pretty
> sure that something like (1) wouldn't work in the compiler,

Try this:

-- file: one-armed.spad
)abbrev domain TEST Test
Test(): with
test1: ()->Integer
test2: ()->Void
  == add
test1() ==
  A := if 1<2 then 1
  return A
test2() ==
  B := if 2<1 then 1
  return B
--

Result:

(1) -> )co one-armed
   Compiling FriCAS source code from file /home/wspage/one-armed.spad
  using old system compiler.
   TEST abbreviates domain Test
...
   Test will be automatically loaded when needed from
  /home/wspage/TEST.NRLIB/TEST

(1) -> test1()

   (1)  1
Type: PositiveInteger
(2) -> test2()
   Type: Void

> but shouldn't we change the documentation and explain,
> that "if" behaves differently in interpreter vs compiler?
>
> Any suggestions?
>

I would rather change the interpreter to behave is the same way as the compiler.

--

BTW, here is another case where |$resolve_level| is needed:

(3) -> test2()=void()$Void

   >> System error:
   The variable |$resolve_level| is unbound.

Also as a one-element set I think 'Void' should really satisfy
'SetCategory' so then

(3) -> (test2()=void()$Void)@Boolean

and similar expressions would return 'true' by definition.

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

Re: [fricas-devel] [PATCH] Void is the unit type, fix doc and cleanup (use 0 as representation)

[Bill Page]

On Wed, Jun 13, 2018 at 9:22 PM, oldk1331  wrote:
>> However I am uncertain about your proposed changes to Void. Why do you
>> prefer a value of 0 instead of the symbol "()"?  Note of course that
>> this is a Lisp symbol and not Lisp NIL. Although the value can be
>> anything, as the empty tuple, I think () is more intuitive than 0.  A
>> value of 0 might be a bit confusing since the unit *type* is usually
>> denoted by 1, not 0. I see no harm in letting the Rep for Void be
>> String. In fact why not just define
>>
>>   void() == "()"
>
> The underlying value of Void is not important, because the type Void
> can only have one possible value.  I don't want to use string because of
> possible memory waste.
>

Does storing 0 take less space than a pointer to a string?

>> Is the Lisp function call voidValue really important for some reason
>> like in-line optimization?
>
> 'voidValue' is used a few places in the compiler.
>

OK. Maybe a global constant would be better?

>> Also, why did you make the following changes in Exit?
>>
>> -coerce(n:%) == error "Cannot use an Exit value."
>> -n1 = n2 == error "Cannot use an Exit value."
>
> Because Exit is the bottom type, no variable can have an Exit value,
> therefore, it can't be printed or compared. When encountering Exit
> type, the function aborts.
>

OK. A domain with no value is a categorical necessity (e.g. initial
object). You are right of course that the coding is non-functional
though perhaps it serves as a kind of documentation.

>> From a formal point of view I am not certain at all about None. Since
>> FriCAS is a statically typed language I think it would be nice if None
>> could be eliminated from the library. FriCAS already has the type Any
>> which implements a type-correct version of "duck typing" and plays the
>> role of a universal type.
>
> None as the top type is very necessary.  The difference between Any and None
> is that Any contains the value and type, None just contains the value.

You should not think of FriCAS domains as "containers". A variable may
"contain" or a function may "return" something of a given type but as
types domains do not contain values.

> None is widely used and can't be replaced.  Although I think "None" is a 
> terrible name.
>

I disagree. None is both unnecessary and harmful, leading to many
potentially unsafe uses of 'pretend'

It is true that 'None' is currently used in the following 22 spad
files in FriCAS:

  algfunc any combfunc exposed expr files fortout fspace jet kl
laplace liouv mkfunc omcat omdev op opalg openmath rdeefx rec table
xhash

with 'op' and domains that use properties being the worst offenders.

As an experiment I re-coded None as Any in the case of properties in
the following branch

  https://github.com/billpage/fricas/tree/NotNone

There are 118 fewer uses of 'pretend'.

Now only the following uses of None remain:

  any files fortout mkfunc omcat omdev openmath tablexhash

These cases can also be easily eliminated. As a result of this
re-coding the compiler was able to detect two cases of unsafe but
benign type errors (fixed in separate commits).

Timing of 'src/input/make' shows that no significant performance
penalty is incurred for safer coding.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] patch to recent commit r2473

[Bill Page]

On Sat, Jun 23, 2018 at 4:52 AM, oldk1331  wrote:
> But for 'min'/'max', the 'map' paradigm is not very suitable.
> The appropriate way is to use 'reduce'.
>

+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 post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] [PATCH] Void is the unit type, fix doc and cleanup (use 0 as representation)

[Bill Page]

On Tue, Jun 12, 2018 at 9:37 AM, oldk1331  wrote:
> Clearly domain "Void" is the unit type:
> https://en.wikipedia.org/wiki/Unit_type
>
> So I'm clearing this up.
>

I think that fixes and better documentation of the Void, Exit, and
None domains are quite welcome but still warrant some discussion. From
a formal linguistic or categorical point of view Void (terminal
object) and Exit (initial object) are more important than they look.
As a category, FriCAS domains should form at least a Cartesian
category (although I think an even better model might be a topos).

However I am uncertain about your proposed changes to Void. Why do you
prefer a value of 0 instead of the symbol "()"?  Note of course that
this is a Lisp symbol and not Lisp NIL. Although the value can be
anything, as the empty tuple, I think () is more intuitive than 0.  A
value of 0 might be a bit confusing since the unit *type* is usually
denoted by 1, not 0. I see no harm in letting the Rep for Void be
String. In fact why not just define

  void() == "()"

Is the Lisp function call voidValue really important for some reason
like in-line optimization?

Also, why did you make the following changes in Exit?

-coerce(n:%) == error "Cannot use an Exit value."
-n1 = n2 == error "Cannot use an Exit value."

>From a formal point of view I am not certain at all about None. Since
FriCAS is a statically typed language I think it would be nice if None
could be eliminated from the library. FriCAS already has the type Any
which implements a type-correct version of "duck typing" and plays the
role of a universal type.

-- 
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.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Exposing formatters

[Bill Page]

+1

On Mon, Jun 11, 2018 at 9:34 AM, Waldek Hebisch
 wrote:
> I think that we should not expose MathMLFormat, ScriptFormulaFormat,
> TexFormat and TexmacsFormat.  AFAICS TexFormat1 has to be
> exposed to fulfil its role, so probably should be exposed.
>
> Opinions?
>
> --
>   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 post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] [PATCH] misc cleanups

[Bill Page]

On Mon, Jun 11, 2018 at 8:17 AM, oldk1331  wrote:
>>> The grammar for 'reduce':   "func"/[args]
>>> is not only very strange, but also not applicable in interpreter.
>>>
>>> I don't think it's worth the effort that compiler supports this grammar,
>>> because it should be easilly replaced by "reduce(func, args)",
>>> so I want to remove this grammar eventually.
>>

+1

>> ATM "func"/[args] notation has one big advantage: it does not create
>> an intermediate list.  So it is more efficient than 'reduce(func, args)'
>> variant.  Supporting it in compiler in a sense is almost trivial:
>> most of code is present anyway to support '[i for i in l]' construct.
>
> OK, if the reason for this grammar is to optimize cases like
>
>func/[f(x) for x in g]
>
> then we can come up with a function called "mapreduce"
>
>mapreduce(func, f, g)
>
> to avoid this special compiler treatment.  Also this style is
> more functional than imperative.
>

+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 post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.