Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[strainer]

terrain[y] = list(currentline) is faster, since it's assigning to the array once for each row

Its also creating a new persistent (array/table) out of each 'currentline' which is also an (array/table/temp-buffer) and it is replacing the old persistent (array/tables) that are neatly structured already in terrain. At least thats what the interpreter is being told to do.

In Python nearly everything is a reference

This is not true, a quick test:

Code: [Select]

b = 2
c = [0,b]
b = 3
print "c[1] is %s" % c[1]
> c[1] is 2


[bloop_bleep]

I said "nearly everything." Literals like numbers and strings are not references, but arrays are:

Code: [Select]

>>> b = [0,1,2]
>>> c = ['a',b]
>>> c[1]
[0, 1, 2]
>>> b[2] = 3
>>> c[1]
[0, 1, 3]


[Mephisto]

And this is where the "id" builtin comes in handy.

[bloop_bleep]

And this is where the "id" builtin comes in handy.

If you want to check whether two objects refer to the same thing, the 'is' keyword works just as well as comparing their ids (better, even, because it's less confusing.)

[strainer]

Literals like numbers and strings are not references, but arrays are

Right - so as in this case we have been discussing, we have to copy string values.... doesnt matter how they are encoded here actually - as raw char arrays, as refs to char arrays, refs to hashes of chars.. whatever. We have to move data from one input_array into another output_array which has already been constructed It is not efficient to create packaging arrays (with list()) and then insert them (references to them most probably) into the structure of the existing output_array. You are creating new arrays there, still needing to populating them with data from the input - then throwing chunks of the existing structure of the output array (references and/or values) on the garbage to be collected later and inserting the new references to the 'sub' arrays in as well.

Just copy the values from the input into the output. one by one - that's everything done, no fuss.

[Urist McScoopbeard]

Lotta stuff happening! At work! Sorry I can't respond, will be home soon!

[bloop_bleep]

Literals like numbers and strings are not references, but arrays are

Right - so as in this case we have been discussing, we have to copy string values.... doesnt matter how they are encoded here actually - as raw char arrays, as refs to char arrays, refs to hashes of chars.. whatever. We have to move data from one input_array into another output_array which has already been constructed It is not efficient to create packaging arrays (with list()) and then insert them (references to them most probably) into the structure of the existing output_array. You are creating new arrays there, still needing to populating them with data from the input - then throwing chunks of the existing structure of the output array (references and/or values) on the garbage to be collected later and inserting the new references to the 'sub' arrays in as well.

Just copy the values from the input into the output. one by one - that's everything done, no fuss.

I understand, I've said I misread the code.

[strainer]

I was a bit confusing talking in a general sense about interpreted array-like classes, because: I since read - we can employ simple and quick arrays in python by importing array or numpy, but here "terrainarray" was really a list of lists.   

...its this old problem of naming things.

Modern javascript interpreters and lua to some degree will internally manage array-like containers simply and performantly if you 'treat them simply' But its possible python doesn't make any attempt to do that with its 'list' container. Good that its able to import array though.

[bloop_bleep]

Okay, everyone, I am soliciting advice on a problem in a C++ project of mine.

Basically, I'm trying to create the framework for a simulation system, that basically consists of several "components", each of which contains several "ports" which are connected (not necessarily within the same component) using "links." The thing is, this system is not meant to simulate any specific phenomenon; rather, I will have several kinds of components, ports and links, e.g. for steam and electricity. I have defined abstract base classes for all of these things, and the specific implementations will be derived classes. The problem arises with how the inheritance will work.

Let's say we have a class SteamPort which derives from Port, and SteamLink which derives from Link. SteamLinks naturally can only be constructed between two SteamPorts. Let's also suppose we have a function that wants to do a certain operation on a SteamLink, by reading and modifying the temperature and pressure values of the two attached SteamPorts. The problem is, the get_ports() method defined in the Link base class returns a pair of two Port pointers, which don't support reading and writing temperature and pressure, since those are specialized functions, which don't belong in the abstract base classes. There are several ways I can think of to work around this:

• Casting the Port pointers to SteamPort pointers. This seems like a pretty simple solution, but I dislike casting and use it as little as possible.
• Declaring abstract get_data() and set_data() methods in the Port class and implementing them in the SteamPort class. My concern with using this is that there might be some other operations (like calculations) or restrictions (like read-only) that I want to do in the derived class that won't be supported with this framework.
• Declare a catch-all interact() method that handles all specific functions, like reading/writing data and performing calculations. I like this option, but I fear this might overcomplicate it for me.

What do all of you think?

[MorleyDev]

My first thought is that inheritance is perhaps not the best solution for this problem. If it's too late for that, you could use RTTI to check the types of your classes when casting for some extra safety but it's a messy solution.

My guess would be a data-driven approach, perhaps something similar to a simplified form of the entity-component system used in several Video Games, may be a better fit. Or just a database and functions that operate on that database.

[Telgin]

Honestly, I'd probably just cast them since it's the easiest way, and probably the most clear too.  Presumably whatever code you have that sets up the links will ensure that only compatible types are ever linked together, so it shouldn't be dangerous.

A component architecture would probably work fine, but might be overkill.  Presumably, it would amount to your code being something like this:

Code: [Select]

void SteamComponent::update_links() {
for (int i = 0; i < links.size(); i++) {
Link link = links[i];

TemperatureComponent *temperature = link->get_component('temperature');
if (temperature) {
temperature->update();
}

// Repeat as needed for each component it should care about
}
}

Bear in mind that I've never actually implemented a component architecture and my C++ is very rusty, but that's my understanding of how you do it.  You'd need a base Component class, with subclasses for each type of component which would store the properties and methods that operate on it.  A TemperatureComponent would store temperature and have functions for manipulating it.  A PressureComponent might do the same for pressure, and so on.  At this point you only need a single Link class with a list of components that are added to it when it's constructed, which tell you what it keeps track of.

Ultimately, that feels like it's just adding an extra layer of complexity and indirection without much benefit though.  It would mostly be helpful if you were going to reuse those components between things, like if the ports, links and simulator components all needed a TemperatureComponent, for example.  In video games, these kinds of component systems are usually used in many places, with a HealthComponent shared between the player, NPCs, destructible environments, and so on, for example.

[MorleyDev]

A TemperatureComponent would store temperature and have functions for manipulating it.

I'd tend to suggest having data separate from logic. So your logic are functions that operate on the data, not stored with it.

ECS was just a first quick thought, but after it bit more thinking the way I'd perhaps approach this problem is more in line with having your 'components' and 'links' and 'ports' stored in a graph data structure, which is what it sounds like bloop_bleep is going for as I'm reading it, and the logic is then carried out with the graph as the input and either mutating the graph (procedural) or the next state of the graph as the output (functional).

But since that's obviously a massive structural change, prudence would perhaps mean a cast is a lesser evil than a rewrite

[McTraveller]

It's been a while since I've C++'d...  does C++ allow heterogeneous collections?

[bloop_bleep]

It's been a while since I've C++'d...  does C++ allow heterogeneous collections?

I suppose you can use std::set<std::any>, but that's some newer features I'm not really familiar with.

[Telgin]

For a very simple and dangerous solution, you can always push void pointers to things into a collection.  Of course, you'd have to know how to convert them back later, lead to inefficient memory layouts if you're dynamically allocating the items you're inserting, and you wouldn't be able to do it for stack variables that get cleaned up before you use the collection.

I can't think of a reason I'd ever do it, but you technically can.