SpiroH,

thanks for understanding, I was kind of desperate after two days searching for the bug...

I am curious how slightly and why does your solution differ (do we speak of the system solution or the expr(string(...)) outputs? )

Here arises another, for me very important question:

I am now at v3.6.0.550 for a long, long time and I am cautious to upgrade to 3.9, 4.0 or 4.2 before I am assured by some bugfix changelog document from TI or by the community experience known bugs (if any, of course) are resolved. The caution comes from the fact it seems practically impossible to downgrade later in case of possibly problematic upgrades, while waiting for the next version (here we have a saying something like "Better a  you know than an  you don't know" )

So, from your experience and up to your knowledge, speaking of handheld/software math engine and lua scripting only (I do not use ndless), is it safe to jump to v4.2.0.532?

Hello,

I came across the following strange behaviour both at CX CAS handheld and in CAS Teacher Software (v3.6.0.550):

I wrote a function that, based on input data, builds a linear system of equations and gives its solution at its output.

I ran it three times (the input data is the same in all the three runs), each times changing Display Digits in Document Settings only.
The systems to solve and the obtained solutions are visible in the attached figures.

In case of "Float 8" and "Float 4" I get the correct solution (although displayed in different precision), in case of "Float 6" not.

When I say "not" I mean the following:

The source of the problem is a difference in matrix coefficients (7,6) and (6,7): the mathematically correct magnitude of both coefficients should be 2.4E-6 (see P.S.), what I get in case of "Float 4" (2.4E-6) and "Float 8" (0.0000024) runs (therefore the correct solution x(1)=x(4)=1.2)

In "Float 6" case the magnitudes are represented as 0.000002, but the problem is that this value not just the representation of number 0.0000024 in "Float 6" precision, the math engine seems work with exactly 0.000002 instead of 0.0000024 (like it truncated the value) and solves a different system corectly, giving actually the "wrong" solution x(1)=x(4)=1.

Seems very strange to me. Or maybe I misunderstand something regarding math engine precision vs numbers representation?

Regards,
Goran

P.S.

The function can solve the system symbolically, too: when symbolic values are supplied, the corresponding coefficients' value is k*sqrt(L1*L2)*omega*imaginary_unit; substituting the numerical values for the described cases  one gets -0.4*sqrt(1E-6*9E-6)*2*imaginary_unit =
= -2.4E-6*imaginary_unit = (2.4E-6 @< -90 deg) in polar notation, what you get in "Float 4" and "Float 8" cases.

Hello,

in which (.rar?) file can I find the "native" CX CAS skin I saw in this thread: 2kArmTI_v60_TCPCX_v0.skn and kArm_374x823_TP_CX.png files?
(I also tried to follow some links, but due to PHPSESSID problem I could not access them (still confused with the suggested conversion workaround))?

Thanks,
Goran

Hello Adriweb,

I did not mentioned in the post: I learn ETK exactly by looking into FormulaPro code.

Regarding putting move/resize calls to either paint() or postPaint() method:
I concluded as you said: it should be irelevant, as it's called just once, either before or after drawing other widgets (if any).
During experimentation, I tried both possibilities anyway, and in the PC software both options work ok and on the handheld neither of them.

Regarding experiment with a D2Editor outside the ETK widget:
What I tried was I made a copy of FormulaPro and embeded a D2Editor into SubCatSel instance of WScreen (in the same way as shown in my previous post).
Again, the D2Editor with a defined simple text scrolled-in together with other widgets in the software, but not on the handheld:
As I defined it in the middle of the screen, in the software it was drawn as a white rectangle over the regular widgets (partially hiding them) with the defined text.
On the handheld all the widgets were regularly visible, no white rectangle with text was hiding them; I conclude that the editor was either not drawn at all or it's drawn first
(even before paint(), as you said we cannot influence on its rendering?)

Does this experiment answer your questions?

Thanks and regards,
Goran

Hello,

I ran into this error on Nspire CX CAS, but saw already that this error message also exists on other TI calcs like 89, 92 and Voyage200.

I got as a result of my program/function a complex function, let's say z(omega), that was calculated correctly and also was shown correctly in e.g. calc application.

But when I want to play with the function further (e.g. getting it's real or imag part, or even to show in again in calculator by typing z(omega)<ENTER>,
I get "Invalid polar complex" error.

On CX CAS you can reproduce the problem if you define a complex function in polar format as e.g.

   z(omega):=(sqrt(omega) @< 90)

On the other hand, if you define the function as

   z(omega):=(abs(sqrt(omega)) @< 90)

everything works fine.

So I thought (as TI says: complex numbers must be properly defined) the problem is that sqrt() function has two solutions (+/-sqrt(x))
and therefore the magnitude of the function internaly is not a scalar value but a two-items entity (e.g. a list), and therefore the error,

but if you define

   z(omega):=(sqrt(4) @< 90)

it works ok as well (sqrt(4) gives 2, not {-2,2}, so I get confused again)

My goal is to understand the cases/circumstances that produce "invalid polar complex" error, in order to circumvene such
problems, if possible (idea: by decomposing the calculation to steps that can be given constraints in order to
force/help engine to yield intermediate results that will in the end result in a valid polar complex).

Thanks for any help and regards,
Goran

 
   

Hello,

I use math.setEvalSettings({{<key>,<value>}) to  control the appearance of results calculated by the math engine.

It works fine for all keys (e.g. 'Angle Mode', 'Real or Complex Format') except for 'Display Digits':
I always get the full precission, no matter what setting value I set (e.g. 'Fixed5').

In Lua Reference Manual it says:

"Note
All results from the TI-NspireTM math server are returned as full-precision ex-
pressions. If users want to limit the display digits, they must call math.getEvalSettings()
and apply the appropriate precision before displaying the value returned by the
TI-NspireTM math server."

Why they mention math.getEvalSettings()?
Isn't it enough to set the option directly with math.setEvalSettings(<setting>)?
As I said, for all other settings it works fine.

Regards,
Goran

Hello again,

I am still trying a functionality that works in software, to be also working on handheld. I guess the problem is due to
a bias in my thinking/developing in terms of a desktop and "classic" mouseDown/mouseUp events, compared to handheld's additional grabDown/grabUp events.

(I am aware of handling these events in ETK versions incorporated into FormulaPro (mouseUp/mouseDown) and ETK_Demo_New (grabDown added),
but for now I would like first to understand the bare event sequence both in software and on handheld.)

My goal is either to:
a) to select an object, drag it across the screen and release it at some different location, or
b) to select a point of one object, drag a line across the screen and connect it to a point of another object on release.

This is exactly what we do in Graph app when grabbing a function graph, translate/rotate it by dragging, and release it at different position/orientation,
or when using the slider widget in ETK_Demo_New script.

So,

1) in software (where it works as planned):
 
I implemented the corresponding mouseDown() and mouseUp() handlers, what is for software enough: When I press down and hold the left mouse button, mouseDown(x1,y1) is triggered,
then I drag an object or draw a line by keeping left mouse button pressed, and on the release of the left mouse button mouseUp(x2,y2) is triggered. Nice, works, and cannot be simplier.

2) on the handheld (CX CAS with touchpad):

the most similar (and only possible?) operation is to "grab" the first object (by selecting, holding for a while and releasing the central touchpad button), drag it across the screen
(by dragging across the touchpad) and releasing the object (by clicking shortly on the central touchpad button again).

So, in order to work on handheld, I guess I have to implement additional grabDown(/grabUp?) handler(s).

Based on reading Lua Scripting API manual and some experimenting, I came to the following conclusions (which are not necessarily correct):

a) when I press and hold for a while the central touchpad button, grabDown(0,0) event is created, preceeded by mouseDown(x1,y1) event.
b) on the release of the central touchpad button, grabUp(0,0) event is created (by now, the object is selected/grabbed and ready to be moved around)
c) the manual says that both grabDown() and grabUp() events actively suppress creation of mouseUp() event

To summarize, up to here, grabing my object creates:
   mouseDown(x1,y1)
   grabDown(0,0)
   grabUp(0,0)

Then, dragging the object is done by implementing mouseMove() event.

In the end, if I press shortly the central touchpad button again (to release the object), I guess I'll produce another mouseDown() event.
But my experience shows that:
   i) on pressing shortly the central touchpad button, mouseUp(x,y) handler is used
   ii) the x,y coordinates correspond to the "grabbing" point x1,y1, no matter that I clicked the button at "dragged" position x2,y2.

All this is really puzzling me (to be honest: making a mess in my head)?

Can someone please explain me step by step what really goes on at handheld platform during select-drag-release operation
with regard to events?

Thanks in advance,
Goran

Thanks for the link, I will go into it soon.

I use 3.2.3.1233 on the handheld.

Regarding invalidite() calls, I'll check them thoroghfully again when I return home. Nevertheless, good you mentioned them, I've also noticed that in the software (after one operation) the screen is refreshed immediatelly, while on the handheld I have to move the mouse first. Why this difference? Is there a list of differnces that are considered as normal when running an app in software and on the handheld?

Secondly, whenever I want mouse cursor to appear at the handheld, I have to scroll across the touchpad for 1-2 seconds before the cursor appears, what is a bit annoying, especially if you compare it with the prompt response in the software; also in software the cursor is always on, while on handheld it dissapears after several seconds of inactivity; which means that when I operate upon the elements on the screen, I constantly have to scroll around the touchpad to get the cursor first. This is the general behavior, not just within my app. Is there a way to improve here anything?

Thirdly, what is/are keystrokes on the handheld that are equivalent to releasing mouse left button in software?
On my side I will have to check again my code where I was messing around with on.charIn, on.mouseDown, on.mouseUp and on.mouseMove functions.

Regards and thanks,
Goran