Little explorations with HP calculators (no Prime)

[pier4r]

Digression
So, after years I have a bit of time to reuse the hp50g and I'm pretty rusty. Not that I was great before, but surely I was a bit more fluent in the library of built in functions of my hp50g.

While I know that already this forum and the old forum on this site have plenty of interesting topics to explore, without checking also comp.sys.hp48, the official support forum by HP and other online forums (if still the links that I have are valid), it is a bit time consuming to find them among other topics. It is a great tasks but not now.

So as a quick but not so trivial (i.e: I can solve them even when I'm tired only with my mind, not even paper) source of math problems to solve with the help of the calculator, I turned to brilliant.org that now, as in 2013, is the only site of its type that I know. (To find similar collections of problems one has to dig forums, like here)
End of digression

From here, every time I cannot solve a problem that I think could be solved with the calculator, I ask for your help if you don't mind. Also, since the new forum let posts grow, I hope to use just this thread to accumulate stuff without creating multiple ones.

So first problem. (neat the inclusion of MathJax, kudos to the admin!)

Quote: \[ \Large \begin{array} {c c c } & & \color{green}{C} \\ + & \color{green}{C} & \color{green}{C} \\
\hline & \color{purple}{D} & 4 \\ \end{array} \]

In this cryptogram, \(\color{green}{C}\) and \(\color{purple}{D}\) represent two different digits. What is the value of \( \color{green}{C} \)?

Now I solved this manually, because I was not able to find a way to let the calculator solve this.

manually I ended up recognizing that C cannot be 2, so it has to be " 2*c mod 10 = 4 " , once found C, the rest is fine.
For the calculator, though, I was using something like:

\[ c + 10c + c = 10d + 4 \]

But that is obviously not enough for the solver. So, how would you solve it?

[Thomas Okken]

12c = 10d + 4

captures only part of the puzzle.
What's missing are these:

c ≠ d
c, d ∈ { 0, 1, 2, ... 9 }

The first equation establishes a straightforward relationship between c and d, but the third one puts this puzzle in the realm of discrete mathematics or number theory. The numerical solvers in calculators aren't designed for such problems, and in fact, many such problems are notoriously difficult, for example:

find a, b, c, n such that

a^n + b^n = c^n

It's trivial to find solutions to this, but if you add these conditions:

a, b, c, n ∈ N
a, b, c > 0
n > 2

It's suddenly a lot harder. :-)

[pier4r]

(03-15-2017 11:56 PM)Thomas Okken Wrote:  What's missing are these:

c ≠ d
c, d ∈ { 0, 1, 2, ... 9 }

The first equation establishes a straightforward relationship between c and d, but the third one puts this puzzle in the realm of discrete mathematics or number theory. The numerical solvers in calculators aren't designed for such problems

I was hoping that there was a way to insert those somehow as conditions (like inequalities or such things). Thanks!

[ekubaskie]

Is it even possible for a calculator or computer to "know" the things we see right off? Like if C <> D then the addition has to have a carry, which cannot possibly be more than one, therefore D = C+1? Or that to cause a carry, C > 4?

Once you know that then you can ignore the tens column's C and D completely and just use the carry. C + C = 14.

Interesting, too, that the whole puzzle will still "work" with the sum as D0, D2, or D6. I love my HPs and have RPNed for very close to 45 years now, but I'm glad our brains are far enough above them to actually have fun trying to make them figure out something like this puzzle.

[Csaba Tizedes]

1.) My first thought was that, where is the puzzle? This is simply wrong - because C+CC=D8, not D4!
2.) OK, which BASE is that where this will be OK? If we assume that the digits are marked with the English alphabet, it's simply to calculate in base=20 the above addition will be right: C+20×C+C = (12)+20×(12)+(12)=264 and 20×D+4=20×(13)+(4)=264, so it is OK.
3.) Also, as per original quiz, as I can see we must to solve (C)+(C)×b+(C) = (D)×b+(4), and we are searching for C, D digits and b base.
4.) In base b=10, the solution is C=7 and D=8

Csaba

[Logan]

(03-15-2017 11:56 PM)Thomas Okken Wrote:  in fact, many such problems are notoriously difficult, for example:

find a, b, c, n such that

a^n + b^n = c^n

It's trivial to find solutions to this, but if you add these conditions:

a, b, c, n ∈ N
a, b, c > 0
n > 2

It's suddenly a lot harder. :-)

That's not hard, I could write down my marvelous little proof but this text box is too narrow.

[TASP]

C = bleen

[pier4r]

So I got to another problem and I'm stuck.

Quote:Brilliant.org
Let

\[A= \sum_{n=1}^{2014}{n} ~~~\text{and} ~~~ B= \sum_{n=1}^{2014}{n^3}.\]

Find the value of \(\log_{\sqrt A} {B}\)

Now, I know the closed formulas for the two summations, but I want to solve it with the calculator as much as I can. (one is "n(n+1)/2" the other is the square of the previous value, the more slightly complicated one is the summation of the term "n^2" but this is not the case )

I found out about the summation symbol (see hp50g AUR, almost at the end of the chapter 3. In short 'n' 1 2014 'n' <right shift, sin : for the summation>. Also proper flags have to be set) and I can compute the first sum to 2029105 .

For the second sum, I can compute it too, but I end up with a floating point number (4.11726710102e12). This is further aggravated if I want to push a bit the summation of n^3 until, say 5000 (ending with 1.5631[...]e14), and so on.

I remember that the hp50g is able to print out long numbers, I tried so search on internet a bit and I found no built in functions. I found a post mentioning the library longFloat (how much great work on for those little devices!) but before trying to use it I would like to ask here, where there are a lot of experienced people compared to me.

Am I wrong when I remember that the hp50g can, by default, print out abitrary precision numbers?

[Joe Horn]

(03-21-2017 10:40 PM)pier4r Wrote:  So I got to another problem and I'm stuck.

Quote:Brilliant.org
Let

\[A= \sum_{n=1}^{2014}{n} ~~~\text{and} ~~~ B= \sum_{n=1}^{2014}{n^3}.\]

Find the value of \(\log_{\sqrt A} {B}\)

Now, I know the closed formulas for the two summations, but I want to solve it with the calculator as much as I can. (one is "n(n+1)/2" the other is the square of the previous value, the more slightly complicated one is the summation of the term "n^2" but this is not the case )

I found out about the summation symbol (see hp50g AUR, almost at the end of the chapter 3. In short 'n' 1 2014 'n' <right shift, sin : for the summation>. Also proper flags have to be set) and I can compute the first sum to 2029105 .

For the second sum, I can compute it too, but I end up with a floating point number (4.11726710102e12). This is further aggravated if I want to push a bit the summation of n^3 until, say 5000 (ending with 1.5631[...]e14), and so on.

If you enter the expression in exact mode, with all the numbers being integers (no decimal point!), and EVAL it instead of using ->NUM, then you'll get the exact answer 4117367101025. Ditto for any upper limit or power (within reason of course!).

If you are in exact mode, but still get floating-point approximations instead of exact integer results, your flag -3 might be set, or some other flag.

Quote:I remember that the hp50g is able to print out long numbers, I tried so search on internet a bit and I found no built in functions. I found a post mentioning the library longFloat (how much great work on for those little devices!) but before trying to use it I would like to ask here, where there are a lot of experienced people compared to me.

Am I wrong when I remember that the hp50g can, by default, print out abitrary precision numbers?

It can output integers of any length, but floating-point precision is always 12 mantissa digits unless you insteall the LongFloat library, which you should, because it's awesome, allowing mantisssas up to 9999 digits long(!), and huge exponents.

[pier4r]

@Joe Horn

Thanks for the help. I checked quickly. Multiplying a 9 by itself, I quickly went past 15 digits without problems.

Still if I do 'n' 1 2014 'n^3' <shift right, SIN (this is to get the sum)> I get a floating point number.

The sum function requires the flag 3 set.

I have flags 1, 3 set (the ones related to computations, I have others set but they are for something else) and exact mode (flag 105 not set). With those, I can produce a long integer but not using the sum function. Maybe is the funtion itself producing floats?

[John Keith]

The Sigma (sum) function works with real and complex numbers but not with exact integers. Thus it will always give a real result if given exact integers.

If you are familiar with programming, it is easy to write a quick program to do the summation.

John

[Joe Horn]

(03-22-2017 08:37 AM)pier4r Wrote:  @Joe Horn

Thanks for the help. I checked quickly. Multiplying a 9 by itself, I quickly went past 15 digits without problems.

Still if I do 'n' 1 2014 'n^3' <shift right, SIN (this is to get the sum)> I get a floating point number.

The sum function requires the flag 3 set.

The AUR says that, but it's wrong. Try it with flag -3 clear. It works, and returns exact values.

(03-22-2017 08:37 AM)pier4r Wrote:  I have flags 1, 3 set (the ones related to computations, I have others set but they are for something else) and exact mode (flag 105 not set). With those, I can produce a long integer but not using the sum function. Maybe is the funtion itself producing floats?

As I wrote above, it returns exact values when fed exact inputs and executed in exact mode with flag -3 clear. If that doesn't work for you, perhaps you have an obsolete firmware version? The most recent VERSION is 2.15. Or maybe you have some other conflicting flag(s)?

EDIT: The ROM version can't be the problem, because I just tried it on an ancient 49G (version 1.19-6) and it works ok there too.

(03-22-2017 12:14 PM)John Keith Wrote:  The Sigma (sum) function works with real and complex numbers but not with exact integers. Thus it will always give a real result if given exact integers.

Not true, at least in VERSION 2.15. This is interesting... I gotta know why some 50g's can't return exact values for the Sigma function.

"Yes, it's puzzling. I don't think I've ever seen anything quite like this before." -- HAL 9000

[pier4r]

(03-22-2017 03:27 PM)Joe Horn Wrote:  The AUR says that, but it's wrong. Try it with flag -3 clear. It works, and returns exact values.

Well I just followed the orders, once I digged to avoid approximations.

So yes, 'n' 1 2014 'n^3' \GS works now (I cleared flag 3 and 105), but the result is incorrect.

It returns 16452725990416 while I would have expected 4117267101025 .

Could you tell me which flag do you have set that could affect the result? At the moment I have only the flags 1 , 27 set that may affect the computational procedures.

If you have more info how to let the \GS work as intented, I'm happpy. The more I use built in functions, the better. Moreover it was extra fast compared to my little program.

[John Keith]

(03-22-2017 03:27 PM)Joe Horn Wrote:  The AUR says that, but it's wrong. Try it with flag -3 clear. It works, and returns exact values.

(03-22-2017 12:14 PM)John Keith Wrote:  The Sigma (sum) function works with real and complex numbers but not with exact integers. Thus it will always give a real result if given exact integers.

Not true, at least in VERSION 2.15. This is interesting... I gotta know why some 50g's can't return exact values for the Sigma function.

Ha! You're right! I, too, was relying on what was written in The Fine Manual. I tried it on my 50g (2.15 ROM) and it does indeed return an exact result.

John

[John Keith]

Oh, and try this:

'n' 1 100 'INV(n) \GS

(i.e. the 100th harmonic number)

Not only exact but a symbolic result containing the Psi function, which I have never seen before on the 50g. I used to think of the \GS function as slow and annoying to use but I now have greater respect for it.

Thanks, Joe!

[pier4r]

(03-22-2017 11:11 PM)John Keith Wrote:  Ha! You're right! I, too, was relying on what was written in The Fine Manual. I tried it on my 50g (2.15 ROM) and it does indeed return an exact result.

John

Did you get the correct result? Why do I get the wrong one?

So if I leave the flags 1 and 27 I get

   

   
(wrong result)

Otherwise if I set the flag 3 or 105 I get

   

   
(correct result, but as real)

[pier4r]

While checking the release notes for the rom 2.15 I discovered the bug repository and I found a gem.

http://bugs.hpcalc.org/show_bug.cgi?id=260

Quote:increase the RAM to anywhere between 128MB to 1GB. people are going to be
programming and developing for this calculator. give them room to do some
serious programming!

It is impressive how little awareness people have about hardware constraints (battery life) and other things. Moreover I saw plenty of serious programming for the 50g not even using all the 230 kb of ram.

[Simone Cerica]

(03-23-2017 08:07 AM)pier4r Wrote:  

(03-22-2017 11:11 PM)John Keith Wrote:  Ha! You're right! I, too, was relying on what was written in The Fine Manual. I tried it on my 50g (2.15 ROM) and it does indeed return an exact result.

John

Did you get the correct result? Why do I get the wrong one?

So if I leave the flags 1 and 27 I get




(wrong result)

Otherwise if I set the flag 3 or 105 I get




(correct result, but as real)

   

probably you're wrong to do something, try to reset the calculator and clears the variable 'N', type the command CASCFG and try again...

[pier4r]

Yep it worked once I purged 'n' . I thought was done automagically.

Can I file a "bug" for the AUR of the hp 50g for those little quirks or is it wasted time? I mean would be nice to use the bug list even just as "list of community fixes".

[Joe Horn]

(03-23-2017 10:00 AM)pier4r Wrote:  Yep it worked once I purged 'n' . I thought was done automagically.

Can I file a "bug" for the AUR of the hp 50g for those little quirks or is it wasted time? I mean would be nice to use the bug list even just as "list of community fixes".

I see no bug here. Variables which are assigned values should never be used where formal variables are required. Managing them is up to the user.