Reading one or two arguments

[HillyBoy]

Hi,

This is my first post on this forum. I have been using a HP-48GX for some 30 years now, but that died on me a few days ago. I replaced it with a HP-Prime and try to understand the current PPL language.

On my 48GX I had a small program that allowed me to convert a vector to its two arguments and vice versa. These vectors I use a lot in land-surveying: by switching from and to polar mode I can easily convert a coordinate-pair to distance and argument and vice versa (and add sets to each other). On the Prime I can do the same using a complex in the following notation: (a,b).

Starting point is one or two arguments on the stack.
The problem I now have is that after testing the first argument on the stack I need to make a decision:
IF TYPE(Arg1) == 0... I need to read to read Arg2 and return them as complex (Arg1, Arg2)
IF TYPE(Arg1) == 3... there is only one complex argument available, all I need to do is return its length and argument to the stack.

Reading two arguments is easy, provided they are available:
EXPORT MyProg(Arg1, Arg2)

But as I do not know in advance whether I can get 1 or 2 arguments, I need to start my program as

EXPORT MyProg(Arg1)

and test Arg1 first, before reading Arg2 when TYPE(Arg1)==0.

The other problem I have is how to return two arguments to the stack...

thanks in advance for your suggestions,
Nicolàs

[essen]

(03-13-2021 04:18 PM)HillyBoy Wrote:  Hi,

This is my first post on this forum. I have been using a HP-48GX for some 30 years now, but that died on me a few days ago. I replaced it with a HP-Prime and try to understand the current PPL language.

On my 48GX I had a small program that allowed me to convert a vector to its two arguments and vice versa. These vectors I use a lot in land-surveying: by switching from and to polar mode I can easily convert a coordinate-pair to distance and argument and vice versa (and add sets to each other). On the Prime I can do the same using a complex in the following notation: (a,b).

Starting point is one or two arguments on the stack.
The problem I now have is that after testing the first argument on the stack I need to make a decision:
IF TYPE(Arg1) == 0... I need to read to read Arg2 and return them as complex (Arg1, Arg2)
IF TYPE(Arg1) == 3... there is only one complex argument available, all I need to do is return its length and argument to the stack.

Reading two arguments is easy, provided they are available:
EXPORT MyProg(Arg1, Arg2)

But as I do not know in advance whether I can get 1 or 2 arguments, I need to start my program as

EXPORT MyProg(Arg1)

and test Arg1 first, before reading Arg2 when TYPE(Arg1)==0.

The other problem I have is how to return two arguments to the stack...

thanks in advance for your suggestions,
Nicolàs

If your calculator settings are in RPL mode, then a program can read stack values
with Ans(N). Where N is the stack number. This work in RPL mode only. The RPL mode
on the Prime is humbug. So if your are going continue with Prime, I strongly advice you to set it in Algebraic mode, if not buying a dedicated RPL calculator. Input to your Prime program when it is in algebraic mode should be done programmatically via the Input() function. Read up on this command in help.

The TYPE() and type() functions are unreliable to use. Because, they change as
the wind blows. Not only changes from shifting CAS/HOME, but also changes in
interaction with other functions in a program. And sometimes it spits out some
numbers and names than given in the help menu. For example, if your program
expects 0 for a float number, it sometimes give you a name; DOM_FLOAT.
Do this, EVAL(TYPE(MyARG)). By this a type name gets evaluated to a number.
This will ease type decision making in the program.

I' m trying out this calculator myself. It's a failure

[Han]

(03-13-2021 04:18 PM)HillyBoy Wrote:  Hi,

This is my first post on this forum. I have been using a HP-48GX for some 30 years now, but that died on me a few days ago. I replaced it with a HP-Prime and try to understand the current PPL language.

On my 48GX I had a small program that allowed me to convert a vector to its two arguments and vice versa. These vectors I use a lot in land-surveying: by switching from and to polar mode I can easily convert a coordinate-pair to distance and argument and vice versa (and add sets to each other). On the Prime I can do the same using a complex in the following notation: (a,b).

Starting point is one or two arguments on the stack.
The problem I now have is that after testing the first argument on the stack I need to make a decision:
IF TYPE(Arg1) == 0... I need to read to read Arg2 and return them as complex (Arg1, Arg2)
IF TYPE(Arg1) == 3... there is only one complex argument available, all I need to do is return its length and argument to the stack.

Reading two arguments is easy, provided they are available:
EXPORT MyProg(Arg1, Arg2)

But as I do not know in advance whether I can get 1 or 2 arguments, I need to start my program as

EXPORT MyProg(Arg1)

and test Arg1 first, before reading Arg2 when TYPE(Arg1)==0.

The other problem I have is how to return two arguments to the stack...

thanks in advance for your suggestions,
Nicolàs

Create a wrapper program that handles the number of arguments. In RPN mode, your program would be called with something like PROG(2) where the 2 here denotes the number of arguments to take from the stack and PROG is the name of your program. The 2 would be changed accordingly. In "Home" mode you would then then separate programs for each scenario (i.e. for each set of arguments: none, 1, 2, 3, etc.). However, if you want a single program to handle any number you would need to create a wrapper program that checks the number of arguments and then based on the arguments. This can be done using the "CAS" mode, which assumes that all input separated by a comma (or whatever separation symbol you use) is a vector/list.

Code:

#cas
myprog(args):=
BEGIN
  local s:=SIZE(args);
  CASE
    IF s==0 THEN
      // code for when no arguments supplied; for example run myprog0()
    END;
    IF s==1 THEN
      // code for when a single argument is supplied; for example run myprog1(a1)
    END;
    IF s==2 THEN
      // code for when 2 arguments are used; for example run myprog2(a1,a2)
    END;
  END;
END;
#end

[HillyBoy]

(03-13-2021 08:40 PM)essen Wrote:  If your calculator settings are in RPL mode, then a program can read stack values
with Ans(N). Where N is the stack number. This work in RPL mode only. The RPL mode
on the Prime is humbug. So if your are going continue with Prime, I strongly advice you to set it in Algebraic mode, if not buying a dedicated RPL calculator. Input to your Prime program when it is in algebraic mode should be done programmatically via the Input() function. Read up on this command in help.

The TYPE() and type() functions are unreliable to use. Because, they change as
the wind blows. Not only changes from shifting CAS/HOME, but also changes in
interaction with other functions in a program. And sometimes it spits out some
numbers and names than given in the help menu. For example, if your program
expects 0 for a float number, it sometimes give you a name; DOM_FLOAT.
Do this, EVAL(TYPE(MyARG)). By this a type name gets evaluated to a number.
This will ease type decision making in the program.

I' m trying out this calculator myself. It's a failure

Hi Essen,

to start with your last comment: I could not agree more, loosing the RPL programming functionality as on the 48GX makes this calculator near to useless for my kind of work. I bought the calculator anticipating it would again be a major improvement over previous models, but it is not. A fancy back-lit colour display is the last thing I need in a calculator, and also one may wonder if it is truly useful to have multiple ways operating the calculator itself (RPN, Home, CAS), while a high power consumption (compared to the 48GX) in combination with an battery-pack behind a lid-with-screws instead of standard AAA-batteries, is not very helpful for those who use it in the field. To me it seems that the Prime was designed by a young generation programmers with no connection to the past and oblivious of one of the major (if not the largest) user groups: the surveyors (at least here in the Netherlands that is).

Thanks for the input method using Ans(). I found it yesterday on another thread as well and meanwhile implemented it, that at least works for me.

I found out that the TYPE() command is quite buggy. Yesterday it kept on returning 3 (complex type), regardless the item I put on the stack. Only after I cleared the stack it started working properly again. I will add the EVAL() command to it, thanks for that suggestion!

Using INPUT() may not work for me. The program I am trying to replicate takes the result of previous calculations from the stack. These results are either X/Y coordinates or distance/direction pairs, at times as separate arguments and otherwise as complex types. With north being 0 degrees, I use them as (Y,X) and (dist,dir). I can add them easily in whatever combination and order, but at times either one of the two arguments of a pair needs modification. For that I need to split the complex type into separate elements, do further calculations on either one or both of them, and recombine them to a complex type to add them to another complex type. So the program I need does nothing else than splitting and combining. If I understand well, using INPUT will give me an input field where I have to enter the argument(s) manually instead of taking them from the stack (but I could be wrong there as the 48GX could retrieve from the stack, but it does add several keystrokes again).

Another nuisance is how polar complex types are dealt with. If I split a vector in the 48GX, the resulting arguments depended on the polar setting of the calculator. The Prime does not have a split function and has another way of showing complex types (i.e. each complex type on the stack has its own display mode). I believe there is no general polar setting and splitting the complex seems only be possible using IM(), RE(), ABS() and ARG(), which of course work independently from the polar setting for the complex type. So what I managed so far is to return a space-separated string containing all these four arguments. But now I have to remove the quotes around it to get them on my stack as separate arguments before I can use them again in further calculations, quite cumbersome. Using my 48GX I needed only three keystrokes to split a vector, with the prime the complex is split with no less than 10 keystrokes, despite my little program.

Another nuisance is that if I assign my program to a user key, that key will only place the text of my program (i.e. MyProg) on the command line, after which I have to press ENTER to get it executed. It seems impossible to execute it straight away, or am I missing something?

Once again I totally agree with you that this instrument is a total failure (compared to the 48GX).

Anyway, thanks for you help, that is much appreciated!

Nicolàs

[HillyBoy]

(03-14-2021 05:20 AM)Han Wrote:  Create a wrapper program that handles the number of arguments. In RPN mode, your program would be called with something like PROG(2) where the 2 here denotes the number of arguments to take from the stack and PROG is the name of your program. The 2 would be changed accordingly. In "Home" mode you would then then separate programs for each scenario (i.e. for each set of arguments: none, 1, 2, 3, etc.). However, if you want a single program to handle any number you would need to create a wrapper program that checks the number of arguments and then based on the arguments. This can be done using the "CAS" mode, which assumes that all input separated by a comma (or whatever separation symbol you use) is a vector/list.

Hi Han,

thanks for that suggestion, it may provide a solution to the export. I wonder if it is possible to detect the display mode of a complex number, because that would be really helpful to limit the output (i.e. only output IM() and RE() when the complex is shown in normal mode and export ABS() and ARG() when it is in polar mode).

Nicolàs

[essen]

(03-13-2021 04:18 PM)HillyBoy Wrote:  Hi,

This is my first post on this forum. I have been using a HP-48GX for some 30 years now, but that died on me a few days ago. I replaced it with a HP-Prime and try to understand the current PPL language.

On my 48GX I had a small program that allowed me to convert a vector to its two arguments and vice versa. These vectors I use a lot in land-surveying: by switching from and to polar mode I can easily convert a coordinate-pair to distance and argument and vice versa (and add sets to each other). On the Prime I can do the same using a complex in the following notation: (a,b).

Starting point is one or two arguments on the stack.
The problem I now have is that after testing the first argument on the stack I need to make a decision:
IF TYPE(Arg1) == 0... I need to read to read Arg2 and return them as complex (Arg1, Arg2)
IF TYPE(Arg1) == 3... there is only one complex argument available, all I need to do is return its length and argument to the stack.

Reading two arguments is easy, provided they are available:
EXPORT MyProg(Arg1, Arg2)

But as I do not know in advance whether I can get 1 or 2 arguments, I need to start my program as

EXPORT MyProg(Arg1)

and test Arg1 first, before reading Arg2 when TYPE(Arg1)==0.

The other problem I have is how to return two arguments to the stack...

thanks in advance for your suggestions,
Nicolàs

I read your objective as you wants to read the args standing on the
calculator window from your program. This is possible with the Ans(N).
Both in calculator settings - either in RPL or Algebraic mode. It is the
CAS mode, it doesn't function. But you can not have them as arguments
to your program. That is:
ThisPrg(Ans(1),Ans(2)) //This is not allowed
BEGIN
...
END;
Above not allowed

But you can do:
ThisPrg()
BEGIN
LOCAL a1,a2;
a1:=Ans(1);
a2:=Ans(2);
//now do operations on a1 and a2 and return the result to the window.
END;

Try below with your calculator in Algebraic mode setting and in HOME mode:
Put this on the window in same order as here. You will get arg and modulus
displayed in the window ( polar coor):
5.7735026919
10.0

and run MyPrg() from the command line:

MyPrg()
BEGIN
LOCAL a1,a2, r1,ang1,plar;
a1:=Ans(1);
a2:=Ans(2);
r1:=(a1^2+a2^2)^0.5;
Z1:=(a1,a2); //the complex
ang1:=ARG(Z1);
plar:=polar_coordinates(Z1);
//RETURN(plar);
RETURN(EXPR("["+r1+,","+ang1+"]")); //calc. by you own
END;

Of course, you can have args in MyPrg(), but just not Ans(N),
but inside as shown is OK.

I have an addition. You should be aware of this:

When using the ARG() function with the calculator in CAS mode
(in this case you don't, as Ans() does not function in this mode).
But in other programs in possibly CAS mode running, the angles
will always come out in radians, even the angle mode are set to
degrees in both HOME and CAS.

Therefore, if you calculates angles in CAS modes and want the result
out in degrees, then use the angle() function. See the help how that
one function.:

It uses 3 points angle((a1,b1),(a2,b2),(a3,b3)). It measure both
the angle and its direction as well as the quadrant its laying in.
Measuring an angle in a normal right angled (x,y) coordinate-system,
the first 2 points should always be set the same as (0,1, ...), because,
0 stands for the coordinate-systems origon (0,0), and the second
point 1 stands for the point laying on the x-axes (1,0).
Shorthand notations for these 2 first points are being accepted.
The angle are measured like this -
You're standing on the x-axes in point (1,0), then you go to the origon
point (0,0), and then to point (a3,b3). Your traces and its directions
define the angle.

[essen]

You don't need to return to the stack if a complex, Reading Ans(N) from
the stack does not remove it from the stack.

You can use affix() to turn a a 2-dimension vector or a point into a
complex notation.:
affix([4,6]); goes to (4,6). And affix((4,6)) goes to (4,6) or to 4+i*6
You have to know that Prime consider a point (a1,b1) being same as a1+i*6
Whether it is transformed into a1+i*6 depends on your calculator settings
of complex. Look up the settings for this. If your setting are a+b*i then
both [a1,b1] and (a1,b1) transform to a1+i*b1

The other poster showed you how to use IF... THEN...ELSE...END
clause to discriminate between the arguments. Whether you put these arguments
in via Ans(1) and Ans(2), or as doing it via the command line, as typing up
the Program name; MyPrg(), and using the direction button (the wriggling rocker
wheel under your thumb) to move it over the arguments for highlighting and Enter
them to MyPrg(here, and_here), does not matter. se all down how easy it is to convert a polar to a vector.

It' s not an all safe solution using eval as recommended. Whether
a name or an Integer results using this command still relies on
interaction with other commands in the executed program. And
whether using upper or under case letters for the function name,
and whether execution are in HOME or in CAS mode.

A better solution wil be doing a survey, when the program are
under development. Write this in the program under development:

ty:=TYPE((a1+b1*i));
RETURN(TY);

Now you can see what it returns to the window. For a complex
it should be 3.

If you want to use TYPE() to decide whether a variable are a complex
or a FLOAT (in most cases a 0 in HOME. but in CAS it sometimes is a 1 or a DOM_FLOAT). A name for it can not be used in an IF THEN ELSE END decision, because DOM_FLOAT isn't a string. So you cannot write IF ty==DOM_FLOAT THEN ...ELSE...END;
not either can you write IF ty=="DOM_FLOAT" THEN ...ELSE ...END;
The same is true with DOM_COMPLEX. You get an error!. But names can
be used in the EQ() clause, there it works. I have done this and seen it, anyway.

So what then:
If you return shows you a "3" for complex then use it in the decision clause.
It's easy to separate a complex. In my last post you saw that a polar point
is written as a vector [r1,arg1]. So, if Z!:=[r1,arg1]; then -

pt is a LOCAL or an EXPORT, if you're gone to use it for another program as a Global. Instead to transform to polar coor, you could transform to a vector
and use affix() to transform to a complex

IF ty==3 THEN
pt:=Z1[1]*[cos(Z1[2]),sin(Z1[2])]; //cartecian coor
pt:= affix(pt); //pt is now a complex
ELSE
...
END;

[HillyBoy]

Hi Essen,

thanks for this further and elaborate reply.
Yes, I am aware how to use an IF ... THEN ... ELSE ... clause after some 37 years of programming in more than a dozen languages, that is not the point (if memory serves me well I had my first computer, a ZX-Spectrum, back in 1984 and never stopped programming after that).

You wrote:

(03-14-2021 10:08 PM)essen Wrote:  You don't need to return to the stack if a complex, Reading Ans(N) from
the stack does not remove it from the stack.

Yes, I have noticed that Ans(N) keeps the item on the stack, which I find quite useful as it remains there for further calculations. I do, however, need the results from the calculations to return to the stack as I need them there for further work. But what I meant was that when using INPUT() I cannot get data from the stack, unless I know where it is beforehand, but then I do not need INPUT() as Ans(N) solves my case. Even if I could get items from the stack using INPUT(), I think the whole method of using an input field is way too cumbersome compared to what was possible with the 48GX. I could also populate a list with the stack items using Ans(N) and then use Choose() to get an item, but again this is way too cumbersome for what I need and still does not return multiple items in a useful way to the stack.

Anyway, I have got my program working well enough to assist me in my daily calculations, albeit with the cumbersome string-output to stack.

So thanks for your help, which is much appreciated!

Nicolàs

[essen]

thanks for this further and elaborate reply.
Yes, I am aware how to use an IF ... THEN ... ELSE ... clause after some 37 years of programming in more than a dozen languages, that is not the point (if memory serves me well I had my first computer, a ZX-Spectrum, back in 1984 and never stopped programming after that).

That's what I had in mind. I wouldn't risk opposing something against other answers
here. Well,
Your problem still there:
Why not the Return good ?.
Though, would not use this myself as a immediately parking station for a result, then fetching it for use as another Program. That's not the right way. I understand you
need the result calculations from your starting program going to another program.
Well, if your starting program are HOME executed, then you need to save the result
in EXPORT variables. Those can be fetched from any other programs running afterwards. A more suitable way are building following program on the same page.
One or more can be placed even below the main program, when declared on line
number 1. And if following are a CAS (enclosed by #cas ... #end), its name on
line 1. should be declared CAS.ProgramNavn();

I realize, you already know that. It seems you're on a test-mission. This stroke me
at first.

Yes, the Prime is more than a Failure. Et may be considered a Monster.

Command and function names are a mess of upper and lower case. Some works in both HOME and CAS mode. Some in one and not the other. This program is made up by programming novices, whom further lost control of there work with it,
caused by the complication they build into it, and the use of a wrong basic
foundation to build a programming language on. It's sad somebody senior folks here kept Prime alive by favoring it. If not, the sales were ceased long ago and
a new and better design would be here.

I don't think there's reason to post more examples to your. You may already be
familiar with diverse conversion Commands existing for converting point(a1,b2) to
complex (a1,b1) (as I noted last, most if not all, functions for geometry in the plan, does not separate between points and complexes) There are also some very
cumbersome conversion Commands with long ...long... names that are quite
unreasonable. The point itself one of them; why not just P(a1,b1). Others are:
rectangular_coordinates([r,arg]) to vector. abscissa and ordinate for taken out these for use in different conversion processes. William Wickes, the creator of
HP48 was a smarter guy using simpler commands like R->C and alike for other
conversion processes.

[HillyBoy]

You know what is really funny?
If you take a complex in the notation (a,b) and make it polar, you get the notation (abs<arg), which is very useful. Now if you try to edit this stack entry it shows up on the command line in that same notation, so far so good, still a happy user. Then when you press ENTER you get a syntax-error as the Prime only accepts polar complex objects in the notation (abs,<arg), so with a comma between "abs" and "<". Once this is corrected and ENTER pressed it shows on the stack as before without a comma, so as (abs<arg).

The other funny thing is when using Ans(N) it is possible to read stack entries, again very useful. The reverse is possible as well, so you can assign a value to Ans(1), Ans(2), Ans(3), etc. But instead of what you would expect, only Ans(1) is being modified. Nice inconsistent behaviour that is.

Now I am only working with the Prime for one week now and only been busy with these complex numbers, so I wonder how many other inconsistencies this marvel of ignorance contains.

While searching for answers I found this very interesting thread: https://h30434.www3.hp.com/t5/Tablets-an...-p/5046879

It dates back from 2014 and nothing seems to have happened with these great suggestions...

Nicolàs

[essen]

(03-16-2021 11:57 AM)HillyBoy Wrote:  You know what is really funny?
If you take a complex in the notation (a,b) and make it polar, you get the notation (abs<arg), which is very useful. Now if you try to edit this stack entry it shows up on the command line in that same notation, so far so good, still a happy user. Then when you press ENTER you get a syntax-error as the Prime only accepts polar complex objects in the notation (abs,<arg), so with a comma between "abs" and "<". Once this is corrected and ENTER pressed it shows on the stack as before without a comma, so as (abs<arg).

The other funny thing is when using Ans(N) it is possible to read stack entries, again very useful. The reverse is possible as well, so you can assign a value to Ans(1), Ans(2), Ans(3), etc. But instead of what you would expect, only Ans(1) is being modified. Nice inconsistent behaviour that is.

Now I am only working with the Prime for one week now and only been busy with these complex numbers, so I wonder how many other inconsistencies this marvel of ignorance contains.

While searching for answers I found this very interesting thread: https://h30434.www3.hp.com/t5/Tablets-an...-p/5046879

It dates back from 2014 and nothing seems to have happened with these great suggestions...

Nicolàs

Hi again,

Yeah it's funny and resentful. On mine, polar coordinates display as a vector. This display mode cops with what help informs. I have’ t observed the mode you see. Right now my software version are the latest 2.1.14425 (2020 01 16). This is the latest suitable for my older hardware version “C”. Maybe yours are the latest Prime G2 model. It uses another software, which is not compatible with my “C”. I had 4 older software on mine for trial. But turned lately back to latest - above.

It takes a huge amount of time taken in to considerations all these inconsistencies when programming. But there is no alternative to Prime. Its speed and memory are way more than any others. TI-Basic will not do anything serious programming. Perhaps Pyton can. I think I wood prefer php.

But Prime:
No flags to set, not even manually. So this st**** auto evaluation could be over come. It is almost impossible programmatically to store a new value in an already in memory existing variable, because it will evaluate when used in all command functions in a program. Unless one use this strange EXPR(“”+x1+”:=”+48) or this one EXPR(“”+48+”>”+x1). The sto(hello,b) can do it. But will not go with this
sto({42,48,50,}[i],{x1,y1,z1}[i]) in a FOR loop, not even will it go with
sto(42,{x1,y1,z1}[2]). Such operation are necessary to have in advanced programming. There are none working when variables already exists. Was a flag like in HP 48, that could be set programmatically to hinder evaluation, the problem could be solved that way. The only offering are to store the variable list in a name. – Who would accept blurring variables in a huge equation having them as an indexed list ?. – I am not going investigate if an equation even will accept like that. Should I Halt the program and go to the command line and store the new value.

Single quoting variables does’ t help as long as it automatically strips off
the quotes as soon as it interacts with a command. A Flag is necessary
to set and offset this auto stripping. Together with a RCL command (Recall).
This will keep compatibility with earlier made programs. As it is now:
And a RCL command must work with a STO command.

Having a list of existing variables {xl,yl,zl} it is impossible to store new values in a single variable in this list. Doing any operation on the list will evaluate list variables. – Any command will evaluate it, even including STRING({xl,yl,zl}) or “”+{xl,yl,zl}. Trying to store a new value, you get a s***** message.
“Purge the variable”.
You can’t purge an existing variable in a list of the form I show, when it
will evaluate and show a float number to the purge command. Even it is
quoted, it will show a float to the purge command.

The programmers who created this coding language does not know they
actually created an useless programming tool. . They should ask them self - “Why did the HP 48 - HP 50 use the single quote the right way of using it. And why have these calculators a Flag to set or offset this evaluation mode”.


I found 4 different names and integers for the same type using TYPE() and type() in HOME and CAS. These functions are absolute necessities in serious programming too. Same with use of IFERR. If running a program enclosed in #cas … #end, IFERR does not work when running in HOME. I say it again, such important build in functions must be functioning under all circumstances.

One cannot even test if a program are running in CAS or HOME. Under TYPE() Help talks about 14.? for types running in cas mode. This type doesn’t exist on my Prime. I presume, it not either existent on the newest – G2. No Flags, no Test options, except a partly invalid IFTE, which suffer same fault as IFERR Nothing; except sufficiently speed and memory.

Also programmatically running a key press are not available. This command is absolute necessary. Starting a program testing whether
the calculator are in HOME or in CAS mode, thereby running a keypress
for a change over, are not possible.

Also trouble with the hardware direction pad. When warming up from heat transfer from one thumb, it starts to wriggle to an unwanted direction. Who are those people who bully millions of people around the world. There’s something for the European Union in Bryssels to work with. It’s not Corona only that needs to come under treatment. But also imported scrap wares from eastern. That have destroyed western countries well known production of quality. It’ s not the people out there
to account for this, but our own people of unscrupulous importers of scrap wares from out there.

Unfortunately, the swissmicros coming WP 43 S are’ t capable enough running from a coin battery. Ramping up from about 20 MHz to 80 MHz when connected to a USB output. It has neither. But it undoubtedly are high quality made – no doubt. HP are not trust worthy anymore.

If you build your programs with it, then you can count on, that they won’ t run on next upgrade. There will be many upgrades. Because, nobody can correct such a messy programming tool.

But you know it as well. No doubt.

It is almost all gone to pot.

Essen

[Gene]

After a number of complaints, this thread is closed.

Gene