The Flat Earth Society
Flat Earth Discussion Boards => Flat Earth Theory => Topic started by: scomato on January 21, 2021, 04:59:12 PM
-
Nick Bostrom postulates the following, that we are statistically very likely to be living in a computer simulation at this very moment:
Many works of science fiction as well as some forecasts by serious technologists and futurologists predict that enormous amounts of computing power will be available in the future. Let us suppose for a moment that these predictions are correct. One thing that later generations might do with their super-powerful computers is run detailed simulations of their forebears or of people like their forebears. Because their computers would be so powerful, they could run a great many such simulations. Suppose that these simulated people are conscious (as they would be if the simulations were sufficiently fine-grained and if a certain quite widely accepted position in the philosophy of mind is correct). Then it could be the case that the vast majority of minds like ours do not belong to the original race but rather to people simulated by the advanced descendants of an original race.
He concludes:
It is then possible to argue that, if this were the case, we would be rational to think that we are likely among the simulated minds rather than among the original biological ones.
Therefore, if we don't think that we are currently living in a computer simulation, we are not entitled to believe that we will have descendants who will run lots of such simulations of their forebears.
Essentially, if there is even a chance that we will develop supercomputers capable of universal simulation at any point in the future, then chances are that we've already done it and are currently inhabitants of one.
In my view, a Flat Earth is totally plausible under Simulation Theory.
If we are living in a simulation of Earth in the 21st century, it wouldn't be computationally optimal to simulate the whole dang universe. Just a projected texture of a sky like a skybox would do. A flat earth that is infinitely accelerating upwards with a small star and moon, might actually be a computationally simpler task to simulate than a massive object in the distance. All the tricks that game designers use to optimize their games, ie simulations, are in play. Object permanence may be called into question as well.
Simulation Theory would also explain how there are millions if not billions of people unaware of the true nature of the planet. As the human mind would merely be information there is absolutely no limit to how it could be manipulated by higher-order beings.
If we one day also create a universal simulator then we can simply assume that the structure of the multiverse is turtles simulations all the way down.
-
It's an interesting idea, but with a few caveats.
The big one is you can't prove or disprove it. There is no test you can run to determine you are, or are not in a simulation. It's still an interesting idea to ponder.
It also assumes we will survive long enough to create so many simulations, which isn't at all a given considering humanity's track record.
We likely will have better things to calculate than simulating humans in the past, like trying to reverse entropy or halt the expansion of the universe or defend against aliens. I can't imagine simulating humans will be the top priority, although who knows, simulating trillions of people to come up with solutions to problems isn't a terrible idea.
More likely is it's aliens simulating us, trying to decide the best way to deal with such a cranky species and looking for the best outcome.
If we are in a simulation, we are also guessing who or what is simulating us, or what the real universe is like. There is no reason it has to be equal to the one we are living in, perhaps it has no speed of light limits, or has other physical properties that make physical computation much easier. The real universe could be far more complex than we could ever hope to understand with out tiny little simulated minds. Endless possibilities, but no way to ever know.
-
It's an interesting idea, but with a few caveats.
The big one is you can't prove or disprove it. There is no test you can run to determine you are, or are not in a simulation. It's still an interesting idea to ponder.
It also assumes we will survive long enough to create so many simulations, which isn't at all a given considering humanity's track record.
We likely will have better things to calculate than simulating humans in the past, like trying to reverse entropy or halt the expansion of the universe or defend against aliens. I can't imagine simulating humans will be the top priority, although who knows, simulating trillions of people to come up with solutions to problems isn't a terrible idea.
More likely is it's aliens simulating us, trying to decide the best way to deal with such a cranky species and looking for the best outcome.
If we are in a simulation, we are also guessing who or what is simulating us, or what the real universe is like. There is no reason it has to be equal to the one we are living in, perhaps it has no speed of light limits, or has other physical properties that make physical computation much easier. The real universe could be far more complex than we could ever hope to understand with out tiny little simulated minds. Endless possibilities, but no way to ever know.
There is also the problem, that if advanced Simulation-capable beings could produce a localized simulation of the Earth and all its inhabitants, it may be just as trivial for them to simulate a whole round earth, the solar system, and the many galaxies, in all of their glory, including the potentially trillions of other forms of life to emerge and die across the multi-quadrillion year life of the entire universe. There's also no way of knowing if our parent-universe is not also a simulation of another, higher-order parent-universe.
-
I completely agree with everything the original poster said. This is what needs to be discussed more regarding flat earth.
The only part you lose me at is the bit about Earth accelerating upwards infinitely and eternally.
I find it much more plausible that Earth is completely stationary, and all inherent functions of Earth are simply programmed into the simulation..
-
I completely agree with everything the original poster said. This is what needs to be discussed more regarding flat earth.
The only part you lose me at is the bit about Earth accelerating upwards infinitely and eternally.
I find it much more plausible that Earth is completely stationary, and all inherent functions of Earth are simply programmed into the simulation..
Yes, if we go with the 'limited computational resource' model of simulation theory then we could posit that its not necessary for the earth to accelerate to create gravitational effects. A downward force keeping everyone planted on a stationary flat earth is just as well.
-
I completely agree with everything the original poster said. This is what needs to be discussed more regarding flat earth.
The only part you lose me at is the bit about Earth accelerating upwards infinitely and eternally.
I find it much more plausible that Earth is completely stationary, and all inherent functions of Earth are simply programmed into the simulation..
Yes, if we go with the 'limited computational resource' model of simulation theory then we could posit that its not necessary for the earth to accelerate to create gravitational effects. A downward force keeping everyone planted on a stationary flat earth is just as well.
In a computer simulation it is easier to move one object rather than multiple objects.
-
I completely agree with everything the original poster said. This is what needs to be discussed more regarding flat earth.
The only part you lose me at is the bit about Earth accelerating upwards infinitely and eternally.
I find it much more plausible that Earth is completely stationary, and all inherent functions of Earth are simply programmed into the simulation..
Yes, if we go with the 'limited computational resource' model of simulation theory then we could posit that its not necessary for the earth to accelerate to create gravitational effects. A downward force keeping everyone planted on a stationary flat earth is just as well.
In a computer simulation it is easier to move one object rather than multiple objects.
I write computer simulations, so I can say with certainty that this statement is incorrect. If you are talking about the computational difficulty of calculating all the objects on the Earth moving down it due to gravity vs the Earth moving up against all those objects due to UA, the computational load is the same. You still have to perform a calculation between the Earth and every object on it, regardless of which direction you do it from.
-
I write computer simulations, so I can say with certainty that this statement is incorrect.
Please do not refer to yourself as an authority when making arguments. You are an anonymous internet rando with no known credentials.
-
I write computer simulations, so I can say with certainty that this statement is incorrect.
Please do not refer to yourself as an authority when making arguments. You are an anonymous internet rando with no known credentials.
You are free to ignore my self-claimed credentials, but I am also free to make them. But to be nice, here is my comment without them so you may reply to my point.
Your statement is incorrect. If you are talking about the computational difficulty of calculating all the objects on the Earth moving down it due to gravity vs the Earth moving up against all those objects due to UA, the computational load is the same. You still have to perform a calculation between the Earth and every object on it, regardless of which direction you do it from.
-
You still have to perform a calculation between the Earth and every object on it, regardless of which direction you do it from.
What makes you think so?
-
You still have to perform a calculation between the Earth and every object on it, regardless of which direction you do it from.
What makes you think so?
Because you can't tell if an object has hit the ground under it unless you check for a collision between it and the ground, and it doesn't matter if the ground is moving up or the object is moving down. You have to calculate it regardless.
I'll demonstrate. I wrote a very simple simulation that calculate objects falling due to gravity on a round Earth, and objects falling due to a Flat Earth under UA. Take note of the two sections of code that handle either gravity or UA, fall_gravity() and fall_flat(). Notice they are doing the same work, one moves all objects down, one moves all the ground up. Both simulations produce the same result, in the same amount of work.
My code is here, you can run it for yourself to verify. Or you can write one yourself if you think I made a mistake.
https://www.onlinegdb.com/i6JrR6sIp
-
Because you can't tell if an object has hit the ground under it unless you check for a collision between it and the ground, and it doesn't matter if the ground is moving up or the object is moving down. You have to calculate it regardless.
For sure - you'll have to run collision detection just as many times. However, motion itself is vastly simplified - you either update the co-ordinates of everything per tick, or just the co-ordinates of the Earth per tick. I would argue that the for loop in fall_flat() becomes redundant once you design your simulation with efficiency in mind - you don't need to manually raise every part of the Earth (I get why it was convenient for you to do so, especially since you wanted to display your visualisation directly in the console - a neat approach - and that has its own value, but it's neither here nor there when we're discussing potential efficiency), you could treat it as a single object (particularly easily if you chose an OOP language instead of C). Every object maintains a set of co-ordinates, but only the Earth needs to be updated every tick.
You could argue that the time complexity will be O(n) in either case, I guess, but given how large n might be (when it could be 1 instead in optimistic cases), it's still a worthwhile consideration.
In short - it's certainly possible to create a simulation in which both models will be equally inefficient. In your case, this inefficiency came from how you chose to deal with your visualisation. I would consider this the worst-case scenario, in which case the two approaches are indeed nearly equal. Any other case will start winning UA some favour.
EDIT: Actually, why the hell is earth_height an array at all? I do apologise if I'm missing something here, but couldn't you just do https://onlinegdb.com/uJ_6XVm0T (https://onlinegdb.com/uJ_6XVm0T)? It seems to me that even with your implementation of display(), UA can be made to trivially win - the motion becomes O(1) rather than O(n), while collision detection remains identical. By the same token, UA is now significantly winning on space complexity (but that could be fixed for RET in a different context)
-
Because you can't tell if an object has hit the ground under it unless you check for a collision between it and the ground, and it doesn't matter if the ground is moving up or the object is moving down. You have to calculate it regardless.
For sure - you'll have to run collision detection just as many times. However, motion itself is vastly simplified - you either update the co-ordinates of everything per tick, or just the co-ordinates of the Earth per tick. I would argue that the for loop in fall_flat() becomes redundant once you design your simulation with efficiency in mind - you don't need to manually raise every part of the Earth (I get why it was convenient for you to do so, and that has its own value, but it's neither here nor there when we're discussing potential efficiency), you could treat it as a single object (particularly easily if you chose an OOP language instead of C). Every object maintains a set of co-ordinates, but only the Earth needs to be updated every tick.
You could argue that the time complexity will be O(n) in either case, I guess, but given how large n might be (when it could be 1 instead in optimistic cases), it's still a worthwhile consideration.
In short - it's certainly possible to create a simulation in which both models will be equally inefficient. I wouldn't be mentioning that on my resumé if my job was to create good simulations, though.
You can't treat the entire Earth as a single object because it's not a single object. If it was, I couldn't pick up a rock or dig a hole. If the Earth was a featureless, indestructible plane then you could represent it with a single number but it isn't.
If you do decide to treat the Earth as a single, indivisible object then you are changing the conditions of the simulation and it's no longer a valid comparison. I could also do this for the 'gravity' section of the code as well by making all the objects heights just an offset that I can change. Any optimization done to one method can be applied to the other, it's the nature of any problem that is just a mirror image of another.
No programmer would put in their resume that they wrote a simulation that optimized away a huge part of what they were supposed to be simulating. :)
I've refactored more code than I can remember at this point, and the one thing that never changes is there is always a limit to how much work you can save. You can't make computational needs go away. You can remove inefficiencies you added due to mistakes and lack of experience, but the amount of work required is never going to vanish no matter how clever you think you are. And programmers always think they are more clever than they really are, at least until the deadline hits and they have to submit their imperfect code which would have been perfect if they just had another week to work on it. Again.
-
EDIT: Actually, why the hell is earth_height an array at all? I do apologise if I'm missing something here, but couldn't you just do https://onlinegdb.com/uJ_6XVm0T (https://onlinegdb.com/uJ_6XVm0T)? It seems to me that even with your implementation of display(), UA can be made to trivially win - the motion becomes O(1) rather than O(n), while collision detection remains identical. By the same token, UA is now significantly winning on space complexity (but that could be fixed for RET in a different context)
On the off-chance you missed it (wow, you were quick to hit that reply button!). Could you perhaps identify what the issue is with this correction? It seems to work just fine, and greatly reduces the time complexity for one case.
You can't treat the entire Earth as a single object because it's not a single object. If it was, I couldn't pick up a rock or dig a hole. If the Earth was a featureless, indestructible plane then you could represent it with a single number but it isn't.
The shape of the Earth can be trivially represented, and it just goes into collision detection - not motion.
-
EDIT: Actually, why the hell is earth_height an array at all? I do apologise if I'm missing something here, but couldn't you just do https://onlinegdb.com/uJ_6XVm0T (https://onlinegdb.com/uJ_6XVm0T)? It seems to me that even with your implementation of display(), UA can be made to trivially win - the motion becomes O(1) rather than O(n), while collision detection remains identical. By the same token, UA is now significantly winning on space complexity (but that could be fixed for RET in a different context)
On the off-chance you missed it (wow, you were quick to hit that reply button!). Could you perhaps identify what the issue is with this correction? It seems to work just fine, and greatly reduces the time complexity for one case.
You can't treat the entire Earth as a single object because it's not a single object. If it was, I couldn't pick up a rock or dig a hole. If the Earth was a featureless, indestructible plane then you could represent it with a single number but it isn't.
The shape of the Earth can be trivially represented, and it just goes into collision detection - not motion.
Taking 18 minutes to reply isn't THAT quick, you just replied to me in 5. :)
I did not see your link because I started writing my reply before you changed your post to add the code and new comments.
The reason earth_height is an array is because the Earth is not a single object. As I stated in my first reply, that's an additional simplification of just one of the methods, and the Earth is not a solid, single object. If I can represent the earth with a simple number, I could change the fall_gravity function to just use an index too, and once more make both methods equal.
Here is another modification that demonstrates it better, giving the Earth a more 'realistic' shape to show the side of a hill. All it does is add a slope to the ground (i/13), which I should have done to start with but was lazy. (I also never initialized that array in my first example, oops.)
https://onlinegdb.com/EQbYeHD_M
-
Taking 18 minutes to reply isn't THAT quick, you just replied to me in 5. :)
You must have hit the quote button within 30 seconds of me posting, since your quote did not include even my first edit - that's where the fast fingers are rather apparent.
I did not see your link because I started writing my reply before you changed your post to add the code and new comments.
Yes. See above.
The reason earth_height is an array is because the Earth is not a single object.
I dispute this, as will just about anyone who wrote code since the advent of OOP. Again, your choice of language for this purpose is peculiar, and very unhelpful (I mean, you could reproduce it all with a few structs, but do you really hate yourself that much?). The Earth can absolutely be represented as a single object. Remember, we're meant to be aiming for efficiency, and you're currently going out of your way to be inefficient.
As I stated in my first reply, that's an additional simplification of just one of the methods, and the Earth is not a solid, single object. If I can represent the earth with a simple number, I could change the fall_gravity function to just use an index too, and once more make both methods equal.
This is laughably incorrect. The height of the objects relative to the Earth (or, indeed, relative to the simulation's "objective" co-ordinate set) is not going to be uniform for a random smattering of falling objects.
Here is another modification that demonstrates it better, giving the Earth a more 'realistic' shape to show the side of a hill.
I already addressed this. The shape of the Earth can be represented separately from its motion, and this approach makes collision detection much simpler, too. You do not need to manually move every part of it. Imagine a higher-resolution approximation, rather than a few ASCII characters. Imagine physics simulations or video games actually tried to calculate the physics of every 1x1x1 voxel (or every pixel, if you'd rather stick to 2D), rather than objects as a whole. Complete and utter insanity!
Tom was spot-on in questioning your credentials - you can just about write code that compiles and runs (albeit with some extremely unusual stylistic choices), but this is clearly your first attempt at optimising anything for computational complexity.
-
The reason earth_height is an array is because the Earth is not a single object.
I dispute this, as will just about anyone who wrote code since the advent of OOP. Again, your choice of language for this purpose is peculiar, and very unhelpful (I mean, you could reproduce it all with a few structs, but do you really hate yourself that much?). The Earth can absolutely be represented as a single object. Remember, we're meant to be aiming for efficiency, and you're currently going out of your way to be inefficient.
I think you misunderstood the use of object in this context. I am not talking about the Earth being an OOP object.
I am saying the Earth is not a single solid mass that can be represented with a single number for it's position, it has hills and bumps which need to respond to either gravity or upward acceleration. It has mountains and valleys, it's not perfectly flat.
Yes you can optimize that by adding offsets and indexes but you can do the same for the gravity version as well, having the Earth move instead of the objects move doesn't save you anything. Same complexity either way.
I wasn't aiming at all for efficiency or trying in the slightest to optimize, I was aiming for a simple quick and dirty example of how simulating two groups of objects moving together is the same complexity no matter which set you define as moving and which is at rest. Standard C is about as close to pseudocode as you can get, I was going for simple and understandable, not some overly complicated object oriented system with overloads and inheritance or even structures which are simply not needed for such a simple concept.
Tom was spot-on in questioning your credentials - you can just about write code that compiles and runs (albeit with some extremely unusual stylistic choices), but this is clearly your first attempt at optimising anything for computational complexity.
If you want to attack me personally we can continue this in AR where I'm able to respond freely.
-
I think you misunderstood the use of object in this context. I am not talking about the Earth being an OOP object.
I am saying the Earth is not a single solid mass that can be represented with a single number for it's position, it has hills and bumps which need to respond to either gravity or upward acceleration. It has mountains and valleys, it's not perfectly flat.
I understood you, and I already addressed your issue twice. By following the basic design patterns involved in anything that requires this type of collision detection, we can represent the shapes of objects separately from their position. OOP just happens to be a convenient abstraction for that, and you've made your task harder for yourself by shying away from it.
Yes you can optimize that by adding offsets and indexes but you can do the same for the gravity version as well, having the Earth move instead of the objects move doesn't save you anything. Same complexity either way.
Not the case. The moment you represent the Earth as a single object (via trivial abstraction explained in previous posts) you've reduced complexity from O(n) to O(1). Something you can only accomplish with one model, and not the other (unless you choose to abstract RE gravitation as UA, of course). This becomes much more significant when you factor in acceleration - your complexity grows even further, while the correct implementation remains nice and steady.
I wasn't aiming at all for efficiency or trying in the slightest to optimize
I take no responsibility for you making an argument about efficiency while forgetting to be efficient in the substantiation of your argument. I also dare suggest that you weren't quite so aloof. You thought you were making a good argument about efficiency, but your programming was not up to scratch.
If you want to attack me personally we can continue this in AR where I'm able to respond freely.
If you cannot stand an assessment of your ability without perceiving it as a personal attack, do not present yourself as an expert in a field you're obviously an amateur at. Any "wowzers, write your first platformer!" tutorial would have taught you enough about collision detection to avoid the mistakes you've made here. Really, you shouldn't blame an educator for marking your work - it's just in my nature.
-
The moment you represent the Earth as a single object (via trivial abstraction explained in previous posts) you've reduced complexity from O(n) to O(1).
This would only be true if simple collision mechanism is used, e.g. collision calculated based on a spherical hull or a bounding box like it is done in many gaming engines. As soon as the precise shape of the object needs to be considered (e.g. terrain), the position for any point of earth must be known.
Therefor usually first the position of the (center of the) object and the orientation is calculated and then the positions for the whole surface are calculated relative to the center - which ends in O(n).
But maybe I just don't know how "trivial abstraction" works for complex shapes ;-)
For having a moving and accelerated earth you also would need an big enough (endless!?) vector space ("outer world") where the object is moved in, or you permanently adjust it to the center, which would be the same as static.
But anyway, this is based on our current technology and that's far away from doing such a simulation and we don't know which algorithm works best for future technologies. If earth could be modeled as some kind of "quantum object" (whatever this might be), then probably Peters assumption could be correct.
-
This would only be true if simple collision mechanism is used, e.g. collision calculated based on a spherical hull like it is done in many gaming engines. As soon as the precise shape of the object needs to be considered (e.g. terrain), the position for any point of earth must be known.
Therefor usually first the position of the (center of the) object and the orientation is calculated and then the positions for the whole surface are calculated relative to the center - which ends in O(n).
Re-read the argument that's being made. I already pointed out several times that the complexity of collision detection would remain the same (in each case, you'd have to consider the distance between your object and the Earth, paying attention to their shapes, rotation, etc.) - it's the complexity of motion where enormous savings can be made - both in terms of time and space.
But maybe I just don't know how "trivial abstraction" works for complex shapes ;-)
No, you just hyperfocused on replying without processing what you're replying to. You're also the victim of an oversimplified example, but I don't want to hammer JSS for making it simple too much. Once you consider things like parallelisation, the efficiency rift becomes even larger.
For having a moving and accelerated earth you also would need an big enough (endless!?) vector space ("outer world") where the object is moved in, or you permanently adjust it to the center, which would be the same as static.
Neither of those are necessary - all you need to do is periodically reset your co-ordinate system.
But anyway, this is based on our current technology and that's far away from doing such a simulation and we don't know which algorithm works best for future technologies. If earth could be modeled as some kind of "quantum object" (whatever this might be), then probably Peters assumption could be correct.
I'm happy to accept an "I don't know" position. However, given everything we know about time complexity, space complexity, and our state-of-the-art algorithms, RET's case for being more efficient is non-existent. Of course, needlessly overcomplicating things is also the nature of modern programmers - perhaps our simulation overlords share a culture of "move fast and break things"?
-
Re-read the argument that's being made. I already pointed out several times that the complexity of collision detection would remain the same (in each case, you'd have to consider the distance between your object and the Earth, paying attention to their shapes, rotation, etc.) - it's the complexity of motion where enormous savings can be made - both in terms of time and space.
If you move a complex object, every point of this object is in a different position after the movement, so every point needs to be updated.
This can be either done by ...
... either calculate each point separately (unusual but maybe more efficient for FE simulation because for each time slice it is the same value added to the z axis for each point).
... or calculate the center and orientation of the object and derive other points from it.
The only difference is where the movement for each point is handled - either by the moving function or by the collision detection function.
It's just a shift of the effort from one place to the other but it does not reduce it.
No, you just hyperfocused on replying without processing what you're replying to. You're also the victim of an oversimplified example, but I don't want to hammer JSS for making it simple too much. Once you consider things like parallelisation, the efficiency rift becomes even larger.
That's a (quite common) misconception of parallelism. Parallelism can make things faster, if it is well implemented. But parallelism makes an algorithm never more efficient (which would be less computing power for same result), it adds more overhead complexity.
This might change with quantum computers - but this will also change the algorithm in a way which makes this discussion obsolete.
Neither of those are necessary - all you need to do is periodically reset your co-ordinate system.
Which is the less smart version of "permanently adjust it to the center".
However, given everything we know about time complexity, space complexity, and our state-of-the-art algorithms, RET's case for being more efficient is non-existent.
I would not even dare to guess which one is more complex.
-
The only difference is where the movement for each point is handled - either by the moving function or by the collision detection function.
It's just a shift of the effort from one place to the other but it does not reduce it.
I can see why you'd intuitively perceive it that way, but it's incorrect - handling it in motion needlessly duplicates near-identical calculations, since collision detection will have to transpose those points into relative co-ordinates for the second time.
That's a (quite common) misconception of parallelism. Parallelism can make things faster, if it is well implemented. But parallelism makes an algorithm never more efficient (which would be less computing power for same result), it adds more overhead complexity.
Once again, you are missing the point of what I said. I did not say that parallelisation would make an algorithm more efficient (I was talking to a person who clearly can write some code - it was my hope I wouldn't need to waste my time detailing the basics). I said that the complexity rift between a parallelised version of the RE model and a parallelised version of the FE model would be even more egregious than that between their single-threaded equivalents.
Which is the less smart version of "permanently adjust it to the center".
If you consider optimisation "not smart", then we can't have a meaningful argument about optimisation, as I'm sure you'll agree. Redundantly repeating an operation every tick is less efficient than only executing it when needed (in general - I'm sure you could find exceptions).
I would not even dare to guess which one is more complex.
Why are you arguing a position you would not even dare to guess, especially with such fervour? Seems counter-productive.
-
I can see why you'd intuitively perceive it that way, but it's incorrect - handling it in motion needlessly duplicates near-identical calculations, since collision detection will have to transpose those points into relative co-ordinates for the second time.
The point is that you do not need to move and/or transpose the points if you keep the earth object static relative to the vector space. So it's not about having one or two transformations (which is question of optimization) but zero. The "points" of the earth object need only to be updated when the shape (terrain) changes, otherwise they are fixed within the coordinate system.
Same is true for all other objects which are standing stable on earth, they can be treated as static until any other force than UA impacts them.
However, as you already pointed out, this approach of simulation (collision of meshes) would be far to simple for a simulated earth as we observe it - regardless of its shape.
Why are you arguing a position you would not even dare to guess, especially with such fervour? Seems counter-productive.
I stepped into the argumentation whether it is more efficient to keep earth static relative to the vector space or not - and I'm convinced static would be less complex (based on current techniques).
I think we don't have sufficient knowledge to judge the complexity of a earth simulation, regardless if it is flat or round, so I don't even try to compare FE vs RE in this context.
-
I agree with forty-two: any simulation on the scale of the one being discussed is just completely beyond our current abilities, and it's likely meaningless for us to judge it based on current methods of computation. I'd also likely want to point out that if a concerned party was interested in creating an optimized scenario, they would probably look to other things for optimization, like giving us less cells, or making hairs larger. There are quite a few things that could be optimized with a much smaller effect.
-
The point is that you do not need to move and/or transpose the points if you keep the earth object static relative to the vector space. So it's not about having one or two transformations (which is question of optimization) but zero. The "points" of the earth object need only to be updated when the shape (terrain) changes, otherwise they are fixed within the coordinate system.
??? You just moved your inefficiency around - you didn't address it at all.
I stepped into the argumentation whether it is more efficient to keep earth static relative to the vector space or not - and I'm convinced static would be less complex (based on current techniques).
Well, I can do nothing more than explain why that's incorrect. I guess we'll just have to agree to disagree, and the field of computing is going to continue not to care about our disagreement.
-
I agree with forty-two: any simulation on the scale of the one being discussed is just completely beyond our current abilities, and it's likely meaningless for us to judge it based on current methods of computation. I'd also likely want to point out that if a concerned party was interested in creating an optimized scenario, they would probably look to other things for optimization, like giving us less cells, or making hairs larger. There are quite a few things that could be optimized with a much smaller effect.
The thing about simulations is you don't have to simulate it all. It doesn't actually matter where all your cells are until a doctor takes a sample. The program can just abstract it all away, and when you get a blood sample and it gets put into a machine, it can just look up your 'stats' and throw the right numbers onto the display. Details don't need to be calculated until we look at them. The computer can just make things up as needed.
On a deeper level, you don't even need to 'render' much of the universe, even when people are looking right at it. Just inject it right into our consciousness. The structures in out brains that remember things are all very self referential, you don't need to draw a complicated object, just put the idea of that object into a persons head.
If I dump a bucket of marbles down a deep well with my eyes closed, the computer wouldn't even need to simulate that. Some random marble noises is all it needs. If I walked away and the well collapsed a year later and nobody ever dug it up, the computer just has to store that a bunch of marbles were dropped in, just in case someone does eventually dig there. Even then, if it's 200 years later and no records exist of those marbles it can just delete them entirely. Who would notice?
-
I think we don't have sufficient knowledge to judge the complexity of a earth simulation, regardless if it is flat or round, so I don't even try to compare FE vs RE in this context.
Considering the fact that the external universe doesn't have to follow our laws, it's completely pointless to even try and guess what their capabilities are.
If the entire universe is simulated then we have zero data to go on, it's all guessing and making stuff up.
Fun, but ultimately pointless.