1. 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'},
{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'}
}
3. Re: Nat_sort problems
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
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
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
7. Re: Nat_sort problems
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
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
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
----- 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
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!
>
>
