before-it-was-popular

Members
  • Content count

    31
  • Joined

  • Last visited

Community Reputation

594 Good

About before-it-was-popular

  • Rank
    Member
  1. Monty Hall Problem Code to Proof

    Strictly speaking, the showmaster doesn't need to know there's a goat behind the door; his knowledge or lack thereof is not relevant.  All he has to do is open a door with a goat behind it.  If he happens to open the door with the car, then it is no longer the Monte Hall problem, because the Monte Hall problem specifies that he opens a goat door.   It doesn't matter if the showmaster's door was chosen at random; it DOES matter what the result happened to be.  With this in mind, I believe the problem statement in the Wikipedia article introduction is correct.
  2. Command line Java: Could not find or load main class

      This was it. Thanks a million!
  3. Hey, everyone.  I'm trying to get started writing Java bots for Starcraft: Brood War using BWMirror.  The starter project runs fine in Eclipse, but I can't get it working on the command line.   I'm trying to compile and run a class TestBot1 that extends a class in a JAR.  It compiles fine, but when I run it I get 'Error: Could not find or load main class TestBot1'.   Here's an MWE.  TestBot1.java: import bwapi.*; public class TestBot1 extends DefaultBWListener {   public static void main(String[] args)   {     System.out.println("It works!");   } } I execute both the compile and the run command in the same directory as TestBot1.java (and TestBot1.class when it generates). I compile with: javac TestBot1.java -classpath .;../lib/bwmirror_v2_5.jar   I attempt to run with: java TestBot1 -classpath .;../lib/bwmirror_v2_5.jar As is evident from the above, my directory structure is as follows: Folder TestBot1 contains folders src and lib; src contains TestBot1.java, and lib contains bwmirror_v2_5.jar.   This run fails with a 'could not find or load main class' error.  If I remove 'extends DefaultBWListener', though, everything compiles and runs fine.  I'm on Windows 7, using Java 1.8.0   I'm not a Java expert, and most of my experience building large codebases is with C/C++/Fortran and make.  I understand that I could just use Eclipse.  I'd like to figure out my misunderstanding here, though.
  4. Moving a point around a Sphere

      Cartesian and spherical coordinates are two ways of representing exactly the same thing.  The thing that keeps the point on the sphere is the Rodriguez formula, not the use of spherical coordinates.  A rotation never changes the length of a vector.  A sphere is just the surface at a particular distance from the center, so a rotation around the center of a sphere will never move you off of that sphere, regardless of your coordinate system.  You should be able to stick with Cartesian coordinates and do everything in a few lines:   1. define your rotation axis 2. apply the Rodriguez formula to renderlist[i].point to get the new point     I haven't figured out where you're getting the error with negatives from, but your strategy is probably not going to work.  The +1s that you add are going to get 'mixed up' by the rotation, so when you subtract them off it won't cancel properly.
  5. Moving a point around a Sphere

    I might be misunderstanding something here, but why are you converting to spherical coordinates?  The Rodriguez formula takes vectors in any representation; you should just be able to apply it to x, y, and z directly.  I think that might be your problem; unless mCross, mDot, and the * operator with a float are defined to work with spherical coordinates, you would expect to get the wrong answer.  For example, for the common overload of *(float, vector), multiplying v by mCos(theta) will scale all three components, but with spherical coordinates you want it to scale r and leave theta and phi unchanged.   As an aside, it shouldn't be necessary to add 1 to x, y, and z either in spherical coordinates or for the Rodriguez formula.  Wouldn't you expect doing so to change the result?     EDIT:  I apologize, it looks like I didn't read the last part of your code carefully enough.  It looks like you're using the Rodriguez formula to produce a vector vRot that rotates another vector, which is also not correct.  The behavior of v * vRot depends on how  *(vector, vector) is defined, but in general it's very weird to define a rotation as some sort of multiplication between two vectors - in fact, multiplication between vectors is usually defined to be a dot or cross product.   The correct usage of the Rodriguez formula is to take vRot as your rotated result without any additional multiplications.
  6. Unity Should I leave Unity?

      Unity actually has some problems specifically with generating large numbers of meshes, as for a chunked voxel world.  One issue is that you need to pass in arrays of the correct size as vertices, indices, etc., so you end up creating and destroying a lot of arrays and can't* do pooling for them.  Also, I'm not sure, but I think Unity creates its own copies of those arrays when you assign them to meshes.   Cities: Skylines isn't really a fair comparison; Unity's approach to procedural meshes and garbage collection might actually be a serious problem for a voxel-based world, as compared to other options OP might investigate.   I'm definitely not a Unity expert, so there might be solutions to these issues that I'm not aware of.  If there are, I'd definitely love to hear about them!  I do see voxel engines on Unity's Asset Store, so it's possible some people have figured it out, or at least gotten good enough performance.   *you CAN create and pool vertex arrays of size MAX_VERTICES and pass them in with the unused regions filled with junk.  I don't know if those junk vertices get transferred to the GPU, though.  Also, as far as I know that approach doesn't work for the indexing arrays.
  7. Kim Davis denies a marriage license to an atheist couple

    Happened to me too, actually. Middle school industrial tech class.
  8. conservation of momentum

    I'm afraid your intuition is wrong about how to add inverse masses.  You can indeed add them as is; inverse mass is just a number, like speed or regular mass.  If I add 7 and 9, I get 16; likewise, if I add mi1 = 1/2 and mi2 = 1/3 I should get 1/2 + 1/3 = 5/6.  Therefore totalInverseMass = inverseMass1 + inverseMass2 = 1/m1 + 1/m2, which is not the same as 1/totalMass = 1/(m1 + m2).  For that reason, you're right that real impulse = deltaVelocity / totalInverseMass; is different from real impulse = deltaVelocity * totalActualMass; But you cannot rewrite the line to real impulse = deltaVelocity / totalActualMass; because totalActualMass = m1 + m2 is not the same as totalInverseMass = 1/m1 + 1/m2.   You can look at totalInverseMass as just a convenient trick to solve the system of equations that I described in my first post:   There is a little bit of physical intuition to be had about totalInverseMass as a quantity by itself, but (in my estimation) it's not too important and there are a few confusing subtleties.  You might be better off considering it as an algebraic step in the solution of the quoted equations.
  9. conservation of momentum

    Looks like someone already posted an answer while I was dealing with reactivation issues!  I'll go ahead and post this answer anyways, as I approach the answer from a slightly different angle.   You can tell this code respects conservation of momentum because the two objects receive the same impulse (in opposite directions, of course) and impulse is the change in momentum. This code does two things.  First, it uses the parameters of the collision to determine how to change the speeds of the objects involved.  The output of that is deltaVelocity, the desired change in relative velocity between the two objects. Second, it calculates how much the velocity of each object must change both to conserve momentum (or, equivalently, to have an equal impulse applied to both objects) and produce the correct change in relative velocity.  The changes of velocity deltaVelocity1 and deltaVelocity2 of the two objects are constrained as below (I treat the velocities as positive numbers in opposite directions): deltaVelocity1 + deltaVelocity2 = deltaVelocity (correct change in relative velocity) mass1 * deltaVelocity1 = mass2 * deltaVelocity2 (equal impulses) The inverse mass of an object with mass m is 1/m, and the code calculates the impulse as deltaVelocity times the sum of the inverse masses (so, 1/mass1 + 1/mass2).  You can use that to calculate deltaVelocity1 and deltaVelocity2, and then plug those in to the above equations to verify that the code is correct.
  10.   I don't know.  There are a number of material and stylistic decisions to make when designing an editor of the type you discuss - every developer will have his or her own preferences, and it's unlikely that a single package, or even several packages, could satisfy everyone's diverse requirements.   Might it not be wiser to develop a more general-purpose editing environment that could construct editor-making editors?
  11. interactive within 4 spatial dimensions

    I'm pretty sure it wouldn't work.  dr^2 - dt^2 is an invariant because of the equations for coordinate transformations between different reference frames, which should be the same in rotated fly-space.  If you construct a similar equation to compare z-distance with xyt-distance, you'll get a quantity that can change from reference frame to reference frame, regardless of how you view the space it's measured in.   I'm not trying to claim that anything is holding still in the absolute sense that you mean - as you seem to agree, movement isn't meaningful in any absolute sense.  I am claiming that something can hold still in a particular reference frame - that is, that its spatial coordinates in that reference frame could be constant.  That much seems clear to me; in a reference frame attached to my desk, my monitor is stationary.   If I restrict my attention to inertial reference frames - that is, reference frames that aren't rotating, accelerating, or breaking the speed of light - I can then make my claim that objects can be stationary in space but not in time.  In short, it doesn't matter that I have no absolute coordinates, because my argument holds true in any set of relative coordinates I choose, as long as those coordinates correspond to an inertial reference frame.   Talking about the fly being in two spots at once was a little sloppy of me; the more precise thing to say would have been that the fly's movement could satisfy things like dx/dt = 0 or dx/dy = 0, but never things like dt/dx = 0, with dt in the numerator.  According to special relativity, that much is true regardless of how the fly interacts with the fourth dimension.   As you say, you can view the fly as a collection of particles; your suggestion, then, is that there's one 'fly' particle, and at any particular time-step it moves through the positions of all the elementary particles in the fly?  Even disregarding the issue of multiple elementary particle types, that's not movement in the sense that I was discussing - it's a jump, not a smooth progression.
  12. interactive within 4 spatial dimensions

    Sorry!  I had a killer final project.   It is a comparison, but it's interesting to me that using that comparison is the way you construct an invariant.  My argument is that if time and space were truly interchangeable, you'd expect an invariant quantity to have dt show up interchangeably with dx, dy, and dz.  If you try to construct the invariant interval that way, though, it doesn't work.  (I know about the c^2; it's easier to use natural units, and in this instance it's conceptually simpler for people who are unfamiliar with relativity.)   I can't call anything absolutely stationary, but my argument holds true in any inertial reference frame.  I can certanly find an inertial reference frame and determine the position of objects within it without breaking relativity.  I don't quite understand what you mean by theory, by the way; theory attempts to describe real life as well as it can.  The expansion of the universe is extremely theoretical.   I agree more or less with what you're saying here.  Using your setup, my point is that if you use t as a delta, the fly can only be at one location at once, but if you use x, y, or z, the fly can at multiple locations simultaneously - that suggests to me that there's something different about t.
  13. interactive within 4 spatial dimensions

    That's not really true.  The point of delta-s as I defined it above is that it is a 'distance' metric between two points that does not change when you move to a different reference frame.  If you try to define the metric without the sign difference, you'll get a 'distance' that changes when you transform coordinates to a reference frame with a different velocity.  That sign difference is necessary and fundamental, and shows up throughout special relativity.   Expansion doesn't imply movement.  Even if you have an object that's not a point particle, every point on that object can remain at a fixed position as space expands, so the object gets larger but experiences no change in spatial position.   This is easier to discuss with graphs: In case A, an object moves through both space and time at less than the speed of light, as normal.  In case B, an object moves through space without moving through time; this what I'm saying is impossible.  Case C is the wormhole.  I agree with you that movement along the red line is continuous.  The red line is always moving through time as well, though, so at no point is the object moving 'horizontally', or even necessarily faster than the speed of light.   In retrospect, I was imprecise when I said 'that's not movement' -  sorry about that.  What I meant was that it's not movement directly through space from instance to instance like the horizontal movement in the diagram.
  14. interactive within 4 spatial dimensions

    We measure space in deltas too - 5 km west of New York, etc.  I'm getting at a different distinction, though.  Mathematically, special relativity treats time and space slightly differently.  For example, the 'pythagorean theorem' in special relativity is delta-s^2 = delta-x^2 + delta-y^2 + delta-z^2 - delta-t^2; note the sign difference between the spatial and temporal terms.   I don't know much about general relativity, but my understanding is that points in space are preserved, but the distance between them increases.  In that case, there's no problem with talking about a spatial position.   Leaving aside the issue of how this time travel works, I'd say that's not really movement.  You have two instances of the same object, but they're not connected by a smooth transition - or rather, they are connected, but their smooth transition goes forward in time, then back in time through a wormhole or similar, not straight from position to position.
  15. interactive within 4 spatial dimensions

      Movement is a tricky idea in this context.  What we really mean by movement is a change in position with respect to time; if we check an object's position at two times and the position has changed, we say the object has moved.  The reason this doesn't work with time is because we've made an arbitrary decision to measure change with respect to time.  A priori, it makes just as much sense to measure movement with respect to a spatial axis - for example, to say that a particle 'moves' because we happen to observe its x-coordinate changing as we change its y-coordinate.   When you're doing special relativity, however, in certain contexts time gets a negative sign and spatial position doesn't, which suggests to me a fundamental distinction of some sort between time and space.  Note that it's possible to move through time without changing spatial position, but it's not possible to move through space without changing temporal position; you could look at that as a consequence of special relativity, namely because of the speed of light as a universal speed limit.   Space and time are two inextricably linked facets of the same idea, though, which is why we refer to the 'space-time' continuum.