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
Two problems: First, unlike the interpreter, SPAD does not have
multiple assignment. The error message about "compColon" is the
compiler's poor way of trying to say that. Secondly, the DirectProduct
domain does not have a direction coercion from (...) tuple, List or
other similar domain. You need
On 30/10/2020 17:29, Ralf Hemmecke wrote:
> In FriCAS they are not (also not in Aldor).
> The reason is that no computation is done at compile time.
> Of course that could be changed if there were a sublanguage that the
> compiler could execute at compile time.
>
> But why would you believe that
That's a nasty error that I cannot resolve without seeing the code.
Usually when I get this, it is an identation problem in the code.
Ralf
On 10/30/20 6:28 PM, Neven Sajko wrote:
> Hmm, I tried to implement lab1method2 with iteration with a for loop
> instead of with recursion, but now Fricas
> a: (VectorFL Double 3)
> b: (VectorFL Double (1 + 2))
...
> a + b should compile because numeric values can be normalised to a
> single number which is equal in this case (in Idris they are
> definitionaly equal).
In FriCAS they are not (also not in Aldor).
The reason is that no computation is
Hmm, I tried to implement lab1method2 with iteration with a for loop
instead of with recursion, but now Fricas tells me this:
Internal Error
Unexpected error in call to system function compColon
The package is again attached.
Thank you,
Neven
--
You received this message because you are
On 10/30/20 4:41 PM, Neven Sajko wrote:
> Thank you very much for your thoughtful responses, Ralf, I understand
> Spad a bit better now thanks to you. However it seems that another
> roadblock has appeared: while your lab1method1 works fine, lab1method2
> does not. At the end of the compilation
On 29/10/2020 21:10, Neven Sajko wrote:
My guess would be that it would be better if Vector's constructor had
a length parameter, because that would enable greater type safety
(i.e. I couldn't pass a Vector of the wrong length to a function).
For me one of the great advantages of static types
Thank you very much for your thoughtful responses, Ralf, I understand
Spad a bit better now thanks to you. However it seems that another
roadblock has appeared: while your lab1method1 works fine, lab1method2
does not. At the end of the compilation there are warnings about the
function
Hi Neven,
thank you. You hit another problem that is not clearly enough described
in the book. When I started with AXIOM, it took some time until I
understood, that not everything that works in the interpreter also works
for the compiler. You have hit such a case here. Another thing that
should
P... tough stuff. And great thanks for sharing your problems with us.
In fact, what you experience is probably for all the biggest frustration
that lets people turn their back to FriCAS.
So let me give a word of clarification. The main difference of FriCAS in
contrast to other CAS(es) is
Hello,
I am getting the following error with the attached Spad code, in the
implementation of lab1method1 while trying to create a matrix of Float
values:
Apparent user error: Cannot coerce i of mode (NonNegativeInteger) to
mode (Fraction (Integer))
I don't know how to proceed. It seems as if
Hello,
I've stumbled on a seeming inconsistency while using Fricas and I'm
writing to the mailing list in hopes of getting more understanding of
the issue, or just reporting a bug if the issue is a bug.
Consider the following Fricas session:
(1) -> x : DirectProduct(2, Float) := (2,3)
(1)
13 matches
Mail list logo
