Sounds like a quantum effect to me ...[ . . . ]
you're in jump space for a week and come out some integer number of parsecs away (up to six, depending on how deep a hole you can punch in spacetime).
Sounds like a quantum effect to me ...[ . . . ]
you're in jump space for a week and come out some integer number of parsecs away (up to six, depending on how deep a hole you can punch in spacetime).
I am going to have to interpret most of the recent posts as a “NO” vote for the OP suggestion on ‘embracing retro computers’. :rofl:
And never underestimate the incompetence of programmers...
(speaking as a developer for the last 30+ years...)
And never underestimate the incompetence of programmers...
(speaking as a developer for the last 30+ years...)
Quite. You may now get off OP's lawn.Our FEM work was designed to run on a Cray X-MP? We compiled BRL-CAD on a Dec 11/780 named "VGR," for benchmarking. That's retro, right?
One idea I've been kicking around is that Jump space fries your iPad, but a fill-the-room 1960s transistorized computer can hack it just fine (doesn't care about the exotic radiations). The higher-end computers are bigger than a Stateroom.If it's supposed to be 2200 AD and we're still spinning up platters on room-sized mainframes that can barely handle basic ship operations, then I get bored. I know what my iPhone can handle.
One idea I've been kicking around is that Jump space fries your iPad, but a fill-the-room 1960s transistorized computer can hack it just fine (doesn't care about the exotic radiations). The higher-end computers are bigger than a Stateroom.
I haven't decided if I want to say "Put your iPad in a magnetic-bubble suitcase and it will be fine upon landing" because the retort is "Why not put the Ship's iPad in the suitcase?"
This also opens up the problem that TL8 is better equipped to casually J-Drive than TL15. And a TL6 vacuum-tube-and-power-cords design might be the ultimate Jump-resistant computer.
Nope. We know, at the end of the week, whether we've successfully written the code. Any problems the show up are secondary to whether the code works for the general case.What does that have to do with it? We will not know for sure if the generated jump space solution is good until we have used it to jump a few times.
Yes. Again, it is a program that can be successfully written in a week, with a smidgeon of luck. The math must be at least somewhat simple for that to be true. It may not be that well known. Maybe everybody learns a simplified method, but only the real die-hards stick on it long enough (Nav-4) to learn the third-order, as close to exact as we get, solution.Is Jump Space simple and well-known maths? I believe not. If it's a trivial well-known problem why do we need Nav-4 skill?
Probably so in many ways. One seeks to model a chaotic fluid/plasma as it expands and responds to magnetic field variations and stuff. It's done with repeated iterations, some kind of Monte Carlo simulation. The other doesn't need a huge FE mesh and matrix.So, is a physics problem (flares) that took a few months to model and code vastly different from a physics problem (jump space flight plan) that on average takes a month or two to model and code?
Who says the spec is wrong? I'm just pointing out that debugging is debugging, whether you end up replacing one argument in one line of code, or write an entirely new bunch of code.If you have to write new code because the specification is wrong is not what I would call debugging.
No, it's a bad mechanic if it models the problem incorrectly. If it doesn't properly reflect the amount of code necessary.[Checking for success each week] is a simplified game mechanic, just like that we only roll one attack roll every 1000 s in space combat.
That could be the problem if the writer or writing team don't get the roll in their favor. It doesn't matter, they still have a chance to figure it out by the end of the next week.What does it matter if we use well-tested math libs if we apply them incorrectly to a physics problem?
We are writing our own code so we can sell it for far less than the kCr800 the big boys are asking. Or we are expanding our business with a second ship. If some security measure doesn't let you copy the whole program then you write your own.If we already have Generate why would we want to write Generate? It can hardly be assumed that we already have software we are trying to write?
True, the decompiled code will seem messy compared to a well documented lib. Many professional libs aren't well documented beyond decribing the proper input parameters.Reverse engineering compiled code is very far from using well documented libs.
The '77 edition programming rules are in JTAS1, as Mike pointed out. The roll to succeed is 12+ and the minimum time is at least two months + a week.In the '77 LBB1 note on the Computer Skill, it says DM +1 per level of expertise (but no table with the required expertise and success throw is in LBB2).
Or our assumptions are wrong. Or our design is wrong. Or the program calculates wrong when jumping to an M3 star with exactly two gas giants because of numeric cancellation.I think a 1/12 chance for a bug so cleverly hidden that no amount of debugging can find it, but it will show up when the program is run under pressure of combat, means both human guided and auto debuggers are crap.
How would you know?If there's a bug it could show up any time.
Nope, we believe the code works when we have succeeded on the roll. Critical Flaws may still exist.Nope. We know, at the end of the week, whether we've successfully written the code. Any problems the show up are secondary to whether the code works for the general case.
Again, it generally takes extremely skilled people a month or two on average. Why would it take months if it was so trivial?Yes. Again, it is a program that can be successfully written in a week, with a smidgeon of luck.
Possibly, or possibly not, we don't know. All we know is that we absolutely need a post-doc specialist to handle it. That does not spell trivial to me.The math must be at least somewhat simple for that to be true. It may not be that well known. Maybe everybody learns a simplified method, but only the real die-hards stick on it long enough (Nav-4) to learn the third-order, as close to exact as we get, solution.
Who knows how jump space is modelled? Both are computerised simulations of mathematical models of physical reality.Probably so in many ways. One seeks to model a chaotic fluid/plasma as it expands and responds to magnetic field variations and stuff. It's done with repeated iterations, some kind of Monte Carlo simulation. The other doesn't need a huge FE mesh and matrix.
The context seems to be lost. You seem to consider any activity after the first week debugging. I was merely pointing out that other problems were possible.Who says the spec is wrong?
I would only call it debugging if it involved finding the exact flaw in the code and fixing it.I'm just pointing out that debugging is debugging, whether you end up replacing one argument in one line of code, or write an entirely new bunch of code.
It's a game. It's even one of the fist wave of role playing games written by minimal staff in the seventies, when programming was even less generally understood by most people.No, it's a bad mechanic if it models the problem incorrectly.
So you agree that we can still produce flawed models or code, even when using well-tested libs?That could be the problem if the writer or writing team don't get the roll in their favor. It doesn't matter, they still have a chance to figure it out by the end of the next week.
Ok, agreed, in such special circumstances we have the software to test against.We are writing our own code so we can sell it for far less than the kCr800 the big boys are asking. Or we are expanding our business with a second ship. If some security measure doesn't let you copy the whole program then you write your own.
So you agree that trying to make sense of decompiled code is much more difficult and time consuming than using well documented libs?True, the decompiled code will seem messy compared to a well documented lib. Many professional libs aren't well documented beyond decribing the proper input parameters.
If you've never seen it, you would be amazed at just how much the optimiser butchers code. Back in the Jurassic, many older compilers would give you pretty deterministic output and you could hold a mental model of what certain statements would compile to.[ . . . ]
So you agree that trying to make sense of decompiled code is much more difficult and time consuming than using well documented libs?