no method round(MathConst{:π},)
+1
Try Julia
81–90 of 105 posts
Re: Try Julia
#82Am I crazy for feeling like Julia is the new HN darling like clojure, go, ruby, lisp, and scala before it? It seems like in the last week it just started popping up on HN every couple days.
Nimrod's turn is coming soon. And it is well-deserving. It has already had some pre-HN-darling attention here, which is what brought it to my attention. I'm very intrigued by it. http://nimrod-lang.org/
Re: Try Julia
#83Julia appears to be a perfect fit for much of what I do at work. I tried it, got very excited, and then facepalmed earlier today. Let's define two functions in the REPL: function foo() return 42 end function bar() return foo() end Evaluating bar() gives 42, just as one would expect. Now let's redefine foo(): function foo() return 69 end Evaluating bar() still gives 42! Not getting something so basic correct tells me…
Not getting something so basic correct tells me to avoid the whole thing for fear of getting subtly screwed by some other oversight. No one denies that this is a problem, and it will be fixed. But I disagree that it represents a fundamental flaw. For iterative development, it is a minor inconvenience, so other priorities have taken precedence. If you are redefining functions in this way in tested code, there may be b…
(to the point of making a pilgrimage to visit Kahan early on)
What does that mean?
Re: Try Julia
#84Earlier quoted context omitted.
Not getting something so basic correct tells me to avoid the whole thing for fear of getting subtly screwed by some other oversight. No one denies that this is a problem, and it will be fixed. But I disagree that it represents a fundamental flaw. For iterative development, it is a minor inconvenience, so other priorities have taken precedence. If you are redefining functions in this way in tested code, there may be b…
(to the point of making a pilgrimage to visit Kahan early on) What does that mean?
"The Father of Floating Point"
http://en.wikipedia.org/wiki/William_Kahan
Re: Try Julia
#85The pi constant didn't work for me
Re: Try Julia
#86Earlier quoted context omitted.
My point wasn't that it can't be done. My point was about usability and what programmers have come to expect from a modern language. I understand that things get trickier when trying to implement arbitrary-precision arithmetic while keeping performance high.
Do you have an example of a language with arbitrary-precision overflow by default and comparable performance?
Common Lisp with SBCL:
(defun double (x)
(+ x x)) ; BigInts (or floats, for that matter)
(defun double (x)
(declare (type fixnum x))
(+ x x)) ; will emit an error if X is more than a long
(defun double (x)
(declare (type fixnum x)
(optimize speed (safety 0)))
(the fixnum (+ x x))) ; trusts that everything is a long - basically like CRe: Try Julia
#87Earlier quoted context omitted.
Julia supports arbitrary precision arithmetic just fine, but you need to explicitly use it. Overflow checks don't matter in Python or Ruby where everything is relatively slow. See also: http://www.johnmyleswhite.com/notebook/2013/01/03/computers-...
I don't think many here argue that Julia doesn't support it. In fact it would be rather disastrous if it didn't, because it wouldn't make for a very nice scientific language if the biggest int value was 2^64-1. The question is why aren't large numbers the default, or why doesn't it do automatic up and down conversion and so on.
> because it wouldn't make for a very nice scientific language
Scientific languages generally don't use aribitrary precision arithmetic. Examples: MATLAB, scipy/numpy/pandas. The reason is that they're optimized for the key use case of large linear algebra calculations. Making arbitrary precision the default would require an overflow or type/tag test in the inner loop dramatically reducing performance. The goal of these languages is to operate at near peak cpu bandwidth.
When wide ranging precision is needed floats are used despite their flaws, because again, the performance matters so much. FEM, CFD and similar engineering calculations can effectively use as much computation as you have hardware and patience for. Machine Learning will too if you're dataset is larger than trivial.
The Julia folks know what they're doing and it's what the community they're targeting expects.
Re: Try Julia
#88Earlier quoted context omitted.
Do you have an example of a language with arbitrary-precision overflow by default and comparable performance?
> Do you have an example of a language with arbitrary-precision overflow by default and comparable performance? No, but that also means Julia isn't much special then either right? Maybe it is just me but Julia positions itself as a better Python not just a better C, in that position, can you really blame people if they misunderstand and expect same "high level" behavior from it?
Better Python in the sense of Python for scientific computing: eg Pandas et all. They aren't targeting all the use cases of Python (for example, I doubt anyone would suggest writing a monit style tool in Julia).
Re: Try Julia
#89Earlier quoted context omitted.
Yes, Julia doesn't auto-convert to BigInt, it's a trade-off between performance and easy-to-useness, but they've definitely made the right decision. You have to convert to BigInt or BigFloat like this: julia> big(3) ^ 60 42391158275216203514294433201
Why not have them as BigInt and donwconvert to machine sized ints explicitly? In any case. If you think of it as a nicer C, it works very well. It is a slight disappointment if you think of it as a nicer Python.
Beacause it would make writing fast code inconvinient, it's a tradeoff, a right choice clearly imo. How often do you need BigInts?
I try to use Julia instead of Python now if I don't need specific libs, it definitey feels like a nicer language to me (i.e. I can get stuff done faster).