CAS memory corruption (6975)

[Snorre]

Hello,

while playing a bit with the CAS I often end up with a corrupted memory. Finally I've managed to construct a simple case which reproduces this error quite reliable:
       
When evaluating my Z-Transformation ZT(f,z) for the first time (which gives the expected result) the memory corruption occurs. After that, the CAS behaves quite strange: cannot find defined variables, odd-named matrix variables, sometimes two variables with the same name, eventually not even able to do a clean restart (so have to delete CAS-vars manually). The more I proceed to play with the CAS the worse it becomes.

It doesn't seem to be related to using the same variable names in different contexts, since I end with a corrupted memory too if using distinct names in every place, e.g. g(k):=c^k. Furthermore the quirky outcome differs sometimes when repeating these steps.
Maybe there's a bug within the internal clean-up routines when leaving a local scope, but I don't know...

[Snorre]

Addendum.
This problem doesn't occur only in sums but also in integrals:
After running the last command from first screenshot five times I ended with a CAS memory as seen in the second screenshot:
       
I'm quite sure all these examples did work some two or three firmware updates ago.

[parisse]

I will investigate. In the meantime, use ztrans.

[Snorre]

Hello,

(12-31-2014 03:04 PM)parisse Wrote:  I will investigate. [...]

Thank you.
I made some further tests and could create even more simplistic examples that may help to isolate the problem.

Ex. 1 (observation):
r(n):=sum_riemann(1,[k n])
r(numericterm) gives a warning about creation of a substitution variable which should be purged manually.
This warning does not occur when calling r(symbolicterm) despite a substitution variable was created too.

Assumption 1:
If the upper limit of sum is a symbolic term a substitution variable remains in memory.

Ex. 2
s(n):=sum(1,k=1..n)
s(symbolicterm) creates a substitution variable (matrix k=[[DOM_SYMBOLIC]]), whereas s(numericterm) does not.
Ex. 3
s(n):=sum(1/2^k,k=1..n)
s(symbolicterm) and s(numericterm) behave like Ex. 2, but
s(∞) corrupts memory.

Assumption 2:
This subsitution variable does not cause further problems as long as it gets a valid name (e.g. "k").
CAS memory corruption is due to invalid variable names "□", "□(□", "#" as described in the first postings (and by s(∞) in Ex. 3 which created a matrix named "4").

Integration behaviour seems similiar to sum (but with exchanged roles of the argument type):
Ex. 4
f(u):=int(1/2^x,x=0..u)
f(numericterm) and f(∞) create a substitution variable "x" but no further problems,
f(symbolicterm) does not.

Assumption 3:
Since all these substitution variables do only appear/remain if the sum/integral is within a function, there seems to be an issue with internal clean-up routine (as assumed in first posting).

Before doing each example the CAS was cleared by hand (in memory manager) and an additional "restart" was invoked.
The CAS-settings were: "Exact", "Use √", "Principal", "Simplify: None".

It's a pity that I didn't check the memory when doing the examples of first two posting for the first time (it was near dec 2013 with then up-to-date firmware).
But as I don't remember having any problems, I'd think it is related to some recent firmware changes.
I hope you can reproduce that behaviour. I love my Prime and am pretty sure it's a minor bug.
(Sidenote: a CFO-reset didn't help.)

Greetings

P.S. I was sloppy about naming things: numericterm means some term like "1.0", "2", "3/4", "ln(5)", etc.; symbolicterm means some term containing a free variable, infinity, etc.

[parisse]

Sorry, I have resolved the bug a few days ago, but I forgot to post about it. The fix is in giac 1.1.4 source (and will be soon in the unstable version of Xcas).
The problem arises when purge is called on an implicitly created global variable in a local context (you are in a local context each time you call a user function), the implicit global variable was given the value 'symbolic assumed' instead of being removed (like if it was a local variable: if you purge any local variable, it remains with the value 'symbolic assumed', that way you can have a symbolic local variable). At the end, the global variables map was messed up (not alphabetically sorted anymore) because the string name of the global implicit variable had been deleted, but the variable was still in the map (since it was not purged, but had the value 'symbolic assumed').
In other words, you may have this kind of problem if your function calls a CAS function that creates implicit variables like sum and integrate.

[Snorre]

Thanks a lot.
Looking forward to the next firmware update.

[Anders]

parisse,

you mention to use ztrans to calculate the z-transform mapping from the discrete domain to frequency domain. So far this seams to work great for me.
Is there also the inverse z-transform function somewhere to map back to the discrete domain (can't find it in the user manual)? I was guessing it might be undocumented and maybe called "iztrans" but I could not get that to work so maybe it is called something else?

[parisse]

The commandname is invztrans

[Anders]

Thanks!

It must be of the format:
invztrans( expression of z, z,n) to match ztrans( expression of n, n, z).

It would be great of this makes it into the official user guide.

[Terje Vallestad]

(03-23-2015 07:55 PM)Anders Wrote:  It would be great of this makes it into the official user guide.

It is in the on calc help if that helps

Quote:invztrans

Syntax: invztrans(Expr,[Var],[InvZtransVar])

Returns the inverse z transform of a rational fraction.

Example:
invztrans(1/(x^2+1)^2) ➔ (x*exp(x*(-i)*π/2)+x*exp(x*(i)*π/2)+4*Dirac(x)- 2*exp(x*(-i)*π/2)-2*exp(x*(i)*π/2))/4 invztrans(z/(z^4-1),z,n)

Cheers, Terje

[Anders]

Thanks Terje!
yes found it in help.