This is the basic pattern in interacting with Reid on these forums:

1. Reid overstates his case on some detail in order to make his point
2. Reid is corrected
3. Reid gets all pissy and starts whacking down strawmen in order to avoid facing up to his sloppiness

Really, I'm not at all interested in arguing with you on this stuff. But it's going to be hard to talk to you if you react to every single correction like its an existential threat to your opinion.

Don't we basically agree?

Yes! That's fine! I do it too! Now can you stop getting lashing out?

Anyway, you really do seem to have this idea that I am some kind of rebel against mainstream mathematics who has an emotional need for his opinions to be validated.

But I couldn't care less! As far as I'm concerned, the corrections I've written in response to your posts are boring and simple matters of fact. If you understand me correctly, then you will be bored with them. Whereas you seem to be taking a difference of opinion on the subjective aspects of these topics to be a green light to slight them.

Yes, I'm not trying to make you feel bad.

See, this is exactly what I'm talking about. Why are you trying to make this personal? Am I really making you that angry?

I couldn't care less if you think I'm an idiot.

Given that I'm the only one reading your posts on these topics, it might be better for both of us to find something better to discuss. I think the discussion of foundations has worn itself far past any reasonable level. I'm totally fine if you want to discuss any of that stuff on a technical level, but I think I'm past the point of reading meta-level quotes and opinions about these subjects.

Look, I respect your expertise on most of this stuff. I don't really have a whole lot of knowledge on these topics myself. But the fact is, in a lot of cases, we really aren't talking about the same things, even when you seem to think we are. So even in cases where you know far more than I do, even I can see your overly broad criticisms don't even apply to anything I'm getting at.

Hey so I have a question about mathematics.

What’s the deal with the mathematics/applied mathematics/computer science divide, huh? Algorithmics and complexity are obviously math to me. Their results should often be considered pure math, even, since they address questions like the lower bounds on classes of problems without actually constructing the corresponding algorithm (and even when they do construct an algorithm, it is usually impractical). Plus, they make frequent contributions to subjects that have been historically considered math, like graph theory (Euler) and,... um, algorithms (Euclid).

Yet there seems to be an artificial divide separating these fields. I also get the feeling that mathematicians don’t really respect algorists much.

IMO it seems more natural for computer science to be focused on information processing/applies algorithmics, and move algorithmics and complexity proper back into mathematics departments and mathematics journals.

I don't think you're an idiot, not at all.

As far as I'm concerned, we haven't been discussing anything at all, beyond a couple technical things that piqued your interest, based on your existing knowledge of mathematics. There has been this straw man of "finitism" that you've set up a few times, but as far as I'm concerned, I'm not really party to that whole debate. The way you've defined it, yeah, finitism is idiotic.

The rest of the stuff I posted, well that was just a bunch of super interesting stuff that may or may not be relevant to your interests.

I've met a mathematician who works on super abstract topology, but also has interests in graph theory, convex geometry, number theory, and computation.

Guess what? He views himself as a problem solver. I think that's the difference: mathematicians who take a problem solving approach realize the importance of computer science and algorithms, and indeed even the most abstract topics like homology benefit from algorithms. Honestly, when it comes down to it, there isn't a whole lot of pure mathematics that isn't algorithmic where it really counts.

Theory builders, on the other hand, can probably get away with not caring about the actual algorithmic effectiveness of their work, but as far as I'm concerned it's a bad sign.

For one, it's important to remember who the head honchos in math are. Most of them are 60 years or older. They grew up in an era when computer science was far less relevant. They're also enamored with a bunch of research projects, they have no shortage of work, so there's no reason to expect they will change course. Conversely, if you look at new faculty hires, you'll see an increasing number of them are involved in computer science, or at least are familiar with some kind of programming. In 30-40 years the divide will be much weaker by this effect alone.

I think most people in my department would say algorithmics, complexity theory, and so forth, are "pure math" in the sense that they do rigorous proofs in the style of pure mathematics. They only aren't "pure math" in the sense that they're not in the pure math department.

The question is more a question of relevancy. If someone wants to work in operator theory, by and large they're going to solve problems by using traditional mathematical methods. And that's all they really can do, still. There's not much for them to use from computer science. Maybe someday, people will do the work to bridge the gap and the fields will be brought closer. I think this is where the feelings of division come from: a mathematician is trying to solve math problems, they want to get a solution and a paper done relatively soon. They see the work of computer scientists as "not relevant", so they don't go listen to them or speak much.

To weaken the divide, you'll need people interested in straddling it and doing relevant and important research in both areas. That's where things get tricky, because it's hard enough to do relevant research in just one area. I suspect you'll get more of these superpeople in the future, but right now they are rare.

Specifically, for graph theory and combinatorics, most mathematicians who do active research in those areas are heavily involved in computer science research. A professor I knew at UCR straddled that line perfectly.

The issue is that graph theory and combinatorics are not necessary for much of mathematics research. That you can reword many problems in that language is not the issue, it's whether mathematicians perceive a gain in doing so. For most, they're able to put out research just fine without combinatorial or graph theorhetic results.

If graph theory and combinatorics start becoming tools necessary to further research, you'll see more mathematicians learn them.

Question for people who know graph theory: what's the best way to store a graph in plain text?

Undirected, simply connected

What does “best” mean to you?

For the bot I'm slowly working on, my idea is to create a "graph creation mode", where as I'm moving through the world it will once every second or so it will store your current position as a vertex, then add an edge from that vertex to the previous, as well as marking vertices where a harvesting node is located. Then, an algorithm could determine an optimal path through all of the harvest nodes.

But, that will obviously create a massive nightmare in short time, so I want some algorithms to help process and cut down the graph. So I'd want to write some other graph processing algorithms, that can read the data later and will do things like: merge vertices within a certain distance, or excise vertices that lie in a straight path, maybe even delete redundant vertices in some way, and other shortcuts to reduce the size of the graph.

Optimally I'd prefer the data to be readable by a human, so that things could be manually added and so it's easier to test the code.

Obviously the concern here is computation and load time. A graph with thousands of vertices is going to be CPU intensive, so having the algorithm load and save graphs in less time is preferred.

I suppose, I could create a theoretical upper limit to how many edges each vertex could have, and I could index each vertex by just enumerating them. Up to 10 connections per vertex or so would probably be sufficient, an array or some sufficient structure to list the vertices connected to our current one. Then list them line by line in a text file.

For your master’s thesis?

I mean this sincerely, even if it does sound snarky: it’s so adorable how you’ve handwaved past loop closure, subgraph isomorphism and the traveling salesman problem, only to be worried about handling “thousands” of vertices and the format of a text file.


Edit: Reverse engineer their collision data and use TRA*, dude.

Well, those certainly will be issues. Thanks for bringing them to my attention

If I absolutely had to do this, here’s basically how I’d approach things.

What I’d do is take the raw sample data and write it to a binary file. I wouldn’t worry about welding nearby vertices or smoothing collinear vertices or any of that other stuff you talked about, because with as fast as computers are today those optimizations simply do not matter. My file format would be a raw, complete sequence of floating point triples, optionally tagged with metadata (e.g. if it’s a resource).

A floating point triple is 12 bytes, so at a sample rate of 1 Hz it’ll take around a full day to generate 1 MB of data. This is an inconsequential amount of information. Your computer processes thousands of times more data per frame of a modern game. If you’re really not convinced, I would probably use some kind of differential coding to reduce the size of the data. Then I’d investigate reducing the floating point precision. I wouldn’t investigate smoothing or welding until after I’d already done those things, and again I’d only do them if I absolutely had to do them.

And again, this format would be binary. At these file sizes it really doesn’t matter, but this is my preference. Parsing text is one of the most expensive things you can do on a modern computer, and roughly ten thousand nines of the data your program processes will never be seen by a human, so I’d rather provide an external tool that can encode and decode this file for testing, rather than permanently cripple my throughput by forcing everything to go through text.

Then the next step is to read the file and build a polygonal chain in memory. It should easily fit, but there are ways around it if it doesn’t. What you’d do now is find pairs of line segments that intersect. (I assume such intersections can be determined easily - flatten it to 2D, maybe, then apply an O(nlogn) sweep line algorithm - you sort the endpoints along a certain axis, then perform a linear scan. It’s real fast.)

Then take the graph with closed loops, copy it*, and smooth the graph by deleting non-resource degree 2 vertices. Make sure to sum the edge weights (lengths) when you delete a vertex.

Now you have two things. A weighted but extremely simple graph connecting resource vertices and significant intersections, and a set of path fragments from the original data, which can be executed or reversed for motion planning between significant vertices but are not otherwise relevant for pathfinding.

For making this final data human readable, SQLite and a tool to decode binary blobs. Again, it’s for you. Nobody is ever going to edit this **** by hand.

The final problem is point location at run-time. If you can convince the user that they need to start the tool when they’re standing next to a POI, great. At arbitrary locations, you need a much more complete navmesh. *handwaves*

Or just extract the collision mesh from the game data, lol.

The standard introductory text is Computational Geometry Algorithms and Applications (BCKO). The sweep line algorithm I mentioned above is detailed in chapter 2 section 1, IIRC with some discussion of edge cases in the notes and comments. I think you mentioned you were doing some work with something like GIS, so the contents of this book would be highly relevant to you if you haven't already studied it.

It may also be constructive if you need more proof that some computer scientists are, indeed, skilled at mathematics.

Yeah, you were totally right here, and I can't even understand why I said that to begin with. ~15 minutes of data consumed about 25kb.



Also a better idea.



All seems doable. I'm pretty close to finalizing the code I have written as of yet. Once I have a stable version written that can do basic tasks consistently, I'm going to ramp up into this graph theory thing. Fasten your seatbelts.



Well, so far the user is just me and my friend, so convincing them of things is not the issue.

I'll give a whack at reversing that part of the code at some point, I think. Right now I'm more concerned with frankly easier parts of reversing. For one, they have a kind of anti-cheat going on with the memory, that updates memory locations of key structures, at different pointer levels etc.

I haven't yet figured out what function is being called to scramble the memory, but I hope to find it.

For now, I have a kind of loophole that works. Addon memory is not scrambled, so any data I can load into an addon I can predictable get a pointer for. Fortunately, the in-game API lets you pull a crazy amount of data, including X, Y, Z coordinates and orientation (????), so it's just a matter of having an addon which updates these values every tick and I'm able to hold onto the data reliably.

So, maybe when I get down further into the code and figure out what the heeeck they are doing, I can start trying to dump meshes. I probably won't do the graph thing because I've realized, simply recording inputs and marking locations of nodes is proving to be an efficient and reliable way of gathering, so all of that graph theory stuff is probably just a bunch of extra work for very marginal gains to productivity.

I'm also working on tying down basic functionality:



I have an addon/screenreading cheesy way of doing this, so now I'll have to refactor the code to work with the addon tick/dll library I have built up.

Yeah, I do some work related to GIS, or at least code that processes GIS data. Thank you for the reference, I'll probably need that for reference with an undisclosable project coming up this summer, tbh.

And yeah! Good mathematics is to be appreciated always, no matter the source.

To be fair, I do have more patents in online analysis of instrumentation data than you.

So, grading. Primary wrote this question for the homework. I'm not quite sure why he would write a question like this, given it can entirely be answered with trivial responses.

Impressive, I bet that earns you a pretty penny.

Also, results came back from my section on the exam. Students in my section performed the best again. Apparently we had a higher than average amount of A's, lower than average amount of B's, average amount of other grades.

Presuming I actually do bear responsibility for my section's results (which is grantedly very dubious), then it seems the insights I was trying to drag my students into was more appreciated by a particular kind of student.

Average is too low?

I just meant that its literally my whole profession to realize stuff like it, and you shouldn’t feel bad for missing it.

Humans are naturally intuitive creatures, but human intuition doesn’t work for software systems performance. It’s totally normal to intuit your way through systems design though. The overwhelming majority of software engineers get by perfectly fine doing it, and most will spend their whole career without realizing that they have a cognitive gap. Systems analysts live in the dark corners where intuition isn’t enough.

I’ve had this exact exchange literally dozens of times. Most were with engineers I consider quite excellent.

Niels Bohr: "An expert is a person who has made all the mistakes that can be made in a very narrow field."

Actually, probably. Given the semi world salad a few students wrote, I think the prof needs a few gimmes.



Fair, the only thing I should feel bad for missing is the obvious complicated of presuming easy solutions for graph theory problems. Granted I haven't seen a lick of graph theory in two years, but I've learned about the travelling salesman problem before. I should have recognized it.

In any case, it's not an issue yet and I would have seen the problems trying to implement it anyway. So really it just saved me some coding time.

https://stackoverflow.blog/2018/04/26/stack-overflow-isnt-very-welcoming-its-time-for-that-to-change/



blah blah blah.

At least they understand they have a problem, but they're either unaware or unwilling to acknowledge what the problem actually is. "hostile or elitist place, especially newer coders"... no, actually, it's hostile for anybody who wants to use Stack Overflow to ask or answer questions, as opposed to points whoring. It has a points whoring / IRC points whore moderation brigade problem, not a jerk problem. Those are different things. You can downvote a jerk, you can't downvote a gang of tier-two user moderators who never participate in Q&A to be downvoted, and those are the people who run Stack Overflow today. Fixing Stack Overflow and making it useful again means stripping out its defective moderation system entirely. You can't fix it by saying "be nice", you have to eliminate the incentive, and unfortunately there was no acknowledgment that user moderation is even a problem in that blog post.

What's with the cutesy spelling?

"cuz" instead of "because", etc.

isn't stack exchange for the dumb questions?

there are no stupid questions, only stupid answer sites

(There are also a lot of cool questions that get downvoted...)

stack overflow seemed fine when i used it a lot about a year ago. Has it gotten worse since then?

I'm not sure if it's better or worse, but it's probably gotten bigger, and has the same limitations it always did....