|
|
Subscribe / Log in / New account

Concurrency in Julia

Concurrency in Julia

Posted Nov 10, 2021 4:30 UTC (Wed) by rsidd (subscriber, #2582)
Parent article: Concurrency in Julia

Thanks for all the articles on Julia. Interesting point on using multiple dispatch in Julia to check for invalid data types without polluting your main function with checks. But shouldn't the type-check function throw an exception, rather than return a string value? It's equally short and better programming practice I'd think, and wouldn't confuse LWN readers. A minor and tangential matter, but a bit of a turn-off when it's right at the top of the article.


to post comments

Concurrency in Julia

Posted Nov 10, 2021 5:24 UTC (Wed) by leephillips (subscriber, #100450) [Link]

I suppose throwing an exception is a better idea. But then I would have to explain the syntax for that, and my version does what I want.

Concurrency in Julia

Posted Nov 10, 2021 14:57 UTC (Wed) by garrison (subscriber, #39220) [Link] (6 responses)

I think the version in the article is great in that is succinctly illustrates the important point to a reader potentially unfamiliar with Julia. If we want to talk about idiomatic Julia, however, instead of defining a second isprime method that throws an exception, one should simply get rid of the second method. When no method is given with compatible types, a MethodError will be thrown, and this is the best way to communicate that a method has not been implemented for the given type(s).

Another comment about making isprime more idiomatic: instead of specializing on Int (which, as the article notes, is a synonym for Int64), it could specialize on Integer instead. Integer is an abstract type that includes all integers, so with this change, the function would still work if passed e.g. an Int32. (The JIT will automatically compile specialized machine code for each case encountered.)

Concurrency in Julia

Posted Nov 10, 2021 16:06 UTC (Wed) by leephillips (subscriber, #100450) [Link]

All relevant observations! The Integer type would also include BigInt, so you could supply as big a prime candidate as you wanted.

Concurrency in Julia

Posted Nov 10, 2021 16:08 UTC (Wed) by droundy (subscriber, #4559) [Link] (3 responses)

Wouldn't using smaller int types simply make overflow almost inevitable? An Int version of factorial is bad enough in terms of uselessness.

Concurrency in Julia

Posted Nov 10, 2021 22:28 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

What `isprime` algorithm requires values larger than the queried number (assuming non-negative values)?

Concurrency in Julia

Posted Nov 12, 2021 4:34 UTC (Fri) by droundy (subscriber, #4559) [Link] (1 responses)

My brain somehow converted it to a factorial program. Not sure how that happened.

Concurrency in Julia

Posted Nov 12, 2021 6:29 UTC (Fri) by rsidd (subscriber, #2582) [Link]

Even for factorial, the parameter type can be anything, the function body can convert it to bigint if needed.
julia> function factorial(n::Integer)
           return prod(1:convert(BigInt,n))
       end
factorial (generic function with 1 method)

julia> factorial(convert(Int32,100))
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000

Concurrency in Julia

Posted Nov 11, 2021 5:36 UTC (Thu) by rsidd (subscriber, #2582) [Link]

I'm only an occasional user of Julia but should have thought of that point, that if you don't define the second function a method exception will be thrown anyway for wrong type of argument. But leaving it out would confuse readers...


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds