Took 8th grade geo last year. Hated it, algebra was easier. You’ll learn basic trig at the end (probably, just sin/cos/tan=opp/hyp, adj/hyp, opp/adj, etc)
slopes are near useless (except in specialized cases) and are only an educational step. Consider as the delta’s approach zero…BOOM.
[quote=“sproingie,post:11,topic:40597”]
Just had to thank you for a great link! I´ll put it to good use now…
Complex numbers can be really helpful in understand 2D transformations…the sad problem is that there are very few good explanations laying around. Complex numbers are pretty much only talked about (for geometry) in dealing with classic (aka nasty/hairy) geometry problems and not basic common stuff…and there’s a silly insistence on sticking to the absurd notion of square roots of negative numbers (which is misleading).
Roquen: I´m gonna try to read up a bit more on this and then you probably can expect a question or two in your tutorial section…
Just thought I’d mention that from a computer science point of view, mathematical entities (e.g. Vectors, Matrices, etc) should always be represented by immutable objects except if it would hurt performance. You may notice that classes like Integer, Long, BigInteger, BigDecimal, etc. are all immutable. For simple code it doesn’t make much of a difference but if you do complex vector math, mutable vectors can make the code really messy.
Are you suggesting to make an immutable Matrix class…? Has anyone ever done that?
And yes, it always hurts performance, which is why it would be madness to make vector classes immutable, let alone matrices.
Sun’s vecmath classes are mutable, but create many objects under the hood. It may look like a great compromise but in the end it’s the reason nobody uses it. It’s slow and puts incredible stress on the garbage collector.
That’s utter nonsense. Stop listening to whomever told you that. Beside java doesn’t even have immutable object (no…it really doesn’t). The widespread usefulness of immutables took a huge blow in the 80s with the introduction of SSA form, but even before that this statement would still be nonsense.
Are you sure about that? I too, was told that immutable objects come with benefits and there are tutorials how to make objects immutable, e.g. this:
http://www.javapractices.com/topic/TopicAction.do?Id=29
[quote]In Effective Java, Joshua Bloch makes this recommendation :
“Classes should be immutable unless there’s a very good reason to make them mutable…If a class cannot be made immutable, limit its mutability as much as possible.”
[/quote]
But I agree, that a math matrix or vector class is better represented by a mutable entity.
There’s the ideal situation, in which object creation and collection is free and immutability solves many problems (mainly in multithreading), and there is this annoying requirement of games to be running at a rock solid 60Hz.
If the object has a rotation and speed, do this:
double x = 0, y = 0;
x += speed * (float) Math.sin(RAD(rotation));
y -= speed * (float) Math.cos(RAD(rotation));
public static double RAD(double VAL) {
return ((VAL * 3.14) / 180);
}
EDIT:
if the object moves the wrong way, switch the + & - signs.
@Varkas - yes I’m sure. As I’m fond of say, you can’t make generalizations about computer science techniques. And as I said, java doesn’t have real immutables, so the only reason to go that route is for some design purpose. A pure functional language can leverage immutability, java never can (at least until it adds them).
@orogamo - see: complex multiply
I don’t understand your sentance, I’m afraid. You say, Java doesn’t have immutables. The Java String class is considered to be immutable though, and the page that I’ve linked talks about immutable objects in Java.
How does that go together?
I understand that for games performance considerations may lead to the decision not to use immutable objects - but I still don’t understand why you say Java does not have immutable objects?
Movement formulas:
p = projectile position
v0 = initial projectile speed
g = gravitational force (downwards acceleration)
t = the time which the projectile has travelled already
-
p = v*t
-
v = v0 + g*t
-
p = tv0 + gt*t
if you set gravity to 0, you get
- p = t * v0
which was suggested before.
If you want to consider air resistance, you need to reduce v over time.
Java the high level language has ‘final’ which disallows direct modification once initialized. It also has (for instance) reflection which allows these final values to be modified at any time during runtime. Since the JVM is a dynamic language that cannot know all code that will run, it cannot do treat final values as immutable. (The decompilation framework does deal with some guesswork of this nature, but not for fields). Off and on there’s been talk of adding real immutables, but it hasn’t happened yet.
HotSpot already treats final variables differently, and changing their value through reflection results in ‘undefined behavior’, in some cases, where the actual memory location is updated, but the old value may be ‘cached’ in certain expressions.
final int one = 1;
public int addOne(int val) {
return val + one; // might be compiled to value+1 (compiled by HotSpot, not javac)
}
IIRC erikd ran into this years ago.
SSA, Single Static Assignment, would seem to imply that it makes everything immutable. Seems compilers have moved in the direction of immutable data even for modeling state.
Look, in terms of theory, referential transparency makes everything so much simpler. Pure functions can be memoized without fear. Evaluation can be done in any order and parallelized trivially. Testing is a matter of plugging in inputs and checking outputs, no setup needed. The list goes on and on.
The fact is, we still use mutable vectors and matrices because the garbage collector does not run at zero cost. State might be useful for modeling other problems, but if not for the gc problem, most of us would rather be using actual math to describe math problems, not coaxing an automaton into simulating it.
SSA is just a technique used by compilers to optimize code. It has nothing to do with what I was saying. And it doesn’t matter if Java has a keyword built in for defining immutable classes. You can still make objects de facto immutable.
I’m even gonna go a step further with my claims and say that making vectors mutable is a form of premature optimization and nothing else. Of course in game/graphic engines it may make sense to do that but unless performance issues force me to optimize my code, I’m gonna stick with immutablity.
The point of SSA (indeed a backend compiler technique) is that transforms and analysis that were previously difficult to impossible for mutable values became possible and therefore made the argument for favoring languages and/or constructions that truly made usage of immutability less (or even much less) strong. I have a reasonably firm grasp of issues related to mutable vs. immutable values (notice I’m talking about values rather than the more abstract notion of types). Furthermore temporal coherency of memory accesses sticks yet another dagger into the heart of the importance of immutability. But there’s about zero reason to push this discussion into language design, type theory, lambda calculus and modern-esqe memory architectures, because it’s moot. Java doesn’t currently support immutable types in the sense that we are talking about. Back to the root of this, DrZoidberg stated that “from a computer science point of view, mathematical entities (e.g. Vectors, Matrices, etc) should always be represented by immutable objects” to which I say is nonsense as you cannot make generalization of this kind, or at least worthwhile ones. Besides computer science is a form of applied mathematics so really all types are mathematical and by this reasoning should be immutable.
I’m even gonna go a step further with my claims and say that making vectors mutable is a form of premature optimization and nothing else.
That’s just silly. This whole “premature optimization” garbage is really out of hand. The important issue is opportunity cost.
Of course in game/graphic engines it may make sense to do that but unless performance issues force me to optimize my code, I’m gonna stick with immutablity
And, as I stated (or at least implied) there’s not wrong with making the design choice of immutability (as long as it doesn’t bite you in the butt), but that’s a far cry from claiming that it’s the “ordained true path” of computer science.