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

Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

sinews.siam.org

Post reply on HN
Print view View original

231–240 of 249 posts

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#231

Post by Iwan-Zotow »

newen wrote: post #194
Iwan-Zotow wrote: post #172

Earlier quoted context omitted.

> 1-indexed ranges can still be composable you could make them work, but improper abstraction leaks out in so many fugly ways. F.e. in Python you could compose functions, not only ranges. What do you pass in? Simple, [0, len(a)). What you get out? Simple, len(a). So you could operate on ranges composing function calls like in FP. Even works for unknown beforehand sequences/streams, just count along the sequence how m…

I don't buy it. Inclusive ranges are much more intuitive than left side inclusive and right side exclusive ranges. And they compose just fine; you just have to add a plus one at the right places. E.g. function mean(a, l, r) s = 0 N = r-l+1 for k in l:r s += a[k] end s/N, N end function mean2(a) N = length(a) lr1 = (1,div(N,2)) lr2 = (div(N,2)+1,N) v1, N1 = mean(a, lr1...) v2, N2 = mean(a, lr2...) N = N1+N2 (v1 * N1 +…

> Arguments of elegance etc. are most of the time personal preferences and very biased.

No, they are not. I'm talking about ability to build (and build upon) underlying algebraic structure.

ok, could you make a monoid out of your/Julia closed ranges? What would be a unit in this monoid? How would you make a null/empty range?

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#232

Post by StefanKarpinski »

mruts wrote: post #201
johnsea wrote: post #125

Earlier quoted context omitted.

Because Pascal. And as Pascal was used as a teaching language, I don't think your 'make code harder to read and harder to write' argument holds. But certainly nowadays 'end's are not seen often; maybe this has an influence in your statement?

Why do you think that "end" is superior to more lightweight syntax? One might argue that using "end" doesn't really matter, but I am extremely skeptical one could argue it is superior to a curly bracket or a tab in any way at all. PS: And in regards to your last statement, maybe "end"s aren't seen very much anymore is because language designers' agree with me, not that somehow my opinion is influenced by the syntax o…

Given the historical precedent of Pascal, Ruby, Matlab and others, using `end` to close blocks is not exactly controversial or uncommon. 5 of the current top 20 languages on the Tiobe Index use `end` to close blocks versus 11/20 for curly braces and 1/20 for indentation. Most of the `{}` languages are C descendants: using `{}` for blocks is popular because C has been wildly successful, not the other way around. Using `{}` for blocks wasn't some brilliant language design choice that caused the success of C—it was a fairly mundane choice that happened to be made by a language that succeeded for entirely unrelated reasons and the syntax spread from there.

As to the benefits of not using `{}` for blocks, pairs of ASCII brackets are one of the most precious commodities in programming language syntax design. Wasting them on blocks is not ideal. For example, C++ was out of brackets to use for template parameters, and had to use `` instead—despite the syntactic clash with their meaning as less than and greater than operators. This has caused no end of parsing problems and irregularities in C++ and related languages and has only been made to work because they're all static languages with separate "expression context" and "type context" and inequality operators don't make sense in type contexts. In a dynamic language, there's only one context and you can't distinguish the use of `` as brackets from its use as inequality operators based on that. Julia uses `()` for function calls (pretty important), `[]` for array indexing (also pretty crucial), and `{}` for type parameters.

Using indentation is a fairly clever choice but not without its drawbacks. It causes lots of problems with cutting and pasting code. It means that your IDE cannot generally autoformat or autoindent your code for you. There are also many people who find the "trailing off into space" visual appearance of Python code unsettling and prefer the symmetry and closure provided by `end` or other block delimiters.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#233

Post by Iwan-Zotow »

mbauman wrote: post #191
Iwan-Zotow wrote: post #170

Earlier quoted context omitted.

please take a look at my rant below, do not want to write it twice

Your rant comes down to a distaste of +1s in certain situations. My point is that Julia's emphasis on arrays allows you to compose ranges with mathy operations in very powerful ways. You're concerned about composing APIs that take endpoints as arguments — I say you should just accept a range in the first place! Say I have an index `idx` into a very large array and I want to select a symmetric window of `N` indices be…

It is not about distaste, though idea about keeping and carrying 1 around is a recipe for bugs. It is all about composability.

Could you make proper monoid out of Julia ranges? What would be a unit in that monoid? Could you tell me how empty range looks in Julia (in Python/C++ it looks trivial)?

> Python cannot even index lists by ranges (or other lists)

sure, Python has deficiencies as well.

C++ STL iterators/ranges are made in the same way, and for a good reason - composability first. It described very well in Alex Stepanov book (https://www.amazon.com/Mathematics-Generic-Programming-Alexa...), as well as how it helps when we move to parallel algorithms (http://stepanovpapers.com/p5-austern.pdf).

It is even more explicit in upcoming Ranges library in C++20

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#234

Post by kazinator »

Recurecur wrote: post #219
lenticular wrote: post #150

Earlier quoted context omitted.

They are ugly, I agree. Personally, I prefer lisp (especially Clojure) syntax, but not many people agree with me there.

What's actually sad (I learned this quite recently) is that the inventor of Lisp wanted to include a mechanism to evaluate formulas along the lines of FORTRAN. Something like: (math "x = sin(a) * b ^ 2") Lack of something like that turned me away from Lisp (LISP at the time) a (cough) long time ago, since I didn't like the impedance mismatch between Lisp code and math for numerics. At any rate, Julia looks like a fin…

Throughout Lisp history, this has been done.

(Let's not count things like computer algebra systems written in Lisp that have some sort of actual math notation for input and output, just alternative syntax for programming in Lisp itself.)

As early as 1973, there was https://en.wikipedia.org/wiki/CGOL

That can actually be made to work today: http://abcl-dev.blogspot.com/2010/04/cgol-on-abcl.html

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#235

Post by 3JPLW »

Iwan-Zotow wrote: post #233
mbauman wrote: post #191

Earlier quoted context omitted.

Your rant comes down to a distaste of +1s in certain situations. My point is that Julia's emphasis on arrays allows you to compose ranges with mathy operations in very powerful ways. You're concerned about composing APIs that take endpoints as arguments — I say you should just accept a range in the first place! Say I have an index `idx` into a very large array and I want to select a symmetric window of `N` indices be…

It is not about distaste, though idea about keeping and carrying 1 around is a recipe for bugs. It is all about composability. Could you make proper monoid out of Julia ranges? What would be a unit in that monoid? Could you tell me how empty range looks in Julia (in Python/C++ it looks trivial)? > Python cannot even index lists by ranges (or other lists) sure, Python has deficiencies as well. C++ STL iterators/ranges…

An empty range in Julia is `1:0`. So yes, they can form monoids just fine. I highly recommend you work with them _directly_ instead of carrying around the two endpoints separately. For example, you can divide any range into two parts with:

    split(r) = r[1:end÷2], r[end÷2+1:end]
That'll happily recurse and eventually spit out empty ranges given an input like `split(32:56)`.

A zealous adherence to one strategy or another will simply blind you to the ways in which the other might be easier at different times.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#236

Post by newen »

Iwan-Zotow wrote: post #231
newen wrote: post #194

Earlier quoted context omitted.

I don't buy it. Inclusive ranges are much more intuitive than left side inclusive and right side exclusive ranges. And they compose just fine; you just have to add a plus one at the right places. E.g. function mean(a, l, r) s = 0 N = r-l+1 for k in l:r s += a[k] end s/N, N end function mean2(a) N = length(a) lr1 = (1,div(N,2)) lr2 = (div(N,2)+1,N) v1, N1 = mean(a, lr1...) v2, N2 = mean(a, lr2...) N = N1+N2 (v1 * N1 +…

> Arguments of elegance etc. are most of the time personal preferences and very biased. No, they are not. I'm talking about ability to build (and build upon) underlying algebraic structure. ok, could you make a monoid out of your/Julia closed ranges? What would be a unit in this monoid? How would you make a null/empty range?

Empty range is 1:0 or a+1:a or a:a-1 for any integer a. Closed ranges (for integers) are equivalent to open ranges since [a,b] is the same as [a,b+1). You just put the plus ones in the right places.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#237

Post by emmanueloga_ »

byt143 wrote: post #228
emmanueloga_ wrote: post #180

I'm always looking for good computer tools to assist with learning Math with computers. I found this: [1]. Are there any other resources like this to learn fundamentals of Math with Julia? ([Linear] Algebra, Calculus, Geometry, Basic Physics, Discrete Math). 1: https://calculuswithjulia.github.io/

https://discourse.julialang.org/t/new-linear-algebra-textboo...

This course looks fantastic! Thanks for sharing :-)

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#238

Post by pavon »

mruts wrote: post #50

Julia is interesting, but the block syntax is a little off-putting. I'm not sure why someone would design a language that uses 'end' to delineate a block. Curly brackets make sense. Tabs make sense. But 'end'? All it does is make code harder to read and harder to write.

I love the use of end for blocks! It avoids the arguments about brace placement on one hand and problems with space sensitive indention on the other. It is simple, consistent, easy to read and write.

Yes, easy to write. Seriously, I can type short words like end just as quickly as I can type shift-}, two keys off in the extremes of the keyboard layout.

I think it gets a bad reputation from languages like bash that have a horribly inconsistent mix of `fi`, `end`, `esac`, and require opening words like `then` and `do`, which people can argue about where to place.

end worked great in pascal and matlab, and it works great in julia as well.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#240

Post by byt143 »

emmanueloga_ wrote: post #180

I'm always looking for good computer tools to assist with learning Math with computers. I found this: [1]. Are there any other resources like this to learn fundamentals of Math with Julia? ([Linear] Algebra, Calculus, Geometry, Basic Physics, Discrete Math). 1: https://calculuswithjulia.github.io/

There's also this: https://www.youtube.com/playlist?list=PL7RZyOlq_Xnw3B5per3IU...
Post reply on HN