Break line (HP50)

[CMarangon]

Hello!
(Reading time: 45 seconds)

I made the program below, to calculate a log of a number in a given basis.

≪CLEAR
"LOGa(b)
Enter a b"
"" INPUT OBJ→ → A B
≪ 'LN(B)/LN(A)' EVAL
"log" A "(" B ")" + + + + →TAG
≫
≫

Lets calculate
log2(500)

Result:
log2.(500.):8.96578......

I need press

to see:
log2.(500.):8.96578428466.
that is the full number.

My questions are,
1 - How can I from inside a program made the same as
press ?

2- How can I remove dots after the numbers link 2. and 500. in log2.(500.)?

[Gerson W. Barbosa]

(10-27-2020 12:36 AM)CMarangon Wrote:  My questions are,
1 - How can I from inside a program made the same as
press ?

2- How can I remove dots after the numbers link 2. and 500. in log2.(500.)?

1) -52 CF would work on the 48, but apparently it does nothing on the 50g.

2) Assuming your bases are always integer:

« CLEAR "LOGa(b)
Enter a b" "" INPUT OBJ→ → A B
« 'LN(B)/LN(A)' EVAL "log" A R→I "(" B DUP NOT { R→I } IFT ")" + + + + →TAG
»
»

————-

P. S.

Just a small workaround until we figure out what’s the problem with flag -52:

« CLEAR "LOGa(b)
Enter a b" "" INPUT OBJ→ → A B
« 'LN(B)/LN(A)' EVAL "log" A R→I "(" B DUP NOT { R→I } IFT ")" + + + + →TAG →STR TAIL ":" DUP 10. CHR + SREPL DROP
»
»

[CMarangon]

Hello Gerson!
Thank you for reply

I will try.

I sent you a private message...

(10-27-2020 02:07 AM)Gerson W. Barbosa Wrote:  

(10-27-2020 12:36 AM)CMarangon Wrote:  My questions are,
1 - How can I from inside a program made the same as
press ?

2- How can I remove dots after the numbers link 2. and 500. in log2.(500.)?

1) -52 CF would work on the 48, but apparently it does nothing on the 50g.

2) Assuming your bases are always integer:

« CLEAR "LOGa(b)
Enter a b" "" INPUT OBJ→ → A B
« 'LN(B)/LN(A)' EVAL "log" A R→I "(" B DUP NOT { R→I } IFT ")" + + + + →TAG
»
»

————-

P. S.

Just a small workaround until we figure out what’s the problem with flag -52:

« CLEAR "LOGa(b)
Enter a b" "" INPUT OBJ→ → A B
« 'LN(B)/LN(A)' EVAL "log" A R→I "(" B DUP NOT { R→I } IFT ")" + + + + →TAG →STR TAIL ":" DUP 10. CHR + SREPL DROP
»
»

[CMarangon]

Hello!

It works, but now I need to remove quotation marks.

Example:

log2 (400)

Result:

"log2(400):
8.64385618978"

Screenshot:

(10-27-2020 04:42 PM)CMarangon Wrote:  Hello Gerson!
Thank you for reply

I will try.

I sent you a private message...

(10-27-2020 02:07 AM)Gerson W. Barbosa Wrote:  1) -52 CF would work on the 48, but apparently it does nothing on the 50g.

2) Assuming your bases are always integer:

« CLEAR "LOGa(b)
Enter a b" "" INPUT OBJ→ → A B
« 'LN(B)/LN(A)' EVAL "log" A R→I "(" B DUP NOT { R→I } IFT ")" + + + + →TAG
»
»

————-

P. S.

Just a small workaround until we figure out what’s the problem with flag -52:

« CLEAR "LOGa(b)
Enter a b" "" INPUT OBJ→ → A B
« 'LN(B)/LN(A)' EVAL "log" A R→I "(" B DUP NOT { R→I } IFT ")" + + + + →TAG →STR TAIL ":" DUP 10. CHR + SREPL DROP
»
»

[Gerson W. Barbosa]

(10-27-2020 05:16 PM)CMarangon Wrote:  Hello!

It works, but now I need to remove quotation marks.

Example:

log2 (400)

Result:

"log2(400):
8.64385618978"

Screenshot:

Somehow I had left an FP command out, so I would expect "log2(400.):..."
Quotation marks still there, but this is better:

« CLEAR "LOGa(b)
Enter a b" "" INPUT OBJ→ → A B
« 'LN(B)/LN(A)' EVAL "log" A R→I "(" B DUP FP NOT { R→I } IFT ")" + + + + →TAG →STR TAIL DUP SIZE 20. > { ":" DUP 10. CHR + SREPL DROP } IFT
»
»

[Artur - Brasil]

The point is the decimal separator. HP50G put it in aproximated results. I soffered with this in my back to school LaPlace transforms and their matrices and other simple things, like comparing two data: 1. == 1 returns false.

I didn't use 50G for years and was a surprise to me such details I didn't remember was there in the past.

Best wishes
Artur

[CMarangon]

Hello Arthur!

I have a similar history.
I stopped using HP for years and now during Pandemic, I bought an HP50 and an HP Prime, both used, but working.
It is fine to get free from boring Covid's Time and Depressing Covid's News!

If you wish, please e-mail me at:
areaseg@hotmail.com

Kind regards,
Carlos - Curitiba

(10-28-2020 02:16 AM)Artur - Brasil Wrote:  The point is the decimal separator. HP50G put it in aproximated results. I soffered with this in my back to school LaPlace transforms and their matrices and other simple things, like comparing two data: 1. == 1 returns false.

I didn't use 50G for years and was a surprise to me such details I didn't remember was there in the past.

Best wishes
Artur

[Valentin Albillo]

(10-28-2020 04:40 AM)CMarangon Wrote:  If you wish, please e-mail me at:

Carlos, never post your e-mail address in the clear on a public forum, it might be harvested by bots and used for malicious intents (such as flooding you with spam or selling your e-mail address to who knows who for who knows what).

I siuggest you edit your post to remove your e-mail address as soon as possible.

V.

[DavidM]

(10-28-2020 02:16 AM)Artur - Brasil Wrote:  ...like comparing two data: 1. == 1 returns false.

Not sure about earlier ROM versions, but v2.15 returns a boolean true value (1 or 1.) on a 50g for the above test.

SAME, on the other hand, does not. SAME can be thought of as "do the two objects have the SAME bit-for-bit representation?" It doesn't attempt to interpret the arguments at all, and simply checks the data as represented on the calculator to see if the bit streams are identical for both objects.

The "==" operator is less strict, and will attempt to simplify some objects before determining equivalency. As an example, 1 '3-2' == returns a boolean true value, despite the two objects being tested having very different internal representations.

Considering the above, another distinct difference between SAME and == becomes apparent: SAME is much faster, and is generally better to use when you are checking objects of the same type for equivalency. This is usually not an issue unless you are mixing approximate numbers and exact integers in your calculations.

[Artur - Brasil]

(10-29-2020 12:16 PM)DavidM Wrote:  

(10-28-2020 02:16 AM)Artur - Brasil Wrote:  ...like comparing two data: 1. == 1 returns false.

Not sure about earlier ROM versions, but v2.15 returns a boolean true value (1 or 1.) on a 50g for the above test.

SAME, on the other hand, does not. SAME can be thought of as "do the two objects have the SAME bit-for-bit representation?" It doesn't attempt to interpret the arguments at all, and simply checks the data as represented on the calculator to see if the bit streams are identical for both objects.

The "==" operator is less strict, and will attempt to simplify some objects before determining equivalency. As an example, 1 '3-2' == returns a boolean true value, despite the two objects being tested having very different internal representations.

Considering the above, another distinct difference between SAME and == becomes apparent: SAME is much faster, and is generally better to use when you are checking objects of the same type for equivalency. This is usually not an issue unless you are mixing approximate numbers and exact integers in your calculations.

You're right, Dave. I'll see my code and check where I had to take care about 1. and 1 ...
See you soon!
Best wishes,
Artur