raptop changed the topic of #principia to: READ THE FAQ: http://goo.gl/gMZF9H; The current version is Fréchet. We currently target 1.5.1, 1.6.1, and 1.7.x. <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/ | <egg> calculating the influence of lamont on Pluto is a bit silly… | <egg> also 4e16 m * 2^-52 is uncomfortably large
<discord-> G​ot. — Yeah, the problem is not orbit mechanism.
<discord-> G​ot. — In stock systems I think the most obvious inaccuracies will be for the comms network, thermal calcs and solar panel output.
<discord-> G​ot. — But TBH, those problems appear as soon as the timestep gets higher than 20-30% of the fastest involved vessel orbit period.
<discord-> G​ot. — For a vessel in LEO orbit, that mean at ~15/30 min timestep, about 100 000x timewarp speed
<discord-> e​gg. — > the problem is not orbit mechanism
<discord-> e​gg. — Well, precessions can be quite fast
<discord-> e​gg. — (but again, we should have an API anyway, so this will resolve itself eventually)
<discord-> e​gg. — note that @Sir Mortimer’s solution is "use the `Orbit` to figure out where the vessel was between game frames", so it is by definition correct in stock (and has whatever resolution he wants)
<discord-> G​ot. — Yep, I agree, but there is a point where we will hit a brick wall in terms of processing power.
<discord-> G​ot. — In the end, if you do large steps but then repeat most of the calculations you are doing in it in hundreds of substeps, that becomes quite counter-productive.
<discord-> G​ot. — You would just be better by not doing the large main steps in the first place...
<discord-> G​ot. — Unless you are doing calculations that can be considered to stay approximately true over the course of several orbits.
<discord-> G​ot. — In that case, you do them for a single orbit period and use them as an analytical result, and update them continuously in a separate thread as frequently as your processing power allow.
<discord-> G​ot. — This way, at high timewarp speeds, you get a less precise simulation, but at least not a totally random one.
<discord-> G​ot. — Of course, that much easier said than done 😛
<discord-> e​gg. — eh
<discord-> e​gg. — there can be quite a bit of margin, depending on how fast you make the check
<discord-> e​gg. — and then we can try to be smart and think about continuity and interpolation
<discord-> e​gg. — instead of discrete checks
<discord-> e​gg. — but also, it’s OK to reach a brick wall !
<discord-> e​gg. — it’s fine !
<discord-> e​gg. — Principia has that
<discord-> e​gg. — if you warp too fast, I will eat your CPU
<discord-> e​gg. — because I just do the same calculation faster, I don’t really have a choice
<discord-> e​gg. — and eventually I run out of room to make it faster, and that is fine
<discord-> G​ot. — Well, depending on what you do, the brick wall can comes quite early...
<discord-> G​ot. — Imagine if we were enforcing proper (read accurate) body occlusion checking for the whole comms network...
<discord-> e​gg. — yeah, we might need to be a little bit smart
<discord-> e​gg. — the obvious thing would be to use an adaptive stepsize for instance
<discord-> e​gg. — if you can express your condition as f(t) > 0, you can tune the step at which you evaluate f based on f′, and find where f crosses 0 either way
<discord-> e​gg. — plenty of classic techniques to deal with that
<discord-> e​gg. — but as a point of comparison, Principia with RSS works with a 10 s stepsize
<discord-> e​gg. — and for every LEO sat, every 10 s, it will compute the gravitational attraction from all planets + the full extended-body gravitational field of the Earth (degree and order 10)
<discord-> P​teropodidae. — @egg: Just curious, have you tried the coz profiler on Principia?
<discord-> e​gg. — we have benchmarking, we know where we spend time
<discord-> e​gg. — the issue isn’t so much finding that out as knowing what to do about it, programming smartness doesn’t materially change much here
<discord-> P​teropodidae. — Yeah, I saw the benchmarks
<discord-> P​teropodidae. — Well, the benchmarking code
<discord-> P​teropodidae. — Coz just claims to look at things a bit differently and so can find hot spots traditional profilers miss
<discord-> P​teropodidae. — But as you said, if you already know where the hot spots are then that won't help much
<discord-> e​gg. — yeah most nontrivial performance improvements are « rewrite the thing with a completely different approach over the next year » at this point  :-p
<discord-> P​teropodidae. — rip
<discord-> P​teropodidae. — Do you run benchmarks on Windows only? Or do you support running them on all platforms?
<discord-> e​gg. — in theory they should work on other platforms, but again this is mostly irrelevant
<discord-> e​gg. — what matters is what kind of integration method you use, not whether the assignment gets hoisted out of the loop
<discord-> P​teropodidae. — That's fair
<discord-> P​teropodidae. — And the integration method is tightly controlled to avoid floating-point errors, right?
<discord-> e​gg. — > floating-point errors
<discord-> e​gg. — asdfghjkl point-virgule apostrophe
<discord-> e​gg. — while properly handling floating point arithmetic is a concern when implementing an integrator, what dominates unless you screw up is *truncation error*
<discord-> e​gg. — i.e., the error due to the finite step size
<discord-> P​teropodidae. — Sorry, sorry
<discord-> P​teropodidae. — Not my area of expertise 😦
<discord-> e​gg. — (if you do screw up you can get roundoff accumulation piling up and dwarfing everything, but a properly-written integrator has an error that is basically the same as it would have if you had infinite precision)
<kmath> <eggleroy> Double-double sum vs. ill-conditioned compensated summation in multistep integrators: hitting the floor vs. going u… https://t.co/0C7k1P7sUm
<discord-> P​teropodidae. — This is definitely way above my pay grade
Wetmelon has quit [Ping timeout: 189 seconds]
<discord-> G​ot. — Yup, there are probably (too clever for me) solutions for all those problems :)
<discord-> G​ot. — This said, it seems to me that in a lot of situations you just can't predict f(t) or find a good enough analytical first estimation...
<discord-> G​ot. — For example, in the context of kerbalism radiation, I fail to see any way to predict if and for how long you're going to pass trough a radiation belt for any given orbit.
<discord-> G​ot. — in the end discrete fixed timestep evaluation has the advantage of being able to catch everything at once.
<discord-> G​ot. — Again in kerbalism, apart from the well known sunlight/shadow evaluation issue, there is also thermal and radiation impact from surrounding bodies, belts radiation, time spent in various situations (belts, biomes passed over...)
<discord-> G​ot. — Seems to me that evaluating from another thread a fixed-step per-vessel-orbit dataset for all that would allow to get reasonable approximations (which would anyway be better that the random data we currently use), with a fixed performance overhead regardless of timewarp speed.
Wetmelon has joined #principia
<discord-> e​gg. — yeah but it gets really hard to avoid correlations with periodic orbits
<discord-> e​gg. — it should not be that hard to find transitions in and out of the shade, for instance
<discord-> e​gg. — you do have to walk along the orbit with a sufficiently small timestep that you don’t miss it entirely
<discord-> e​gg. — but « sufficiently small » here is pretty big
<discord-> G​ot. — > it gets really hard to avoid correlations with periodic orbits
<discord-> G​ot. — Not sure I follow ?
<discord-> e​gg. — sample every 3600 s on a 3601 s orbit, you will think that it spends many hours in the shade
<discord-> e​gg. — but actually it was basking in the sun every hour
<discord-> e​gg. — ah,
<discord-> e​gg. — > per-vessel-orbit
<discord-> e​gg. — hm
<discord-> G​ot. — ha, ok, well in any case I was thinking quite small steps, probably in the minute range.
<discord-> G​ot. — Since that method involve having a thread dedicated to continuously crunching that data, I'm guessing we could go pretty low.
<discord-> G​ot. — Since in the end, you just loose precision by having the data of orbit n-x being used for orbit x
<discord-> G​ot. — But I guess you can scale down based on the the vessel orbital period ?
<discord-> e​gg. — I really dislike the idea of aiming for a fixed perf. overhead regardless of timewarp speed
<discord-> e​gg. — because it makes thing exceedingly hard to debug
<discord-> e​gg. — or to reproduce
<discord-> e​gg. — things end up depending on the way people timewarped
<discord-> e​gg. — and again, all of these calculations can be done pretty cheap
<discord-> G​ot. — Well, I don't say it's ideal. I say it would be better than what we are currently doing, which is complete random garbage
<discord-> e​gg. — yeah, random garbage is not great
<discord-> e​gg. — horribly slow is not great, but at least it is reproducible :-p
<discord-> e​gg. — and smart enough to not grind things to a halt should be feasible
<discord-> G​ot. — > all of these calculations can be done pretty cheap
<discord-> G​ot. — well, it make sense from your C++ magician and advanced math aware POV :P
<discord-> G​ot. — In my case, for the few substepping experiments I made, just trying to get sun occlusion and thermal data was putting KSP to a standstill.
<discord-> e​gg. — at what stepsize
<discord-> G​ot. — something like one minute
<discord-> e​gg. — how are you implementing the occlusion?
<discord-> G​ot. — basic sphere-ray vector math. but that part was quite fast, it was more the thermal calcs.
<discord-> G​ot. — Getting the positions of everything at a given UT is quite fast using the KSP methods, but in the end it adds up too...
<discord-> G​ot. — And I was probably doing all that in suboptimal data structures too...
<discord-> G​ot. — But the real issues were when I tried to get the biome passed over.
<discord-> G​ot. — Anyway i remember ending in the 100ms+ range for substepping at max stock timwarp speed
<discord-> e​gg. — something sounds horribly wrong if doing O(number of vessels) calculations at a 1 min step is too slow
<discord-> e​gg. — considering that Principia does that at 10 s
<discord-> e​gg. — (with some nontrivial calculations as well)
<discord-> e​gg. — if you do something part-level you might have a bad time
<discord-> e​gg. — (assuming that you have ~100 parts per vessels, ballpark)
<discord-> e​gg. — (assuming that you have ~100 parts per vessel, ballpark) (edited)
<discord-> D​RVeyl. — For reference, there's a built-in occlusion check call in stock CommNet. Each body registers an Occluder, tests if a ray from A to B hits one or not.
<discord-> G​ot. — Honestly I don't really remember what I was doing, but no there wasn't any partcount dependant calcs.
<discord-> G​ot. — I think it was more or less acceptable until I added the biomes getting part
<discord-> e​gg. — yeah that might get nasty
<discord-> e​gg. — or s/might/definitely will/ :-p
<discord-> D​RVeyl. — What, not fun describing the ground track? 😉
<discord-> e​gg. — the biomes have horrible horrible shapes that you can't really do maths to
<discord-> D​RVeyl. — Also that.
<discord-> D​RVeyl. — (Ground track probably isn't bad, you have the body position and orientation and vessel position.)
<discord-> e​gg. — yeah ground track, or azimuth/elevation from a point on the surface, etc., all of that should be cheap
<discord-> e​gg. — actually looking at a biome map, nope
<discord-> D​RVeyl. — Hm. Actually, wonder if you can do edge detection on it, then turn those into more reasonably-shaped closed polygons.
<discord-> G​ot. — Yeah, I remember copy-pasting the biome getting code to try to optimize it a bit, but there is no way around it, you just have to iterate over the huge image array
<discord-> e​gg. — yeah that is death incarnate
<discord-> D​RVeyl. — But it doesn't change. You should only need to iterate over it once. Am I wrong that it should reduce to closed shapes?
<discord-> e​gg. — @DRVeyl either polygons or circles, if you can admit overlapping boundaries
<discord-> e​gg. — circles are cones in the context of "over a biome" which is really nice to work with
<discord-> e​gg. — though covering the biome with circles might be a bit too interesting
<discord-> e​gg. — why is it 3:30
<discord-> G​ot. — Yeah, we should definitely go to sleep
<discord-> e​gg. — well, you should pump
<discord-> e​gg. — while sleeping
<discord-> G​ot. — the pump is specially conceived, I only have to dream that I'm pumping 🙂
<discord-> G​ot. — So, good night folks, interesting discussion over here, as always
<discord-> e​gg. — (hm, cones are nice for "over a biome" but what if you want "seeing a biome at an elevation greater than x")
<discord-> D​RVeyl. — I think that is just a cone with a shifted apex.
Wetmelon has quit [Ping timeout: 204 seconds]
<discord-> e​gg. — probably
<discord-> e​gg. — though then you need some design thinking around whether you care about seeing the biome at that elevation, or seeing the biome cross-track within the swatch at that elevation, etc., etc.
<discord-> e​gg. — though then you need some design thinking around whether you care about seeing the biome at that elevation, or seeing the biome cross-track within the swath at that elevation, etc., etc. (edited)
Wetmelon has joined #principia
<discord-> e​gg. — getting quite foggy here
<discord-> e​gg. — wasn't I supposed to sleep
<discord-> D​RVeyl. — Yes, you were. (Nite!)
<discord-> e​gg. — 🥚💤
egg|laptop|egg has joined #principia
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #principia
<discord-> P​teropodidae. — egg, just to make sure I'm understanding the plots you linked earlier
<discord-> P​teropodidae. — Those show how error decreases as iterations per step increase?
<discord-> P​teropodidae. — Er
<discord-> P​teropodidae. — Never mind, apparently he's sleeping
<discord-> P​teropodidae. — Er, slight correction to my earlier question
<discord-> P​teropodidae. — Actually, never mind
<discord-> P​teropodidae. — I think I get it
<discord-> P​teropodidae. — The roundoffs mentioned there are the floating-point errors I originally mentioned as opposed to truncation error?
<discord-> P​teropodidae. — And ill-conditioned means the relative error is large?
* discord- P​teropodidae. — regrets not taking a numerical analysis class when the opportunity was available_
<discord-> e​gg. — I suggest googling, it will be quicker than waiting for me to be awake https://en.wikipedia.org/wiki/Condition_number
<discord-> P​teropodidae. — Part of it is I'm never confident that I'm googling the right things
<discord-> P​teropodidae. — And because I'm trying to link it to my original wording, which may or may not have been correct
<discord-> P​teropodidae. — Thanks though
<discord-> e​gg. — "floating-point error" is nonspecific and typically not a very useful term
<discord-> e​gg. — (and all too often it means "error analysis is hard but floating point arithmetic is a good bogeyman")
<discord-> A​cer_Saccharum. — unless you're doing something really weird floating point errors shouldn't be the issue
<discord-> e​gg. — well
<discord-> e​gg. — there are *many* places in Principia where we have to do careful things to avoid issues of that sort
<discord-> e​gg. — arguably Principia is really weird
<discord-> A​cer_Saccharum. — I wouldn't dispute that at all
<discord-> e​gg. — but error analysis is important
<discord-> A​cer_Saccharum. — at least you can generally engineer your way around floating point errors, whereas other errors have a more mathematical basis
<discord-> e​gg. — aaand nope.
<discord-> A​cer_Saccharum. — I could very well be totally and completely wrong
<discord-> e​gg. — "floating point errors", whatever that means, is typically about roundoff error and its amplification by ill-conditioned operations
<discord-> e​gg. — maths is all you have
<discord-> A​cer_Saccharum. — at least you can generally engineer your way around floating point (I mean rounding and finite-precision things) errors, whereas other errors have a more mathematical basis (edited)
<discord-> e​gg. — sure you can extend the precision, but doing so beyond what you have natively does require some understanding of numerical analysis, but mostly you want to move the ill-conditioned bits around
<discord-> e​gg. — and that is all about formally rewriting your functions in clever ways
<discord-> A​cer_Saccharum. — I shouldn't keep you up much longer, the point I was trying and failing to make was what you just said, you can extend the precision as far as you want, but that isn't really a solution in and of itself
<discord-> e​gg. — as an exercise, consider the question of computing the angle between two vectors
<discord-> e​gg. — it is a good exercise
<discord-> A​cer_Saccharum. — the method that I've used in the past has been taking the arctangent of the norm of the cross product of the vectors and their dot product
<discord-> A​cer_Saccharum. — no clue at all how good of a method that is from a numerics perspective
<discord-> e​gg. — yes, that is a good method
<discord-> e​gg. — the question for you is then why arc cos of the dot product divided by the product of norms, or arc sin of the norm of the cross product divided by the product of norms, are bad
<discord-> e​gg. — and how bad
<discord-> P​teropodidae. — o_O That's a new method for me
<discord-> e​gg. — > that is all about formally rewriting your functions in clever ways
<discord-> e​gg. — oh a trivial example of that
<discord-> e​gg. — compute x^2 - y^2
<discord-> P​teropodidae. — Cancellation?
<discord-> e​gg. — cancellation is a special case of things being ill-conditioned, yes, *but*
<discord-> e​gg. — Sterbenz's lemma
<discord-> A​cer_Saccharum. — well for small vectors the division by the product of norms seems like it might get nasty precision-wise
<kmath> <stephentyrone> #FloatingPointWithAtlas #SterbenzLemma https://t.co/5o9SjEs0Ci
<discord-> e​gg. — @Acer_Saccharum that is not the issue
<discord-> e​gg. — division is very well behaved
<discord-> e​gg. — @Pteropodidae so, re. cancellation, if x is near y, x - y is *exact*
<discord-> A​cer_Saccharum. — well what do I know, I'm only halfway through an introductory numerical methods class as a non-math major
<discord-> e​gg. — so it is not the subtraction that induces error
<discord-> e​gg. — what it does is make it so only the error remains, in a sense
<discord-> e​gg. — or, if you want to look at it from a more analytic perspective, it amplifies the error
<discord-> e​gg. — so in x^2 - y^2, with x and y close to each other, the squarings are perfectly good operations
<discord-> e​gg. — they give you half an ULP on their result
<discord-> e​gg. — but the subtraction then leaves you with a number which may be as small as that ULP, leading to an arbitrarily big relative error
<discord-> e​gg. — in contrast
<discord-> e​gg. — compute it as (x+y)(x-y)
<discord-> e​gg. — for x close to y, x-y is exact, x+y has half an ULP on its result
<discord-> e​gg. — then you have a product, which is a well-conditioned thing
<discord-> e​gg. — you get an ULP on the overall result
<discord-> e​gg. — i.e., x^2 - y^2 could lose all bits of precision, (x+y)(x-y) loses only one bit
<discord-> P​teropodidae. — This is also why the more traditional methods of finding the angle between two vectors is not a good idea?
<discord-> e​gg. — it also has to do with conditioning, yes
<discord-> P​teropodidae. — This is also why the more traditional methods of finding the angle between two vectors are not a good idea? (edited)
<discord-> P​teropodidae. — Hm
<discord-> P​teropodidae. — Googling is proving to be enlightening
<discord-> e​gg. — you compute a cosine, if it is close to -1 or 1, a very small error in the cosine will lead to an arbitrarily large error in the arccosine
<discord-> e​gg. — https://www.wolframalpha.com/input/?i=arccos because the graph is vertical there
<discord-> A​cer_Saccharum. — and the same would therefore be true for the asin method, since that also has vertical-in-the-limit places
<discord-> e​gg. — yup, but instead of screwing up near null or flat angles like the arccos method, arcsin will screw up near right angles
<discord-> e​gg. — in contrast, if you look at arctg, its graph does not get very steep
<discord-> A​cer_Saccharum. — it appears well-behaved everywhere
<discord-> P​teropodidae. — scicomp.SE says that cross product/dot products can also suffer from cancellation?
<discord-> e​gg. — so even if you used the one-parameter arctg (the two-parameter one does some discrete magic but ultimately is just arctg y/x), arctg sin/cos would be the way to go
<discord-> e​gg. — well a dot product is product followed by a sum
<discord-> P​teropodidae. — Seems to suggest something using a variant of Heron's formula
<discord-> A​cer_Saccharum. — I was in fact referring to the piecewise? 2-argument atan2 function
<discord-> P​teropodidae. — https://scicomp.stackexchange.com/a/27694
<discord-> e​gg. — ultimately "suffers from cancellation" is a fancy way of saying "things are being added and we don't control their sign"
<discord-> P​teropodidae. — No idea how correct that is
<discord-> P​teropodidae. — Ah
<discord-> e​gg. — @Acer_Saccharum yup, that is definitely the right choice; but in its absence it is amusing to note that dividing then arctg would do
<discord-> e​gg. — @Acer_Saccharum ultimately an atan2(y, x) is really just a call to atan(y/x) after a lot of special cases
<discord-> A​cer_Saccharum. — yeah, it just does the whole +- pi radians for you after checking the sign of x
<discord-> A​cer_Saccharum. — yeah, it just does the whole +- pi radians for you after checking the sign of x and y (edited)
<discord-> e​gg. — yeah, handling 0s, infinities, and NaNs differently, not signaling in the same way as the division would, etc.
<discord-> e​gg. — but the main path is just the normal atan behind a division
<discord-> A​cer_Saccharum. — it'll actually give you a result for when x is zero
<discord-> e​gg. — well, so will atan(y/x)
<discord-> e​gg. — more interestingly, it will give you results when both are 0
<discord-> A​cer_Saccharum. — am I missing something in thinking that there'd be an issue with arctan(y/x) as x--> 0- being different to arctan(y/x) as x--> 0+
<discord-> e​gg. — there's a branch cut
<discord-> e​gg. — that's why you have signed 0
<discord-> e​gg. — there's a branch cut in atan2 too
<discord-> A​cer_Saccharum. — I do know that
<discord-> e​gg. — ah you mean that it doesn't fall in the same place
<discord-> A​cer_Saccharum. — well would both not have the same physical meaning, in that an angle of -pi/2 and pi/2 between vectors has the same effect
<discord-> A​cer_Saccharum. — well would both the 0- and 0+ cases have the same physical meaning, in that an angle of -pi/2 and pi/2 between vectors has the same effect (edited)
<discord-> A​cer_Saccharum. — well I mean you define signed angle with the right-hand rule there is a distinction
<discord-> e​gg. — I am bad at this sleep thing
<discord-> e​gg. — 💤
<discord-> A​cer_Saccharum. — has the sun risen yet?
<discord-> e​gg. — no, it's 5:20
<discord-> A​cer_Saccharum. — so dawn isn't that far off, I'll stop bothering you now
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #principia
<discord-> P​teropodidae. — Sorry for those poorly-timed questions 😦
<discord-> P​teropodidae. — And good night!
<discord-> P​teropodidae. — (morning?)
egg|laptop|egg has quit [Ping timeout: 190 seconds]
Mike` has quit [Ping timeout: 378 seconds]
Mike` has joined #principia
<_whitenotifier-d13c> [Principia] davidljung starred Principia - https://git.io/Jvxhm
Jesin has quit [Ping timeout: 190 seconds]
Jesin has joined #principia
Raidernick has quit [Ping timeout: 190 seconds]
Raidernick has joined #principia
Raidernick has quit [Ping timeout: 190 seconds]
Raidernick has joined #principia
<discord-> S​ir Mortimer. — 200+ new messages don’t u guys sleep
<discord-> P​teropodidae. — Not enough in my case at least
Wetmelon has quit [Ping timeout: 189 seconds]
<discord-> B​utcher. — @egg my cat is less helpful than yours I feel.
<discord-> n​eph. — that's a high quality cat
<discord-> B​utcher. — Isn't it.
<discord-> n​eph. — look at those paws
<discord-> n​eph. — golly
<discord-> B​utcher. — A rough and tumble street cat who has adapted to home life very well.
<discord-> n​eph. — Melting my cold heart
<discord-> B​utcher. — @neph
<discord-> n​eph. — give the cat skritches
egg|laptop|egg has joined #principia
<discord-> S​tandecco. — the best 250+ messages conversation I've ever read
egg|cell|egg has quit [Ping timeout: 189 seconds]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #principia
egg|laptop|egg has quit [Remote host closed the connection]
<discord-> S​ir Mortimer. — To reiterate the converation, I'm pondering the possibilities to maybe improve the performance of a biome lookup. It's not going to be simple.
egg|cell|egg has quit [Ping timeout: 190 seconds]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #principia
egg|laptop|egg has joined #principia
egg|laptop|egg has quit [Remote host closed the connection]
egg|cell|egg has quit [Ping timeout: 189 seconds]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 189 seconds]
egg|laptop|egg has joined #principia
<discord-> e​gg. — yeah biome lookup sounds like a mess
egg|cell|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 190 seconds]
<discord-> B​utcher. — What's the current issue?
<discord-> B​utcher. — I've looked through the squad stuff in dotpeek and it's suboptimal I think.
<discord-> S​ir Mortimer. — its borderline illegible, too, leaning towards the wrong side of that border.
<discord-> S​ir Mortimer. — i think the bottom line of the discussion will be that we will still need to do some form of discrete subsampling, maybe with a variable sample step size, and just accept the remaining errors that this will still have. somehow I don't see an analytical approach that would work in the long run, especially with adding new variables to the simulation.
<discord-> e​gg. — well, the analytical approach lies in the whole "variable stepsize" thing
<discord-> e​gg. — but I think it is critical to retaining sanity that the behaviour be roughly independent of timewarp
<discord-> e​gg. — bear in mind that biomes are uniquely messy; if you look at the things discussed in that design page, most properties are geometrical, and thus much nicer to do maths to than biomes which are by definition an arbitrary image
<discord-> e​gg. — elevation angle, solar exposure, DOP, all are ultimately basic and cheap geometry
<discord-> S​ir Mortimer. — what I mean is, you can calculate when an orbit will enter and leave the umbra, when it will be closest to the body and when it will be at given tresholds in relation to a point on the surface. but as soon as you add things like radiation belts that vary in size and intensity based on a scalar that we use as a sorry excuse for the solar cycle, or biomes, i somehow have my doubts that we will be
<discord-> S​ir Mortimer. — so you can do it analytically if you don't include biomes. ever. at which point you will just have to live with some error.
<discord-> e​gg. — the question however whether biomes can be processed into something sane
<discord-> S​ir Mortimer. — i thought about converting them into vectors, but that process itself will produce errors.
<discord-> e​gg. — of course
<discord-> e​gg. — but the fact that you can technically have single pixels of a biome in the middle of another is not necessarily something you want to spend too much time thinking about
<discord-> e​gg. — the question is not whether you will have errors or not
<discord-> e​gg. — obviously you will, in some form
<discord-> e​gg. — the question is whether you can constrain these errors, and whether you can make them deterministic
<discord-> e​gg. — and I think that last point, that the errors should be deterministic, is critical
<discord-> e​gg. — otherwise the fancy heuristics will fall on their face in a way that you will never be able to debug
<discord-> B​utcher. — Ideally you shouldn't have single pixels of biomes, I agree that it occurs but its not desirable anyway.
<discord-> B​utcher. — I did a bit of cleanup on the Earth biome recently because of this very issue.
<discord-> S​tandecco. — you could say that instead of being _over_ a biome, it's more important if said biome is visible at all
<discord-> S​tandecco. — so you take the biome map, extract a series of point at startup (ideally, a point for each biome larger than 2 pixels), then check if any of those points are visible
<discord-> S​tandecco. — maybe check which is closest?
<discord-> S​tandecco. — that has issues when the biome is really large, though
<discord-> S​ir Mortimer. — i think not having an accurate biome evaluation would carry a long way. they could be partly substituded by waypoints on the surface if needed.
<discord-> S​tandecco. — even extracting 360x360 points would come a long way, I think
<discord-> D​RVeyl. — I think egg is also saying that you can put some definitions on what the biome maps that you handle *well* look like, what biome maps will cause some errors, see how close or far you are to current maps... and then just make this fact known. "Hey, we can't handle properties like these. Can you make them look more like what we can handle?"
<discord-> e​gg. — or maybe you can subdivide space into cones from which the biome is visible, or something similarly clever
<discord-> S​tandecco. — isn't checking if a biome is larger than `predefined value` trivial?
<discord-> S​tandecco. — you could eliminate single pixel or 4x4 pixel biomes and such
<discord-> e​gg. — it definitely needs some throwing of brains at the problem but I think it is possible to have useful approximations
<discord-> e​gg. — @Standecco even downsampled, I just don’t think a grid on an equirectangular projection is a very useful representation of anything
<discord-> e​gg. — @Sir Mortimer but anyway, let’s not get too carried away ; I think your current approach of fixed-step downsampling is a good start to get something reproducible and sane, and then once you run into performance issue we can try using our brains
<discord-> e​gg. — I should make tea
<discord-> S​tandecco. — why is that? You project the biome map (with its n biome markers that you just calculated) onto the planet and then check if said markers are visible
<discord-> S​tandecco. — why is that? You project the biome map (with its `n` biome markers that you just calculated) onto the planet and then check if said markers are visible (edited)
<discord-> e​gg. — because it’s still massively inefficient
<discord-> e​gg. — you are computing cartographic coordinates, you have a projection whose higher density at the poles buys you nothing useful, and you still need a pretty large image if you want it to resemble the original
<discord-> e​gg. — as much as possible you want to preprocess for the problem you will be solving
<discord-> S​ir Mortimer. — @egg yeah, subsampling will work for quite a while. if needed i can try to move that brick wall a little bit by using threads, too.
<discord-> S​tandecco. — well, translating the markers into points on the planet surface might be inefficient, but you can do that only once right?
<discord-> S​tandecco. — and you can account for the different density at the poles
<discord-> e​gg. — if that is biome visibility rather than being-above a biome, those structures are different
<discord-> S​tandecco. — and you can account for the different density at the poles when you sample your biome map (edited)
<discord-> e​gg. — @Standecco if you want to partition space into places from which areas are visible, checking the visibility of lots of points is woefully inefficient
<discord-> e​gg. — the problem here is not your preprocessing, it is the structure that you get
<discord-> e​gg. — it is still bad
<discord-> S​ir Mortimer. — Cat vs. Stirling Engine
<discord-> e​gg. — you probably want some sort of tree structure or somesuch, to ignore the bits where you definitely are not
<discord-> e​gg. — Cat!
<discord-> e​gg. — hah, stirling engine on a mac charger :D
<discord-> S​tandecco. — connect a dynamo to that stirling engine, then connect the mac charger to the dynamo
<discord-> S​tandecco. — infinite energy!
<discord-> e​gg. — OK tea time
<discord-> S​ir Mortimer. — the engine won 🙂
<discord-> S​tandecco. — @egg how would you structure it, if points are inefficient?
<discord-> S​tandecco. — @egg how would you structure it, if point visibility checks are inefficient? (edited)
<discord-> S​ir Mortimer. — > hah, stirling engine on a mac charger 😄
<discord-> S​ir Mortimer. — recycling the energy lost to heat! 🙂
<discord-> e​gg. — @Standecco I don’t know, I have not spent much time thinking about it :-p https://en.wikipedia.org/wiki/Quadtree comes to mind, since we are talking about a space partitioning problem
<discord-> e​gg. — probably not this specifically, but some form of hierarchical structure
<discord-> S​ir Mortimer. — that at least would speed up biome lookup.
<discord-> S​ir Mortimer. — actually the KSP implementation might be such that it has a similar effect
<discord-> e​gg. — I mean biome *lookup*, as in, "which biome are we in", should be pretty fast by just looking at the image (you have a massive lookup table at hand)
<discord-> S​tandecco. — right, how does ksp's own method hold up at fast time warp speeds?
<discord-> e​gg. — biome *visibility checks* are a nightmare without massive preprocessing
<discord-> S​ir Mortimer. — @Standecco it was the most time consuming factor in the substepping implementation that Got has done for kerbalism a while ago
<discord-> S​tandecco. — so you're trying to completely reimplement that
<discord-> D​RVeyl. — Which is weird since I don't imagine body.GetLatLonAlt should be that bad.
<discord-> S​ir Mortimer. — no. I'm currently doing it for contracts only.
<discord-> S​tandecco. — I guess squad never bothered to try making something fast since their biome checks only matters when you activate your experiments
<discord-> D​RVeyl. — Although I guess you need the body -at- the right stepped place.
<discord-> S​tandecco. — so you're trying to completely reimplement that check (edited)
<discord-> e​gg. — @DRVeyl I suspect KSP might be doing something dumb
<discord-> D​RVeyl. — Hm. Weird. Wouldn't expect even a re-calc of body.GetLatLongAlt to be bad.
<discord-> B​utcher. — Fast visibility check, render the biome mapped sphere for the planet, determine which colours you can see.
<discord-> e​gg. — maybe it doesn’t actually have the lookup table in a usable state
<discord-> e​gg. — if it need to mangle the image every time that would cause slowness
<discord-> B​utcher. — Without using the gpu though...
<discord-> S​tandecco. — right, can't you use the gpu to check which biomes are visible?
<discord-> e​gg. — leave the poor GPU alone :-p
<discord-> B​utcher. — Well part of the problem is that Squad doesn;t store the biome map as a texture.
<discord-> S​tandecco. — it seems like it would scale well for parallelization
<discord-> B​utcher. — It stores it in cpu memory for faster cpu lookups.
<discord-> e​gg. — yes but precisely that should be nice for this purpose @Butcher
<discord-> B​utcher. — Though obviously you can just load the texture itself (since I assume that's what they do for the biome overlay).
<discord-> e​gg. — the issue is what form it is kept in
<discord-> S​tandecco. — ok then move all biome maps to the L1 cache
<discord-> S​tandecco. — easy
<discord-> S​ir Mortimer. — yah, sounds doable.
<discord-> e​gg. — anyway 🐴 , 🛒, etc.
<discord-> B​utcher. — @Standecco On the GPU it would take microseconds, however getting the result back is the issue - that would need to wait a frame or so.
<discord-> B​utcher. — @egg You're taking your horse shopping?
<discord-> e​gg. — you have a very wide vector unit at the end of a very long pipe
<discord-> B​utcher. — A very long pipe.
<discord-> e​gg. — @Butcher nah, trying emoji-based puns about horses and carts
<discord-> e​gg. — I guess if I had a horse I could use it to go shopping
<discord-> S​tandecco. — @egg you could try riding your cat
<discord-> S​tandecco. — @Butcher is getting the results back so slow because of software limitations, or just because of the physical interface between the gpu and cpu being slow?
<discord-> B​utcher. — The former in a manner of speaking.
<discord-> B​utcher. — The interface between the GPU and memry is on the order of 5-10 GB/s typically.
<discord-> B​utcher. — The issue you have is that the GPU is usually running about a frame or two behind the CPU - i.e. the CPU builds up a frame of work for the GPU and submits it, then the GPU consumes it. So your turnaround is at beast about 1-2 frames.
<discord-> B​utcher. — The issue you have is that the GPU is usually running about a frame or two behind the CPU - i.e. the CPU builds up a frame of work for the GPU and submits it, then the GPU consumes it. So your turnaround is at best about 1-2 frames. (edited)
<discord-> B​utcher. — Which is maybe 33ms at 60 fps, or more at lower frame rate.
<discord-> B​utcher. — For biome visibility you'd do something like, draw the planet shaded with biomes only to a texture, use a compute shader to read the texture and determine which colours are present, write the colour presence info to a buffer, CPU reads the buffer.
<discord-> P​teropodidae. — If you want visibility, you could try something like an R-tree? Downsample the biome map to something relatively sparse, use the tree to find points within a certain radius of your ground position, and determine the biomes using those points?
<discord-> P​teropodidae. — Approximate visibility by assuming biomes within a certain radius of your ground position are visible
<discord-> P​teropodidae. — Not really sure about how accurate that would be though
<discord-> e​gg. — It’s a long way to the GPU / It’s a long way to go / It’s a long way to the GPU / To the widest float vectors / Goodbye vector FPU / Farewell ALU / It’s a long long way to the GPU / but my image’s due
<discord-> P​teropodidae. — Nor the performance
<discord-> P​teropodidae. — Big-O wise it's nice but I'm not sure how well that translates to real-world performance
<discord-> e​gg. — Anyway
<discord-> P​teropodidae. — Those also tend to work better for clustered data and a downsampled biome map isn't clustered
<discord-> e​gg. — we’ll cross the performance bridge when we get there
<discord-> S​ir Mortimer. — @egg do you know of that invention where people somehow manage the artistic act of driving on a contraption with two wheels behind each others without falling over? I've seen kids doing it
<discord-> B​utcher. — @Sir Mortimer Sounds like the devil's work.
<discord-> e​gg. — yeah there are a bunch of those devices here
<discord-> S​ir Mortimer. — how far is it for that horse of yours? 5km?
<discord-> e​gg. — yeah
<discord-> S​ir Mortimer. — pittoresque.
<discord-> S​ir Mortimer. — also, get a drivers license. they're quite useful outside of big cities.
<discord-> e​gg. — yeah I have noticed
<discord-> B​utcher. — I drove to work today, to pick up some stuff. Risky business being outside.
<discord-> e​gg. — just saw a police car patrolling the bike path
<discord-> S​ir Mortimer. — oh which reminds me, you're not supposed to go out any more for sports, right? because those disciplined french ignored the rules?
<discord-> e​gg. — hm, I haven’t checked
<discord-> e​gg. — @Sir Mortimer govt website seems to say that you can still do sport individually or walk your dog, but no more than an hour a day and within 1 km of your house
<discord-> S​ir Mortimer. — I've been staring at that cursor for 5 minutes now, unable to come up with anything meaningful to write there. I think I should go for a walk
<discord-> e​gg. — attachments?
<_whitenotifier-d13c> [Principia] pleroy opened pull request #2522: Generate marshalers for structs - https://git.io/JvpnW
<_whitenotifier-d13c> [Principia] Pending. Build queued… - 
<_whitenotifier-d13c> [Principia] Pending. Building… - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4200/
VITAS has quit [Ping timeout: 190 seconds]
<_whitenotifier-d13c> [Principia] pleroy edited pull request #2522: Generate marshalers for structs - https://git.io/JvpnW
<discord-> P​teropodidae. — Actually
<discord-> P​teropodidae. — I'm not sure how bad of an idea this is
<discord-> P​teropodidae. — But what if you downsampled the biome map into a grid
<discord-> P​teropodidae. — Er
<discord-> P​teropodidae. — Wait
egg|cell|egg has joined #principia
<discord-> P​teropodidae. — How accurate do biome checks need to be?
<discord-> P​teropodidae. — Biome *visibility checks
<discord-> S​ir Mortimer. — the crater island biome on eve is one of the smallest I know of. look at that for reference.
<discord-> e​gg. — Anyway, plenty of things to look at before biome performance
<discord-> e​gg. — DOP!
<discord-> e​gg. — @Sir Mortimer iirc you had experimented with a Transit-like contract? how did that come out?
<discord-> P​teropodidae. — Hrm
<discord-> P​teropodidae. — I was going to say maybe do something dumb like downsample the biome map into a grid and look in an NxN grid cell centered on the vessel's ground location when you want biome visibility
<discord-> P​teropodidae. — Not very accurate, but simple
<discord-> e​gg. — I don’t think spending much more time and brain cells on that question is useful at this point, especially since whatever is said will be forgotten by the point the issue arises
<discord-> B​utcher. — I mean you could quantise the biome map down to a relatively coarse resolution but store all visible biomes in each cell of the map (as a bitfield or the like).
<discord-> e​gg. — ja genau
<discord-> S​ir Mortimer. — i think it works 🙂
<discord-> D​RVeyl. — For attachments... I vote "tassels."
<discord-> S​ir Mortimer. — i handwaved the minimal pass duration to be able to get a fix tho.
<discord-> e​gg. — slightly confused at the radial velocity expressed in, uh, degrees per metre?!
<discord-> S​ir Mortimer. — minute
<discord-> e​gg. — but even then that's an angular speed, not linear one
<discord-> e​gg. — the radial velocity is the derivative of the radius, which is a length
<discord-> e​gg. — so it's in m/s
<discord-> e​gg. — I think the constraint should be a notable *change* in radial velocity over the course of the pass
<discord-> e​gg. — but I need to check my notes
<discord-> S​ir Mortimer. — actually i'm not sure that we a) talk about the same thing and b) any of those things is relevant to TRANSIT. as far as I can tell, it depends on a doppler shift, which requires a satellite to first get closer and later to get away again. the angle above the surface doesn't play a role in this.
<discord-> e​gg. — looks like I thought the same thing in December at least, not sure whether that tells us much https://discordapp.com/channels/319857228905447436/480397772248580098/651843787273928717
<discord-> e​gg. — @Sir Mortimer radial velocity means the component of velocity towards/away from the ship
<discord-> e​gg. — i.e. a thing that moves circles you at a constant distance has 0 radial velocity
<discord-> S​ir Mortimer. — ah. so i confused radial velocity with angular velocity 🙂
<discord-> e​gg. — confusion happens
<discord-> e​gg. — radial velocity is the thing that you see as Doppler shift
<discord-> e​gg. — so you want that to change over the pass, to detect a change in doppler shift
<discord-> e​gg. — and then I think you have subtleties with how high the satellite is leading to inaccuracies in different directions but I forget the specifics of that
<discord-> S​ir Mortimer. — angular velocity might be relevant for a tundra satellite. there are huge ground stations with big dishes that need to point at the satellites, it would maybe make sense to require a max. angular velocity so that those dishes can actually track the damned thing
<_whitenotifier-d13c> [Principia] Success. Build finished. - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4200/
<discord-> e​gg. — yeah, angular velocity is relevant for anything that requires a tracking antenna
<discord-> e​gg. — e.g. you don’t want to track those where they are молния, *lightning*
<discord-> e​gg. — (which is where you don’t use them, in the south hemisphere)
<discord-> e​gg. — (to quote capderou, those orbits are chosen because they are slow in the north, but named because they are fast in the south, they should be called snail orbits instead)
<discord-> B​utcher. — Eh, just make everyone use phased arrays. 😁
<discord-> e​gg. — орбита улитка
<discord-> S​ir Mortimer. — anyway, i don't know if we actually need something that calculates the accuracy of the fix that can be obtained from a pass of a satellite. if it is not something the player can get an understanding of how it is calculated, i fear it will only lead to confused players
<discord-> e​gg. — true
<discord-> e​gg. — but Δradial velocity is the important bit
<discord-> S​ir Mortimer. — i don't have the ∆ yet.
<discord-> S​ir Mortimer. — wow
<discord-> e​gg. — that is mostly understandable (you want the siren on the satellite to goo weeeeeeeooouuuuuuuuuuuuu as it goes overhead :-p), and close enough
<discord-> S​ir Mortimer. — why is your Δ different from my ∆
<discord-> e​gg. — mine is a delta because I am lazy
<discord-> e​gg. — yours is probably an increment sign
<discord-> S​ir Mortimer. — alt+k on my keyboard -> ∆ there are also Ωµπ in the vicinity. looks greek
<discord-> e​gg. — ∆: U+2206 INCREMENT
<discord-> e​gg. — Δ: U+0394 GREEK CAPITAL LETTER DELTA
<discord-> e​gg. — also µ: U+00b5 MICRO SIGN
<discord-> S​ir Mortimer. — well, apple done goofed then.
<discord-> e​gg. — and μ: U+03bc GREEK SMALL LETTER MU
<discord-> e​gg. — @Sir Mortimer not really
<discord-> e​gg. — you don’t have an entire greek alphabet with alt+stuff, just mathy things
<discord-> S​ir Mortimer. — yeah but my mathy thing is more a poiny thing 😦
<discord-> e​gg. — so you want INCREMENT, semantically
<discord-> e​gg. — I only type delta because I have a greek keyboard and I am too lazy to look up the proper symbol
<discord-> S​ir Mortimer. — well. delta *does* designate increments.
<discord-> e​gg. — well
<discord-> e​gg. — they are disunified
<discord-> S​ir Mortimer. — why the hell are there 2 symbols for the same thing in unicode
<discord-> e​gg. — they are not the same thing, and you often would typeset them differently
<discord-> e​gg. — you could have a quantity called Δ and consider its variation ∆Δ, if you were trolly  :-p
<discord-> S​ir Mortimer. — also note: а and a are not the same. (something you might find out the hard way when copying source code from the ukraine)
<discord-> S​tandecco. — Δω = radial velocity when Δ = radius
<discord-> l​pg. — unicode goes higher than 2 for some things
<discord-> e​gg. — @Sir Mortimer note that Apple gives you omega probably for Ohm, because while there is a dedicated Ohm sign in Unicode, that one is deprecated
<discord-> S​tandecco. — ∆Δ is the least confusing way to use a Δ named variable; it's where you can't confuse Δ for ∆
<discord-> e​gg. — @Standecco depends on the font
<discord-> e​gg. — I am looking at this in Noto Sans and it is indistinguishable
<discord-> S​tandecco. — totally different here
<discord-> S​tandecco. — yeah but I mean, literally any product with the Δ variable is going to look like a variation of the other variable
<discord-> l​pg. — ooh. "astronomical symbol for "Sun" ☉, "circled dot operator" ⊙, the Gothic letter 𐍈, the IPA symbol for a bilabial click ʘ"
* discord- S​tandecco. — ∆_
<discord-> S​tandecco. — ∆
<discord-> l​pg. — ooh.
<discord-> l​pg. — > astronomical symbol for "Sun" ☉, "circled dot operator" ⊙, the Gothic letter 𐍈, the IPA symbol for a bilabial click ʘ (edited)
<discord-> S​tandecco. — looks exactly the same in italics
<discord-> e​gg. — hm, unicode.org is having trouble today
<discord-> e​gg. — but other than that this is a list of fun things like that
<discord-> e​gg. — including I l 1, fwiw
<discord-> B​utcher. — You people are monsters.
egg|laptop|egg has quit [Remote host closed the connection]
egg|cell|egg has quit [Ping timeout: 204 seconds]
<UmbralRaptop> Δ∇
egg|cell|egg has joined #principia
egg|laptop|egg has joined #principia
<discord-> e​gg. — hm the relay bot has encoding issues
egg|cell|egg has quit [Ping timeout: 190 seconds]
egg|cell|egg has joined #principia
<discord-> P​teropodidae. — Is "psychohistory" in the Principia codebase named after the thing from the *Foundation* series?
<discord-> P​teropodidae. — Also, question about Principia's code
<discord-> P​teropodidae. — Erm
<discord-> P​teropodidae. — When computing trajectory predictions for flight planning purposes
<discord-> P​teropodidae. — ...I'm not really sure how to phrase my question, actually
egg|laptop|egg has quit [Remote host closed the connection]
<discord-> P​teropodidae. — I guess it boils down to "How does Principia's handling of vessels during a flight plan prediction differ from its 'normal' handling?"
<discord-> P​teropodidae. — I saw #2347 and wanted to see how much I could figure out on my own
<discord-> P​teropodidae. — I think I figured out how the flight planner gets its trajectory for segments with burns?
<discord-> P​teropodidae. — Something about using the ephemeris to integrate the vessel's trajectory, with the burn providing its own acceleration?
<discord-> P​teropodidae. — And the vessel's trajectory during "normal" gameplay is derived from the psychohistory?
<discord-> P​teropodidae. — But I'm not yet certain how the psychohistory is calculated
<discord-> P​teropodidae. — How off am I?
egg|cell|egg has quit [Ping timeout: 189 seconds]
<discord-> n​eph. — if I had to guess, it's the same thing with less stringent tolerances
<discord-> n​eph. — You'll accumulate more error in the predicted future than in the actual future, but it's faster to calculate. I don't know if it's actually a different solver or the same one with a bigger solution epsilon though. Knowing egg, I wouldn't be surprised if he wrote a different one for each application 🙂
egg|cell|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 190 seconds]
<discord-> P​teropodidae. — I'm guessing it's different?
<discord-> P​teropodidae. — Egg said this:
<discord-> P​teropodidae. — > In addition, the integration method1 that we use for long-term vessel trajectories only works if the forces that it is applying depend solely on the position of the vessel, not its velocity; and it only has nice properties if these forces derive from a potential.
<discord-> P​teropodidae. — Which I suppose answers my question now that I think about it
egg|laptop|egg has joined #principia
<discord-> e​gg. — #2347 is, uh,
<discord-> e​gg. — well, at least those two are entertaining each other in that issue
<discord-> P​teropodidae. — Yeah, that guy has an *interesting* perspective
<discord-> P​teropodidae. — > become costless for only estimated less than 1000 lines of core codes xDDD
<discord-> e​gg. — **an** interesting ***approach*** to *formatting* __as__ _____well_____
<discord-> e​gg. — **an** __***interesting***__ ***approach*** to *formatting* __as__ _____well_____ (edited)
egg|cell|egg has joined #principia
<discord-> P​teropodidae. — At least the issue made for an interesting starting point for exploring the Principia codebase
<discord-> e​gg. — this is massively out of date but might be relevant https://github.com/mockingbirdnest/Principia/wiki/Technical-Overview
<discord-> e​gg. — this is massively out of date but might be interesting https://github.com/mockingbirdnest/Principia/wiki/Technical-Overview (edited)
<discord-> P​teropodidae. — Yep, saw that
<discord-> P​teropodidae. — It was a bit too high-level for what I was trying to look for though
<discord-> P​teropodidae. — I have to say though that the codebase is fairly approachable given how unfamiliar I am with its subject matter
<discord-> P​teropodidae. — At least before I got down into the weeds
<discord-> e​gg. — we try to write cleanly, but we suck at basic documentation and there in a mountain of domain-specific knowledge
<discord-> e​gg. — there is ultraspecific documentation, but not so much an overview
<discord-> e​gg. — so there is a bit of a gap
<discord-> P​teropodidae. — Yeah, the domain-specific stuff is the biggest stumbling block
<discord-> e​gg. — e.g. https://github.com/mockingbirdnest/Principia/blob/master/documentation/Geopotential.pdf is good documentation, but there is a bit of a gap before you can start understanding what it is all about
<discord-> P​teropodidae. — I could sort of follow things around, but actually understanding the specifics is another thing entirely
egg|cell|egg has quit [Ping timeout: 190 seconds]
<discord-> P​teropodidae. — Yeah, that document is a little beyond me
<_whitenotifier-d13c> [Principia] eggrobin reviewed pull request #2522 commit - https://git.io/JvpEQ
<_whitenotifier-d13c> [Principia] eggrobin labeled pull request #2522: Generate marshalers for structs - https://git.io/JvpnW
<discord-> B​utcher. — > #2347 is, uh,
<discord-> B​utcher. — @egg yeah that person is a bit um...
<discord-> e​gg. — uhm indeed.
<discord-> e​gg. — @Pteropodidae btw note that the identifiers in https://github.com/mockingbirdnest/Principia/blob/master/physics/geopotential_body.hpp match the notation in Geopotential.pdf :D
<discord-> e​gg. — ```C++
<discord-> e​gg. — σℜ_over_r = σ * ℜ_over_r;
<discord-> e​gg. — // Writing this as σ′ℜ + ℜ′σ rather than ℜ∇σ + σ∇ℜ turns some vector
<discord-> e​gg. — // operations into scalar ones.
<discord-> e​gg. — grad_σℜ = (σʹr * ℜ_over_r + ℜʹ * σ) * r_normalized;
<discord-> e​gg. — ```
<discord-> P​teropodidae. — I'm pretty sure Principia is the only codebase where I would have to install a new keyboard layout to be productive in 😛
<discord-> e​gg. — or
<discord-> e​gg. — ```C++
<discord-> e​gg. — Vector<ReducedAcceleration, Frame> grad_ℜ𝔅𝔏 = 𝔅𝔏_grad_ℜ + ℜ𝔏_grad_𝔅;
<discord-> e​gg. — if constexpr (m > 0) {
<discord-> e​gg. — // Compensate a cos_β to remove a singularity when cos_β == 0.
<discord-> e​gg. — Vector<ReducedAcceleration, Frame> const ℜ𝔅_grad_𝔏 =
<discord-> e​gg. — (ℜ_over_r *
<discord-> e​gg. — cos_β_to_the_m_minus_1 * DmPn_of_sin_β[n][m] * // 𝔅/cos_β
<discord-> e​gg. — m * (Snm * cos_mλ - Cnm * sin_mλ)) * grad_𝔏_vector; // grad_𝔏*cos_β
<discord-> e​gg. — grad_ℜ𝔅𝔏 += ℜ𝔅_grad_𝔏;
<discord-> e​gg. — }
<discord-> e​gg. — ```
<discord-> P​teropodidae. — Cna you not use ∇ instead of `grad_`? Or does `grad` not mean gradient?
<discord-> e​gg. — ∇ is illegal in identifiers
<discord-> P​teropodidae. — Huh
<discord-> P​teropodidae. — Can you not use ∇ instead of `grad_`? Or does `grad` not mean gradient? (edited)
<discord-> e​gg. — (also grad is pretty common notation so that is fairly readable anyway)
<discord-> e​gg. — (`_over_` is more annoying tbh)
<discord-> P​teropodidae. — That's fair
<discord-> P​teropodidae. — Is the Unicode fraction slash treated as a forward slash?
<discord-> P​teropodidae. — (Not that using that is necessarily a good idea anyways)
UmbralRaptop has quit [Remote host closed the connection]
UmbralRaptop has joined #principia
<discord-> S​tandecco. — so `grad_ℜ𝔅𝔏` is accepted as an identifier but nabla is not?
egg|cell|egg has joined #principia
<discord-> P​teropodidae. — Apparently
<discord-> P​teropodidae. — Seems the standard defines the exact range of characters allowed in identifiers
UmbralRaptop has quit [Remote host closed the connection]
UmbralRaptop has joined #principia
<_whitenotifier-d13c> [Principia] pleroy synchronize pull request #2522: Generate marshalers for structs - https://git.io/JvpnW
<_whitenotifier-d13c> [Principia] Pending. Build queued… - 
<_whitenotifier-d13c> [Principia] Pending. Building… - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4201/
<_whitenotifier-d13c> [Principia] Success. Build finished. - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4201/
<_whitenotifier-d13c> [Principia] pleroy closed pull request #2522: Generate marshalers for structs - https://git.io/JvpnW
<_whitenotifier-d13c> [Principia] pleroy pushed 12 commits to master [+8/-8/±24] https://git.io/Jvp2q
<_whitenotifier-d13c> [Principia] pleroy bd05ccb - Study of a marshaler.
<_whitenotifier-d13c> [Principia] pleroy 222da28 - Generated files before the changes.
<_whitenotifier-d13c> [Principia] pleroy 625e44e - Separate custom and predefined marshalers.
<_whitenotifier-d13c> [Principia] ... and 9 more commits.
egg|laptop|egg has quit [Remote host closed the connection]
Wetmelon has joined #principia
<discord-> P​teropodidae. — I'm curious why they chose the range of characters they did
<discord-> P​teropodidae. — I don't see any reasoning in the standard