Re: [fricas-devel] How one talk to sqlite3 database from Fricas?

[Kurt Pagani]

https://github.com/nilqed/spadlib/tree/master/sqlite


'Nasser M. Abbasi' via FriCAS - computer algebra system <
fricas-devel@googlegroups.com> schrieb am So., 24. Dez. 2023, 03:53:

> I googled and could not find hit on this. Is it possible to open SQLITE3
>  database file from Fricas and
> read/write to the database using SQL?
>
> Currently all my integration problems are stored in sqlite3 database which
> is open source database. Both Maple and Mathematica support reading/write
> to it. I wrote small note sometime ago how to do this in Maple. Here is
> link 
>
> Does Fricas have such API?  I use sqlite3 for all my software and store
> everything in database files.
>
> Thanks
> --Nasser
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fricas-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/31dff7b9-5745-491e-95f3-90ed3d2fe949n%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/CA%2BTGnoZDbhnyB7nSKbB-yxb9-KkO%2BJA3h-U0Lk5XjveYbCsZoA%40mail.gmail.com.

Re: [fricas-devel] Re: thoughts on SparseUnivariatePolynomial multiplication

[Kurt Pagani]

On 02.10.2022 12:37, Qian Yun wrote:



On 10/2/22 13:18, Qian Yun wrote:

So first conclusion is to optimize for small inputs.  There's not much
room for it, I think.

For bigger inputs, I think current implementation is bad both ways:

a) For sparse cases, simply chain the MxN terms together, sort and
dedupe is O(N^2*log(N)) better than current O(N^3).

b) For dense cases, using actual dense representation like array
should be a great improvement over current implementation:
we only need a (slightly larger than) (M+N) length array to store
the temp result.


No need to create an array to store temp result, we only need to
create array for input (p, q) and the coefficient of (p * q) can
be computed directly, for example:

https://github.com/sympy/sympy/blob/sympy-1.11.1/sympy/polys/densearith.py#L735

I think this will be valid optimization for small (but dense)
inputs as well.  Will need data to determine when to use this
method -- what qualifies a polynomial as "dense"?
For example, max degree - min degree < 2 * number of monomials ?


A good question. I've never seen a satisfactory definition. While some think of
(https://math.berkeley.edu/~bernd/cbms.pdf)

"""
Here and throughout this book, a polynomial is called sparse if we know a priori 
which monomials appear with non-zero coefficients in that polynomial.

"""

it may well make sense to distinguish sparse/dense:

What Can (and Can’t) we Do with Sparse Polynomials?
https://arxiv.org/pdf/1807.08289.pdf
https://www.usna.edu/Users/cs/roche/research/phd/



- 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/5f7bdd45-fcc4-2eb5-9bb9-b88f1f554d48%40gmail.com.

Re: [fricas-devel] FYI, new SQLlite interface to the Independent CAS integration tests available

[Kurt Pagani]

Addendum: forgot adding the example   works well despite the 1.2 GB size 
now!

(ql:quickload :sqlite)
(use-package :sqlite)
(defvar *db* (connect "/home/kfp/Desktop/cas_integration_tests.db"))
*DB*
(execute-single *db* "select COUNT(*) from main where fricas_anti LIKE 
'%weierstrass%'")

4054
(execute-single *db* "select COUNT(*) from main where fricas_anti LIKE 
'%fresnel_sin%'

OR'%fresnel_cos%'")
395
(execute-to-list *db* "select fricas_anti from main limit 10")

(("1/3*(2*x + 1)^(3/2)") ("2/135*(27*x^2 + 3*x - 2)*sqrt(3*x + 1)")

 ("2/105*(15*x^3 + 3*x^2 - 4*x + 8)*sqrt(x + 1)")

 ("-2/27*(3*x + 4)*sqrt(-3*x + 2)") ("-1/4/(x^4 + 4*x^3 + 8*x^2 + 8*x + 4)")

 ("1/3*cos(x)^3 - cos(x)") ("3/28*(4*z^2 - z - 3)*(z - 1)^(1/3)")

 ("1/2/(cos(x)^2 - 1)") ("1/3*(sin(2*x) - 4)*sqrt(-sin(2*x) + 4)")

 ("1/(cos(x) + 3)"))

*

On 22.09.2022 13:37, 'Nasser M. Abbasi' via FriCAS - computer algebra system 
wrote:

Fyi,

CAS integrations tests SQL database is now fully build.

<http://localhost/my_notes/CAS_integration_tests/reports/summer_2022/DATA_BASE/index.htm>

After extracting the zip file, the size of the db is 1.3 GB.

Added lots of examples also.  Here are few related to Fricas

Find how many problem Fricas uses Weierstrass special functions in its
solution

sqlite>select COUNT(*) from main where fricas_anti LIKE '%weierstrass%';
  4066

sqlite> select COUNT(*) from main where fricas_anti LIKE '%fresnel_sin%'
OR'%fresnel_cos%';
   395

Find how many problems Fricas solved
sqlite>  SELECT COUNT(*) from main where fricas_pass=1;
64582

Total number of intergrals

sqlite> select COUNT(*) from main;
85479


--Nasser


On Wednesday, August 24, 2022 at 10:47:24 AM UTC-5 Nasser M. Abbasi wrote:


Hello Kurt;

The latex for Fricas and Maxima and Giac is all generated by sagemath
itself. After the call from integrate returns, the test program does

anti_in_latex = latex(anti)

In the sagemath/python script. Also the grading is done in the same Python
script, all inside sagemath.

--Nasser


On Wednesday, August 24, 2022 at 7:54:39 AM UTC-5 Kurt Pagani wrote:


That's great! By the way, may I ask how the latex (e.g. column
fricas_anti_in_latex) is generated? By sage or fricas itself?

Greetings
Kurt

On 24.08.2022 11:42, 'Nasser M. Abbasi' via FriCAS - computer algebra
system wrote:

FYI posted at https://groups.google.com/g/fricas-devel and
https://groups.google.com/g/sci.math.symbolic



<

https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/DATA_BASE/index.htm>


<

https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/DATA_BASE/index.htm




To make it easier to query the Independent CAS integration tests

results,

there is now an SQLite database which contains all relevant results
generated during testing. This is meant to complement the reports
and the webpages and not replace them.

The database and the reports were all generated from the same CSV tables
after running the integration tests. But using the SQL database it
is much easier to obtain the information needed by issuing SQL commands.

To use the database requires the free sqlite3 software. There is
also a free GUI interface.

There is an initial release of the database now with information how to
install it and the software needed use it at the above link.

The database is not fully populated yet, but can be used immediately.
It will take about another 1-2 weeks. The above page will indicate
when the database is completed.

Examples are given on the above page how to use it.

Any problems/bugs please let me know.

--Nasser









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

Re: [fricas-devel] FYI, new SQLlite interface to the Independent CAS integration tests available

[Kurt Pagani]

Hi Nasser

Cool, thanks.

BTW1:  slipped into your last link ;)
https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/DATA_BASE/index.htm

BTW2: there is a sqlite interface to CL: 
https://cl-sqlite.common-lisp.dev/#installation, i.e. the db can be used in 
fricas/quicklisp as well.


On 22.09.2022 13:37, 'Nasser M. Abbasi' via FriCAS - computer algebra system 
wrote:

Fyi,

CAS integrations tests SQL database is now fully build.

<http://localhost/my_notes/CAS_integration_tests/reports/summer_2022/DATA_BASE/index.htm>

After extracting the zip file, the size of the db is 1.3 GB.

Added lots of examples also.  Here are few related to Fricas

Find how many problem Fricas uses Weierstrass special functions in its
solution

sqlite>select COUNT(*) from main where fricas_anti LIKE '%weierstrass%';
  4066

sqlite> select COUNT(*) from main where fricas_anti LIKE '%fresnel_sin%'
OR'%fresnel_cos%';
   395

Find how many problems Fricas solved
sqlite>  SELECT COUNT(*) from main where fricas_pass=1;
64582

Total number of intergrals

sqlite> select COUNT(*) from main;
85479


--Nasser


On Wednesday, August 24, 2022 at 10:47:24 AM UTC-5 Nasser M. Abbasi wrote:


Hello Kurt;

The latex for Fricas and Maxima and Giac is all generated by sagemath
itself. After the call from integrate returns, the test program does

anti_in_latex = latex(anti)

In the sagemath/python script. Also the grading is done in the same Python
script, all inside sagemath.

--Nasser


On Wednesday, August 24, 2022 at 7:54:39 AM UTC-5 Kurt Pagani wrote:


That's great! By the way, may I ask how the latex (e.g. column
fricas_anti_in_latex) is generated? By sage or fricas itself?

Greetings
Kurt

On 24.08.2022 11:42, 'Nasser M. Abbasi' via FriCAS - computer algebra
system wrote:

FYI posted at https://groups.google.com/g/fricas-devel and
https://groups.google.com/g/sci.math.symbolic



<

https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/DATA_BASE/index.htm>


<

https://12000.org/my_notes/CAS_integration_tests/reports/summer_2022/DATA_BASE/index.htm




To make it easier to query the Independent CAS integration tests

results,

there is now an SQLite database which contains all relevant results
generated during testing. This is meant to complement the reports
and the webpages and not replace them.

The database and the reports were all generated from the same CSV tables
after running the integration tests. But using the SQL database it
is much easier to obtain the information needed by issuing SQL commands.

To use the database requires the free sqlite3 software. There is
also a free GUI interface.

There is an initial release of the database now with information how to
install it and the software needed use it at the above link.

The database is not fully populated yet, but can be used immediately.
It will take about another 1-2 weeks. The above page will indicate
when the database is completed.

Examples are given on the above page how to use it.

Any problems/bugs please let me know.

--Nasser









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

Re: [fricas-devel] Adding new lisp (ABCL) support

[Kurt Pagani]

This is the official one:
https://abcl.org/

Meta: it is (very briefly) mentioned in 
https://en.wikipedia.org/wiki/Common_Lisp

"""
Freely redistributable implementations
Armed Bear Common Lisp (ABCL)
A CL implementation that runs on the Java Virtual Machine.[23] It includes a
compiler to Java byte code, and allows access to Java libraries from CL. It was
formerly just a component of the Armed Bear J Editor.
"""

On 19.09.2022 18:05, Grégory Vanuxem wrote:
> I wonder always : a link to ABCL?
> Am not a fan of « Google is your friend » but yes I can find some
> information.
> 
> But, for sure, it’s a good idea and can ameliorate the stuff.
> __
> Greg
> 
> Le lun. 19 sept. 2022 à 16:24, Qian Yun  a écrit :
> 
>> I'd like to add new lisp support for FriCAS soon, starting with ABCL.
>>
>> First, ABCL almost supports fricas0, I have identified 2 bugs and they
>> are fixed upstream (not merged yet, should be available next release).
>> So I think it is time to add ABCL support in FriCAS repo.
>>
>> https://github.com/armedbear/abcl/issues/500
>> https://github.com/armedbear/abcl/issues/504
>>
>> Second, to add ABCL support for FriCAS, I guess it is similar to add
>> support for POPLOG?  So basically adding "#+abcl" near "#+poplog".
>>
>> Third, if so, I'd like to clean it up a bit before adding ABCL support:
>> how about grouping those implementation specific stuff into a single
>> place/file?
>>
>> - 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/87df413f-02a0-76ca-ce0c-9e27c36e1507%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/c1a041f1-b501-c3bd-8102-11d9ed5d2dd8%40gmail.com.

Re: [fricas-devel] Adding new lisp (ABCL) support

[Kurt Pagani]

Hi Qian

I strongly encourage this endeavor :)
ABCL is quite useful when speed is not the top priority. Fricas in a .jar would
be really attractive.

I reported a bug  5 years ago ... but I'm not up to date at the moment.
https://armedbear-devel.common-lisp.narkive.com/Yh8vNHwi/fricas-w-abcl

It works fine with Maxima, especially in combination with the Java based jEdit
editor. Would be great to have something alike for fricas.

https://github.com/nilqed/abcl_maxima
https://github.com/nilqed/abcl-j


On 19.09.2022 16:24, Qian Yun wrote:
> I'd like to add new lisp support for FriCAS soon, starting with ABCL.
> 
> First, ABCL almost supports fricas0, I have identified 2 bugs and they
> are fixed upstream (not merged yet, should be available next release).
> So I think it is time to add ABCL support in FriCAS repo.
> 
> https://github.com/armedbear/abcl/issues/500
> https://github.com/armedbear/abcl/issues/504
> 
> Second, to add ABCL support for FriCAS, I guess it is similar to add
> support for POPLOG?  So basically adding "#+abcl" near "#+poplog".
> 
> Third, if so, I'd like to clean it up a bit before adding ABCL support:
> how about grouping those implementation specific stuff into a single
> place/file?
> 
> - 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/4829e5cb-77f3-c754-c52c-134e2ddcb8e4%40gmail.com.

Re: [fricas-devel] definite integral

[Kurt Pagani]

I guess the problem is limit(Ei(-x),x=%plusInfinity) --> failed

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

Even with c:=1:

I:=integrate(exp(-x)*log(x),x=eps..1/eps,"noPole")

 1
  - ---
   - eps   2eps  1 1
 %e log(eps ) - %e log() + 2 Ei(- ---) - 2 Ei(- eps)
  2   eps
   eps
   (1)  ---
2
  Type: Union(f1: OrderedCompletion(Expression(Integer)),...)
limit(%,eps,0)


limit(%,eps=0)

   (42)  [leftHandLimit = - infinity, rightHandLimit = "failed"]
Type: Union(Record(leftHandLimit:
Union(OrderedCompletion(Expression(Integer)),"failed"),rightHandLimit:
Union(OrderedCompletion(Expression(Integer)),"failed")),...)

So the MM/M-results are not better.


On 05.09.2022 14:48, Ralf Hemmecke wrote:
> Consider c>0.
> 
> (1) -> integrate(exp(-c*x)*log(x),x=0..%plusInfinity)
> 
>    (1)  "faileed"
> 
> Can FriCAS specify "c>0" somehow?
> 
> In Mathematica I get.
> 
> In[1]:= Integrate[Exp[-c*x]*Log[x], {x, 0, Infinity}]
> 
> Out[1]= ConditionalExpression[-((EulerGamma + Log[c])/c), Re[c] > 0]
> 
> In Maple I get at least...
> 
>> integrate(exp(-c*x)*log(x),x=0..infinity);
> 
>   exp(-c x) ln(x) + ln(c) + Ei(1, c x) + gamma
>   lim   - 
>  x -> infinity c
> 
> Since we do not have "lim" in OutputForm, it would be hard to return a result
> similar to Maple.
> 
> Ralf
> 


I:=integrate(exp(-c*x)*log(x),x=eps..1/eps,"noPole")

   c
- ---
   - c eps   2eps  1 c
 %e   log(eps ) - %e log() + 2 Ei(- ---) - 2 Ei(- c eps)
2   eps
 eps
   (1)  ---
 2 c
  Type: Union(f1: OrderedCompletion(Expression(Integer)),...)



I.f1

   c
- ---
   - c eps   2eps  1 c
 %e   log(eps ) - %e log() + 2 Ei(- ---) - 2 Ei(- c eps)
2   eps
 eps
   (2)  ---
 2 c
 Type: OrderedCompletion(Expression(Integer))


limit(I.f1,eps=0)

   (3)  "failed"
Type: Union("failed",...)




Using c^2 instead of c =>

limit(I.f1,eps=0)

   (22)  [leftHandLimit = - infinity, rightHandLimit = "failed"]
Type: Union(Record(leftHandLimit:
Union(OrderedCompletion(Expression(Integer)),"failed"),rightHandLimit:
Union(OrderedCompletion(Expression(Integer)),"failed")),...)


J:=integrate(exp(-c^2*x)*log(x),x)

2
 - c x   2
 - %e log(x) + Ei(- c x)
   (24)  ---
   2
  c
 Type: Union(Expression(Integer),...)

limit(J,x=0)

   (27)
 2
log(c ) - log(- 1) - digamma(1)
   [leftHandLimit = ---, rightHandLimit = "failed"]
2
   c
Type: Union(Record(leftHandLimit:
Union(OrderedCompletion(Expression(Integer)),"failed"),rightHandLimit:
Union(OrderedCompletion(Expression(Integer)),"failed")),...)

limit(J,x=%plusInfinity)

   (34)  "failed"
Type: Union("failed",...)


limit(Ei(-x),x=%plusInfinity)

   (37)  "failed"
Type: Union("failed",...)

-- 
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/e1deb241-ba32-dd91-c566-b6a910e9a2c2%40gmail.com.

Re: [fricas-devel] Numbers as type parameters

[Kurt Pagani]

Thanks for this elaborate explanation - a real eye-opener and hint for a 
(pseudo) work-around :)
When we change Impl B to (using _0,_2,...):

  Implementation == BOP add 
Rep := BOP  
coerce(s:Symbol):% == operator s
_0:PINT
_2:PINT
r:Polynomial Integer
NULL:A(_0):="NULL"::Symbol::A(_0)
TWO:A(_2):="TWO"::Symbol::A(_2)
OK:A(r):="OK"::Symbol::A(r)
f x == NULL 
g x == OK
h x == TWO

then it works, suggesting that I should use a type Symbolic(X) which is 
able to handle primitive integer arithmetics, but avoids constants/numbers? 
Let's see.  

   B is now explicitly exposed in frame initial 
   B will be automatically loaded when needed from 
  /Users/kfp/Desktop/work/spad/BDOM.NRLIB/BDOM

[5] b:=b::B

   (5)  b
  Type: 
B
[6] f b

   (6)  NULL
   Type: 
A(0)
[7]  g b

   (7)  OK
   Type: 
A(r)
[8]  h b

   (8)  TWO
   Type: 
A(2)
[9] 

On Thursday, 1 September 2022 at 20:38:20 UTC+2 Waldek Hebisch wrote:

> On Thu, Sep 01, 2022 at 07:32:00PM +0200, Kurt Pagani wrote:
> > On 01.09.2022 19:11, Waldek Hebisch wrote:
> > > On Thu, Sep 01, 2022 at 09:11:33AM -0700, Kurt Pagani wrote:
> > >> Problem: when using a type A(p:Polynomial Integer) in another type B, 
> then 
> > ...
> > > 
> > > ATM I see no chance to make this working. Let me recall what I wrote
> > > im March 2021:
> > > 
> > > : However, as long as use is strictly at
> > > : Spad level, types are not used in conditions and
> > > : parameters are first assigned to variables and
> > > : only variables are passed to constructors, then arbitrary
> > > : non-type parameters probably should work (I know of no obstacle
> > > : to such use).
> > 
> > I had this vaguely in the back of my head, but did not find the page.
> > Now I can remember that only variables may be passed ... that's why the 
> function
> > "g" is working.
>
> I would say "no error is detected", it does not mean int works...
>
> > > You violated one of rules above, namely you are passing nontrivial
> > > constants directly to constructor.
> > 
> > Yes, indeed :(
> > 
> > > 
> > > BTW: '2 pretend PINT' is really bad code. It works only when
> > > '2@PINT' works and otherwise silently produces wrong result.
> > 
> > I only wanted to build an A(0) type and was surprised by the
> > "The value 0 is not of type CONS", so I tried other things (numbers),
> > which I don't need, actually.
>
> If you look at BDOM.NRLIB/index.KAF you will see:
>
> (CATEGORY |domain| (SIGNATURE |coerce| ($ (|Symbol|)))
> (SIGNATURE |f| ((A 0) $)) (SIGNATURE |g| ((A |r|) $))
> (SIGNATURE |h| ((A (|pretend| 2 (|Polynomial| (|Integer|
>
> And this shous explain source of the problem: constants in signatures
> are represented by Lisp expressions directly taken from source.
> Later. the expressions are passed (maybe quoted) to Lisp eval.
>
> So 0 produces Lisp integer 0. But as you can see:
>
> (3) -> PRETTYPRINT(0::Polynomial(Integer))$Lisp
> (0 . 0)
>
> 0 in Polynomial(Integer) is represented by a pair, with first
> element indicating Union branch, in this case base ring R (that
> is Integer), the second element is value in R, this time
> Lisp integer 0.
>
> This is not easy to fix, because at each place in code we need
> to know intended meaning. Namely, one meaning is syntactic,
> the other is actual value in the domain. ATM we have no way
> to represent general domain values in signatures. Stephen
> Watt sayed that during type checking Aldor compares parse
> tree of actual argument with parse tree of formal argument.
> More or less the same holds for Spad compiler. But at runtime
> we need values from the parameter domain. So, compiler
> and intepreted should insert code computing values.
> Unfortunetly this is missing and requires finding all places
> where we need to do this. Additionally, interpreter represents
> things differently than Spad compiler, so we need extra
> work in interpreter.
>
> -- 
> 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/8b4f4a66-8d0a-4011-9132-5cc5db66f268n%40googlegroups.com.

Re: [fricas-devel] Numbers as type parameters

[Kurt Pagani]

On 01.09.2022 19:11, Waldek Hebisch wrote:
> On Thu, Sep 01, 2022 at 09:11:33AM -0700, Kurt Pagani wrote:
>> Problem: when using a type A(p:Polynomial Integer) in another type B, then 
...
> 
> ATM I see no chance to make this working.  Let me recall what I wrote
> im March 2021:
> 
> : However, as long as use is strictly at
> : Spad level, types are not used in conditions and
> : parameters are first assigned to variables and
> : only variables are passed to constructors, then arbitrary
> : non-type parameters probably should work (I know of no obstacle
> : to such use).

I had this vaguely in the back of my head, but did not find the page.
Now I can remember that only variables may be passed ... that's why the function
"g" is working.

> 
> You violated one of rules above, namely you are passing nontrivial
> constants directly to constructor.

Yes, indeed :(

> 
> BTW: '2 pretend PINT' is really bad code.  It works only when
> '2@PINT' works and otherwise silently produces wrong result.

I only wanted to build an A(0) type and was surprised by the
 "The value 0 is not of type CONS", so I tried other things (numbers),
which I don't need, actually.

Perhaps I'll find a work-around (quite confident).

Thank you for the quick answer!
Kurt


> 

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

[fricas-devel] Numbers as type parameters

[Kurt Pagani]

Problem: when using a type A(p:Polynomial Integer) in another type B, then 
Fricas complains if p is a number (Expression makes no difference). Is 
there any method to tell the compiler that the number (if) is a "Polynomial 
Integer"? I tried out as much as crossed my mind. Any clues highly 
appreciated?

Below is a minimal code sample:

[1] b:=b::B

   (1)  b
  Type: 
B
[2] f b
 
   >> System error:
   The value
  0
is not of type
  CONS

[3] g b

   (3)  OK
 
 Type: A(r)
[4] h b
 
   >> System error:
   The value
  |pretend|
is not of type
  FIXNUM




)abbrev domain ADOM A
A(p:Polynomial Integer) : Exports == Implementation where 
  --p : Polynomial Integer
  BOP ==> BasicOperator 
  Exports == SetCategory with
coerce : Symbol -> %  
  Implementation == BOP add 
Rep := BOP  
coerce(s:Symbol):% == operator s

)abbrev domain BDOM B
B : Exports == Implementation where 
  BOP  ==> BasicOperator
  PINT ==> Polynomial Integer
  Exports == SetCategory with
coerce : Symbol -> % 
f : % -> A(0)
g : % -> A(r)
h : % -> A(2 pretend PINT)
  Implementation == BOP add 
Rep := BOP  
coerce(s:Symbol):% == operator s
NULL:A(0):="NULL"::Symbol::A(0)
TWO:A(2 pretend PINT):="TWO"::Symbol::A(2 pretend PINT)
r:Polynomial Integer
OK:A(r):="OK"::Symbol::A(r)
f x == NULL 
g x == OK
h x == TWO
---

Background:
http://fricas-wiki.math.uni.wroc.pl/DependentTypeTest1

-- 
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/dee3ae65-8ca5-457a-af05-406d8253a872n%40googlegroups.com.

Re: [fricas-devel] interpret output of the guessing package

[Kurt Pagani]

On 24.08.2022 09:42, Ralf Hemmecke wrote:
>> The reason that the innermost terms (i.e., the factors in the product

> 
> Still there is the question, how am I supposed to take the result apart for
> further computation. That should be explained somewhere. You cannot expect 
> your
> users to know how the internals of Expression(Integer) are to be handled.

Not? ;-)

Maybe, most simple:

f.1

   (13)
   s  - 1  p  - 1s  - 1
   n - 18   7 6
--+++-++--+  ++-++
>   | | >  -  | |[f(p ): (p  - 1)f(p ) + p  - 1 = 0] + 2 + 2
--+ | | --+   | |5 55 5
   s  = 0  p  = 0  s  = 0p  = 0
8   7   6 5
Type: Expression(Integer)
g:=f.1::InputForm

   (15)
   (+

 (sum

   (product

 (+

   (sum

 (*  - 1

   (product  (rootOfRec %F (%inforec1))
(equation %F (SEGMENT 0 (+ %G - 1
   )

(equation %G (SEGMENT 0 (+ %H - 1

  2)

(equation %H (SEGMENT 0 (+ %I - 1

  (equation %I (SEGMENT 0 (+ n - 1

2)
  Type: InputForm
car g

   (16)  +
  Type: InputForm
cdr g

   (17)
   (
 (sum

   (product

 (+

   (sum

 (*  - 1

   (product  (rootOfRec %F (%inforec1))
(equation %F (SEGMENT 0 (+ %G - 1
   )

(equation %G (SEGMENT 0 (+ %H - 1

  2)

(equation %H (SEGMENT 0 (+ %I - 1

  (equation %I (SEGMENT 0 (+ n - 1

2)
  Type: InputForm




> 
> 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/1180786c-c633-fb55-028e-33dcaf2c409e%40gmail.com.

Re: [fricas-devel] FYI, new SQLlite interface to the Independent CAS integration tests available

[Kurt Pagani]

That's great! By the way, may I ask how the latex (e.g. column
fricas_anti_in_latex) is generated? By sage or fricas itself?

Greetings
Kurt

On 24.08.2022 11:42, 'Nasser M. Abbasi' via FriCAS - computer algebra system 
wrote:
> FYI posted at https://groups.google.com/g/fricas-devel and 
> https://groups.google.com/g/sci.math.symbolic 
> 
> 
>   
> 
>  
> 
>  
> 
> To make it easier to query the Independent CAS integration tests results,
> there is now an SQLite database which contains all relevant results
> generated during testing.  This is meant to complement the reports
> and the webpages and not replace them.
> 
> The database and the reports were all generated from the same CSV tables
> after running the integration tests. But using the SQL database it
> is much easier to obtain the information needed by issuing SQL commands.
> 
> To use the database requires the free sqlite3 software. There is
> also a free GUI interface.
> 
> There is an initial release of the database now with information how to
> install it and the software needed use it at the above link.
> 
> The database is not fully populated yet, but can be used immediately.
> It will take about another 1-2 weeks. The above page will indicate
> when the database is completed.
> 
> Examples are given on the above page how to use it.
> 
> Any problems/bugs please let me know.
> 
> --Nasser
> 

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

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

[Kurt Pagani]

Although I care little about logos, it might be preferable to have one that can
be constructed in a simple way, e.g. as ASCII art or by a LaTeX macro.
There are some tools (figlet for ascii-art) or tizk for LaTeX which may be of
help (see links below).
A quick search and some adjustments resulted in the hints below (which doesn't
mean, I like it ;). Actually I like the one Bill referred to in the last post.



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


logo:=[_
"   ",_
"   __     ",_
"  / /__(__) __/ __ | / / ",_
" / __// / / //  |__\ \   ",_
"/__/ /__/ /__/\__/__/ |__/__/   ",_
"=~=~=~=~==~=~=~=~==~=~=~=~=  "]

   (2)

   ["   __", "   _     ",
"  / __/___(_) ___/ _ | / __/ ", " / _// __/ / /__/ __ |_\ \   ",
"/_/ /_/ /_/\___/_/ |_/___/   ", "=~=~=~=~==~=~=~=~==~=~=~=~=  "]
   Type: List(String)
map(output,logo);
  __
  _    
 / __/___(_) ___/ _ | / __/
/ _// __/ / /__/ __ |_\ \
   /_/ /_/ /_/\___/_/ |_/___/
   =~=~=~=~==~=~=~=~==~=~=~=~=

 Type: List(Void)




or in LaTeX:

https://tex.stackexchange.com/questions/381262/logo-design-with-tikz
https://tex.stackexchange.com/questions/297879/drawing-logo-with-tikz
https://tex.stackexchange.com/questions/469279/how-can-i-create-this-logo-in-latex

\documentclass[tikz,border=3.14mm]{standalone}
\usetikzlibrary{fit}
\usepackage{amssymb}
\begin{document}
\begin{tikzpicture}
\node [yscale=2.8,xscale=1.2,rotate=-5] (int)
{$\int_\mathtt{\partial}^{\mathtt{\aleph_0}}$};
\node (H1) at ([yshift=-1mm,xshift=2mm]int.east) {\textbf{\textsf{CAS}}};
\node (H2) at ([yshift=1mm,xshift=-1mm]int.west) {\textbf{\textsf{Fri}}};
\node[circle,draw,thick,fit=(int) (H1) (H2),inner sep=-4pt]{};
\end{tikzpicture}
\end{document}






On 20.08.2022 21:01, Bill Page wrote:
> 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/ef717da8-4465-69a1-2371-69597611a843%40gmail.com.


fricas_logo.pdf
Description: Adobe PDF document


logo:=[_
"   ",_
"   __     ",_
"  / /__(__) __/ __ | / / ",_
" / __// / / //  |__\ \   ",_
"/__/ /__/ /__/\__/__/ |__/__/   ",_
"=~=~=~=~==~=~=~=~==~=~=~=~=  "]

   (2)
   ["   __", "   _     ",
"  / __/___(_) ___/ _ | / __/ ", " / _// __/ / /__/ __ |_\ \   ",
"/_/ /_/ /_/\___/_/ |_/___/   ", "=~=~=~=~==~=~=~=~==~=~=~=~=  "]
   Type: List(String)
map(output,logo);
  __
  _    
 / __/___(_) ___/ _ | / __/
/ _// __/ / /__/ __ |_\ \
   /_/ /_/ /_/\___/_/ |_/___/
   =~=~=~=~==~=~=~=~==~=~=~=~=

 Type: List(Void)
Font: slant
__ _ _   _
   / /(_) /   | / ___/
  / /_  / ___/ / /   / /| | \__ \ 
 / __/ / /  / / /___/ ___ |___/ / 
/_/   /_/  /_/\/_/  |_//  


Font: small
 ____  ___   _   ___ 
| __| _(_)/ __| /_\ / __|
| _| '_| | (__ / _ \\__ \
|_||_| |_|\___/_/ \_\___/

Font: smshadow
 __|   _)  __|   \__|
 _|  _| | ( _ \ \__ \
_| _|  _|\___|_/  _\/
 

Font: smslant
   _    
  / __/___(_) ___/ _ | / __/
 / _// __/ / /__/ __ |_\ \  
/_/ /_/ /_/\___/_/ |_/___/  


Font: standard
 _ _  _  
|  ___| __(_)/ ___|  / \  / ___| 
| |_ | '__| | | / _ \ \___ \ 
|  _|| |  | | |___ / ___ \ ___) |

Re: [fricas-devel] FYI, CAS independent integration tests, summer 2022 edition completed

[Kurt Pagani]

Hi Nasser
Nice work!
Thanks and best regards
Kurt

p.s.
I'm quite surprised by the Sympy performance.
Not bad (IMO) for a pure Python system :)

On 21.08.2022 08:15, 'Nasser M. Abbasi' via FriCAS - computer algebra system 
wrote:
>  FYI,
> 
> (Posted at https://groups.google.com/g/fricas-devel and 
> https://groups.google.com/g/sci.math.symbolic)
> 
> Independent CAS integration tests summer 2022 edition is now complete.
> (It took about 5 months since I initially started working on it!)
> 
> 
> 
> The following is summary of changes in this version
> compared to last year's edition 
> 
> 1. Number of integrals increased to 85,479 from 71,994.
> 
> The integrals are made of the following 210 files:
> 
> a. Rubi test suite. Files 1 to 208. Thanks to Alert Rich. 
> Downloaded from 
> b. IntegrateAlgebraic test file. File 209. Thanks to Sam Blake.
> c. Fricas test file. File 210. Thanks to Waldek Hebisch.
> 
> 2. CAS version changes: 
> Maple 2021.1 -> 2022.1
> Mathematica 12.3 -> 13.01
> Giac 1.7.0 -> 1.9.0-13 
> Sympy 1.8/python 3.8.8 -> 1.10.1/Python 3.10.4 
> Maxima 5.44 -> 5.46
> FriCAS 1.3.7 -> 1.3.8 
> Sagemath 9.3 -> 9.6
> 
> No version change for Mupad at Matlab 2021a and Rubi at 4.16.1
> but Rubi was run again on the current Mathematica 13.1 version.
> 
> 3. General improvements to Latex and other formatting.
> 
> 4. Flow chart of the test program at
> 
> 
> 5. Links to download all the 85,483 integrals in plain text in 
> Mathematica, Rubi, Maple, Mupad, Sympy, and Sagemath (Fricas, Maxima, Giac) 
> formats are at introduction page of the main page.
> 
> 6. Regression reports comparing results in 2022 edition to 2021 edition
> are also now available. These reports show integrals that failed 
> in current versions compared to last versions per CAS. 
> 
> 
> 
> Regression per CAS
> --
> This table below gives the number of integrals that failed in 
> this test (could be due to timeout, exception or not solved) but 
> are solved in summer 2021 for each CAS.
> 
> Number of regression per CAS is (less is better)
> 
> Fricas: 16
> Maxima: 17
> Mathematica: 98
> Maple: 114
> Giac: 363
> Sympy: 379 
> 
> Tables give details about each integral that failed in regression.
> 
> 7. Sympy, Sagemath (Fricas, Maxima, Giac) were all run on Linux 
> inside Oracle Virtual Box. Maple, Rubi, Mupad and Mathematica were 
> run on windows 10. All on same PC with 128 GB RAM with 
> Intel Core i9-12900K 3.20 GHz.
> 
> RESULTS
> ===
> 
> Overall solved percentage in summer 2022 edition
> =
> 1. Mathematica 13.1 97.99 %
> 2. Rubi 4.16.1 94.21 %
> 3. Maple 2022.1 84.53 %
> 4. Fricas 1.3.8 79.33 %
> 5. Giac 1.9.0-13 58.37 %
> 6. Maxima 5.46 56.86 %
> 7. Mupad 2021a 56.1 %
> 8. Sympy 1.10.1 41.89 %
> 
> Grading results
> =
> Note that mupad is not graded. Default grade of B is given for 
> any passed integral.
> 
> 1. Rubi 91.50 %
> 2. Mathematica 78.58 % 
> 3. Maple 56.34 %
> 4. Fricas 53.78 %
> 5. Maxima 43.57 % 
> 6. Giac 42.36 %
> 7. Sympy 28.49 % 
> 8. Mupad* N/A
> 
> Time and leaf size Performance
> ==
> Sorted by time performance in average time used per integrals (seconds).
> 
> Note for Maple(*) timing: the option method=_RETURNVERBOSE was used 
> which made Maple run through all integration methods increasing 
> average time used. For example in summer 2021 edition which did 
> not use this option, Maple had 0.79 seconds average time on 
> a slower PC also than the one used for the current tests.
> 
> 1. Rubi 0.3 (sec)
> 2. Maxima 0.49 (sec) 
> 3. Giac 0.75 (sec) 
> 4. Fricas 1.17 (sec) 
> 5. Mathematica 2.38 (sec) 
> 6. Mupad 2.75 (sec) 
> 7. Maple* 3.33 (sec) 
> 8. Sympy 5.24 (sec) 
> 
> General notes
> ==
> 1) Maxima, Fricas and Giac were called via Sagemath. Some integrals 
> could have failed due to interface issues. These will have F(-2) 
> error code in the section "Detailed conclusion table per each 
> integral for all CAS systems" per each report and also in the actual 
> integral page with the actual exception name shown. 
> 
> This allows one to see if the cause of the failure is due to 
> interface issue or internal error from the CAS itself. 
> 
> For an example, the integral on
> 
> 
> 
> Has F(-2) on Fricas output, but looking at the exception
> 
> integrate(x*sin(a+b*log(c*x^n))^(1/2),x, algorithm="fricas")
> 
> "Exception raised: TypeError >> Error detected within library code:
> integrate: 

Re: [fricas-devel] Re: upload CI built binaries to nightly release

[Kurt Pagani]

A great convenience, +1 :)



On 20.08.2022 14:33, Qian Yun wrote:
> Done, you can see the result at:
> 
> https://github.com/fricas/fricas-nightly-builds
> https://github.com/fricas/fricas-nightly-builds/releases/tag/nightly
> 
> - Qian
> 
> On 8/18/22 18:57, Qian Yun wrote:
>> So this is my CI scripts, comments are welcome.
>>
>> Some comments:
>>
>> 1. You can see the testing nightly builds from
>> https://github.com/oldk1331/fricas/releases
>>
>> 2. It is hardcoded with my username right now, after setting up
>> repos in https://github.com/fricas, this script will be tweaked
>> and pushed to https://github.com/fricas/fricas.
>>
>> 3. I modified the binary filename to contain date so that it
>> is sorted by date in release page.
>>
>> 4. The scripts does not delete old files.  It may require us
>> to manually clean the release page (once a month is enough I think).
>>
>> 5. Failure of uploading will not make the whole script fail.
>>
>> @Rlaf, if you see my private email regrading repo permissions,
>> please reply.
>>
>> - Qian
>>
>> =
>>  - name: Upload to nightly release
>>    if: ${{ github.event_name == 'push' && github.event.ref ==
>> 'refs/heads/master' && github.repository == 'oldk1331/fricas' }}
>>    run: |
>>  export OWNER_REPO=oldk1331/fricas
>>  export RELEASE_ID=`curl
>> https://api.github.com/repos/${OWNER_REPO}/releases/tags/nightly | jq .id`
>>  curl -v -X POST -H "Accept: application/vnd.github+json" -H
>> "Authorization: token ${{ secrets.token }}"
>> "https://uploads.github.com/repos/${OWNER_REPO}/releases/${RELEASE_ID}/assets?name=FriCAS-$(date
>> +%Y-%m-%dT%H.%M)-linux-x86_64-$(echo ${{ github.sha }} | cut -c 1-8).tbz2"
>> --data-binary "@FriCAS-linux-x86_64-${{ github.sha }}.tbz2" -H "Content-Type:
>> application/x-bzip2" || 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/d12b095e-2af4-ae70-e95c-77753a494f41%40gmail.com.

Re: [fricas-devel] Re: FFI, CFFI, C2FFI, AUTOWRAP

[Kurt Pagani]

On 02.07.2022 19:08, Waldek Hebisch wrote:
> On Sat, Jul 02, 2022 at 10:10:11PM +0800, Qian Yun wrote:

...

> 
> What I would like to call:
> - matrix-matrix multiplication from BLAS
> - routines like solve, SVD, eigenvalue decomposition from Lapack
> - multiplication for polys over Z_p
> 
> That is rather small number of routines (of order of 20).  Generating
> signatures for them is not a problem.  What remains to solve:
> - detecting if there is BLAS/Lapack available and if yes in
>   which library (there are few competing BLAS libraries and
>   Lapack may be configured to use any of them).  To make
>   things more "interesting" original BLAS and Lapack interface
>   was in Fortran 77, there are now C wrappers
> - as I mentioned we need to solve problem of transfering data
>   to foreign routines
> 
> As I mentioned for sbcl we can use pinned objects, for Clozure CL
> and Clisp we need copy, for GCL ATM we just pass pointer to C
> side, but this is not guaranteed to work (basically we bet that
> GCL will not run its garbage collector during foreign call, which
> seem to work in current use.  So the remaing part is avalability
> of BLAS/Lapack.  In other words, problem is not FFI itself but
> managing dependencies.  This affects binary distributions
> because BLAS/Lapack tend to use machine specific instructions
> (BLAS using say AVX will fail on machine without AVX instructions).
> 

That sounds interesting.

There is also a very useful fortran to lisp translator (f2cl) available:

https://trac.common-lisp.net/f2cl/
https://trac.common-lisp.net/f2cl/wiki/GettingF2cl
http://quickdocs.org/f2cl/

"""
The easiest way to get F2CL is to use ​Quicklisp. You can just say
(ql:quickload :f2cl)
to get f2cl.
"""

I translated some examples (*)
(https://github.com/nilqed/f2cl/tree/master/packages/) some years ago (e.g.
BLAS) and it worked well, i.e. it seems easier to me to do lisp->spad than
c->spad.

(*) fortran sources partly from netlib.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/89c60e08-48f4-7bd7-ec56-81dc40c25b23%40gmail.com.

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

[Kurt Pagani]

On 17.06.2022 14:58, Qian Yun wrote:
> echo 100 | sudo tee /proc/sys/kernel/ns_last_pid
Hi Qian
Indeed!

---
fp@sirius:~$ echo 100 | sudo tee /proc/sys/kernel/ns_last_pid

100

kfp@sirius:~$ fricas

viewman not present, disabling graphics
hypertex  not present, disabling
*** buffer overflow detected ***: terminated
Aborted (core dumped)

kfp@sirius:~$ uname -a
Linux sirius 5.13.0-48-generic #54-Ubuntu SMP Wed Jun 1 20:38:48 UTC 2022 x86_64
x86_64 x86_64 GNU/Linux

kfp@sirius:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 21.10"
NAME="Ubuntu"
VERSION_ID="21.10"
VERSION="21.10 (Impish Indri)"
VERSION_CODENAME=impish
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/;
SUPPORT_URL="https://help.ubuntu.com/;
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
UBUNTU_CODENAME=impish

-- 
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/b20afdd8-7a57-b9f1-dfaa-b84eb2e1cfe2%40gmail.com.

Re: [fricas-devel] texmacs interface

[Kurt Pagani]

You're right, there is not much that's not already integrated in TeXmacs. On the
other hand, as a frequent Tm user, I'd suggest to update the folder and even
considering to fill it with useful addons instead ;) There is no doubt, Tm has
dramatically improved in the past years and the fricas interface should not be
left out in the cold. There are interesting features, like serializing and so
on,  which seem unique to me.

On this occasion I suggest to think about the "prompt" and the display of types
- not very nice from an aesthetic point of view. A first step could be to
rewrite the "markers" in the fricas start script, then one could edit various
items more easily:


markers=$(cat << EOF
)lisp (setf |\$ioHook| (lambda (x  args)
   (cond ((eq x '|startPrompt|) (princ (concat (code-char 2) "prompt\#") ))
 ((eq x '|endOfTeXmacsOutput|) (princ (concat (code-char 5) (code-char
10
 ((eq x '|startTeXmacsOutput|) (princ (code-char 2)))
 ((eq x '|startKeyedMsg|)  (princ (concat (code-char 2) "verbatim:")))
 ((eq x '|endOfKeyedMsg|)  (princ (code-char 5)))
 ((eq x '|endOfPrompt|) (princ (code-char 5) ))  )))

EOF
)


So, just as an a example, the user could set some variables to control the
output items mentioned above.

#
cc2="(code-char 2)"
cc5="(code-char 5)"
cc10="(code-char 10)"

#msgbeg="\"html:\""
#msgend="\"\""

msgbeg="\"latex:{}_{textsf{\""
msgend="\"}}\""

markers=$(cat << EOF
)lisp (setf |\$ioHook| (lambda (x  args)
   (cond ((eq x '|startPrompt|) (princ (concat $cc2 "prompt\#")))
 ((eq x '|endOfTeXmacsOutput|) (princ (concat $cc5 $cc10)))
 ((eq x '|startTeXmacsOutput|) (princ $cc2))
 ((eq x '|startKeyedMsg|)  (princ (concat $cc2 $msgbeg)))
 ((eq x '|endOfKeyedMsg|)  (princ (concat $msgend $cc5 $cc10)))
 ((eq x '|endOfPrompt|) (princ $cc5)

EOF
)

##

Obvioulsy, this is not as user friendly as it should be, however, most features
can also be controlled by a spad file.

To bring it back to your question, it's perhaps more favourable to handle these
things outside the fricas distribution (changed my mind during writing ;).

Best regards
Kurt



---
(2) -> )sh TMSPT
 TexmacsSupport is a package constructor
 Abbreviation for TexmacsSupport is TMSPT
 This constructor is exposed in this frame.
--- Operations 

 addDefaultStyle : () -> Void  addStyle : String -> Void
 changeZoomFactor : Float -> Void  clearAllFields : () -> Void
 closeSession : () -> Void command : String -> Void
 createSubsession : () -> Void evaluateAbove : () -> Void
 evaluateAll : () -> Void  evaluateBelow : () -> Void
 evaluateFieldsInOrder : () -> VoidfirstField : () -> Void
 fitAllToScreen : () -> Void   fitToScreen : () -> Void
 fitToScreenHeight : () -> VoidfitToScreenWidth : () -> Void
 foldAllFields : () -> Voidhtml : String -> Void
 inlineImage : String -> Void  input : String -> Void
 insertFieldAbove : () -> Void insertFieldBelow : () -> Void
 insertTextFieldAbove : () -> Void insertTextFieldBelow : () -> Void
 lastField : () -> Voidlatex : String -> Void
 linkImage : String -> VoidmathInput : String -> String
 message : (String, String) -> VoidnextField : () -> Void
 output : String -> Void   previousField : () -> Void
 prompt : String -> Void   ps : String -> Void
 removeBanner : () -> Void removeDefaultStyle : () -> Void
 removeLastField : () -> Void  removeNextField : () -> Void
 removePreviousField : () -> Void  removeStyle : String -> Void
 scheme : String -> Void   sessionEval : () -> Void
 showTimings : () -> Void  splitSession : () -> Void
 tmActive? : () -> Boolean toggleFooter : () -> Void
 toggleFullScreenMode : () -> Void toggleHeader : () -> Void
 toggleMathInput : () -> Void  toggleMathOutput : () -> Void
 toggleMultilineInput : () -> Void toggleTreeOutput : () -> Void
 unfoldAllFields : () -> Void  verbatim : String -> Void
 zoomIn : Float -> VoidzoomOut : Float -> Void
 toggleSchemeTreeOutput : () -> Void

On 15.05.2022 14:59, Ralf Hemmecke wrote:
> I was just wondering whether we still need to have the directory
> contrib/texmacs in the fricas repo. All these files have
> 
> COPYRIGHT   : (C) 1999, 2012  Joris van der Hoeven and Andrey Grozin
> 
> and fall under GPL3+ and FriCAS is not actually distributing them in the 
> binary
> tarballs. I also do not see that the texmacs directory is ever touched during 
> a
> normal build+install of fricas.
> 
> I suggest to remove contrib/texmacs, because they appear in the latest
> distribution of TeXmacs itself.
> 
> 

Re: [fricas-devel] Problem with retract

[Kurt Pagani]

Thank you for the detailed explanations. I see the problems and would agree that
keeping retraction to coefficients has priority. In user code one may easily get
along with the current state. In the meantime I've been trying to rewrite some
functions avoiding XDP, i.e. just using Free-Monoid/Module. In the course of
this I found the following peculiarity when using listOfTerms/construct:

R:=EXPR INT
FMR:=FreeModule(R,Symbol)
[a,b,c]:=[s::FMR for s in [a,b,c]]
T:=a+b+c
lT:=listOfTerms T
clT:=concat(lT,lT)
c1:=construct(clT)$FMR
c2:=constructOrdered(clT)$FMR
c1+c2
c1-c2
c1-c1
c1+c1
--- better!
d1:=reduce(_+,[construct([s])$FMR for s in clT])
d1-d1
d1+d1

Apparently it's favourable to construct each term as the single member of a
list, otherwise the collection/simpl procedure seems to be puzzled (like me).
Is this intentional?

On 30.04.2022 01:03, Waldek Hebisch wrote:
> I am looking at problem reported by Kurt Pagani.  Direct reason
> for trouble is that up to 1.3.6  FreeModuleCategory exported
> retraction to base set.  This retraction is no longer present
> in 1.3.7.  FreeModule still has such retraction, but
> XPolynomialRing which inherits implementation from FreeModule
> among other is of category FreeModuleCategory and no longer
> exports this retraction.  XDistributedPolynomial which officially
> exorts 'retract' used to inherit implementation from XPolynomialRing,
> but in 1.3.7 XPolynomialRing has no 'retract' so also
> XDistributedPolynomial has no implemetation of 'retract'.
> 
> At first glance this may look easy to fix.  But there is deeper
> trouble.  Trying to export 'retract' from FreeModuleCategory
> leads to trouble with polynomials.  Reason is easy to see:
> various retractions are distinguished only by target type.
> If we have several retractions with the same target type,
> then overloading does not work (retractions have quite
> different effects, but our overloading machinery gives no way
> to choose right one).  In particular, for univariate polynomials
> NNI is type of exponents, but also legal type for coefficients.
> Worse, NNI is subtype of Integer and our retraction machinery
> assumes that it can use retraction to Integer even when NNI is
> requested.
> 
> Anyway, in general having retraction both to T1 and T2 is unsafe
> unless we are sure that T1 is different than T2.  In case of
> commutative polynomials currently we have retraction to variables
> and retraction to coefficients.  AFAICS this is unsafe, as we can
> form SparseMultivariatePolynomial(Integer, Integer), that
> is Integer may serve both as coefficients and as variables.
> More generally, any ordered commutatitve semiring may serve
> such dual purpose.
> 
> In case of XDistributedPolynomial ATM there is only one exported
> retraction, that is retraction to exponents.  However, is would be
> natural to have retraction to coefficients (such retraction makes
> sense for any algebra with unit).  For XDistributedPolynomial
> this still is safe, as coefficients are required to be a ring
> and exponents are FreeMonoid which is not a ring.  But
> in case of XPolynomialRing in principle coefficients may be
> the same as exponents (both can be a ring), so having two
> retractions is unsafe.
> 
> I admit that ATM I am not sure what to do.  Inside algebra
> probably most sensible solution is to keep retraction from
> polynomials to coefficients (which is very fundamental) and
> avoid use of other retractions.  It is less clear if we
> should keep exporting extra retractions for use in user
> code or ban them as potentially unsafe.
> 

-- 
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/77ce72c1-7348-c875-2660-8462a32c37b3%40gmail.com.

Re: [fricas-devel] retract(s) missing ( Internal Error)

[Kurt Pagani]

On 24.04.2022 17:38, Ralf Hemmecke wrote:
>>> You do not need to create a new domain. It also fails to work with XDP in 
>>> the
>>> latest master.
>>
>> I was aware about that, however, the strange thing is that this failed 
>> already
>> in version 1.3.5.
> 
> Something I don't understand... you claim that retract$TestXDP works in 1.3.5
> although retract in XDP is claimed to be not implemented as you show below. 
> How
> can that be?

That's the question here :) -- a mystery @moment.

> 
> Anyway, for git-bisect it would be good to know FriCAS commit where 
> retract$XDP
> **is** actually working as expected. I guess that fixing XDP will also fix 
> TestXDP.
> 
> 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/3074030b-0b4b-a899-3d4e-f776efd03192%40gmail.com.

Re: [fricas-devel] retract(s) missing ( Internal Error)

[Kurt Pagani]

On 24.04.2022 17:14, Ralf Hemmecke wrote:
> Hi Kurt,
> 
> You do not need to create a new domain. It also fails to work with XDP in the
> latest master.

I was aware about that, however, the strange thing is that this failed already
in version 1.3.5.


(2) -> [x,y]:=[s::XDistributedPolynomial(Symbol,EXPR INT) for s in [x,y]]

   (2)  [x, y]
   Type: List(XDistributedPolynomial(Symbol,Expression(Integer)))
(3) -> x*y^3

   3
   (3)  x y
 Type: XDistributedPolynomial(Symbol,Expression(Integer))
(4) -> retract %

   >> Error detected within library code:
   FM1.retract impossible

(4) -> )version

Value = "FriCAS 1.3.5 compiled at Mi, 17. Apr 2019 03:15:11"
(4) ->

(4) -> retractIfCan(x*y^5);

Type: Union("failed",...)
(5) -> retractIfCan(x);

Type: Union("failed",...)

> 
> Actually, if I am not wrong than "A has C" only tells you that C is explicitly
> mentioned in the exports of A, but not whether there is an actual 
> implementation
> for C.

Yes, I also think so, however, when it worked, as it certainly did in 1.3.5,
then you wouldn't waste much time ;)

> 
> (1) -> Expression Integer has SemiRing
> 
>    (1)  true
> (2) -> R   ==> Expression Integer
> (3) -> SYM ==> Symbol
> (4) -> XDP  ==> XDistributedPolynomial(SYM,R)
> (5) -> [x::XDP for x in [X,Y,Z]]
> 
>    (5)  [X, Y, Z]
>    Type: List(XDistributedPolynomial(Symbol,Expression(Integer)))
> 
> (6) -> [a,b,c] := [x::XDP for x in [X,Y,Z]]
> 
>    (6)  [X, Y, Z]
>    Type: List(XDistributedPolynomial(Symbol,Expression(Integer)))
> (7) -> a
> 
>    (7)  X
>    Type: XDistributedPolynomial(Symbol,Expression(Integer))
> (8) -> r := a*b^2*c^4
> 
>    2 4
>    (8)  X Y Z
>    Type: XDistributedPolynomial(Symbol,Expression(Integer))
> (9) -> retract r
> Function:  retractIfCan : % -> Union(FreeMonoid(Symbol),"failed") is missing
> from domain: XDistributedPolynomial(Symbol,Expression(Integer))
>    Internal Error
>    The function retractIfCan with signature
>   (Union (FreeMonoid (Symbol)) failed)$ is missing from domain
>   XDistributedPolynomial(Symbol)(Expression (Integer))
> 
> (9) -> R
> 
>    (9)  Expression(Integer)
> 
> (10) -> R has SemiRing
> 
>    (10)  true
> 
> (11) -> XDP has RetractableTo(FreeMonoid SYM)
> 
>    (11)  true
> 
> However, looking down the implementation chain tells me that retract should be
> implemented through FreeModule(R,FreeMonoid SYM). But we have
> 
> (12) -> F := FreeModule(R,FreeMonoid SYM)
> 
>    (12)  FreeModule(Expression(Integer),FreeMonoid(Symbol))
> (13) -> F has RetractableTo(FreeMonoid SYM)
> 
>    (13)  true
> 
> (16) -> s := 'x::Symbol
> 
>    (16)  x
>    Type: Symbol
> (17) -> sf := s :: F
> 
>    (17)  x
>    Type: FreeModule(Expression(Integer),FreeMonoid(Symbol))
> (18) -> retract sf
> 
>    (18)  x
>    Type: FreeMonoid(Symbol)
> 
> So indeed, your detected error is weird.
> In fact, when you enter XDistributedPolynomial into HyperDoc browse, add the
> parameters vl=Symbol and R=Expression Integer, click on Operations and then on
> Implementation, it also tell you that retractIfCan is nowhere implemented.
> 
> My suspicion is that it has something to do with the conditional 
> implementation
> of retract in FreeModule. I faintly remember that I once had a similar issue.
> 
> Looks like someone must use "git bisect run" to find out which commit causes 
> the
> issue.

Thanks!
Kurt
> 
> Ralf
> 
> 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/4d2496dd-0200-4ac6-8afa-27ed0f9ecf30%40gmail.com.

[fricas-devel] retract(s) missing ( Internal Error)

[Kurt Pagani]

Some code using "retract" breaks since V1.3.7. I couldn't figure out which 
revs might be accountable for. Any clues?

Here a minimal sample:

)abbrev domain TSTXDP TestXDP
TestXDP() : Exports == Implementation where 
  R   ==> Expression Integer
  SYM ==> Symbol  
  XFS  ==> XFreeAlgebra(SYM,R)
  XDP  ==> XDistributedPolynomial(SYM,R)
  --
  Exports == Join( XFS) with
makeIt : SYM -> %
  Implementation == XDP add
Rep := XDP  
makeIt(s:SYM):% == s::Rep

==
V1.3.5
==
; compilation finished in 0:00:00.008

   TestXDP is now explicitly exposed in frame initial 
   TestXDP will be automatically loaded when needed from 
  /Users/kfp/Desktop/work/spad/pform/TSTXDP.NRLIB/TSTXDP

(1) -> )version

Value = "FriCAS 1.3.5 compiled at Mi, 17. Apr 2019 03:15:11"
(1) -> [X,Y,Z] := map(makeIt,[X,Y,Z])

   (1)  [X, Y, Z]
  Type: 
List(TestXDP)
(2) ->  r:=X*Y^2*Z^4

   2 4
   (2)  X Y Z
Type: 
TestXDP
(3) -> TestXDP has RetractableTo FreeMonoid Symbol

   (3)  true
Type: 
Boolean
(4) -> retract r

   2 4
   (4)  X Y Z
 Type: 
FreeMonoid(Symbol)
(5) -> 

==
V1.3.7
==
; compilation finished in 0:00:00.004

   TestXDP is now explicitly exposed in frame frame1
   TestXDP will be automatically loaded when needed from
  /tmp/TSTXDP.NRLIB/TSTXDP

(1) -> )version

Value = "FriCAS 2021-03-06 compiled at Fr 22 Apr 2022 15:24:45 CEST"
(1) -> [X,Y,Z] := map(makeIt,[X,Y,Z])

   (1)  [X, Y, Z]
  Type: 
List(TestXDP)
(2) ->  r:=X*Y^2*Z^4

   2 4
   (2)  X Y Z
Type: 
TestXDP
(3) -> TestXDP has RetractableTo FreeMonoid Symbol

   (3)  true
Type: 
Boolean
(4) ->  retract r
Function:  retractIfCan : % -> Union(FreeMonoid(Symbol),"failed") is 
missing from domain: TestXDP
   Internal Error
   The function retractIfCan with signature
  (Union (FreeMonoid (Symbol)) failed)$ is missing from domain TestXDP

(4) -> )sh TestXDP

...
 retract : % -> FreeMonoid(Symbol) 
 retractIfCan : % -> Union(FreeMonoid(Symbol),"failed")

-- 
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/a8253ad9-30f3-4043-97eb-e1857c92dbd7n%40googlegroups.com.

Re: [fricas-devel] Re: Debian package on github?

[Kurt Pagani]

There is one, however, its underlying Lisp is GCL. Unfortunately jfricas
requires SBCL or another bordeaux threads capable Lisp. Otherwise it works well 
;)

kfp@sirius:~$ apt search fricas
Sorting... Done
Full Text Search... Done
elpa-fricas/impish,impish 1.3.7-1 all
  General purpose computer algebra system: emacs support

fricas/impish,now 1.3.7-1 amd64 [residual-config]
  General purpose computer algebra system: main binary and modules

fricas-databases/impish,impish,now 1.3.7-1 all [installed,auto-removable]
  General purpose computer algebra system: generated text databases

fricas-doc/impish,impish,now 1.3.7-1 all [installed,auto-removable]
  General purpose computer algebra system: documentation

fricas-graphics/impish 1.3.7-1 amd64
  General purpose computer algebra system: graphics subsystem

fricas-graphics-data/impish,impish,now 1.3.7-1 all [installed,auto-removable]
  General purpose computer algebra system: graphics data

fricas-hypertex/impish 1.3.7-1 amd64
  General purpose computer algebra system: hypertex subsystem

fricas-hypertex-data/impish,impish,now 1.3.7-1 all [installed,auto-removable]
  General purpose computer algebra system: hypertex data

fricas-source/impish,impish,now 1.3.7-1 all [installed,auto-removable]
  General purpose computer algebra system: source files

fricas-test/impish,impish 1.3.7-1 all
  General purpose computer algebra system: regression test inputs


Greetings
Kurt



On 21.04.2022 21:10, 'Nasser M. Abbasi' via FriCAS - computer algebra system 
wrote:
> There is not one. At least I have never seen a Debian package for latest 
> Fricas. 
> 
>>apt-cache search --names-only '^fricas*'
>>
> 
> But it is easy enough to build Fricas from source on Ubuntu. 
> 
> Another option, which I used before is to use Arch Linux based distribution. I
> recommend Manjaro. Then you can simply install Fricas 1.3.7 with one click of 
> a
> button, using its GUI installer, since Fricas package exist on AUR for all 
> Arch
> linux based distributions.  It will download it and install for you.
> 
> https://aur.archlinux.org/packages/fricas
> 
> Nasser
> 
> 
> On Wednesday, April 20, 2022 at 10:06:34 AM UTC-5 ra...@hemmecke.org wrote:
> 
> On https://github.com/fricas/fricas/releases/tag/1.3.7
>  I see the source
> distribution of FriCAS.
> 
> Do we have a FriCAS 1.3.7 debian package (using sbcl) for Ubuntu 20.04
> or 18.04?
> 
> 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/fbe621f1-4801-49df-a4bd-33e88d5a2ea6n%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/79ea2374-b748-09ec-2982-59ff6b70f641%40gmail.com.

Re: [fricas-devel] write!(f, Integer)

[Kurt Pagani]

For instance,

FORMAT('NIL,"~12,'0d",123)$Lisp
 "0123"

s:=s.(1..#s-1) 
s:=string FORMAT('NIL,"~0,20$",123)$Lisp 
"0123" 

https://en.wikipedia.org/wiki/Format_(Common_Lisp)

On Wednesday, 13 April 2022 at 18:47:27 UTC+2 ra...@hemmecke.org wrote:

> On 13.04.22 18:03, Sid Andal wrote:
> > The output file type is for Integers and each solution (hundreds of 
> > thousands of them) is tagged with a six-digit integer identifier for 
> > searching and analysis purposes. Leading zeros allow to distinguish
> > these tags from other integers (the solutions).
>
> Are you sure you want a leading zero as a distinction of the different
> types of solutions?
>
> A little example of input/output would have been very helpful.
>
> > I was thinking about converting the tags with leading zeros into
> > strings, but, then writing them out will be a problem since output
> > file is of type Integer.
>
> Hmmm... first thing that comes to my mind is add 10^50 to your tags and 
> then rely on the fact that a "tag" number starts with "10". ;-)
> Honestly, I find the File(S) feature rather lispy, anyway. It's 
> seamingly not really meant for communication with other programs, but 
> rather with writing out and reading back into FriCAS itself.
>
> But, Kurt has another solution. You can use the function FORMAT from the 
> Lisp that is present underneath FriCAS. That is not a SPAD-only 
> solution, but for your purpose it would probably be the simplest way to 
> achieve your goal.
>
> I leave it to Kurt to post the details.
>
> 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/95135ae4-119b-488d-a73b-3243296b9b14n%40googlegroups.com.

Re: [fricas-devel] latex symbols in fmtmathjax

[Kurt Pagani]

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

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



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

-- 
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/bf15797b-0349-22f6-498b-bfcabe19a625%40gmail.com.

Re: [fricas-devel] latex symbols in fmtmathjax

[Kurt Pagani]

On 02.05.2021 17:29, 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. 

++1

In my view it's simpy great. For example, one can (deliberately!) write
a:="\alpha"::Symbol or hb := "\hbar"::Symbol::EXPR INT, then 'a', 'hb' will be
rendered as 훼,ℏ as soon as we set

  setPrettySymbols! true

It does no harm to OutputForm at all; moreover, one is not urged to use special
identifiers (like alpha, %alpha, ...) and, last but not least, it works for
BasicOperator as well :)



> 
> 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] INSTALL

[Kurt Pagani]

On 19.04.2021 21:26, Waldek Hebisch wrote:
...
> 
> Mainly the second, INSTALL should be readable as plain text.
> It is OK to have marked up version as master source.  Some
> markup formats can produce decent looking plain text versions
> (IIUC sphinx is supposed to produce text version, but ATM
> this does not work for me so in particular I can not see
> if this is good enough).  Another issue is dependency. .rst
> is claimend to be ligtweight, but supporting programs are
> rather large...

That's true, however, there are a lot of little helpers around, e.g.

Emacs Support for reStructuredText
https://docutils.sourceforge.io/docs/user/emacs.html

> 

https://pandoc.org/MANUAL.html

This (usually) provides good results:

pandoc --from=rst --to=plain filename.rst

OTOH --from=plain --to=rst is not always what you'll expect.




-- 
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/b381a783-5971-3bb8-6679-e9ffdf1d8cdd%40gmail.com.

Re: [fricas-devel] New README

[Kurt Pagani]

On 18.04.2021 17:34, Ralf Hemmecke wrote:
>> http://www.math.uni.wroc.pl/~hebisch/fricas/README
...
> 
> https://stackoverflow.com/questions/2351190/static-dynamic-vs-strong-weak
> 
> If I look at what they write in the first reference than with our
> "pretend" keyword, SPAD would be weakly typed.
> 

I'm advertising for 'strongly typed'. First of all, we claim it in
https://en.wikipedia.org/wiki/FriCAS and second - following the link:

"""
Generally, a strongly typed language has stricter typing rules at compile time,
which implies that ...
"""

That's just what we find, don't we? Using "pretend" should be last resort.

...
> 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/9e0a953f-0a9d-3674-99ef-6fbb9eade62a%40gmail.com.

Re: [fricas-devel] 4ti2 and )set message time on

[Kurt Pagani]

On 16.04.2021 00:39, Waldek Hebisch wrote:
> On Thu, Apr 15, 2021 at 05:59:54PM +0200, Ralf Hemmecke wrote:
>> I am calling an external program in a .spad file like this:
>>
>> systemCommand(cmd)$MoreSystemCommands
>>
>> where cmd is
>>
>> "system /usr/bin/zsolve-4ti2 DATA"
>>
>> When I switch on timing I get something like and call the function from
>> my .spad file, I get
>>
>> Time: 0 (IN) + 0.04 (EV) + 0.00 (OT) = 0.05 sec
>>
>> although the actual computation (via 4ti2) took actually longer than one
>> minute.
>>
>> Understandibly, the time spent in FriCAS is negligible, but is there
>> some way to tell FriCAS to show the time spent in the external computation?
> 
> ATM no.  This requires support in operationg system which in turn
> would require support in Lisp.  

According to
https://stackoverflow.com/questions/6065446/executing-a-shell-command-from-common-lisp,
"uiop:run-program" is a viable solution.
"Trivial shell" also works fine: https://common-lisp.net/project/trivial-shell/,
however, requires some installations, whereas "uiop" loads with "(require 
:asdf)".

syscmd(s) ==> systemCommand(s)$MoreSystemCommands
lisp1(s)  ==> syscmd(string(FORMAT('NIL,"lisp ~A",s)$Lisp))

Example: sleep 2 sec

lisp1 "(require :asdf)"
lisp1 "(time (uiop:run-program _"sleep 2_" :output *standard-output*))"

thus:

mysys(cmd) == lisp1(FORMAT('NIL, "(time (uiop:run-program _"~A_" _
:output *standard-output*))", cmd)$Lisp)


(11) -> mysys "sleep 4"
   Compiling function mysys with type String -> Void
Evaluation took:
  4.049 seconds of real time
  0.00 seconds of total run time (0.00 user, 0.00 system)
  0.00% CPU
  4 forms interpreted
  12,522,875,702 processor cycles
  65,504 bytes consed

> We probably could do this using
> implementation specific features, but up to now nobody implemented
> it.
>

Would it be wortwhile at all? IMO everyone can piece together a function using
the simple lisp constructions mentioned above.




-- 
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/94acb964-33c6-182d-4175-b5556d15cef3%40gmail.com.

Re: [fricas-devel] Interfacing C functions (with SBCL)

[Kurt Pagani]

The problem seems to be known for a long time. It works when "compiled" but not
when interpreted.

https://bugs.launchpad.net/sbcl/+bug/1731556
https://bugs.launchpad.net/sbcl/+bug/992362
https://bugs.launchpad.net/sbcl/+bug/734259


Note: I added a "(in-package :cl-user)" top in your test.lsp, otherwise you are
in package "BOOT" where symbol conflicts may occur, e.g. (coerce 0 
'double-float):


   FriCAS Computer Algebra System
Version: FriCAS 1.3.5
Timestamp: Mi, 17. Apr 2019 03:15:11
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-

   Function declaration sixel : TexFormat -> Void has been added to
  workspace.
   Type: Void
   Function declaration quickLoad : String -> Void has been added to
  workspace.
   Type: Void
(3) -> )lisp (load "test.lsp")

Value = T
(3) -> )lisp (compile "test.lsp")

   >> System error:
   Invalid function name: "test.lsp"

(3) -> )lisp (compile testfun)

   >> System error:
   The variable TESTFUN is unbound.

(3) -> )lisp (compile 'testfun)

   >> System error:
   The function BOOT::TESTFUN is undefined.

(3) -> )lisp (compile 'cl-user::testfun)

Value = COMMON-LISP-USER::TESTFUN
(3) -> )lisp (testfun 10.0d0)

   >> System error:
   The function BOOT::TESTFUN is undefined.

(3) -> )lisp (CL-USER::testfun 10.0d0)

Value = #C(10.0 31.402)
(3) ->



This link may ALSO be helpful:
https://stackoverflow.com/questions/21353376/how-to-use-double-float

Although I find it realy ghastly interfacing C in fricas (but if, why not using
CFFI?)

>   The value
> 0.0d0
>   is not of type
> (SB-ALIEN:ALIEN (* T))


)lisp (defun |foo| (x) x)
foo(7)$Lisp -> 7
foo(7.2)$Lisp ->  (265633114661417543270 . - 65)
foo(7.2::DoubleFloat)$Lisp ->  7.199

)lisp  (coerce 0 'double-float)
)lisp (defun mycoerce (x) (cl-user::coerce x 'double-float))





On 13.04.2021 03:03, Tobias Neumann wrote:
> I've noticed that FriCAS doesn't have a numerical implementation of polylog's 
> yet.
> So I will have to interface some C/Fortran code. For that I have constructed 
> a small
> example:
> 
> test.c:
> void testfun(double arg, double* realpart, double* imagpart)
> {
>     *realpart = 1.0 * arg;
>     *imagpart = 3.14 * arg;
>     return;
> }
> gcc -shared -o libtest.so test.c
> 
> test.lsp:
> (sb-alien:load-shared-object "./libtest.so")
> (defun testfun (arg)
>     (sb-alien:with-alien ((repart (double-float) 0.0d0) (impart (double-float)
> 0.0d0))
>         (sb-alien:alien-funcall
>           (sb-alien:extern-alien "testfun" (sb-alien:function sb-alien:void
> (double-float) (* double-float) (* double-float)))
>           arg (sb-alien:addr repart) (sb-alien:addr impart)
>          )
>         (complex repart impart)
>     )
> )
> 
> And I can successfully use that function within sbcl:
> sbcl --load "test.lsp"
> (testfun 10.0d0)
> #C(10.0d0 31.402d0)
> 
> Within FriCAS I ran ")lisp (load "test.lsp")" and it
> seems to parse/load the file successfully, but I can't directly use that
> function, i.e.  (testfun 10.0d0) within ")fin", and neither from within FriCAS
> as TESTFUN(1$DoubleFloat)$Lisp:
> 
> debugger invoked on a TYPE-ERROR in thread
> #:
>   The value
>     0.0d0
>   is not of type
>     (SB-ALIEN:ALIEN (* T))
>   from the function type declaration.
> 
> As it turns out, somehow I can not give it an initial value here, and I just
> have to declare it with (repart (double-float)), which is fine, but I am
> wondering why.
> 
> The final step for me is to convert the SExpression into a FriCAS
> Complex(DoubleFloat). For that I looked into the SExpression domain, and it
> seems to be easiest to instead return (list repart impart) and then have
> something like: 
> 
> testfun(xx) == 
>     res := TESTFUN(xx :: DoubleFloat)$Lisp
>     complex(float car res, float car cdr res) 
> 
> Presumably I could convert this into Complex(DoubleFloat) within the Lisp code
> directly with some SPADCALL calls? But the current way seems to be perfectly
> fine, but I am wondering if this is the right/recommended way to do it. 
> Overall
> I'm really happy how easy this turned out to be.
> 
> Thanks,
> Tobias
> 
> -- 
> 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
> 

Re: [fricas-devel] inverting matrixes over rings

[Kurt Pagani]

On 13.04.2021 11:35, Prof. Dr. Johannes Grabmeier privat wrote:
> the FriCAS code for inverting matrices over R is not correct. If wished
> I can provide the necessary changes to matfuns.spad

From my side, please do ;)

(2) -> IU := inverse(U)@Matrix(R)

   An expression involving @ Matrix(IntegerMod(26)) actually evaluated
  to one of type Union(Matrix(Fraction(Integer)),"failed") .
  Perhaps you should use :: Matrix(IntegerMod(26)) .

(2) -> IU := inverse(U)::Matrix(R)

+1  24+
   (2)  | |
+0  1 +
 Type: Matrix(IntegerMod(26))


)sh Matrix(R) => provides no inverse, indeed.


> 
> Problem: recip returns "failed", inverse coerces to Fraction Integer:
> 
> (1) -> R := IntegerMod 26
> 
>    (1)  IntegerMod(26)
>   
>    
> Type: Type
> 
> (2) -> U : Matrix R := [[1,2],[0,1]]
> 
>     +1  2+
>    (2)  |    |
>     +0  1+
>    
> Type: Matrix(IntegerMod(26))
> (3) -> recip U
> 
>    (3)  "failed"
>   
> Type: Union("failed",...)
> (4) -> inverse U
> 
>     +1  - 2+
>    (4)  |  |
>     +0   1 +
>   Type:
> Union(Matrix(Fraction(Integer)),...)
> 
> 
> The desired result should be the following:
> 
> (72) -> inverse U
> 
>  +1  24+
>    (72)  | |
>  +0  1 +
>  Type:
> Union(Matrix(IntegerMod(26)),...)
> 
> 

-- 
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/94649bb7-c3dc-07b3-d27e-2038de129d2c%40gmail.com.

Re: [fricas-devel] Airy, Bessel and hypergeometric functions

[Kurt Pagani]

Oh, I must have had some other Fortran code in mind (Gautschi has only $p\in
(0,1)$, indeed).

https://jblevins.org/mirror/amiller/

I guess it was the one below, but there are some others (CTRL-F Bessel ...)
https://jblevins.org/mirror/amiller/cbsslj.f90
cbsslj.f90 Complex Bessel function J_{\nu}(z) where both the argument, z, and
the order, \nu, are complex.

Anyway, it makes hardly sense to convert F90 to fricas, but it may be helpful
for comparing purposes.





On 08.04.2021 20:06, Waldek Hebisch wrote:
> On Thu, Apr 08, 2021 at 07:17:42PM +0200, Kurt Pagani wrote:
>> Maybe you are already aware of
>>
>> COMPUTATION OF BESSEL AND AIRY FUNCTIONS AND OF RELATED GAUSSIAN QUADRATURE
>> FORMULAE by WALTER GAUTSCHI
>> https://www.cs.purdue.edu/homes/wxg/selected_works/section_02/169.pdf
> 
> Thanks for reference.
> 
>> The code is in Fortran though.
>> https://www.cs.purdue.edu/archives/2001/wxg/codes/
>>
>> IMO it would be easier, however, if we took it from GSL:
>> https://www.gnu.org/software/gsl/doc/html/specfunc.html
>> Bill  wrote an interface: 
>> https://github.com/billpage/gsla/blob/master/gsl.lisp
> 
> Both ilutrate what I wrote: Gautschi has 0 has real arguments.  As I wrote, there are good looking
> implementations for real p (and complex x).  A have a toy
> multiple precision implementation, it is fast enough
> if arguments are resonably small.  OTOH our Bessel J and
> H01 also seem to havve resonable accuracy when arguments
> are small.  The problem is large arguments.  Also, it
> would be silly to use multiple precision implementation
> to get double accuracy, but do not provide real multiple
> precision implementation.  But with multiple precision
> results problem of large arguments gets worse...
> 
> Just to be clear: in case of Airy we can try to hide
> bug, that is provide low accuracy version.  That
> would be easy, but the accuracy problem would come back
> later.  The point is to sort out the mess so that
> it works.  And ATM it seem that nobody else did this
> in really satisfactory way, so appearently we should
> be first to do 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/425b014f-d3b4-b62f-b694-2c57be034a6e%40gmail.com.

Re: [fricas-devel] Airy, Bessel and hypergeometric functions

[Kurt Pagani]

Maybe you are already aware of

COMPUTATION OF BESSEL AND AIRY FUNCTIONS AND OF RELATED GAUSSIAN QUADRATURE
FORMULAE by WALTER GAUTSCHI
https://www.cs.purdue.edu/homes/wxg/selected_works/section_02/169.pdf

The code is in Fortran though.
https://www.cs.purdue.edu/archives/2001/wxg/codes/

IMO it would be easier, however, if we took it from GSL:
https://www.gnu.org/software/gsl/doc/html/specfunc.html
Bill  wrote an interface: https://github.com/billpage/gsla/blob/master/gsl.lisp



On 08.04.2021 18:13, Waldek Hebisch wrote:
> This is mainly to let you know why bug fixes take so much
> time.  There is old bug, namely our numeric Airy functions
> fails for positive real arguments (and gives quite wrong
> results for some complex arguments).  Problem is that
> our current formula for Airy Ai uses Bessel functions and
> square root.  For some arguments (including positive reals)
> we get wrong branch of square root and conseqently
> completely wrong result.  Mathematically, fix
> looks easy.  Namely there is formula for Airy Ai:
> 
> Ai(x) = (3)^(-2/3)*(1/Gamma(2/3))*H01(2/3, (1/9)*x^3) -
> (3)^(-1/3)*(1/Gamma(1/3)* x*H01(4/3, (1/9)*x^3)
> 
> where H01 is hypergeometric function.  H01 is analytic
> for all complex x, so no problem with branches.  But
> it has two problem, one fundamental.  First, for
> positve reals H01 grows quite fast while Ai decays fast.
> So we are subracting two large numbers to get tiny
> difference, which leads to significant loss of
> accuracy (this is fundamental problem).  This one can
> be corrected by expressing Ai in terms of Bessel K
> function (this only for limited set of arguments, as
> outherwise we would get back problems with branches).
> However, our Bessel K uses formula that is similar
> to expression for Ai above, and in particular has
> the sane problem with loss of accuracy that we are
> trying to avoid...
> 
> Other problem is that for some arguments our H01 is
> quite inaccurate.  Now, H01 is closely related to Bessel
> J function:
> 
> H01(p, x) = (sqrt(-x))^(-(p-1))*Gamma(p)J_{p-1}(2 sqrt(-x))
> 
> For efficiency it makes some sense to have separate
> special method for Bessel J and for H01, but one
> can use common method just doing little adjustment
> implied by equation above.  Certainly, there is no
> reson to have significant difference in accuracy.
> For positive reals formula for H01 means that we take
> square root of negative number, that is evaluate
> Bessel J at imaginary arguments.  Alternativly, one
> can use Bessel I function.  Again, for complex arguments
> Bessel J and Bessel I are closely related and one
> can use common method.  But our (Boot) code for
> Bessel J and Bessel K differ quite a lot.  In particular
> Bessel I raises error for most arguments.  This means
> we have not only problem with Airy functions, but
> also we have problem with Bessel functions (and H01).
> 
> I looked at methods used to compute Bessel functions.
> There are some:
> - direct use of power series (good only for small x)
> - asymptotic expansions (needs large x or p)
> - Chebyshev series (moderate arguments)
> - recurences
> 
> There are several asymptotic expansions, each with its
> validity conditions and with different errors.  It seems
> that most expansions are given without error bounds, so
> it is not clear where they are really useful.  Recurences
> have problem with stability, some are claimed stable,
> but this is probably valid only for real p and real x.
> My calculations suggest that in "interesting" ranges
> of p and x recurences are unstable.  What looked
> like easy bugfix expanded to a research program...
> 
> Anyway, it took some time and I probably will postopone
> fixing this one past current release.  But there are
> few other "easy looking" potential fixes...
> 
> BTW: Obvious thing to do is to look at other implementations.
> ATM I have not found "full range" implementation, that
> is one giving good accuracy for all arguments where
> function may be computed (there good looking implementations
> for real p).  According to various papers Mathematica
> is using multiple procision which gives good accuracy,
> but is so slow for some arguments that range is
> limited by compute time.  AFAICS the same it true of
> mpmath.
> 

-- 
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/07d9bb7d-d412-0d06-a619-7f46cd65a2f9%40gmail.com.

Re: [fricas-devel] The function leadingTerm with signature hashcode is missing from domain UnivariatePuiseuxSeries

[Kurt Pagani]

> I think also the web API could be improved. For example when I started using
> FriCAS I didn't realize that 
> a lot of functions have descriptions, but only when it track them back to the
> category where
> they are defined. So
> on https://fricas.github.io/api/UnivariatePuiseuxSeries.html you don't see 
> that
> order can run into problems, only
> on https://fricas.github.io/api/UnivariatePowerSeriesCategory.html
> Other functions like leadingMonomial don't have such warnings at all.
>

A ")show ups" reveals that it is not pretended having leadingTerm being
available. So the API is IMO not generally binding in the sense that the
parameters have yet to be determined. I rely on ")show XY", i.e. when the type
is complete (as you surely noticed there may be a lot of "if X has Y" in the
sources).

-- 
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/614203ee-a7de-2452-5243-f8108179ab5d%40gmail.com.

Re: [fricas-devel] The function leadingTerm with signature hashcode is missing from domain UnivariatePuiseuxSeries

[Kurt Pagani]

ups inherits from IndexedProductCategory(A, S)
leadingTerm: % -> Record(k: S, c: A) if S has Comparable

leadingTerm(x) returns the leading (with respect to the ordering on the
indexing set) term of z. Error: if z has no support.

EI has Comparable -> true, but I guess there is no support in IPC.

At least this works:

(2) -> terms(monomial(1, 1/2)$ups)$ups

  1
   (2)  [[k = -, c = 1]]
  2
Type: Stream(Record(k: Fraction(Integer),c: Expression(Integer)))



(3) -> leadingMonomial(monomial(1, 1/2)$ups)$ups

 1
 -
 2
   (3)  t
   Type: UnivariatePuiseuxSeries(Expression(Integer),t,0)



(3) -> terms leadingMonomial(monomial(1, 1/2)$ups)$ups

  1
   (3)  [[k = -, c = 1]]
  2
Type: Stream(Record(k: Fraction(Integer),c: Expression(Integer)))


thus

   leadingTerm x ==> terms leadingMonomial x


(5) -> leadingTerm(monomial(1, 1/2)$ups)

   1
   (5)  [[k = -, c = 1]]
   2
Type: Stream(Record(k: Fraction(Integer),c: Expression(Integer)))

may be a work-around.





On 02.04.2021 23:35, Tobias Neumann wrote:
> EI ==> Expression(Integer)
> ups := UnivariatePuiseuxSeries(EI,'t,0)
> 
> leadingTerm(monomial(1, 1/2)$ups)$ups
> 
>    Internal Error
>    The function leadingTerm with signature hashcode is missing from
>       domain UnivariatePuiseuxSeries(Expression (Integer))t((0 . 0) 0 . 1)
> 
> It seems like this is just missing implementation in the series expansion
> domains, just like `leadingSupport`, unless I'm overlooking something.
> 
> Tobias
> 
> -- 
> 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/5d0d8f66-47ae-453d-b1fd-43946b0f6a9en%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/f6963e9d-ff10-27ba-45a3-a484cdad1cfa%40gmail.com.

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

[Kurt Pagani]

On 23.03.2021 20:41, Bill Page wrote:
> 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.  

That's all past now. Ralf refactored the Lisp code to a minimum:
https://github.com/fricas/jfricas/blob/master/jfricas/webspad.lisp
The kernel itself is now Python based:
https://github.com/fricas/jfricas/tree/master/jfricas
Just two files ;)

The dependency is https://edicl.github.io/hunchentoot/
We require a version of FriCAS_ which was compiled with a Common Lisp that
supports multithreading and Hunchentoot. We recommend SBCL 1.4.5 or later.

>From the website above:
"""
It currently works with LispWorks and all Lisps which are supported by the
compatibility layers usocket and Bordeaux Threads.
"""

We've tested SBCL and ECL only, and it also works in WSL at least.

> 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 guess you're thinking of the "old" (lisp based) Jupyter kernel (?). It was too
hard to maintain because the dependency on the cl libraries, especially ZMQ
changed too often.
https://github.com/nilqed/fricas_jupyter is **deprecated** ! I have to edit the
README ASAP.


-- 
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/354cfcd6-09c7-a33f-8803-0fcf33fd5d90%40gmail.com.

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

[Kurt Pagani]

On 24.03.2021 13:20, Andrey G. Grozin wrote:
> On Tue, 23 Mar 2021, Ralf Hemmecke wrote:
>>> Or send stuff to plot to gnuplot (that's what Maxima does)
>> Would be an idea, but the original AXIOM developers obviously had some
>> interaction (dynamic graphic) in mind. Not sure whether that would work
>> with gnuplot. Don't ask more opinion from me. I'm not in the graphics
>> world and haven't any need for graphics currently. If you know someone
>> who is able to work on the FriCAS graphics system, then send him/her to
>> us. Ideas and code are welcome.
> 
> A few years ago my student tried to use geomview as a 3D backend instead of 
> the
> standard fricas 3D viewer. geomview (http://www.geomview.org/) is very
> interactive: it can show several 3D objects (various kinds of plots), you can
> rotate, translate, zoom etc. each of them, or all together, or some subsets of
> objects. Objects are described in a lisp-like language; these descriptions 
> were
> generated by draw and sent to geomview via pipes. He had some semi-working
> prototype; unfortunately, he has got his bachelor degree and left. I'm not 
> sure
> if I still have his code somewhere.
> 
> If we want an interactive 3D graphics backend, geomview is very good at it.
> Unfortunately, its development seems to stop. The last release, 1.9.5, is from
> 2014. It still works nicely. It uses motif, not a very fasionable toolkit, but
> motif is now free and can be easily installed.

I remember "geomview" well. It was widely used in the old days. But interactive
3d is another topic. In this case I would focus on VTK and ParaView (both BSD):

https://en.wikipedia.org/wiki/VTK
https://en.wikipedia.org/wiki/ParaView

Writing related 3d format files is quite easy in fricas.



> 
> Just an idea.
> 
> Andrey
> 

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/68d0df29-0472-208a-2340-e032c711d510%40gmail.com.

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

[Kurt Pagani]

>>
>> Since (AFAIK) there is no graphics library for CL, I see no alternative other
>> than resorting to an external tool - nobody will write a lib from scratch ;)
> 
> there is no graphics in CL standard, but you certainly have plenty of
> choices to pick
> CL bindings to various graphics libraries
> https://www.cliki.net/graphics%20library
> 

You're right and I looked at that list several times in the past. In the end we
land on CFFI or a Lisp pipe. Interfacing is not the problem. Most of those libs
could be accessed by the same method as Bill used for gnuDraw
(https://fricas.github.io/api/GnuDraw.html). I also tried some from
https://www.cliki.net/plotting, especially "vgplot"
(https://www.cliki.net/vgplot) is noteworthy.

-- 
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/25c50041-d819-b36d-4833-4814b549b191%40gmail.com.

Re: [fricas-devel] Bug in Complex

[Kurt Pagani]

Not at all ;) It shows once more that DF ought to have no place in a CAS. DF is
a source of confusion on its own. I'd use Interval(Float) or Float, if need be 
...
BTW 0.5 and 1/2 have different types. The interpreter is sometimes too 
broadminded.


On 19.02.2021 01:17, Tobias Neumann wrote:
> Maybe this is most convincing:
> 
> (3) -> ((-1) :: Complex(DoubleFloat))^(0.5)
> 
>    (3)  6.123233995736766e-17 - %i
>                                                    Type: Complex(DoubleFloat)
> (4) -> ((-1) :: Complex(DoubleFloat))^(1/2)
> 
>    (4)  %i
>                                                    Type: Complex(DoubleFloat)
> 
> I would say that this is undesired behavior and just confuses people.
> 
> -- 
> 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/da5f99f4-3951-4052-9f73-515bb7ef6c66n%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/edc1bce4-2ca2-beba-9c5e-c8d084f5c08e%40gmail.com.

Re: [fricas-devel] missing implementation bug (?)

[Kurt Pagani]

The strange thing is, that *now* there's no need to get the macros out of the
body ;) Hence, I guess the problem is related to type coercion. If you could
rewrite the macros to local functions (w. types), e.g. minrootpol(X:Type):?,
then ... maybe.


f2(): Void ==
  minrootpol(X) ==> monomial(1,2)$SUP(X) + 1
  CX(Y) ==> SimpleAlgebraicExtension(Y, SUP Y, minrootpol Y)
  px2 := px()$Foo(CX(C), L1 CX(C))
  dbgPrint("px2", px2)

On 04.11.2020 17:45, Ralf Hemmecke wrote:
>> Seemingly it also works by using macros, so this may be a work-around?
>> Not nice perhaps, but ...
> 
> Great. Thank you for this suggestion. Unfortunately, it only helps in my
> cut-down example for the demonstration of the problem, but my actual
> code is more complicated and there it's not so easy to use macros. It
> would lead to re-evaluation of functions that I only want to compute
> once. Also introducing a new function and passing the respective
> function values as parameters did not work. But maybe I was not careful
> enough.
> 
> I'll try to figure out what Waldek's suggestion might mean for my code.
> It is unfortunate anyway that this restriction and its possible
> workaround is not documented. :-(
> 
> 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/5c048e79-6c0f-f2bc-c183-d6ccfbd34b94%40gmail.com.

Re: [fricas-devel] missing implementation bug (?)

[Kurt Pagani]

On 04.11.2020 11:47, Ralf Hemmecke wrote:
> On 11/4/20 12:05 AM, Kurt Pagani wrote:
>> Strange, indeed. The CATs seem to be ok.
>> When taking minrootpol and CX out of the body of f2, the it works.
> 
> OK, good to know, but I don't think it will help me since in fact, I
> want to get minrootpol from
> 
>   cyclotomic(n)$CyclotomicPolynomialPackage
> 
> and the n is computed from some other data at runtime.
> So moving it out of the function is not of big help, since I want to
> create this SimpleAlgebraicExtension at runtime.

Seemingly it also works by using macros, so this may be a work-around?
Not nice perhaps, but ...

Bar(C: IntegralDomain): with
f1: () -> Void
f2: () -> Void
  == add
--minrootpol: SUP C := monomial(1,2)$SUP(C) + 1
--CX ==> SimpleAlgebraicExtension(C, SUP C, minrootpol)

minrootpol(X) ==> monomial(1,2)$SUP(X) + 1
CX(Y) ==> SimpleAlgebraicExtension(Y, SUP Y, minrootpol Y)

f1(): Void ==
  px1 := px()$Foo(C, L1 C)
  dbgPrint("px1", px1)

f2(): Void ==
  px2 := px()$Foo(CX(C), L1 CX(C))
  dbgPrint("px2", px2)

-- 
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/de860e82-bac9-10ed-be8c-ff5895a6e219%40gmail.com.

Re: [fricas-devel] missing implementation bug (?)

[Kurt Pagani]

Strange, indeed. The CATs seem to be ok.
When taking minrootpol and CX out of the body of f2, the it works.


)abbrev package BAR Bar
Bar(C: IntegralDomain): with
f1: () -> Void
f2: () -> Void
  == add

minrootpol: SUP C := monomial(1,2)$SUP(C) + 1
CX:=SimpleAlgebraicExtension(C, SUP C, minrootpol)

f1(): Void ==
  px1 := px()$Foo(C, L1 C)
  dbgPrint("px1", px1)

f2(): Void ==
  px2 := px()$Foo(CX, L1 CX)
  dbgPrint("px2", px2)

   Bar is now explicitly exposed in frame initial
   Bar will be automatically loaded when needed from
  /Users/kfp/AppData/Local/Temp/BAR.NRLIB/BAR

(3) -> f2()$BAR(FRAC INT)
   23
   [:> , px2, 1 + q + q  + q ]
   Type: Void
(4) -> f1()$BAR(FRAC INT)
   23
   [:> , px1, 1 + q + q  + q ]
   Type: Void
(5) ->




On 03.11.2020 23:35, Waldek Hebisch wrote:
> On Tue, Nov 03, 2020 at 11:07:14PM +0100, Ralf Hemmecke wrote:
>> Hi Kurt, hi Waldek,
>>
>> I really cannot make sense out of the error in the attached program.
>> Why would it in some cases work fine and in others not? That is quite
>> frustrating. Anyone spots an error in my code? Or is it another compiler
>> bug?
> 
> First guess is that this is due to different handling of constants
> in types in various part of FriCAS (this is known bug).
> Try consitently keeping parameters as variables and pass actual
> values from interpeter only at one place.
> 

-- 
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/b4683e68-a31d-5b56-124a-3b6c7d8e712b%40gmail.com.

Re: [fricas-devel] compiler bug (?)

[Kurt Pagani]

QETARKA -->
   Warnings:
  [1] findRelation: not known that (UnivariateLaurentSeriesCategory C) is of
mode (CATEGORY domain (SIGNATURE coerce ($ (Variable (QUOTE q (SIGNATURE
differentiate ($ $ (Variable (QUOTE q (IF (has CX (Algebra (Fraction
(Integer (SIGNATURE integrate ($ $ (Variable (QUOTE q noBranch))

Looks like a CAT error, or Join(Algebra Q, EuclideanDomain) is simply not 
enough?


On 01.11.2020 22:30, Ralf Hemmecke wrote:
> findIdentity()$QEtaRamanujanKolberg(Fraction Integer)

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

Re: [fricas-devel] FriCAS and TeXmacs update

[Kurt Pagani]

On 29.10.2020 18:30, Bill Page wrote:

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

Not really. In jfricas there are some fake system commands, ")python" for
instance, which are captured and handled by the ipython interpreter. One such
command was (deactivated at the moment) ")gnuplot", that allowed to write
arbitrary GnuPlot commands into the NB cell, wherbey data comes from Fricas via
the PLOT and PLOT3D domains.

> 
> 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?

You hit the nail. The gle.spad that I mentioned in a former mail is quite old,
and I have a newer one (must have forgotten, although it is dated August 2020) 
here:

https://github.com/nilqed/spadlib/blob/master/gle/src/gle.spad

It requires (on debian):  apt install gle-graphics.

GLE is similar to Asymptote, https://asymptote.sourceforge.io/ , but has IMO
some advanatges.

As you indicated, data is generated by another package: PLTSPT ==> PlotSupport
is required.

https://github.com/nilqed/spadlib/blob/master/pltspt/src/pltspt.spad

I suppose this could be a path, but I have to refresh mind and do some
documentation first.

Best wishes
Kurt
> 
> 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/8b4d0a90-6f83-4114-7ec0-b123ce51e360%40gmail.com.

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

[Kurt Pagani]

We seemingly have to blame SBCL. The changelog reveals a change in 2.0.3 related
to UTF, so it might be the case that < 2.0.3 will work for you, although I have
no clue why it should - merely based on the description below.

"""
New in version 2.0.3

incompatible change: the external format now defaults to UTF-8 and is not
affected by LANG. SB-EXT:*DEFAULT-EXTERNAL-FORMAT* is now the only way to change
it.
"""

Unfortunately I have no SBCL >= 2.x in use yet. Let us know if you get new
insights.

On 25.10.2020 23:46, Kostas Oikonomou wrote:
> With fricas 1.3.5:
> 
> (1) -> )lisp  (code-char 945)
> Value = #\GREEK_SMALL_LETTER_ALPHA
> (1) -> )lisp  (code-char 177)
> 
> Value = #\PLUS-MINUS_SIGN
> (1) -> )lisp (format t "~a" (code-char 177))
> ±
> Value = NIL
> (1) -> )lisp (format t "~a" (code-char 945))
> α
> Value = NIL
> (1) ->
> 
> With fricas 1.3.6:
> 
> (1) -> )lisp  (code-char 945)
> Value = #\GREEK_SMALL_LETTER_ALPHA
> (1) -> )lisp  (code-char 177)
> 
> Value = #\PLUS-MINUS_SIGN
> (1) -> )lisp (format t "~a" (code-char 177))
> �
> Value = NIL
> (1) -> )lisp (format t "~a" (code-char 945))
> ?
> Value = NIL
> (1) ->
> 
> 
> On 10/24/20 6:59 PM, Kurt Pagani wrote:
>> )lisp (format t "~a" (code-char 945))
> 

-- 
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/420233c7-3d41-cca0-0f33-e55d67c2a09b%40gmail.com.

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

[Kurt Pagani]

Hi Kostas

> I tried your suggestion, no difference.
Well, a pity :(

I guess Waldek is on the right track. Can you confirm the lines below in your
envirnoment?

(3) -> )lisp  (code-char 945)

Value = #\GREEK_SMALL_LETTER_ALPHA
(3) -> )lisp  (code-char 177)

Value = #\PLUS-MINUS_SIGN
(3) -> )lisp

(3) -> )lisp (format t "~a" (code-char 177))
±
Value = NIL
(3) -> )lisp (format t "~a" (code-char 945))
α
Value = NIL
(3) ->




On 25.10.2020 00:40, Kostas Oikonomou wrote:
> Hi Kurt,
> 
> I tried your suggestion, no difference.  My locale is set to "en_US.UTF-8", 
> as I
> posted earlier.
> In any case, FreeBSD is fully "internationalized", has been so for a while. 
> See
> 
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/l10n.html
> 
> I don't know what the issue is, but it seems like a difference between 1.3.5 
> and
> 1.3.6.
> 
>                             Kostas
> 
> 
> On 10/24/20 1:50 PM, Kurt Pagani wrote:
>> FreeBSD migt be tricky regarding to UTF-8. Apparently "alpha" appears as
>> U+00B1 (PLUS-MINUS SIGN) in FriCAS. There must be some mismatch. Perhaps
>> setting LC_COLLATE=C will help?
>>
>> """
>> FreeBSD, like many UNIX-based operating systems, is unfortunately not 
>> configured
>> to use UTF-8 by default. This sometimes causes confusion about whether 
>> Unicode
>> is supported on FreeBSD. Fortunately, it is easy to enable UTF-8 on FreeBSD.
>> """
>>
>> Consult:
>> https://www.b1c1l1.com/blog/2011/05/09/using-utf-8-unicode-on-freebsd/
>>
>>
>>
>>
>> ---
>>     FriCAS Computer Algebra System
>>  Version: FriCAS 1.3.5
>>  Timestamp: Mi, 17. Apr 2019 03:15:11
>> -
>>     Issue )copyright to view copyright notices.
>>     Issue )summary for a summary of useful system commands.
>>     Issue )quit to leave FriCAS and return to shell.
>> -
>>
>>     Function declaration sixel : TexFormat -> Void has been added to
>>    workspace.
>>     Type: 
>> Void
>>     Function declaration quickLoad : String -> Void has been added to
>>    workspace.
>>     Type: 
>> Void
>>
>>  Type: 
>> Variable(alpha)
>> (1) -> α
>>
>>     (1)  α
>>
>> On 24.10.2020 01:48, Kostas Oikonomou wrote:
>>> Yes, Greek works fine with many other applications, e.g. emacs.  Or shell
>>> windows.  Or LibreOffice, Thunderbird, etc.
>>> I am not running Linux, but FreeBSD (you can see what FriCAS reports when it
>>> starts.)
>>>
>>> On 10/23/20 7:08 PM, Bill Page wrote:
>>>> 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/936b2bb0-4938-32a0-ddce-e842ffb88fe5%40gmail.com.

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

[Kurt Pagani]

FreeBSD migt be tricky regarding to UTF-8. Apparently "alpha" appears as
U+00B1 (PLUS-MINUS SIGN) in FriCAS. There must be some mismatch. Perhaps
setting LC_COLLATE=C will help?

"""
FreeBSD, like many UNIX-based operating systems, is unfortunately not configured
to use UTF-8 by default. This sometimes causes confusion about whether Unicode
is supported on FreeBSD. Fortunately, it is easy to enable UTF-8 on FreeBSD.
"""

Consult:
https://www.b1c1l1.com/blog/2011/05/09/using-utf-8-unicode-on-freebsd/




---
   FriCAS Computer Algebra System
Version: FriCAS 1.3.5
Timestamp: Mi, 17. Apr 2019 03:15:11
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-

   Function declaration sixel : TexFormat -> Void has been added to
  workspace.
   Type: Void
   Function declaration quickLoad : String -> Void has been added to
  workspace.
   Type: Void

Type: Variable(alpha)
(1) -> α

   (1)  α

On 24.10.2020 01:48, Kostas Oikonomou wrote:
> Yes, Greek works fine with many other applications, e.g. emacs.  Or shell
> windows.  Or LibreOffice, Thunderbird, etc.
> I am not running Linux, but FreeBSD (you can see what FriCAS reports when it
> starts.)
> 
> On 10/23/20 7:08 PM, Bill Page wrote:
>> 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/a7b319a3-649b-4cef-2bac-903b72c5fb23%40gmail.com.

Re: [fricas-devel] Units of Measurement

[Kurt Pagani]

Maybe this is what you're looking for?

http://fricas-wiki.math.uni.wroc.pl/SandBoxPQTY?root=SandBox


deprecated, but should work:
https://github.com/nilqed/PhysQty
https://nilqed.github.io/PhysQty/  (doc)

latest:
https://github.com/nilqed/spadlib/tree/master/pqty
https://github.com/nilqed/spadlib/blob/master/pqty/src/pqty.spad

On 02.09.2020 17:03, rus...@gmail.com wrote:
> 
> Hello,
> 
> Does FriCAS support units of measurement?
> 
> I've only found this 15 year old discussion:
> http://fricas-wiki.math.uni.wroc.pl/UnitsAndDimensions
> 
> Was there any progress?
> 
> Best regards,
> 
> 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/54928507-81f5-4ca2-abf5-822286fd626an%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/63ed517b-0927-f196-89f4-c291c68d4300%40gmail.com.

Re: [fricas-devel] Print OutputFrom without end-of-line?

[Kurt Pagani]

Although I'm not a lisp expert nor exactly understand the goal, I suggest
combining "mathprint" with the FORMAT function (~%: newline):

(1) -> print(x) == (mathprint(x)$Lisp; FORMAT('T,"~% ~% ~%")$Lisp)


(2) -> print3(x^n+2::OutputForm)
   Compiling function print3 with type OutputForm -> SExpression
n
   x  + 2




   (2)  ()
Type: SExpression

I recently wrote a cl-format notebook for testing purposes (pdf attached), maybe
you will find a better solution when using FORMAT only (can also write to
strings instead of stdout, so one can process further):

(3) -> FORMAT('NIL,"~a ~%",(z^2)::OutputForm)$Lisp

   (3)  "(^ z 2)
"
Type: SExpression

Best wishes
Kurt


On 10.04.2020 17:30, Prof. Dr. Johannes Grabmeier privat wrote:
> would like to have a print functions with this feature, right now it
> seems that print in OutputForm using print(x  == mathprint(x)$Lisp is
> the only way. Would appreciate if the LISP experts indicate such a
> function, the of course it should be possible to print an end-of-line, 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/73193dcf-6e63-304d-91fa-e936829e2ff2%40gmail.com.


cl-format.pdf
Description: Adobe PDF document

Re: [fricas-devel] )load )lib and XXX.NRLIB/XXX.lsp

[Kurt Pagani]

I had a look into my notes and the case is

)read can read a Lisp file if it ends in *.lisp (*.lsp doesn't work)

This seems to be an undocumented feature? (nothing to do with my hack)


(3) -> )read TMFORM.lisp

; compiling file "C:/git-sdk-64/mingw64/lib/fricas/target/x86_64-w64-mingw32/src
/algebra/TMFORM.NRLIB/TMFORM.lisp" (written 29 MAR 2020 08:50:40 PM):
Heap exhausted during garbage collection: 65536 bytes available, 65552 requested
.
Gen  Boxed Unboxed   LgBox LgUnbox  Pin   Alloc WasteTrig  W
P GCs Mem-age
 03278   0   0   02   107663440 10716356864633034327
8   1  0.
 15093   0   0   03   172419520 16135532810737418509
3   0  0.4429
 26870 237   0   0   26   300132880 165631472 200710
7   0  0.
 3   0   0   0   00   0 0 200
0   0  0.
 4   0   0   0   00   0 0 200
0   0  0.
 5   0   0   0   00   0 0 200
0   0  0.
 6 652 181  45  15056796640   1727008 200 89
3   0  0.
 7   0   0   0   00   0 0 200
0   0  0.
   Total bytes allocated= 637012480
   Dynamic-space-size bytes =1073741824
GC control variables:
   *GC-INHIBIT* = true
   *GC-PENDING* = true
   *STOP-FOR-GC-PENDING* = false
fatal error encountered in SBCL pid 9844(tid 00856940):
Heap exhausted, game over.

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>




On 29.03.2020 20:20, Grégory Vanuxem wrote:
> Kurt,
> 
> TMFORM file is pure Lisp whereas the )read command expects FriCAS interpreter
> language.
> So no success of course ;)
> 
> Greg
> 
> Le dim. 29 mars 2020 à 20:12, Kurt Pagani  <mailto:nil...@gmail.com>> a écrit :
> 
> Usually ")read" can also read a lisp file (provided it ends in *.input):
> 
> $ cp TMFORM.lsp  TMFORM.input
> 
> )read TMFORM
> ...
> 
> No guarantee, though ;)
> 
> 
> On 29.03.2020 20:04, Grégory Vanuxem wrote:
> > Hello here,
> >
> > I'm trying to spot a bug in my MSYS2/MinGW configuration, the build 
> process
> > shocks on TMFORM (texmacs format) if I build FriCAS from scratch i.e. 
> without
> > pre-generated files. With pre-generated files all is right.
> >
> > So :
> > 1) which Lisp compiler compile pre-generated .lsp files? It compiles 
> correctly
> > the files from Waldek but if I remove those files I obtain an exhausted 
> heap
> > with TMFORM. Same thing if I build, install FriCAS, that's shocks
> identically on
> > texmacs.spad.A precision, TMFORM.lsp in the source tarball and 
> generated by my
> > configuration are identical.
> >
> > 2) So I tried to load the TMFORM.lsp file. Here is the session:
> >
> > 
> > (1) -> )help load
> > 
> > A.16.  )load
> > 
> >  
> > User Level Required:  interpreter
> >  
> > Command Description:
> >  
> > This command is obsolete. Use )library instead.
> >  
> > (1) -> )help library
> > 
> > Library examples
> > 
> >  
> > The Library domain provides a simple way to store FriCAS values
> > in a file.  This domain is similar to KeyedAccessFile but fewer
> > declarations are needed and items of different types can be saved
> > together in the same file.
> >
> > To create a library, you supply a file name.
> >
> >   stuff := library "Neat.stuff"
> >
> > [SNIPPED]
> >
> > 1) -> )lib MSET.NRLIB/MSET.lsp
> >    )library cannot find the file MSET.
> > ==
> >
> > As you can see help of the ')lib' system command is apparently not 
> available
> > right now and moreover I am unable to specify a directory that contains 
> a dot.
> > Am I alone with those things?
> >
> > In fact I would like to load the lisp file directly in the FriCAS 
> interpreter.
> > Is it possible without ')fin' and not falling back in pure Lisp?
> >
> > Cheers,
> >
> > Greg
> >
> >
> > --
>   

Re: [fricas-devel] )load )lib and XXX.NRLIB/XXX.lsp

[Kurt Pagani]

You have to ")fin ... (|spad|)" of course (forget to mention).
Is not a good idea anyway, you're right; I have hacked the boot code to read
inline lisp code but that's certainly not to recommend.



On 29.03.2020 20:20, Grégory Vanuxem wrote:
> Kurt,
> 
> TMFORM file is pure Lisp whereas the )read command expects FriCAS interpreter
> language.
> So no success of course ;)
> 
> Greg
> 
> Le dim. 29 mars 2020 à 20:12, Kurt Pagani  <mailto:nil...@gmail.com>> a écrit :
> 
> Usually ")read" can also read a lisp file (provided it ends in *.input):
> 
> $ cp TMFORM.lsp  TMFORM.input
> 
> )read TMFORM
> ...
> 
> No guarantee, though ;)
> 
> 
> On 29.03.2020 20:04, Grégory Vanuxem wrote:
> > Hello here,
> >
> > I'm trying to spot a bug in my MSYS2/MinGW configuration, the build 
> process
> > shocks on TMFORM (texmacs format) if I build FriCAS from scratch i.e. 
> without
> > pre-generated files. With pre-generated files all is right.
> >
> > So :
> > 1) which Lisp compiler compile pre-generated .lsp files? It compiles 
> correctly
> > the files from Waldek but if I remove those files I obtain an exhausted 
> heap
> > with TMFORM. Same thing if I build, install FriCAS, that's shocks
> identically on
> > texmacs.spad.A precision, TMFORM.lsp in the source tarball and 
> generated by my
> > configuration are identical.
> >
> > 2) So I tried to load the TMFORM.lsp file. Here is the session:
> >
> > 
> > (1) -> )help load
> > 
> > A.16.  )load
> > 
> >  
> > User Level Required:  interpreter
> >  
> > Command Description:
> >  
> > This command is obsolete. Use )library instead.
> >  
> > (1) -> )help library
> > 
> > Library examples
> > 
> >  
> > The Library domain provides a simple way to store FriCAS values
> > in a file.  This domain is similar to KeyedAccessFile but fewer
> > declarations are needed and items of different types can be saved
> > together in the same file.
> >
> > To create a library, you supply a file name.
> >
> >   stuff := library "Neat.stuff"
> >
> > [SNIPPED]
> >
> > 1) -> )lib MSET.NRLIB/MSET.lsp
> >    )library cannot find the file MSET.
> > ==
> >
> > As you can see help of the ')lib' system command is apparently not 
> available
> > right now and moreover I am unable to specify a directory that contains 
> a dot.
> > Am I alone with those things?
> >
> > In fact I would like to load the lisp file directly in the FriCAS 
> interpreter.
> > Is it possible without ')fin' and not falling back in pure Lisp?
> >
> > Cheers,
> >
> > Greg
> >
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups
> > "FriCAS - computer algebra system" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an
> email
> > to fricas-devel+unsubscr...@googlegroups.com
> <mailto:fricas-devel%2bunsubscr...@googlegroups.com>
> > <mailto:fricas-devel+unsubscr...@googlegroups.com
> <mailto:fricas-devel%2bunsubscr...@googlegroups.com>>.
> > To view this discussion on the web visit
> >
> 
> https://groups.google.com/d/msgid/fricas-devel/CAHnU2daqFu27MM54fYcQaTYfhwTkaOA4F01Ua-L-ptfk-qK8%2BA%40mail.gmail.com
> >
> 
> <https://groups.google.com/d/msgid/fricas-devel/CAHnU2daqFu27MM54fYcQaTYfhwTkaOA4F01Ua-L-ptfk-qK8%2BA%40mail.gmail.com?utm_medium=email_source=footer>.
> 
> -- 
> 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
> <mailto:fricas-devel%2bunsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/fricas-devel/7ddc70fb-08e7-78e7-84dc-a8fe66095c64%40gmail.com.
> 
> --

Re: [fricas-devel] )load )lib and XXX.NRLIB/XXX.lsp

[Kurt Pagani]

Usually ")read" can also read a lisp file (provided it ends in *.input):

$ cp TMFORM.lsp  TMFORM.input

)read TMFORM
...

No guarantee, though ;)


On 29.03.2020 20:04, Grégory Vanuxem wrote:
> Hello here,
> 
> I'm trying to spot a bug in my MSYS2/MinGW configuration, the build process
> shocks on TMFORM (texmacs format) if I build FriCAS from scratch i.e. without
> pre-generated files. With pre-generated files all is right.
> 
> So :
> 1) which Lisp compiler compile pre-generated .lsp files? It compiles correctly
> the files from Waldek but if I remove those files I obtain an exhausted heap
> with TMFORM. Same thing if I build, install FriCAS, that's shocks identically 
> on
> texmacs.spad.A precision, TMFORM.lsp in the source tarball and generated by my
> configuration are identical.
> 
> 2) So I tried to load the TMFORM.lsp file. Here is the session:
> 
> 
> (1) -> )help load
> 
> A.16.  )load
> 
>  
> User Level Required:  interpreter
>  
> Command Description:
>  
> This command is obsolete. Use )library instead.
>  
> (1) -> )help library
> 
> Library examples
> 
>  
> The Library domain provides a simple way to store FriCAS values
> in a file.  This domain is similar to KeyedAccessFile but fewer
> declarations are needed and items of different types can be saved
> together in the same file.
> 
> To create a library, you supply a file name.
> 
>   stuff := library "Neat.stuff"
> 
> [SNIPPED]
> 
> 1) -> )lib MSET.NRLIB/MSET.lsp
>    )library cannot find the file MSET.
> ==
> 
> As you can see help of the ')lib' system command is apparently not available
> right now and moreover I am unable to specify a directory that contains a dot.
> Am I alone with those things?
> 
> In fact I would like to load the lisp file directly in the FriCAS interpreter.
> Is it possible without ')fin' and not falling back in pure Lisp?
> 
> Cheers,
> 
> Greg
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to fricas-devel+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/CAHnU2daqFu27MM54fYcQaTYfhwTkaOA4F01Ua-L-ptfk-qK8%2BA%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/7ddc70fb-08e7-78e7-84dc-a8fe66095c64%40gmail.com.

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

[Kurt Pagani]

On 13.03.2020 22:47, Neven Sajko wrote:
> On Fri, 13 Mar 2020 at 21:38, Kurt Pagani  wrote:
>>
>> There must be something wrong :( The digits(15000) -> 0.686467020... can't be
>> true. Even with intervals: setting digits gives wrong results. BTW Julia and 
>> CL
>> confirm more or less -0.94..
>>
>> (1) ->  IFL==>Interval(Float)
>> (2) -> interval(1.461920290375737576933544899379e+31)$IFL
>>
>>(2)  [0.1461920290_3757375769 E 32, 0.1461920290_3757375769 E 32]
>> Type: Interval(Float)
>> (3) -> sin(%)
>>
>>(3)  [- 0.9468766486_6677289159, - 0.9468766486_6677289158]
>> Type: Interval(Float)
>>
>>
>>
>> julia> sin(1.461920290375737576933544899379e+31)
>> -0.9468766486679395
>>
>> julia>
>>
>> julia> sin(14619202903757375769335448993790.0::Float64)
>> -0.9468766486679395
>>
>> (4) -> )lisp (sin 14619202903757375769335448993790.0)
>>
>> Value = -0.9468766486679395
>>
>>
>>
>> On 13.03.2020 22:30, Ralf Hemmecke wrote:
>>>> The issue manifests most clearly with huge values, for example: in the
>>>> interpreter, with digits set to 15000 (a lower value should work, too),
>>>> sin(1.461920290375737576933544899379e+31) evaluates
>>>> to 0.68646702078634009753101826, while
>>>> sin(1.461920290375737576933544899379e+31::DoubleFloat::Float) evaluates
>>>> to -0.946876648667939552351769566483, which is obviously a huge
>>>> difference.
>>>
>>> Hey, what do you expect?
>>>
>>>
>>> (7) -> 1.461920290375737576933544899379e+31
>>>
>>>(7)  1461_9202903757_3757693354_48993790.0
>>> Type: Float
>>> (8) -> 1.461920290375737576933544899379e+31::DoubleFloat::Float
>>>
>>>(8)  1461_9202903757_3757693354_48993792.0
>>> Type: Float
>>> (9) -> 1.461920290375737576933544899379e+31::DoubleFloat
>>>
>>>(9)  1.4619202903757376e31
>>>   Type: DoubleFloat
>>>
>>> That this gives different sine values is certainly clear.
>>> Whether this is a problem of the conversion in FriCAS or a problem with
>>> the representation of DoubleFloat in the underlying Lisp, I don't know.
>>>
>>> Maybe someone else with more knowledge about FriCAS' floating point
>>> representation can answer.
>>>
>>> I have no idea about the "disassemble" thing. But if you compile your
>>> code then look into the *.NRLIB directory that is generated by
>>> ")compile". You probably find the respective lisp code.
>>>
>>> Ralf
> 
> Nothing is wrong as far as I know. The difference is because Fricas seems
> to parse its input to Float by default, while with julia one would presumably
> need to do something like:
> 
> julia> sin(parse(BigFloat, "1.461920290375737576933544899379e+31"))

You're right. I forgot that in Julia one has to do this explicitly.
All the better ;)

> 

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

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

[Kurt Pagani]

There must be something wrong :( The digits(15000) -> 0.686467020... can't be
true. Even with intervals: setting digits gives wrong results. BTW Julia and CL
confirm more or less -0.94..

(1) ->  IFL==>Interval(Float)
(2) -> interval(1.461920290375737576933544899379e+31)$IFL

   (2)  [0.1461920290_3757375769 E 32, 0.1461920290_3757375769 E 32]
Type: Interval(Float)
(3) -> sin(%)

   (3)  [- 0.9468766486_6677289159, - 0.9468766486_6677289158]
Type: Interval(Float)



julia> sin(1.461920290375737576933544899379e+31)
-0.9468766486679395

julia>

julia> sin(14619202903757375769335448993790.0::Float64)
-0.9468766486679395

(4) -> )lisp (sin 14619202903757375769335448993790.0)

Value = -0.9468766486679395



On 13.03.2020 22:30, Ralf Hemmecke wrote:
>> The issue manifests most clearly with huge values, for example: in the
>> interpreter, with digits set to 15000 (a lower value should work, too),
>> sin(1.461920290375737576933544899379e+31) evaluates
>> to 0.68646702078634009753101826, while
>> sin(1.461920290375737576933544899379e+31::DoubleFloat::Float) evaluates
>> to -0.946876648667939552351769566483, which is obviously a huge
>> difference.
> 
> Hey, what do you expect?
> 
> 
> (7) -> 1.461920290375737576933544899379e+31
> 
>(7)  1461_9202903757_3757693354_48993790.0
> Type: Float
> (8) -> 1.461920290375737576933544899379e+31::DoubleFloat::Float
> 
>(8)  1461_9202903757_3757693354_48993792.0
> Type: Float
> (9) -> 1.461920290375737576933544899379e+31::DoubleFloat
> 
>(9)  1.4619202903757376e31
>   Type: DoubleFloat
> 
> That this gives different sine values is certainly clear.
> Whether this is a problem of the conversion in FriCAS or a problem with
> the representation of DoubleFloat in the underlying Lisp, I don't know.
> 
> Maybe someone else with more knowledge about FriCAS' floating point
> representation can answer.
> 
> I have no idea about the "disassemble" thing. But if you compile your
> code then look into the *.NRLIB directory that is generated by
> ")compile". You probably find the respective lisp code.
> 
> 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/e95bf9a6-a52c-df69-f720-0302ff88e399%40gmail.com.

Re: [fricas-devel] How to check if GMP is being used at runtime?

[Kurt Pagani]

I heard rumours about problems installing GMP on MacOS, so the question is
whether it's installed on your machine at all? Basically I would expect an error
message when using --enable-gmp if GMP wasn't installed, but who knows?

https://gmplib.org/macos.html
maybe you'll find it with: pkgutil --pkgs



On 07.03.2020 19:28, Pieter van Oostrum wrote:
> Waldek Hebisch  writes:
> 
>> 1) FriCAS uses dynamic linking via dlopen, and should work even
>> if GMP is not prosent.  After succesfuly loading GMP FriCAS
>> sets an internal variable.  Doing:
>>
>> )lisp FRICAS-LISP::*gmp-multiplication-initialized*
>>
>> Value = T
>>
>> prints its value.  T means that GMP is loaded.
> 
> I have fricas 1.3.5 installed on MacOS with --enable-gmp.
> 
> But:
> 
> $ fricas
> Checking for foreign routines
> AXIOM="/opt/local/lib/fricas/target/x86_64-apple-darwin17.7.0"
> spad-lib="/opt/local/lib/fricas/target/x86_64-apple-darwin17.7.0/lib/libspad.so"
> foreign routines found
> openServer result 0
>FriCAS Computer Algebra System 
> Version: FriCAS 1.3.5
>Timestamp: Sat Mar  7 19:17:48 CET 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) -> )lisp FRICAS-LISP::*gmp-multiplication-initialized*
> Value = NIL
> 
> What could be the cause of 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/c2fa399e-7041-0433-e1ea-7b8b6faf64a4%40gmail.com.

Re: [fricas-devel] New release

[Kurt Pagani]

Good :)

BTW I compiled yesterday the current rev (fresh clone). I guess the version
dates (2018) were already wrong in the last release (1.3.5 / 3 February 2019;
according to https://en.wikipedia.org/wiki/FriCAS)? Or asked differently, is
there a special policy?


   FriCAS Computer Algebra System
 Version: FriCAS 2018-03-10
   Timestamp: Thu Mar  5 20:11:13 CET 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) -> )version
Value = "FriCAS 2018-03-10 compiled at Thu Mar  5 20:11:13 CET 2020"
(1) ->



On 06.03.2020 19:25, Waldek Hebisch wrote:
> Trunk is now closed for release.  In next days I will add
> release notes, create release branch and tarballs.
> 

-- 
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/9237e83a-091f-3c6b-34e6-fb3cc611e41f%40gmail.com.

Re: [fricas-devel] New release

[Kurt Pagani]

Thanks for the hint. Actually this was discussed several times in the forum:

https://groups.google.com/forum/#!searchin/fricas-devel/dynamic-space-size%7Csort:date

Nevertheless this might be always an option, as a last resort ;)
If it could be fixed in the code, however, then it should be done.

BTW I wasn't aware of https://aur.archlinux.org/packages/?O=0=fricas
a fricas package. Very interesting!

https://aur.archlinux.org/packages/fricas/

This ought to be mentioned somewhere (@Ralf: maybe http://fricas.github.io/)



On 28.02.2020 22:28, Neven Sajko wrote:
>> The second issue concerns big files (compile or read doesn't matter):
>> ...
>> --SBCL
>> -- >> System error:
>> -- Control stack exhausted (no more space for function call frames).
>> -- This is probably due to heavily nested or infinitely recursive function
>> -- calls, or a tail call that SBCL cannot or has not optimized away.
> 
> SBCL imposes limits on stack and heap size. To configure them (increase
> the limits), run configure before compiling Fricas like this:
> 
> ./configure '--with-lisp=sbcl --control-stack-size 512 --dynamic-space-size 
> 6000'
> 
> This are, in fact, the exact options used in the Archlinux AUR package
> for Fricas.
> 
> Warning: these limits may be too high if Fricas runs on a system with
> limited memory. On the other hand one may want to use even greater
> limits if enough memory is available (e.g., on a server computer).
> 
> I guess similar adjustments may be possible for ECL.
> 
> -- 
> 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/d669ca75-c7c6-46da-a240-15b4f831e24b%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/41898b3c-0dc6-fbdd-925d-9b980e8172c0%40gmail.com.

Re: [fricas-devel] New release

[Kurt Pagani]

On 28.02.2020 17:58, Waldek Hebisch wrote:
> On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:
>>
>> The second issue concerns big files (compile or read doesn't matter):
>>
>>
>> --ECL
>> -- (1) -> )r bigfile
>> --
>> --   >> System error:
>> --   C-STACK overflow at size 1042432. Stack can probably be resized.
>> -- Proceed with caution.
>>
>> --SBCL
>> --  >> System error:
>> --   Control stack exhausted (no more space for function call frames).
>> -- This is probably due to heavily nested or infinitely recursive function
>> -- calls, or a tail call that SBCL cannot or has not optimized away.
>> --
>> -- PROCEED WITH CAUTION.
>>
>> Example:
>> - http://fricas-wiki.math.uni.wroc.pl/AWAIC
> 
> That one looks like sbcl bug: stack overflow is during lisp compilation.

Yes, ECL and ABCL the same/similar.

> 
>> - attached bigfile.input (mostly comments, ~30k lines)
>>
>> I'm wondering why reading a file uses recursion?
>  
> Recursion in general is reasonable.  

Dear me, nothing against recursion. I forgot the 'scanner', probably because one
is used to read the whole file into memory before preocessing nowadays (e.g.
Python).

> Our scanned uses too complicated
> method which usually keeps recursion depth low.  But on long
> streches of comments the method backfires and recursion depth
> is very high.  Adding some actual code (so distnce between executable
> lines is at most 5000) between comment makes problem go away,
> so it there is at least partial workaround.  Anyway, I was
> thinking about simplifyng scanner, but up to now "do not fix
> what is not broken" won.  Now I will have good excuse
> to work on it.  To say the truth I am more worried about
> releated problem: skiping long parts using ')if' and ')endif'
> also leads to crash...
> 

The strange thing is that the (compiled) AWAIC example
(http://fricas-wiki.math.uni.wroc.pl/AWAIC) worked some years ago. Unfortunately
I can't remember which Fricas version. I found one old version only (1.2.7,
2016) and this one is able to read the bigile but cannot compile the AWAIC
either. By the way, I thought it wouldn't matter whether comments or commands
are read, however, this seems not to be case, indeed (the snippet below creates
a file that runs with 100k lines without any problem at all). So mucht the more
I'm wondering why the AWAIC won't compile. It's certainly not a problem of
upmost priority, though.

---
N:=10
f:=open("bigfile2.input"::FileName,"output")$TextFile
writeLine!(f,"X:=[0 for i in 1.." string(N) "]")
for i in 1..N repeat
  writeLine!(f,"X." string(i) ":=random(" string(N) ")")
close!(f)
)q

---



(2) -> )r bigfile
x:=0


   (2)  0
 Type: NonNegativeInteger
(3) -> x

   (3)  0
 Type: NonNegativeInteger
(4) -> )lisp (lisp-implementation-version)

Value = "1.3.0"
(4) -> )lisp (lisp-implementation-type)

Value = "SBCL"

-- 
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/182cb7a7-7dca-d278-4e3d-3a52b70c84e0%40gmail.com.

Re: [fricas-devel] New release

[Kurt Pagani]

> 
> The problem is not the conversion to TeX, but rather a strange way of
> storing that in OutputForm.
> 
> (12) -> (eq1 :: OutputForm) pretend SExpression
> 
>(12)  (= ((PRIME f ",,,") x) (^ x n))
> 

You're right, of course. The root of all evil (not all, though) in TEX is found
in OUTFORM. However, the line

https://github.com/fricas/fricas/blob/master/src/algebra/tex.spad @ line 354
op = 'PRIME =>
formatSpecial('SUPERSUB, [first args, " "::E, second(args)], prec)

makes it even worse. One might change " "::E to hspace(1), but the ugly ",,,"
will remain (I'd prefer ''' ;). In the console it looks ok.

> Wouldn't it make more sense to store it as (PRIME f 3) and let the
> Formatter deal with how it is shown? Here eq1::OutputForm does too much.
> In other words, I would be in favour of moving the code
> 
> add_prime(a : %, s : %) : % == convert [eform 'PRIME, a, s]
> prime(a, nn) == (s := new(nn, char ",");  add_prime(a, sform s))
> 
> away from OutputForm and simply say something like
> 
>prime(a, nn) ==
>   if a is of form (PRIME x n) then
>(PRIME x n+nn)
>   else
>(PRIME a nn)
> 
> Then i-output.boot or the various Formatters would have to deal with
> translating that s-expression into something nice.

Indeed, this would simplify the construction of a reasonable LaTeX string.
Moreover it could provide more flexibility (in TexFormat) for multivariate
functions as well (e.g. f_x, f_y instead of only f_{,1}, f_{,2}).

> 
> 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/1fb132e8-5dad-c1d0-f234-24382c521621%40gmail.com.

Re: [fricas-devel] strange bug

[Kurt Pagani]

After some thinking I don't find it so strange anymore that adding
'finiteAgggregate' is a remedy. The domain FOOX (only one List) works without
this because S=Integer, whereas in FOO we have S=List Integer where some info
may be get lost in the recursion.

ListAggregate(S : Type) : Category == Join(StreamAggregate S,
   FiniteLinearAggregate S, ExtensibleLinearAggregate S) with
FiniteLinearAggregate(S : Type) : Category == Join(LinearAggregate S,
 finiteAggregate)

)abbrev domain FOOX Foox
Foox(): Exports == Implementation where
  Exports == with
foox: () -> Boolean
  Implementation == add
foox(): Boolean ==
a: List Integer := empty()
b: List Integer := empty()
a < b




On 21.02.2020 16:41, Waldek Hebisch wrote:
> On Wed, Feb 19, 2020 at 09:10:26PM +0100, Ralf Hemmecke wrote:
>>> This tells you that offending part is
>>>
>>> a < b
>>>
 ** level 3  **
 $x:= (< a b)
 $m:= (Boolean)
 $f:=
 |b| # #) (|a| # #) (|foo| #) (|$DomainsInScope| # # #) ...)))

>> Apparent user error:
not known that (List (List (Integer))) has (AND (has (List (List
 (Integer))) (finiteAggregate)) (has (List (Integer)) (OrderedSet)))
>

-- 
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/fcf3e0db-32f4-2712-8aa7-e772ccea0561%40gmail.com.

Re: [fricas-devel] strange bug

[Kurt Pagani]

When we add Join(finiteAggregate) it works; strange isn't it. Why?

)abbrev domain FOO Foo
Foo(): Exports == Implementation where
  Exports == Join(finiteAggregate) with
foo: () -> Boolean
  Implementation == add
foo(): Boolean ==
a: List List Integer := empty()
b: List List Integer := empty()
a < b

; compilation finished in 0:00:00.008

   Foo is now explicitly exposed in frame initial
   Foo will be automatically loaded when needed from
  /Users/kfp/Desktop/work/spad/FOO.NRLIB/FOO

(2) -> )sh FOO
 Foo is a domain constructor.
 Abbreviation for Foo is FOO
 This constructor is exposed in this frame.
 1 Names for 1 Operations in this Domain.
--- Operations 

 foo : () -> Boolean

(2) -> foo()

   (2)  false
Type: Boolean
(3) ->



On 21.02.2020 16:53, Waldek Hebisch wrote:
> On Wed, Feb 19, 2020 at 10:19:45PM +0100, Ralf Hemmecke wrote:
>> Since we are at interpreter error messages.
>> I get ...
>>
>> (210) -> onetnStep! ycomp
>>
>>>> System error:
>>The function BOOT::|*1;onetnStep!;1;initial| is undefined.
> 
> I consider this as interpreter bug.  Interpreter is producing
> specialized versions of functions on demand, but in some
> cases this machinery fails.
> 
>> It's hard to track this down. Maybe there is a generic solution to it
>> that I don't know of.
> 
> Write simpler code :(  Unfortunatly interpreter is buggy and
> more complicated code is more likely to find bugs.
> 
> I have fixed a bunch of interpreter bugs, but may feeling is that
> to make definite progress we need to rewrite it almost from
> scratch.  The diffeculty of rewrite is mostly that current
> interpreter also have nice features and we would like to
> preserve them.
> 

-- 
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/dfca70c9-3690-9633-b46e-be321711ebee%40gmail.com.

Re: [fricas-devel] Remove VectorSpace?

[Kurt Pagani]

Below are some 'losses' I encounter when compiling (older) code from other 
people:

OrderedFreeMonoid
FreeAbelianMonoidCategory
InnerFreeAbelianMonoid
FreeAbelianMonoid
FreeAbelianGroup
Monad was renamed to Magma
Magma was renamed to FreeMagma
lo => low
hi => high

VectorSpace ;)

Usually, some macros allow compilation without changes in the sources. There are
certainly not so many as I've thought, so it wouldn't justify a special
compatibility package (e.g. like in python2/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/c24d9f7d-bd42-9b2f-b716-8cd26a191ddf%40gmail.com.

Re: [fricas-devel] Remove VectorSpace?

[Kurt Pagani]

On 17.02.2020 16:44, Waldek Hebisch wrote:
> On Sun, Feb 16, 2020 at 09:15:29PM +0100, Ralf Hemmecke wrote:
>> On 2/16/20 4:40 PM, Waldek Hebisch wrote:

> Actually, 'dimension' alone is of limited use.  In finite
> dimensional case one usually wants a basis and we have
> good ways to provide basis (like FramedModule).  

May I ask why you used LeftAlgebra(R) in the implementation? A special reason?
It's natural of course to multiply from the left but it limits the use together
with other constructs (i.e. when providing a basis we somehow should be able to
form the tensor products, IMO):

(1) -> FramedModule Integer has FreeModuleCategory(Integer,Symbol)
   (1)  false

> Actually,
> it would be rather unusual when one can compute dinension
> and get finite value, but one can not easily give a basis.
> So, in this sence current VectorSpace looks like bad
> concept: it requres _one_ extra nontrival operation, but
> omits a lot of other which would be needed in practical
> computations.

Yes, admittedly true. I think FreeModule(R, S) is perfectly sufficient for most
applications (dimension related to #S). I guess nobody will go beyond aleph0.


-- 
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/da8b3139-998f-cd53-1b87-1c234dca60a1%40gmail.com.

Re: [fricas-devel] Remove VectorSpace?

[Kurt Pagani]

On 16.02.2020 16:40, Waldek Hebisch wrote:
...
>   
>   
> So, it seems that we should remove VectorSpace: it adds   
>   
> almost nothing and is essentially unused.  Any comments?

I would agree in principle if Ralf didn't make a point: it's a widely known
concept whereas Module(F) is for the algebraist ;) But you're right, so as it
stands it's quite useless.
More important to me would be a (backward compat.) list keeping records of what
has been removed, so that "old code" can easily be compiled , e.g.


FreeAbelianGroup X ==> FreeModule(Integer,X)
VectorSpace X ==> Module X
...

-- 
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/39a7787f-20c4-7b6e-7cb3-60feb82fc991%40gmail.com.

Re: [fricas-devel] OrderedAbelianMonoid vs OrderedAbelianMonoidSup

[Kurt Pagani]

On 14.02.2020 17:24, Waldek Hebisch wrote:
> On Fri, Feb 14, 2020 at 04:43:12PM +0100, Ralf Hemmecke wrote:

>>
>> Easy patch, but I do not propose it right now, because there is more and
>> I want to hear opinions.
> 
> For different resons I am looking at similar issue.  Namely, there is
> redundancy between free monoid and polynomials.  I would like to
> make polynomials available for tensor products, but limit profileration
> of spurious signatures.  So I am thinking about introducing some intermediate
> categories.  Clearly, it is worth looking if DirectProductCategory
> deserves some intermediate category.
>  
I'm using FreeMonoid S also with non-ordered S, so I guess there is no
redundancy? Or do I overlook something? Actually there might be some redundancy
with XFreeAlgebra, XDistributedPolynomial and TensorProduct etc., but the latter
are quite useful.
Accidentally, I tested a domain TensorAlgebra a week ago
(http://fricas-wiki.math.uni.wroc.pl/SandBoxTensorAlgebra2?root=SandBox) based
on XDistributedPolynomial (saves a lot of work compared to implementing it by
FreeMonoid+FreeModule).


-- 
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/551a698c-234e-3dec-520a-2f2826dad1fa%40gmail.com.

Re: [fricas-devel] undo macro

[Kurt Pagani]

)clear prop Q

should do !?


On 12.02.2020 16:56, Ralf Hemmecke wrote:
> Q ==> Fraction Integer

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

Re: [fricas-devel] Generating random expressions

[Kurt Pagani]

>> (1) -> add
>>   Line   1: add
>>A
>>   Error  A: syntax error at top level
>>   Error  A: Improper syntax.
>>2 error(s) parsing
> 
> 'add' is a keyword, no wonder that parser complains. Use '_add'
> if you need to disable its syntactic significance.

Yes, how stupid of me :(
I must have mixed up 'add and '+ somehow ...
Undersocres actually work in all cases so far.
Thanks!
> 
>> (2) -> pp:INFORM:='+::INFORM
>>   Line   1: pp:INFORM:='+::INFORM
>>.A
>>   Error  A: Improper syntax.
>>1 error(s) parsing
> 
> addition is also special.
> 

-- 
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/ae2c536a-d3b2-b896-f4ae-60d64edefee6%40gmail.com.

Re: [fricas-devel] Why is there no ubuntu package for Fricas?

[Kurt Pagani]

I'm not aware of such plans. Building the package is easy, though, but to get it
through the Debian mill is time-consuming and tedious, not to speak of
maintaining it (updates etc.).

If you are interested, I've created deb/ub packages some time ago:
http://repos.aisys.ch/apt/ubuntu/pool/main/f/fricas/
with the method described in
https://github.com/nilqed/fricas_docker/tree/master/fpm

Eventually it's matter of trust to get packages from non official sources, of
cocurse. On the other hand it's really no big deal to compile fricas from
sources (see the docker file, this could be rewritten to a bash file to fully
automate the whole process.

Greetings
Kurt



On 06.01.2020 00:52, 'Nasser M. Abbasi' via FriCAS - computer algebra system 
wrote:
> ubuntu is the most used Linux distro. But I am not able to find Fricas ubuntu
> package. 
> 
> I could find sagemath and also xcas.
> 
>>apt-cache search giac
> xcas - Computer Algebra System - console and graphical calculator
> 
> 
>>apt-cache search sagemath
> sagemath - Open Source Mathematical Software
> 
> 
>>apt-cache search fricas
>>
> 
> The manual installations instructions
> at http://fricas.sourceforge.net/doc/INSTALL.txt  can be daunting with all
> the Prerequisites needed.
> 
> Are there plans to make Ubuntu package for Fricas?
> 
> Thanks
> --Nasser
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to fricas-devel+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/773dfa38-9936-4fec-9647-acfc6aec7fb3%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/ab4b1775-7e5e-e4e1-20e0-3529c061115b%40gmail.com.

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

[Kurt Pagani]

Hi Ralf, thanks.
Perhaps I should have mentioned the origin: even with quoting and type 
hints it's quite error-prone.
I'm wondering if there is a possibility to limit (time) the process? 
BTW the function name doesn't matter (foo instead of display etc.)

)abbrev domain IDXOBJ IndexedObject
IndexedObject() : Exports == Implementation where

  OF   ==> OutputForm
  LOF  ==> List OF
  INT  ==> Integer
  SYM  ==> Symbol
  CTOF ==> CoercibleTo OutputForm
  CTEX ==> ConvertibleTo TexFormat
  
  Exports == Join(CTOF, CTEX) with
 
construct : List Integer -> %
display : (%, Symbol, List Symbol) -> OutputForm
coerce : List Integer -> %

  Implementation == add
  
-- [n1,n2,...]; nj=+-1 ; +1:upper, -1:lower
Rep := List Integer

construct(x:List Integer):% ==
  empty? x => x
  x1:List Integer:=[abs n for n in x]
  x1 = [1 for m in 1..#x1] => x@%
  error "Expecting [+- 1, +- 1, +- 1, +- 1,...]"  
  
coerce(x:List Integer):% ==
  empty? x => x
  x1:List Integer:=[abs n for n in x]
  --x1 = expand(1..#x1) => x@%
  x1 = [m for m in 1..#x1] => [sign n for n in x]@%
  error "Expecting [+- 1, +- 2, +- 3, +- 4,...]"
  
label(x:%):List Integer == [n*x.n for n in 1..#x] 

display(x:%,b:Symbol,il:List Symbol):OF ==
  #x ~= #il => error "err ..."
  U:(INT,SYM)->OF:= (m,s)+->if m>0 then outputForm(s)$OF else 
hspace(1)$OF
  L:(INT,SYM)->OF:= (m,s)+->if m<0 then outputForm(s)$OF else 
hspace(1)$OF
  UX:OF:=hconcat [U(n,il.(abs n)) for n in label x]
  LX:OF:=hconcat [L(n,il.(abs n)) for n in label x]
  bas:OF:=outputForm(b)$OF
  scripts(bas, [LX,UX])$OF   

coerce(x:%):OF ==
  S:List Symbol:=[string(n)$String::Symbol for n in 1..#x]
  display(x,'X,S)

---
   IndexedObject is now explicitly exposed in frame initial 
   IndexedObject will be automatically loaded when needed from 
  /Users/kfp/Desktop/work/spad/IDXOBJ.NRLIB/IDXOBJ

(2) -> display(J,'Q,['a,'b,'c,'d,'e,'f]) 
   There are 1 exposed and 0 unexposed library operations named display
  having 3 argument(s) but none was determined to be applicable. 
  Use HyperDoc Browse, or issue
 )display op display
  to learn more about the available operations. Perhaps 
  package-calling the operation or using coercions on the arguments
  will allow you to apply the operation.
 
   Cannot find a definition or applicable library operation named 
  display with argument type(s) 
 Variable(J)
 Variable(Q)
  List(OrderedVariableList([a,b,c,d,e,f]))
  
  Perhaps you should use "@" to indicate the required return type, 
  or "$" to specify which version of the function you need.

(2) -> J:=[1,2,-3,4,-5,-6]::IDXOBJ

 12 4
   (2)  X
   3 56
  Type: 
IndexedObject
(3) -> display(J,'Q,['a,'b,'c,'d,'e,'f]) 

 ab d
   (3)  Q
   c ef
 Type: 
OutputForm
(4) -> display(K,Q::Symbol,['a,'b,'c,'d,'e,'f]@List Symbol) 
   There are 1 exposed and 0 unexposed library operations named display
  having 3 argument(s) but none was determined to be applicable. 
  Use HyperDoc Browse, or issue
 )display op display
  to learn more about the available operations. Perhaps 
  package-calling the operation or using coercions on the arguments
  will allow you to apply the operation.
 
   Cannot find a definition or applicable library operation named 
  display with argument type(s) 
 Variable(K)
   Symbol
List(Symbol)
  
  Perhaps you should use "@" to indicate the required return type, 
  or "$" to specify which version of the function you need.

(4) -> -- takes 50s :(




On Monday, 6 January 2020 11:20:48 UTC+1, Ralf Hemmecke wrote:
>
> Indeed it's a problem with conversion. The following returns quickly 
>
> dsp(x, ['a,'b,'c,'d,'5,'5,'t,'s,'r,'s,'s,'s,'s]) 
>
> The problem seems to be that you have the number 5 in your list. 
> If you evaluate [a,b,c,d,5,5,t,s,r,s,s,s,s] in a session, you get 
>
> (18) -> [a,b,c,d,5,5,t,s,r,s,s,s,s] 
>
>(18)  [a, b, c, d, 5, 5, t, s, r, s, s, s, s] 
>  Type: List(Polynomial(Integer)) 
>
> You give FriCAS the task to figure out how to convert from Polynomial 
> Integer to Symbol. 
>
> (19) -> p := (a::Polynomial(Integer)) 
>
>(19)  a 
>Type: Polynomial(Integer) 
> (20) -> p::Symbol 
>
>(20)  a 
>Type: Symbol 
> (21) -> q := (5::Polynomial(Integer)) 
>
>(21)  5 
>Type: Polynomial(Integer) 
> (22) -> 5::Symbol 
>
>Cannot convert the value from type 

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

[Kurt Pagani]

Hi Qian, thank you! I wasn't aware of "bottom on". Now it's evident what's the
crux of the matter. Although I suspected something like this, I wouldn't expect
the interpreter being so persistent.
Quoting (as Ralf already suggested) helps, nevertheless it might be a pitfall.

Greetings
Kurt


On 06.01.2020 03:37, oldk1331 wrote:
> You can see what is happening by
> ")set message bottom on".
> 
> It seems to try various type conversions (involving polynomial types)
> and fail eventually.
> 
> There are other places where a correct program needs long time to type
> check.
> In that case, adding additional explicit type hints/conversion helps.
> 
> - Qian
> 

-- 
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/3853ec63-5bf1-488a-3551-6d46b86e288b%40gmail.com.

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

[Kurt Pagani]

I've been confronted with the following oddness when accidentally a wrong 
entry (i.e. 1 instead of a symbol) is used:

(1) -> foo(L:List Symbol):OutputForm == first [outputForm(s)$OutputForm for 
s in L]

(2) -> foo [a,b,c,1]
   Compiling function foo with type List(Symbol) -> OutputForm
   Conversion failed in the compiled user function foo .

   Cannot convert the value from type List(Polynomial(Integer)) to List
  (Symbol) .

(4) -> foo [a,b,c,d,e,1]
   Conversion failed in the compiled user function foo .

   Cannot convert the value from type List(Polynomial(Integer)) to List
  (Symbol) .

(5) -> foo [a,b,c,d,e,f,1]
   Conversion failed in the compiled user function foo .

   Cannot convert the value from type List(Polynomial(Integer)) to List
  (Symbol) .

time needed grows exponentially with the length of the list !?
 foo [a,b,c,d,e,f,g,1] hangs already ...

This is an isolated example. The same occurs whether compiled or 
interpreted (as below).
What's going on?   

--- same

foo.spad
)abbrev domain FOO foo
foo() : Exports == Implementation where   
  Exports == with
mkfoo : Integer -> %
dsp: (%,List Symbol) -> OutputForm
  Implementation == Integer add 
Rep := Integer  
mkfoo(x:Integer) == x@%  
dsp(x:%,il:List Symbol):OutputForm ==
  l:List OutputForm := [outputForm(s)$OutputForm for s in il]
  first l

Example: dsp(5,[a,b,c,d,s,r]) 

foo.input:
dsp(x:Integer,il:List Symbol):OutputForm ==
  l:List OutputForm := [outputForm(s)$OutputForm for s in il]
  first l

Example: dsp(5,[a,b,c,d,5,5,t,s,r,s,s,s,s]) (killed after 1h)

Thanks
Kurt

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/a9c97164-5fce-499b-a951-8cea68846b6f%40googlegroups.com.

[fricas-devel] Re: Fricas assumes parameters of integrated function to be non-zero, bug?

[Kurt Pagani]

Indefinite integrals make no sense without specifying types. However, you may
take the definite integral.

(1) -> integrate(f,x=u..v)

a u 2   a v 4 a u 4a v 2  a u 2
 (%e   ) (%e   )  + (- (%e   )  - 1)(%e   )  + (%e   )
   (1)  --
 a u 2   a v 2
  8 a (%e   ) (%e   )
  Type: Union(f1: OrderedCompletion(Expression(Integer)),...)
(2) -> limit(%,a=0)

   (11)  0
  Type: Union(OrderedCompletion(Expression(Integer)),...)
(2) ->


Better would be anyway (use functions (==) instead of Expression (:=))

(5) -> h(a,x)== cosh(a * x) * sinh(a * x)
   Type: Void
(6) -> integrate(h(a,x),x)
   Compiling function h with type (Variable(a), Variable(x)) ->
  Expression(Integer)

 22
sinh(a x)  + cosh(a x)
   (6)  ---
  4 a
 Type: Union(Expression(Integer),...)
(7) -> integrate(h(0,x),x)
   Compiling function h with type (NonNegativeInteger, Variable(x)) ->
  Expression(Integer)

   (7)  0
 Type: Union(Expression(Integer),...)


You certainly know from calculus that

(9) -> integral(f,x)

   x
 ++
   (9)   |   cosh(%A a)sinh(%A a)d%A
++
Type: Expression(Integer)

is not necessarily continuous in "a" ;)

-- 
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/5f1194f4-cf6d-4b34-8450-74b624b6e5b4%40googlegroups.com.

Re: [fricas-devel] Re: InputForm bug in formal derivative

[Kurt Pagani]

Hi Martin
Thanks for the explanations. I really don't want to be nit-picking, 
however, you hit the nail:

> Maybe the confusion comes from the difference between D and f_1:
> f_1(a,b) is the *result* of D(f(a,b), a). 
> D is a FriCAS function, whereas f_1(a,b) is an expression.
  

F(x,y)==D(y*sin(x),x)
-> InputForm (* y (cos x))

That is, the information that y*cos(x) comes from a derivative is lost 
(although not really because F(y,y)::INFORM -> (+ (sin y) (* y (cos y))) 
(before your patch). 

So why not expecting F(u,v)==D(f(u,v),u) as f_1(u,v)? Then F(u,u)=f_1(u,u) 
naturally. On the other hand when using macro (==>):

F(x,y) ==> D(y*sin(x),x)

it's clear to me that we have a substitution F(x,x)->D(x*sin(x),x). But you 
are right of course, one may/should see it as you mentioned:

> D is a FriCAS function, whereas f_1(a,b) is an expression.

Again, thanks for the trouble!
Kurt

On Tuesday, 19 February 2019 07:28:07 UTC+1, Martin R wrote:
>
> Dear Kurt!
>
> As far as I can see, eval, D, == and := are behaving exactly as 
> specified.  With
>
> f(x,y) == D(f(x,y),x)
>
> the symbol "f" is a FriCAS function, and NOT a function in the usual 
> mathematical sense!
> In particular, f(a,b) returns the expression (in the pre-calculus sense)
>
> f_1(a,b),
>
> first derivative of with respect to the first argument, evaluated at a and 
> b.
> Note that it is somewhat sloppy to write f_x(a,b) in calculus, because it 
> is
> unclear what x refers to.
>
> Therefore, eval(f(a,b), b=a) must return f_1(a,a).
>
> On the other hand, f(a,a) should return the expression D(f(a,a), a), which
> is the derivative of f(a,a) with respect to a.
>
> Maybe the confusion comes from the difference between D and f_1:
>
> f_1(a,b) is the *result* of D(f(a,b), a). 
>
> D is a FriCAS function, whereas f_1(a,b) is an expression.
>
> 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 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/03c24daf-bf28-449e-abf4-68ae249d8b1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Re: InputForm bug in formal derivative

[Kurt Pagani]

It's certainly better than before. Nevertheless, IMO there is still a mess 
concerning the usage of "eval". In LISP eval/apply macro/function are 
properly defined, but it seems to me that "eval" here is used more like 
"subst" and moreover, "=="  behaves like "==>" reagrding "D". I have a 
conceptional problem in accepting the possibility g(x,x) <> eval(g(x,y), 
y=x), when g is a function (else if g was defined as a macro). Am I barking 
up the wrong tree?


Before
==
g(x,y) == D(f(x,y),x)

 interpret(g(x,x)::INFORM)

   (1)  2 f  (x,x) + 2 f  (x,x)
,2   ,1
Type: 
Expression(Integer)

g(x,x)::INFORM

   (2)  (+ (D (f x x) (:: x Symbol)) (D (f x x) (:: x Symbol)))
  Type: 
InputForm

but

(3) -> g(x,x)

   (3)  f  (x,x) + f  (x,x)
  ,2 ,1
Type: 
Expression(Integer)

After patch

(1) -> interpret(g(x,x)::INFORM)

   (1)  f  (x,x) + f  (x,x)
 ,2 ,1
Type: 
Expression(Integer)


$ patch fspace.spad  fspace.diff

; compiling file "C:/msys64/home/kfp/patches/FS2.NRLIB/FS2.lsp" (written 18 
FEB 2019 10:26:58 PM):

; wrote C:/msys64/home/kfp/patches/FS2.NRLIB/FS2.fasl
; compilation finished in 0:00:00.018

   FunctionSpaceFunctions2 is now explicitly exposed in frame initial
   FunctionSpaceFunctions2 will be automatically loaded when needed
  from /msys64/home/kfp/patches/FS2.NRLIB/FS2

(1) ->  f:=operator 'f

   (1)  f
  Type: 
BasicOperator
(2) -> g(x,y) == D(f(x,y),x)
   Type: 
Void
(3) -> g(x,y)
   Compiling function g with type (Variable(x), Variable(y)) ->
  Expression(Integer)

   (3)  f  (x,y)
 ,1
Type: 
Expression(Integer)
(4) -> g(x,x)
   Compiling function g with type (Variable(x), Variable(x)) ->
  Expression(Integer)

   (4)  f  (x,x) + f  (x,x)
 ,2 ,1
Type: 
Expression(Integer)
(5) -> g(x,x)::INFORM

   (5)  (+ (eval (D (f x %C) %C) %C x) (eval (D (f %B x) %B) %B x))
  Type: 
InputForm
(6) -> eval(g(x,y),x=y)

   (6)  f  (y,y)
 ,1
Type: 
Expression(Integer)
(8) -> h(x,y) == x^2*sin(y)
   Type: 
Void
(9) -> h1(x,y) == D(h(x,y),x)
   Type: 
Void
(10) -> h1(x,y)
   Compiling function h with type (Variable(x), Variable(y)) ->
  Expression(Integer)
   Compiling function h1 with type (Variable(x), Variable(y)) ->
  Expression(Integer)

   (10)  2 x sin(y)
Type: 
Expression(Integer)
(11) -> h1(x,x)
   Compiling function h with type (Variable(x), Variable(x)) ->
  Expression(Integer)
   Compiling function h1 with type (Variable(x), Variable(x)) ->
  Expression(Integer)

   2
   (11)  2 x sin(x) + x cos(x)
Type: 
Expression(Integer)
(12) -> eval(h1(x,y),x=y)

   (12)  2 y sin(y)
Type: 
Expression(Integer)
(13) -> eval(h1(x,y),y=x)

   (13)  2 x sin(x)
Type: 
Expression(Integer)
(14) -> h1(s,s)
   Compiling function h with type (Variable(s), Variable(s)) ->
  Expression(Integer)
   Compiling function h1 with type (Variable(s), Variable(s)) ->
  Expression(Integer)

   2
   (14)  2 s sin(s) + s cos(s)
Type: 
Expression(Integer)
(15) -> h1(s,t)
   Compiling function h with type (Variable(s), Variable(t)) ->
  Expression(Integer)
   Compiling function h1 with type (Variable(s), Variable(t)) ->
  Expression(Integer)

   (15)  2 s sin(t)
Type: 
Expression(Integer)




On Monday, 18 February 2019 18:03:58 UTC+1, Waldek Hebisch wrote:
>
> Martin R wrote: 
>
> > Here is a proposed fix: 
>
> Could you say more how it is supposed to work?   AFAICS 
> obiously correct method would introduce new symbols and 
> use eval.  Other cases are optimizations to get simpler/ 
> nicer output.  You change several things, most seem 
> to be irrelevant, but curcialy I do not see creation 
> of new symbols. 
>
> -- 
>   Waldek Hebisch 
>

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this 

Re: [fricas-devel] FriCAS on windows

[Kurt Pagani]

On 18.02.2019 05:55, oldk1331 wrote:
> 
> 
> On 2/17/19 12:29 AM, Waldek Hebisch wrote:
>> Thanks for info.  I have put preliminary version
>> of this at:
>>
>> http://www.math.uni.wroc.pl/~hebisch/fricas/windows.txt
>>
>> If you think that this is reasonably accurate and useful
>> I will add this to documentation pages at Sourceforge.
>>
> 
> Hi Kurt, is this line correct:
> 
> $ ./configure --with-lisp="sbcl --dynamic-space-size 1048"
> 

$ ls -l $(which sbcl)
-rwxr-xr-x 1 kfp None 3163221 29. Nov 10:00 /usr/bin/sbcl

It worked but you're right it is not correct, at least not state of the art:

> I think it should be "sbcl.exe" instead of "sbcl". (One has
> to also setup PATH properly.)

I probably copied/renamed sbcl.exe to /usr/bin/sbcl and one should mention to
set up the PATH variable properly, indeed.

> 
> Also, "1048" feels strange -- is it 1024 or 2048?

I recall that I tried 2048 in the first place (what didn't work) so I change the
"2" to "1", therefore 1048. Better is 1024 of course.
> 
> And Waldek, will you add this file to the repo?
> 

Do you agree to this one?
$ ./configure --with-lisp="/pathto/sbcl.exe --dynamic-space-size 1024"

-- 
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/f9054b7d-5937-7513-95fc-a250594f0155%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Re: InputForm bug in formal derivative

[Kurt Pagani]

Oh, just recogniced that I mixed up 'syntactical' & 'semantical' :(
Should read "syntactically g(x,y)=D(f(x,y), x) => g(x,x)=D(f(x,x), x)", of 
course.
So, what shall be the semantics of g(x,y) in fricas? As is or the actually 
a partial function?



-- 
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/e9a92f28-d138-4070-b243-c0c45bdc421e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Re: InputForm bug in formal derivative

[Kurt Pagani]

On Sunday, 17 February 2019 18:46:48 UTC+1, Martin R wrote:
>
> Hi Kurt!
>
> I'm not sure I understand the problem.  With the patch applied, I obtain:
>


You do, your patch is certainly a partial solution (now G and h are 
correct). What I actually wanted to say/ask is that/whether g and G ought 
to be identical.

Semantically g(x,y)=D(f(x,y), x) => g(x,x)=D(f(x,x), x), but is that really 
the answer the user expects? It might be a source of confusion. If you 
hadn't pointed out the issue, I certainly would have made the mistake using 
g instead of G ;)  
 
What is the general opinion? 
BTW thanks for the patch.
Kurt

>
> (1) -> f:=operator 'f
>
>(1)  f
>   Type: 
> BasicOperator
> (2) -> g(x,y) == D(f(x,y), x)
>Type: 
> Void
> (3) -> G(x,y) == eval(D(f(t,s), t),[t=x,s=y])
>Type: 
> Void
> (4) -> expr:=D(f(x,y), x, 1);
>
> Type: 
> Expression(Integer)
> (5) -> function(expr, h, [x,y]);
>
>  Type: 
> Symbol
> (6) -> [G(x,x), g(x,x), h(x,x)]
>
>(6)  [f  (x,x), f  (x,x) + f  (x,x), f  (x,x)]
>   ,1,2 ,1,1
>   Type: 
> List(Expression(Integer))
>
> (7) -> [interpret(G(x,x)::INFORM), interpret(g(x,x)::INFORM), 
> interpret(h(x,x)::INFORM)]
>
>(7)  [f  (x,x), f  (x,x) + f  (x,x), f  (x,x)]
>   ,1,2 ,1,1
>   Type: 
> List(Any)
>
>
> I think that this is OK, let's look at it in detail.
>
> * G(x,y) == eval(D(f(t,s), t),[t=x,s=y])
>
> D(f(t,s), t) means "consider f as a bivariate function and compute the 
> derivative with respect to the first variable"
> G then evaluates this expression at t=x and s=x.
>
> * g(x,y) == D(f(x,y), x)
>
> g(x,x) means "compute D(f(x,x), x)"
>
> * function(expr, h, [x,y])
>
> I admit that I am not completely sure about the semantics of "function", 
> but I think it should be roughly equivalent to G.
>
> Maybe you could say what result you would expect?
>
> Best wishes,
>
> 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 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/c4c0c8d5-97a9-4e5f-a1ba-52d0e4e5a5f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Re: InputForm bug in formal derivative

[Kurt Pagani]

Hi Martin
I suppose this problem is even more involved:

f:=operator 'f
g(x,y) == D(f(x,y), x)
G(x,y) == eval(D(f(t,s), t),[t=x,s=y])

expr:=D(f(x,y), x, 1)
function(expr, h, [x,y])

Then G(q,q) is what I had expected, but neither g nor h may be considered 
as functions. 
The problem seems to be that we here deal with a kind of "macro", i.e. 
G,g,h are not functions as long as 'f' is not concrete.

Even unparse(G(q,q)::INFORM) yields "D(f(q,q),q::Symbol)" :(

I guess this requires some fundamental changes?

Best
Kurt



(8) -> [G(x,x),g(x,x),h(x,x)]
   Compiling function g with type (Variable(x), Variable(x)) -> 
  Expression(Integer) 
   Compiling function h with type (Variable(x), Variable(x)) -> 
  Expression(Integer) 

   (8)  [f  (x,x), f  (x,x) + f  (x,x), f  (x,x) + f  (x,x)]
  ,1,2 ,1,2 ,1
  Type: 
List(Expression(Integer))


On Saturday, 16 February 2019 23:41:35 UTC+1, Martin R wrote:
>
> Hi there!
>
> I'm afraid that there is a slight bug in the InputForm of formal 
> derivatives in 1.3.5.
>
> I guess the problem is that evaluation does not commute with 
> differentiation.
>
> Best wishes,
>
> Martin
>
>
>
>

-- 
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/5ba8c48f-6521-44cd-bcdd-ca2b4af8f841%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] FriCAS on windows

[Kurt Pagani]

On 17.02.2019 00:20, Ralf Hemmecke wrote:
> On 2/16/19 11:40 PM, Kurt Pagani wrote:
>> Hi Ralf
>> I guess "rst" on SF will not diplay properly.
> 
> Huh?
> 
> rst is a text format that is usually nicely readable also as pure text,
> i.e., not translated into HTML by some converter.

I thought you were interested in the HTML rendered form, displayed on SF ... a
misunderstanding.

> 
> Look at
> 
> https://raw.githubusercontent.com/hemmecke/fricas-ws/master/README.rst
> 
> I would still call this properly readable.

Yes, of course.

> 
>> You could make/select a new branch on github/fricas in the settings, then 
>> adding
>> the suffix .rst to the files you mentioned should do (maybe some cosmetics 
>> will
>> be necessary, but seems peanuts to me;)
> 
> Yeah I could do that on my own clone of FriCAS. I intend to keep
> 
> https://github.com/fricas/fricas/
> 
> an exact mirror of the SVN repo.
> 
> I definitely will not invest time in manually updating the respective
> .rst files if the original .txt file changes. 

Understandable ;)

> SVN should go away. I also
> don't think that the sourceforge pages are particularly attractive.

I've been thinking that the problem will sort out itself someday, just because
of the unattractiveness and the tedious advertisments ... being tenacious.

> 
> But it's obviously only me who wants a change. :-(

Not at all. The day will dawn when SF will resign ... principle of least
inherent necessity :)

> 
> 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 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/2abc2b95-3bc0-a5d7-1e17-6f21261293f0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] FriCAS on windows

[Kurt Pagani]

Hi Ralf
I guess "rst" on SF will not diplay properly.
You could make/select a new branch on github/fricas in the settings, then adding
the suffix .rst to the files you mentioned should do (maybe some cosmetics will
be necessary, but seems peanuts to me;)
Kurt



On 16.02.2019 18:45, Ralf Hemmecke wrote:
> Hi Waldek,
> 
> Do you have any opinion on writing such things in restructuredText?
> 
> I've already asked here
> https://www.mail-archive.com/fricas-devel@googlegroups.com/msg12749.html
> and up to now got no reaction.
> 
> Ralf
> 
> On 2/16/19 5:29 PM, Waldek Hebisch wrote:
>> Thanks for info.  I have put preliminary version
>> of this at:
>>
>> http://www.math.uni.wroc.pl/~hebisch/fricas/windows.txt
>>
>> If you think that this is reasonably accurate and useful
>> I will add this to documentation pages at Sourceforge.
>>
> 

-- 
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/7448aeeb-1b8f-575a-c378-e044116aeb2e%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] FriCAS on windows

[Kurt Pagani]

Perfect. I think Win$ows users now have a sufficient number of options.
Thanks a lot!
Kurt

On 16.02.2019 17:29, Waldek Hebisch wrote:
> Thanks for info.  I have put preliminary version
> of this at:
> 
> http://www.math.uni.wroc.pl/~hebisch/fricas/windows.txt
> 
> If you think that this is reasonably accurate and useful
> I will add this to documentation pages at Sourceforge.
> 

-- 
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/df2c351e-f04c-ac48-0dfc-e33e66515014%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] FriCAS on windows

[Kurt Pagani]

Thank you both, it works!

The problem was an outdated version (pacman -Syu solved the problems)

before: MINGW64_NT-6.1 NUC 2.9.0(0.318/5/3) 2017-09-13 23:16 x86_64 Msys
now: MINGW64_NT-6.1 NUC 2.11.2(0.329/5/3) 2018-11-26 09:22 x86_64 Msys

I cant's say which components were responsible for the failure, unfortunately
... but a "pacman -Syu" might be indicated anyway ;)


On 13.02.2019 16:01, Grégory Vanuxem wrote:
> Hello,
> 
> 
> >
> > May I ask how you managed the MingW 64bit build? I can only build the 
> mingw32
> > version.
> >
> 
> On the website of msys2, there is a 64bit version.  Just use that to
> install build dependencies (and 64bit sbcl), then you will have a
> 64bit build of fricas.
> 
> 
> Yes on the https://www.msys2.org/ web site download it and SBCL (x86-64).
> 
> After I would suggest to use the package manager 'pacman' :
> 
> use
> pacman -Syu
> 
> to upgrade your installation and close the terminal window and redo
> the same things several time until your installation is up to date.
> 
> Don't ask why you need to close the terminal window each time I don't know 
> why.
> 
> Afer : 'pacman -S' make and the x86-64 gcc to install them
> 
> If you want to build FriCAS from scratch i.e. without pre-generated files add
> the diffutils package,
> 
> the FriCAS build process use the 'cmp' command somewhere.
> 
> Cheers
> __
> 
> Greg
> 
> 
>  
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to fricas-devel+unsubscr...@googlegroups.com
> .
> To 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/CAHnU2dbpQ0-1wH5Sj_RBHsrkKoi8uSAy%2BgfpovrDOcMaB%2BWCDA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/1c9e9c8c-4406-d731-04dd-e1c3e261426a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] FriCAS on windows

[Kurt Pagani]

> 
> 
> Yes completely faster. As an example :
> 
> WSL on left, MinGW64 on the right (same machine) :
> 
> https://drive.google.com/file/d/16cq6a_d2jDdGTiIFr7S4nu_eJL-gr-5a/view?usp=sharing
> 
> -- 

Indeed, I got similar results. WSL certainly is the method of choice for Windows
10 users, however, there still seems to be numerous working on Windows 7 ;

May I ask how you managed the MingW 64bit build? I can only build the mingw32
version.

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To 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/f04df805-07f5-312e-24ad-156661026aaf%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] FriCAS on windows

[Kurt Pagani]

> IIUC "obey" is not needed for buld from release tarball.  Concerning
> 'texmacs.lsp' I at loss now, from earlier mails by Greg and Kurt
> I thougt that it builds.
>  
> 
It builds fine (32bit), however, one has to increase DSS: 

$ ./configure --with-lisp="sbcl --dynamic-space-size 1048"

kfp@NUC MINGW32 ~/fricas-1.3.5
$ uname -a
MINGW32_NT-6.1 NUC 2.9.0(0.318/5/3) 2017-09-13 23:16 x86_64 Msys



echo "else " >> efricas
echo "  echo You must have installed emacs to run efricas.;" >> efricas
echo "fi" >> efricas
make[1]: Zirkuläre Abhängigkeit gen-cpl.lisp <- gen-cpl.lisp wird nicht 
verwendet.
echo ')read gen-cpl.lisp' | \
AXIOM=C:/msys64/home/kfp/fricas-1.3.5/target/i686-w64-mingw32 
DAASE=C:/msys64/home/kfp/fricas-1.3.5/target/i686-w64-mingw32 \
FRICAS_INITFILE='' 
C:/msys64/home/kfp/fricas-1.3.5/target/i686-w64-mingw32/bin/AXIOMsys
Checking for foreign routines
AXIOM="C:/msys64/home/kfp/fricas-1.3.5/target/i686-w64-mingw32"
spad-lib="C:/msys64/home/kfp/fricas-1.3.5/target/i686-w64-mingw32/lib/libspad.so"
foreign routines found
openServer result -2
   FriCAS Computer Algebra System
Version: FriCAS 1.3.5
Timestamp: Di, 12. Feb 2019 20:56:11
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-

   Using local database 
C:/msys64/home/kfp/fricas-1.3.5/target/i686-w64-mingw32/algebra/compress.daase..
   
Using local database 
C:/msys64/home/kfp/fricas-1.3.5/target/i686-w64-mingw32/algebra/interp.daase..
   Using local database 
C:/msys64/home/kfp/fricas-1.3.5/target/i686-w64-mingw32/algebra/operation.daase..
   Using local database 
C:/msys64/home/kfp/fricas-1.3.5/target/i686-w64-mingw32/algebra/category.daase..
   Using local database 
C:/msys64/home/kfp/fricas-1.3.5/target/i686-w64-mingw32/algebra/browse.daase..
(1) ->
; compiling file 
"C:/msys64/home/kfp/fricas-1.3.5/contrib/emacs/gen-cpl.lisp" (written 03 
FEB 2019 01:36:26 PM):

; wrote C:/msys64/home/kfp/fricas-1.3.5/contrib/emacs/gen-cpl.fasl
; compilation finished in 0:00:00.005
(1) -> cat ./fricas-cpl.hd fricas-cpl.in ./fricas-cpl.tl > fricas-cpl.el
make[1]: Verzeichnis „/home/kfp/fricas-1.3.5/contrib/emacs“ wird verlassen

$ make install

...
make[1]: Verzeichnis „/home/kfp/fricas-1.3.5/contrib/emacs“ wird verlassen
79 FriCAS contrib installation finished.




$ fricas -nosman
Checking for foreign routines
AXIOM="C:/msys64/mingw32/lib/fricas/target/i686-w64-mingw32"
spad-lib="C:/msys64/mingw32/lib/fricas/target/i686-w64-mingw32/lib/libspad.so"
foreign routines found
openServer result -2
   FriCAS Computer Algebra System
Version: FriCAS 1.3.5
Timestamp: Di, 12. Feb 2019 20:56:11
-
   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) -> )lisp  (lisp-implementation-type)

Value = "SBCL"
(1) -> )lisp  (lisp-implementation-version)

Value = "1.4.14"
(1) -> )q

kfp@NUC MINGW32 ~/fricas-1.3.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 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/6575cd84-302b-40c8-af88-33a33ebb32c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Re: FriCAS on windows

[Kurt Pagani]

On 11.02.2019 23:50, 'Martin R' via FriCAS - computer algebra system wrote:
> I am sorry, I think I wrote nonsense.  After 'sage -i fricas' you can use 
> fricas
> from *within* sage, but I guess this doesn't really make sense.

Not at all. If "sage: fricas_console()" will work, then it's virtually the same.
I guess there are some who will use it this way, although not many of them on
Windows (just a bold claim ;)

> 
> Please excuse the noise,
No worries!

> 
> Martin
> 
Greetings
Kurt

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To 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/793fde75-186b-7aff-b75e-323ee288edb4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Re: FriCAS on windows

[Kurt Pagani]

On 11.02.2019 23:27, 'Martin R' via FriCAS - computer algebra system wrote:
> "sage -i fricas" is enough as soon as sage 8.7 is out.

Oh, good to know! I had no idea.

> 
> If you are willing to use the sage develop branch, then fricas 1.3.5 is in 
> fact
> already available.

Well, do you mean
http://doc.sagemath.org/html/en/reference/interfaces/sage/interfaces/fricas.html
 (as a ECL lib?)

or will it be built standalone?

I'm not using the former very often (I admit :(
> 
> Best wishes,
> 
> Martin
> 
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 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/c1334bb8-6263-60b7-7058-d81f1adf028a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Re: FriCAS on windows

[Kurt Pagani]

On Monday, 11 February 2019 19:18:11 UTC+1, Waldek Hebisch wrote:
>
> I thought a little about what can we write to Windows users. 
> IIUC: 
>
> - FriCAS release builds using mingw + sbcl (assuming utilites 
>   from Mysys and ???). 
> - FriCAS builds using cygwin + ecl 
> - There is now Docker image by Kurt Pagani 
> - WSL, do I undertand correctly that FriCAS works (builds ???) 
>   here 
> -- 
>   Waldek Hebisch 
>



Good idea! Would be desirable, indeed. 

Another (IMO good) option for Windows users is abusing the awesome SageMath
Windows installer which provides (besides SageNotebook) a fully configured
Cygwin with ECL already installed. All one has to do then is download/
configure/make fricas-1.3.5-full.tar.bz2 (as reported below). 
As a side effect one may use FriCAS from within SAGE etc. ;)

Get it:
---
https://www.sagemath.org/download-windows.html
ftp://ftp.fu-berlin.de/unix/misc/sage/win/index.html

SageMath-8.6-Installer-v0.4.1.exe1197.17 MB2019-01-24 09:23


Build Fricas:
-
Open/(click) "SageMath 8.6 Shell":

(sage-sh) kfp@NUC:~$ uname -a
CYGWIN_NT-6.1 NUC 2.11.2(0.329/5/3) 2018-11-08 14:34 x86_64 Cygwin

(sage-sh) kfp@NUC:~$ which ecl
/opt/sagemath-8.6/local/bin/ecl

(sage-sh) kfp@NUC:~$ ecl --version
ECL 16.1.2

(sage-sh) kfp@NUC:~$ wget 
https://sourceforge.net/projects/fricas/files/fricas/1.3.5/fricas-1.3.5-full.tar.bz2

(sage-sh) kfp@NUC:~$ tar xvf fricas-1.3.5-full.tar.bz2
(sage-sh) kfp@NUC:~$ cd fricas-1.3.5

(sage-sh) kfp@NUC:fricas-1.3.5$ ./configure --with-lisp=ecl --without-x

config.status: creating contrib/emacs/Makefile
config.status: creating config/fricas_c_macros.h
extracting list of SPAD type definitions
Type 'make' (without quotes) to build FriCAS
(sage-sh) kfp@NUC:fricas-1.3.5$
(sage-sh) kfp@NUC:fricas-1.3.5$ make

... 

   preloading 
/home/sage/fricas-1.3.5/target/x86_64-x-cygwin/algebra/OUTFORM.fas..loaded.

before fricas-restart
openServer result -2
   FriCAS Computer Algebra System
Version: FriCAS 1.3.5
Timestamp: Mo, 11. Feb 2019 22:31:16
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-

   Using local database 
/home/sage/fricas-1.3.5/target/x86_64-x-cygwin/algebra/compress.daase..   
Using local database 
/home/sage/fricas-1.3.5/target/x86_64-x-cygwin/algebra/interp.daase..
   Using local database 
/home/sage/fricas-1.3.5/target/x86_64-x-cygwin/algebra/operation.daase..
   Using local database 
/home/sage/fricas-1.3.5/target/x86_64-x-cygwin/algebra/category.daase..
   Using local database 
/home/sage/fricas-1.3.5/target/x86_64-x-cygwin/algebra/browse.daase..
(1) ->
;;;
;;; Compiling /home/sage/fricas-1.3.5/contrib/emacs/gen-cpl.lisp.
;;; OPTIMIZE levels: Safety=0, Space=0, Speed=3, Debug=0
;;;
;;; End of Pass 1.
;;; Finished compiling /home/sage/fricas-1.3.5/contrib/emacs/gen-cpl.lisp.
;;;
(1) -> cat ./fricas-cpl.hd fricas-cpl.in ./fricas-cpl.tl > fricas-cpl.el
make[1]: Verzeichnis „/home/sage/fricas-1.3.5/contrib/emacs“ wird verlassen
(sage-sh) kfp@NUC:fricas-1.3.5$

(sage-sh) kfp@NUC:fricas-1.3.5$ make install

...
...
/usr/bin/install -c efricas '/usr/local/bin/efricas'
make[1]: Verzeichnis „/home/sage/fricas-1.3.5/contrib/emacs“ wird verlassen
79 FriCAS contrib installation finished.
(sage-sh) kfp@NUC:fricas-1.3.5$


before fricas-restart
openServer result 0
   FriCAS Computer Algebra System
Version: FriCAS 1.3.5
Timestamp: Mo, 11. Feb 2019 22:31:16
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-

   Function declaration sixel : TexFormat -> Void has been added to
  workspace.
   Type: 
Void

(1) -> D(x^n,x,12)

   (1)
12   11 10  9   8
7 6
   n   - 66 n   + 1925 n   - 32670 n  + 357423 n  - 2637558 n  + 
13339535 n
 +
   5  4  3  2
   - 45995730 n  + 105258076 n  - 150917976 n  + 120543840 n  - 
39916800 n
  *
  n - 12
 x
Type: 
Expression(Integer)
(2) -> )version

Value = "FriCAS 1.3.5 compiled at Mo, 11. Feb 2019 22:31:16"
(2) -> )lisp (lisp-implementation-type)

Value = "ECL"
(2) -> )lisp (lisp-implementati

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

[Kurt Pagani]

Great, thank you!

BTW
* Will somebody update the Wikipedia page?

* The docker image just built with ease: https://hub.docker.com/r/nilqed/fricas/


Pull and run


$ docker pull nilqed/fricas
Using default tag: latest
latest: Pulling from nilqed/fricas
38e2e6cd5626: Pull complete
705054bc3f5b: Pull complete
c7051e069564: Pull complete
7308e914506c: Pull complete
7d2d2b74b341: Pull complete
e4fc773ac367: Pull complete
Digest: sha256:00297a8eebe7c422ed4f8ef3f63a472e2f26950541387d6c55b47319f95adef0
Status: Downloaded newer image for nilqed/fricas:latest

$ docker images
REPOSITORY  TAG IMAGE IDCREATED 
SIZE
nilqed/fricas   latest  b5de5b7aae1436 minutes ago
1.22GB


$ docker run -t -i nilqed/fricas fricas -nox
Checking for foreign routines
AXIOM="/usr/local/lib/fricas/target/x86_64-linux-gnu"
spad-lib="/usr/local/lib/fricas/target/x86_64-linux-gnu/lib/libspad.so"
foreign routines found
openServer result 0
   FriCAS Computer Algebra System
Version: FriCAS 1.3.5
   Timestamp: Sun Feb  3 18:21:59 UTC 2019
-
   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) -> )version
Value = "FriCAS 1.3.5 compiled at Sun Feb  3 18:21:59 UTC 2019"
(1) -> )lisp (lisp-implementation-type)

Value = "SBCL"
(1) -> )lisp (lisp-implementation-version)

Value = "1.4.5.debian"
(1) -> )lisp (require :asdf)

Value = ("uiop" "UIOP" "asdf" "ASDF")
(1) -> D(x^n,n,2)

  2 n
   (1)  log(x) x
Type: Expression(Integer)
(2) -> )q






On 03.02.2019 17:09, Waldek Hebisch wrote:
> This is copy of the annoucemnt I posted in newsgroups:
> 
> FriCAS is an advanced computer algebra system. Its capabilities
> range from calculus (integration and differentiation) to abstract
> algebra. It can plot functions and has integrated help system.
> 
> FriCAS 1.3.5 should build on Linux and many Unix like systems (for
> example Mac OSX and Cygwin).  FriCAS is build on top of Common Lisp;
> several Lisps can compile and run FriCAS -- currently supported are
> GCL, SBCL, Clisp, ECL, Closure CL (former OpenMCL).
> 

-- 
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/1d9d4a04-1489-f879-f2ca-8798359540d0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] next release?

[Kurt Pagani]

On 02.01.2019 20:51, Waldek Hebisch wrote:
> oldk1331 wrote:
>>
>> I wish next release can provide Windows and macsOS binary
>> (without X11 dependency).
>>
>> I can do this work as I have relevant environment.
> 
> Hmm, on Windows recent Cygwin clisp on longer supports creation
> of executables, so we need some different way of creating
> executables.  Having X11 parts would be nice, but you decide
> on which parts you want ot spend effort and which to skip.
> 

AFAIK ECL works fine.
Compiled fricas for cygwin64 recently ...
https://github.com/nilqed/fricas_cygwin

-- 
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/a9dbb2b0-a1c9-19ab-3445-2cefc547b6fd%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Using aldor FFI to link mathgl

[Kurt Pagani]

On 02.08.2018 18:42, Riccardo GUIDA wrote:
...
> 
> PS2: could you give a link to the asymptote wrapper?
> 

I've searched a while, unfortunately only parts of it were rediscovered.
The "asy" package works interactively (i.e. you need the 'pipe' package which
requires SBCL exclusively at the moment), however, I couldn't find the Asymptote
package itself (must be on a drive at home, will revert when back). A
non-interactive "asy" (e.g. graph) should work along the lines of gnudraw or
gle.spad (attached). Feel free to provide one ;-)


-- 
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.
)abbrev package GLE GraphicsLayoutEngine
++ Author: 
++ Ideas from GDRAW by Bill Page and David Cyganski
++ Date: November 11, 2014
++ Description:
++ This package provides support for GLE.

EF==> Expression Float
SBF   ==> SegmentBinding Float
DROP  ==> DrawOption
DROP0 ==> DrawOptionFunctions0
STR   ==> String
LDF   ==> List DoubleFloat
GraphicsLayoutEngine(): with

  GLE:(EF, SBF, SBF, STR, List DROP)->Void
  ++ \spad{GLE} provides 3d surface plotting with options
  GLE:(EF, SBF, SBF, STR)->Void
  ++ \spad{GLE} provides 3d surface plotting, default options
  
 == add
 
 -- 3-d plotting
  GLE(f:EF,segbind1:SBF, segbind2:SBF, filename:STR, opts:List DROP):Void ==
import SubSpace, ThreeSpace DoubleFloat, TopLevelDrawFunctions EF
datfile:STR:=concat [filename,".dat"]
glefile:STR:=concat [filename,".gle"]
zfile:STR  :=concat [filename,".z"]
f1:TextFile:=open(datfile::FileName,"output")
-- process optional parameters
---writeLine!(f1,concat(["set title _"",title(opts,"")$DROP0,"_""]))
---writeLine!(f1,"splot '-' title '' with pm3d")
-- extract data as List List Point DoubleFloat
p2:=mesh(subspace(draw(f, segbind1, segbind2)));
for p1 in p2 repeat
  for p in p1 repeat
writeLine!(f1,concat([unparse(convert(p.1)@InputForm)," ",
  unparse(convert(p.2)@InputForm)," ",
  unparse(convert(p.3)@InputForm)]))
  --writeLine!(f1); -- blank line need to mark a "branch"
close! f1
f2:TextFile:=open(glefile::FileName,"output")
writeLine!(f2,"begin fitz")
writeLine!(f2,concat["  data ","_"",datfile,"_""])
writeLine!(f2,"  x from 0 to 1 step 0.03")
writeLine!(f2,"  y from 0 to 1 step 0.03")
writeLine!(f2,"  ncontour 6")
writeLine!(f2,"end fitz")
writeLine!(f2)
writeLine!(f2,"begin surface")
writeLine!(f2,"  size  18 18")
writeLine!(f2,concat["  data ","_"",zfile,"_""])
writeLine!(f2,concat["  points ","_"",datfile,"_""])
writeLine!(f2,"top color orange")
writeLine!(f2,"underneath color blue")
writeLine!(f2,"  harray 5000")
writeLine!(f2,"end surface")
close! f2
-- use )sys gle /preview glefile

  -- default title is ""
  GLE(f:EF,segbind1:SBF, segbind2:SBF, filename:STR):Void ==
GLE(f,segbind1,segbind2,filename,[title("")$DROP])


 
)lisp (defun |spadPipe| (app  args)(let ((proc (sb-ext:run-program app 
args :input :stream :output :stream :wait nil :search t)))(when proc 
(make-two-way-stream (sb-ext:process-output proc) (sb-ext:process-input 
proc)
)lisp (defun |readPipe| (stream)(with-output-to-string (out)(loop for c = 
(read-char-no-hang stream) while c do (write-char c out
--)lisp (load "pipe.lisp")
)abbrev package PIPE SpadPipe 
++ Author: Kurt Pagani 
++ Date Created: Mon Nov 23 13:30:24 CET 2015
++ License: BSD
++ Date Last Updated: 
++ Keywords: 
++ Examples: 
++ References: 
++ Documentation:
++ Description: interfacing interactive programs 
++ Notes: SBCL only at the moment
SpadPipe() : Exports == Implementation where
 
  Exports ==  with


run : (String,List String) -> SExpression
write : (String,SExpression) -> SExpression
writeln : (String,SExpression) -> SExpression
readNoHang : SExpression -> String
readln : SExpression -> String
close : SExpression -> SExpression

  Implementation ==  add 

run(s:String,a:List String):SExpression ==
  stream:=spadPipe(s,a)$Lisp
  
write(s,x) == FORMAT(x,"~a

Re: [fricas-devel] Solving system of PDEs with polynomial power series

[Kurt Pagani]

> 
> If assumptions of Cauchy-Kovalevskaya theorem are not satisfied,
> then it is possible that some transformation will give you
> new system for which Cauchy-Kovalevskaya method works.
> FriCAS Jet bundle package can help here.
> 
> No idea what is this. is there a good link I can read more about it? 

Have a look at

https://groups.google.com/forum/#!searchin/fricas-devel/JET%7Csort:date/fricas-devel/DCwxIiwWRC4/xiKIpC6QAQAJ

especially diss.ps and jet_Axiom.ps.

Solving BVPs numerically is usually not in the scope of a CAS, otherwise there
is hardly more to add to Waldeks statements.

> 
> 
> -- 
>                               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: Fwd: [fricas-devel] Using aldor FFI to link mathgl

[Kurt Pagani]

Dear Riccardo,

a lot of questions ;-) But seriously, see below:

On 02.08.2018 12:30, Riccardo GUIDA wrote:
> Dear Kurt,
> 
> a lot of infos: thanks! BTW A list of all FriCAS non-core packages available 
> on
> internet would be quite helpful to new users, hope Ralf one day will add it to
> the github site
> 

Well, "proof of conecept" is one thing, "production quality" another. That's why
I like the "SandBOX" where users may pick up what they need.

> 
> (Kurt)> May certainly compete with mathgl regarding quality ;)
> 
> I do not want to enter in graphics-lib faith wars :) -- I must say I do not 
> care
> the lib as far as standard features are available and layout is reasonably 
> good.

Neither do I. There are so many good libs that we're spoilt for choice. What
probably counts is a) maintainability and b) ease of implementing/use. IMO
"mathgl" is not so easy to interface like others providing the same
functionality/quality as well.

> 
> As  for mathgl: I spent (and I'm spending) some hours in trying to clarify the
> question of angles (theta,phi) in viewport, and I rapidly realized that the C
> code is -- how to say that politely -- "quite intricate" (tons of global
> variables and includes, verbatim code repetitions, unnecessarily repeated
> computations of geometrical matrices, mysterious changes of signs every here 
> and
> there). For instance, nowadays, each time you plot a single 3D  point in 
> view3D
> you compute two 4x4 matrix products (of which one involving the *identity
> matrix*) to recover the matrices describing the global geometry (which is 
> shared
> among *all* points in a given object). So, to calm my stomach ache, I just
> started to think how I would replace viewmanager and hyperdoc (and maybe 
> socket
> manager) if I was a programmer and to dream of a nice Qt interface (mathgl is
> self contained but Qt friendly).
> 

Only now do I probably understand what you mean. You'd like to replace Fricas'
graphics completely (C-code+viewXY?). It's admittedly true what you've been
criticizing above, however, there is surely one merit: it worked for years
without heavy maintenance. Replacing such long-standing components will (IMO)
require quite a well staffed development team.

> 
> 
> As  for spad_http: I did not follow your spad_http project in the last months
> and now I'm really impressed by the the fact that you managed to have Jupyter
> working for spad and with some graphics support: bravo!
> 
> On the other hand, I must say that there a few things in spad_http that 
> disturb
> me  :(  and (for the moment) prevent me from rush and install it in my
> production system: basically my motivations are due to paranoia and ignorance,
> which may pass with time & study of your code. Let me impudently expose them:
> 

To preclude misunderstandings: it's not intended for production yet (far from
;). That's why I'll condense the answers, but in a nutshell, the whole setup is
just for ease of devlopment at the moment.

> 1)
> I do not like the idea of having a package loader (quicklisp) that installs
> things in my production system (where btw?). IIUC, looking at the *.asd files,
> at each start of the kernel quicklisp is called to load your webSPAD server,
> which depends only on hunchentoot which :depends-on (:chunga, :cl-base64,
> :cl-fad, :cl-ppcre :flexi-streams :md5 :rfc2388 :trivial-backtrace :usocket
> :bordeaux-threads).

The "quicklisp" is just a local version (independent of your systemwide and/or
personal quicklisp). You certainly know that the "local-projects" folder is only
an easy way to load any package having a "asdf" file, i.e. in principle nothing
has to be loaded from the internet.

> 
> In debian I have py2 and py3 packages for all the 3 needed main dependences:
> requests, plotly and Hunchentoot: why should I need quicklisp at all?

Wow, I really didn't know that "Hunchentoot" is available by "apt". Good news,
indeed. Besides this, we don't need "quicklisp" in the end ...

> 
> Would not be better to keep install of dependencies as an optional command, 
> well
> separated from kernel start & run?
> 

Yes, of course. The "start" procedure as it is by now will be changed anyway.
We're used to start the kernel by opening a jupyter notebook and then select the
kernel (so it will be here as well when it's finished). The current method is
convenient for developing in that it re-installs the kernel at every 
"./start.sh".

> 2) (less severe, I guess)
> 
> Why do you hardcode the dependence on python 2 ?
> 

That's just a technical reason -- I used py3 in the first place but encountered
some issues which have to be resolved. Planned is py2/py3-agnostic as you
suggested below.

> On my side I have Jupyter running in python 3 (simpy is stopping support of
> python2 and sagemath working towards supporting py3). I do not know if I can
> safely install debian packages for python2-jupyter and python3-jupyter, so I
> would prefer to patch your code for py3.
> 
> Would not be better 

Fwd: [fricas-devel] Using aldor FFI to link mathgl

[Kurt Pagani]

BTW: I found the GLE prototype again (https://kfp.bitbucket.io/tmp/GLE.html).
May certainly compete with mathgl regarding quality ;)

There's also a patch for view2/3d somewhere.
https://nilqed.github.io/drawfe/


 Forwarded Message 
Subject: Re: [fricas-devel] Using aldor FFI to link mathgl
Date: Wed, 1 Aug 2018 22:03:28 +0200
From: Kurt Pagani 
To: Riccardo GUIDA 

Hi Riccardo

On 01.08.2018 20:40, Riccardo GUIDA wrote:
> Hi
> 
> Quite dreamy, I was thinking at the conceptual possibility of writing a spad
> wrapper for the mathgl graphics library [1].

There are a lot of prototypes around for FFIs and a lot of spad interfaces to
graphics packages like gnuplot,gle,asymptote,paraview,mathmod,plotly ...
Lisp interfaces (e.g. like vgplot) are almost trivial to access from spad,
whereas C might be trickier (see [2]). As a rule of thumb, you can interface
almost any package from SPAD via CFFI (https://common-lisp.net/project/cffi/).



[1] http://goto.glocalnet.net/volkers/vgplot/vgplot.html
[1] https://parasol.tamu.edu/~gdr/OpenAxiom/ffi-draft.pdf


BTW: I'm implementing plotly.js in the new jupyter kernel
(https://github.com/nilqed/spad_http) in a similar way.

http://axiom-wiki.newsynthesis.org/SandBoxPlotly?root=SandBox

Unfortunately, the js script gets blocked, but the produced html snippet works
fine locally.

Best
Kurt

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To 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] interesting error in integration

[Kurt Pagani]

On 25.07.2018 15:30, Waldek Hebisch wrote:
> Ralf Hemmecke wrote:
>>
>>> Thinking loudly.  In order to integrate trigonometric
>>> functions we need imaginary unit. So, if not present we
> 
> Well, ATM I am thinking of doig this, but witout introducing such
> global constructor.  

> But this is just small part of the whole problem.
> 
Indeed! It would be nice to have full conformity with the (group) of roots of
unity (makes sense for any unital ring).

(Un)fortunately - depending on the pint of view - we have with X==>EXPR
INT,XC==>EXPR COMPLEX INT


(1) -> I:=rootsOf(x::X^2+1)

   (1)  [%x0, - %x0]
  Type: List(Expression(Integer))

(2) -> J:=rootsOf(x::XC^2+1)

   (2)  [%x8, - %x8]
 Type: List(Expression(Complex(Integer)))


but neither test(J.?=%i::XC) -> true. It's even unclear to me how one could
"save" XC so that exp(2*%pi*%i/N) is "known" as a principal N-th root of unity?

https://en.wikipedia.org/wiki/Principal_root_of_unity
In an integral domain, every primitive n-th root of unity is also a principal
n-th root of unity. In any ring,...


It works at least in the context of primitive roots, e.g. N=5

(3) -> rootsOf(x::XC^5+1)

   (3)
 2 3   3  2
   [%x0, %x0 %x1, %x0 %x1 , %x0 %x1 , - %x0 %x1  - %x0 %x1  - %x0 %x1 - %x0]
 Type: List(Expression(Complex(Integer)))

but simply adding an "imaginary" might lead to more confusion.


-- 
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: Error detected within library code:, index out

[Kurt Pagani]

On 19.07.2018 11:15, Riccardo GUIDA wrote:
> Hi
> 
>> If using A == Test(SL) with (in package PTEST):
> 
> IIUC Test(SL) is a domain: is it legal in SPAD to use a domain in the LHS of a
> 'with' statement?

No, it's not. This was just to provoke the error message (which has changed over
the versions, apparently). I'm supposing the "index 2 is too large" is somehow
related to the problem, but I couldn't find out yet who did the changes.

 (In Aldor it is not, "the LHS is an optional 'Category'-valued
> expression", see AldorUG sec 7.9)
> 
> ric
> 

-- 
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: Error detected within library code:, index out

[Kurt Pagani]

> Normal way to debug such problems is to use Lisp debugger, see
> doc/debug.txt in the trunk.

This seens different ...

)abbrev domain TEST Test
Test(s:List Symbol):A==B where
  OVL ==> OrderedVariableList s
  A == SetCategory with
gen:()->List %
  B == FreeGroup(OVL) add
Rep:=FreeModule(Integer,OVL)
gen() == [x::% for x in enumerate$OVL]

)abbrev package PTEST Ptest
Ptest:A==B where
  SL ==> ['a,'b,'c]
  A == with --Test(SL) with
foo : Integer -> Test(SL)
  B == add
foo(n) == (gen()$Test(SL)).n


   Ptest is now explicitly exposed in frame frame0
   Ptest will be automatically loaded when needed from
  /cygdrive/c/users/kfp/Desktop/work/spad/PTEST.NRLIB/PTEST

(1) -> T:=Test(['a,'b,'c])

   (1)  Test([a,b,c])
   Type: Type
(2) -> gen()$T

   (2)  [a, b, c]
Type: List(Test([a,b,c]))
(3) -> foo(2)$Ptest

   (3)  b
  Type: Test([a,b,c])
(4) -> )sh Ptest
 Ptest is a package constructor
 Abbreviation for Ptest is PTEST
 This constructor is exposed in this frame.
--- Operations 


   >> Error detected within library code:
   index out of range

(4) ->


If using A == Test(SL) with (in package PTEST):

(1) -> )version

Value = "FriCAS 1.3.3 compiled at Do,  3. Mai 2018 19:01:26"

   Test is already explicitly exposed in frame frame0
   Test will be automatically loaded when needed from
  /cygdrive/c/users/kfp/Desktop/work/spad/TEST.NRLIB/TEST

   PTEST abbreviates package Ptest

   initializing NRLIB PTEST for Ptest
   compiling into NRLIB PTEST
   cannot produce category object:
(|Join| (|Test| (|construct| '|a| '|b| '|c|))
(CATEGORY |package|
 (SIGNATURE |foo| ((|Test| (|construct| '|a| '|b| '|c|)) (|Integer|)

   >> Apparent user error:
   cannot produce category object

same on 1.3.4, while on older versions:

Value = "FriCAS 1.2.7 compiled at Sat Mar 26 17:23:40 GMT 2016"
(2) ->

   Test is now explicitly exposed in frame initial
   Test will be automatically loaded when needed from
  /Users/kfp/Desktop/work/spad/TEST.NRLIB/TEST

   PTEST abbreviates package Ptest

   initializing NRLIB PTEST for Ptest
   compiling into NRLIB PTEST

   >> System error:
   The index 2 is too large.





On 18.07.2018 01:31, Waldek Hebisch wrote:
> Kurt Pagani wrote:
>>
>> Hello Ric
>>
>> Thanks for concerning yourself with this, it might be helpful indeed.
>>
>> When slightly extending it's even worse ... strange ;)
>> I'd expect that u()$SI worked?
>>
>> ---
>>
>> a) PhysicalUnit() : Category == SetCategory  with  -- inherit from SETCAT
>> b) baseUnits() == [x::% for x in enumerate$OrderedVariableList(u)]
>>
>> (2) -> b:=baseUnits()$PUSYS(['a,'b,'c])
>>
>>(2)  [a,b,c]
>>   Type: List(PhysicalUnitSystem([a,b,c]))
>>
>> (3) -> )sh SI
>>  SIunits  is a package constructor
>>  Abbreviation for SIunits is SI
>>  This constructor is exposed in this frame.
>> --- Operations 
>>
>>>> Error detected within library code:
>>Improper script count in symbol
>>
>> (3) -> u()$SI
>>
>>
>>>> Error detected within library code:
>>index out of range
>>
> 
> The error happens during printing of type.  The following works:
> 
> (1) -> u()$SI; 1
> 
>(1)  1
> Type: PositiveInteger
> 
> Normal way to debug such problems is to use Lisp debugger, see
> doc/debug.txt in the trunk.
> 

-- 
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: Error detected within library code:, index out of range

[Kurt Pagani]

Hello Ric

Thanks for concerning yourself with this, it might be helpful indeed.

When slightly extending it's even worse ... strange ;)
I'd expect that u()$SI worked?

---

a) PhysicalUnit() : Category == SetCategory  with  -- inherit from SETCAT
b) baseUnits() == [x::% for x in enumerate$OrderedVariableList(u)]

(2) -> b:=baseUnits()$PUSYS(['a,'b,'c])

   (2)  [a,b,c]
  Type: List(PhysicalUnitSystem([a,b,c]))

(3) -> )sh SI
 SIunits  is a package constructor
 Abbreviation for SIunits is SI
 This constructor is exposed in this frame.
--- Operations 

   >> Error detected within library code:
   Improper script count in symbol

(3) -> u()$SI


   >> Error detected within library code:
   index out of range


On 17.07.2018 16:47, Riccardo GUIDA wrote:
> Hi Kurt
> 
> As FriCAS exercise of the day, I tried to understand the source of your bug 
> but
> the best I can do is a minimal example (vaguely related to the original one) 
> and
> similar errors.
> 
> I do not know what mean "non extending category" and "has no ..." compilation
> messages but there were similar ones in the original version.

I guess this is of no importance w.r.t. to the error (but I may be mistaken)

> 
> Hope not increasing the confusion 

Not at all.
Kurt

> 
> ric
> 

-- 
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] Error detected within library code:, index out of range

[Kurt Pagani]

I'm struggling with an obstinate problem:

)show SI

 SIunits is a package constructor
 Abbreviation for SIunits is SI
 This constructor is exposed in this frame.
--- Operations 

   >> Error detected within library code:
   index out of range


Although the package compiles and works perfectly, the )show command
persistently displays "index out of range". By exclusion I could reduce the
problem to:

)abbrev package SI SIunits
SIunits : Exports == Implementation where

USY ==> ['m,'kg,'s,'A,'K,'mol,'cd]
SIU ==> PhysicalUnitSystem(USY)

Exports == with

  %m   : Integer -> SIU

The "-> SIU" is the source of the evil. When changing SIU to INT for example,
then there is no problem at all. I've been supposing that it might be an issue
in the interpreter code. A 'grep', however, only yields two candidates:


$ grep "index out of range" *.*
br-search.boot:  if startpos < 0 or startpos > n then error "index out of 
range"

match.boot:  if startpos < 0 or startpos > n then error "index out of range"

BTW: the full code is @ 
http://axiom-wiki.newsynthesis.org/SandBoxPhysicalUnitSystem

I've no idea :(
Any hints appreciated.
Kurt


-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To 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

[Kurt Pagani]

> but haven't had a chance yet to
> compare it to the one distributed with FriCAS

Oh dear, you're right, I didn't think of that.

@Slawomir: see the official version
https://github.com/fricas/fricas/tree/master/contrib/texmacs

@Bill
I certainly added some stuff (a lot provided by you, as I remember) but I've no
clear recollection at the moment. I need to compare as well.



On 01.07.2018 23:24, Bill Page wrote:
> 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.

[fricas-devel] Re: TEXmacs as interface

[Kurt Pagani]

Usually this works well. However, you should check the following 
items/prerequisites:

1. Where is the fricas plugin installed? (should be either local or global 
but not both)
  In ~/.TeXmacs/plugins/fricas/progs/ or globally, e.g.
  /usr/local/share/TeXmacs/plugins/ ?

2. Does $ fricas -texmacs work?

kfp@nilqed:~$ fricas -texmacs

   FriCAS Computer Algebra System 
Version: FriCAS 1.3.3
  Timestamp: Don Apr 12 19:26:08 CEST 2018
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave FriCAS and return to shell.
-
Value = #
 prompt#(2) -> )quit

3. In the file init-fricas.scm (folder: TeXmacs/plugins/fricas/progs/)

find the routine

(plugin-configure fricas
(:require #t)
(:launch "fricas -texmacs")
(:session "Fricas")
(:serializer ,fricas-serialize)
(:scripts "Fricas"))

and check the field :launch and :session.
In :launch you may set the full path to fricas, although not necessary.

If all these points are ok, then it should work ...
BTW: your TeXmacs versions is quite old.
I've attached my config in a pdf, maybe it will help you to find the error.



On Sunday, 1 July 2018 16:26:35 UTC+2, Slawomir Kolodynski wrote:
>
> I am trying to use GNU TEXmacs as interface to Fricas. I have installed 
> Fricas 1.3.3 by downloading the tar with binaries and the fricas script is 
> on PATH so I can start fricas from shell by typing "fricas". I also have 
> Texmacs 1.0.7.18 installed from Linux Mint repositories. I assume the 
> Fricas plugin is installed because I can see Fricas as one of the options 
> to select from the Texmacs Insert --> Session menu. However, when I select 
> Fricas there I get "Busy" then "Dead" indication from Texmacs. 
> Does Texmacs 1.0.7.18 work with Fricas 1.3.3? If not, what is a version 
> combination that is known to work? Should I configure Texmacs somehow to 
> point to the location of fricas binaries? How would I do that?
>
> 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.


tmfricas.pdf
Description: Adobe PDF document