1. Need clarification on empty arrays and alocated space

I went through the manual but I could not find the answer I need.

Are OEu empty arrays a different type like the 'slices' in Go?
Do these 'slices' need a backup array with a certain predefined size?
Does the size of these backup arrays grow exponentially as the 'slice' increases its length (as they do in Go)?

Thank you.

new topic     » topic index » view message » categorize

2. Re: Need clarification on empty arrays and alocated space

jpartridge said...

I went through the manual but I could not find the answer I need.

Are OEu empty arrays a different type like the 'slices' in Go?
Do these 'slices' need a backup array with a certain predefined size?
Does the size of these backup arrays grow exponentially as the 'slice' increases its length (as they do in Go)?

Thank you.

Everything in Euphoria is an object. An object is either a number (called atoms in Euphoria) or a sequence. There are no "arrays". You can simulate arrays with sequences. The sequence {1,2,3,4} is like an array. Well, think of a sequence as an array of general objects.

print(1, sequence({})) -- prints 1 (for true) 
print(1, sequence({1,2,3})) -- also prints 1 (for true) 

See so empty sequences are sequences too. You can make a user defined type for empty sequence

type empty_sequence(object x) 
    if not sequence(x) then 
        return 0 
    end if 
    return length(x) = 0 
end type 

Then you can say:

print(1, empty_sequence({})) -- prints 1 (for true) 
print(1, empty_sequence({1,2,3})) -- but this prints 0 (for false) 
new topic     » goto parent     » topic index » view message » categorize

3. Re: Need clarification on empty arrays and alocated space

Replying for Phix:

jpartridge said...

Are OEu empty arrays a different type like the 'slices' in Go?
Do these 'slices' need a backup array with a certain predefined size?

No and no.

jpartridge said...

Does the size of these backup arrays grow exponentially as the 'slice' increases its length (as they do in Go)?

Yes, if by that you mean that whenever more space is needed it doubles in size. (Not sure it is exactly that in OE, but it is double in phix.)
What happens in practice is that:
a) in the worst case some items may occupy nearly twice the theoretical minimum.
b) however freeing and de-fragmenting no longer needed space happens automatically and extremely efficiently,
c) and growing a list/table one element at a time is (obviously) far faster than copying the whole lot every time.
d) reference counting/memory sharing makes phix surprisingly memory thrifty, especially compared to many oo and dynamically typed languages.
e) almost always, you simply should not care much (except for deliberate memory hogging) about such details, it is in fact part of the core language philosophy that you should not need to.

Pete

new topic     » goto parent     » topic index » view message » categorize

4. Re: Need clarification on empty arrays and alocated space

Thank you SDPringle.
I think I've got it (although I think more as a mathematician than as a programmer).

new topic     » goto parent     » topic index » view message » categorize

5. Re: Need clarification on empty arrays and alocated space

said...
jpartridge said...

Does the size of these backup arrays grow exponentially as the 'slice' increases its length (as they do in Go)?

Yes, if by that you mean that whenever more space is needed it doubles in size. (Not sure it is exactly that in OE, but it is double in phix.)
What happens in practice is that:
a) in the worst case some items may occupy nearly twice the theoretical minimum.
b) however freeing and de-fragmenting no longer needed space happens automatically and extremely efficiently,
c) and growing a list/table one element at a time is (obviously) far faster than copying the whole lot every time.
d) reference counting/memory sharing makes phix surprisingly memory thrifty, especially compared to many oo and dynamically typed languages.
e) almost always, you simply should not care much (except for deliberate memory hogging) about such details, it is in fact part of the core language philosophy that you should not need to.

Pete

a), b), c), d):
Thank you petelomax.

e)
That argument is almost as good as the one invoked by the group(*) to vote 'democratically' that Golang should be preferred over OpenEuphoria because it's a "more modern language" and "everybody is using it now". Almost. :)

(*)Half of them are not programmers and half of those who (theoretically) are do not intend to write a single line of code for the project.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu