Decimal problem using solve

[vterez]

(Brazilian here, sorry if my English is bad)
I was trying to use the solve function to do my homework and I noticed something really weird:
I was solving this equation
70/(23000+z)=x*177.35+(1-x)*1.133
(23000+z)*(x*2571.11+(1-x)*696.21)=23000*104.91+z*2779.65
on my calculator and for some reason I received {} as my answer.

So I turned my computer on and typed the same equation on HP Prime Virtual Calculator and I got the right answer. The fact that my calculator didn't solve this really annoyed me, so I tried to change a few things (reducing a few terms, calculating partial results) and found out that if I changed (x*2571.11) and (x*177.35) to (x*257111/100) and (x*17735/100) and kept everything else (I could change other things but this was enought) the way it was in the first place, I would get my result.

At first sight I thought it could have something to do with decimal numbers multiplying the variables, but I didn't have to change (z*2779.65) nor (x*696.21), so I gave up trying to figure it out on my own.

Does anyone know if the solve function has problems with decimal numbers or something like that?

Thanks in advance,
Vitor.

[Aries]

Hi vterez,
are you in Home view or in CAS View ?
Is Exact CAS mode turned on or turned off ?
Best,

Aries

[vterez]

(08-26-2018 07:27 AM)Aries Wrote:  Hi vterez,
are you in Home view or in CAS View ?
Is Exact CAS mode turned on or turned off ?
Best,

Aries

I used the exact same set up on my computer and on my calculator and even tried changing them on my calculator. Tried in HOME and in CAS View, enabled/disabled the Exact and Principal CAS modes, set the auto-simplification to minimum, even increased the recursive parameters but nothing changed. The only thing that really worked was changing some decimals to fractions. Not that it is a problem, but for a moment I thought that this simple (not so simple, but still simple) equation couldn't be solved by an expensive calculator and I'm afraid that there are more little glitches someone may experience that could be easily solved.

[DrD]

Different ways to solve it:

1. [CAS]
solve({(70/(23000+z)) = (x*177.35+(1-x)*1.133), ((23000+z)*(x*2571.11+(1-x)*696.21)) = (2412930.+z*2779.65)}, [x,z]);

2. [HOME]
CAS.solve("{(70/(23000+z)) = (x*177.35+(1-x)*1.133),((23000+z)*(x*2571.11+(1-x)*696.21)) = (2412930.+z*2779.65)},[x,z]")

3. [HOME] (Solve App):
[Symb]
E1: (70/(23000+Z))=X*177.35+(1-X)*1.133
E2: (23000+Z)*(X*2571.11+(1-X)*696.21)=23000*104.91+Z*2779.65
[Num]
Press [Solve] softkey

-Dale-

[Albert Chan]

(08-26-2018 02:57 AM)vterez Wrote:  (Brazilian here, sorry if my English is bad)
I was trying to use the solve function to do my homework and I noticed something really weird:
I was solving this equation
70/(23000+z)=x*177.35+(1-x)*1.133
(23000+z)*(x*2571.11+(1-x)*696.21)=23000*104.91+z*2779.65
on my calculator and for some reason I received {} as my answer.

If it were homework, I think it meant not using SOLVE, calculator only for number crunching.
You really should do y = 1/(23000+z), and simplified it by hand:

70*y = x*177.35+(1-x)*1.133
(x*2571.11+(1-x)*696.21) = (2779.65*(23000+z) + 23000*(104.91-2779.65)) / (23000+z) = 2779.65 - 61519020*y

Above simplified to linear equations:
70*y = 1.133 + 176.217*x
61519020*y = 2083.44 - 1874.9*x

Cancel the y's --> x ~ -0.00641604 --> z ~ 6358.11

Regarding the {} answer, I believe SOLVER assumed decimals as float, to speed up calculation.
Slight rounding error cause above into nonlinear equations.

[vterez]

(08-26-2018 10:02 AM)DrD Wrote:  Different ways to solve it:

1. [CAS]
solve({(70/(23000+z)) = (x*177.35+(1-x)*1.133), ((23000+z)*(x*2571.11+(1-x)*696.21)) = (2412930.+z*2779.65)}, [x,z]);

2. [HOME]
CAS.solve("{(70/(23000+z)) = (x*177.35+(1-x)*1.133),((23000+z)*(x*2571.11+(1-x)*696.21)) = (2412930.+z*2779.65)},[x,z]")

3. [HOME] (Solve App):
[Symb]
E1: (70/(23000+Z))=X*177.35+(1-X)*1.133
E2: (23000+Z)*(X*2571.11+(1-X)*696.21)=23000*104.91+Z*2779.65
[Num]
Press [Solve] softkey

-Dale-

I typed the exact same thing you showed on way 1 (it was not a syntax error, just a solution error). I didn't try using the solve app, gonna try sometime.

[vterez]

(08-26-2018 07:22 PM)Albert Chan Wrote:  If it were homework, I think it meant not using SOLVE, calculator only for number crunching.
You really should do y = 1/(23000+z), and simplified it by hand:

70*y = x*177.35+(1-x)*1.133
(x*2571.11+(1-x)*696.21) = (2779.65*(23000+z) + 23000*(104.91-2779.65)) / (23000+z) = 2779.65 - 61519020*y

Above simplified to linear equations:
70*y = 1.133 + 176.217*x
61519020*y = 2083.44 - 1874.9*x

Cancel the y's --> x ~ -0.00641604 --> z ~ 6358.11

Regarding the {} answer, I believe SOLVER assumed decimals as float, to speed up calculation.
Slight rounding error cause above into nonlinear equations.

I did solve it myself, I was just checking my results.
I love to solve math problems by hand (I swear I spend some free time playing with matrixes and finding zeros for some equations) but since this was just a small part of the problem and it is not for math class, is for advanced circuit analysis, I wouldn't mind using my calculator to solve it. I am almost graduating in Electrical Engineering and my teachers tell the students to use computer solving to save time (which is a relief when I stumble across some really annoying problems involving complex numbers).

[Albert Chan]

Hi, vterez:

I thougt that was a math class problem ...

I dont know HP Prime, but Mathematica have similar issue.
Decimals were assumed inexact, and use fast float.

This force Mathematica to solve it exactly:

Code:

Solve[ Rationalize @ {
    70/(23000+z) == (177.35 x + 1.133 (1-x)),
    (23000+z)*(2571.11 x + 696.21 (1-x)) == 23000*104.91 + 2779.65 z
  }, {x, z}
]

[Tim Wessman]

The quickest way to deal with this is when you get back your empty set [ ]:

(assuming you are in the cas screen)

1. Tap ONCE on your solve(...) entry to select it. (the line about your [ ] empty set)
2. Press the [a b/c] key
3. You get back exact(solve(....)) and it returns an expression as the "answer" containing solve(<all_decimals_converted_to_fractions>)
4. Tap your expression twice and press ENTER. You may need to press shift-Enter for "Approximate" since you'll get back an exact, very big fraction




The [a b/c] key will insert a call to "exact()" which will convert your decimals to fractions which now gives you exact numbers for the calculation. This allows exact, CAS type calculations vs numerical solvers which are inexact by nature and can be thrown easily for a loop if they start with initial bad guesses, or have other types of issues. The reason why you might be seeing different results happening is due to initial guesses. In some cases (from memory, I might be wrong here), the CAS will use random number generation within ranges to seed those guesses. Hence why you might see differing results sometimes.

[Albert Chan]

(08-26-2018 07:22 PM)Albert Chan Wrote:  70*y = x*177.35+(1-x)*1.133
(x*2571.11+(1-x)*696.21) = (2779.65*(23000+z) + 23000*(104.91-2779.65)) / (23000+z) = 2779.65 - 61519020*y

Above simplified to linear equations ...

I noticed another trick to solve above, with regression mode of my Casio
Above problem look exactly like interpolation within interval

70*y = i1(x)
i2(x) = 2779.65 - 61519020*y

Let Y = 61519020 i1(x) + 70 i2(x). To satisfy above, Y = 70 * 2779.65

At x=0, Y = 61519020 * 1.133 + 70 * 696.21
At x=1, Y = 61519020 * 177.35 + 70 * 2571.11

Enter these 2 points for linear regression, interpolate for Y = 70 * 2779.65, I get x = -6.41604187e-3

[vterez]

(08-27-2018 04:55 AM)Tim Wessman Wrote:  The quickest way to deal with this is when you get back your empty set [ ]:

(assuming you are in the cas screen)

1. Tap ONCE on your solve(...) entry to select it. (the line about your [ ] empty set)
2. Press the [a b/c] key
3. You get back exact(solve(....)) and it returns an expression as the "answer" containing solve(<all_decimals_converted_to_fractions>)
4. Tap your expression twice and press ENTER. You may need to press shift-Enter for "Approximate" since you'll get back an exact, very big fraction




The [a b/c] key will insert a call to "exact()" which will convert your decimals to fractions which now gives you exact numbers for the calculation. This allows exact, CAS type calculations vs numerical solvers which are inexact by nature and can be thrown easily for a loop if they start with initial bad guesses, or have other types of issues. The reason why you might be seeing different results happening is due to initial guesses. In some cases (from memory, I might be wrong here), the CAS will use random number generation within ranges to seed those guesses. Hence why you might see differing results sometimes.

It worked. Thanks.