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

Think in Math, Write in Code

justinmeiners.github.io

Post reply on HN
Print view View original

231–240 of 256 posts

Re: Think in Math, Write in Code

#231

Post by higherkinded »

hinkley wrote: post #216
warent wrote: post #8

There's an unpopular and somewhat seemingly contradictory opinion that I have regarding this, because this isn't the first time I've seen this topic brought up. Mathematics and programming are not really all that related to each other and I think there's an overemphasis on the importance of math in programming for 99% of applications. Sure, mathematical thinking can be useful, but it's only one type of logical thinki…

My second job, the project had been run by a couple of vocational developers. They did okay. No version control, lots of corner cases not covered, lots of code that made inferences from incomplete data. But the team needed to grow significantly and none of this stuff was going to survive other people touching the code. One of the bad patterns in the code was very complex nested boolean logic in places. Often with the…

How come math's to blame? That's clearly just some nuts level of incompetence that spawned all of spaghetti described. Lack of any conscious effort. After all, the mathematical thinking mentioned in the article inevitably includes covering the corner cases of the problem at hand as well as of the solution proposed, not to mention simplification and generalization. That's not trying to be smart, that's outright being dumb. (I'm not even sure if you're trolling at this point.)

Re: Think in Math, Write in Code

#232

Post by higherkinded »

lonelappde wrote: post #200
thfuran wrote: post #198

Earlier quoted context omitted.

> there are very specific algorithms for that, they don't look anything like a math formula I'm not sure what you mean by that. I'd describe making a 3D game (engine) with rendering, collision detection, etc as probably one of the math-heaviest areas of programming outside of scientific computing or algorithm R&D.

Numerical solutions in computer programs look very different from the closed form symbolic theorems in math books.

I think it's pretty safe to assume that you haven't heard of ML language family and Hindley—Milner type system. At the lowest possible level, I mean, yes, numeric solutions are computed by the sets of instructions that are pretty distant from the mathematical level of abstraction. But in higher-level languages, everything remotely readable and reliable usually looks like formal math from the textbooks. I'd say that the representation heavily depends on what language you're using to write your programs, yes, though not everything looks like Algol 68 nowadays.

Re: Think in Math, Write in Code

#233

Post by 0x445442 »

nwallin wrote: post #173
0x445442 wrote: post #94

Earlier quoted context omitted.

I'll bet the engineering process of the software written for the Apollo 11 lunar lander was much closer to the bridge building process than you might think. I'll also bet there's a whole host of software projects which use similar processes today. It's just that most of us writing DB skins for "The Enterprise" are rarely, if ever exposed to real engineering for the simple fact that quality software is expensive and t…

> I'll bet the engineering process of the software written for the Apollo 11 lunar lander was much closer to the bridge building process than you might think. Of course, but the Apollo 11 lunar lander was created without the aid of ubiquitous desktop computers. I imagine the SpaceX guidance/control software was written in a way that less resembles bridge-building/Apollo 11 lunar landers and more like the organic proc…

> I imagine the SpaceX guidance/control software was written in a way that less resembles bridge-building/Apollo 11 lunar landers and more like the organic processes we see elsewhere in the software industry.

For the guidance/control systems, I bet you're wrong.

Re: Think in Math, Write in Code

#234

Post by nineteen999 »

0x445442 wrote: post #89
LandR wrote: post #9

Earlier quoted context omitted.

> Is this really a common thing? How can you try to implement something without first having had thought of the solution? Unfortunately, it's incredibly common. The result is always almost a mess. Functions that are never called, parameters that are never used, as they discovered their mistake as they were coding but then never went and cleaned up the stuff they don't use anymore. Broken logic, poor performance. Func…

Welcome to "Agile".

Rhymes with "fragile".

Re: Think in Math, Write in Code

#235

Post by runeks »

I agree that math is a useful tool in programming, but domain knowledge always trumps math knowledge. Case in point:

> Recently, I worked on an API at work for pricing cryptocurrency for merchants. It takes into account recent price changes and recommends that merchants charge a higher price during volatile times.

You shouldn’t look at the past price for a cryptocurrency to determine the current one. If few trades happen in a period you’re using outdated data.

The price of interest for merchants who want to sell cryptocurrency is the best bid (highest-priced buy order) in a market where fiat bids on crypto (e.g. BTC/USD, ETH/USD). You should be downloading order book data from exchanges (e.g. [1]), and quoting the best bid to merchants.

Also, what you call high volatility (of past trade prices) might simply be a proxy for a large difference between the highest-priced buy order and lowest-priced sell order (large “spread”). Instead of looking at volatility of past trades, I recommend you look at monitoring the spread of the order book of interest. Although this might not be all that relevant, since merchants (who sell crypto for fiat) are only interested in the price they can sell for, not the price they can buy for.

[1] https://docs.pro.coinbase.com/#get-product-order-book

Re: Think in Math, Write in Code

#236

Post by scooble »

higherkinded wrote: post #18
warent wrote: post #8

There's an unpopular and somewhat seemingly contradictory opinion that I have regarding this, because this isn't the first time I've seen this topic brought up. Mathematics and programming are not really all that related to each other and I think there's an overemphasis on the importance of math in programming for 99% of applications. Sure, mathematical thinking can be useful, but it's only one type of logical thinki…

Logic is part of math, not the other way around. Basically the same goes for your "how it affects the web" since that becomes about directed graphs. On algorithms and data structures: do you actually evaluate their complexity if that's not about math? Math is everywhere.

I think the ghost of Gottlob Frege just gave you a stern look.

Re: Think in Math, Write in Code

#237

Post by 1PlayerOne »

jhayward wrote: post #214
1PlayerOne wrote: post #203

Earlier quoted context omitted.

I used to believe as you do until AlphaZero learn to play Go and Chess by itself and discovering new strategies in the process.

By using tensor calculus.

Can you provide link to paper explaining the use of tensor calculus in AlphaZero?

Re: Think in Math, Write in Code

#239

Post by kd0amg »

lonelappde wrote: post #200
thfuran wrote: post #198

Earlier quoted context omitted.

> there are very specific algorithms for that, they don't look anything like a math formula I'm not sure what you mean by that. I'd describe making a 3D game (engine) with rendering, collision detection, etc as probably one of the math-heaviest areas of programming outside of scientific computing or algorithm R&D.

Numerical solutions in computer programs look very different from the closed form symbolic theorems in math books.

Don't numeric solutions in math books also look very different from closed-form solutions?

Re: Think in Math, Write in Code

#240

Post by mannykannot »

nomel wrote: post #149
mannykannot wrote: post #38

Earlier quoted context omitted.

There's some non-trivial math behind the methods for defining and selecting well-formed data.

And they tend to always accept data that is malformed to look like regular data.

Putting aside the question of whether this is a tendentious exaggeration, it is more of a problem in ad-hoc code.
Post reply on HN