CAS command question

[DrD]

Han,

To be clear, I have made only one request, and offered one alternative, not multiple requests. The rest of this thread was trying build support for the idea, by responding to the various 'can't be done' spot issues that have followed.

Lets start with the "Dale doesn't understand how CAS works," and try to find where I fall off the train:

1. It is asserted that the CAS front end starts out by evaluation:

Quote: The issue is not with the commands, but how the parser was designed and implemented. That is, the parser evaluates the arguments and then passes it to the commands. As parisse has already mentioned, by the time the arguments reach the actual code for left() and right(), the expression is already transformed

.

Where does the parser get something to parse? I assert that the first process is an I/O step, and nothing is known about the information, other than it will be passed on to additional processes. This could be an entry point to return "dry" processed commands. Before any further "Wet" processing, which would include any conditioning of the resulting inputs to CAS, or HOME or etc., such as evaluation. DO IT BEFORE EVALUATION. If the parser is hard-coded in ROM, and no way can you intercept the incoming keystrokes, or the keystroke buffers, or the flushed buffer output, then make sure the data is captured as TYPE(2) data.

2. From the very first explanation, where it was explained "Why" and "How" things are done in CAS, I totally got it. "That's the way it's always been done." Okay, change isn't always easy ... just not impossible.

3. This is a bit troubling:

Quote:However, there currently is no mechanism for passing arguments that forever remain "unchanged" except as a string. As far as what is required to make this happens, I do not know.

Strings are a completely viable way to, "make this happen." Everything needed is present in the string. For example, lhs() would see the string object, search for the relational operators, and return everything from the first character to just before the first operator. No, a user should not have to write that routine. Especially if the product is targeted for a specific educational market. That should just be an intrinsic command, like other program statements. No one is asking for the be-all end-all CAS system, but we have referenced several other CAS and Math systems that DO have this feature. Even better, they return the corresponding result, without the reversal of sides being visible on output. This isn't altogether unlike the properly operating LEFT() and RIGHT() commands, in Home, for strings.

3. I have tried to be clear to say what I thought should happen. What I don't want, to be equally clear, is that a user need to be forewarned that the results don't always represent what the command says, or that certain additional characters must be carefully inserted in the string, before it has ANY chance to work, or any other superfluous steps. Here's an example of why: If a student is sent an example to solve, the student should be able to copy/paste the example into a requesting INPUT field, be it the command line, or a program. Likewise for the virtual calculator. Currently, I can copy and paste example problems found on the internet into an optimality program I have created for the purpose. Because a lot of the examples use implicit multiplication, and because of the inequalities in play, I naturally had to include a lot of additional program steps to facilitate other CAS commands. The upshot of that was largely because other needed CAS commands needed the expressions, as opposed to the entire relation. It's not about the extra steps, it's not about the variations of how to do it, it's not about CAS and the underlying limitations of xcas, giac, and consequently the prime. The issue of this topic is that CAS does poorly on the left right implementation.

In summary, I have not been successful in trying to help improve the CAS and the prime, but I have tried. We can let the topic go ... we've about said it all, in a variety of ways, and the take away is that we must live with the status quo, because the vendors are not able to change the behavior. That's ok, at least they aren't silent on the matter. If this were downright important, better suited products, i.e., CAS's exist, so this issue is pretty minor, especially at this stalemate point. I don't want to cause further aggravation, or frustration and I haven't heard anything that makes me want to change my thinking on this issue. It's probably just me, and a few others, so there just isn't anything more I can offer.

I hope you are having good weather, it's cold here, not to suggest we change the subject...