No announcement yet.

Constant arrays, operations with arrays

  • Filter
  • Time
  • Show
Clear All
new posts

  • Constant arrays, operations with arrays


    I'd like to design a GUI that includes a few equally spaced polygons. The first of them is defined like this:

    var vx[5], vy[5];

    vx[0] := 97; vx[1] := 175; vx[2] := 175; vx[3] := 97; vx[4] := 109;
    vy[0] := 183; vy[1] := 183; vy[2] := 209; vy[3] := 209; vy[4] := 197;
    gfx_PolygonFilled(5, vx, vy, BLUE);

    The next has all y-coordinates lesser by 30, still next - by 60, and so on.

    When written this way, the code occupies too much space, so I would like:

    1. To define a "seed" polygon as a whole, not element-wise:

    Xpoly1[] := [97, 163, 175, 163, 97];
    Ypoly1[] := [63, 63, 77, 89, 89];



    2. To assign these arrays to suitable variables:
    var x[] = Xpoly1;
    var y[] = Ypoly1 ;

    3. Add a constant offset to all y-coordinates simultaneously:

    y[] := y[] - 30;

    Unfortunately, the compiler does not allow me neither to define a constant array, nor to subtract a constant from an existing variable array.

    Is there a compact syntax to do that?

  • #2
    To subtract a constant from an exiting array, simply use a for statement.

    Not sure why you say 'occupies too much space', in terms of code space it will be the same even if there were 'helpers'. The 'helpers' would generate the same code (ideally, in reality it would probably generate more).



    • #3
      Hi Mark,

      thank you for your reply,

      What do you mean by "simply use a for statement"? a "what"?

      And what about definitions? Can I define a constant array (or, which is the same, an array of constants)?

      When I said "too much space", I meant too much space on the screen. That's why I mentioned "syntax".
      Of course, I don't expect the required memory to be less when the syntax looks simpler.


      • #4
        Well... I see. You meant a "for" statement? I wouldn't all it easy in terms of syntax :-)


        • #5
          A constant array is defined using a #DATA statement.



          • #6
            Thank you very much.


            • #7
              Mark, please help. I'm using this code:

              word Xpoly 97, 175, 175, 97, 109
              word Ypoly 183, 133, 209, 209, 197

              var vx[5] := Xpoly, vy[5] := Ypoly;

              The compiler doesn't like the way I use to assign the defined constants to variables. What's wrong?


              • #8
                The compiler is very straight forward, perhaps a bit like Pure C, and many other languages

                vx[5] := Xpoly

                Says put the address of Xpoly in vx[5].

                You need something like
                for (i:=0;i<5;i++)
                vx[i] := Xpoly[i] ;


                • #9
                  Mark, I was talking about syntax. Believe me, I wouldn't bother you with algorithmic questions, just because I don't like my work being done at someone else's expense.

                  But I thought it was the compiler's task to convert expressions like "array3 := array1 + array2" into a "for" cycle behind the scene.
                  If this is not the case, then arrays aren't actually a variables in the mathematical sense (1-D arrays of the same size form a group with respect to addition).

                  Now, I have encountered another strange behavior. The code

                  var vx[5] := [97, 175, 175, 97, 109];
                  var vy[5] := [183, 183, 209, 209, 197];
                  gfx_PolygonFilled(5, vx, vy, WHITE);

                  gives the desired result. But when I then re-assign a new array to vy:
                  vy[5] := [153, 153, 179, 179, 167];

                  I don't see the second polygon 30 pixels above the first. Can you comment on this?


                  • #10
                    The first form defines a variable and assigns initial values to it.

                    The assignment you have specified puts the address of the array in vy[5],I think, regardless it will not do what you hope it will.


                    • #11
                      You are right. Nevertheless, we have a strange situation:

                      var vx[] := [ 3, 3, 17, 29, 29]; -- works
                      vx[] := [ 3, 3, 17, 29, 29]; -- doesn't work.

                      In other words, a variable cannot be re-defined using the same syntax it has been defined with. Strange and disappointing.

                      I have also found this in 4DGL-Programmers-Reference-Manual-rev4.pdf:

                      Section 6.2

                      a := &myArray[0];
                      a := myArray; // same as above. The array name without indices

                      The reference is saying that the difference between the two expressions is the absence of the index (which normally means index 0).
                      Actually, the difference is the absence of the "&", and you have two different syntaxes for the same thing.
                      On the other hand, you have the same syntax for two different things, which is much worse:

                      a : = b; assigns a value of b to a - if b is a number
                      and the same statement assigns the address of b to a - if b is an array.

                      Sections 6.1 and 6.2 are clearly in contradiction with each other.


                      • #12
                        One is an initialized variable, the other is an assignment statement, they are completely different.

                        6.2 is 'address modifiers', 6.1 is 'assignments' I don't see any contradiction.

                        If you are referring to the use of the array name as a 'shortcut' to taking the address of array variable 0, then this is another example of something that was taken straight from C.

                        If you want to take apart the parts of 4DGL 'borrowed' from C, then be my guest as I am not a fan of C either, but this isn't the place for it, try a C forum.

                        C is the most popular language there is, by far, once it's descendants are included, it has lots of quirks that I find odd, but what's done is done, you can't change C once a language is documented, its existing code ensures that there can be no significant syntax changes. Same for 4DGL.


                        • #13
                          Sorry, "contradiction" is not the most suitable word here. It's better to say that sections 6.1 and 6.2 are inconsistent with each other. Moreover, the "&" sub-section of 6.2 is inconsistent with itself -- because it offers a syntax that does not start with "&". It's like using a "+" to mean addition or multiplication depending on your data type.

                          Once again, we have the situation when the same expression, a := b, assigns either value or address, depending on whether the data is structured or not.
                          I believe this is not sort of things allowable in a programming language.

                          Also, I suggest to include in the programmer's manual a section titled "data structures". A very short one, actually. It should state just two things:
                          1. The only type of supported data structures are 1-D numerical arrays.
                          2. Operations with arrays as a whole (such as array3 := array2 + array1, and re-assigning a new value as well) are not supported.

                          Simple as that.

                          The second line is necessary because another section says:

                          "Variables can also be an array such as..."

                          This gives the reader a misleading impression that all variables are alike (at least, can be re-assigned in the same way they have been defined).

                          And - last but not least: the manual is full of grammar mistakes and other inaccuracies. For instance, the sentence just quoted should read:

                          "Variables can also be arrays, such as:" or "A variable can also be an array, such as:"

                          Also, in another document describing SIN and COS functions it is stated that the result of these operations is in radians, while it s clearly dimensionless.

                          I suspect, though, that boring things like grammar and logic are unimportant for most of the people :-)
                          But I strongly believe that writing logically and grammatically flawless documents advertises your products as nothing else does.

                          Thank you again for your answers.