Threaded Mode | Linear Mode

Claudio L. · 06-03-2016, 01:59 AM

(06-02-2016 03:40 AM)Francois Lanciault Wrote: Found what I think is another bug:

The function DET gives an error "Invalid opcode" when used on a valid matrix

For example:

[ [4 2 7] [7 2 9] [1 4 8] ]
DET

Gives 8 on standard firmware but "Invalid opcode" in newRPL.

I know the matrix is entered correctly because newRPL will compute its inverse without reporting any error and return the correct result.

François

Many functions in the matrix library are not implemented. Their names were listed and ready to implement (hence they show up in autocomplete, they compile and decompile properly) but their execution is not done yet. DET is one of those. In general, the "Invalid Opcode" comes up when the interpreter finds a command that's not implemented. Sorry I had to leave that library half-done, I should probably disable those commands for the time being (you can check the detailed status page to see which commands are ready for testing).

Claudio L. · 06-03-2016, 02:21 AM

(06-02-2016 07:58 AM)JoJo1973 Wrote: Ok, I'll start some torture tests on built-in functions... results will surface on this thread ASAP.

If I've correctly understood the implementation in your code, infinities are just normal numbers with an INFINITY flag set. This could open interesting possibilities:

±∞ are represented just by ±1 with INFINITY flag set

Complex ∞ is represented by (0,0) with real and imaginary parts having INFINITY flag set

Similarly a point at infinity on the complex plane is represented as a generic complex number (normalized to unitary modulus?) with real and imaginary parts having INFINITY flag set. In this way the calc could return meaningful results to programs such as « -∞ 4 XROOT ».

Wolfram Alpha has just taught me that this program is meaningful, and the answer is (sqrt(2)/2,sqrt(2)/2)*∞. Quite logical, if I think about it!

I see two advantages: everything seems to be already in place for implementation, and numeric type will be automatically been taken care of by the system. What do you think?

It could work, though I haven't thought about it in depth. So a complex infinity would be shown on the stack as (∞,∞)? Or perhaps it should be (∞, NaN), in other words: infinite magnitude, but unknown direction. Or perhaps it should be a polar complex? (∞, ∡0.5r).
In your example -∞ 4 XROOT the result is still infinity, but the result should actually be (∞, ∡45°).
Treating real -∞ as (-1,0)*∞ is a neat trick, but I'm not sure it has any real use. You could do the same by using a variable instead of infinity, operate to get the result you need, then take limit when it tends to infinity.

JoJo1973 · (This post was last modified: 06-03-2016 01:01 PM by JoJo1973.)

(06-03-2016 02:21 AM)Claudio L. Wrote: It could work, though I haven't thought about it in depth. So a complex infinity would be shown on the stack as (∞,∞)? Or perhaps it should be (∞, NaN), in other words: infinite magnitude, but unknown direction. Or perhaps it should be a polar complex? (∞, ∡0.5r).
In your example -∞ 4 XROOT the result is still infinity, but the result should actually be (∞, ∡45°).
Treating real -∞ as (-1,0)*∞ is a neat trick, but I'm not sure it has any real use. You could do the same by using a variable instead of infinity, operate to get the result you need, then take limit when it tends to infinity.

EDIT: Rephrasing and clarification

Well, (-1,0)*∞ was not intended by me as trick to manipulate infinite quantities, but just a way to represent them internally. On the stack the only thing the user should see is "+∞", "-∞" or "∞". For directed infinities, the polar notation (∞, ∡45°) is very expressive and compact; for rectangular notation one could display "(...)∞" (i.e. "(3-4i)∞").

I don't want to seem to push my own ramblings on your project (if I had the technical expertise I could at least contribute with code and not with words!) but, just for the sake of discussion, have you considered to give to infinities and NaN's the "angle treatment" i.e. promote them to full fledged objects?

After all:

They appear in multiple variants (real, complex, unsigned, directed)
They are argument of functions and can be returned as result of functions, sometimes unexpectedly (at least for me... complex analysis has never been my forte . Think for example at ACOS(-∞): Undefined in real domain, -i*∞ in the complex domain.
They combine with numeric types and operators in their peculiar ways: this page explains better than I could do the tricky relationships between infinities and NaN's.
Handling them in a library of their own, with overloaded operator supports should allow for concise coding and greater flexibility (e.g. NaN's could represent different indeterminate forms)
Being a separate class of objects could be advantageous for the CAS: substitution rules dealing with them could be easily written and managed

Claudio L. · 06-03-2016, 02:17 PM

(06-03-2016 08:16 AM)JoJo1973 Wrote:
(06-03-2016 02:21 AM)Claudio L. Wrote: It could work, though I haven't thought about it in depth. So a complex infinity would be shown on the stack as (∞,∞)? Or perhaps it should be (∞, NaN), in other words: infinite magnitude, but unknown direction. Or perhaps it should be a polar complex? (∞, ∡0.5r).
In your example -∞ 4 XROOT the result is still infinity, but the result should actually be (∞, ∡45°).
Treating real -∞ as (-1,0)*∞ is a neat trick, but I'm not sure it has any real use. You could do the same by using a variable instead of infinity, operate to get the result you need, then take limit when it tends to infinity.

EDIT: Rephrasing and clarification

Well, (-1,0)*∞ was not intended by me as trick to manipulate infinite quantities, but just a way to represent them internally. On the stack the only thing the user should see is "+∞", "-∞" or "∞". For directed infinities, the polar notation (∞, ∡45°) is very expressive and compact; for rectangular notation one could display "(...)∞" (i.e. "(3-4i)∞").

I don't want to seem to push my own ramblings on your project (if I had the technical expertise I could at least contribute with code and not with words!) but, just for the sake of discussion, have you considered to give to infinities and NaN's the "angle treatment" i.e. promote them to full fledged objects?

After all:

They appear in multiple variants (real, complex, unsigned, directed)

They are argument of functions and can be returned as result of functions, sometimes unexpectedly (at least for me... complex analysis has never been my forte . Think for example at ACOS(-∞): Undefined in real domain, -i*∞ in the complex domain.

They combine with numeric types and operators in their peculiar ways: this page explains better than I could do the tricky relationships between infinities and NaN's.

Handling them in a library of their own, with overloaded operator supports should allow for concise coding and greater flexibility (e.g. NaN's could represent different indeterminate forms)

Being a separate class of objects could be advantageous for the CAS: substitution rules dealing with them could be easily written and managed

So much food for thought that I'm going to choke! Let's see...
If infinity is an object, what would the math library return when trying to divide 1 by 0 (which are reals)? Right now it simply marks the result with an infinity flag, because the only thing the decimal library can return is a real number. Object infinity would have to be handled 100% by higher level code (RPL library) as opposed to the decimal math library, including all special cases that could cause an infinity result, like TAN(∡90°). Right now in this example, the TAN function returns a real infinity, but the TAN code itself doesn't know anything about objects yet, it only deals with real numbers.
So having a separate object might not help the developer of newRPL libraries that much, as every new command would need to handle the various new special objects.

I think a simple way to represent it would be:
∞ (with or without the sign) = real infinity.
(∞, ∡0.3r) = Complex infinity (directed)

Since polar numbers stay polar in newRPL, Infinities don't need to be represented in cartesian form. However, this leaves one question: How to represent complex infinity in symbolic form?
The complex form (x,y) is not allowed in a symbolic expression (though right now due to bad handling of complex numbers, adding a complex to a symbolic actually displays it in (x,y) form, but that shouldn't be allowed). I think '(x+i*y)*∞' is the only way to properly represent it (a complex number times real infinite magnitude), so we could say that directed infinity is doable.
What about undirected infinity? I think there's no other way but to create a special symbol. Doesn't have to be a special object, though.
An undirected infinity can come out as a result of a divide by zero, so technically the decimal library should output an undirected complex infinity rather than a real infinity.
Thinking out loud, there's 2 flags on a real number: NAN and INF. What if we designate complex undirected infinity to a number that has BOTH flags up? It makes sense that it's infinity, but also undefined since it's direction in the complex plane is unknown.
It could be displayed with a special symbol, like ∞̅ which for some reason doesn't look good on this forum (Unicode Infinity with combining overline).
Yes, you could argue that doesn't make sense for complex infinity to be a real number... but it makes sense for a decimal library to be able to output complex infinity as a result of a real operation.
So in the end:
∞ (with or without the sign) = real infinity.
(∞, ∡0.3r) = Complex infinity (directed)
∞̅ = Undirected complex infinity (a real number w/some special flags).

This should be able to accomplish most of what you discussed without fundamentally changing existing code.
Undirected infinity should not be allowed inside a complex number though: (∞̅,0), (0,∞̅), (∞̅,∞̅) should be invalid.

emece67 · (This post was last modified: 06-03-2016 04:40 PM by emece67.)

(06-03-2016 02:17 PM)Claudio L. Wrote: It could be displayed with a special symbol, like ∞̅ which for some reason doesn't look good on this forum (Unicode Infinity with combining overline).

\(\overline\infty\), that's "\ (\overline\infty\ )", remove the spaces between \ and ( and between \ and ).

Sorry, I cannot be of more help here...

JoJo1973 · 06-03-2016, 09:22 PM

(06-03-2016 02:17 PM)Claudio L. Wrote: So much food for thought that I'm going to choke!

I hope not, I'd hate to see that! Wink

(06-03-2016 02:17 PM)Claudio L. Wrote: Let's see...
If infinity is an object, what would the math library return when trying to divide 1 by 0 (which are reals)? Right now it simply marks the result with an infinity flag, because the only thing the decimal library can return is a real number. Object infinity would have to be handled 100% by higher level code (RPL library) as opposed to the decimal math library, including all special cases that could cause an infinity result, like TAN(∡90°). Right now in this example, the TAN function returns a real infinity, but the TAN code itself doesn't know anything about objects yet, it only deals with real numbers.
So having a separate object might not help the developer of newRPL libraries that much, as every new command would need to handle the various new special objects.

And this settles the question, I guess... Clearly I hadn't reflected enough about how RPL functions interact with decimal library.

(06-03-2016 02:17 PM)Claudio L. Wrote: Yes, you could argue that doesn't make sense for complex infinity to be a real number... but it makes sense for a decimal library to be able to output complex infinity as a result of a real operation.
So in the end:
∞ (with or without the sign) = real infinity.
(∞, ∡0.3r) = Complex infinity (directed)
∞̅ = Undirected complex infinity (a real number w/some special flags).

This should be able to accomplish most of what you discussed without fundamentally changing existing code.

Sounds good. At the end the objective is to represent unambiguously the possible outcomes of infinity-related calculations.

(06-03-2016 02:17 PM)Claudio L. Wrote: Undirected infinity should not be allowed inside a complex number though: (∞̅,0), (0,∞̅), (∞̅,∞̅) should be invalid.

Definitely not. BTW your previous remark about division by zero reminded me a question I wanted to ask you: will NewRPL have a "complex mode" like the original firmware or will the functions seamlessly return results in the appropriate domain?

I'm asking because some calculations (e.g. SQRT(-1)) return complex results if possible while others (e.g. LN(-1)) yield "Argument Outside Domain" error.

Claudio L. · (This post was last modified: 06-04-2016 12:28 AM by Claudio L..)

(06-03-2016 09:22 PM)JoJo1973 Wrote: Definitely not. BTW your previous remark about division by zero reminded me a question I wanted to ask you: will NewRPL have a "complex mode" like the original firmware or will the functions seamlessly return results in the appropriate domain?

I'm asking because some calculations (e.g. SQRT(-1)) return complex results if possible while others (e.g. LN(-1)) yield "Argument Outside Domain" error.

It already has a complex mode: you can enable it with
-103 SF
Sorry, I didn't give it a proper name yet because it isn't finished, so you have to use the flag number (soon it will be either 'COMPLEX' SF or 'CPLXMODE' SF). You'll see a C in the status area. when enabled.

Many transcendental functions are already working but it's still a work in progress (ASINH, ACOSH, ATANH, LOG and ALOG are not done yet if I remember correctly).

The fact SQRT returns a complex when not in complex mode is a bug you just found: I forgot to check for the complex mode flag on that one.

I debated for a long time about removing the mode and having different sets of commands for complex (like CSIN, CCOS, etc.), but I hit a wall with the overloadable operators.
If we want -1 0.5 ^ to return a complex or give an error, and we can't have a parallel set of operators, there's no choice but to have a complex mode controlled by a flag.

EDIT: BTW, division by zero returns an error "Infinite result". This error can be disabled with the flag -22, so functions can return infinity without complaining.

Vtile · (This post was last modified: 06-09-2016 02:52 PM by Vtile.)

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?

Claudio L. · 06-09-2016, 08:09 PM

(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.

emece67 · 06-09-2016, 10:28 PM

If this can also manage SI prefixes (k, M, G, \(\mu\) and the like) it would be really useful.

Vtile · 06-10-2016, 06:14 AM

Well I have few comments, but I have no time to make decent writing, so I'll return at monday.

(06-09-2016 10:28 PM)emece67 Wrote: If this can also manage SI prefixes (k, M, G, \(\mu\) and the like) it would be really useful.

How do you mean. ENG notation is for just that, but with 10^x in steps of 3. I think you didn't mean those, but actual symbols.

emece67 · 06-10-2016, 08:42 AM

(06-10-2016 06:14 AM)Vtile Wrote:
(06-09-2016 10:28 PM)emece67 Wrote: If this can also manage SI prefixes (k, M, G, \(\mu\) and the like) it would be really useful.
How do you mean. ENG notation is for just that, but with 10^x in steps of 3. I think you didn't mean those, but actual symbols.

That's what I mean, the ability to display 1.234k or 56.345G (or even 1k123 and 56G345).

Claudio L. · 06-13-2016, 07:05 PM

(06-10-2016 08:42 AM)emece67 Wrote:
(06-10-2016 06:14 AM)Vtile Wrote: How do you mean. ENG notation is for just that, but with 10^x in steps of 3. I think you didn't mean those, but actual symbols.

That's what I mean, the ability to display 1.234k or 56.345G (or even 1k123 and 56G345).

I couldn't find any reference to this way of writing being used or endorsed by any group or organization. Can you point me in the right direction? I want to see how (and if) this is standarized somewhere so we can adhere to it.

emece67 · (This post was last modified: 06-13-2016 08:02 PM by emece67.)

(06-13-2016 07:05 PM)Claudio L. Wrote:
(06-10-2016 08:42 AM)emece67 Wrote: That's what I mean, the ability to display 1.234k or 56.345G (or even 1k123 and 56G345).

I couldn't find any reference to this way of writing being used or endorsed by any group or organization. Can you point me in the right direction? I want to see how (and if) this is standarized somewhere so we can adhere to it.

I suppose you are referring to the later use, with the prefix replacing the decimal dot/comma. I have no idea if it is standardized by anybody, but it is in common use in EE. See, for example, the schematics on this service manual of a Nokia phone. You will see lots of components whose value is something like 3k3, 4u7 (4.7·10^-6), 1u5, 2u2, 6p8 (6.8·10^-12) and so on.

I suspect that this is as a safeguard against tiny dots "missed" in big paper sheets.

Regards.

Vtile · (This post was last modified: 06-14-2016 12:50 PM by Vtile.)

(06-13-2016 07:59 PM)emece67 Wrote:
(06-13-2016 07:05 PM)Claudio L. Wrote: I couldn't find any reference to this way of writing being used or endorsed by any group or organization. Can you point me in the right direction? I want to see how (and if) this is standarized somewhere so we can adhere to it.

I suppose you are referring to the later use, with the prefix replacing the decimal dot/comma. I have no idea if it is standardized by anybody, but it is in common use in EE. See, for example, the schematics on this service manual of a Nokia phone. You will see lots of components whose value is something like 3k3, 4u7 (4.7·10^-6), 1u5, 2u2, 6p8 (6.8·10^-12) and so on.

I suspect that this is as a safeguard against tiny dots "missed" in big paper sheets.

Regards.

It also shortens the notation by one character. I don't know If I have seen it anywhere else than electronics and with resistor values. With magnitude prefixes you need to know the value of such prefix and with so called engineering notation (with magnitude steps of thousand) you need to know the correct prefix for a value.

While 3k3 style marking would be cool, I don't see much of an true value for it. Since anyone who uses such should be fluent of magnitude prefixes anyway, so 3.3k(Ohm) or 3.3e3 should be as clear as 3k3..

Claudio L. · (This post was last modified: 06-14-2016 02:18 PM by Claudio L..)

(06-14-2016 12:48 PM)Vtile Wrote:
(06-13-2016 07:59 PM)emece67 Wrote: I suppose you are referring to the later use, with the prefix replacing the decimal dot/comma. I have no idea if it is standardized by anybody, but it is in common use in EE. See, for example, the schematics on this service manual of a Nokia phone. You will see lots of components whose value is something like 3k3, 4u7 (4.7·10^-6), 1u5, 2u2, 6p8 (6.8·10^-12) and so on.

I suspect that this is as a safeguard against tiny dots "missed" in big paper sheets.

Regards.
It also shortens the notation by one character. I don't know If I have seen it anywhere else than electronics and with resistor values. With magnitude prefixes you need to know the value of such prefix and with so called engineering notation (with magnitude steps of thousand) you need to know the correct prefix for a value.

While 3k3 style marking would be cool, I don't see much of an true value for it. Since anyone who uses such should be fluent of magnitude prefixes anyway, so 3.3k(Ohm) or 3.3e3 should be as clear as 3k3..

Interesting that they use this notation to omit actual physical units. 3k3 = 3.3_kΩ and 100p = 100_pF. But do they use this notation to actually perform calculations?
Let's say your result from a calculation is 3243.54534_Ω (or just the number, forget the unit). I don't see an easy way to display it, it would look like 3k24354534 ? or 3.24354534k?
The first one looks like an integer at first sight, as the letter gets lost in the numbers so while it might work for display of final numbers (like resistor values, all rounded and neat), it's not very good for general number display. The second form is doable (it's relatively simple to replace the ENG exponents for a single letter).
There's a lot of room for confusion, though, as 100k looks very similar to 100_K, same thing for 100m and 100_m. There's also the issue of which prefixes to use (all 20?). If I read 100a on the screen, I don't personally know what that means, unless I go to an SI reference table to see that a = atto = 10^-18.
There's also a prefix E = exa = 10^18, which looks like I forgot to print the exponent:
100E and 100E3 are quite similar.

If there's enough interest or a real use I can implement it, but I see some potential issues with this notation.

EDIT: I just thought of parsing issues if the user types 100E, is that a syntax error or the user actually means 100*10^18?

emece67 · 06-14-2016, 03:35 PM

(06-14-2016 02:16 PM)Claudio L. Wrote: Interesting that they use this notation to omit actual physical units. 3k3 = 3.3_kΩ and 100p = 100_pF. But do they use this notation to actually perform calculations?
Let's say your result from a calculation is 3243.54534_Ω (or just the number, forget the unit). I don't see an easy way to display it, it would look like 3k24354534 ? or 3.24354534k?
The first one looks like an integer at first sight, as the letter gets lost in the numbers so while it might work for display of final numbers (like resistor values, all rounded and neat), it's not very good for general number display. The second form is doable (it's relatively simple to replace the ENG exponents for a single letter).
There's a lot of room for confusion, though, as 100k looks very similar to 100_K, same thing for 100m and 100_m. There's also the issue of which prefixes to use (all 20?). If I read 100a on the screen, I don't personally know what that means, unless I go to an SI reference table to see that a = atto = 10^-18.
There's also a prefix E = exa = 10^18, which looks like I forgot to print the exponent:
100E and 100E3 are quite similar.

Keep in mind that this is an (ab)use of notation by engineers. I fact no EE (well, most of then) cares much about numbers such as 3k24354534, they only want to know about 3k2, so the k is not missed. (You know, for EE people the volume of a cow, or any other animal in fact, is half the cube of the distance from horns to tail ;-)

I understand that many people will need to read the table to know that 2 aA is 2·10^-18 amperes, but my personal case is just the other, The machine gives 2·10^-18 A, then I convert it to 2 aA and this is "the value" of the current. I find many students lost when dealing with powers of ten until they start to think with the prefixes.

In any case, I asked for this notation (or the simpler one 2.34 k, or 2.34_k or whatever you think enough clear and easy to implement) as a display only capability accessed thru a combination of keys similar to that Vtile proposed to circle between different powers of ten in ENG mode (here circling between different prefixes). Forcing the machine to parse expressions like "0u1 ENTER 10000p +" in order to return 110n0 seems overkill to me. Perhaps for "heavier" use the unit approach "2.3_u ENTER 100_p +" can be better, provided the UNIT system can cope with non-dimensional quantities with prefixes but w¡thout units.

As a side note. The "complete" use of this notation (as I know it) is this: the dot/comma is always replaced by the prefix and the unit is appended at the end (eg. 3u3F is 3.3·10^-6 Farad). If the prefix is 1, then it is replaced by a letter identifying the magnitude (and using R instead of \(\Omega\) for Ohms, thus 3R3 means 3.3 Ohm and 2H2 is 2.2 H).

Claudio L. · 06-16-2016, 12:32 PM

(06-14-2016 03:35 PM)emece67 Wrote: Keep in mind that this is an (ab)use of notation by engineers. I fact no EE (well, most of then) cares much about numbers such as 3k24354534, they only want to know about 3k2, so the k is not missed. (You know, for EE people the volume of a cow, or any other animal in fact, is half the cube of the distance from horns to tail ;-)

I understand that many people will need to read the table to know that 2 aA is 2·10^-18 amperes, but my personal case is just the other, The machine gives 2·10^-18 A, then I convert it to 2 aA and this is "the value" of the current. I find many students lost when dealing with powers of ten until they start to think with the prefixes.

In any case, I asked for this notation (or the simpler one 2.34 k, or 2.34_k or whatever you think enough clear and easy to implement) as a display only capability accessed thru a combination of keys similar to that Vtile proposed to circle between different powers of ten in ENG mode (here circling between different prefixes). Forcing the machine to parse expressions like "0u1 ENTER 10000p +" in order to return 110n0 seems overkill to me. Perhaps for "heavier" use the unit approach "2.3_u ENTER 100_p +" can be better, provided the UNIT system can cope with non-dimensional quantities with prefixes but w¡thout units.

I think some clarity starts to emerge here. The unit system already supports prefixes (not without units though), however, it won't automatically convert to your preferred prefix.
I think the best compromise without breaking the rules of the SI system is to enforce the use of units but auto-convert to a desired prefix. If you are willing to type 2.34_k then 2.34_kF or 2.34_kA is not going to give you carpal tunnel syndrome.
When in ENG mode, I can try to display units using a prefixed unit instead of showing an exponent, so if your number is 3300_Ω, in ENG mode it will show 3.3_kΩ instead of 3.3E3_Ω (display only, the actual object on the stack remains 3300_Ω).
It's not exactly what you asked for, but this way it will work for all units, so other disciplines can also use this feature (nothing against EE :-).
If/when I implement the changing ENG exponent (I'm still not clear on how to implement it), it shouldn't be too difficult to implement this on units too.
I think it should be a "preferred exponent" that you can change at will (perhaps it has to be a separate mode, as ENG chooses the best exponent for you). For example, if your preferred exponent is set to 3, all number displays will be forced to display as NNNE3, and all units would be forced to have the k prefix.

emece67 · 06-16-2016, 01:38 PM

(06-16-2016 12:32 PM)Claudio L. Wrote: I think it should be a "preferred exponent" that you can change at will (perhaps it has to be a separate mode, as ENG chooses the best exponent for you). For example, if your preferred exponent is set to 3, all number displays will be forced to display as NNNE3, and all units would be forced to have the k prefix.

I think that such "preferred exponent" is not needed, in fact it can be counter-intuitive. Nobody expects to get capacitance values in kF, MF or whatever prefix greater than 1 (or even m) you select but, on the other side, few people want to see resistance values in n\(\Omega\) or p\(\Omega\). I think that the system choosing the "right" exponent (in such a way that, at the left of the dot/comma, there are 1, 2 or 3 significant digits) is the right way. I think there's an Android calculator (HiPER Scientific Calculator? not sure, I no longer have and android phone, in fact I no longer have a mobile phone at all) that supports this mode.

Claudio L. · 06-16-2016, 06:09 PM

(06-16-2016 01:38 PM)emece67 Wrote: I think that such "preferred exponent" is not needed, in fact it can be counter-intuitive. Nobody expects to get capacitance values in kF, MF or whatever prefix greater than 1 (or even m) you select but, on the other side, few people want to see resistance values in n\(\Omega\) or p\(\Omega\). I think that the system choosing the "right" exponent (in such a way that, at the left of the dot/comma, there are 1, 2 or 3 significant digits) is the right way. I think there's an Android calculator (HiPER Scientific Calculator? not sure, I no longer have and android phone, in fact I no longer have a mobile phone at all) that supports this mode.

Well, the normal ENG mode does exactly that: choose an exponent such that the integer part is between 0-999.