programming and maths (how are they related or NOT ) !

how is maths relevant to programming?

Even if you take maths in terms of formal logic. It won't help

racqueteer...

It helps to be old enough to have seen (and lived through) the
development of programming . When I came into computing as an
amateur (early 70's), it was important to write "tight" code because
program space was limited, and this usually meant fairly convoluted
statements had to be produced (in basic when I began teaching myself)
that were heavily laced with Boolean logic. Professional programming
was mostly done in Fortran (later in Cobol). To my knowledge, there
were no libraries of subroutines or "calls". No object-oriented
programming. A lot of stuff was done with the equivalent of "pokes"
and "peeks" (direct memory accessing; memory addresses usually given
in base 16 - hexadecimal). Accessing arrays (matrices in one or more
dimensions) as well as employing loops, required indexing. Things as
"simple" as making lines perpendicular required stuff like dot
products of vectors. Math was so ingrained in the process that it
wasn't exactly avoidable.

As the available program space grew and as structured languages
appeared (along with function and procedure libraries), one could
begin to program mechanically, without the need for a deep
mathematical understanding of what one was doing. Programmers no
longer needed a good grasp of computer architecture or how the
computer processed instructions; it all happened "magically". As the
old-timers of education know, "computer education" in schools began as
the province of teachers of mathematics who, naturally enough, taught
it as a math course. (Later there was a second area of penetration -
in the "business" department, where "programming" as we're discussing
it didn't really happen).

As an aside, some of the best kid programmers I observed over the
years came from the users of the TI99 computers because programs were
so scarce for them. The users HAD to program almost anything they
wanted done. As a consequence, many of them became VERY proficient at
basic programming. I remember one in particular who duplicated an
Apple game (Choplifter?) in his spare time, and his game went
commercial. Had his own company later on which was eventually bought
out by Netscape .

q_q_anonymous...

what is behind a loop, is not a deeply mathematical thing. Nothing
beyond primary school level is required to understand it. . Even if you
know about stacks.

you mention boolean logic, that's innovative. Not part of a standard
maths curriculum, and really barely necessary. A programmer if he has a
long logical exprsesion, needn't draw a karnaugh map to simplify it. He
can use the logic ingrained in a his mind He can probably figure out
that NOT(A or B) = NOT A AND NOT B . Besides, he can get it right
without boolean algebra.

Basic boolean logic isn't typically taught as maths . It's extemely
basic. It requires you to know what an operator is. You can pick it up
without any maths background beyond primary school level.

To program, you need to understand what an number is too. So it's
related to some basic aspects of primary school maths concepts.
Anybody that has come out of primay school has the "maths backgroud"
necessary. That's why 11 year olds can program.

computer architecture. - knowing the registers in the cpu, - is not
mathemetical. i.e. you don't need a maths backgroudn beyond primary
school level.

Maybe I should've been cleare abotu what I meant by mathematical.

It has been mentinoed though, that for more advanced programming, like
compuetr graphics , 3D modelling, stuff like that, maths is required.
Or , it may be required.

Programming uses the most basic logic. if a then b else c. You don't
need to study logic or mathematics to get it. If you want to know that
the program works, you test the procedures with data. You don't need
anything more than a flow chart to understand a loop.

Maybe if it's a life/death program, you might want to Specify main
parts and pesky parts and hacks using formal logic. Outside of
life/death programs, it's certainly unnecessary.

Maybe those that write programming languages should *consult*
mathematicians. And get symbols in there. Like set symbols. I think PJ
Landin might have been into programming languages having better
facilities, being less restricted. That's 1 association! It's
important. But it only takes consulting mathematicians. Compiler
writers learning a TINY bit of discrete maths. A mathematician should
be consulted. There's no need even for the guy that write the compiler
be great at maths or have a good maths background.

With programming. Some can do it. Others have some mental probs that

q_q_anonymous...

In most cases, you don't need maths to write efficient code.

But even in those rare cases of a program involving compression or
computer graphics, I imagine that in those instances these are classic
problems and have classic algorithms that mathematicians have already
worked out the "time complexity" for.

hrubin...

"Time complexity" theorems are asymptotic. Knowing what to
do to get fast algorithms is both science and art; it also
can depend drastically on the machine, and be impossible if
using high level languages.

The hardware makes a difference, also. Good mathematical
algorithms have yet to be written for many things, and the
specific hardware needs to be considered. It may even be
that what should be a clearly faster algorithm runs slower
due to paging problems; getting this information can be
difficult.

Typically, programs use some data structure and have to
add/delete/amend data. There are standard ways for that. Similarly with
the more complex programs.

hrubin...

And you better know what you are doing.

I've seen programs with inefficient code because the programmer has no
common sense. e.g. writing to files that he never reads from. Or,
using files to pass data between procedures. But, I can't really think
of a case of a lack of maths background getting in the way of writing
efficeint code. Or causing writing inefficient code.

hrubin...

<> As someone who uses mathematical algorithms, the typical
<> programmer does not know enough mathematics to know how
<> to do something slightly unusual. Try coming up with a
<> good algorithm to compute x - ln(x+1) to close to machine
<> precision on a computer for all x larger than -1; this is
<> not a made-up example, it occurs naturally.

<> >You could say that knowing assembly language when writing high level
<> >code, helps write more efficient code. But that would only tweak the
<> >speed a tiny bit.

<> And right now the computer manufacturers, etc., try to
<> make it hard. The idea is to let the high level language
<> and the supposedly good compiler do it all for you. It
<> does a good job on some problems, but badly on others.

hrubin...

As someone who uses mathematical algorithms, the typical
programmer does not know enough mathematics to know how
to do something slightly unusual. Try coming up with a
good algorithm to compute x - ln(x+1) to close to machine
precision on a computer for all x larger than -1; this is
not a made-up example, it occurs naturally.

You could say that knowing assembly language when writing high level
code, helps write more efficient code. But that would only tweak the
speed a tiny bit.

hrubin...

And right now the computer manufacturers, etc., try to
make it hard. The idea is to let the high level language
and the supposedly good compiler do it all for you. It
does a good job on some problems, but badly on others.

q_q_anonymous...

but what you describe. The science and the art of figuring out the time
complexity and producing a fast algorithm, and moreso, at the level
where the high level language doesn't support the speed or efficiency
that you are trying to acheive.
That is not just slightly unusual. That's not a situation that most
programmers would ever be in. Similarly with the x-Ln(x+1) example.

hrubin...

As I said, the problem occurs naturally, and it might be
used billions of times in a computational run.

Most programmers don't even need to use Ln - though as a programmer,
they'd find the function to do it. But, if they needed precision,
they'd just use the data type that supports extremely large or small
numbers, with lots of 0s. One that uses a sort of "Scientific form" to
store the number in binary e.g. 10100 *2^104. Floating point. The
programmer usually just uses the best data type offered by the
programming language. The language is meant to be more than sufficient.
It's v.rare to need to provide a hack for that. Most programmers would
never run into it. Mabe only mathematician-programmers run into it
occassionally in highly mathematical-numerical number-crunching
programs.

hrubin...

I suggest you try to see what you can do; there is a very
definitely unexpected problem in coming up with a procedure
with good speed (not quite that of ln) and the desired
accuracy for all x. The packages which use extremely large
or small numbers are typically quite slow, and are not at all
needed here.

stop them. Not grasping syntax, not grasping rules, not grasping strict
basic logic when it's relentless. Whatever those problems are, it's
nothing to do with maths.
And there's one ENORMOUS difference. Programming can be more easily
self taught. Somebody that can't do maths may just have a bad teacher,
and be put off by the textbook.
That could happen with programming, but perhaps less so. OTOH, the way
some unis teach it, I think it could go wrong from bad books and bad
teaching ! But it is easier to teach yourself programming. Regardless
of maths background.