(48/49/50) LSORT v0.6b

[Werner]

[Edit:] Changed to LSORT v0.6b

LSORT behaves exactly like the built-in SORT, except that it doesn't accept units,
and it is many times faster.

Some things you may not realise SORT, and LSORT, do:
- no error for an empty list (contrary to DOLIST, for instance)
- no type checking for a list of 1 element
-> e.g. you can sort { \<< \>> }
- Tagged objects will be sorted according to value, not tags, of course
-> { A:3 1 B2:C3:2 } (L)SORT -> { 1 B2:C3:2 A:3 }
- Included objects vs. ROM objects
{ 3. 1. 2. } is 12.5 bytes, while { 3.3 1.1 2.2 } is 36.5 bytes. That is because 1., 2. and 3. reside in ROM, and the list entries merely point at those rather than including them. So any self-respecting SORT routine must be able to handle both included objects and referenced ones. In SysRPL that makes no difference, but in ASM it surely does.
- List of lists
When the elements of a list are themselves lists, (L)SORT will sort them by the first object of each list element.
{ {3} {1 [1]} {2 "A"} } -> { {1 [1]} {2 "A"} {3} }
You may even have a list of lists of lists etc...
- stable sort: elements having the same value will be kept in the same order (this will only be apparent for lists of lists)
{{2 "A"}{3}{2 "B"}{1}} -> {{1}{2 "A"}{2 "B"}{3}}

This version corrects a few bugs that were present in v0.4, and adds support for binary integers, respecting wordsize.

The zip file in annex contains compiled versions for the 48 and 49/50.
(The 50 file should work in all versions of the 49 and 50)

Cheers, Werner

[pier4r]

great that after years you still update your contributions (and LSORT) is pretty neat!

Just the zip file is missing.

Side note: while I love the idea of having a single repository (hpcalc), uploading the file here and there is not bad. As wrote in many other threads, redundancy on internet is never bad.

[Eric Rechlin]

All contributions to my site should be done through https://www.hpcalc.org/contribute.php.

That said, almost nobody contributes anything anymore. I average about one contribution a week. Everything else comes from me scouring the Internet, including this forum (and sadly this forum does not encourage a user-friendly experience for finding and downloading software, so the fact that so many people only post things here is far from ideal).

[Werner]

Managed to include the file this time ;-)
I uploaded it to hpcalc.org as well, thanks Eric!

Cheers, Werner

[Gerald H]

Sorting hexadecimal strings works on 49G, Version 1.19-6 & 2.10-7 but not on 50g, Version 2.10-7.

[Werner]

Dang. That means the (getwordsize) is in a different location again on the 50G.
Sigh. I'll try and sort it out, no pun intended.
Thanks, Werner

[Eric Rechlin]

If both the 49G and 50g are running the same 2.10-7 ROM, I wouldn't think it would make a difference, so this surprises me. But I'll hold off updating my site until there is confirmation.

[Werner]

Mh my 49G is certainly not running the latest ROM.
I updated the zip file in the previous post, it now has a .50.HP file as well. The hex numbers work as far as I've been able to tell.
I'll add a note later to explain that the 50 version will work for ROM 2.10-7, while the 49 version will be for ROM (I think) 1.19-6.

Cheers, Werner

[pier4r]

(01-25-2018 10:26 PM)Eric Rechlin Wrote:  All contributions to my site should be done through https://www.hpcalc.org/contribute.php.

That said, almost nobody contributes anything anymore. I average about one contribution a week. Everything else comes from me scouring the Internet, including this forum (and sadly this forum does not encourage a user-friendly experience for finding and downloading software, so the fact that so many people only post things here is far from ideal).

While I agree that finding particular contributions scattered on a forum is not easy, I still find it better to have them twice, thrice, etc.. on different sites rather than once.

On the other side it is sad that people don't commit content to your awesome site anymore and it is amazing that after so many years you still go hunting for programs.

[Eric Rechlin]

(01-26-2018 08:11 PM)pier4r Wrote:  While I agree that finding particular contributions scattered on a forum is not easy, I still find it better to have them twice, thrice, etc.. on different sites rather than once.

I agree. More redundancy is better. That's why it would also be nice to be able to download a raw dump of all the messages posted to this forum so if this site ever goes down, the discussions can live on, much like the torrent I distribute with 230k messages archiving all discussions from comp.sys.hp48. Far too often web forums die and then all the valuable content is lost, unless by chance they all got archived in archive.org (and even then it's often not ideal to browse or search).

(01-26-2018 08:11 PM)pier4r Wrote:  On the other side it is sad that people don't commit content to your awesome site anymore and it is amazing that after so many years you still go hunting for programs.

Yes, and it's a lot of work to prepare a complete package for each program to download, too.

[Gerald H]

New 50 version works on 50g with 2.10-7 & on 49G with 2.10-7 but not with 1.19-6.

50 version has

CkSum 8165h
Size 1061.5

49 version

CkSum FEF1h
Size 1069.5

Does that tally with your values?

[Werner]

No, that 49 version is wrong, should also be 1061.5 bytes, # 70BEh and that
surely should run on 1.19-6.

Anyway this is not how it's supposed to work.
I have a new version with just a tiny change to solve this unsupported entry business.
There will be two binaries, one for the 48 and one for the 49/50, and just one source.
I will however have to create and test them on all three platforms.. (48,49,50).
That will take awhile, as it's been a long time and I don't have EMU48 set up any more (just m48+ on my phone. I can already confirm that it works for the 48 ;-).
Stay tuned for v0.6b..
Werner

[pier4r]

(01-26-2018 10:21 PM)Eric Rechlin Wrote:  I agree. More redundancy is better. That's why it would also be nice to be able to download a raw dump of all the messages posted to this forum so if this site ever goes down, the discussions can live on, much like the torrent I distribute with 230k messages archiving all discussions from comp.sys.hp48. Far too often web forums die and then all the valuable content is lost, unless by chance they all got archived in archive.org (and even then it's often not ideal to browse or search).

On this I strongly agree. Let's ask in the admin section.

edit: also werner, great commitment to fix the problem!

[John Keith]

Thanks also from me, Werner. An absolutely essential program for the HP50 IMHO.

One small issue compared to the built-in SORT command- LSORT cannot sort lists of mixed real numbers and exact integers, which the built-in command can. Not a big deal, but I wanted to note it since it is a difference.

John

[Werner]

Thanks John - I wasn't aware of that. After all these years, I still discover new things.
I'll add it to the 'unresolvable differences', since there's no way I can incorporate that as it is.
For me to solve this (and integrate units as well, which pose a similar problem), the program has to be 100% rewritten, will be a lot larger, use more memory, and be somewhat slower.

Cheers, Werner

[Gerald H]

As for me type mixing is not a desired feature.

I take this opportunity to praise your work, I've used LSORT for years & am very grateful for your efforts.

[Werner]

Okay finally got round to uploading v0.6b (see first post in this thread). Hope I got it right this time ;-)
Cheers, Werner

[DavidM]

LSORT is definitely a must-have for anyone working with lists on RPL systems.

Thanks for continuing to improve LSORT, Werner!

[Gerald H]

Works on 50g (2.10-7) & 49G (1.19-6 & 2.10-7), cksum & size as in your documentation.

Bravo!

[John Keith]

(02-02-2018 08:01 AM)Werner Wrote:  Thanks John - I wasn't aware of that. After all these years, I still discover new things.
I'll add it to the 'unresolvable differences', since there's no way I can incorporate that as it is.
For me to solve this (and integrate units as well, which pose a similar problem), the program has to be 100% rewritten, will be a lot larger, use more memory, and be somewhat slower.

Cheers, Werner

Don't worry, I'm not complaining- one can use I\->R or R\->I first and LSORT is still zillions of times faster than the built-in SORT. Thanks again for all your efforts.

John