Threaded Mode | Linear Mode

akmon · 05-21-2015, 08:47 AM

Hello again.

I would like to understand definitly the differences between commands in upper or lowercase.

In this case, I search "solve" in the catalog, I type solve(x^2+x+1) in CAS mode and I get {1/2*(SQR(3)*i-1), 1/2*(-SRQ(3)*i-1)}. If I type solve(X^2+X+1) in HOME I get the same result (X in uppercase).

SOLVE in uppercase does not exist in catalog, but, when I manually type it in HOME mode I don´t get Syntax error. It runs and outputs {Error: Extremum found, -0,4921875}.

Even if I type SOLVE in CAS mode, I get ["Error: Extremum found"].

So resuming all the combinations:

solve is a CAS command that works on CAS or HOME mode, I only have to type variables in upper or lowercase.

SOLVE does not exists in catalog, but the calculator recognizes it and it works, with differents results.

So, how is the way that solve or SOLVE works? I have used SOLVE in a little program (IRR, see thread) and it works flawlessly, but I don´t know when is more suitable using solve or SOLVE.

I suppose this example can be applied to other lowercase commands.

Thank you.

Tim Wessman · 05-21-2015, 03:10 PM

SOLVE is an app function in the solve application (toolbox->app->solve). It is the same thing as FNROOT in home and calls the classic HP numerical solver.

akmon · 05-21-2015, 04:21 PM

Thank you Tim. Understood. I thought app commands were present in catalog, the same as on hp49 when you installed a library.

Tim Wessman · 05-21-2015, 04:41 PM

No, they are not. I'd like to change that in the future though.

Marcio · 05-21-2015, 04:46 PM

Yes, and they behave differently: http://www.hpmuseum.org/forum/thread-3704.html

salvomic · 05-21-2015, 05:01 PM

as you know, Akmon, I'm using these command to calculate IRR, and I get different results with the same data:
Solve.SOLVE() output only one result even if there are more results;
solve() output a list
fsolve() doesn't go in Home
...

Still I'm not decided what to do use, 'cause sometimes I'll would have complete results, sometimes only one...
And this for my program about IRR is a problem: the program should decide which of them use based on ...type of results, not so easy... Smile

Salvo

Marcio · 05-21-2015, 07:32 PM

(05-21-2015 05:01 PM)salvomic Wrote: as you know, Akmon, I'm using these command to calculate IRR, and I get different results with the same data:
Solve.SOLVE() output only one result even if there are more results;
solve() output a list
fsolve() doesn't go in Home
...

Still I'm not decided what to do use, 'cause sometimes I'll would have complete results, sometimes only one...
And this for my program about IRR is a problem: the program should decide which of them use based on ...type of results, not so easy...

Salvo

SOLVE, with capital letters, never failed me.

akmon · 05-21-2015, 08:03 PM

To add more wood to the fire.

Look at this screenshot. If I type SOLVE in the emulator it outputs a syntax error. If I type Solve.SOLVE it works. But in the physical calculator, if I type SOLVE it works well. What the hell is happening?

Tim Wessman · 05-21-2015, 08:13 PM

Which application is running the the calculator? What does it say in the menu bar?

akmon · 05-21-2015, 10:00 PM

Excuse me Tim. I don´t understand exactly what you asked. I have reseted the emulator to factory settings, but the syntax error still appears. It´s strange. It works on the physical calculator, and the firmware is exactly the same. Can you try on yours?

salvomic · 05-21-2015, 10:04 PM

(05-21-2015 07:32 PM)Marcio Wrote: SOLVE, with capital letters, never failed me.

no, dear Marcio, here it doesn't fail, but my particular example, IRR some times gives more results (one of sign's change), and I noted SOLVE gave one (the principal) result, solve() a list with all + one, the first, that in case of many results it erratic or not financially relevant...)

I meant this only.

Salvo

Tim Wessman · (This post was last modified: 05-21-2015 10:28 PM by Tim Wessman.)

(05-21-2015 10:00 PM)akmon Wrote: Excuse me Tim. I don´t understand exactly what you asked. I have reseted the emulator to factory settings, but the syntax error still appears. It´s strange. It works on the physical calculator, and the firmware is exactly the same. Can you try on yours?

SOLVE is an app function in the solve app. If the solve app is not the active app, it will error like you report. So unless you see SOLVE at the top of your screen, you are running another application. If you press APPS-> select solve app, then home and try, does it work?

akmon · (This post was last modified: 05-21-2015 10:55 PM by akmon.)

Bingo! It works in SOLVE app on the emulator. I´ve checked the calculator and it was running Solve app. That´s the reason of being working there, too. Conclusion, It´s better to use Solve.SOLVE command instead of SOLVE. only
Thank you very much Tim, you nailed it and I´ve learnt an useful lesson.

cyrille de brébisson · 05-22-2015, 05:30 AM

Hello,

In the case of IRR, where you are doing purely numerical calculations, Solve.SOLVE is the best solution.

If you are using the SOLVE command in an app program that belong to an app that is based on Solve, there is no need to do Solve.SOLVE, but SOLVE is enough.

If you are doing it from the command line and the current app is a copy of Solve, SOLVE is also enough.

To do something generic that will work everywhere, you need to do Solve.SOLVE.

solve and fsolve are CAS functions and are designed to work more on CAS objects. Since the equation that you are trying to solve is a numerical function, using CAS functions will be very inefficient as you will be repetitively having to convert from CAS to non CAS.

Cyrille

salvomic · 05-22-2015, 07:53 AM

(05-22-2015 05:30 AM)cyrille de brébisson Wrote: fsolve are CAS functions and are designed to work more on CAS objects. Since the equation that you are trying to solve is a numerical function, using CAS functions will be very inefficient as you will be repetitively having to convert from CAS to non CAS.

Cyrille

yes, I know, but in the program about IRR I needed to explore every result, not only the (only) numeric given by Solve.SOLVE...
Mostly, well suited problems for IRR give only this result, and Solve.SOLVE is the better solution, but to test the problem I used some series of flows "at limit", where or IRR gives more solutions, or it's needed MIRR and not IRR... So, both solution "solve" the problem, depending on what happen...

However, generally we treat (about IRR) lists (or matrix) with relatively few items (10-100 max), so inefficiency is a problem that's "acceptable"...

Salvo

toml_12953 · 05-22-2015, 09:19 AM

Well, I'm glad that's SOLVEd (solve.SOLVEd? solved?)

Marcio · (This post was last modified: 05-22-2015 09:59 AM by Marcio.)

(05-22-2015 09:19 AM)toml_12953 Wrote: Well, I'm glad that's SOLVEd (solve.SOLVEd? solved?)

Tom, if you can't solve things with solve.SOLVE which is suppose to solve independently of the solve app, things are not solved!

salvomic · 05-22-2015, 10:30 AM

(05-22-2015 09:19 AM)toml_12953 Wrote: Well, I'm glad that's SOLVEd (solve.SOLVEd? solved?)

Tom, if you can't solve things with solve.SOLVE which is suppose to solve independently of the solve app, things are not solved!
[/quote]

indeed, we are solving the solution, to find a true Solve or solve the solution..., better so, than without a SOLVE method Smile