Re: [julia-users] Re: For loop = or in?

2015-10-27 Thread Hai Nguyen
On Tue, Oct 27, 2015 at 10:04 AM, Stefan Karpinski 
wrote:

> My general approach is to only use = when the RHS is an explicit range, as
> in `for i = 1:n`. For everything else I use `for i in v`. I would be ok
> with dropping the = syntax at some point, but it seems pretty harmless to
> have it.
>
>
I have 1 vote for removing '='. It is harmless but it introduces confusion.

Hai


> On Tue, Oct 27, 2015 at 8:56 AM, FANG Colin  wrote:
>
>> Thank you. In that case I will happily stick with `in`.
>>
>>
>> On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:
>>>
>>> There is no difference, as far as I know.
>>>
>>> '=' seems to be used more for explicit ranges (i = 1:5) and 'in' seems
>>> to be used more for variables (i in mylist). But using 'in' for everything
>>> is ok too.
>>>
>>> The '=' is there for familiarity with matlab. Remember that julia's
>>> syntax was in part designed to be familiar to matlab users.
>>>
>>> On Tuesday, October 27, 2015 at 8:26:07 AM UTC+13, FANG Colin wrote:

 Hi All

 I have got a stupid question:

 Are there any difference in "for i in 1:5" and "for i = 1:5"?

 Does the julia community prefer one to the other? I see use of both in
 the documentations and source code.

 Personally I haven't seen much use of "for i = 1:5" in other languages.

 Thanks.

>>>
>


Re: [julia-users] Re: What's the reason of the Success of Python?

2015-09-30 Thread Hai Nguyen
I myself do not care much about Julia or python speed since I can write
fast code in Cython (C/C++ speed with Python syntax sugar). There are
several features in Julia I like much (and I think they can be good selling
points).

* CFFI: great that we can call C function easily.
* Parallel: I very like Julia parallel syntax. Never tried to write Julia
parallel code but once I read the code, just have feeling that the parallel
usage is very natural
* macro: @time bla_bla --> I like the macro in the same line
* Julia syntax for computing is much more concise than python.

Things I don't like in Julia
* developers and user encourage to use 'using' to import all methods. I
prefer to see exporting importing in Python (from numpy import dot, ...)
* Julia's string stuff seems very strict to me. For example I wish Julia
has: a = "my 1st string; b = 'my 2nd string', c = a + b
* declare type by `x::Int`. I myself prefer to use 'x : int' typehint in
Python3.5.
* warming up time in Julia is still slow for me.

Hai

On Wed, Sep 30, 2015 at 1:01 PM, David Anthoff  wrote:

> When you have matrices with special structures and symmetries, Julia can
> encode that information in the type of the matrix, and in those cases the
> backslash operator should actually be more efficient than in Matlab because
> there is no need to “guess” what the best algorithm might be. My
> understanding is that no such thing exists in Matlab. Having said that,
> take this with a grain of salt, this is not my area of expertise (neither
> in Julia nor in Matlab).
>
>
>
> The relevant Julia manual section is
> http://docs.julialang.org/en/latest/manual/linear-algebra/.
>
>
>
> *From:* julia-users@googlegroups.com [mailto:julia-users@googlegroups.com]
> *On Behalf Of *Art Kuo
> *Sent:* Wednesday, September 30, 2015 9:30 AM
> *To:* julia-users 
> *Subject:* Re: [julia-users] Re: What's the reason of the Success of
> Python?
>
>
>
> > (x=inv(A)*b) than it is in many other languages.  Julia has at least
> this
>
>
> You shouldn't ever do this (in either Julia or Matlab, or any language),
> it is ill-conditioned for general matrices. I think the Matlab function
> is linsolve.
>
> Perhaps more precise to say  "A\b is always faster than inv(A)*b, and more
> accurate if A is ill-conditioned." I also usually prefer Matlab's backslash
> or mldivide, A\b, over the more specific linsolve, because backslash
> chooses the right solver (including linsolve) most of the time, for systems
> that are sparse, over- or under-determined, etc. Julia also implements
> similar functionality, but I doubt if it is as optimized as Matlab, which
> has many years' advantage. As for the accuracy advantage, it is true that
> inv(A)*b can go wrong, and A\b will go less wrong. But Ill-conditioned A is
> usually an indicator that neither approach will be great.
>
>
>