userRPL / hp 50g, creating grobs from list using the "text" view.

[pier4r]

As someone may have noticed, I have a hp 50g.

Due to past experiences I got to know a program to break down a large number on multiple lines. Lnviewer. It works very neatly.

With the recent programming puzzle about regular numbers I wanted to test if it was possible to create a picture out of a very long list. Amazingly, the 50g is able to do that. I converted the list of 300 numbers, that has a width of 11k and counting pixels .

The problem is that the list is visualized horizontally, and not like the text mode that the calculator offers. The text mode breaks down the list vertically and it is way more compact.

Is there a way to create a GROB like in text mode, without converting first the list in a string and then break it down? I did not find it in the 50g AUR, nor in a search on this forum ( search string site:hpmuseum.org grob long list text view , although it has returned a nice thread that I linked here.)

Many thanks

[Han]

Consider converting the list into an array with the appropriate number of columns and then creating the grob of the matrix.

[pier4r]

Ok, I really hoped to make use of the text view. I just tested and even creating a string, manually split over 3 lines, when transformed in a GROB becomes a long string. Dunno why.

[Claudio L.]

Don't know if it works on the 50g, but AGROB from Java had pretty print for matrices and lists if I remember correctly.

http://www.hpcalc.org/details/202

Perhaps it works on the 50g, might be worth a shot.

[DavidM]

(04-17-2017 04:44 PM)pier4r Wrote:  Ok, I really hoped to make use of the text view. I just tested and even creating a string, manually split over 3 lines, when transformed in a GROB becomes a long string. Dunno why.

If you set system flag 70 (-70 SF), ->GROB will respect carriage returns in the source text when creating the resulting grob.

I know that your focus is on UserRPL here, but I just thought I'd mention that this is an area which is much easier to deal with using SysRPL. There are commands available in that environment which allow direct access to built-in functions for wrapping strings at a given column and converting strings to grobs without needing to set flag -70.

[pier4r]

@DavidM: awesome knowledge!

http://i.imgur.com/tJhHsM8.png (lists have the 'return sign' already)

Thanks!

I wonder if the advice was in the user manual but I missed it.

@DavidM #2: what do you mean with sysRPL ? I mean, since the text mode is "there" in the calculator, I thought a solution was readily available. (as it seems, thanks to flag -70)

@ Claudio: thanks for the hint!

[DavidM]

(04-18-2017 08:06 AM)pier4r Wrote:  I wonder if the advice was in the user manual but I missed it.

To be honest I don't remember where (or even if) this is documented. Don't feel bad about not seeing it.

(04-18-2017 08:06 AM)pier4r Wrote:  what do you mean with sysRPL ? I mean, since the text mode is "there" in the calculator, I thought a solution was readily available. (as it seems, thanks to flag -70)

I was mainly referring to the specific case of converting a list to a "wrapped" GROB. The functions exist to do this in userRPL, but the code to do it in sysRPL is fairly straightforward and compact because of the existence of a couple of commands which are not available in userRPL:

Code:

::
   CK2NOLASTWD             ( must have 2 arguments on stack )

   CK&DISPATCH1            ( will convert zints to reals if needed )
   LISTREAL ::             ( SL2: LIST, SL1: REAL )
      COERCE               ( convert real to system binary integer )
      !DcompWidth          ( set column wrap breakpoint )
      FLASHPTR FSTR4       ( convert list to string, insert CRs as appropriate )
      $>GROBCR             ( convert string to GROB, respect CRs )
   ;
;

The above 7-step sysRPL program takes a list in stack level 2, and a number in stack level 1 that represents the targeted "wrap" column. The result is the GROB representing that list in column-wrapped form using the "large" font. It even validates that the arguments are present and of the proper type, raising an error if not.

I'm not trying to suggest that you can't do similar things with userRPL, but merely that this particular function was a good example of when sysRPL can be very useful.