Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Mathematical Hacker

evanmiller.org

Post reply on HN
Print view View original

121–130 of 135 posts

Re: The Mathematical Hacker

#121

Post by hazov »

michaelochurch wrote: post #108
hazov wrote: post #103

Earlier quoted context omitted.

This description defines abstract algebra and some topology well, but I am an applied mathematician and for me mathematics is about number crunching and stability of this number crunching. Without numbers or numerical structures like polynomials and matrices you'll only have set theory, some parts of algebra and some mathematical logic. Philosophers of mathematics spent the 20th century what mathematics is all about…

Philosophers of mathematics spent the 20th century what mathematics is all about and they did not settled on any potential definition. Ok, I have to disagree with you here. What Godel established is that there's no complete axiom system. Every mathematical formalism will have statements P for which neither P nor ~P can be proven. This was not an unexpected result. What makes Godel's Incompleteness Theorem awesome is…

I know about that, AoC, CH, Gödel, Turing, Cantor, Hilbert and such, I had a course on mathematical logic and one on set theory when I was an undergrad and the lectures about Gödel were the high point in both of them, although in set theory there were some high points with the idea of "set of all sets" and some other things.

AoC is used indirectly in almost every place of pure mathematics, but I researched numerical methods for PDEs and Stochastic PDEs which is not pure mathematics, maybe someone who is much more intelligent than me will say where you will use AoC directly in this area outside of some theorems of Analysis that are used but well, I've never ever touched this same axiom again in my life and if I chose to spend my life as a researcher I doubt I will ever need it again to work and publish, and yet I was able to get a Ph.d in Applied Mathematics. The theorem that I know uses the AoC that I cited once but not exactly used is Banach–Alaoglu theorem.

As sbi put if you go to a department of mathematics that includes mathematicians, statisticians and applied mathematicians chances are that almost no one will know too much of set theory excluding some pure mathematicians, this was true on almost every department that I saw in my entire life. So there are mathematicians whose life are not spent trying to use abstractions everywhere. That was the point.

Re: The Mathematical Hacker

#122

Post by gnaritas »

papsosouid wrote: post #120
gnaritas wrote: post #119

Earlier quoted context omitted.

> Prototypes don't go into production, so it is moot. Yes they do. > No, first versions should not skimp on correctness. Yes they should. > It saves virtually no time at all. It saves plenty of time. > we just use scalable tech to build it in the first place instead of garbage. We aren't talking about tech, but technique. There are plenty of times you can do things in a less than optimal fashion that is much quicker…

If it goes into production, then it is not a prototype by definition. Since you are making the claim that doing things right is so much more time and effort, could you give an example of that happening? As I've gotten more experienced over the years, and built up a greater mathematical knowledge, I've found that writing correct code has saved me time, not cost it.

> If it goes into production, then it is not a prototype by definition.

That's not what prototype means to me. A prototype is a first cut that's enough to try an idea out with real users, but is built by optimizing developer time only, not performance or scalability. If an idea is validated, you can come back and optimize things, add caches, optimize db queries to pull minimal required fields or add paging or all of the dozens of little things you can skip to save time that don't add functionality but do add scalability to either traffic or a full database. This has nothing at all to do with mathematical knowledge.

It's not about correct code vs wrong code, it's about the right code for the situation. Bad ideas don't need scalable code and scalable performant code is not as fast to write as quick and dirty code. Quick and dirty doesn't mean wrong, it means working but not optimal.

Sometimes you write these quick and dirty things to let the business guy try his idea out and if it fails, as it often does, then you've not wasted time or money making something scalable and performant that doesn't need to be.

Production code is code that has had the optimization pass after you've decided an idea is worth the effort.

Re: The Mathematical Hacker

#123

Post by papsosouid »

gnaritas wrote: post #122
papsosouid wrote: post #120

Earlier quoted context omitted.

If it goes into production, then it is not a prototype by definition. Since you are making the claim that doing things right is so much more time and effort, could you give an example of that happening? As I've gotten more experienced over the years, and built up a greater mathematical knowledge, I've found that writing correct code has saved me time, not cost it.

> If it goes into production, then it is not a prototype by definition. That's not what prototype means to me. A prototype is a first cut that's enough to try an idea out with real users, but is built by optimizing developer time only, not performance or scalability. If an idea is validated, you can come back and optimize things, add caches, optimize db queries to pull minimal required fields or add paging or all of…

>That's not what prototype means to me

It is what it means in English.

>Bad ideas don't need scalable code and scalable performant code is not as fast to write as quick and dirty code.

Scalable and performant are two entirely orthogonal concepts. Neither of which are really relevant to the topic, correctness.

Re: The Mathematical Hacker

#124

Post by gnaritas »

papsosouid wrote: post #123
gnaritas wrote: post #122

Earlier quoted context omitted.

> If it goes into production, then it is not a prototype by definition. That's not what prototype means to me. A prototype is a first cut that's enough to try an idea out with real users, but is built by optimizing developer time only, not performance or scalability. If an idea is validated, you can come back and optimize things, add caches, optimize db queries to pull minimal required fields or add paging or all of…

>That's not what prototype means to me It is what it means in English. >Bad ideas don't need scalable code and scalable performant code is not as fast to write as quick and dirty code. Scalable and performant are two entirely orthogonal concepts. Neither of which are really relevant to the topic, correctness.

> It is what it means in English.

Oh, you want to be a jerk; OK, discussion over, grow up.

> Scalable and performant are two entirely orthogonal concepts.

Obviously, that's why they were mentioned separately. Get a clue.

> Neither of which are really relevant to the topic, correctness.

Well aren't you full of yourself, bugger off now.

Re: The Mathematical Hacker

#125

Post by lolcraft »

spacemanaki wrote: post #67
chimeracoder wrote: post #63

Earlier quoted context omitted.

This has been discussed to death already, so without opening Pandora's box too much: (1) If a compiler can't automatically eliminate tail calls, that's either a design flaw or a bug, and (2) If I wanted to write a loop, I wouldn't be asking for recursion - even if they're executed in the same way by the machine, I'm expressing something different by writing my code that way.

> If a compiler can't automatically eliminate tail calls, that's either a design flaw or a bug You may know this already, but my understanding is that Clojure opts to not automatically eliminate tail calls in order to use Java calling conventions, which I imagine simplifies or eases interop. I'm not defending this decision, as I don't have much of an opinion on it, but to call it a design flaw or a bug seems a bit di…

I don't know why Clojure does not do TCO, but I would be surprised if the Java VM has something to do with it. I mean, why? TCO is just an AST transformation. Takes a function, returns a function and a for loop. Yeah, yeah, the easy implementation needs goto, but it's not necessary. AFAICT any tail-recursive function can be implemented as a for loop plus continue, break and return.

Now, while Clojure just not implementing automatic TCO would not be a bug or a design flaw per se -- clisp does fairly well without it, because the developers just didn't bother -- if implementing such an AST transformation in the Clojure compiler is impossible, then the compiler's design is faulty. It's like programming FizzBuzz so that you can't later modify it to add a case for multiples of 7. OK, yeah, TCO without goto is not such a piece of cake, but you get the idea.

And I don't think it's a trade-off in the least. If so, what are Clojure programmers winning now? The glorious overhead of thousands of function calls? Those tasty "stack overflow" back-traces, with thousands of calls to the same function?

Re: The Mathematical Hacker

#126

Post by sesqu »

daniel-cussen wrote: post #106
alexkus wrote: post #36

Earlier quoted context omitted.

n(n+1)/2 also exists as a simple direct method of summing a series of 1..n. There's no similar (obvious) shortcut for n! (I don't count lgamma as obvious...)

And n(n+1)/2 was only obvious to Euler!

Hardly. It's a simple equation that has been independently discovered for as long as we've had algebra.

Re: The Mathematical Hacker

#127

Post by daniel-cussen »

sesqu wrote: post #126
daniel-cussen wrote: post #106

Earlier quoted context omitted.

And n(n+1)/2 was only obvious to Euler!

Hardly. It's a simple equation that has been independently discovered for as long as we've had algebra.

That's not the same as being obvious. Obvious means clear at first sight, or clear to a child. If you have to work for it, it's not obvious.

Re: The Mathematical Hacker

#128

Post by spacemanaki »

lolcraft wrote: post #125
spacemanaki wrote: post #67

Earlier quoted context omitted.

> If a compiler can't automatically eliminate tail calls, that's either a design flaw or a bug You may know this already, but my understanding is that Clojure opts to not automatically eliminate tail calls in order to use Java calling conventions, which I imagine simplifies or eases interop. I'm not defending this decision, as I don't have much of an opinion on it, but to call it a design flaw or a bug seems a bit di…

I don't know why Clojure does not do TCO, but I would be surprised if the Java VM has something to do with it. I mean, why? TCO is just an AST transformation. Takes a function, returns a function and a for loop. Yeah, yeah, the easy implementation needs goto, but it's not necessary. AFAICT any tail-recursive function can be implemented as a for loop plus continue, break and return. Now, while Clojure just not impleme…

I did a little homework before posting the comment you're replying to, and found a few sources stating that Clojure lacks general tail call optimization due to limitations in the JVM. I'll share what I dug up with you, although to be honest I'm almost just making an appeal to authority (actually to several authorities!), because I haven't actually read the JVM spec.

Rich Hickey wrote:

"No language that uses the JVM stack and calling convention (e.g. Clojure and Scala) can do TCO since it would require either stack manipulation capabilities not offered in the bytecode spec or direct support in the JVM. The latter is the best hope for functional languages on the JVM, but I'm not sure is a priority for Sun as tail-calls are not idiomatic for JRuby/Jython/ Groovy." [0]

I thought that there are implementations of Scheme and other languages on the JVM that do tail call optimization, but I assumed they utilised some kind of virtual stack. Jörg W Mittag on StackOverflow confirmed this:

"Nah, TCO [on the JVM] is easy. Seph does it, Erjang does it, Kawa and all the other Scheme implementations on the JVM do it. The JVM has Exceptions, which are basically the same as GOTO, which can be used to implement TCO. Or you use trampolines. Or you don't use the JVM call stack at all and just implement your own. The reason why Clojure and Scala only provide limited TCO (basically, only tail recursion is optimized) is because they want to use the JVM call stack for interoperability and performance reasons. As Rich Hickey, Clojure's designer said: Interop, speed, TCO -- Pick two." [1]

James Iry wrote the following on LtU, which explains why even though "Real instruction sets (or C) don't 'support' proper tail recursion either", the fact that the JVM doesn't is an issue for Clojure (and Scala):

"Native instruction sets often let you do whatever you want with the stack. C doesn't in the ANSI standard, but you can do it with a bit of assembly. .NET IL has an explicit instruction for tail calls. The JVM, on the other hand, is very strict about how you use its stack and has no tail call instruction." [2]

During my Googling, I also found this[3], which is pretty interesting!

"CTCO works by applying a first-order one-pass CPS algorithm (via Danvy 2007), then transforming the code to return thunks, and finally creating a custom trampoline to be used when the code is executed. Thanks to the properties of the CPS transformation, CTCO will make all function calls into tail calls, thereby even making non-tail code compiled by CTCO use constant space."

This actually sounds not far from what you suggested! Although it does seem to be a bit more than "just an AST transformation". I haven't read through it, or read the referenced paper [4] it's a bit over my head. You should check it out and report back! I've bookmarked it for now.

Finally, you wrote:

"And I don't think it's a trade-off in the least. If so, what are Clojure programmers winning now? The glorious overhead of thousands of function calls? Those tasty 'stack overflow' back-traces, with thousands of calls to the same function?"

Do you still think it's not a trade-off? Unless that last link I found is a magic bullet that makes TCO fast without interfering with Java interop (or the performance of Java interop) then I really don't think it's fair to say that it's not a design trade-off. Rich Hickey (and Martin Odersky) obviously made a conscious decision about this, and you're welcome to disagree with them, but it's not clear cut.

What Clojure programmers are winning now (by being hosted on the JVM) is a lot, I think. Easy interop is one of the pillars of Clojure that has contributed heavily to it picking up steam. I think the same applies to Scala. I said earlier that I don't have an opinion, and I guess it's only true that I don't have a strong opinion. If I had to pick, I think I'd pick interop.

Sorry for the long comment but I'd already done the research, I figured I might as well share it, although there really already has been a great deal said about this.

[0] https://groups.google.com/forum/?fromgroups=#!msg/clojure/Oi...

[1] http://stackoverflow.com/questions/7261039/haskell-on-jvm

[2] http://lambda-the-ultimate.org/node/3106

[3] https://github.com/cjfrisz/clojure-tco

[4] http://www.brics.dk/RS/07/Abs/BRICS-RS-07-Abs/BRICS-RS-07-Ab...

Re: The Mathematical Hacker

#129

Post by bromang »

benbataille wrote: post #46
p4bl0 wrote: post #40

Earlier quoted context omitted.

It's the same in France. But the language is not necessarily Java, it may also be C, OCaml, Scheme, Python… depending on your university.

To be fair, France is insanely biased towards maths. The typical curriculum if you want a correct career in CS outside of research is to go through an engineering school and the amount of maths (and physics) you need to enter and then to graduate is mostly equivalent to a BSc. I did an engineering degree in France and an MSc in the UK, I can compare. Globally, a French student leaving high school has done slightly mo…

first year maths at a UK university normally includes a lot more than just "calculus and basic linear algebra"

Re: The Mathematical Hacker

#130

Post by wolfgke »

meaty wrote: post #10

Algebra is required all the time for me for pretty much any non trivial problem that isn't CRUD (most apps seem to have no functional complexity past CRUD). The only time I had to delve into deep mathematics was implementing CORDIC algorithm for microcontroller powered floating point ops (sin/cos/ln) on a 68HC11 because we couldn't buy an implementation in that had source code so we could verify it. Even then it wasn…

> I do find that mathematical literature is all theory and no application, even with my engineering background. If we had some applications, people would use it more and take it seriously as well and therefore there would be more mathematical programmers.

I have a mathematics background and I see immediately thousands of not-implemented applications when I read mathematical literature (especially the highly abstract one). Thus applications are there. But getting the abilities to see these applications takes time and dedication. I try to hint lots of colleagues to these connections and applications and get ignored (I could talk to a wall instead - it wouldn't make a difference). The colleagues only want to get their job done somehow and nothing more...

Post reply on HN