1. Nat_sort problems
- Posted by Tony Steward <tsteward at dodo.com.au> Aug 09, 2003
- 453 views
Hello all, When I use nat_sort on the following sequence My program crashes with this error C:\EUPHORIA\ExInclude\\\\nat_sort.e:171 in function nat_compare() type_check failure, x2num is 1234567890 I use nat_sort like this: order = nat_sort(order) Below is the actual data order contains. order = { {49'1',48'0',52'4',47'/',82'R',73'I',78'N',71'G'}, {49'1',50'2',51'3',52'4',53'5',54'6',55'7',56'8',57'9',48'0',49'1',50'2',51'3',52'4',53'5'}, {49'1',53'5',48'0',47'/',82'R',73'I',78'N',71'G'}, {51'3',56'8',54'6',32' ',80'P',82'R',73'I',77'M',85'U',83'S'}, {53'5',49'1',50'2'}, {53'5',49'1',50'2',32' ',67'C',79'O',78'N',84'T',82'R',79'O',76'L'}, {65'A',65'A',65'A',49'1',48'0',47'/',50'2',49'1',49'1'}, {65'A',65'A',65'A',50'2',51'3'}, {65'A',65'A',65'A',57'9'}, {65'A',66'B',65'A'}, {65'A',66'B',65'A',49'1',48'0'}, {65'A',66'B',65'A',49'1',50'2'}, {65'A',66'B',65'A',49'1',54'6'}, {65'A',66'B',65'A',50'2',49'1'}, {65'A',66'B',65'A',50'2',51'3'}, {65'A',66'B',65'A',50'2',55'7'}, {65'A',66'B',65'A',54'6'}, {65'A',66'B',65'A',56'8'}, {65'A',66'B',66'B'}, {65'A',66'B',66'B',49'1'}, {65'A',66'B',66'B',49'1',48'0'}, {65'A',66'B',66'B',49'1',50'2'}, {65'A',66'B',66'B',51'3'}, {65'A',66'B',66'B',53'5'}, {65'A',66'B',66'B',55'7'}, {65'A',66'B',66'B',56'8'}, {66'B'}, {66'B',67'C',66'B',52'4',52'4',47'/',50'2',49'1',50'2'}, {66'B',67'C',68'D',47'/',50'2',49'1',53'5'}, {67'C',66'B'}, {67'C',66'B',71'G',77'M'}, {67'C',68'D',65'A',47'/',50'2',49'1',49'1'}, {68'D',83'S',77'M'}, {70'F',52'4',55'7',50'2'}, {70'F',79'O',66'B'}, {71'G'}, {71'G',77'M'}, {76'L',83'S'}, {79'O',77'M',32' ',85'U',83'S',69'E',82'R',32' ',35'#'}, {79'O',85'U',84'T'}, {80'P',46'.',32' ',70'F',73'I',76'L',69'E'}, {80'P',82'R',79'O',88'X',32' ',67'C',65'A',82'R',68'D',32' '}, {82'R',69'E',67'C',50'2',50'2',56'8'}, {83'S',75'K',68'D',49'1',47'/',50'2',49'1',53'5'}, {83'S',75'K',68'D',50'2'}, {83'S',75'K',68'D',51'3'}, {83'S',75'K',68'D',67'C'}, {83'S',75'K',68'D',74'J',72'H'}, {85'U',49'1'} }
2. Re: Nat_sort problems
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 11, 2003
- 441 views
Tony, changing x2num, x1num to integers doesn't work either because atoms can't hold very large numbers either. Another technique will be required for this problem. There are big-number libraries available so you might have to use these but I suspect a different approach to the natural sort algorithm might be be faster. Just not sure yet. -- Derek
3. Re: Nat_sort problems
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 11, 2003
- 430 views
On Sun, 10 Aug 2003 22:25:34 +0000 (08/11/03 08:25:34) , Andy Serpa <ac at onehorseshy.com> wrote: > > > Tony Steward wrote: >> >> >> Hello all, >> When I use nat_sort on the following sequence My program crashes with >> this error >> >> C:\EUPHORIA\ExInclude\\\\nat_sort.e:171 in function nat_compare() >> type_check failure, x2num is 1234567890 >> > > The number simply got too big -- outside integer range. I never > considered that. Just change the declarations for "x1num" & "x2num" to > atom (from integer) in nat_compare() and it should take care of it. > Change them also in nat_compare_str(). > I was thinking that rather than converting them to numbers, you just need toi 'justify' the strings and do a string compare. So if you 'converted' a string that looks like its a number, make it look something like ... "Z0000000000000123456789012345.00000000000000" where the decimal point is always in a fixed place (eg. 30 digits to the left and 15 digits to the right, or whatever you think is fair) and do a string compare. Note the first element is a 'Z' for +ve numbers and a 'A' for -ve numbers. This ensures that negative numbers all sort before positive ones. -- cheers, Derek Parnell
4. Re: Nat_sort problems
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Aug 11, 2003
- 431 views
On Sat, 9 Aug 2003 12:09:03 +0000, Tony Steward <tsteward at dodo.com.au> wrote: >Hello all, >When I use nat_sort on the following sequence My program crashes with=20 >this error > >C:\EUPHORIA\ExInclude\\\\nat_sort.e:171 in function nat_compare()=20 >type_check failure, x2num is 1234567890=20 >Below is the actual data order contains. > >order =3D {"104/RING", > "123456789012345", ^ there lies the root. Change the definition of x1num and x2num to atom, it works fine. That's just a quick fix, though: If/when Andy Serpa answers, pay attention & trust him, not me! HTH, Pete
5. Re: Nat_sort problems
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 11, 2003
- 427 views
On Mon, 11 Aug 2003 02:07:43 +0100 (08/11/03 11:07:43) , Pete Lomax <petelomax at blueyonder.co.uk> wrote: > > > On Sat, 9 Aug 2003 12:09:03 +0000, Tony Steward > <tsteward at dodo.com.au> wrote: > >> Hello all, >> When I use nat_sort on the following sequence My program crashes with >> this error >> >> C:\EUPHORIA\ExInclude\\\\nat_sort.e:171 in function nat_compare() >> type_check failure, x2num is 1234567890 Below is the actual data order >> contains. >> >> order = {"104/RING", >> "123456789012345", > ^ there lies the root. > Change the definition of x1num and x2num to atom, it works fine. > That's just a quick fix, though: Changing it to an atom doesn't always work. Sure it no longer crashes, but it doesn't aways sort correctly either. For example, "123456789012345" and "123456789012399" sort to the same location. -- cheers, Derek Parnell
6. Re: Nat_sort problems
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 11, 2003
- 431 views
----- Original Message ----- From: "Andy Serpa" <ac at onehorseshy.com> To: "EUforum" <EUforum at topica.com> Subject: RE: Nat_sort problems > > > Derek Parnell wrote: [snip] > > > > Changing it to an atom doesn't always work. Sure it no longer crashes, > > but > > it doesn't aways sort correctly either. > > > > For example, "123456789012345" and "123456789012399" sort to the same > > location. > > > > They do? Works fine with my system. > You are correct Andy. I made a mistake when I did a quick test. I displayed the results incorrectly without looking at it very closely. Sorry about that. -- Derek
7. Re: Nat_sort problems
- Posted by Robert Craig <rds at RapidEuphoria.com> Aug 11, 2003
- 442 views
Andy Serpa wrote: > While we are talking about nat_sort, I offer the following very slight > optimization: > > Declare a constant at the top of the file: > > constant WHITESPACE = "\t\n\r" > > and then replace the two instances of "\t\n\r" in nat_compare() with > WHITESPACE. I believe Rob once mentioned the fact the such inline use > of sequences is not free -- they have to be recreated each time ... That doesn't apply to strings "...", just more general sequences that you construct with {....} String sequences are created only once, when the program is parsed (loaded into memory). After that, a pointer refers to the sequence. Of course from a readability/maintainability point of view using a named constant is better than repeating the same value in many places. You might also save memory and improve the hit rate of the data cache, but now we're getting into really trivial issues. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
8. Re: Nat_sort problems
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Aug 11, 2003
- 431 views
On Mon, 11 Aug 2003 15:47:57 +0000, Andy Serpa <ac at onehorseshy.com> wrote: >Aha... is is actually the string designation (use of quotes) that makes=20 >the difference, or just any "byte-sized" sequence of integers? When you= =20 >first mentioned it, it was to do with peek(), using {addr,len} where=20 >you've got a 32-bit address and an integer together... > I was just trying it Andy, strings are about the same, the following shows about 75% more iterations per second using the constant: constant x=3D{'\t','\n','\r'} integer a,b atom t t=3Dtime()+1 a=3D0 while t>time() do if find(1,{'\t','\n','\r'}) then end if a+=3D1 end while t=3Dtime()+1 b=3D0 while t>time() do if find(1,x) then end if b+=3D1 end while printf(1,"inline:%d constant:%d ration %g",{a,b,b/a}) if getc(0) then end if Thanks, it's always handy to know that kind of stuff Pete PS I suspect if Rob tried to optimise such cases it would make the average program slower.
9. Re: Nat_sort problems
- Posted by Robert Craig <rds at RapidEuphoria.com> Aug 11, 2003
- 429 views
Andy Serpa wrote: > Aha... is is actually the string designation (use of quotes) that makes > the difference, or just any "byte-sized" sequence of integers? When you > first mentioned it, it was to do with peek(), using {addr,len} where > you've got a 32-bit address and an integer together... At the moment, I save a single copy of each string sequence "..." at parse time, but I never save a copy of {...} expressions - they are recreated each time. Pete Lomax was right. I could do the same for {...} expressions where each element is a constant value, but I don't. I may do it in the future. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
10. Re: Nat_sort problems
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 11, 2003
- 441 views
----- Original Message -----=20 From: "Tony Steward" <tsteward at dodo.com.au> To: "EUforum" <EUforum at topica.com> Subject: Nat_sort problems >=20 >=20 > Hello all, > When I use nat_sort on the following sequence My program crashes with=20 > this error >=20 > C:\EUPHORIA\ExInclude\\\\nat_sort.e:171 in function nat_compare()=20 > type_check failure, x2num is 1234567890=20 >=20 >=20 > I use nat_sort like this: order =3D nat_sort(order) >=20 > Below is the actual data order contains. >=20 > order =3D { > {49'1',48'0',52'4',47'/',82'R',73'I',78'N',71'G'}, > =20 > = {49'1',50'2',51'3',52'4',53'5',54'6',55'7',56'8',57'9',48'0',49'1',50'2',= 51'3',52'4',53'5'}, Tony, the problem is that the nat_sort routine defines x2num as an integer and = integers can only hold numbers up to 1073741824, but the second element = in your sample is 123456789012345, which is too big. Try changing the = nat_sort routine so that the x1num and x2num are atoms instead of = integers. --=20 Derek
11. Re: Nat_sort problems
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 11, 2003
- 435 views
This message of mine below took over 24-hours to show up on the list, behind subsequent messages I'd also sent! ----- Original Message ----- From: "Derek Parnell" <ddparnell at bigpond.com> To: "EUforum" <EUforum at topica.com> Subject: Re: Nat_sort problems > > > ----- Original Message ----- > From: "Tony Steward" <tsteward at dodo.com.au> > To: "EUforum" <EUforum at topica.com> > Sent: Saturday, August 09, 2003 10:09 PM > Subject: Nat_sort problems > > > > Hello all, > > When I use nat_sort on the following sequence My program crashes with > > this error > > > > C:\EUPHORIA\ExInclude\\\\nat_sort.e:171 in function nat_compare() > > type_check failure, x2num is 1234567890 > > > > > > I use nat_sort like this: order = nat_sort(order) > > > > Below is the actual data order contains. > > > > order = { > > {49'1',48'0',52'4',47'/',82'R',73'I',78'N',71'G'}, > > > > > > {49'1',50'2',51'3',52'4',53'5',54'6',55'7',56'8',57'9',48'0',49'1',50'2',51'3',52'4',53'5'}, > > Tony, > the problem is that the nat_sort routine defines x2num as an integer and > integers can only hold numbers up to 1073741824, but the second element in your > sample is 123456789012345, which is too big. Try changing the nat_sort routine so > that the x1num and x2num are atoms instead of integers. > > -- > Derek > > --^---------------------------------------------------------------- > This email was sent to: ddparnell at bigpond.com > > > TOPICA - Start your own email discussion group. FREE! > >