Re: [fricas-devel] FricasUG metapatch: 7 and )set functions cache all all

2018-07-07 Thread Ralf Hemmecke
> --
> https://github.com/fricas/fricas/blob/master/src/doc/htex/ug06.htex#L894
> REPLACE:
> What is the value for \spad{n = 7}?
> BY:
> What is the value for \spad{n = 3}?
> MOTIVATION:
> The line below contains facto(3)

Thanks. But I rather changed the line with "facto(3)" to "facto(7)".
Just aesthetical reason, since there is a facto(-7) coming just below.

> --
> https://github.com/fricas/fricas/blob/master/src/doc/htex/ug06.htex#L1218
> REPLACE:
> Use no list of names or ``all'' when you want to define the default
> BY:
> Use no list of names when you want to define the default
> MOTIVATION:
> IIUC, the original sentence suggests that the syntax is
> )set functions cache (0||all)  [f...|all]
> while a test shows that the syntax is
> )set functions cache (0||all)  [f...]
> Eg: the trailing ``all`` is interpreted as a function.
> (1) -> )set functions cache 0 all
>     Caching for function all is turned off
> (1) -> )set functions cache 3 all
>     function all will cache the last 3 values.
> (1) -> )set functions cache all all
>     function all will cache all values.
> (1) -> )set functions cache all f
>     function f will cache all values.
> 
> If I'm missing another more meaningful interpretation, I would say
> that the statement should be rewritten to be unambiguous.
> --

OK, it's indeed slightly confusing.

Have you tried to type

  )set function cache

in a session?

==
(1) -> )set function cache
 The cache Option -

 Description: number of function results to cache

 )set functions cache is used to tell FriCAS how many
 values computed by interpreter functions should be saved.  This can save
 quite a bit of time in recursive functions, though one must consider that
 the cached values will take up (perhaps valuable) room in the workspace.

 The value given  after cache must either be the word all or a positive
 integer.  This may be followed by any number of function names whose cache
 sizes you wish to so set.  If no functions are given, the default cache
 size is set.
 Examples:   )set fun cache all )set fun cache 10 f g Legendre

 In general, functions will cache no returned values.
==

It also does not completely rule out the "all" in such a case.

  )set function cache n all

However, clearly "all" in this position can only count as the name of a
fricas function, because there is nothing in FriCAS that forbids a
function to be named "all".

Anyhow. I'll remove the

  or "all"

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


[fricas-devel] FricasUG metapatch: 7 and )set functions cache all all

2018-07-07 Thread Riccardo GUIDA

Mainly for Ralf...

--
https://github.com/fricas/fricas/blob/master/src/doc/htex/ug06.htex#L894
REPLACE:
What is the value for \spad{n = 7}?
BY:
What is the value for \spad{n = 3}?
MOTIVATION:
The line below contains facto(3)

--
https://github.com/fricas/fricas/blob/master/src/doc/htex/ug06.htex#L1218
REPLACE:
Use no list of names or ``all'' when you want to define the default
BY:
Use no list of names when you want to define the default
MOTIVATION:
IIUC, the original sentence suggests that the syntax is
)set functions cache (0||all)  [f...|all]
while a test shows that the syntax is
)set functions cache (0||all)  [f...]
Eg: the trailing ``all`` is interpreted as a function.
(1) -> )set functions cache 0 all
Caching for function all is turned off
(1) -> )set functions cache 3 all
function all will cache the last 3 values.
(1) -> )set functions cache all all
function all will cache all values.
(1) -> )set functions cache all f
function f will cache all values.

If I'm missing another more meaningful interpretation, I would say
that the statement should be rewritten to be unambiguous.
--

--
You received this message because you are subscribed to the Google Groups "FriCAS - 
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [fricas-devel] interoperability with sage again

2018-07-07 Thread 'Martin R' via FriCAS - computer algebra system

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

Help very much appreciated!

In your first message you wrote: 
>
> ... 
>
> > (53) -> f::INFORM 
> > 
> >(53) 
> >(%defprod  (+ (%defsum (/ 1 (+ %LW 2)) %LW (*01000s 10) 0 (+ %LX - 
> 1)) 1) 
> > %LX  (*01000p 11)  0  (+ n - 1)) 
> >   Type: 
> > InputForm 
> > 
> > As you can see, the summation variables have subscripts.  However, 
> > the string representation of the InputForm of scripted symbols does 
> > not allow to reproduce the symbol. 
>
> Although I am very much in favor of improving the coding for 
> InputForm, I note what you wrote above is strictly speaking not true. 
>
> (*01000s 10) and (*01000p 11) 
>
> do contain all the information you need to reconstruct the s_{10} and 
> p_{11} subscripts. Could process *01000s as a function that takes one 
> argument 10 and produces a subscripted symbol s, etc.  In the past I 
> have done this in FriCAS internally when wanting to interpret 
> InputForm expressions. 
>

Oh dear, that's very "clever".  Many thanks.  What information does the 
01000
contain?

In any case, this raises the question:

* does the FriCAS team prefer if I do this mangling on the sage side, or
* does the FriCAS team prefer if I wait for the patch (or something 
similar) above?

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


Re: [fricas-devel] interoperability with sage again

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

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

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

In your first message you wrote:

...

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

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

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [fricas-devel] interoperability with sage again

2018-07-07 Thread 'Martin R' via FriCAS - computer algebra system
Can I do anything to facilitate inclusion in FriCAS?

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

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