"x" shades of vacuum?

[Nedix]

I have several searing hot boulders on my map (Volcanea) and after slowly digging them and constantly checking the temp I discovered that not all vacuums are equal. 3 chambers in the image are sealed off and according to the temp chart they are at Absolute Zero. The 4th chamber, the one with the shaft, is the active digging chamber and it seems to be only Chilled vacuum. What gives?

 

 

[Olleus]

Does the UI just show the temperature of the last gas in the vacuum? It doesn't really make sense to say the Vacuum is at absolute 0 (or any other temperature), it doesnt have a temperature at all.

[Nedix]

Well, the last gas in any of those chambers was anywhere between 400 and 1300 degrees.

[suxkar]

From what I have understood from other topics, while having different rules, vacuum is basically a gas that is destroyed by other gasses. Because of this, it might have the attribute of "temperature" like any other gas, although such attribute is effectively not used

[Nedix]

It's not an issue, not even an annoyance, it's just a curiosity

[psusi]

1 hour ago, suxkar said:

From what I have understood from other topics, while having different rules, vacuum is basically a gas that is destroyed by other gasses. Because of this, it might have the attribute of "temperature" like any other gas, although such attribute is effectively not used

I don't think so.  It has no mass and does not spread around, nor does it ever exchange heat, even with a tempshift plate, and that works on neutronium.  Vacuum is simply the absence of any fluid.

[PhailRaptor]

8 hours ago, psusi said:

I don't think so.  It has no mass and does not spread around, nor does it ever exchange heat, even with a tempshift plate, and that works on neutronium.  Vacuum is simply the absence of any fluid.

True, but that's not even remotely how vacuum is coded into the game.  The game simulation handles it as though it was a gas with no temperature and can't exchange temperature.

[psusi]

1 hour ago, PhailRaptor said:

True, but that's not even remotely how vacuum is coded into the game.  The game simulation handles it as though it was a gas with no temperature and can't exchange temperature.

Have you looked at the code?  Because neutronium is a solid with no temperature and does not exchange heat.. but a temp shift plate works to exchange heat with it.  How much mass does it have?

If I were programming it I wold make an enum for the fluid type in a tile and the first one would be NONE, aka vacuum and have a mass of zero.  I guess you could describe that the way you have, but I consider that to mean NO FLUID.

[Gurgel]

10 hours ago, psusi said:

Because neutronium is a solid with no temperature and does not exchange heat.. but a temp shift plate works to exchange heat with it.  How much mass does it have?

From my observations, quite a bit or quite high specific heat capacity.

10 hours ago, psusi said:

If I were programming it I wold make an enum for the fluid type in a tile and the first one would be NONE, aka vacuum and have a mass of zero.  I guess you could describe that the way you have, but I consider that to mean NO FLUID.

So, is "not a fluid" actually a fluid? This is a pretty tricky border case and sometimes hard to get right. For example, is NaN a number? For some purposes (calculations) it can be, but it you print it it does something that can be catastrophic: It prints a string of letters "NaN" instead of _digits_, i.e. it violates the spec what a number looks like. Also, is "no car" the type of car you can own? Or is "not ill" your sickness state? 

The underlying issue is what to make your ground set. The choice you have when defining the set of all states A (e.g. fluid type) is to require everything in there to be a fluid (then you get the exception case that something is not a fluid outside of the ground set and you need to go into a fully separate process step/code path to deal with that case) or you add a specific state "not a fluid" which violates that the set of exactly all fluids should of course only contain fluids. There you can mostly keep the regular process steps/code paths, but you need to add "small" exceptions in different places. 

So what to do? The really correct solution would use a "set of all fluids" and a super-set "set of all tings that can be in a tile". The first one would not include vacuum, the second one would. But now you need to handle this far more generally and you still need to be able to recognize in the fluid processing code that there may not be a fluid in a tile.

This is one of the decision points where good engineers go one way and mediocre and bad ones go another. And it is why good engineers are rare. This question also nicely illustrates why software is really hard, even though many people these days seem to mistakenly think software is easy. (Well, many people these days think epidemiology is easy too and that they do understand it, when that is very much not the case. But that is a different discussion.)

 

[psusi]

3 hours ago, Gurgel said:

From my observations, quite a bit or quite high specific heat capacity.

I meant vacuum, not neutronium.

3 hours ago, Gurgel said:

So what to do? The really correct solution would use a "set of all fluids" and a super-set "set of all tings that can be in a tile". The first one would not include vacuum, the second one would. But now you need to handle this far more generally and you still need to be able to recognize in the fluid processing code that there may not be a fluid in a tile.

Good point: tiles can also be solid.  So is vacuum a solid or a liquid or a gas?

 

[Ozcuraz]

1 hour ago, psusi said:

I meant vacuum, not neutronium.

Good point: tiles can also be solid.  So is vacuum a solid or a liquid or a gas?

 

Vacuum is none of the above. It is classified as "Other" under Element Category according to in-game database.

[Gurgel]

1 hour ago, psusi said:

I meant vacuum, not neutronium.

Good point: tiles can also be solid.  So is vacuum a solid or a liquid or a gas?

 

That one is easily fixed! You just add another super-set where things can be solid, liquid, gas and then you add a super-set on top where all elements are tiles, but "not solid, liquid or gas" is also allowed. Now the code needed handling these starts to get interesting

28 minutes ago, Ozcuraz said:

Vacuum is none of the above. It is classified as "Other" under Element Category according to in-game database.

Cheaters! Defining a special case is the _easy_ way out! That is basically on the same level as using a global variable! No self-respecting programmer would ever do that...

[psusi]

28 minutes ago, Gurgel said:

Cheaters! Defining a special case is the _easy_ way out! That is basically on the same level as using a global variable! No self-respecting programmer would ever do that...

Is there another kind of variable?

I'm used to working on embedded systems where your ram is measured in bytes not GB or MB or even usually KB.  I'm a big fan of the KISS principal.  Sure all of that object oriented stuff makes the code more flexible, but it also makes it 10x larger and more complicated, and therefore harder to debug.  I can't stand working on code like that and trying to do something simple but you can't get there from here due to all of the encapsulation so you have to write 3 helper functions, add a few pointers to different structures, and it ends up being 100 lines of code just to call one simple function that may has well have just been a global anyway since the system only needs one "instance".

We had a contractor write a subsystem based on a previous product.  The previous product was a few thousand lines of z80 ASM.  He spent over a year coming up with 12,000 lines of C to re-implement that.  How the heck do you write more loc in C than asm?  Lots of stupid OOP and encapsulation.  The  system needed something like 3 timers for certain events.  Instead of just declaring 3 4 byte integer variables to use as counters, he wrote a good 500 lines of code to be an API just to manage timers, and a 20 byte structure to represent them, and defined an array of 20 of them just in case he wanted to add more timers in the future, so 400 bytes of ram used instead of 12.  Then the code setting, checking, and clearing the timers ended up being like another 100 lines instead of half a dozen.

I had to reduce that bloat by at least 1/3rd before I could even start to debug his problems.  These days the whole thing is under 6kloc, and actually works properly.

[Gurgel]

26 minutes ago, psusi said:

Is there another kind of variable?

I was using hyperbole

If you have a really good reason, global variables are fine and sometimes they are the only good way to do KISS. In those cases you should definitely use them. I mean the global namespace is there for a reason. As it is only one, do not clutter it, but for some things it is simply the best place.

26 minutes ago, psusi said:

 How the heck do you write more loc in C than asm? 

Hahahah, that is "special"! Maybe he got paid by number of LoC delivered?

26 minutes ago, psusi said:

Lots of stupid OOP and encapsulation. 

OOP is just one tool (of many) in the toolbox and if misused or used where it does not offer real, tangible advantages it can (and often does) lead to bloated and unreadable code. There certainly is no value in doing OOP just to do OOP, although tons of younger developers seem to have gotten indoctrinated in this being the only true way. Then they mindlessly follow the ritual.

[Nedix]

Yeah, I'd definitely loved to know coding but last time when I touched this was over 20 yrs ago - it was Turbo Pascal and a little bit of ASM when we studied microprocessors but that's about it. I tried tinkering with C for Arduino but the tutorials are "hey, 1st lesson is Let's light an LED, 2nd lesson is Let's control a rocket".

[Olleus]

11 hours ago, Gurgel said:

From my observations, quite a bit or quite high specific heat capacity.

So, is "not a fluid" actually a fluid? This is a pretty tricky border case and sometimes hard to get right. For example, is NaN a number? For some purposes (calculations) it can be, but it you print it it does something that can be catastrophic: It prints a string of letters "NaN" instead of _digits_, i.e. it violates the spec what a number looks like. Also, is "no car" the type of car you can own? Or is "not ill" your sickness state? 

The underlying issue is what to make your ground set. The choice you have when defining the set of all states A (e.g. fluid type) is to require everything in there to be a fluid (then you get the exception case that something is not a fluid outside of the ground set and you need to go into a fully separate process step/code path to deal with that case) or you add a specific state "not a fluid" which violates that the set of exactly all fluids should of course only contain fluids. There you can mostly keep the regular process steps/code paths, but you need to add "small" exceptions in different places. 

So what to do? The really correct solution would use a "set of all fluids" and a super-set "set of all tings that can be in a tile". The first one would not include vacuum, the second one would. But now you need to handle this far more generally and you still need to be able to recognize in the fluid processing code that there may not be a fluid in a tile.

This is one of the decision points where good engineers go one way and mediocre and bad ones go another. And it is why good engineers are rare. This question also nicely illustrates why software is really hard, even though many people these days seem to mistakenly think software is easy. (Well, many people these days think epidemiology is easy too and that they do understand it, when that is very much not the case. But that is a different discussion.)

 

I'd have a base class "Tile" which is a parent of "Vacuum", "Solid" and "Fluid", the later of which is in turn inherited by "Liquid" and "Gas". Tile has a (virtual) method such as "exchange heat" which is defined to do something meaningful with the "temperature", "mass", and "heat capacity" attributes when inherited by Solid and Fluid. For vacuum, that method does nothing at all, and it doesn't even have those attributes.

What kind of engineer does that make me?

[Gurgel]

1 hour ago, Olleus said:

I'd have a base class "Tile" which is a parent of "Vacuum", "Solid" and "Fluid", the later of which is in turn inherited by "Liquid" and "Gas". Tile has a (virtual) method such as "exchange heat" which is defined to do something meaningful with the "temperature", "mass", and "heat capacity" attributes when inherited by Solid and Fluid. For vacuum, that method does nothing at all, and it doesn't even have those attributes.

What kind of engineer does that make me?

No idea  

You have a bit of a layering issue here, since "Vacuum" is a on the same level as "Solid" and "Fluid", which are sets and not concrete tiles. No idea how much of an issue that is. Depends on the OOP model used, I guess. Unfortunately there are many different ones, both on the modelling side and on the runtime performance side. Also note that the OOP model may or may not have virtual methods and may or may not require object instances to have the same signature for them to be able to interact. The whole thing is a bit of a mess.

[Olleus]

21 minutes ago, Gurgel said:

No idea  

You have a bit of a layering issue here, since "Vacuum" is a on the same level as "Solid" and "Fluid", which are sets and not concrete tiles. No idea how much of an issue that is. Depends on the OOP model used, I guess. Unfortunately there are many different ones, both on the modelling side and on the runtime performance side. Also note that the OOP model may or may not have virtual methods and may or may not require object instances to have the same signature for them to be able to interact. The whole thing is a bit of a mess.

Sure, at the end of the day you can't design an architecture without some insight in how you're going to implement it. But I've just had to deal with the antiquated mess that is MATLAB in the last couple of weeks at work, which makes me deeply miss the wide range of tools I'm used to in Python.

[Gurgel]

33 minutes ago, Olleus said:

Sure, at the end of the day you can't design an architecture without some insight in how you're going to implement it. But I've just had to deal with the antiquated mess that is MATLAB in the last couple of weeks at work, which makes me deeply miss the wide range of tools I'm used to in Python.

I can understand that! I moved to Python for all my glue-code (C modules for heavy lifting if needed) a few years back and even for some shell-scripting replacement. It is a great language.

[psusi]

56 minutes ago, Olleus said:

But I've just had to deal with the antiquated mess that is MATLAB in the last couple of weeks at work, which makes me deeply miss the wide range of tools I'm used to in Python.

I never used matlab, only gnu octave to generate some filter coefficients for some digital signal processing I needed to do.  I'm glad I finally figured out how to actually do DSP since the the theoretical math behind it kind of eludes me.  I keep meaning to learn more python but so far I've just read some of the code of Ubiquity, the Ubuntu installer that is written in it, and found it a very readable language.  I guess I also wrote a simple little tool once in python to use the launchpad API to mass close a thousand bugs related to packages that had been removed from the Ubuntu archive, and I also wrote a little tool once to calculate how orderly the relationship was between the file names and inode numbers in my Maildir and the inode numbers to the actual first block address of the files so I could get an idea of how fragmentation was hurting the performance of my Maildir ( it turned out to be pretty bad ).  That took me a good while to figure out how to write but ended up only being like 100 lines of code, which was pretty cool.