Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Author
Message
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 22nd Jan 2011 12:24
Then you provide a command for that purpose.

@Everyone else,
The BYREF terminology was simply the first thing that came out of my head - whatever the words are doesn't matter at this point. It's the reference idea that I wanted to get across.

@Diggsey,
Yes, a tree works the same as the array/array-reference form would, with one difference: with UDT's and arrays, you aren't limited to binary trees.

For instance:
1-cell array = singly linked-lists
2-cell array = doubly linked-lists, binary trees
n-cell array = n-ary trees (such as quadtree, octree), skiplists, graphs, B-trees
array of n-cell array = hash map with buckets, jagged arrays

@dark coder,
But no-one actually redefines arrays to different dimensions, and when they access them then access them either using the dimensions they've defined, or as a 1d array.

So, a 3D array would never be accessed as a 2D array - at least I've never seen it, and I can't visualise how you'd use it if it was done.

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 12:32
Quote: "with UDT's and arrays, you aren't limited to binary trees."


I wasn't suggesting trees would be limited to binary trees. You could resize each tree to have however many child trees you want. Initially they would have zero.

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 12:33
Quote: "Then you provide a command for that purpose."


How about



?

Why is this so difficult?

If arrays were handled like variables then the language would be much simpler to learn. If the result is a slowdown then the programmer should think again about the advisability of their array copying and/or arithmetic. What's wrong with that? You have exactly the same considerations with the existing for/next loops - but only worse.
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 12:36
How do you suggest subtracting arrays when there is no way to compare two UDTs?

[b]
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 22nd Jan 2011 12:54
Quote: "But no-one actually redefines arrays to different dimensions, and when they access them then access them either using the dimensions they've defined, or as a 1d array.

So, a 3D array would never be accessed as a 2D array - at least I've never seen it, and I can't visualise how you'd use it if it was done."


Good point.

Wouldn't it then make the most sense to have distinct types for arrays of different dimensions? Because functions like ArrayInsert/Remove/Reserve/Size/Push/Pop/whatever only make sense with 1D arrays, so simply disallowing them being passed at compile time due to them being of the wrong type should be clearer for the user, and it would make function signatures use a simpler syntax.

i.e. 'names as Array of Integer', 'grid as Array2D of Integer' and so on.

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 13:02
Hmm... This still doesn't look quite right.



[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 13:09
Quote: "How do you suggest subtracting arrays when there is no way to compare two UDTs?"


I don't understand the question.
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 13:12 Edited at: 22nd Jan 2011 13:13
Presumably this line from your example:
ThirdArray = FirstArray - SecondArray

Would remove all the elements from FirstArray that are in SecondArray and put the result in ThirdArray.

To do that you need to be able to compare two elements, which is not always possible.

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 13:24
Quote: "Would remove all the elements from FirstArray that are in SecondArray and put the result in ThirdArray."


NO!! I mean simple element by element arithmetic.

For example, instead of the ugly and error prone



you would have simply



or perhaps



I'm not too fussed about the precise syntax but the first is just dreadful and antiquated. Let's keep up.

Obviously the arrays would need to be commensural arrays of appropriate types in either case.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 22nd Jan 2011 13:42
Back to the 'arrays as references' thing - I'm not sure why I can't get you to accept this, so I'll lay out everything together.

- Pass-by-reference is more efficient for multi-word objects that pass-by-value (the next isn't a justification, but Java chose the same route for the same reason).

- Efficient in terms of the devices that this language is targeted at means less memory usage, less instructions at the processor level, which translates into less power used, meaning longer battery-lifetime for the device. This is especially important when we're going to be guzzling power for graphics at the same time.

- Having arrays as references to reference-counted objects make pass-by-reference easy. (Push the array reference on the stack, increment the array reference count, call the function. When returning, decrement the array reference count, and if now zero, delete the array).

- Making array objects act as references when you pass them means that the compiler has to support two methods of array access, because you have to have array references anyway.

Yes, I accept that it's an exception to the default of pass-by-value that the programmer will have to learn, but we're already heading towards making arrays stand out anyway by the use of square brackets and their differing array-creation syntax.

On the non-beginner side of things, look at how much power it opens up in the base language for those who'll use it.

@Diggsey,
If trees are simply expandable arrays with data attached, then why have the separate syntax at all?

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 13:44 Edited at: 22nd Jan 2011 13:47
@GG
Hmm, it seems like it would have very limited usefulness though... I mean how many times do you need to add together all the elements in two arrays? I don't think I've ever had to do that, in any of the languages I've used.

And as it can only be used on primitive type arrays as well, it just seems unnecessary.

@IanM
The reason is that trees require special memory management. If any UDT can be made into a tree, it becomes very complicated to enforce the restrictions which need to be applied. (No trees within trees)

By having a special type for it, it simplifies the implementation significantly, and makes it easier for beginners to use.

[b]
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 22nd Jan 2011 13:51
Quote: "Hmm, it seems like it would have very limited usefulness though... I mean how many times do you need to add together all the elements in two arrays? I don't think I've ever had to do that, in any of the languages I've used.

And as it can only be used on primitive type arrays as well, it just seems unnecessary."


If variable-dimension vectors are implemented as native types this functionality should be supported naturally.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 15:08 Edited at: 22nd Jan 2011 15:15
Quote: "Back to the 'arrays as references' thing - I'm not sure why I can't get you to accept this, so I'll lay out everything together."


Is that directed at me?

We seem to be talking about two quite different things. I have absolutely no objection to having the option of passing parameters to functions by reference or by value or whatever and could live with any reasonable option.

In my posts I'm talking about simple component by component arithmetic and assignment for arrays where you might want to initialise a new array using the values of another array before doing something else to it. It would be amazingly tedious if we still had to use for/next looks to do such simple tasks.

@Diggsey

Quote: "I mean how many times do you need to add together all the elements in two arrays? I don't think I've ever had to do that, in any of the languages I've used."


Frequently. And I have to use painfully laborious for/next loops. Manipulating arrays of terrain vertex and heightmap data are good examples where they could be used to streamline code. Just because you've never had to do something doesn't mean others won't find it useful.

Admittedly I'm a bit biased. In my professional work I was working with array arithmetic on large data arrays all the time and have been frustrated by the lack of decent array arithmetic support in DBPro.
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 22nd Jan 2011 15:14
Quote: "Hmm... This still doesn't look quite right.

+ Code Snippet
myarr1 as Array[5] of Integer
myarr2 as Array of Integer
myarr3 as Array2D[2, 3] of Integer
myarr4 as Array2D of Integer

Resize(myarr4, 3, 3)"


Why allow the size of the array to be set in the array declaration? This could cause confusion, because function arguments that are arrays wouldn't be able to have them(presumably). And the square bracket notation is already being changed from round brackets to differentiate function calls from array access, this is basically a constructor call, so that would make it a bit more confusing.

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 15:22 Edited at: 22nd Jan 2011 15:28
@GG
I just don't see why it's so integral to the language that it needs to be implemented as an operator. Especially when it's not obvious that it means apply the operator to every element in the array. Many languages using + to mean a union of two arrays, - to mean one array subtracted from another, and * to mean the intersection of two arrays. That's why I was confused at first.

It could equally well be done like this:


If there was a command called "Add" to do it.

Or even:


@DC
So it would be more like this:
myarr1 as Array of Integer
myarr2 as Array of Integer
myarr3 as Array2D of Integer
myarr4 as Array2D of Integer

Resize(myarr1, 5)
Resize(myarr3, 2, 3)
Resize(myarr4, 3, 3)

[b]
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 22nd Jan 2011 15:47 Edited at: 22nd Jan 2011 15:49
Quote: "@DC
So it would be more like this:
myarr1 as Array of Integer
myarr2 as Array of Integer
myarr3 as Array2D of Integer
myarr4 as Array2D of Integer

Resize(myarr1, 5)
Resize(myarr3, 2, 3)
Resize(myarr4, 3, 3)"


Yes, it would make array declaration require at most 1 extra line, but I think it's more consistent than introducing a constructor like syntax when nothing else has it.


As for the array operators, I don't think any operators besides equality makes any sense compared to the other variables. Addition always adds the elements together for single variables and indeed vectors, why should arrays be totally different?

What you're talking about is concatenating the arrays, which isn't what + means, so it should use a separate function called ConcatenateArray() or similar, and I don't think there should be any inverse to this function. The only exception I guess is strings, but in that case addition of them makes sense and there isn't any ambiguity.(and in case that sentence is confusing, I didn't mean to say strings should have - )

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 15:52
I was saying there SHOULDN'T be operators for arrays. My example of + for union is just what some other languages use. The problem is that everyone has different ideas about what the different operators should do. It's much clearer to have this functionality in commands, because it's obvious what Add() should do, and it's obvious what Concatenate() should do (for example).

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 16:38
"A+B" is just so much simpler than add(A,B).

Do we really want to clutter up the language with



rather than the simpler and clearer



?
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 22nd Jan 2011 16:49
I thought we were talking about arrays here, when would you ever want to divide arrays?

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 16:51 Edited at: 22nd Jan 2011 16:52
Quote: "rather than the simpler and clearer"


Yes, because with D = A + B/C it will only work with integer or floating point arrays. By having methods to do the job you can get it to work with a member of a UDT, or do something slightly different for some elements, etc. without having to resort to a completely different syntax.

@DC
We're talking about making all the normal operators like +-*/^ etc. work on every element in an array when used on arrays.

[b]
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 22nd Jan 2011 16:57
I see, wouldn't it make more sense to create a set of Matrix containers to do this?

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 17:02
That would just lead to more cumbersome code. Let's keep it simple.
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 22nd Jan 2011 17:10 Edited at: 22nd Jan 2011 17:11
But what you're proposing would be a very very specific feature, considering it would only apply to arrays of numeric types, plus, this kind of matrix operation has very limited use cases that wouldn't already be covered by any 2/3/4D vector/matrix function set. Do you really use linear algebra on larger vectors/matrices(via arrays) to the extent that such an addition would be worth it?

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 18:09
Quote: "But what you're proposing would be a very very specific feature"


It's quite possible that you're just not used to vectorizing your calculations.

I'm familiar with one language (R) where vectorized calculations are far more efficient than for/next loops. However I doubt that would apply here.

Quote: "Do you really use linear algebra on larger vectors/matrices(via arrays) to the extent that such an addition would be worth it?"


I'm not suggesting linear algebra as such - just a cleaner way of doing repetitive calculations on arrays. Simple examples might be working on images in code, blending two bitmaps, etc. Once the image data has been put into an array it would be easy to work on. Also, once you start thinking that way you soon realise that many repetitive calculations could be organised into arrays.

However, I can see from the discussion that there probably isn't enough call for this feature - especially as you say it would probably have to be limited to numeric arrays. It's a shame because it's been around for a long time.

Incidentally I was amazed to discover today that C++ apparently doesn't have such support:

arrays in C++

Such support was introduced into FORTRAN in 1992 and into other languages before that and several others since:

FORTRAN90

I can see I'm in a minority of almost one so I guess we'll have to live without it.
bitJericho
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 22nd Jan 2011 18:16 Edited at: 22nd Jan 2011 18:27
It might be worth it to create special functions for such operations if it's *faster* than coding it in the native language.

Otherwise, why not just create special functions in the native language to do what you need

You'd need some way to pass the arrays to a function via a pointer to conserve ram usage. You'd need a set of special function that tells you how many subsets are in an array so you can cycle through an unknown number of subsets and all their indices

You'd need a special function that allows you to modify an array when the number of subsets may change.

You need to be able to return an array.

[center]
Join the TGC Group!
http://tehcodez.groups.live.com
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 18:38
I still think something like this is the best way to do it:


It solves two problems:
- Doing calculations on arrays like you suggested is slow, because for an array with 1000 items, you have to loop from 1 to 1000 for each operation you do. With this method, the ForEach method loops from 1 to 1000 once and you do all the calculations at once for each element.
- It is far more flexible, and can be applied to string arrays, UDT arrays, arrays in arrays, etc.

[b]
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 22nd Jan 2011 18:38
Quote: "Incidentally I was amazed to discover today that C++ apparently doesn't have such support:"


You'll find C++ doesn't do much of anything without #include, it merely gives you the basic tools to do everything. For advanced matrices you'd look at uBLAS, or similar libraries.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 19:56
Quote: "I still think something like this is the best way to do it:



It solves two problems:
- Doing calculations on arrays like you suggested is slow, because for an array with 1000 items, you have to loop from 1 to 1000 for each operation you do. With this method, the ForEach method loops from 1 to 1000 once and you do all the calculations at once for each element.
- It is far more flexible, and can be applied to string arrays, UDT arrays, arrays in arrays, etc."


Good points there. Lets leave this array topic with that suggestion.

[Puts another snippet into his template collection. ]
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 22nd Jan 2011 20:45
Hmm, I might actually try to code that with DBPro - it won't be as clean, but it's doable.

It was just an idle thought I had, but I'll throw it our for discussion: Basically, if you can hold an array within an array, you no longer need multi-dimensional arrays. I wouldn't allow this to dispense with the syntax we've worked our way to right now though.



The compiler would accept either syntax as equivalent.

Quote: "Is that directed at me?"

Yes, in part at least. If 'a = b' copies arrays rather than assigns a reference, then you have to design a new construct to hold array references anyway, making the language more complex. If you write a function to copy arrays, then you have to write one function.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 21:06
Quote: "Hmm, I might actually try to code that with DBPro - it won't be as clean, but it's doable."


I look forward to it.

Quote: "If you write a function to copy arrays, then you have to write one function."


I can live with that as long as we can pass arrays to the function one way or another.

I think I'm happy now.

[Especially so since my attempts at applying your (and enderleit's) DBPro modular coding suggestions seem to be coming along nicely. No unexpected bugs yet. ]
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 23rd Jan 2011 02:26
Quote: " But if you want a copy, how do you suggest we do it? Not by cumbersome for/next loops surely? I agree simple copies should be avoided if possible for large arrays but if you are processing arrays then it's highly desirable to have efficient ways provided by the language rather than potentially inefficient ways provided by the programmer.
"


True

At this point, we're second guessing performance issues of the VM. Hopefully it's quicker than DB classic for example, but you never know.

For clarify, I as originality referring to passing such structures into functions.


Quote: "
Also, if a programmer finds that their array copies slow things up too much then they should think about doing things differently. Why make it impossible for them to make a copy efficiently via the language for those occasions when it works?
"


Agreed, the idea is sound and that's why PB for example has such features built into it.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 23rd Jan 2011 11:51
Quote: "the idea is sound and that's why PB for example has such features built into it."


Interesting. Just looked at the features page on the PlayBasic site and it doesn't seem to mention more general array arithmetic (such as element by element addition, etc). Is it just basic manipulation like copying that's built-in? Even if it is it's good to hear and would be useful here.
Digital Awakening
AGK Developer
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 1st Feb 2011 20:30
I like to do my variable declarations with as little work as possible as I do not like doing them but I can see the benefit of doing them. I prefer as few letters and words as possible and I also like grouping multiple variables using commas.

int integer1, integer2...
flt float1, float2...
str string1, string2...

With arrays I'm happy with:
int array1[10, 10], array2[100]...

[center]
Alquerian
18
Years of Service
User Offline
Joined: 29th Mar 2006
Location: Reno Nevada
Posted: 17th Feb 2011 01:22
I like the second approach better. Defining a variable with "" should be evidence enough that it is a string. If you want to explicitly declare it as:



would suffice as well. I don't think you need the # or the $ or any of that nonsense to define or declare a variable. Leave the special characters in regex and perl where they belong
LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 15th Mar 2011 02:05
Hi Guys,

Phew, a lot of ideas for how to deal with arrays in about of functions! Right now the AppGameKit compiler handles arrays pretty much like DBP and I am using this as a grounding post for any new fangled ideas thrown at it I'm not too happy about adding arrays within user types, pointer types, special operators, memory commands, complex array symbolism or departing too far from how the DBP array system functioned right now.

So right now an array is created like this:

Dim myarray[100] As Integer

And accessed like so:

myarray[50]=123

Having read 'most' of the posts, it seems there is a strong desire to enable modular tasks by passing all or some of the array into a function by reference and/or by value.

Just a heads up that in order to promise universal compatibility with any device with AppGameKit, I have instructed the compiler to reject locally defined arrays within user functions to preserve stack memory, which some devices might have precious little of. This means we don't need arrays passed by value (which is not a great idea for performance apps, i.e. all apps). This leaves pass by reference, which is also not required as all arrays by virtue of not having any local arrays are entirely global. This means all arrays can be accessed immediately without them being passed into functions and thus producing a faster program. Agreed, yes, no?

One area I could look at is passing variables (standard and UDT) by reference, so you can do something like this:

Type LeeType
A B C
EntType
Dim Lee[50] as LeeType
For N=1 To 100
MyFunc(Lee[N])
Next N
End
Function MyFunc(T As LeeType Ref)
T.A = T.B
EndFunction

Essentially without the 'Ref' keyword it would be a typical pass by value which works in DBP right now, but the Ref keyword instructs the calling command to only pass the UDT pointer and instructs the user function to handle the T as a pointer to the data, rather than the data itself. In this case, you can see the clear performance advantages, especially if the UDT was a large one.

Sorry to reduce what must be a huge amount of discussion to the statement, let's add a 'Ref' keyword, but I wanted to get some reaction on taking a popular request and running with it. I thought about 'it'll be a cold day in hell before I implement that pile', but figured you needed something more constructive after waiting over a month!

I may also be tempted to add this command:

Dim Lee[50] As Integer
Dim Fred[100] As Integer
CopyArray ( Fred[], Lee[] )

Essentially the compiler would understand this as 'copy as much of Lee into Fred as you can without creating a memory overrun. Variations on this theme could be:

CopyArray ( Fred[], iToPos, Lee[], iFromPos, iSize )

The reason I propose this over lots of squiggles is that symbolic meaning is very tough to read when you don't know the language, and we want AppGameKit to be very readable (like the original BASIC). Coders will understand a command approach. I also feel that because we are using a VM/Interpreter, it is not recommended to create a large loop to copy this data one element at a time for performance reasons. The above command would resolve to a single memcpy command, and providing the two arrays are sensibly paired to types, will be amazingly fast indeed. I am not too keen on an 'intelegent' copy which trawls UDT fields for likely things to copy as this hides functionality under the hood, requiring a healthy user manual to unravel what is going on.

Whether we denote the array reference as 'Fred[]', or just 'Fred' is open for debate but I leaned towards the [] to clearly show this is an array, and used very deliberately. Emotionally though, without the brackets, the code looks much cleaner and a little nicer to read.

If I can get a consensus on these two issues (A) adding 'Ref' and (B) adding CopyArray and whether these satisfy many (er, two) of the functional additions you would like to see in AGK. Personally I can see myself using both of these quite a lot as they're very easy to incorporate into my existing coding habits So for me;

A=YES
B=YES

I drink tea, and in my spare time I write software.
Digital Awakening
AGK Developer
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 15th Mar 2011 15:06
Lee:
A = YES PLEASE!
B = YES

Having all arrays global seems practical to me, although I can see the use of local arrays as well. CopyArray() is probably going to be useful too.

Also, for clarity I think you should always use [] when dealing with arrays to distinguish them from variables. I was wondering if you can have a variable and an array with the same name, [] would be the only difference.

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 15th Mar 2011 15:07
Quote: "This leaves pass by reference, which is also not required as all arrays by virtue of not having any local arrays are entirely global."

Don't agree.
Without passing arrays by reference, a function can operate only on hard-coded arrays, and cannot be written to handle an unknown number of arrays for generic tasks such as sorting & filtering.

I'd definitely like to be able to do this:



A=YES
B=YES, but I could do it myself with array references

Digital Awakening
AGK Developer
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 15th Mar 2011 15:25
Yes, it is really annoying having to make multiple identical functions to handle different arrays.

I think it's better to write:
myFunction(myArray[] as int)

Instead of this:
myFunction(myArray as integer ref)

If all arrays are global the "ref" keyword seems pointless. Correct me if I'm wrong.

Rampage
16
Years of Service
User Offline
Joined: 4th Feb 2008
Location: New Zealand
Posted: 15th Mar 2011 23:32
I personally find the overall idea of the dim command a bit silly.
Its really an unneccassary basic programming addition.

Whats wrong with:

int DeepFriedChicken[50];
float DeepFryTempC;

DeepFryTempC = 12.6;
or
DeepFryTempC(12.6);

Doesn't really matter.

And then call define each array part in the same manner.
Looks a lot better in my book, but that may just because I am a C++ programmer more than a DB dude.

Keeps in simpler, if not a little less difined in my honest opinion.


Regards,

Max
Digital Awakening
AGK Developer
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 16th Mar 2011 01:29
I agree, the existence of the dim command is also a good question. Since arrays now have [], using dim in the declaration seems unnecessary.

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 16th Mar 2011 15:04
DIM is also a command that has an effect at runtime - it allocates the memory for the array, and as arrays can vary in size, it makes sense to have a command to do that.

LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 18th Mar 2011 06:30
If I was teaching programming, and I had a choice between:

int* pMyArray = new int[100];
pMyArray[50]=10;

and:

DIM MyArray[100]
MyArray[50]=10

I think I would choose the second one Less to type, less to explain, easier to read and recognisable to a lot of DBP users As Ian suggests, DIM is actually a command which can not only create arrays but resize them while protecting the data stored inside it. Try DIM MyArray[200] in C++ and you get:

dwMyNewArraySize = 200;
int* pMyNewArray = new int[dwMyNewArraySize ];
memcpy ( pMyNewArray, pMyArray, dwMyOldArraySize * sizeof(int) );
delete pMyArray;
pMyArray = pMyNewArray;
dwMyOldArraySize = dwMyNewArraySize;

I think my classroom would be empty (or asleep) in about ten minutes! I suppose we could try out a new form of array declaration such as:

MyArray AS INTEGER ARRAY
MyArray[] = CreateArray ( 100 )

But again it's longer, more to learn, looks a little odd to DBP users, is somewhere between returning a value from a function and a malloc and my personal dislike; it forces you to pre-declare your data type. From the various AppGameKit threads, the DIM statement has come under quite a bit of thrashing, but I've not seen anything that can elegantly replace it as yet (and I quite like it too).

In respect of REF, when we pass a variable or UDT into a function (not an array) by reference, we need to declare it as different from something passed by value, perhaps we use Ptr instead:

FUNCTION MyFunc ( Variable As Integer Ptr )

Ian, your idea about having array pointers passed into the functions gets very messy when you consider the user can pass in any array they want, even ones that are different sizes and dimensions. The only way it could be done that is not messy, is to allow only single dimension arrays as in your example and the size of the local array is copied from the source array at runtime (for a small performance hit). This would allow your filter function to work as intended. Does anyone else have any ideas on how this 'pass any global array to a function by reference for use as temporary access to that array' feature might be used? I can't think of many.

I drink tea, and in my spare time I write software.
Digital Awakening
AGK Developer
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 18th Mar 2011 10:43
Lee:
I also prefer DIM over the examples you use. But is there any reason these cannot be used:

array1[50] as integer
int array2[50]

Then a command like: resize(array1[100])

I don't really mind DIM myself, just thought the above would be more consistent now that arrays use [].

DMXtra
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: United States
Posted: 18th Mar 2011 11:23
I think DIM is fine.

Dark Basic Pro - The Bedroom Coder's Language of choice for the 21st Century.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 18th Mar 2011 16:04
Quote: "In respect of REF, when we pass a variable or UDT into a function (not an array) by reference, we need to declare it as different from something passed by value, perhaps we use Ptr instead:"

The difference from a compiler internals type view is minimal. The difference is in the programmers usage of that variable.

As a reference:


My preference is to use it as a standard variable and that the compiler works out how to get the right value stored or retrieved from the right storage location for me.

Quote: "Does anyone else have any ideas on how this 'pass any global array to a function by reference for use as temporary access to that array' feature might be used?"

As a 'for-instant', how about having lists of sprites to test for collisions.



Simply being able to pass around references to lists opens up all sorts of possibilities, and code-space-wise, is more efficient that having a function for each possible set of arrays. It's also better the code once than many times, especially in the presence of programmer bugs (fix in one place, rather than in many copies of essentially the same code).

I'm happy to drop multiple-dimension arrays for now, as lists are much more useful.

However, with references in place, it should be possible to pass the pointer to the array header around. If the array data is separated from the header (ie the header points to the data, rather than the way DBPro does it), then even resizing an array after it has been passed should be possible without causing problems.

LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 7th Apr 2011 05:15
Thanks for the example Ian, I can see how useful your function becomes to save space and development time. Currently AppGameKit passes arrays around as a pointer to the header, not the data, so I have full access to the size of the elements and overall array size, so (at least for a single dimension list) your idea should not be rocket science to add in (I just need to reconcile it with the passing of multi-dimensional arrays which would either have to be identically structured or use some internal magic). Initially I thought global access to arrays answers the need for passing arrays in, but your idea has merits I cannot solve any other way at present.

Does anyone else see this as a priority compiler addition, or do many of you prefer to unroll your logic to something more like this:



Thoughts welcome!

I drink tea, and in my spare time I write software.
DMXtra
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: United States
Posted: 7th Apr 2011 11:07
I like Ian's example and would like to see this as a priority compiler addition.

Dark Basic Pro - The Bedroom Coder's Language of choice for the 21st Century.
Digital Awakening
AGK Developer
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 7th Apr 2011 11:10
Lee:
I see uses for both ways. However, I would much rather put the FOR loops within functions if possible as that would make the code calling the functions much cleaner. Maybe you need to check the length of the lists etc. and maybe you need to call the function more then twice per loop. Then it becomes even more useful to have all that code within the function.

So BOTH (if your method doesn't work either)

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 9th Apr 2011 13:26
@Lee,

Before you go away and hack apart arrays, and to be clear on what I meant when I said...
Quote: "If the array data is separated from the header (ie the header points to the data, rather than the way DBPro does it)"


I mean that rather than a single allocation to create the array that includes header + data pointers, to instead allocate the data pointers separately from the header, and extend the header to include a pointer to that data.



So you'd still use a pointer to the header, but the header would no longer contain the data directly and instead have a pointer of its own to point to the data.

That gives a benefit (with pointers/references etc) that the pointer will always point to a valid array header even in the event of an array resize, which is not true for DBPro arrays right now.

Login to post a reply

Server time is: 2024-04-19 00:40:17
Your offset time is: 2024-04-19 00:40:17