+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Software Libraries (/forum-10.html)
+--- Forum: General Software Library (/forum-13.html)
+--- Thread: (48/49/50) LSORT v0.6b (/thread-10018.html)
(48/49/50) LSORT v0.6b - Werner - 01-25-2018 09:19 PM
[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
RE: (48/49/50) LSORT v0.6a - pier4r - 01-25-2018 09:32 PM
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.
RE: (48/49/50) LSORT v0.6a - Eric Rechlin - 01-25-2018 10:26 PM
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).
RE: (48/49/50) LSORT v0.6a - Werner - 01-26-2018 06:34 AM
Managed to include the file this time ;-)
I uploaded it to hpcalc.org as well, thanks Eric!
Cheers, Werner
RE: (48/49/50) LSORT v0.6a - Gerald H - 01-26-2018 03:22 PM
Sorting hexadecimal strings works on 49G, Version 1.19-6 & 2.10-7 but not on 50g, Version 2.10-7.
RE: (48/49/50) LSORT v0.6a - Werner - 01-26-2018 04:09 PM
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
RE: (48/49/50) LSORT v0.6a - Eric Rechlin - 01-26-2018 04:17 PM
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.
RE: (48/49/50) LSORT v0.6a - Werner - 01-26-2018 04:35 PM
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
RE: (48/49/50) LSORT v0.6a - pier4r - 01-26-2018 08:11 PM
(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.
RE: (48/49/50) LSORT v0.6a - Eric Rechlin - 01-26-2018 10:21 PM
(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.
RE: (48/49/50) LSORT v0.6a - Gerald H - 01-27-2018 06:44 AM
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?
RE: (48/49/50) LSORT v0.6a - Werner - 01-27-2018 10:09 AM
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
RE: (48/49/50) LSORT v0.6a - pier4r - 01-27-2018 01:12 PM
(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!
RE: (48/49/50) LSORT v0.6a - John Keith - 02-01-2018 08:23 PM
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
RE: (48/49/50) LSORT v0.6a - Werner - 02-02-2018 08:01 AM
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
RE: (48/49/50) LSORT v0.6a - Gerald H - 02-02-2018 08:28 AM
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.
RE: (48/49/50) LSORT v0.6b - Werner - 02-16-2018 02:52 PM
Okay finally got round to uploading v0.6b (see first post in this thread). Hope I got it right this time ;-)
Cheers, Werner
RE: (48/49/50) LSORT v0.6b - DavidM - 02-16-2018 03:42 PM
LSORT is definitely a must-have for anyone working with lists on RPL systems.
Thanks for continuing to improve LSORT, Werner!
RE: (48/49/50) LSORT v0.6b - Gerald H - 02-16-2018 04:56 PM
Works on 50g (2.10-7) & 49G (1.19-6 & 2.10-7), cksum & size as in your documentation.
Bravo!
RE: (48/49/50) LSORT v0.6b - John Keith - 02-16-2018 08:29 PM
(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