New array features
-
- Posts: 284
- Joined: Mar 07, 2018 13:59
- Location: Germany
Re: New array features
Jeff,
i don´t claim, that the solutions i found for various problems, are the most efficient solutions. I first want to make it work (somehow), then i don´t mind making it faster, better, more efficient, whatever. My overall knowledge about the compiler and how things might be done most efficent is still limited compared to yours. Nevertheless i try to find ways of acchieving what i want.
Making a pull request for every little thing (i don´t even know, if it needs to be changed or removed again or in the course of development), wouldn´t let me make any progress. I would have to wait, if it is accepted or not, or if it is accepted with changes, which might make it worthless for my purposes. I would have to justify every request (why, what for).
So i choose to go on and to make it work as a whole before making maybe useless pull requests. There is still one feature (array scan) to add, then i´m ready and open for comments, critics and improvements.
TYPEOF:
i need a method of retrieving a variables type (any type, not only the predefined ones) at run time too. Integer values representing each standard type and one for UDTs would do as well. Something like "vartype" would indeed come in handy. I´m sure there are more places, where my code could/should be improved.
JK
i don´t claim, that the solutions i found for various problems, are the most efficient solutions. I first want to make it work (somehow), then i don´t mind making it faster, better, more efficient, whatever. My overall knowledge about the compiler and how things might be done most efficent is still limited compared to yours. Nevertheless i try to find ways of acchieving what i want.
Making a pull request for every little thing (i don´t even know, if it needs to be changed or removed again or in the course of development), wouldn´t let me make any progress. I would have to wait, if it is accepted or not, or if it is accepted with changes, which might make it worthless for my purposes. I would have to justify every request (why, what for).
So i choose to go on and to make it work as a whole before making maybe useless pull requests. There is still one feature (array scan) to add, then i´m ready and open for comments, critics and improvements.
TYPEOF:
i need a method of retrieving a variables type (any type, not only the predefined ones) at run time too. Integer values representing each standard type and one for UDTs would do as well. Something like "vartype" would indeed come in handy. I´m sure there are more places, where my code could/should be improved.
JK
Re: New array features
@JK,
Why don't you focus more on: what the community as a whole, deems important.
Like as a first step, the possibility to distinguish between "Fix-Len" and "Dynamic"
array? This implementation (as a first step) could be a first commit, to start off
with. It might also be the only one, that people like myself whould appreciate (use
in practice). The remainder (whatever that might be), is of a far lesser interest.
(As already discussed between you and fxm.)
This sounds very self centered.JK wrote:Nevertheless i try to find ways of acchieving what i want.
Why don't you focus more on: what the community as a whole, deems important.
Like as a first step, the possibility to distinguish between "Fix-Len" and "Dynamic"
array? This implementation (as a first step) could be a first commit, to start off
with. It might also be the only one, that people like myself whould appreciate (use
in practice). The remainder (whatever that might be), is of a far lesser interest.
(As already discussed between you and fxm.)
Re: New array features
I agree.
The most important thing for a user is to add in FBC features that do not exist yet and that the user can not code himself, or do it, but in a twisted way.
For me, this ability to discriminate between an array of fixed size and an array of variable size is interesting (like the ability to easily obtain certain information contained in the array descriptor). The rest, I can code it myself in a own reusable module.
The most important thing for a user is to add in FBC features that do not exist yet and that the user can not code himself, or do it, but in a twisted way.
For me, this ability to discriminate between an array of fixed size and an array of variable size is interesting (like the ability to easily obtain certain information contained in the array descriptor). The rest, I can code it myself in a own reusable module.
-
- Posts: 538
- Joined: Dec 02, 2011 22:51
- Location: France
Re: New array features
In my opinion, it is very important to be able to offer "high level" libraries but at the same time easy to use because it contributes to the attractiveness of the language. The question of how only arises in the case where one envisages targeted evolutions of the functions low-level, this point being outside my scope of proposal. We thus have, it seems to me, three lines of contradictory explorations: the openness to the high level, the ease, the need to preserve the performances and the low level optimization consistency. Another point to consider is that the language have to live, evolve: thus more people are attracted to language.
Re: New array features
Yes, but for example for the new array copy feature:
- it would be nice to be able to write it in the natural form:
array2() = array1()
=> evolution of the implicit 'Let operator', - and not:
copyArray(array2, array1)
=> where 'copyArray' would be for example a macro name in a library.
Re: New array features
In pascal you can do this for fixed length arrays, but not for dynamic arrays (which always start at element[0] thus can be regarded as pointers)
So in pascal for dynamic arrays, the result is as memcpy.
Also I notice in python (lists) that it seems to be a pointer copy also.
What would freebasic's array2() = array1() aspire to be?
Both static and dynamic arrays with similar dimensions up to 8 resulting in completely individual arrays ?
You could perhaps extend dim byref array2() = array1() for an alternative.
At the moment:
"Array of references - not supported yet"
If any of this stuff has been done yet then I apologise, I have not been testing code in this thread.
So in pascal for dynamic arrays, the result is as memcpy.
Also I notice in python (lists) that it seems to be a pointer copy also.
Code: Select all
a=[1,2,3]
b=a
b[1]=5
print(a)
#resuts was [1, 5, 3]
Both static and dynamic arrays with similar dimensions up to 8 resulting in completely individual arrays ?
You could perhaps extend dim byref array2() = array1() for an alternative.
At the moment:
"Array of references - not supported yet"
If any of this stuff has been done yet then I apologise, I have not been testing code in this thread.
Re: New array features
For example, only allowed by the compiler for two arrays of the same type and number of dimensions (or the destination array of same type declared as dynamic without specifying the number of dimensions):dodicat wrote:What would freebasic's array2() = array1() aspire to be?
Both static and dynamic arrays with similar dimensions up to 8 resulting in completely individual arrays ?
- If the destination array is static, copy only common elements (corresponding to all index combinations defined for both).
- If the destination array is dynamic, resize it as is the source array, and copy all the elements.
Last edited by fxm on Jul 15, 2019 15:34, edited 1 time in total.
Re: New array features
FB is a language that implements variables as boxes in memory that you can address, so I would expect a deep copy in FB, and that appears to be what happens. Python is more abstract and its variables do not work the same way.
This is obviously off topic here, but it's interesting. Python "variables" are simply names bound to objects, not slots in memory. In Python "=" is not copying, but rather binding a name to a value or object. The same object can have multiple names bound to it. Also objects like a list can refer to other objects of course. If one needs an actual copy of a list or other mutable object, there's a bunch of methods for doing this in the copy module. When an object is unbound from a name, or a reference is removed, the count on the object is decremented and when it hits zero, the garbage collector will remove it, which works well most of the time if the references are not circular.dodicat wrote:Also I notice in python (lists) that it seems to be a pointer copy also.
-
- Posts: 284
- Joined: Mar 07, 2018 13:59
- Location: Germany
Re: New array features
Sigh...This sounds very self centered.
Despite of the fact, that i´m definitely not the most experienced FreeBASIC compiler coder (Nevertheless) i try to find ways of acchieving what i want (the compiler to do)
If Jeff accepts my appoach for this specific problem, there will be something like this:
Code: Select all
dim a(1 to 5) as long
...
if array(isfixed, a) then
...
This would be a wrapper for a RTL function, which inside the RTL could be used for fixing the issues about erasing fixed size arrays you dicussed with Jeff. Tests show, that combining binaries compiled with prior versions of the compiler with new binaries doesn´t raise combatibility problems. The only drawback would be that as long as "old" binaries are involved you cannot tell for sure, if an array is of fixed size or not (just as you cannot right now).
All array macros returning a value will finally be written in a way that they can be used in a function like manner even inside expressions.
And there will be methods of retrieving the descriptor values e.g.
Code: Select all
dim a(1 to 5) as long
dim p as any ptr
...
p = array(data, a) 'returns pointer to memory location, where the array´s data is stored
...
JK
Re: New array features
I hope that all these new features for arrays will be compatible not only of all types predefined by fbc (including the var-len string, the fix-len strings, the pointers, ...), but also any type defined by the user (taking into account its own constructors/destructor and overload operators if exist).
Last edited by fxm on Jul 16, 2019 15:04, edited 1 time in total.
-
- Posts: 284
- Joined: Mar 07, 2018 13:59
- Location: Germany
Re: New array features
It will be compatible with all kinds of arrays, i will do my very best ;-)
-
- Posts: 606
- Joined: Nov 28, 2012 1:27
- Location: CA, USA moving to WA, USA
- Contact:
Re: New array features
@MrSwiss:
He has made it clear: he is not sure what he will do, how he will solve all problems, what he will change while working toward his goal. An early commit fixes a POSSIBLE fix for an issue. To change it, now it then becomes a triple step to get what he would need. THAT is not a smart very practice.
If YOU want something, YOU should author and submit that change. Or is that too self-centered?
@fxm
Someone said: Everything Should Be Made as Simple as Possible, But Not Simpler
Are you smarter than that guy?
All of you:
1 - JK IS attempting to add new features
2 - it is his desire; he is making the effort and not doing it in secret and is inviting the community to help
3 - he has been sensitive to advice and criticism from others - trying to follow any rules suggested to him
You should all be applauding him.
Are YOU extending, fixing, maintaining the language? Has his effort cost YOU something?This sounds very self centered. ...
He has made it clear: he is not sure what he will do, how he will solve all problems, what he will change while working toward his goal. An early commit fixes a POSSIBLE fix for an issue. To change it, now it then becomes a triple step to get what he would need. THAT is not a smart very practice.
If YOU want something, YOU should author and submit that change. Or is that too self-centered?
@fxm
You are making valuable contributions on the wiki and helping many, many people improve their code with your perceptive, critical eye. Clearly, your knowledge of FB is deep. But ... what does an added feature teach a newbie when it is added "in a twisted way"? Is the message to be: obfuscation and code tricks are a good practice? Or - go away, you aren't ready for this?The most important thing for a user is to add in FBC features that do not exist yet and that the user can not code himself, or do it, but in a twisted way.
Someone said: Everything Should Be Made as Simple as Possible, But Not Simpler
Are you smarter than that guy?
All of you:
1 - JK IS attempting to add new features
2 - it is his desire; he is making the effort and not doing it in secret and is inviting the community to help
3 - he has been sensitive to advice and criticism from others - trying to follow any rules suggested to him
You should all be applauding him.
Re: New array features
Maybe I did not express myself well, but on the contrary I wanted to say that it is better to have a proper feature added in fbc to prevent the user from being content with a twisted personal code.speedfixer wrote:But ... what does an added feature teach a newbie when it is added "in a twisted way"? Is the message to be: obfuscation and code tricks are a good practice? Or - go away, you aren't ready for this?
-
- Posts: 606
- Joined: Nov 28, 2012 1:27
- Location: CA, USA moving to WA, USA
- Contact:
Re: New array features
@fxm:
Please forgive me. I thank you for the clarification.
david
Please forgive me. I thank you for the clarification.
david
Re: New array features
Yes, as soon as nobody else of the community as a whole, gains anything by doing so.speedfixer wrote:If YOU want something, YOU should author and submit that change. Or is that too self-centered?