CAS command question

[DrD]

(01-10-2017 07:58 AM)parisse Wrote:  Using strings instead of symbolic expressions shoud not be the normal choice because strings have no structure, and calling the parser is inefficient. But I have nothing against improving left and right for strings arguments if DrD really prefers to program with strings.

1. How does the "CAS" interface with the hardware architecture? Before (Parisse), can interact with the hp prime hardware, has the hardware architecture already evaluated the keystrokes, and (Parisse), isn't able to see unevaluated data? This would make the whole discussion a different matter, because this would be a hardware constraint, and nothing to do with CAS firmware. IF that is the case, I totally, understand, and withdraw my complaints. Maybe you just can't implement these features, due to hardware limitations. While Parisse and Han have said that my lack of understanding of how CAS works is the problem, nothing has been said that reveals why CAS can't do this.

2. The INPUT() command can handle various types of objects. It so happens, that TYPE(8), Function Objects, get evaluated before users get a chance to work with them directly. Therefore TYPE(2), String Objects, are the ONLY way to access unevaluated content. It's not that DrD wants to work with strings, per se.

3. I haven't been living in a cave, though. I have computer science coursework, and vocational experience in the design of M6800 processor computer systems, in my early background. Prior to recent retirement, I have been on the diagnostic side, (maintenance and repair) of some pretty sophisticated systems. Most recently, I played a role in the development of a SCADA based telemetry system, using microwave, VHF and UHF data radio, and 2w/4w landline communications, in the natural gas industry. This includes state-of-the-art PLC systems from more than one manufacturer. So if willing and you want to get a little more technical, I'll try to improve my understanding of the CAS inner workings, to better understand why the simplistic idea of left is left, and right is right can't work in this product. If you were to say something like, "It's a hardware issue." or "CAS firmware cannot access unevaluated data." I understand.

4. Another topic altogether:

Quote:I disagree with DrD with the fact that in an educatonial environment, we should make softwares available that exactly support the syntax of textbook problems, students are not robots, we should explain students the logic behind so that they can adapt to any kind of software later. In a professional environment, it's different and being able to copy/paste without user intervention is desirable. The additional work will be done by a programmer that should take the time to understand how the software works

Students exist at every level of the educational process. At higher levels, the prime is very useful to expedite problem solving, to help students learn more about the process than specific results. The student has spent a fortune trying to get the underlying education, and the tool, should not be something requiring much diversion from the fundamental educational goal. Simpler is better. Newer products will most likely be available before the student gets grey hair, so existing tools are transients. Becoming intimately familiar with the tools inner complexities, should not be a bigger problem than the problem the tool is designed to solve. If you disagree, then I do too.

Bringing this back to the topic under discussion, using strings at the user interface, gets us past all of these concerns. String handling in the prime could be improved ...

(If we were to meet and discuss these details, one on one, I bet that we really don't disagree as much as this post seems to indicate. I admit I don't have all the answers, I don't even know how to ask most of the questions!)

-Dale-