|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19/08/2011 11:23 PM, Patrick Elliott wrote:
> You do realize that about half the people here, including me, read this
> and thought, "Man I really hate this guy for being able to do that
> shit!", right? lol No wonder I can't even figure out some "basic" stuff
> I need for some 3D math. The most I ever derived was some non-standard
> way of multiplying two, two digit, numbers, so it wasn't necessary to do
> all the complicatedly silly stuff the teacher insisted we screw with. :p
Uh, *which* newsgroup am I in? :-?
Seriously though. I was awful at maths when I was at school. Then again,
when I was at school, "maths" consisted of doing endless arithmetic. In
class, you would have a textbook the size of a small hardback
dictionary. Most pages contained 40 questions. For example, you might
have a page containing 40 sums, another page containing 40
multiplications, another contained 40 long-divisions, and so on.
At the start of the book, you get to do really easy stuff like 3+7. They
would have several pages of adding, and then a few pages of subtracting,
then a few pages explaining how multiplication works, and then some
pages of multiplication, then how long multiplication works, and then
several pages of progressively harder long multiplication questions.
Then they might get you to do sums involving multiple numbers of
increasing size. Then they have a couple of pages explaining about
negative numbers, then you do progressively more complicated sums
involving multiple negative and positive quantities. Then they might
talk about long division, and get you to do a few hundred of those. And
then division and multiplication with negative quantities as well. Then
maybe they start talking about fractions...
Can you imagine anything more MIND-NUMBINGLY BORING than staring at a
sheet of 40 long division problems? YES, I GET IT! I KNOW HOW LONG
DIVISION WORKS! STOP BUGGING ME ALREADY! >_<
Seriously. If you know how it works, do you really need to do it 200
times over just to *prove* that you know how it works? It's not even
like it's particularly important to be able to *do* long division; it
isn't something you're going to need to do every day of your adult life.
You just need to have a firm grasp of /how/ it works and /why/ it works.
Once you've got that, practising it on endless question sheets is just
an utter waste of time.
I was always quite bad at arithmetic. I still am. The difference is that
today, I use a frigging *computer* to do the work for me. :-P My job is
to figure out what the actual calculation is; the computer does the
mundane work of actually *running* it.
It wasn't until I got to college that I discovered, mainly due to DKJ,
that "mathematics" consists of something other than just doing hundreds
of identical long division calculations over and over again. Mathematics
provides a systematic way of solving puzzles and problems. It lets you
manipulate and analyse hypothetical entities who's identity (or, indeed,
existence) is as-yet unknown. Through tools like FractInt, I discovered
that mathematics can be beautiful. I spent almost all of my time at
college sat in the library, absorbing everything I could lay my hands on.
At school, fractions were about the most sophisticated topic we came
into contact with. Oh, and drawing graphs on graph paper. We a little
bit of that too. But at college, I learned how to do algebra. I learned
about complex numbers, vectors and matricies, polynomials, solving
equations, differential and integral calculus, cryptography, and so on.
By the way, it's not always easy to learn this kind of stuff from books.
You may not realise, but mathematics is a *very* old subject. It abounds
with strange vocabulary and archaic turns of phrase. For example,
instead of a third-order polymonial, a book might talk about a
polynomial "of order three". On top of that, the books frequently assume
prior knowledge that I don't have. If you're smart you can sometimes
figure out the missing pieces for yourself. But sometimes it's really
hard to follow what's happening. To this day, I /still/ can't figure out
most logic textbooks. And I guess that's simply because I have nobody to
ask.
There's some really interesting stuff out there. Like, group theory,
where you *make up* new kinds of entities which you can "add" and
"subtract" in a mannar similar to ordinary numbers. How neat is that? Or
matrix algebra, where you gain the tools necessary for doing crazy 3D
work. Complex numbers, like normal numbers but with added superpowers.
Cryptology, a battle of whits between code-maker and code-breaker. I
could go on and on.
Most people I know seem to be "afraid" of mathematics. Like "oh man,
there's no way I could ever understand that stuff". Without even
actually trying. I'm stupid, and I managed it, so how hard can it
possibly be?
I suspect it's some combination of math being taught badly, a cultural
expectation that math is impossible to understand, and a society where
stupidity is seen as desirable.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19/08/2011 11:23 PM, Patrick Elliott wrote:
> No wonder I can't even figure out some "basic" stuff
> I need for some 3D math.
What part of
| U x V | = |U| * |V| * cos a
do you *not* understand? :-P
Only teasing. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/08/2011 11:49 AM, Orchid XP v8 wrote:
>
> Can you imagine anything more MIND-NUMBINGLY BORING than staring at a
> sheet of 40 long division problems? YES, I GET IT! I KNOW HOW LONG
> DIVISION WORKS! STOP BUGGING ME ALREADY! >_<
>
> Seriously. If you know how it works, do you really need to do it 200
> times over just to *prove* that you know how it works?
Wrong, it's not to prove that it works. It is to drum into your "thick
little head" how to do it with out thinking. Compare it to repeating a
dance step until your body does not think of the individual moves. Then
you can build on it.
> It's not even
> like it's particularly important to be able to *do* long division; it
> isn't something you're going to need to do every day of your adult life.
You don't know how to do mental arithmetic, then?
> You just need to have a firm grasp of /how/ it works and /why/ it works.
> Once you've got that, practising it on endless question sheets is just
> an utter waste of time.
It is if you don't want to be numerate. And BTW adding, subtracting,
dividing and multiplying is arithmetic not maths.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> The assignment was basically to implement Bresenham's Algorithm,
> optionally *with* antialiasing for extra marks.
IIRC the algorithm in question can be used to roughly *approximate*
antialiasing of the line, but it's not mathematically accurate.
Drawing an accurate antialiased line (of certain width) is not a trivial
problem. Basically for each pixel you need to calculate how much of it is
covered by the line. Doing this accurately with integer math only can be
complicated.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> On 20/08/2011 11:30 AM, clipka wrote:
> > Am 20.08.2011 11:34, schrieb Orchid XP v8:
> >
> >> I can still remember everybody laughing when he said that our assignment
> >> was to write a program to draw a straight line. But *you* try doing that
> >> with only integer arithmetic. It's surprisingly nontrivial.
> >
> > ... but can be accomplished by surprisingly elegant and (comparatively)
> > fast code in Assembler. (What surprised me even more was to see how a
> > similarly elegant and efficient algorithm could draw a circle. No
> > trigonometrics, not even a radix, just plain Assembler commands you'd
> > find on a Z80 processor.)
> The circle is the locus of all points equidistant from the centre. It's
> not especially hard to do that with simple integer arithmetic.
Doing it *fast* is not all that trivial.
Also, don't confuse the length of the implementation with its complexity.
A fast circle drawing algorithm using integer math only (and only additions
and subtractions at that, no multiplications or divisions) is a relatively
short algorithm in terms of lines of code, but *understanding* it is a bit
more difficult. (Coming up with it on your own is even more difficult, but
not impossible, if you think about it long enough.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/08/2011 12:11 PM, Warp wrote:
> Orchid XP v8<voi### [at] devnull> wrote:
>> The assignment was basically to implement Bresenham's Algorithm,
>> optionally *with* antialiasing for extra marks.
>
> IIRC the algorithm in question can be used to roughly *approximate*
> antialiasing of the line, but it's not mathematically accurate.
>
> Drawing an accurate antialiased line (of certain width) is not a trivial
> problem. Basically for each pixel you need to calculate how much of it is
> covered by the line. Doing this accurately with integer math only can be
> complicated.
In the simple case of lines beginning and ending on pixel boundaries,
it's pretty easy. I'm not aware of any way in which Bresenham's
algorithm deviates from a perfect solution.
On the other hand, if you want lines that begin and end at fractional
coordinates, or have rounded ends or whatever, the problem becames far
more complicated.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The circle is the locus of all points equidistant from the centre. It's
>> not especially hard to do that with simple integer arithmetic.
>
> Doing it *fast* is not all that trivial.
>
> Also, don't confuse the length of the implementation with its complexity.
> A fast circle drawing algorithm using integer math only (and only additions
> and subtractions at that, no multiplications or divisions) is a relatively
> short algorithm in terms of lines of code, but *understanding* it is a bit
> more difficult. (Coming up with it on your own is even more difficult, but
> not impossible, if you think about it long enough.)
Our graphics lecturer asserted that it's a minor modification of
Bresenham's algorithm, and Wikipedia concurs. It would take a while with
pencil and paper to figure out the math, and there's probably a few
tricky special cases, but it doesn't look intractible.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Seriously. If you know how it works, do you really need to do it 200
>> times over just to *prove* that you know how it works?
>
> Wrong, it's not to prove that it works. It is to drum into your "thick
> little head" how to do it with out thinking. Compare it to repeating a
> dance step until your body does not think of the individual moves. Then
> you can build on it.
Doing arithmetic "without thinking" is how we ended up with Verizon Math
Fail.
>> It's not even
>> like it's particularly important to be able to *do* long division; it
>> isn't something you're going to need to do every day of your adult life.
>
> You don't know how to do mental arithmetic, then?
Nobody ever needs to compute the exact quotient of two 4-figure numbers
mentally. It's not necessary. You just need to be able to estimate the
answer with sufficient accuracy. (Something which apparently a great
many people can't do for some reason...)
>> Once you've got that, practising it on endless question sheets is just
>> an utter waste of time.
>
> It is if you don't want to be numerate.
Practising something you're going to need to do every single day of your
life is worth while. Practising something which you will never, ever
need to actually do is pointless.
Nobody computes 6-figure quotients mentally. Nobody needs to.
> And BTW adding, subtracting, dividing and multiplying is arithmetic not maths.
...which was the entire point of my rant, yes. Our "maths" class covered
*only* arithmetic, and nothing else.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> In the simple case of lines beginning and ending on pixel boundaries,
> it's pretty easy.
How so?
Ok, maybe if you assume each pixel to be a circle (instead of a square)
it would become simply calculating the distance between the (edge of the)
line and the center of the pixel. That might work as a quite accurate
approximation.
However, since pixels are squares, not circles, and if you want a very
accurate antialiasing, you would have to calculate how much of the square
is covered by the line. I'm not aware of a very trivial way of doing that.
(I'm not saying it's *complicated*. I'm saying it's *not trivial*, like
eg. a simple one-liner.)
> On the other hand, if you want lines that begin and end at fractional
> coordinates, or have rounded ends or whatever, the problem becames far
> more complicated.
The ends of the line, especially if the line is wider than one pixel
(and especially if you use antialiasing) become a quite ambiguous problem.
Should the line be essentially a rectangle? Or two circles joined by a
rectangle? What if you draw two consecutive lines, what should the joint
point look like?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/08/2011 01:40 PM, Warp wrote:
> However, since pixels are squares, not circles, and if you want a very
> accurate antialiasing, you would have to calculate how much of the square
> is covered by the line. I'm not aware of a very trivial way of doing that.
> (I'm not saying it's *complicated*. I'm saying it's *not trivial*, like
> eg. a simple one-liner.)
Suppose, for argument's sake, that your line is nearly horizontal.
Assume also that pixels are square, and the line is exactly 1 pixel thick.
Now for every pixel that the line intersects, the edge of the line cuts
the pixel into two regions: an "inside" and an "outside" region. In the
simplest case, we want the darkness of the pixel to be proportional to
the area that is "inside".
(In more advanced applications, people sometimes use more complicated
methods that take into account the actual real-world fuzziness of the
pixels and so forth. That obviously complicates things drastically.)
Bresenham's algorithm would draw a horizontal line by iterating over all
the X-coordinates and tracking, for each one, the fractional Y
coordinate of the center of the line. (But represented in integral
form.) In the standard Bresenham's algorithm, this fractional-Y is
simply rounded to the nearest integral-Y, and that is what is plotted.
Let us assume that integral coordinates correspond to the centers of
pixels (rather than one of their corners or something). In that case,
the fractional-Y is the Y value of the line at the center of a column of
pixels.
The slanted area cut by the line actually has the same area as a
rectangle with the same center hieght. (This is why the trapezoidal rule
for numerical integration works.)
Hence, for every X-value, we colour floor(Y) according to floor(Y) - Y,
and ceiling(Y) according to ceiling(Y) - Y (which, you'll notice, is
equal to 1 - floor(Y) - Y). This trivial piece of math gives us
antialisaing almost "for free".
>> On the other hand, if you want lines that begin and end at fractional
>> coordinates, or have rounded ends or whatever, the problem becames far
>> more complicated.
>
> The ends of the line, especially if the line is wider than one pixel
> (and especially if you use antialiasing) become a quite ambiguous problem.
> Should the line be essentially a rectangle? Or two circles joined by a
> rectangle? What if you draw two consecutive lines, what should the joint
> point look like?
Most real drawing systems let you select the kind of end-caps and join
styles you want, and so forth. Implementing this properly is highly
non-trivial, I would expect.
A more "interesting" problem is what happens when multiple
different-coloured lines overlap...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|