On Mon, Jul 2, 2018 at 10:20 PM, Raymond Rogers
wrote:
> Bill, Okay that works.
> Newbie question: why? I thought I was specifying the incoming data type.
You have already specified the incoming (and outgoing) data type by writing:
factor_test : (XDP,LIST(NCP))-> BOOLEAN
Note: BOOLEAN is th
Bill, Okay that works.
Newbie question: why? I thought I was specifying the incoming data type.
Thanks for the more extensive response earlier; although at this stage
"commit" makes me laugh :)
I will try github.
Ray
On 07/02/2018 05:40 PM, Bill Page wrote:
Raymond,
Sorry for the delayed
Raymond,
Sorry for the delayed response. Perhaps you have already discovered
the solution.
The line:
factor_test(x::XDP , y::LIST(NCP)) ==
should actually read:
factor_test(x , y) ==
--
Bill Page.
On Wed, Jun 20, 2018 at 1:35 PM, Raymond Rogers
wrote:
> If anybody is running the ncpo
Riccardo GUIDA wrote:
>
> Thoughts:
>
> * The Aldor compiler is an improved version of the Spad compiler, written by
> one of its authors. So, as a non-expert, I would blindly tend to say that
> Aldor compiler is "better" than Spad compiler. At least it has written
> documentation and, I guess
PS
(6) -> solve(sinh(z)/cosh(z)=0,z) -- ??? AWFUL KO
(6) [z = 0, z = log(- 1)]
Type: List(Equation(Expression(Integer)))
I mean, if log it is defined also on the axis |z| e^{i pi } than z=i pi should
be ok, but what is bad is that one finds 0,1,2 solu
Riccardo GUIDA wrote:
>
> > You seem to use different terminology. Spad is language of .spad files.
> > They are intended for non-interactive use -- basicaly enhancements to
> > FriCAS library. Spad is different than language of .input files.
> > .input files are intended for interactive use. N
Dear Waldek
Could you comment on my (naive) thoughts & questions below?
I use quotes for admittedly-unprecise terms.
I'm pretty sure you've talked about this in the last decade, but the
information is quite spread around in the list.
Thoughts:
* The Aldor compiler is an improved version of th
You seem to use different terminology. Spad is language of .spad files.
They are intended for non-interactive use -- basicaly enhancements to
FriCAS library. Spad is different than language of .input files.
.input files are intended for interactive use. Now, with "interactive
language" there is
>
> Hello,
>
> I'm currently preparing an article that involves GrĂśbner basis
> computation and then finding the representation of some polynomial in
> terms of that GrĂśbner basis. Doing this in FriCAS, is, of course, easy,
> but I was unable to find that such an extended reduction is already
>
Raymond,
I am sorry that it has taken me so long to get back to this project.
My only excuse is that summer is finally here in Canada and there seem
to many other things that occupy my attention. I am of course still
very interested and enthusiastic about this work.
On Sat, Jun 23, 2018 at 2:09 P
Riccardo GUIDA wrote:
>
> @ Waldek
>
> > The command line is not representative of FriCAS language.
>
> OK, crystal clear.
>
> The pedagogical problem is that, maybe not to scare the reader, the FricasUG
> is somehow vague on the differences among interpreter and compiler. For
> instance note
This is an improved revival of a 2007 bug [1] which seems still in good health
(1) -> solve(tan(z)=0,z) -- OK
(1) [z = 0]
Type: List(Equation(Expression(Integer)))
(2) -> solve(sin(z)/cos(z)=0,z) -- OK
(2) [z = 0]
Hi,
I'm now aware of the status of the interpreter in fricas: this is just for the
record (fricas 1.3.4).
fricas 1.3.4: interpreter bug on scopes similar the one reported in
https://www.mail-archive.com/fricas-devel@googlegroups.com/msg12273.html
(1) -> i:=1; for i in 1..3 repeat output(i^2);
13 matches
Mail list logo