Are their any restrictions using copycode?

, ,
1

Are their any known limitations in relation to copycode.

I have implemented a quicksort algorithm using copycode. The idea is that any data type can be used, since the type of data array elements are determined at compile time. This doesn’t seem to work for some reason.

If you look at the following excerpt

0190 #qs.n := *ubound(&1&)
0200 for #qs.j 1 #qs.n
0210 #qs.l := (#qs.n / 2) + 1
0220 #qs.ir := #qs.n
0230 repeat
0240 if #qs.l > 1
0250 #tempidx1 := #qs.l
0260 #qs.indxt := &2&(#tempidx1)
0270 #tempidx1 := #qs.indxt
0280 &3& := &1&(#tempidx1)
0290 subtract 1 from #qs.l

First I have used #tempidx1, since the compiler seems to have problems with a construction like &2&(#qs.l), so I replaced #qs.l with a temporary variable. That seems to solve this problem. But when I run the test program, #tempidx1 is 0 while #qs.l is 4, even after the assignment.

Personally I have no clue what’s going on. That’s why I would like to know if their are any restrictions in relation to arrays.

Rudolf

2

First, a note. Probably 20 years ago I did a timing comparison of Natural’s internal sort versus a double bubble sort (bi directional bubble sort) I had written. Natural won by a factor of ten. Have not run such a timing comparison in a long while, but I would be willing to be Natural still wins, by a large margin.

Are you saying that if you insert a WRITE #tempidx1 #qs.l between lines 0250 and 0260 they are different? If so, what are their formats? Also, formats of other variables in the code.

steve

3

There are some limitations, like

But the reason for your &2&(#qs.l)-Problem is another one. Try this:

define data local
1 #a10 (A10/1:10)
1 #qs
  2 l  (N1) init <1>
end-define
write #a10(l)      /* works
write #a10(#qs.l)  /* doesn't work
end

:shock: Could you post a compilable example of your code?

4

I believe you have identified a bug Matthias.

Whereas #a10 (l) works for your example, suppose I had:

define data local
1 #a10 (A10/1:10)
1 #qs
2 L (N1) init <1>
1 #qq
2 L (N1) init <3>
end-define
write #a10(L) /* works
write #a10(#qs.L) /* doesn’t work
end

Now #a10 (L) produces an error message that the L is not adequately qualified.

Worse, there does not appear to be a way to reference this properly except for the somewhat clumsy code:

move #qs.L to #sub /* where #sub might be I2 or N1
write #a10 (#sub)

steve

5

Really? I know this index-behaviour for many years…

The following program doesn’t throw an error on Open Systems.

define data local
1 #a10 (A10/1:10) init <'A','B','C'>
1 #qs
2 L    (N1) init <1>
1 #qq
2 L    (N1) init <3>
end-define
write #a10(L)
end

Output on Natural 6.1.1 for Windows:

C

… Ok, that’s a real bug. :shock:

6

Hi Mathias

I am on 6.3.7 and your program above does produce:

NAT0434 Qualification does not uniquely identify variable.

steve

7

Thank you. So my company should consider an update.

I remember there was a (maybe) related problem regarding variable referencing some years ago…

8

Here it is: http://tech.forums.softwareag.com/viewtopic.php?t=14136

9

Natural 6.2 thows a NAT0434, too.

BTW: What about Rudolf’s initial problem? Maybe we are a bit off topic at the moment …

10

Now we are on NAT 6.3.9@Solaris.

define data local
1 #a10 (A10/1:10)
1 #qs
2 L (N1) init <1>
1 #qq
2 L (N1) init <3>
end-define
write #a10(L)     /* NAT0434 --> OK
write #a10(#qs.L) /* NAT0281 --> not OK
end

After thinking twice about that problem:
I think write #a10(#qs.L) should be a valid code… Seems like I have to open a empower service call.

11

SAG says, only simple variables can be used.

See http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat639unx/pg/pg_defi_dv.htm#Index_Notation