[julia-users] Re: Help Julia win a performance comparison!

[Chris Rackauckas]

Most of the arrays are changing size each time though, since they represent 
a population which changes each timestep.

On Wednesday, July 20, 2016 at 6:47:39 PM UTC-7, Steven G. Johnson wrote:
>
> It looks like you are allocating lots of arrays in your doStep inner-loop 
> function, so I'm sure you could improve it by moving the allocations out of 
> the inner loop.  (In general, vectorized routines are convenient but they 
> aren't the fastest way to do things.)
>

[julia-users] Re: Help Julia win a performance comparison!

[Steven G. Johnson]

It looks like you are allocating lots of arrays in your doStep inner-loop 
function, so I'm sure you could improve it by moving the allocations out of 
the inner loop.  (In general, vectorized routines are convenient but they 
aren't the fastest way to do things.)

Re: [julia-users] findpeaks

[Gabriel Gellner]

Yay! thanks so much. Under my nose the whole time.

On Wednesday, July 20, 2016 at 4:30:44 PM UTC-7, Tim Holy wrote:
>
> On Wednesday, July 20, 2016 4:01:00 PM CDT Gabriel Gellner wrote: 
> > Is there a standard (Base or common package) that implements something 
> akin 
> > to matlab's `findpeaks`. It is easy enough to make something like this, 
> but 
> > I imagined that this would be something that already exists but that I 
> have 
> > just missed? 
>
> julia> using Images 
>
> help?> Images 
> search: Images nimages Image ImageCmap OverlayImage AbstractImage 
> AbstractImageDirect AbstractImageIndexed imaverage integral_image 
>
>   Images is a package for representing and processing images. 
>
>   Constructors, conversions, and traits: 
>
>   - Construction: `Image`, `ImageCmap`, `grayim`, `colorim`, `convert`, 
> `copyproperties`, `shareproperties` 
>   - Traits: `colordim`, `colorspace`, `coords_spatial`, `data`, 
> `isdirect`, 
> `isxfirst`, `isyfirst`, `pixelspacing`, `properties`, `sdims`, 
> `spacedirections`, `spatialorder`, `storageorder`, `timedim` 
>   - Size-related traits: `height`, `nchannels`, `ncolorelem`, `nimages`, 
> `size_spatial`, `width`, `widthheight` 
>   - Trait assertions: `assert_2d`, `assert_scalar_color`, 
> `assert_timedim_last`, `assert_xfirst`, `assert_yfirst` 
>   - Indexing operations: `getindexim`, `sliceim`, `subim` 
>   - Conversions: `convert`, `raw`, `reinterpret`, `separate` 
>
>   Contrast/coloration: 
>
>   - `MapInfo`: `MapNone`, `BitShift`, `ClampMinMax`, `ScaleMinMax`, 
> `ScaleAutoMinMax`, etc. 
>   - `imadjustintensity`, `sc`, `imstretch`, `imcomplement` 
>
>   Algorithms: 
>
>   - Reductions: `maxfinite`, `maxabsfinite`, `minfinite`, `meanfinite`, 
> `sad`, 
> `ssd`, `integral_image` 
>   - Resizing: `restrict`, `imresize` (not yet exported) 
>   - Filtering: `imfilter`, `imfilter_fft`, `imfilter_gaussian`, 
> `imfilter_LoG`, 
> `imROF`, `ncc`, `padarray` 
>   - Filtering kernels: `ando[345]`, `guassian2d`, `imaverage`, `imdog`, 
> `imlaplacian`, `prewitt`, `sobel` 
>   - Exposure : `imhist`, `histeq` 
>   - Gradients: `backdiffx`, `backdiffy`, `forwarddiffx`, `forwarddiffy`, 
> `imgradients` 
>   - Edge detection: `imedge`, `imgradients`, `thin_edges`, `magnitude`, 
> `phase`, `magnitudephase`, `orientation`, `canny` 
>   - Corner detection: `imcorner` 
>   - Blob detection: `blob_LoG`, `findlocalmaxima`, `findlocalminima` 
>   - Morphological operations: `dilate`, `erode`, `closing`, `opening`, 
> `tophat`, `bothat`, `morphogradient`, `morpholaplace` 
>   - Connected components: `label_components`, `component_boxes`, 
> `component_lengths`, `component_indices`, `component_subscripts`, 
> `component_centroids` 
>
>   Test images and phantoms (see also TestImages.jl): 
>
>   - `shepp_logan` 
>
> help?> findlocalmaxima 
> search: findlocalmaxima findlocalminima 
>
>   findlocalmaxima(img, [region, edges]) -> Vector{Tuple} 
>
>   Returns the coordinates of elements whose value is larger than all of 
> their 
> immediate neighbors. region is a list of dimensions to consider. edges is 
> a 
> boolean specifying whether to 
>   include the first and last elements of each dimension. 
>
> (I think it would be great if most packages would provide an API summary 
> with 
> ?PkgName. Not that I always remember myself) 
>
> --Tim 
>
>

[julia-users] Help Julia win a performance comparison!

[Chris Rackauckas]

Hey, there's a performance comparison on Code Review 
.
 
I gave it a go and with help from @TotalVerb via Gitter, I got Julia really 
close to being the fastest. However, R slightly beats it out since the 
problem is able to be vectorized well. But maybe one of you have a way to 
get a little bit more performance? The difficulty is that the random number 
generator is such a large portion of the code. If anyone knows about the 
newest RNGs in RNG.jl, it would be interesting to try them out here.

Re: [julia-users] FFT, PSD and Windowing functions

[Islam Badreldin]

Hello Yared,
Take a look at the DSP packagehttps://github.com/JuliaDSP/DSP.jl
  -Islam


_
From: Yared Melese 
Sent: Wednesday, July 20, 2016 10:15 AM
Subject: [julia-users] FFT,  PSD and Windowing functions
To: julia-users 


Hello 
Would you please let me know the package available to do windowing, FFT and 
PSD? 
Currently, I have bin file that I have processed in Julia and need to window it 
and take preferably PSD but FFT work as well
Thanks Yared
 

Re: [julia-users] findpeaks

[Tim Holy]

On Wednesday, July 20, 2016 4:01:00 PM CDT Gabriel Gellner wrote:
> Is there a standard (Base or common package) that implements something akin
> to matlab's `findpeaks`. It is easy enough to make something like this, but
> I imagined that this would be something that already exists but that I have
> just missed?

julia> using Images

help?> Images
search: Images nimages Image ImageCmap OverlayImage AbstractImage 
AbstractImageDirect AbstractImageIndexed imaverage integral_image

  Images is a package for representing and processing images.

  Constructors, conversions, and traits:

  - Construction: `Image`, `ImageCmap`, `grayim`, `colorim`, `convert`, 
`copyproperties`, `shareproperties`
  - Traits: `colordim`, `colorspace`, `coords_spatial`, `data`, `isdirect`, 
`isxfirst`, `isyfirst`, `pixelspacing`, `properties`, `sdims`, 
`spacedirections`, `spatialorder`, `storageorder`, `timedim`
  - Size-related traits: `height`, `nchannels`, `ncolorelem`, `nimages`, 
`size_spatial`, `width`, `widthheight`
  - Trait assertions: `assert_2d`, `assert_scalar_color`, 
`assert_timedim_last`, `assert_xfirst`, `assert_yfirst`
  - Indexing operations: `getindexim`, `sliceim`, `subim`
  - Conversions: `convert`, `raw`, `reinterpret`, `separate`

  Contrast/coloration:

  - `MapInfo`: `MapNone`, `BitShift`, `ClampMinMax`, `ScaleMinMax`, 
`ScaleAutoMinMax`, etc.
  - `imadjustintensity`, `sc`, `imstretch`, `imcomplement`

  Algorithms:

  - Reductions: `maxfinite`, `maxabsfinite`, `minfinite`, `meanfinite`, `sad`, 
`ssd`, `integral_image`
  - Resizing: `restrict`, `imresize` (not yet exported)
  - Filtering: `imfilter`, `imfilter_fft`, `imfilter_gaussian`, `imfilter_LoG`, 
`imROF`, `ncc`, `padarray`
  - Filtering kernels: `ando[345]`, `guassian2d`, `imaverage`, `imdog`, 
`imlaplacian`, `prewitt`, `sobel`
  - Exposure : `imhist`, `histeq`
  - Gradients: `backdiffx`, `backdiffy`, `forwarddiffx`, `forwarddiffy`, 
`imgradients`
  - Edge detection: `imedge`, `imgradients`, `thin_edges`, `magnitude`, 
`phase`, `magnitudephase`, `orientation`, `canny`
  - Corner detection: `imcorner`
  - Blob detection: `blob_LoG`, `findlocalmaxima`, `findlocalminima`
  - Morphological operations: `dilate`, `erode`, `closing`, `opening`, 
`tophat`, `bothat`, `morphogradient`, `morpholaplace`
  - Connected components: `label_components`, `component_boxes`, 
`component_lengths`, `component_indices`, `component_subscripts`, 
`component_centroids`

  Test images and phantoms (see also TestImages.jl):

  - `shepp_logan`

help?> findlocalmaxima
search: findlocalmaxima findlocalminima

  findlocalmaxima(img, [region, edges]) -> Vector{Tuple}

  Returns the coordinates of elements whose value is larger than all of their 
immediate neighbors. region is a list of dimensions to consider. edges is a 
boolean specifying whether to
  include the first and last elements of each dimension.

(I think it would be great if most packages would provide an API summary with 
?PkgName. Not that I always remember myself)

--Tim

[julia-users] Re: Clarification about @parallel (op) for loop

['Greg Plowman' via julia-users]

>
>
> does every worker compute func(i) and return it to the calling process, 
> which then reduces it on the fly? 
>
No.
 

> Or does every worker apply the reduction operator for its chunk and then 
> return it to the calling process?
>
Yes.
 

The documentation 
>  says 
> that "In case of @parallel for, the final reduction is done on the calling 
> process."  
>
 Does this mean that func(i) *for every i* is returned to the calling 
process? 
No.
 

> On the other hand, from what I understand from this implementation of 
> preduce 
> ,
>  
> line 1723 seems to indicate that the reduction happens on the worker 
> process itself, and only the *final* reduction is carried out on the 
> calling process.
>
 Yes. That is what is meant by "the *final* reduction is done on the 
calling process". It's the reduction of the single, already-reduced results 
from each worker.


Also, the documentation mentions: "In contrast, @parallel for can handle 
> situations where each iteration is tiny, perhaps merely summing two 
> numbers." However, my function func() is nowhere near this simple. Should I 
> still be using @parallel? Or try to go for pmap() with my own written 
> version of a pmap_reduce()?
>

@parallel *statically* splits the work among workers in *batches*. 
Statically means each worker runs the same number of loops.
In batches means communication is minimised.

pmap dynamically splits the work among workers (dynamic load balancing)
Each worker is given the next task only when it has completed the previous 
task.
pmap is useful for uneven workloads and/or uneven processors.
It is less ideal for small workloads because of the communication per 
iteration.

Of course you could custom code a sort of hybrid, where pmap dishes out the 
work to workers in batches.

[julia-users] findpeaks

[Gabriel Gellner]

Is there a standard (Base or common package) that implements something akin 
to matlab's `findpeaks`. It is easy enough to make something like this, but 
I imagined that this would be something that already exists but that I have 
just missed?

[julia-users] unable to connect to FTP using IP address

[Yared Melese]

Hello 

Would you please let me know if I missed anything, I am using FTPClient and 
using IP address as a host but not able to connect 
Here are my commands 

using FTPClient
ftp_init()
ftp = FTP(host="192.168.251.200", implt=true, ssl=true, user="anonymous", 
pswd="")
binary(ftp)
file = download(ftp, "dataOnFTP.bin", "C:\Users\xyz\test.bin")
close(ftp)
ftp_cleanup()

when sending  " using FTPClient" there are bunch of warnings as shown below 
partially
WARNING: Base.String is deprecated, use AbstractString instead.
  likely near C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:35
WARNING: Base.String is deprecated, use AbstractString instead.
  likely near C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:67
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
  likely near C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:81
..
.
.and at the end I am getting the following error 

ERROR: Failed to connect. :: LibCURL error #7
 [inlined code] from C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:138
 in ftp_command at C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:454
 in ftp_connect at C:\Users\melese\.julia\v0.4\FTPClient\src\FTPC.jl:493
 in call at C:\Users\melese\.julia\v0.4\FTPClient\src\FTPObject.jl:23

Thanks 
Yared

[julia-users] Issue with Pkg.update() after fresh Julia installation on Windows 7 system

[Pedro Hussain]

After installing Julia language on my Windows 7 PC (Windows Self-Extracting 
Archive 64 bit) I started the Julia console and ran Pkg.update(). This 
resulted in following error message:

*ERROR: couldn't update julia\v0.4.cache\JuliaParser using git remote 
update*

I also installed Atom and after the first start Atome recompiled a number 
of modules and then halted with following error message:

*Error loading Atom.jl package*
*Go to the Packages → Julia → Open Terminal menu and*
*run Pkg.update()in Julia, then try again.*
*If you still see an issue, please report it to:*
*_ http://discuss.junolab.org/_ *

Don't know whether the same cause is in effect in both cases. Can anyone 
advice on the cause and how to overcome this issue? Thanks

Re: [julia-users] IBM Power port

[Viral Shah]

Just a heads up, there is a bug in atlas that causes the linalg/lq test to fail 
(thanks Andreas for finding!). The bugfix is going to be in the next atlas 
release - 3.10.3

 https://sourceforge.net/p/math-atlas/bugs/254/#64f2

Turns out at this moment, both atlas and openblas are not passing julia’s tests 
on power.

-viral



> On Jul 20, 2016, at 3:11 PM, James Fairbanks  wrote:
> 
> Updating to master and using that Make.user worked for me.
> 
> Success!
> [jpf@power8 julia-dev]$ ./julia
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "?help" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.5.0-dev+5549 (2016-07-20 15:47 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Commit 80fcb57 (0 days old master)
> |__/   |  ppc64le-redhat-linux
> 
> Thanks for going through this with me. Hopefully it will be easier for the 
> next person.
> 
> On Wednesday, July 20, 2016 at 10:27:27 AM UTC-4, Viral Shah wrote:
> 
> Julia now  builds on master. No longer need to disable threading. Make.user 
> for me is now: 
> 
> override USE_SYSTEM_BLAS = 1 
> override LIBBLAS = -L/usr/lib64/atlas -lsatlas 
> override LIBBLASNAME = libsatlas 
> override USE_BLAS64 = 0 
> 
> -viral 
> 
> 
> > On Jul 19, 2016, at 7:00 PM, Viral Shah  wrote: 
> > 
> > I am testing on CentOS Linux release 7.2.1511 (AltArch) 
> > 
> > This is the line I am using: 
> > export LD_LIBRARY_PATH=/usr/lib64/atlas:$LD_LIBRARY_PATH 
> > 
> > Our README says LAPACK >= 3.5, so I suspect the system lapack won’t work 
> > out. Assuming that symbol is present in the libsatlas file, perhaps try 
> > also copying it in julia’s usr/lib. 
> > 
> > The other thing is to run make again to make sure that all the rpath and 
> > linking stuff has gone through fine. Or perhaps make cleanall and make. 
> > 
> > -viral 
> > 
> > 
> > 
> >> On Jul 19, 2016, at 6:55 PM, James Fairbanks  wrote: 
> >> 
> >> For completeness I should say that the julia executable appears not to 
> >> have the libjulia.so correctly linked. 
> >> 
> >> $ ./julia 
> >> ./julia: symbol lookup error: /home/jpf/julia/usr/bin/../lib/liblapack.so: 
> >> undefined symbol: lsame_ 
> >> $ ldd ./julia 
> >>linux-vdso64.so.1 =>  (0x3fff9d14) 
> >>libjulia.so.0.5 => not found 
> >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff9d10) 
> >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff9d0d) 
> >>libpthread.so.0 => /lib64/power8/libpthread.so.0 (0x3fff9d09) 
> >>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9ceb) 
> >>/lib64/ld64.so.2 (0x251e) 
> >> 
> >> $ ldd ./usr/lib/libjulia.so 
> >>linux-vdso64.so.1 =>  (0x3fff9968) 
> >>libLLVM-3.8.so => /home/jpf/julia/./usr/lib/libLLVM-3.8.so 
> >> (0x3fff97d8) 
> >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff97d4) 
> >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff97d1) 
> >>libpthread.so.0 => /lib64/power8/libpthread.so.0 (0x3fff97cd) 
> >>libstdc++.so.6 => /lib64/libstdc++.so.6 (0x3fff97b5) 
> >>libm.so.6 => /lib64/power8/libm.so.6 (0x3fff97a6) 
> >>libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x3fff97a2) 
> >>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9784) 
> >>libz.so.1 => /lib64/libz.so.1 (0x3fff9780) 
> >>/lib64/ld64.so.2 (0x35a0) 
> >> 
> >> On Tuesday, July 19, 2016 at 6:30:34 PM UTC-4, James Fairbanks wrote: 
> >> Adding /usr/lib64/atlas was insufficient so I created a symlink in ln -s 
> >> /usr/lib/atlas/libsatlas.so.3 /usr/lib/atlas/libsatlas.so 
> >> This allowed the build process to complete but leads to an error when 
> >> running the julia executable. 
> >> 
> >> The error is: 
> >> /home/jpf/julia/usr/bin/julia: symbol lookup error: 
> >> /home/jpf/julia/usr/bin/../lib/liblapack.so: undefined symbol: lsame_ 
> >> 
> >> Is it a good idea to go with the RHEL ppc64le system lapack instead of 
> >> having julia build lapack against system blas? 
> >> I have this version of lapack available from the system. 
> >> 
> >> Available Packages 
> >> Name: lapack 
> >> Arch: ppc64le 
> >> Version : 3.4.2 
> >> Release : 5.el7 
> >> Size: 4.9 M 
> >> Repo: rhel-7-for-power-le-rpms/7Server/ppc64le 
> >> 
> >> 
> >> Thanks, 
> >>  James 
> >> On Tuesday, July 19, 2016 at 4:46:22 PM UTC-4, Viral Shah wrote: 
> >> 
> >> Yes - I forgot to mention that. On the machine I am using, I had to add 
> >> /usr/lib64/atlas or something like that to LD_LIBRARY_PATH. I can’t login 
> >> at the moment for some reason, or else I could have retrieved the exact 
> >> line. 
> >> 
> >> 
> >> -viral 
> >> 
> >> 
> >> 
> >>> On Jul 19, 2016, at 4:12 PM, James Fairbanks  wrote: 
> >>> 
> >>> I set it up 

Re: [julia-users] IBM Power port

[James Fairbanks]

Updating to master and using that Make.user worked for me.

Success!
[jpf@power8 julia-dev]$ ./julia
   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.0-dev+5549 (2016-07-20 15:47 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 80fcb57 (0 days old master)
|__/   |  ppc64le-redhat-linux

Thanks for going through this with me. Hopefully it will be easier for the 
next person.

On Wednesday, July 20, 2016 at 10:27:27 AM UTC-4, Viral Shah wrote:
>
>
> Julia now  builds on master. No longer need to disable threading. 
> Make.user for me is now: 
>
> override USE_SYSTEM_BLAS = 1 
> override LIBBLAS = -L/usr/lib64/atlas -lsatlas 
> override LIBBLASNAME = libsatlas 
> override USE_BLAS64 = 0 
>
> -viral 
>
>
> > On Jul 19, 2016, at 7:00 PM, Viral Shah  > wrote: 
> > 
> > I am testing on CentOS Linux release 7.2.1511 (AltArch) 
> > 
> > This is the line I am using: 
> > export LD_LIBRARY_PATH=/usr/lib64/atlas:$LD_LIBRARY_PATH 
> > 
> > Our README says LAPACK >= 3.5, so I suspect the system lapack won’t work 
> out. Assuming that symbol is present in the libsatlas file, perhaps try 
> also copying it in julia’s usr/lib. 
> > 
> > The other thing is to run make again to make sure that all the rpath and 
> linking stuff has gone through fine. Or perhaps make cleanall and make. 
> > 
> > -viral 
> > 
> > 
> > 
> >> On Jul 19, 2016, at 6:55 PM, James Fairbanks  > wrote: 
> >> 
> >> For completeness I should say that the julia executable appears not to 
> have the libjulia.so correctly linked. 
> >> 
> >> $ ./julia 
> >> ./julia: symbol lookup error: 
> /home/jpf/julia/usr/bin/../lib/liblapack.so: undefined symbol: lsame_ 
> >> $ ldd ./julia 
> >>linux-vdso64.so.1 =>  (0x3fff9d14) 
> >>libjulia.so.0.5 => not found 
> >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff9d10) 
> >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff9d0d) 
> >>libpthread.so.0 => /lib64/power8/libpthread.so.0 
> (0x3fff9d09) 
> >>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9ceb) 
> >>/lib64/ld64.so.2 (0x251e) 
> >> 
> >> $ ldd ./usr/lib/libjulia.so 
> >>linux-vdso64.so.1 =>  (0x3fff9968) 
> >>libLLVM-3.8.so => /home/jpf/julia/./usr/lib/libLLVM-3.8.so 
> (0x3fff97d8) 
> >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff97d4) 
> >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff97d1) 
> >>libpthread.so.0 => /lib64/power8/libpthread.so.0 
> (0x3fff97cd) 
> >>libstdc++.so.6 => /lib64/libstdc++.so.6 (0x3fff97b5) 
> >>libm.so.6 => /lib64/power8/libm.so.6 (0x3fff97a6) 
> >>libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x3fff97a2) 
> >>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9784) 
> >>libz.so.1 => /lib64/libz.so.1 (0x3fff9780) 
> >>/lib64/ld64.so.2 (0x35a0) 
> >> 
> >> On Tuesday, July 19, 2016 at 6:30:34 PM UTC-4, James Fairbanks wrote: 
> >> Adding /usr/lib64/atlas was insufficient so I created a symlink in ln 
> -s /usr/lib/atlas/libsatlas.so.3 /usr/lib/atlas/libsatlas.so 
> >> This allowed the build process to complete but leads to an error when 
> running the julia executable. 
> >> 
> >> The error is: 
> >> /home/jpf/julia/usr/bin/julia: symbol lookup error: 
> /home/jpf/julia/usr/bin/../lib/liblapack.so: undefined symbol: lsame_ 
> >> 
> >> Is it a good idea to go with the RHEL ppc64le system lapack instead of 
> having julia build lapack against system blas? 
> >> I have this version of lapack available from the system. 
> >> 
> >> Available Packages 
> >> Name: lapack 
> >> Arch: ppc64le 
> >> Version : 3.4.2 
> >> Release : 5.el7 
> >> Size: 4.9 M 
> >> Repo: rhel-7-for-power-le-rpms/7Server/ppc64le 
> >> 
> >> 
> >> Thanks, 
> >>  James 
> >> On Tuesday, July 19, 2016 at 4:46:22 PM UTC-4, Viral Shah wrote: 
> >> 
> >> Yes - I forgot to mention that. On the machine I am using, I had to add 
> /usr/lib64/atlas or something like that to LD_LIBRARY_PATH. I can’t login 
> at the moment for some reason, or else I could have retrieved the exact 
> line. 
> >> 
> >> 
> >> -viral 
> >> 
> >> 
> >> 
> >>> On Jul 19, 2016, at 4:12 PM, James Fairbanks  
> wrote: 
> >>> 
> >>> I set it up like you said and got the following error 
> >>> 
> >>> $ make 
> >>> ... a bunch of stuff successfully building ... 
> >>> /usr/bin/ld: cannot find -lsatlas 
> >>> collect2: error: ld returned 1 exit status 
> >>> make[1]: *** [build/lapack-3.5.0/liblapack.so] Error 1 
> >>> make: *** [julia-deps] Error 2 
> >>> 
> >>> Do I need to add something to LD_LIBRARY_PATH in the makefile or bash 
> environment? 
> >>> 
> >>> On Tuesday, July 19, 2016 at 3:59:55 PM UTC-4, 

[julia-users] Re: Array of vectors in type definition

[Jussi Piitulainen]

keskiviikko 20. heinäkuuta 2016 18.57.13 UTC+3 Ferran Mazzanti kirjoitti:
>
> Sorry guys again,
>
> I said it works as I tried it out and seemed to work. Now I'm not even 
> sure it does work, don't ask me why. I try now this
>
> type caw
>legs :: Int64
>spots :: Vector{Vector{Float64}}
>caw() = new()
> end
>
> then I can do things like
> z = caw()
> which produce
>
> caw(4587026064,#undef)
>
>
> Now the question is: how do I start adding vectors to z.spots?
>
> I've tried things like
>
>
> push!(z.spots,[1.0])
>
>
> but then I get 
>
>
> LoadError: UndefRefError: access to undefined reference
> while loading In[30], in expression starting on line 1
>
>
> Thanks for your help,
>
>
> Ferran.
>
>
> and now it does not complain
>
> On Monday, July 18, 2016 at 5:13:23 PM UTC+2, Ferran Mazzanti wrote:
>>
>> Guys,
>>
>> today I've tried to include a vector of vectors as part of atype 
>> definition, something like
>>
>> type caw
>>legs :: Int64
>>spots :: Array{Float64}[]
>> end
>>
>> but that fails. Shall I understand that it is not possible to define that 
>> in a type definition? I just wanted to include a structrure that could grow
>> by adding more data dynamically...
>>
>> Any hint about this?
>>
>> Thanks for your kind help,
>>
>> Ferran.
>>
>
 
julia> type caw
 legs :: Int64
 spots :: Vector{Vector{Float64}}
 caw() = new(4587026064, Vector{Float64}[])
   end

julia> z = caw()
caw(4587026064,Array{Float64,1}[])

julia> push!(z.spots, [1.0])
1-element Array{Array{Float64,1},1}:
 [1.0]

julia> z
caw(4587026064,[[1.0]])

Re: [julia-users] Re: Array of vectors in type definition

[Stefan Karpinski]

You're constructing caw with no spots at all, not an empty vector. You
should probably not construct incomplete objects, but rather create objects
with reasonable initial values, like new(0, Vector{Vector{Float64}}()). I'm
not sure what legs is supposed to be.

On Wed, Jul 20, 2016 at 11:57 AM, Ferran Mazzanti  wrote:

> Sorry guys again,
>
> I said it works as I tried it out and seemed to work. Now I'm not even
> sure it does work, don't ask me why. I try now this
>
> type caw
>legs :: Int64
>spots :: Vector{Vector{Float64}}
>caw() = new()
> end
>
> then I can do things like
> z = caw()
> which produce
>
> caw(4587026064,#undef)
>
>
> Now the question is: how do I start adding vectors to z.spots?
>
> I've tried things like
>
>
> push!(z.spots,[1.0])
>
>
> but then I get
>
>
> LoadError: UndefRefError: access to undefined reference
> while loading In[30], in expression starting on line 1
>
>
> Thanks for your help,
>
>
> Ferran.
>
>
> and now it does not complain
>
> On Monday, July 18, 2016 at 5:13:23 PM UTC+2, Ferran Mazzanti wrote:
>>
>> Guys,
>>
>> today I've tried to include a vector of vectors as part of atype
>> definition, something like
>>
>> type caw
>>legs :: Int64
>>spots :: Array{Float64}[]
>> end
>>
>> but that fails. Shall I understand that it is not possible to define that
>> in a type definition? I just wanted to include a structrure that could grow
>> by adding more data dynamically...
>>
>> Any hint about this?
>>
>> Thanks for your kind help,
>>
>> Ferran.
>>
>

[julia-users] Re: Array of vectors in type definition

[Ferran Mazzanti]

Sorry guys again,

I said it works as I tried it out and seemed to work. Now I'm not even sure 
it does work, don't ask me why. I try now this

type caw
   legs :: Int64
   spots :: Vector{Vector{Float64}}
   caw() = new()
end

then I can do things like
z = caw()
which produce

caw(4587026064,#undef)


Now the question is: how do I start adding vectors to z.spots?

I've tried things like


push!(z.spots,[1.0])


but then I get 


LoadError: UndefRefError: access to undefined reference
while loading In[30], in expression starting on line 1


Thanks for your help,


Ferran.


and now it does not complain

On Monday, July 18, 2016 at 5:13:23 PM UTC+2, Ferran Mazzanti wrote:
>
> Guys,
>
> today I've tried to include a vector of vectors as part of atype 
> definition, something like
>
> type caw
>legs :: Int64
>spots :: Array{Float64}[]
> end
>
> but that fails. Shall I understand that it is not possible to define that 
> in a type definition? I just wanted to include a structrure that could grow
> by adding more data dynamically...
>
> Any hint about this?
>
> Thanks for your kind help,
>
> Ferran.
>

Re: [julia-users] Re: Possible bug: very slow module load after addprocs()

[Marius Millea]

Done, see https://github.com/JuliaLang/julia/issues/17509



On Wednesday, July 20, 2016 at 5:21:23 PM UTC+2, Cedric St-Jean wrote:
>
> That does look suspicious. Maybe file an issue if there isn't one?
>
> On Wed, Jul 20, 2016 at 4:31 AM, Marius Millea  > wrote:
>
>> I don't think that theory totally works, it seems to scale to some extent 
>> with the length of time to load the package itself. Another example:
>>
>> julia> tic(); using PyPlot; toc()
>> elapsed time: 3.395904233 seconds
>>
>> vs
>>
>> julia> addprocs();
>> julia> tic(); using PyPlot; toc()
>> elapsed time: 13.877550518 seconds
>>
>> or even:
>>
>> julia> addprocs();
>> julia> using Empty; tic(); using PyPlot; toc()
>> elapsed time: 7.357315778 seconds
>>
>>
>> In any case, it can get pretty painful loading a few modules at the 
>> beginning of my parallelized scripts... 
>>
>>
>>
>>
>> On Tuesday, July 19, 2016 at 4:55:40 PM UTC+2, Cedric St-Jean wrote:
>>>
>>> Yes, that's what I meant. Presumably the multi-proc machinery is getting 
>>> compiled at the first `using`. It's the same reason why "println(2+2)" is 
>>> very slow on first use, but fast afterwards. 
>>>
>>> On Tue, Jul 19, 2016 at 10:41 AM, Marius Millea  
>>> wrote:
>>>
 Seems it may have something to do with that. If I understood correctly 
 what you're saying, if I create Empty2.jl defining module Empty2, I get, 

 julia> addprocs();

 julia> tic(); using Empty; toc()
 elapsed time: 2.706353202 seconds
 2.706353202

 julia> tic(); using Empty; toc()
 elapsed time: 0.00042397 seconds
 0.00042397

 julia> tic(); using Empty2; toc()
 elapsed time: 0.029200919 seconds
 0.029200919

 julia> tic(); using Empty2; toc()
 elapsed time: 0.000193097 seconds
 0.000193097



 That first load of Empty2 at 0.02 secs is much more in line with what 
 loading it on a single processor takes. 



 On Tuesday, July 19, 2016 at 4:13:15 PM UTC+2, Cedric St-Jean wrote:
>
> Maybe there is some warm-up JIT time in there? If you create an Empty2 
> module and load it after Empty, is it also slow?
>
> On Tuesday, July 19, 2016 at 9:07:01 AM UTC-4, Marius Millea wrote:
>>
>> I noticed that once I addprocs(), subsequent "using" statements were 
>> extremely slow. I guess in this case its loading the module on each 
>> processor, but if it happens in parallel it shouldn't be *that* much 
>> more 
>> wall time, and here I'm talking about two orders of magnitude 
>> difference. 
>>
>> Assuming I've got a file Empty.jl who contents is,
>>
>> module Empty
>> end
>>
>> then single threaded:
>>
>> tic()
>> using Empty
>> toc()
>> elapsed time: 0.024461076 seconds
>>
>> vs. multi-threaded:
>>
>> addprocs() #I've got 8 procs
>> tic()
>> using Empty
>> toc()
>> elapsed time: 2.479418079 seconds
>>
>>
>> Should I submit this as an Issue on Github, or is there something 
>> else going on? I've checked both Julia 0.4.5. and 0.5 (01e3c8a). I'm on 
>> Ubuntu 16.04 64bit. 
>>
>>
>>
>>>
>

Re: [julia-users] Re: Possible bug: very slow module load after addprocs()

[Cedric St-Jean]

That does look suspicious. Maybe file an issue if there isn't one?

On Wed, Jul 20, 2016 at 4:31 AM, Marius Millea 
wrote:

> I don't think that theory totally works, it seems to scale to some extent
> with the length of time to load the package itself. Another example:
>
> julia> tic(); using PyPlot; toc()
> elapsed time: 3.395904233 seconds
>
> vs
>
> julia> addprocs();
> julia> tic(); using PyPlot; toc()
> elapsed time: 13.877550518 seconds
>
> or even:
>
> julia> addprocs();
> julia> using Empty; tic(); using PyPlot; toc()
> elapsed time: 7.357315778 seconds
>
>
> In any case, it can get pretty painful loading a few modules at the
> beginning of my parallelized scripts...
>
>
>
>
> On Tuesday, July 19, 2016 at 4:55:40 PM UTC+2, Cedric St-Jean wrote:
>>
>> Yes, that's what I meant. Presumably the multi-proc machinery is getting
>> compiled at the first `using`. It's the same reason why "println(2+2)" is
>> very slow on first use, but fast afterwards.
>>
>> On Tue, Jul 19, 2016 at 10:41 AM, Marius Millea 
>> wrote:
>>
>>> Seems it may have something to do with that. If I understood correctly
>>> what you're saying, if I create Empty2.jl defining module Empty2, I get,
>>>
>>> julia> addprocs();
>>>
>>> julia> tic(); using Empty; toc()
>>> elapsed time: 2.706353202 seconds
>>> 2.706353202
>>>
>>> julia> tic(); using Empty; toc()
>>> elapsed time: 0.00042397 seconds
>>> 0.00042397
>>>
>>> julia> tic(); using Empty2; toc()
>>> elapsed time: 0.029200919 seconds
>>> 0.029200919
>>>
>>> julia> tic(); using Empty2; toc()
>>> elapsed time: 0.000193097 seconds
>>> 0.000193097
>>>
>>>
>>>
>>> That first load of Empty2 at 0.02 secs is much more in line with what
>>> loading it on a single processor takes.
>>>
>>>
>>>
>>> On Tuesday, July 19, 2016 at 4:13:15 PM UTC+2, Cedric St-Jean wrote:

 Maybe there is some warm-up JIT time in there? If you create an Empty2
 module and load it after Empty, is it also slow?

 On Tuesday, July 19, 2016 at 9:07:01 AM UTC-4, Marius Millea wrote:
>
> I noticed that once I addprocs(), subsequent "using" statements were
> extremely slow. I guess in this case its loading the module on each
> processor, but if it happens in parallel it shouldn't be *that* much more
> wall time, and here I'm talking about two orders of magnitude difference.
>
> Assuming I've got a file Empty.jl who contents is,
>
> module Empty
> end
>
> then single threaded:
>
> tic()
> using Empty
> toc()
> elapsed time: 0.024461076 seconds
>
> vs. multi-threaded:
>
> addprocs() #I've got 8 procs
> tic()
> using Empty
> toc()
> elapsed time: 2.479418079 seconds
>
>
> Should I submit this as an Issue on Github, or is there something else
> going on? I've checked both Julia 0.4.5. and 0.5 (01e3c8a). I'm on Ubuntu
> 16.04 64bit.
>
>
>
>>

Re: [julia-users] @sprintf variable length padding

[Stefan Karpinski]

Not currently supported via printf.

On Wed, Jul 20, 2016 at 10:32 AM, Tamas Papp  wrote:

> Thanks --- this is helpful for my particular problem, but I am still
> curious about how to do this with @sprintf (or whether it is currently
> not supported).
>
> Best,
>
> Tamas
>
> On Wed, Jul 20 2016, Stefan Karpinski wrote:
>
> > julia> lpad(12, 4, 0)
> > "0012"
> >
> > On Wed, Jul 20, 2016 at 9:05 AM, Tamas Papp  wrote:
> >
> >> Hi,
> >>
> >> how can I @sprintf an integer i padded to length l with zeros, where l
> >> is not a constant? Current workaround is
> >>
> >> printpad(i, l) = mapreduce(string, *, reverse(digits(i, 10, l)))
> >>
> >> julia> printpad(12, 4)
> >> "0012"
> >>
> >> but I could not figure out how to do this with @sprintf. If my
> >> understanding of printf syntax is correct, something like
> >>
> >> @sprintf("%*d", 4, 12)
> >>
> >> should do the trick, but in Julia it is an invalid format string.
> >>
> >> Best,
> >>
> >> Tamas
> >>
>
>

Re: [julia-users] IBM Power port

[Viral Shah]

Julia now  builds on master. No longer need to disable threading. Make.user for 
me is now:

override USE_SYSTEM_BLAS = 1
override LIBBLAS = -L/usr/lib64/atlas -lsatlas
override LIBBLASNAME = libsatlas
override USE_BLAS64 = 0

-viral


> On Jul 19, 2016, at 7:00 PM, Viral Shah  wrote:
> 
> I am testing on CentOS Linux release 7.2.1511 (AltArch) 
> 
> This is the line I am using:
> export LD_LIBRARY_PATH=/usr/lib64/atlas:$LD_LIBRARY_PATH
> 
> Our README says LAPACK >= 3.5, so I suspect the system lapack won’t work out. 
> Assuming that symbol is present in the libsatlas file, perhaps try also 
> copying it in julia’s usr/lib.
> 
> The other thing is to run make again to make sure that all the rpath and 
> linking stuff has gone through fine. Or perhaps make cleanall and make.
> 
> -viral
> 
> 
> 
>> On Jul 19, 2016, at 6:55 PM, James Fairbanks  wrote:
>> 
>> For completeness I should say that the julia executable appears not to have 
>> the libjulia.so correctly linked.
>> 
>> $ ./julia
>> ./julia: symbol lookup error: /home/jpf/julia/usr/bin/../lib/liblapack.so: 
>> undefined symbol: lsame_
>> $ ldd ./julia
>>linux-vdso64.so.1 =>  (0x3fff9d14)
>>libjulia.so.0.5 => not found
>>libdl.so.2 => /lib64/libdl.so.2 (0x3fff9d10)
>>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff9d0d)
>>libpthread.so.0 => /lib64/power8/libpthread.so.0 (0x3fff9d09)
>>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9ceb)
>>/lib64/ld64.so.2 (0x251e)
>> 
>> $ ldd ./usr/lib/libjulia.so
>>linux-vdso64.so.1 =>  (0x3fff9968)
>>libLLVM-3.8.so => /home/jpf/julia/./usr/lib/libLLVM-3.8.so 
>> (0x3fff97d8)
>>libdl.so.2 => /lib64/libdl.so.2 (0x3fff97d4)
>>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff97d1)
>>libpthread.so.0 => /lib64/power8/libpthread.so.0 (0x3fff97cd)
>>libstdc++.so.6 => /lib64/libstdc++.so.6 (0x3fff97b5)
>>libm.so.6 => /lib64/power8/libm.so.6 (0x3fff97a6)
>>libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x3fff97a2)
>>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9784)
>>libz.so.1 => /lib64/libz.so.1 (0x3fff9780)
>>/lib64/ld64.so.2 (0x35a0)
>> 
>> On Tuesday, July 19, 2016 at 6:30:34 PM UTC-4, James Fairbanks wrote:
>> Adding /usr/lib64/atlas was insufficient so I created a symlink in ln -s 
>> /usr/lib/atlas/libsatlas.so.3 /usr/lib/atlas/libsatlas.so
>> This allowed the build process to complete but leads to an error when 
>> running the julia executable.
>> 
>> The error is:
>> /home/jpf/julia/usr/bin/julia: symbol lookup error: 
>> /home/jpf/julia/usr/bin/../lib/liblapack.so: undefined symbol: lsame_
>> 
>> Is it a good idea to go with the RHEL ppc64le system lapack instead of 
>> having julia build lapack against system blas?
>> I have this version of lapack available from the system.
>> 
>> Available Packages
>> Name: lapack
>> Arch: ppc64le
>> Version : 3.4.2
>> Release : 5.el7
>> Size: 4.9 M
>> Repo: rhel-7-for-power-le-rpms/7Server/ppc64le
>> 
>> 
>> Thanks,
>>  James
>> On Tuesday, July 19, 2016 at 4:46:22 PM UTC-4, Viral Shah wrote:
>> 
>> Yes - I forgot to mention that. On the machine I am using, I had to add 
>> /usr/lib64/atlas or something like that to LD_LIBRARY_PATH. I can’t login at 
>> the moment for some reason, or else I could have retrieved the exact line. 
>> 
>> 
>> -viral 
>> 
>> 
>> 
>>> On Jul 19, 2016, at 4:12 PM, James Fairbanks  wrote: 
>>> 
>>> I set it up like you said and got the following error 
>>> 
>>> $ make 
>>> ... a bunch of stuff successfully building ... 
>>> /usr/bin/ld: cannot find -lsatlas 
>>> collect2: error: ld returned 1 exit status 
>>> make[1]: *** [build/lapack-3.5.0/liblapack.so] Error 1 
>>> make: *** [julia-deps] Error 2 
>>> 
>>> Do I need to add something to LD_LIBRARY_PATH in the makefile or bash 
>>> environment? 
>>> 
>>> On Tuesday, July 19, 2016 at 3:59:55 PM UTC-4, Viral Shah wrote: 
>>> There is some old ATLAS stuff in there to build atlas that hasn’t been used 
>>> for a very long time. We are going to delete it. If we find this atlas 
>>> stuff to be generally useful, we can bring it into the Makefile - but I 
>>> definitely don’t want to support a source build. 
>>> 
>>> override USE_SYSTEM_BLAS = 1 
>>> override LIBBLAS = -L/usr/lib64/atlas -lsatlas 
>>> override LIBBLASNAME = libsatlas 
>>> override USE_BLAS64 = 0 
>>> override JULIA_THREADS := 0 
>>> 
>>> Use the vs/ccall-ppc branch that I just pushed, with the above Make.user.  
>>> Master still doesn’t work. 
>>> 
>>> -viral 
>>> 
>>> 
 On Jul 19, 2016, at 3:49 PM, James Fairbanks  wrote: 
 
 You are overriding the SYSTEM_BLAS with ATLAS. There is a USE_ATLAS 
 option. Sould that work? 
 
 the relevant part from Make.inc is 
 
 USE_ATLAS := 0 
 

Re: [julia-users] @sprintf variable length padding

[Tamas Papp]

Thanks --- this is helpful for my particular problem, but I am still
curious about how to do this with @sprintf (or whether it is currently
not supported).

Best,

Tamas

On Wed, Jul 20 2016, Stefan Karpinski wrote:

> julia> lpad(12, 4, 0)
> "0012"
>
> On Wed, Jul 20, 2016 at 9:05 AM, Tamas Papp  wrote:
>
>> Hi,
>>
>> how can I @sprintf an integer i padded to length l with zeros, where l
>> is not a constant? Current workaround is
>>
>> printpad(i, l) = mapreduce(string, *, reverse(digits(i, 10, l)))
>>
>> julia> printpad(12, 4)
>> "0012"
>>
>> but I could not figure out how to do this with @sprintf. If my
>> understanding of printf syntax is correct, something like
>>
>> @sprintf("%*d", 4, 12)
>>
>> should do the trick, but in Julia it is an invalid format string.
>>
>> Best,
>>
>> Tamas
>>

[julia-users] FFT, PSD and Windowing functions

[Yared Melese]

Hello 

Would you please let me know the package available to do windowing, FFT and 
PSD? 

Currently, I have bin file that I have processed in Julia and need to 
window it and take preferably PSD but FFT work as well

Thanks 
Yared

 

Re: [julia-users] Re: Using gemm!()

[Ahmed Mazari]

Thanks a lot it's more clear for me

On Wed, Jul 20, 2016 at 4:01 PM, Stefan Karpinski 
wrote:

> This page is a bit more helpful:
>
>
> http://www.ibm.com/support/knowledgecenter/SSFHY8_5.2.0/com.ibm.cluster.essl.v5r2.essl100.doc/am5gr_hsgemm.htm
>
> N = no transform
> T = transpose
> C = conjugate transpose
>
> On Wed, Jul 20, 2016 at 9:48 AM, Ahmed Mazari 
> wrote:
>
>> l still don't understand 'N' , 'T' . Any clarifications please ?
>>
>> TRANSA = 'N' or 'n',  op( A ) = A.
>>
>>  TRANSA = 'T' or 't',  op( A ) = A'.
>>
>> TRANSB = 'N' or 'n',  op( B ) = B.
>>
>>  TRANSB = 'T' or 't',  op( B ) = B'.
>>
>>  TRANSB = 'C' or 'c',  op( B ) = B'.
>>
>>
>> On Wed, Jul 20, 2016 at 3:36 PM, Steven G. Johnson > > wrote:
>>
>>>
>>>
>>> On Wednesday, July 20, 2016 at 9:33:37 AM UTC-4, Ahmed Mazari wrote:

 l'm new to julia. l want to use the Blas package. To do so, the meaning
 of the two first parameters of gemm function are less evident for me What
 the parameters 'N', 'T' represent?

>>>
>>> Those exactly correspond to arguments to the Fortran dgemm subroutine (
>>> http://www.math.utah.edu/software/lapack/lapack-blas/dgemm.html).  They
>>> indicate whether the matrices are to be treated as transposed.
>>>
>>>
  BLAS.gemm!('N', 'T', lr,  alpha, A, B, beta, C)

 What is the difference between BLAS.gemm and BLAS.gemm! ?

>>>
>>> The convention in Julia is that appending an exclamation mark (e.g.
>>> gemm!) indicates that the function modifies one of its arguments in-place,
>>> whereas gemm allocates a new array for the result.
>>>
>>
>>
>

Re: [julia-users] Re: Using gemm!()

[Stefan Karpinski]

It's a weird API but this is how it's been done since antiquity.

On Wed, Jul 20, 2016 at 10:04 AM, Ahmed Mazari 
wrote:

> Thanks a lot it's more clear for me
>
> On Wed, Jul 20, 2016 at 4:01 PM, Stefan Karpinski 
> wrote:
>
>> This page is a bit more helpful:
>>
>>
>> http://www.ibm.com/support/knowledgecenter/SSFHY8_5.2.0/com.ibm.cluster.essl.v5r2.essl100.doc/am5gr_hsgemm.htm
>>
>> N = no transform
>> T = transpose
>> C = conjugate transpose
>>
>> On Wed, Jul 20, 2016 at 9:48 AM, Ahmed Mazari 
>> wrote:
>>
>>> l still don't understand 'N' , 'T' . Any clarifications please ?
>>>
>>> TRANSA = 'N' or 'n',  op( A ) = A.
>>>
>>>  TRANSA = 'T' or 't',  op( A ) = A'.
>>>
>>> TRANSB = 'N' or 'n',  op( B ) = B.
>>>
>>>  TRANSB = 'T' or 't',  op( B ) = B'.
>>>
>>>  TRANSB = 'C' or 'c',  op( B ) = B'.
>>>
>>>
>>> On Wed, Jul 20, 2016 at 3:36 PM, Steven G. Johnson <
>>> stevenj@gmail.com> wrote:
>>>


 On Wednesday, July 20, 2016 at 9:33:37 AM UTC-4, Ahmed Mazari wrote:
>
> l'm new to julia. l want to use the Blas package. To do so, the
> meaning of the two first parameters of gemm function are less evident for
> me What the parameters 'N', 'T' represent?
>

 Those exactly correspond to arguments to the Fortran dgemm subroutine (
 http://www.math.utah.edu/software/lapack/lapack-blas/dgemm.html).
 They indicate whether the matrices are to be treated as transposed.


>  BLAS.gemm!('N', 'T', lr,  alpha, A, B, beta, C)
>
> What is the difference between BLAS.gemm and BLAS.gemm! ?
>

 The convention in Julia is that appending an exclamation mark (e.g.
 gemm!) indicates that the function modifies one of its arguments in-place,
 whereas gemm allocates a new array for the result.

>>>
>>>
>>
>

Re: [julia-users] Re: Using gemm!()

[Ahmed Mazari]

loool

On Wed, Jul 20, 2016 at 4:12 PM, Stefan Karpinski 
wrote:

> It's a weird API but this is how it's been done since antiquity.
>
> On Wed, Jul 20, 2016 at 10:04 AM, Ahmed Mazari 
> wrote:
>
>> Thanks a lot it's more clear for me
>>
>> On Wed, Jul 20, 2016 at 4:01 PM, Stefan Karpinski 
>> wrote:
>>
>>> This page is a bit more helpful:
>>>
>>>
>>> http://www.ibm.com/support/knowledgecenter/SSFHY8_5.2.0/com.ibm.cluster.essl.v5r2.essl100.doc/am5gr_hsgemm.htm
>>>
>>> N = no transform
>>> T = transpose
>>> C = conjugate transpose
>>>
>>> On Wed, Jul 20, 2016 at 9:48 AM, Ahmed Mazari 
>>> wrote:
>>>
 l still don't understand 'N' , 'T' . Any clarifications please ?

 TRANSA = 'N' or 'n',  op( A ) = A.

  TRANSA = 'T' or 't',  op( A ) = A'.

 TRANSB = 'N' or 'n',  op( B ) = B.

  TRANSB = 'T' or 't',  op( B ) = B'.

  TRANSB = 'C' or 'c',  op( B ) = B'.


 On Wed, Jul 20, 2016 at 3:36 PM, Steven G. Johnson <
 stevenj@gmail.com> wrote:

>
>
> On Wednesday, July 20, 2016 at 9:33:37 AM UTC-4, Ahmed Mazari wrote:
>>
>> l'm new to julia. l want to use the Blas package. To do so, the
>> meaning of the two first parameters of gemm function are less evident for
>> me What the parameters 'N', 'T' represent?
>>
>
> Those exactly correspond to arguments to the Fortran dgemm subroutine (
> http://www.math.utah.edu/software/lapack/lapack-blas/dgemm.html).
> They indicate whether the matrices are to be treated as transposed.
>
>
>>  BLAS.gemm!('N', 'T', lr,  alpha, A, B, beta, C)
>>
>> What is the difference between BLAS.gemm and BLAS.gemm! ?
>>
>
> The convention in Julia is that appending an exclamation mark (e.g.
> gemm!) indicates that the function modifies one of its arguments in-place,
> whereas gemm allocates a new array for the result.
>


>>>
>>
>

Re: [julia-users] Re: Using gemm!()

[Stefan Karpinski]

This page is a bit more helpful:

http://www.ibm.com/support/knowledgecenter/SSFHY8_5.2.0/com.ibm.cluster.essl.v5r2.essl100.doc/am5gr_hsgemm.htm

N = no transform
T = transpose
C = conjugate transpose

On Wed, Jul 20, 2016 at 9:48 AM, Ahmed Mazari 
wrote:

> l still don't understand 'N' , 'T' . Any clarifications please ?
>
> TRANSA = 'N' or 'n',  op( A ) = A.
>
>  TRANSA = 'T' or 't',  op( A ) = A'.
>
> TRANSB = 'N' or 'n',  op( B ) = B.
>
>  TRANSB = 'T' or 't',  op( B ) = B'.
>
>  TRANSB = 'C' or 'c',  op( B ) = B'.
>
>
> On Wed, Jul 20, 2016 at 3:36 PM, Steven G. Johnson 
> wrote:
>
>>
>>
>> On Wednesday, July 20, 2016 at 9:33:37 AM UTC-4, Ahmed Mazari wrote:
>>>
>>> l'm new to julia. l want to use the Blas package. To do so, the meaning
>>> of the two first parameters of gemm function are less evident for me What
>>> the parameters 'N', 'T' represent?
>>>
>>
>> Those exactly correspond to arguments to the Fortran dgemm subroutine (
>> http://www.math.utah.edu/software/lapack/lapack-blas/dgemm.html).  They
>> indicate whether the matrices are to be treated as transposed.
>>
>>
>>>  BLAS.gemm!('N', 'T', lr,  alpha, A, B, beta, C)
>>>
>>> What is the difference between BLAS.gemm and BLAS.gemm! ?
>>>
>>
>> The convention in Julia is that appending an exclamation mark (e.g.
>> gemm!) indicates that the function modifies one of its arguments in-place,
>> whereas gemm allocates a new array for the result.
>>
>
>

Re: [julia-users] @sprintf variable length padding

[Stefan Karpinski]

julia> lpad(12, 4, 0)
"0012"

On Wed, Jul 20, 2016 at 9:05 AM, Tamas Papp  wrote:

> Hi,
>
> how can I @sprintf an integer i padded to length l with zeros, where l
> is not a constant? Current workaround is
>
> printpad(i, l) = mapreduce(string, *, reverse(digits(i, 10, l)))
>
> julia> printpad(12, 4)
> "0012"
>
> but I could not figure out how to do this with @sprintf. If my
> understanding of printf syntax is correct, something like
>
> @sprintf("%*d", 4, 12)
>
> should do the trick, but in Julia it is an invalid format string.
>
> Best,
>
> Tamas
>

Re: [julia-users] Re: Using gemm!()

[Ahmed Mazari]

l still don't understand 'N' , 'T' . Any clarifications please ?

TRANSA = 'N' or 'n',  op( A ) = A.

 TRANSA = 'T' or 't',  op( A ) = A'.

TRANSB = 'N' or 'n',  op( B ) = B.

 TRANSB = 'T' or 't',  op( B ) = B'.

 TRANSB = 'C' or 'c',  op( B ) = B'.


On Wed, Jul 20, 2016 at 3:36 PM, Steven G. Johnson 
wrote:

>
>
> On Wednesday, July 20, 2016 at 9:33:37 AM UTC-4, Ahmed Mazari wrote:
>>
>> l'm new to julia. l want to use the Blas package. To do so, the meaning
>> of the two first parameters of gemm function are less evident for me What
>> the parameters 'N', 'T' represent?
>>
>
> Those exactly correspond to arguments to the Fortran dgemm subroutine (
> http://www.math.utah.edu/software/lapack/lapack-blas/dgemm.html).  They
> indicate whether the matrices are to be treated as transposed.
>
>
>>  BLAS.gemm!('N', 'T', lr,  alpha, A, B, beta, C)
>>
>> What is the difference between BLAS.gemm and BLAS.gemm! ?
>>
>
> The convention in Julia is that appending an exclamation mark (e.g. gemm!)
> indicates that the function modifies one of its arguments in-place, whereas
> gemm allocates a new array for the result.
>

[julia-users] Re: Using gemm!()

[Steven G. Johnson]

On Wednesday, July 20, 2016 at 9:33:37 AM UTC-4, Ahmed Mazari wrote:
>
> l'm new to julia. l want to use the Blas package. To do so, the meaning of 
> the two first parameters of gemm function are less evident for me What the 
> parameters 'N', 'T' represent?
>

Those exactly correspond to arguments to the Fortran dgemm subroutine 
(http://www.math.utah.edu/software/lapack/lapack-blas/dgemm.html).  They 
indicate whether the matrices are to be treated as transposed.
 

>  BLAS.gemm!('N', 'T', lr,  alpha, A, B, beta, C)
>
> What is the difference between BLAS.gemm and BLAS.gemm! ?
>

The convention in Julia is that appending an exclamation mark (e.g. gemm!) 
indicates that the function modifies one of its arguments in-place, whereas 
gemm allocates a new array for the result.

[julia-users] Using gemm!()

[Ahmed Mazari]

 

l'm new to julia. l want to use the Blas package. To do so, the meaning of 
the two first parameters of gemm function are less evident for me What the 
parameters 'N', 'T' represent?

 BLAS.gemm!('N', 'T', lr,  alpha, A, B, beta, C)

What is the difference between BLAS.gemm and BLAS.gemm! ? 

Re: [julia-users] Re: isdefined with local variables

[Isaiah Norton]

>
> ​I want the behavior seen in t with the macro. t2 with `isdefined` has the
> "wrong" and counterintuitive behavior.​


Please see the documentation for `isdefined`, which mentions that
`isdefined` only works at module scope:

http://docs.julialang.org/en/release-0.4/stdlib/base/#Base.isdefined

As far as why `isdefined` and `eval` don't do what you want (work in local
scope): this is an explicit design decision. See explanation here:

https://github.com/JuliaLang/julia/issues/2386#issuecomment-13966397

On Wed, Jul 20, 2016 at 9:10 AM, Christopher Rinderspacher <
crind...@gmail.com> wrote:

> Here's a session demonstrating what I see:
>
> julia> macro isDefined(x)
>   return :(defined = true; try eval($x); catch e; defined =
> !isa(e,UndefVarError); end; defined)
>end
>
> julia> function t()
>   if !@isDefined(x)
>println("x is not defined")
>   end
>   x = 1
>   if !@isDefined(x)
>   println("x should be defined.")
>   end
>end
> t (generic function with 1 method)
>
> julia> t()
> x is not defined
>
> julia> function t2()
>   if !isdefined(:x)
>  println("x is not defined")
>   end
>   x = 1
>   if !isdefined(:x)
>  println("x is defined, but `isdefined` doesn't recognize it.")
>   end
>end
> t2 (generic function with 1 method)
>
> julia> t2()
> x is not defined
> x is defined, but `isdefined` doesn't recognize it.
>
> julia>
>
> ​I want the behavior seen in t with the macro. t2 with `isdefined` has the
> "wrong" and counterintuitive behavior.​
> Since the macro is a product of trial and error (no pun intended), I can
> only rationalize its behavior.
>
>
>
> On Wed, Jul 20, 2016 at 8:37 AM, Yichao Yu  wrote:
>
>> On Wed, Jul 20, 2016 at 8:32 AM, Christopher Rinderspacher
>>  wrote:
>> > My solution right now is a macro
>> >
>> > macro isDefined(x)
>> >return :(defined = true; try eval($x); catch e; defined =
>> > isa(e,UndefVarError); end; defined)
>>
>> It's unclear what you are trying to do here. The eval is likely a
>> no-op or not doing what you want. `$x` should probably be escaped.
>>
>> > end
>> >
>> > I find this to be very clunky, but it works for my limited test cases.
>> >
>> >> All compile-time undefined bindings become a runtime lookup from the
>> >> enclosing (i.e. module) scope. The undefined error means that this
>> lookup
>> >> failed.
>> >
>> > If that is so, what is the function I can call to determine whether my
>> > variable is in scope? `isdefined` is definitely _not_ that function.
>> How do
>> > I need to call that function from Julia? Your explanation is not a
>> solution
>> > to my problem.
>> >
>> >
>> >
>> > On Wed, Jul 20, 2016 at 12:01 AM, Yichao Yu  wrote:
>> >>
>> >> On Tue, Jul 19, 2016 at 11:54 PM, Isaiah Norton <
>> isaiah.nor...@gmail.com>
>> >> wrote:
>> >> > Creating variables dynamically at local scope is not possible (if you
>> >> > are
>> >> > calling `eval` inside a function: it does not work like that!)
>> >> >
>> >> >> Since the runtime can determine that the local variable is
>> undefined as
>> >> >> evidenced by an appropriate error
>> >> >
>> >> >
>> >> > All compile-time undefined bindings become a runtime lookup from the
>> >> > enclosing (i.e. module) scope. The undefined error means that this
>> >> > lookup
>> >> > failed.
>> >>
>> >> We do have local only variables that can be undefined.
>> >>
>> >> >
>> >> >
>> >> > On Tue, Jul 19, 2016 at 10:43 PM, Christopher Rinderspacher
>> >> >  wrote:
>> >> >>
>> >> >> I, too, would like to be able to check whether local variables are
>> >> >> defined. In my case, I am parsing a file that doesn't allow
>> >> >> redefinition of
>> >> >> a field. The natural way to do this is to check whether I've
>> previously
>> >> >> assigned a variable with the content.
>> >> >>
>> >> >> The fact that isdefined only looks at the module scope is really
>> >> >> irrelevant to my use case. Since the runtime can determine that the
>> >> >> local
>> >> >> variable is undefined as evidenced by an appropriate error, I wish I
>> >> >> could
>> >> >> do the same within my function without some clunky try ... catch
>> >> >> mehcanism.
>> >>
>> >> A separate bool flag or a Nullable should work equally well.
>> >>
>> >> >>
>> >> >>
>> >> >> On Monday, May 11, 2015 at 7:31:06 PM UTC-4, Juha Heiskala wrote:
>> >> >>>
>> >> >>>  Hello,
>> >> >>>
>> >> >>> Am I missing something or doesn't isdefined detect local variables
>> of
>> >> >>> a
>> >> >>> function?
>> >> >>>
>> >> >>>
>> >> >>> julia> foo()= begin bar=1; isdefined(current_module(), :bar); end
>> >> >>> foo (generic function with 1 method)
>> >> >>>
>> >> >>> julia> foo()
>> >> >>> false
>> >> >>>
>> >> >>> Best Regards,
>> >> >>>
>> >> >>> Juha
>> >> >>>
>> >> >>> julia version 0.3.5
>> >> >>>
>> >> >>> julia> versioninfo()
>> >> >>> 

Re: [julia-users] Re: isdefined with local variables

[Christopher Rinderspacher]

Here's a session demonstrating what I see:

julia> macro isDefined(x)
  return :(defined = true; try eval($x); catch e; defined =
!isa(e,UndefVarError); end; defined)
   end

julia> function t()
  if !@isDefined(x)
   println("x is not defined")
  end
  x = 1
  if !@isDefined(x)
  println("x should be defined.")
  end
   end
t (generic function with 1 method)

julia> t()
x is not defined

julia> function t2()
  if !isdefined(:x)
 println("x is not defined")
  end
  x = 1
  if !isdefined(:x)
 println("x is defined, but `isdefined` doesn't recognize it.")
  end
   end
t2 (generic function with 1 method)

julia> t2()
x is not defined
x is defined, but `isdefined` doesn't recognize it.

julia>

​I want the behavior seen in t with the macro. t2 with `isdefined` has the
"wrong" and counterintuitive behavior.​
Since the macro is a product of trial and error (no pun intended), I can
only rationalize its behavior.



On Wed, Jul 20, 2016 at 8:37 AM, Yichao Yu  wrote:

> On Wed, Jul 20, 2016 at 8:32 AM, Christopher Rinderspacher
>  wrote:
> > My solution right now is a macro
> >
> > macro isDefined(x)
> >return :(defined = true; try eval($x); catch e; defined =
> > isa(e,UndefVarError); end; defined)
>
> It's unclear what you are trying to do here. The eval is likely a
> no-op or not doing what you want. `$x` should probably be escaped.
>
> > end
> >
> > I find this to be very clunky, but it works for my limited test cases.
> >
> >> All compile-time undefined bindings become a runtime lookup from the
> >> enclosing (i.e. module) scope. The undefined error means that this
> lookup
> >> failed.
> >
> > If that is so, what is the function I can call to determine whether my
> > variable is in scope? `isdefined` is definitely _not_ that function. How
> do
> > I need to call that function from Julia? Your explanation is not a
> solution
> > to my problem.
> >
> >
> >
> > On Wed, Jul 20, 2016 at 12:01 AM, Yichao Yu  wrote:
> >>
> >> On Tue, Jul 19, 2016 at 11:54 PM, Isaiah Norton <
> isaiah.nor...@gmail.com>
> >> wrote:
> >> > Creating variables dynamically at local scope is not possible (if you
> >> > are
> >> > calling `eval` inside a function: it does not work like that!)
> >> >
> >> >> Since the runtime can determine that the local variable is undefined
> as
> >> >> evidenced by an appropriate error
> >> >
> >> >
> >> > All compile-time undefined bindings become a runtime lookup from the
> >> > enclosing (i.e. module) scope. The undefined error means that this
> >> > lookup
> >> > failed.
> >>
> >> We do have local only variables that can be undefined.
> >>
> >> >
> >> >
> >> > On Tue, Jul 19, 2016 at 10:43 PM, Christopher Rinderspacher
> >> >  wrote:
> >> >>
> >> >> I, too, would like to be able to check whether local variables are
> >> >> defined. In my case, I am parsing a file that doesn't allow
> >> >> redefinition of
> >> >> a field. The natural way to do this is to check whether I've
> previously
> >> >> assigned a variable with the content.
> >> >>
> >> >> The fact that isdefined only looks at the module scope is really
> >> >> irrelevant to my use case. Since the runtime can determine that the
> >> >> local
> >> >> variable is undefined as evidenced by an appropriate error, I wish I
> >> >> could
> >> >> do the same within my function without some clunky try ... catch
> >> >> mehcanism.
> >>
> >> A separate bool flag or a Nullable should work equally well.
> >>
> >> >>
> >> >>
> >> >> On Monday, May 11, 2015 at 7:31:06 PM UTC-4, Juha Heiskala wrote:
> >> >>>
> >> >>>  Hello,
> >> >>>
> >> >>> Am I missing something or doesn't isdefined detect local variables
> of
> >> >>> a
> >> >>> function?
> >> >>>
> >> >>>
> >> >>> julia> foo()= begin bar=1; isdefined(current_module(), :bar); end
> >> >>> foo (generic function with 1 method)
> >> >>>
> >> >>> julia> foo()
> >> >>> false
> >> >>>
> >> >>> Best Regards,
> >> >>>
> >> >>> Juha
> >> >>>
> >> >>> julia version 0.3.5
> >> >>>
> >> >>> julia> versioninfo()
> >> >>> Julia Version 0.3.5
> >> >>> Commit a05f87b* (2015-01-08 22:33 UTC)
> >> >>> Platform Info:
> >> >>>   System: Linux (x86_64-linux-gnu)
> >> >>>   CPU: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
> >> >>>   WORD_SIZE: 64
> >> >>>   BLAS: libopenblas (NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY)
> >> >>>   LAPACK: liblapack.so.3
> >> >>>   LIBM: libopenlibm
> >> >>>   LLVM: libLLVM-3.3
> >> >
> >> >
> >
> >
>

[julia-users] @sprintf variable length padding

[Tamas Papp]

Hi,

how can I @sprintf an integer i padded to length l with zeros, where l
is not a constant? Current workaround is

printpad(i, l) = mapreduce(string, *, reverse(digits(i, 10, l)))

julia> printpad(12, 4)
"0012"

but I could not figure out how to do this with @sprintf. If my
understanding of printf syntax is correct, something like

@sprintf("%*d", 4, 12)

should do the trick, but in Julia it is an invalid format string.

Best,

Tamas

Re: [julia-users] Re: isdefined with local variables

[Yichao Yu]

On Wed, Jul 20, 2016 at 8:32 AM, Christopher Rinderspacher
 wrote:
> My solution right now is a macro
>
> macro isDefined(x)
>return :(defined = true; try eval($x); catch e; defined =
> isa(e,UndefVarError); end; defined)

It's unclear what you are trying to do here. The eval is likely a
no-op or not doing what you want. `$x` should probably be escaped.

> end
>
> I find this to be very clunky, but it works for my limited test cases.
>
>> All compile-time undefined bindings become a runtime lookup from the
>> enclosing (i.e. module) scope. The undefined error means that this lookup
>> failed.
>
> If that is so, what is the function I can call to determine whether my
> variable is in scope? `isdefined` is definitely _not_ that function. How do
> I need to call that function from Julia? Your explanation is not a solution
> to my problem.
>
>
>
> On Wed, Jul 20, 2016 at 12:01 AM, Yichao Yu  wrote:
>>
>> On Tue, Jul 19, 2016 at 11:54 PM, Isaiah Norton 
>> wrote:
>> > Creating variables dynamically at local scope is not possible (if you
>> > are
>> > calling `eval` inside a function: it does not work like that!)
>> >
>> >> Since the runtime can determine that the local variable is undefined as
>> >> evidenced by an appropriate error
>> >
>> >
>> > All compile-time undefined bindings become a runtime lookup from the
>> > enclosing (i.e. module) scope. The undefined error means that this
>> > lookup
>> > failed.
>>
>> We do have local only variables that can be undefined.
>>
>> >
>> >
>> > On Tue, Jul 19, 2016 at 10:43 PM, Christopher Rinderspacher
>> >  wrote:
>> >>
>> >> I, too, would like to be able to check whether local variables are
>> >> defined. In my case, I am parsing a file that doesn't allow
>> >> redefinition of
>> >> a field. The natural way to do this is to check whether I've previously
>> >> assigned a variable with the content.
>> >>
>> >> The fact that isdefined only looks at the module scope is really
>> >> irrelevant to my use case. Since the runtime can determine that the
>> >> local
>> >> variable is undefined as evidenced by an appropriate error, I wish I
>> >> could
>> >> do the same within my function without some clunky try ... catch
>> >> mehcanism.
>>
>> A separate bool flag or a Nullable should work equally well.
>>
>> >>
>> >>
>> >> On Monday, May 11, 2015 at 7:31:06 PM UTC-4, Juha Heiskala wrote:
>> >>>
>> >>>  Hello,
>> >>>
>> >>> Am I missing something or doesn't isdefined detect local variables of
>> >>> a
>> >>> function?
>> >>>
>> >>>
>> >>> julia> foo()= begin bar=1; isdefined(current_module(), :bar); end
>> >>> foo (generic function with 1 method)
>> >>>
>> >>> julia> foo()
>> >>> false
>> >>>
>> >>> Best Regards,
>> >>>
>> >>> Juha
>> >>>
>> >>> julia version 0.3.5
>> >>>
>> >>> julia> versioninfo()
>> >>> Julia Version 0.3.5
>> >>> Commit a05f87b* (2015-01-08 22:33 UTC)
>> >>> Platform Info:
>> >>>   System: Linux (x86_64-linux-gnu)
>> >>>   CPU: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
>> >>>   WORD_SIZE: 64
>> >>>   BLAS: libopenblas (NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY)
>> >>>   LAPACK: liblapack.so.3
>> >>>   LIBM: libopenlibm
>> >>>   LLVM: libLLVM-3.3
>> >
>> >
>
>

Re: [julia-users] Re: isdefined with local variables

[Christopher Rinderspacher]

My solution right now is a macro

macro isDefined(x)
   return :(defined = true; try eval($x); catch e; defined =
isa(e,UndefVarError); end; defined)
end

I find this to be very clunky, but it works for my limited test cases.

> All compile-time undefined bindings become a runtime lookup from the
> enclosing (i.e. module) scope. The undefined error means that this lookup
> failed.

If that is so, what is the function I can call to determine whether my
variable is in scope? `isdefined` is definitely _not_ that function. How do
I need to call that function from Julia? Your explanation is not a solution
to my problem.



On Wed, Jul 20, 2016 at 12:01 AM, Yichao Yu  wrote:

> On Tue, Jul 19, 2016 at 11:54 PM, Isaiah Norton 
> wrote:
> > Creating variables dynamically at local scope is not possible (if you are
> > calling `eval` inside a function: it does not work like that!)
> >
> >> Since the runtime can determine that the local variable is undefined as
> >> evidenced by an appropriate error
> >
> >
> > All compile-time undefined bindings become a runtime lookup from the
> > enclosing (i.e. module) scope. The undefined error means that this lookup
> > failed.
>
> We do have local only variables that can be undefined.
>
> >
> >
> > On Tue, Jul 19, 2016 at 10:43 PM, Christopher Rinderspacher
> >  wrote:
> >>
> >> I, too, would like to be able to check whether local variables are
> >> defined. In my case, I am parsing a file that doesn't allow
> redefinition of
> >> a field. The natural way to do this is to check whether I've previously
> >> assigned a variable with the content.
> >>
> >> The fact that isdefined only looks at the module scope is really
> >> irrelevant to my use case. Since the runtime can determine that the
> local
> >> variable is undefined as evidenced by an appropriate error, I wish I
> could
> >> do the same within my function without some clunky try ... catch
> mehcanism.
>
> A separate bool flag or a Nullable should work equally well.
>
> >>
> >>
> >> On Monday, May 11, 2015 at 7:31:06 PM UTC-4, Juha Heiskala wrote:
> >>>
> >>>  Hello,
> >>>
> >>> Am I missing something or doesn't isdefined detect local variables of a
> >>> function?
> >>>
> >>>
> >>> julia> foo()= begin bar=1; isdefined(current_module(), :bar); end
> >>> foo (generic function with 1 method)
> >>>
> >>> julia> foo()
> >>> false
> >>>
> >>> Best Regards,
> >>>
> >>> Juha
> >>>
> >>> julia version 0.3.5
> >>>
> >>> julia> versioninfo()
> >>> Julia Version 0.3.5
> >>> Commit a05f87b* (2015-01-08 22:33 UTC)
> >>> Platform Info:
> >>>   System: Linux (x86_64-linux-gnu)
> >>>   CPU: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
> >>>   WORD_SIZE: 64
> >>>   BLAS: libopenblas (NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY)
> >>>   LAPACK: liblapack.so.3
> >>>   LIBM: libopenlibm
> >>>   LLVM: libLLVM-3.3
> >
> >
>

Re: [julia-users] Re: Linear-Equation-System Solver("\") does not work reliably for the "Rational" Type

[Kurolong]

Ah right, so what you are doing is just solving successively for L and U.
Okay, all questions answered.
Thank you^^

Re: [julia-users] Re: Possible bug: very slow module load after addprocs()

[Marius Millea]

I don't think that theory totally works, it seems to scale to some extent 
with the length of time to load the package itself. Another example:

julia> tic(); using PyPlot; toc()
elapsed time: 3.395904233 seconds

vs

julia> addprocs();
julia> tic(); using PyPlot; toc()
elapsed time: 13.877550518 seconds

or even:

julia> addprocs();
julia> using Empty; tic(); using PyPlot; toc()
elapsed time: 7.357315778 seconds


In any case, it can get pretty painful loading a few modules at the 
beginning of my parallelized scripts... 




On Tuesday, July 19, 2016 at 4:55:40 PM UTC+2, Cedric St-Jean wrote:
>
> Yes, that's what I meant. Presumably the multi-proc machinery is getting 
> compiled at the first `using`. It's the same reason why "println(2+2)" is 
> very slow on first use, but fast afterwards. 
>
> On Tue, Jul 19, 2016 at 10:41 AM, Marius Millea  > wrote:
>
>> Seems it may have something to do with that. If I understood correctly 
>> what you're saying, if I create Empty2.jl defining module Empty2, I get, 
>>
>> julia> addprocs();
>>
>> julia> tic(); using Empty; toc()
>> elapsed time: 2.706353202 seconds
>> 2.706353202
>>
>> julia> tic(); using Empty; toc()
>> elapsed time: 0.00042397 seconds
>> 0.00042397
>>
>> julia> tic(); using Empty2; toc()
>> elapsed time: 0.029200919 seconds
>> 0.029200919
>>
>> julia> tic(); using Empty2; toc()
>> elapsed time: 0.000193097 seconds
>> 0.000193097
>>
>>
>>
>> That first load of Empty2 at 0.02 secs is much more in line with what 
>> loading it on a single processor takes. 
>>
>>
>>
>> On Tuesday, July 19, 2016 at 4:13:15 PM UTC+2, Cedric St-Jean wrote:
>>>
>>> Maybe there is some warm-up JIT time in there? If you create an Empty2 
>>> module and load it after Empty, is it also slow?
>>>
>>> On Tuesday, July 19, 2016 at 9:07:01 AM UTC-4, Marius Millea wrote:

 I noticed that once I addprocs(), subsequent "using" statements were 
 extremely slow. I guess in this case its loading the module on each 
 processor, but if it happens in parallel it shouldn't be *that* much more 
 wall time, and here I'm talking about two orders of magnitude difference. 

 Assuming I've got a file Empty.jl who contents is,

 module Empty
 end

 then single threaded:

 tic()
 using Empty
 toc()
 elapsed time: 0.024461076 seconds

 vs. multi-threaded:

 addprocs() #I've got 8 procs
 tic()
 using Empty
 toc()
 elapsed time: 2.479418079 seconds


 Should I submit this as an Issue on Github, or is there something else 
 going on? I've checked both Julia 0.4.5. and 0.5 (01e3c8a). I'm on Ubuntu 
 16.04 64bit. 



>

Re: [julia-users] How to determine the type of a complex data structure

[Fred]

Hi !

Here are the results :

type Ions_frag{}
  mz::Float64 
  intensity::Float64
  charge::Int64 
end


computation time : 26.88 s


immutable Ions_frag

   mz::Float64
   intensity::Float64
   charge::Int64
end


computation time : 27.00 s



Ions = Dict{ASCIIString, Ions_frag}()


immutable Ions_frag


   mz::Float64
   intensity::Float64
   charge::Int64
end
computation time : 17.96 s



Ions = Dict{ASCIIString, Ions_frag}()

type Ions_frag{}
  mz::Float64 
  intensity::Float64
  charge::Int64 
end

computation time : 17.58 s



So, in conclusion "immutable" is better than "type" in theory but not in 
practice. The Dict() type has a major effect on performances !

Thanks !