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
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
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
Hi Kurt!
I'm not sure I understand the problem. With the patch applied, I obtain:
(1) -> f:=operator 'f
(1) f
Type:
BasicOperator
(2) -> g(x,y) == D(f(x,y), x)
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
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
I'm not sure, but maybe an indication for the wrong DB entry (domain
instead of package) of the following packages might be that all these
packages get their exports from a category.
A comment in ncomp.spad
-- at this stage distinction between domain and package does
-- not
this is stranger than I thought at first:
(1) -> limit(sin(x)+erf(x+sqrt(-1)/2) + erf(x-sqrt(-1)/2), x=0)
(1) 0
Type:
Union(OrderedCompletion(Expression(Integer)),...)
so, apparently, the limit exists unconditionally, but adding the direction
makes FriCAS believe it
Here is a proposed fix:
diff --git a/src/algebra/fspace.spad b/src/algebra/fspace.spad
index 3e6d3dda..29031e32 100644
--- a/src/algebra/fspace.spad
+++ b/src/algebra/fspace.spad
@@ -593,37 +593,26 @@ FunctionSpace(R : Comparable) : Category ==
Definition where
error concat("Unknown
