Jim Henderson wrote:

> simulated, the math and physics are the same for the airfoil.  But for 
> the person doing simulation, there's this thing called a library that we 
> can link into to figure out the fancy math for us - so we don't need to 
> memorise arcane formulae.  We just need to know the inputs to a function 
> and the outputs from a function.

I'm playing devil's advocate a bit, but ... what if there is no such 
library that would give you the values you need regarding lift, etc. 
What if part of what you need to do in the simulation is to create these 
calculations? Then you must certainly know these arcane formulae.

Granted, if something is needed enough, you won't be the first person to 
do it and a solution will be available...



-- 
~Mike

Post a reply to this message

Orchid XP v8 wrote:
> I don't know. There are things you *must* know if you hope to write 
> nontrivial programs and expect them to work properly. And there are 
> other things which are useful to know, but generally not vital. I'd say 
> all of the above fall definitely into the range of "it's great if you 
> know it, but it's really not *required*".

You don't need to know algebra to know how to write a program? You don't 
need to know how "and" and "or" works to write a program?

You can't understand what a compiler does without knowing any abstract 
algebra. Heck, you can't even know the difference between a literal and an 
expression without knowing abstract algebra. You realize that "pass by 
value" is abstract algebra, right?

How do you know if your while loop terminates if you don't know how 
predicate calculus works?

Actually, I think the answer is more that you know these things, and you 
just don't know the terminology the academics use for much of the stuff.

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Darren New wrote:
> understood why people thought calculus was worthwhile for computer 

By "calculus" I mean the calculus of integrals and derivatives, not 
something like "relational calculus".

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

On Fri, 16 Jan 2009 13:30:11 -0600, Mike Raiford wrote:

> Jim Henderson wrote:
> 
>> simulated, the math and physics are the same for the airfoil.  But for
>> the person doing simulation, there's this thing called a library that
>> we can link into to figure out the fancy math for us - so we don't need
>> to memorise arcane formulae.  We just need to know the inputs to a
>> function and the outputs from a function.
> 
> I'm playing devil's advocate a bit, but ... what if there is no such
> library that would give you the values you need regarding lift, etc.
> What if part of what you need to do in the simulation is to create these
> calculations? Then you must certainly know these arcane formulae.
> 
> Granted, if something is needed enough, you won't be the first person to
> do it and a solution will be available...

When it comes to formulae for airfoil calculations, that's all pretty 
well established now.

But even if you needed to create the library, how many people do you know 
who would rely solely on their memory when creating a library that 
hundreds or thousands of people might end up using?  I know *I'd* be 
referring to my books to make sure I implemented the formula correctly.

Jim

Post a reply to this message

Darren New wrote:

> You don't need to know algebra to know how to write a program? You don't 
> need to know how "and" and "or" works to write a program?
> 
> You can't understand what a compiler does without knowing any abstract 
> algebra. Heck, you can't even know the difference between a literal and 
> an expression without knowing abstract algebra. You realize that "pass 
> by value" is abstract algebra, right?

OK, now I actually *know* abstract algebra, and your statements still 
make no sense to me.

> How do you know if your while loop terminates if you don't know how 
> predicate calculus works?

You don't need to know the formal theory to understand how a simple loop 
works. Basic intuition will tell you that.

> Actually, I think the answer is more that you know these things, and you 
> just don't know the terminology the academics use for much of the stuff.

The discussion seems to be gradually anealing towards the idea that it's 
not the *names* that are the problem, but the near-total lack of any 
semblance of documentation about them that doesn't assume you already 
hold a PhD in advanced mathematics.

For example, the documentation for the Monoid class states

   "The monoid class. A minimal complete definition must supply mempty 
and mappend, and these should satisfy the monoid laws.

   Methods:
   - mempty: Identity of mappend.
   - mappend: An associative operation.
   - mconcat: Fold a list using the monoid. For most types, the default 
definition for mconcat will be used, but the function is included in the 
class definition so that an optimized version can be provided for 
specific types."

Assuming you already know what a monoid is, this is quite transparent. 
If you've never heard of a monoid in your life, none of this makes the 
slightest semblance of sense. And looking it up on Wikipedia still 
doesn't tell you what this has to do with writing useful programs in 
Haskell. (Or any other language.)

(The same library features Endo, "the monoid of endomorphisms under 
composition". Even I have no clue what in the name of God that actually 
means.)

The concensus seems to be that
- Haskell is inherantly mathematical, with a strong emphasis on deep 
abstractions.
- Deep abstractions can be hard to learn, so we should document them better.

However - and this is what makes me so angry - there is a strong element 
in the community who claim that Haskell should *only* be used by maths 
experts. I find that to be arrogant and elitist.

The reasoning behind this seems to be "if you don't study category 
theory, you cannot write computer programs, so it's OK for Haskell to 
demand that everybody learns category theory before using it". This is 
of course easily falsifiable.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> OK, now I actually *know* abstract algebra, and your statements still 
> make no sense to me.

I suspect you just never really thought it thru. You know that a compiler is 
just a bunch of rewrite rules, for example, right?

Basically, everything a computer program does is mapping strings of bits to 
abstract algebras. The I/O of a Turing machine is a mapping from strings of 
whatever-symbols-can-be-on-the-tape to abstract algebras.

>> How do you know if your while loop terminates if you don't know how 
>> predicate calculus works?
> 
> You don't need to know the formal theory to understand how a simple loop 
> works. Basic intuition will tell you that.

That's because the basics of predicate calculus are easy to learn. So easy, 
you probably already knew them before you knew what it was called.

I have a box with some balls in it. I pull out one ball. It's black. I can 
conclude that not all the balls that were in the box were white, right? That 
means if I want to check if all the balls are white in a box, I can stop the 
loop once I find the first black ball.

>> Actually, I think the answer is more that you know these things, and 
>> you just don't know the terminology the academics use for much of the 
>> stuff.
> 
> The discussion seems to be gradually anealing towards the idea that it's 
> not the *names* that are the problem, but the near-total lack of any 
> semblance of documentation about them that doesn't assume you already 
> hold a PhD in advanced mathematics.

In Haskell, yes, that could be the case.  For example, "mempty is the 
identity of mappend" makes perfect sense, if you know what "is an identity 
of" means.

> Assuming you already know what a monoid is, this is quite transparent. 
> If you've never heard of a monoid in your life, none of this makes the 
> slightest semblance of sense. 

Sounds like someone needs to write a textbook about what the terms in 
Haskell means.

> However - and this is what makes me so angry - there is a strong element 
> in the community who claim that Haskell should *only* be used by maths 
> experts. I find that to be arrogant and elitist.

I suppose that is. I guess it depends on their goals. Telling someone else 
what they should or should not use seems arrogant.

> The reasoning behind this seems to be "if you don't study category 
> theory, you cannot write computer programs, so it's OK for Haskell to 
> demand that everybody learns category theory before using it". This is 
> of course easily falsifiable.

Haskell doesn't demand anything. :-)  If you write the documentation for 
people who don't study category theory, I'm sure Haskell won't object.

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

>> OK, now I actually *know* abstract algebra, and your statements still 
>> make no sense to me.
> 
> I suspect you just never really thought it thru. You know that a 
> compiler is just a bunch of rewrite rules, for example, right?

What do rewrite rules have to do with abstract algebra?

> Basically, everything a computer program does is mapping strings of bits 
> to abstract algebras. The I/O of a Turing machine is a mapping from 
> strings of whatever-symbols-can-be-on-the-tape to abstract algebras.

Still not making any sense...

>> You don't need to know the formal theory to understand how a simple 
>> loop works. Basic intuition will tell you that.
> 
> That's because the basics of predicate calculus are easy to learn. So 
> easy, you probably already knew them before you knew what it was called.

Well fair enough. But certain people seem to think that "if you haven't 
even bothered to do an undergraduate course in advanced mathematics, you 
shouldn't be allowed near a computer". Which just seems absurd to me...

>> The discussion seems to be gradually anealing towards the idea that 
>> it's not the *names* that are the problem, but the near-total lack of 
>> any semblance of documentation about them that doesn't assume you 
>> already hold a PhD in advanced mathematics.
> 
> In Haskell, yes, that could be the case.  For example, "mempty is the 
> identity of mappend" makes perfect sense, if you know what "is an 
> identity of" means.

...which *I* do, but your typical programmer has *no clue*.

This is really why the whole discussion started. Some blogger tried to 
switch from Python to Haskell, and was looking for a class called 
"appendable" or something. But no, it's called Monoid. Notice how this 
sounds almost exactly like Monad, yet does something wildly different. 
(Somebody was even kind enough to point out that a Monad *is* a Monoid. 
Yay, that's really going to help...)

>> Assuming you already know what a monoid is, this is quite transparent. 
>> If you've never heard of a monoid in your life, none of this makes the 
>> slightest semblance of sense. 
> 
> Sounds like someone needs to write a textbook about what the terms in 
> Haskell means.

My favourit is the documentation for the Writer monad. The documentation 
basically says "This module is inspired by [some random paper]". The 
paper in question is an essay on how to do polymorphic programming. It 
mentions a writer monad as a brief 6-line example program in passing, 
with no suggestion as to how you use it. Yay for documentation!

We need propper documentation here! The docs for existantial 
quantification are similarly vague. (But hey, it's a compiler manual, 
not a language tutorial... *sigh*)

>> However - and this is what makes me so angry - there is a strong 
>> element in the community who claim that Haskell should *only* be used 
>> by maths experts. I find that to be arrogant and elitist.
> 
> I suppose that is. I guess it depends on their goals. Telling someone 
> else what they should or should not use seems arrogant.

Yeah, what *are* Haskell's goals? An often-quoted one is "avoid success 
at all costs". They seem to be doing a good job!

Thing is, I really love Haskell. But I'm not a mathematician, so I can't 
understand lots of stuff. And the attitude seems to be "well if you're 
not clever like us, you should go back to Python" or similar.

>> The reasoning behind this seems to be "if you don't study category 
>> theory, you cannot write computer programs, so it's OK for Haskell to 
>> demand that everybody learns category theory before using it". This is 
>> of course easily falsifiable.
> 
> Haskell doesn't demand anything. :-)  If you write the documentation for 
> people who don't study category theory, I'm sure Haskell won't object.

Hmm... Do you have *any idea* how many monad tutorials there are?

Not that monads are complicated. They're just very abstract, so it's 
kinda hard to explain what they "are".

Imagine trying to explain what a number "is" to somebody who doesn't 
already know. Well, I mean sure, the integers are easy enough. But what 
about negative numbers? Fractions? Irrationals? Transcendentals? 
Imaginary numbers? Hmm... actually, this is pretty hard!

And yet, most people wouldn't think twice about using "numbers". So it 
can't be that hard...

I think perhaps that's Haskell's problem. It's a language which excells 
at abstracting things, with the result that the standard libraries are 
chock-full of constructs so abstract that they can only be named after 
terms from mathematics. And even if they weren't, it would *still* be 
stupidly hard to explain what they're for...

I guess Haskell will never be popular. :-(

Post a reply to this message

Invisible wrote:
> What do rewrite rules have to do with abstract algebra?

Algebra *is* rewrite rules.

> Well fair enough. But certain people seem to think that "if you haven't 
> even bothered to do an undergraduate course in advanced mathematics, you 
> shouldn't be allowed near a computer". Which just seems absurd to me...

Agreed.

> ...which *I* do, but your typical programmer has *no clue*.

I think learning what an identity value is should be pretty easy. :)

> We need propper documentation here! The docs for existantial 
> quantification are similarly vague. (But hey, it's a compiler manual, 
> not a language tutorial... *sigh*)

So write them.

> Yeah, what *are* Haskell's goals? An often-quoted one is "avoid success 
> at all costs". They seem to be doing a good job!

Haskell doesn't have goals. He's dead. The programming language doesn't have 
goals. It was never alive.

> Imagine trying to explain what a number "is" to somebody who doesn't 
> already know. Well, I mean sure, the integers are easy enough. But what 
> about negative numbers? Fractions? Irrationals? Transcendentals? 
> Imaginary numbers? Hmm... actually, this is pretty hard!

I don't know. That was like third and fourth grade, here.

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> What do rewrite rules have to do with abstract algebra?
> 
> Algebra *is* rewrite rules.

AFAIK, abstract algebra is about the study of anything that has certain 
mathematical properties, and what that gives rise to. You don't actually 
rewrite anything.

>> ...which *I* do, but your typical programmer has *no clue*.
> 
> I think learning what an identity value is should be pretty easy. :)

Yes - if it was documented! (In language relevant to computer 
programming...)

>> We need propper documentation here!
> 
> So write them.

Gotta understand something before you can explain it.

>> Imagine trying to explain what a number "is" to somebody who doesn't 
>> already know. Well, I mean sure, the integers are easy enough. But 
>> what about negative numbers? Fractions? Irrationals? Transcendentals? 
>> Imaginary numbers? Hmm... actually, this is pretty hard!
> 
> I don't know. That was like third and fourth grade, here.

Yeah. But you try summing all that up in a short expression. Quite hard, 
isn't it?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Darren New wrote:
>> Invisible wrote:
>>> What do rewrite rules have to do with abstract algebra?
>>
>> Algebra *is* rewrite rules.
> 
> AFAIK, abstract algebra is about the study of anything that has certain 
> mathematical properties, and what that gives rise to. You don't actually 
> rewrite anything.

The rewrite rules specify what the properties are. List some properties for 
me, and I'll show you what the rewrite rules are. :-)

"Zero is the identity for addition"
A+0 = A
0+A = A


>>> ...which *I* do, but your typical programmer has *no clue*.
>>
>> I think learning what an identity value is should be pretty easy. :)
> 
> Yes - if it was documented! (In language relevant to computer 
> programming...)

I dunno. I don't think I could have gotten out of third grade without 
knowing the identity value for addition and multiplication.

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message