Threaded Mode | Linear Mode

Vtile · (This post was last modified: 06-17-2016 03:21 PM by Vtile.)

(06-09-2016 08:09 PM)Claudio L. Wrote:
(06-09-2016 02:09 PM)Vtile Wrote: Hey one feature proposal (if it is not there already). This arises from the Casio ENG key - thread hovering around in the forums atm.

Could it be possible and beneficial to make (at some point of course) ENG key to function as a special Shift key along its normal exponent of ten ( Ex ) function. So that you can control the shown exponent value in steps of three. Let me explain by rough example..

You press and hold [ EEX ] at the same time you press left arrow.. Value is now shown in format of "X e0-3"

You press and hold [ EEX ] at the same time you press Right arrow.. Value is now shown in format of "X e0+3"

You press and hold [ EEX ] at the same time you press UP arrow.. Value is now changed "X * 1e0+3"

You press and hold [ EEX ] at the same time you press DOWN arrow.. Value is now changed "X * 1e0-3"

This could be used also in different modes, ie. in FIX mode you could change the number of shown decimals on the fly and UP/Down could be used to round the value to specific lenght.

In scientific mode it would work similar as in ENGineering, but with exponent steps of one.

Or something similar on these lines. Atm. atleast on the HP firmware the EEX & Arrows combination have no functions (if not counted the normal swap,editor etc.).
What people think?

I like this a lot! Something along the lines of using On-+/- to change the contrast, no need to get into a special form to change settings. Of course, newRPL supports a very complex way to display numbers, as there are 3 different number formats (for large, medium, small numbers), and the user has to select the limits between those classes of numbers too.
But we could have simple defaults that can be controlled from the keyboard directly.
Here's a simple proposal:
On + [space] can cycle between STD/SCI/FIX/ENG predefined defaults.
On + [number] can select display digits (On+9 = 9 digits, etc.).
On + [dot] can cycle between using dot, dot+thousand separator, comma, comma+thousand separator
On + [div] can increase the display digits by 1
On + [mult] can decrease the display digits by 1

In newRPL there's no such thing as moving the ENG exponent by 3 places. I need to study how to add that feature (should we call it exponent bias?), though I don't anticipate it being too difficult.

I'm actually not sure what you are truely meaning with exponent bias, maybe something you later posts refer as preferred magnitude or similar.

For my propose of using [EEX] as a special shift key (while you hold it down, just like [ON] key or [RShift]+[TOOL] to change R<>C) I see it more convenient way to manipulate the exponent and or other "display rounding properties ie. FIX n". More so than the ON+"keys".

Now one week after my half thought proposal I'm not sure anymore if the actual and real magnitude changing (actual shortcut for multiplying with 1000 or 0.001) I proposed for [EEX]+[UP]/[DOWN] would be the best option and truely usefull. Much more usefull option would be to change the shown decimals on fly as you propose for [On]+[mult]/[Div]. The [EEX]+[RIGHT]/[LEFT] would still be truely handy for those moments your head decides to turn pool of jelly and you struggle to comprehend some value like 800.0e-3 . With ie. [EEX]+[LEFT] (the working direction logic must be decided at somepoint to fit other parts of the system) you change shown exponent format (temporarily?) by one step at time. Maybe there would be better options?

For [EEX]+[up]/[down] it would change the decimals shown in all number formats. (This would be extremely handy ie. in standard and FIX modes) My argument over [ON] is that with [EEX] or [LShift]+[EEX] you kind of do similar task while entering the numbers.

How it exactly works on Casio, I don't know since I only momentarily owned the ClassPad2 and there to 50g, previously I were two decades rather unhappy owner of the original TI-83+ (Uh, laplace tables etc. *yak*)

For [ON]+[Div]/[Mult] you could change ie. the precision used internally? if that is planned feature. Like Decimal(xxx) or similar command on the Maple software (while I really can't remember were there ability to exceed the IEE floating point precision).

What I forgot to mention or comment.. hmm.

Guenter Schink · 06-18-2016, 03:17 PM

Weird!

Consider this symbolic expression '(1+1/x)^x'. Store 1E9 in "x" then press EVAL while the expression is on the stack. It will take about 42sec until the expression is evaluated to '1000000001/1000000000'. If you key ->NUM instead, the expression is solved instantly to 2.7182818271.

Günter

Claudio L. · 06-18-2016, 06:10 PM

(06-18-2016 03:17 PM)Guenter Schink Wrote: Weird!

Consider this symbolic expression '(1+1/x)^x'. Store 1E9 in "x" then press EVAL while the expression is on the stack. It will take about 42sec until the expression is evaluated to '1000000001/1000000000'. If you key ->NUM instead, the expression is solved instantly to 2.7182818271.

Günter

Actually, the result I got is '(100000001/1000000000)^1000000000'. What happens is you stored an exact value into X, therefore EVAL will try to compute only an exact result. This means the fraction 1+1/1e9 results in 100000001/100000000, then it does the power, which means multiplying this fraction by itself 1e9 is of the order of 2^29, so it does at least 29 fraction multiplications, each time simplifying the fraction and increasing the precision as needed to keep the result exact. After a while, it reaches a point where the maximum system precision of 2000 digits is not enough to produce an exact answer, so it gives up and presents the result in exact form.
Now if you store 1e9. (see the trailing dot there?) the system will know you are interested in approximated numbers, then it will instantly present you with the same answer as ->NUM, at the current system precision.

Guenter Schink · 06-18-2016, 06:29 PM

(06-18-2016 06:10 PM)Claudio L. Wrote:
(06-18-2016 03:17 PM)Guenter Schink Wrote: Weird!

Consider this symbolic expression '(1+1/x)^x'. Store 1E9 in "x" then press EVAL while the expression is on the stack. It will take about 42sec until the expression is evaluated to '1000000001/1000000000'. If you key ->NUM instead, the expression is solved instantly to 2.7182818271.

Günter

Actually, the result I got is '(100000001/1000000000)^1000000000'.

Ah, you're right, my omission

Quote: What happens is you stored an exact value into X, therefore EVAL will try to compute only an exact result. This means the fraction 1+1/1e9 results in 100000001/100000000, then it does the power, which means multiplying this fraction by itself 1e9 is of the order of 2^29, so it does at least 29 fraction multiplications, each time simplifying the fraction and increasing the precision as needed to keep the result exact. After a while, it reaches a point where the maximum system precision of 2000 digits is not enough to produce an exact answer, so it gives up and presents the result in exact form.
Now if you store 1e9. (see the trailing dot there?) the system will know you are interested in approximated numbers, then it will instantly present you with the same answer as ->NUM, at the current system precision.

Thanks for the explanation, but

sorry, I still can't follow. I'd expect, that the "x" within the symbolic expression would simply be substituted by its stored value. I don't see, that anything has to be computed at this time . Seems I have an odd understanding of the symbolic expressions.

Günter

Guenter Schink · 06-18-2016, 06:33 PM

(06-18-2016 06:29 PM)Guenter Schink Wrote:
(06-18-2016 06:10 PM)Claudio L. Wrote: Actually, the result I got is '(100000001/1000000000)^1000000000'.
Ah, you're right, my omission

Quote: What happens is you stored an exact value into X, therefore EVAL will try to compute only an exact result. This means the fraction 1+1/1e9 results in 100000001/100000000, then it does the power, which means multiplying this fraction by itself 1e9 is of the order of 2^29, so it does at least 29 fraction multiplications, each time simplifying the fraction and increasing the precision as needed to keep the result exact. After a while, it reaches a point where the maximum system precision of 2000 digits is not enough to produce an exact answer, so it gives up and presents the result in exact form.
Now if you store 1e9. (see the trailing dot there?) the system will know you are interested in approximated numbers, then it will instantly present you with the same answer as ->NUM, at the current system precision.

Thanks for the explanation, but

sorry, I still can't follow. I'd expect, that the "x" within the symbolic expression would simply be substituted by its stored value. I don't see, that anything has to be computed at this time . Seems I have an odd understanding of the symbolic expressions.

Günter

Huh, disregard, after rereading your explanation I got it. Sometimes somewhat slow.

Smile

Günter

Claudio L. · 06-19-2016, 02:44 AM

(06-18-2016 06:33 PM)Guenter Schink Wrote: Huh, disregard, after rereading your explanation I got it. Sometimes somewhat slow.

Günter

You asked a good question, as is not as trivial as it seems. I actually added a new command to newRPL called EVAL1 (it's along press on the EVAL key) to do only 1 step in the evaluation process. EVAL tries to do as much as possible replacing variables, and performing operations/simplifications as long as it keeps the result exact (fully equivalent to the expression being evaluated). EVAL1 will instead do a single step, in this case it would replace the variables, without trying to simplify the fraction or do the power.

So there's 3 different evaluations of a symbolic:
EVAL1: Does a single step
EVAL: Does all steps possible keeping the exact expressions exact, while approx. numbers in the expression are computed.
->NUM: Does all steps possible, and doesn't care if they are not exact, uses numeric approximations always.

It's roughly the same as the 50g, but not quite as EVAL will work like ->NUM if you have approximate mode enabled (there's no such mode in newRPL). I think this caused your confusion, as you expected EVAL to be the same as ->NUM.

Claudio L. · 06-22-2016, 03:56 PM

June update!
Please go to the first post for download instructions.

Changes in this update are various:

* Added support for Unicode combining marks (currently, only the overline is drawn, others are ignored).
* Added complex infinity symbol (Left-shift-hold-0) (no functions return this symbol yet)
* Added SD card support (most important SDSTO and SDRCL, but try all SDXXX commands). So far it's SD only, SDHC will be supported in the future but not for now (we need plain SD to flash the firmware anyway)
* Added immediate settings shortcuts for the keyboard:

On-Dot: Cycle between various number formatting options
On-SPC: Cycle between various number formatting modes
On-0 through On-9: Select display number of digits (for STD and FIX it's number of figures after the dot, for SCI/ENG it's total number of significant figures displayed).
On-/ On-*: Change forced display exponent for ENG mode (this is experimental, if there's no use it will be removed).
On-Up On-Down: Change current system precision by 8 digits (up/down).

There's other minor bug fixes and updates to some commands, but these are the most significant changes.

As usual, please test and report!

Nigel (UK) · 06-23-2016, 08:04 PM

Just to let you know that the high current draw problem with newRPL on my HP49G+ continues with this new release: "on" current of about 40 mA, "off" current of about 4 mA, and - with right shift pressed and ON held down - an amazing draw of 150 mA!

Is anyone else with an HP49G+ having the same problem? Or is there something wrong with my machine? It looks like I'll have to buy myself another HP50g if I am to use newRPL on a regular basis.

Nigel (UK)

JoJo1973 · 06-23-2016, 08:59 PM

I confirm the battery drain bug on my HP49G+. A fresh set of batteries lasts about a week before discharging completely. Backup battery is unaffected, though.

Claudio L. · 06-24-2016, 02:00 AM

(06-23-2016 08:04 PM)Nigel (UK) Wrote: Just to let you know that the high current draw problem with newRPL on my HP49G+ continues with this new release: "on" current of about 40 mA, "off" current of about 4 mA, and - with right shift pressed and ON held down - an amazing draw of 150 mA!

Is anyone else with an HP49G+ having the same problem? Or is there something wrong with my machine? It looks like I'll have to buy myself another HP50g if I am to use newRPL on a regular basis.

Nigel (UK)

(06-23-2016 08:59 PM)JoJo1973 Wrote: I confirm the battery drain bug on my HP49G+. A fresh set of batteries lasts about a week before discharging completely. Backup battery is unaffected, though.

We need to come up with a plan, as I don't have a 49G+ to test on. First of all, I need you to download and flash the latest firmware, which includes 2 new commands PEEK and POKE that we can use for debugging. I'll start thinking about the current drain and will give you a series of POKE's to try out while you measure the current. Stay tuned.

Nigel (UK) · 06-24-2016, 05:54 AM

I have the latest firmware loaded. I await instructions!

Nigel (U(?)K)

JoJo1973 · 06-24-2016, 11:52 AM

Me too! Ready to go!

Claudio L. · 06-24-2016, 01:54 PM

First test:

Turn calculator on and measure current consumption (A)

Run this program, then measure current (B).

<< #05600014h 0 POKE >>

Now run this other program, then measure current (C).

<< #05600014h 4 POKE >>

Explanation: This is the speaker port. Normally it's being driven low (A), and the first program forces it to low state (B), so in theory B=A.
The second program drives it high (C). It's expected that (C) > (B), so newRPL leaves the speaker driven low when at sleep, this test will confirm that this is the correct configuration for the 49G+ too.

This is a fun port to play with:

<< 1 1000 START #05600014H DUP PEEK 4 BXOR POKE NEXT >>

Let me know the current values.

Nigel (UK) · 06-24-2016, 02:31 PM

(06-24-2016 01:54 PM)Claudio L. Wrote: First test:

Turn calculator on and measure current consumption (A)

A is 42.3 mA for me. (Actually, the first time I apply power from the lab power supply the calculator turns on and draws a current of just over 80 mA. Turning the calculator off and on from the keyboard causes the current to drop to 42.3 mA.)

Quote:Run this program, then measure current (B).

<< #05600014h 0 POKE >>

No change: B = A.

Quote:Now run this other program, then measure current (C).

<< #05600014h 4 POKE >>

A brief increase in current of between 3 to 4 mA; current quickly falls back to previous value. The multimeter I'm using takes about 2 readings per second, so I can't give you an exact value for the maximum value of this current pulse.

Quote:This is a fun port to play with:

<< 1 1000 START #05600014H DUP PEEK 4 BXOR POKE NEXT >>

Let me know the current values.

This made a musical buzzing sound; the current rose to about 46 mA while the program was running, and then it returned to its original value.

I suspect this information is mostly negative, but perhaps it will help to rule out a possible cause of the problem.

Nigel (UK)

Guenter Schink · 06-24-2016, 02:52 PM

(06-22-2016 03:56 PM)Claudio L. Wrote: June update!

On-Dot: Cycle between various number formatting options
On-SPC: Cycle between various number formatting modes
On-0 through On-9: Select display number of digits (for STD and FIX it's number of figures after the dot, for SCI/ENG it's total number of significant figures displayed).
On-/ On-*: Change forced display exponent for ENG mode (this is experimental, if there's no use it will be removed).
On-Up On-Down: Change current system precision by 8 digits (up/down).

As usual, please test and report!

Using the "On"-button as another shift-key could perhaps provide a means to re-enact the original functions of the additional menu keys.
1. On APP, On MODE and On TOOL would then do what their function was in UserRpl
2. Holding left or right shift combined with the respective key would act accordingly.
3. This could work for the HIST key as well.
This would certainly help to navigate on the keyboard.

I think the new functions on the arrow keys, UPDIR, HOME, BEGIN, END etc., are so intuitive, they could exist in parallel.

Günter

Guenter Schink · 06-24-2016, 03:33 PM

LS UP or LS (hold) UP changes the directory correctly as expected but not the status area.

ON- 0 through 9 works nicely. How to get all digits displayed?
Günter

Guenter Schink · 06-24-2016, 04:35 PM

A very interesting list of SD-commands

Code:

SDNEXTFILE

SDOPENDIR

SDEOF

SDFILESIZE

SDTELL

SDSEEKCUR

SDSEEKEND

SDSEEKSTA

SDREADLINE

SDWRITETEXT

SDREADTEXT

SDCLOSE

SDOPENMOD

SDOPENAPP

SDOPENWR

SDOPENEND

SDPGDIR

SDMKDIR

SDCHDIR

SDRCL

SDSTO

SDSETPART

SDRESET

Look at this glitch
"This is some text" 'test' SDSTO
'test' will be turned into 'TEST' on the sdcard, which is o.k. as FAT doesn't distinguish between capital and lower characters.
BUT the command 'test' SDRCL will result in an error message "File not found". 'TEST' SDRCL works of course.

Next step: "another text" 'test' SDSTO will create a file "test;" which then is not accessible from the calculator. Now I change that name on the sdcard to 'test1' and SDRCL will work correctly

Günter

Claudio L. · 06-24-2016, 10:07 PM

(06-24-2016 02:31 PM)Nigel (UK) Wrote: I suspect this information is mostly negative, but perhaps it will help to rule out a possible cause of the problem.

Inconclusive I'd say. I don't think the speaker is the cause of the current drain as it made no difference. I'm not interested in the transients you see, more in the idle current after it settles down. The peaks are because the CPU works to execute the code and then redraw the stack, etc.

We'll have to look somewhere else. More later.

Claudio L. · 06-24-2016, 10:11 PM

(06-24-2016 02:52 PM)Guenter Schink Wrote: Using the "On"-button as another shift-key could perhaps provide a means to re-enact the original functions of the additional menu keys.
1. On APP, On MODE and On TOOL would then do what their function was in UserRpl
2. Holding left or right shift combined with the respective key would act accordingly.
3. This could work for the HIST key as well.
This would certainly help to navigate on the keyboard.

I think the new functions on the arrow keys, UPDIR, HOME, BEGIN, END etc., are so intuitive, they could exist in parallel.

Günter

The idea is to recall or change system settings with the On-as-a-shift method. However, there's at least one problem: you can't change settings while in the command line editor, as pressing On cancels the edit.
I'll have to think about a workaround for that.

Claudio L. · 06-24-2016, 10:15 PM

(06-24-2016 03:33 PM)Guenter Schink Wrote: LS UP or LS (hold) UP changes the directory correctly as expected but not the status area.

ON- 0 through 9 works nicely. How to get all digits displayed?
Günter

I'll have to investigate, I thought I had fixed that bug about the status area update.

To get all digits displayed... you'll have to wait for the full GUI to change the settings, no shortcut on the keyboard (unless you want to propose one?).