Furthermore, what audience and level of mathematics education are we discussing? The goals (and hence appropriate metrics of success) are certainly different for high schoolers targeting non-STEM careers vs. engineering undergrads vs. math grad students. The authors reference "aspiring mathematicians" and "domain specific mathematical problem-solving skills", indicating they're arguing about education for math majors, or at least students in STEM fields. In that case, the argument is somewhat meaningless - who's arguing math majors shouldn't learn math-specific skills? But, as I understand it, the argument for general problem-solving skills is that students outside of math don't actually need many specific math skills. Instead, math is a vessel for teaching logic, reasoning, and problem-solving skills. Then again, this might not be the type of problem-solving the authors are referencing - as I said above, it's not very clear.

On a similar note, they cite evidence that studying worked examples is more effective than "general problem-solving strategies", citing an "improvement in subsequent problem-solving performance" without explaining how this performance is measured. If students are tested on specific problem types, of course they'll perform better when taught strategies for those specific problem types. But it's not clear that this is meaningful. For STEM majors, sure, solving specific problems is a skill worth cultivating. But for most students, solving specific problems isn't as important as learning logic, reasoning, and general problem-solving skills. In my anecdotal experience tutoring math, students tend to just memorize strategies for specific problem types instead of learning transferable logic and reasoning skills because that's what's tested. I'd be curious to see which method of learning facilitates better performance on a more general problem-solving test of some sort.

Now, I'm not an education researcher or an educator of any sort. But I am passionate about good STEM education, especially in math. I genuinely feel that math education fails most students, at least here in America. If I'm being generous, this article is a well-intentioned but poorly-executed argument for effective math education strategies. If I'm not being so generous, this article advocates for the status quo in math education that forces students to slog through years of math classes for little discernible benefit. Either way, it's a disappointing article with a poorly-explained thesis.

I wonder this too, I think they might mean university-level as well. For younger audiences, I feel one of the biggest problems for most people to understand math is they don't understand why any of it is relevant. If educators can make it seem more like teaching general problem solving abilities, that will likely improve the overall acceptance and lead to better overall math skills as a result.

As a specific example, our high-school math curriculum taught a lot of calculus, but framed it incorrectly as being a useful tool that people would use. Eg as if a business man would write down an equation for their revenue based on inputs, and then take the derivative to compute the maximum. I'm assuming they told students this to try and get them motivated, but it clearly was a lie since everybody knows you could just plot a graph and look at it to find the maximum. If they instead were honest that the point of learning calculus was to help with understanding more advanced concepts in math/engineering/science, while also being a valuable learning tool for general problem solving, I think that would have been a better result.

One day at FedEx the BoD (board of directors) was concerned about the future of the company and as part of that wanted an estimate of the likely growth of the company.

In the offices there were several efforts, free-hand, wishes, hopes, guesses, what the marketing/selling people thought, etc., and none of those efforts seemed to be objective or with a foundation or rationality.

We knew the current revenue. We could make an okay estimate of revenue when all the airplanes were full. So, the problem was essentially to interpolate over time between those two numbers.

For the interpolation, how might that go? That is, what, day by day, would be driving the growth? So, notice that each day current customers would be shipping packages, and customers to be would be receiving packages and, thus, learning about FedEx and becoming customers. That is, each day the growth would be directly proportional to (1) the number of current customers creating publicity and (2) the number of customers to be receiving that publicity.

So, for some math, let t be time in days, y(t) the revenue on day t, t = 0 for the present day, and b the revenue when all the planes were full. Then for some constant of proportionality k, we have

     y'(t) = k y(t) (b - y(t))

A little calculus yields the solution.

     y(t) = y(0) b exp(bkt) /
            ( y(0)( exp(bkt) - 1) + b))

That was a Friday, and the BoD meeting started at 8 AM the next day, Saturday.

First thing at the meeting, two crucial BoD members asked how the graph was drawn. For several hours, no one had an answer. The two members gave up on FedEx, got plane tickets back to Texas, returned to their rented rooms, packed, and as a last chance returned to the BoD meeting. FedEx was about to die.

I did all the work for the graph, the idea, calculus, arithmetic (HP calculator), but didn't know about the BoD meeting. Someone guessed that I did know about the graph, and I got a call and came to the meeting. The two crucial BoD members were grim, standing in the hallway with their bags packed, and their airline tickets in their shirt pockets.

I reproduced a few points on the graph, and FedEx was saved.

So, some math saved a business.

Then, for the arithmetic, some code can be short and, compared with cells in a spreadsheet, easier and with more control over the time steps, e.g., in Rexx with cf for customer fraction:

     Say '        ==== Growth ===='
     Say ' '
     Say '                Customer'
     Say '     Year       Fraction'

     max_years = 5
     steps_per_year = 10 * 365
     cf = 1 * ( 1 / 100 )
     year = 1
     k = 1 * ( 1 / 2000 )
     Do Forever
       Do i = 1 To steps_per_year
         cf = cf + k * cf * ( 1 - cf )
       End
       Say Format(year,9) Format(100*cf,10,2) || '%'
       If year = max_years Then Leave
       year = year + 1
     End

        ==== Growth ====

                Customer
     Year       Fraction
        1          5.89%
        2         27.97%
        3         70.66%
        4         93.73%
        5         98.93%

Adjust some of the constants in the program and can get more output, say, for each month, day, etc. The code above uses 10 steps per day.

For more, someone could use the calculus solution and compare.

In a sense, for the FedEx problem and the assumptions about what was driving the growth, the calculus solution is a smooth version of the somewhat more appropriate discrete time version.

But when I did the calculation at FedEx, my best source of arithmetic was an HP calculator in which case the calculus solution was a lot easier.

Of course, this FedEx calculation was just one example and there are many others.

My view from 10,000 feet up is that in business, at times some math can be an advantage if not the work of a steady job.

If some math is an advantage, then that advantage tends to go to the owners of the business. If a mathematician wants to get paid for some math they have in mind, maybe they should start a business and be the owner.

For the arithmetic for the calculus solution, in Rexx,

     y.0 = ( 1 / 100 )
     b = 1
     k = ( 1 / 2000 )

     Do t = 1 To 5
       t1 = t * (10 * 365 )
       e1 = RxCalcExp( b * k * t1, 16 )
       y.t = ( y.0 * e1 ) /  ( y.0 * ( e1 - 1 ) + b )
       Say Format(t,9) Format(100*y.t,6,2) || '%'
     End

         ==== Growth ====

             Customer Fraction
     Year   Calculus   Discrete
        1      5.90%      5.89%
        2     27.99%     27.97%
        3     70.68%     70.66%
        4     93.73%     93.73%
        5     98.93%     98.93%

Putting TC aside (don't most programmers make plenty anyways?), isn't it just cool to learn new and cutting-edge things? Personally, I think so. Curiosity is central to what it means to be a hacker.

Nothing overstated; just the circumstance in the real world that these four languages are the only ones used in the most demanding HPC.

C and Fortran are also not as fast as they could be if you use them incorrectly. Using concrete types is not “significant tweaking”.

There the "naive" Julia code, simply implementing the code like I would in Fortran is a factor of 10 or 15 slower than the optimised cython version (which would be the same as a regular C version), the optimised Julia version is still a factor of 5 slower than the cython and pythran version. Can you show me how to optimise it so that Julia performs on par with pythran or cython?

    apply_filter(x, y) = vec(y)' \* vec(x)

    function cma!(wxy, E, mu, R, os, ntaps)
        L, pols = size(E)
        N = (L ÷ os ÷ ntaps - 1) \* ntaps  # ÷ or div are integer division
        err = similar(E)  # allocate array without initializing its values
        @inbounds for k in axes(E, 2)  # avoid assuming 1-based arrays. Just need a single inbounds macro call
            @views for i in 1:N   # everything in this block is a view
                X = E[i*os-1:i*os+ntaps-2, :]
                Xest = apply_filter(X, wxy[:,:, k])
                err[i,k] = (R - abs2(Xest)) \* Xest  # abs2 avoids needless extra work
                wxy[:,:,k] .+= (mu \* conj(err[i,k])) .\* X  # remember the dots!
            end  
        end
        return wxy, err  # note order of returns, seems more idiomatic
    end

For another take, Jack Dongarra was just awarded 2021 ACM Turing prize. He’s the creative force behind LINPACK and BLAS, and says that Julia is a good candidate for the “next computing paradigm”: https://www.zdnet.com/article/jack-dongarra-who-made-superco...

> I sometimes wish [Julia] had just appeared one day as version 1, and made periodic updates every year or three.

> Its “multi-paradigm” nature. Yeah, I know other languages have this too, but it does tend to bloat a language.

And some are just funny:

> The language is not stable, and by that I mean it seems to have a lot of bugs [links to github issues with label:bug]. You can’t really call something that has bugs stable.

No, that is not a common thing post Julia v1.0.

A lot of newer libraries are not well documented in Julia, but the core stuff is much better documented than Python IMHO. So his view on Julia documentation lacks nuance. It is both good and bad depending on what you look at.

The post talks about the complexity if importing stuff with using and include. Yes, if you start from scratch it is more complex, but the benefit is that it scales better. I have helped compete beginners with Julia who had totally given up on Python due to the complexity of package management, modules and environments. Julia has a beautiful solution to this which is far easier to get right and manage.

A novice will find it easier to import packages they want to use with Julia compared to Python. But very often people evaluating this stuff are experienced Python developers and they don’t see the Python hassle easily. If you take somebody who is a beginner in both languages then experienced will be quite different.

The “multi paradigm” comment makes zero sense. Sure Julia is multi paradigm but it is far more streamlined than the common OOP-functional mess you see in other mainstream languages today such as Python , Java, C#, Swift.

In Julia it is all functions. You don’t distinguish between free functions and methods. For a beginner this is much easier to deal with.

Either way, there's still often at least some native code you have to write and wrap. That's where a professional programmer might get involved. But probably more often than not, it's the engineers and scientists themselves.