[julia-users] Re: range bug in 0.4.1?

[Gabor]

I am also surprised at this behaviour, but it is certainly not a bug.
Have a look at the help:

help?> range
  range(start, [step], length)
  Construct a range by length, given a starting value and optional step 
(defaults to 1).

help?> colon
  ..  \:(start, [step], stop)
  Range operator. ``a:b`` constructs a range from ``a`` to ``b`` with a 
step size of 1, 
  and ``a:s:b`` is similar but uses a step size of ``s``. 
  These syntaxes call the function ``colon``.
  The colon is also used in indexing to select whole dimensions.
  colon(start, [step], stop)
  Called by : syntax for constructing ranges.


On Sunday, December 6, 2015 at 8:41:34 AM UTC+1, Jürgen Bohnert wrote:
>
>
>
> Hi everyone,
>
> I found some really strange behaviour of the 'range' function
>
> range(1,5)
> > 1:5
> everything is OK
>
> range(2,5)
> > 2:6
> NOT OK!
>
> range(10,20)
> > 10:29
> NOT OK!
>
> However, if I define the range like so
> 10:20
> > 10:20
> OK and obviously works for all you guys as well.
>
> Am I missing some syntax or is this a bug?
>
>
>
> Also: is there a way to redefine the default behaviour of the 
> range-syntax? It's really annoying having to 'Int' everything when I'm just 
> specifying limits that get coerced to 'Float' because of division but are 
> otherwise 'X.0'
> N=2^3 -1
> > 7
> imid = (N+1)/2
> > 4.0
> range(imid-2, imid+2)
> > ERROR: MethodError: 'range' has no method matching range(::Float64, ::
> Float64)
>
> Thanks for helping,
> Juergen
>
> julia build:
> Version 0.4.1 (2015-11-08 10:33 UTC)
> both:
>
>- x86_64-w64-mingw32
>- x86_64-linux-gnu
>
>
>
>
>
>
>
>

[julia-users] parsing a string into several floats

[Gabor]

Let ss="10.0 20.0 30.0 90. 90. 90"

With Julia 3.x I could do this:
v = float64(split(ss))

With Julia 4.0 I had to change the code to:
v = [parse(Float64,s) for s=split(ss)]

Please advise, is there a more compact solution?

Re: [julia-users] parsing a string into several floats

[Gabor]

Milan:
This is the solution for me.
So float64(split(ss)) is deprecated but float(split(ss)) is not.

Eric:
I also see the logic, but similar code occurs at many places.
I prefer as little eye clutter as possible.

On Wednesday, December 2, 2015 at 11:48:41 AM UTC+1, Milan Bouchet-Valat 
wrote:
>
> Le mercredi 02 décembre 2015 à 02:41 -0800, Gabor a écrit : 
> > Let ss="10.0 20.0 30.0 90. 90. 90" 
> > 
> > With Julia 3.x I could do this: 
> > v = float64(split(ss)) 
> > 
> > With Julia 4.0 I had to change the code to: 
> > v = [parse(Float64,s) for s=split(ss)] 
> > 
> > Please advise, is there a more compact solution? 
> float(split(ss)) still works, and is documented to produce Float64 when 
> passed strings. The explicit comprehension form is fine too. 
>
>
> Regards 
>

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

[Gabor]

My vote is for keeping '='.
It is very readable for counters as is 'in' for other containers.

Confusion?
Considering the investment into learning all the new and powerful Julia 
language constructs,
I don't see why exactly this elegant duality would be a problem for anyone.

It is not even a documentation issue, 
the documentation is already crystal clear:

"In general, the for loop construct can iterate over any container. 
In these cases, the alternative (but fully equivalent) keyword in is 
typically used
instead of =, since it makes the code read more clearly"

On Tuesday, October 27, 2015 at 10:55:23 PM UTC+1, Hai Nguyen wrote:
>
>
>
> 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.
>

>>
>

[julia-users] copy a local variable to all parallel workers

[Gabor]

I would like to copy a local variable to all parallel workers.

I thought that the following code would do the job:
local_var=123
@everywhere var=local_var


But I get the following error:

ERROR: On worker 2:
UndefVarError: local_var not defined
 in eval at sysimg.jl:14
 in anonymous at multi.jl:1350
 in anonymous at multi.jl:892
 in run_work_thunk at multi.jl:645
 [inlined code] from multi.jl:892
 in anonymous at task.jl:63
 in remotecall_fetch at multi.jl:731

...and 2 other exceptions.

 in sync_end at task.jl:413
 in anonymous at multi.jl:1361


I ask for your help.
What is the simplest solution for this simple problem?

Re: [julia-users] copy a local variable to all parallel workers

[Gabor]

Thank you very much for your help!
Even better, your solution also works within functions.
I am with Seth with his question. 
Could you explain the significance of $ in front of "local_var" ?

On Tuesday, October 6, 2015 at 1:04:13 AM UTC+2, Jameson wrote:
>
> despite your naming convention, it looks like "local_var" was a global. 
> try wrapping it in a let block:
>
> let local_var=123
> @everywhere var=$local_var
> end
>
> On Mon, Oct 5, 2015 at 6:22 PM Gabor <g...@szfki.hu > wrote:
>
>> I would like to copy a local variable to all parallel workers.
>>
>> I thought that the following code would do the job:
>> local_var=123
>> @everywhere var=local_var
>>
>>
>> But I get the following error:
>>
>> ERROR: On worker 2:
>> UndefVarError: local_var not defined
>>  in eval at sysimg.jl:14
>>  in anonymous at multi.jl:1350
>>  in anonymous at multi.jl:892
>>  in run_work_thunk at multi.jl:645
>>  [inlined code] from multi.jl:892
>>  in anonymous at task.jl:63
>>  in remotecall_fetch at multi.jl:731
>>
>> ...and 2 other exceptions.
>>
>>  in sync_end at task.jl:413
>>  in anonymous at multi.jl:1361
>>
>>
>> I ask for your help.
>> What is the simplest solution for this simple problem?
>>
>

Re: [julia-users] downloaded binaries vs source compilation

[Gabor]

Thank you.
So the average user should stick to the binaries.

On Sunday, September 27, 2015 at 9:11:28 PM UTC+2, Jameson wrote:
>
> The performance should be fairly close. The advantage of source 
> compilation is that it is easier to edit files in Base and submit those 
> changes as a PR.
>
> On Sun, Sep 27, 2015 at 2:33 AM Gabor <g...@szfki.hu > wrote:
>
>> I have always used the downloadable binaries of Julia.
>>
>> Please advise:
>>
>> Running 64-bit Windows 7 on a Haswell processor with AVX2 instructions
>> should I expect a speedup or any other advantage from source compilation?
>>
>

[julia-users] Re: Why is String deprecated in favour of AbstractString?

[Gabor]

I do not know the answer, and may not be a solution for you,
but here is what I do:

typealias String   ASCIIString

It turned out that I unnecessarily used an abstract type before,
so from here on I use and alias the concrete ASCIIString type in my program.


On Sunday, September 27, 2015 at 9:40:31 AM UTC+2, Daniel Carrera wrote:
>
> Why are we changing from String to AbstractString? Obviously, the former 
> is easier to type. Even if there are some changes to the guts of the string 
> implementation, I would have thought that you could just keep the shorter 
> name "String".
>
> Cheers,
> Daniel.
>

[julia-users] downloaded binaries vs source compilation

[Gabor]

I have always used the downloadable binaries of Julia.

Please advise:

Running 64-bit Windows 7 on a Haswell processor with AVX2 instructions
should I expect a speedup or any other advantage from source compilation?

Re: [julia-users] Why is String deprecated in favour of AbstractString?

[Gabor]

Of course, if you need Greek characters, then use UTF8String,
I used ASCIIString just for filenames and atom types.

On Sunday, September 27, 2015 at 11:00:17 AM UTC+2, Daniel Carrera wrote:
>
>
> On 27 September 2015 at 10:39, Milan Bouchet-Valat <nali...@club.fr 
> > wrote:
>>
>> Then the default concrete type can be called String or Str, and that's
>> what people will use. Calling the abstract type String was confusing as
>> it could prompt people to write type-unstable fields believing that it
>> was the concrete one.
>>
>
>
> So... it would be a good idea if I made an alias to a concrete type the 
> way Gabor did?
>
> typealias String UTF8String
>
>
> Is there a reason to use ASCIIString instead of UTF8String? They are both 
> concrete types, but UTF8 allows me to include greek characters.
>
> Cheers,
> Daniel.
>
>
>

[julia-users] Re: help!

[Gabor]

help(sin) is valid in Julia 0.3.11 but not in 0.4.0-rc1.
(ERROR: UndefVarError: help not defined)

On Saturday, September 26, 2015 at 5:12:24 PM UTC+2, Daniel Carrera wrote:
>
> I usually use the `help` function:
>
> julia> help(sin)
>
> On Friday, 25 September 2015 15:55:14 UTC+2, Marcio Sales wrote:
>>
>> Hi, 
>>
>> I have 2 silly (but could find the answer yet) questions about help.
>> 1) Is there another way to see help text besides using "?" to change the 
>> shell mode? I use software like Juno that doesn't allow that. I know that 
>> methods(function) shows a function's methods, but I wonder if there's 
>> something simillar to show help..., as help() is not defined.
>>
>> 2) how can I write help text in a function that could be displayed in the 
>> same way?
>>  
>>
>

Re: [julia-users] FFTW inv(plan) for ifft

[Gabor]

Thank you for the positive answer.

May I have one more question?

Let b=fft(a) and P=plan_fft(a).
Are the following two expressions equally good?
  a = inv(P) * b  
  a = P \ b

On Sunday, September 13, 2015 at 6:15:05 PM UTC+2, Yichao Yu wrote:
>
> On Sun, Sep 13, 2015 at 11:53 AM,   wrote: 
> > I am learning the new FFTW syntax of version 0.4.0. 
> > 
> > One thing that surprised me is the possibility of using 
> > inv(plan1) for ifft, where plan1 was created for fft by plan_fft. 
> > 
> > Could you confirm please, that this method is just as efficient 
> > as creating a separate plan2 for ifft by a separate plan_ifft call? 
>
> When I measured it right around when it was merged, the difference 
> between `ifft_plan * ary` and `fft_plan \ ary` are smaller than what I 
> can measure. (and both of them are much faster compare to the old one) 
>

Re: [julia-users] FFTW inv(plan) for ifft

[Gabor]

Thanks!  Now all is clear.

On Sunday, September 13, 2015 at 6:46:25 PM UTC+2, Kristoffer Carlsson 
wrote:
>
> From dft.jl
>
> \(p::Plan, x::AbstractArray) = inv(p) * x
>
>
>
> On Sunday, September 13, 2015 at 6:38:48 PM UTC+2, Gabor wrote:
>>
>> Thank you for the positive answer.
>>
>> May I have one more question?
>>
>> Let b=fft(a) and P=plan_fft(a).
>> Are the following two expressions equally good?
>>   a = inv(P) * b  
>>   a = P \ b
>>
>> On Sunday, September 13, 2015 at 6:15:05 PM UTC+2, Yichao Yu wrote:
>>>
>>> On Sun, Sep 13, 2015 at 11:53 AM,  <g...@szfki.hu> wrote: 
>>> > I am learning the new FFTW syntax of version 0.4.0. 
>>> > 
>>> > One thing that surprised me is the possibility of using 
>>> > inv(plan1) for ifft, where plan1 was created for fft by plan_fft. 
>>> > 
>>> > Could you confirm please, that this method is just as efficient 
>>> > as creating a separate plan2 for ifft by a separate plan_ifft call? 
>>>
>>> When I measured it right around when it was merged, the difference 
>>> between `ifft_plan * ary` and `fft_plan \ ary` are smaller than what I 
>>> can measure. (and both of them are much faster compare to the old one) 
>>>
>>

[julia-users] Re: Where is documentation on { } notation for creating an Array(Any,1) ??

[Gabor]

The {1,2,3} syntax is deprecated in v0.4.0-dev.

See:  https://github.com/JuliaLang/julia/blob/master/NEWS.md

Cheers,
Gabor

On Friday, January 9, 2015 at 3:08:22 AM UTC+1, Ronald L. Rivest wrote:

 I am failing at finding where the { } notation is documented in the
 manual.  E.g. 
  { 1, 2, 3} 
 creates an array of type Array{Any,1} of length 3.

 Somehow both the TOC and the index are failing me...
 I'm looking at the julia.pdf release 0.4.0-dev.

 I did discover in my search that type Any seems to be missing from the 
 index.

 Also, the notations in section 8.4 should also be in the index (e.g.
 bracket notation for creating arrays is not in the index...)

 Where is { } described ???

 Thanks!

 Cheers,
 Ron

[julia-users] Re: how to Replicate array, translate from matlab

[Gabor]

B=repmat(A,x...)

On Friday, May 16, 2014 8:18:14 PM UTC+2, paul analyst wrote:

 in matlab :
 x=[1,4]
 B=repmat(A,x)

 /(B==)


 how to replicate A in Julia
 Paul

[julia-users] Fortran-formatted files

[Gabor]

Could someone help, please.
 
What is the most efficient way of reading and writing
Fortan-formatted files ?  [ e.g. FORMAT(3I4,4F8.2)  ]

Re: [julia-users] Fortran-formatted files

[Gabor]

Sorry, I was not clear enough.
Of course it is just a simple formatted text file.
 
All I wanted to know, how to read such files efficiently.
Currently I use readline(), string indexing and int()/float64() conversions.
Is there a better way to do this?
 

On Friday, March 7, 2014 10:05:53 PM UTC+1, Stefan Karpinski wrote:

 Is there a standard Fortran data format? Do you have a link to a standard 
 or specification?


 On Fri, Mar 7, 2014 at 1:17 PM, Gabor g...@szfki.hu javascript: wrote:

 Could someone help, please.
  
 What is the most efficient way of reading and writing
 Fortan-formatted files ?  [ e.g. FORMAT(3I4,4F8.2)  ]

Re: [julia-users] Fortran-formatted files

[Gabor]

Thanks.
I fear that readdlm() will not work in those cases when there is no 
delimiter.
Unfortunately, such files [ e.g.FORMAT(3I4,4F8.2) ] are frequently written 
by standard crystallographic programs.
 

On Friday, March 7, 2014 10:20:30 PM UTC+1, Jacob Quinn wrote:

 Have you checked out `readdlm`? It's flexibility has grown over time and 
 serves most of my needs.

 http://docs.julialang.org/en/latest/stdlib/base/#Base.readdlm

 -Jacob


 On Fri, Mar 7, 2014 at 4:17 PM, Gabor g...@szfki.hu javascript: wrote:

 Sorry, I was not clear enough.
 Of course it is just a simple formatted text file.
  
 All I wanted to know, how to read such files efficiently.
 Currently I use readline(), string indexing and int()/float64() 
 conversions.
 Is there a better way to do this?
  

 On Friday, March 7, 2014 10:05:53 PM UTC+1, Stefan Karpinski wrote:

 Is there a standard Fortran data format? Do you have a link to a 
 standard or specification?


 On Fri, Mar 7, 2014 at 1:17 PM, Gabor g...@szfki.hu wrote:

 Could someone help, please.
  
 What is the most efficient way of reading and writing
 Fortan-formatted files ?  [ e.g. FORMAT(3I4,4F8.2)  ]