[julia-users] Re: error while loading shared libraries: libjulia.so

[Jeffrey Sarnoff]

Try using a prebuilt installation for your operating system: 
http://julialang.org/downloads/

On Wednesday, March 9, 2016 at 7:38:34 PM UTC-5, Manu Jain wrote:
>
> My julia code compile successfully. But when I try to run the excecutable 
> it shows - "error while loading shared libraries: libjulia.so: cannot open 
> shared object file: No such file or directory". Please help.
>

[julia-users] Re: Help with pipes

[J Luis]

Thanks but doesn't work either

a = IOBuffer();
print(a, P.ps);

julia> run(pipeline(a, `gswin64c -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox 
-`))
ERROR: MethodError: `uvtype` has no method matching uvtype(::Base.
AbstractIOBuffer{Array{UInt8,1}})
 in _jl_spawn at process.jl:253



domingo, 13 de Março de 2016 às 00:36:19 UTC, ele...@gmail.com escreveu:
>
> Can't test ATM, but argument one IOBuffer(ps_string) ?
>
> On Sunday, 13 March 2016 09:52:52 UTC+10, J Luis wrote:
>>
>> Hi,
>>
>> I need to reproduce a similar behavior of this on command line. 
>>
>> cat barco.eps | gswin64c -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox -
>> %%BoundingBox: 0 0 71 64
>> %%HiResBoundingBox: 0.00 0.00 70.865998 63.305998
>>
>> What it does is to send the contents of a PostScript file (ascii file) 
>> through ghostscript and get the result printed on stdout
>>
>> Now, instead of a file I have in Julia the contents of that file as a 
>> long string and wanted to feed it to ghostscript, first to do the 
>> BoundingBox query and later on to convert the ps into a raster. So I tried
>>
>>  run(pipeline(P.ps, `gswin64c -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox 
>> -`))
>> ERROR: open: no such file or directory (ENOENT)
>>  in open at fs.jl:82
>>
>> I guess the reason lies on the *pipeline *manual mention when it says 
>> that "Strings refer to filenames". So given that P.ps above is a string 
>> it tries to open it as a file.
>> So my question is, how can I put the string inpipeline's first argument 
>> and get the output in a Julia variable?
>>
>> Thanks
>>
>> Joaquim
>>
>

[julia-users] Re: Help with pipes

[elextr]

Can't test ATM, but argument one IOBuffer(ps_string) ?

On Sunday, 13 March 2016 09:52:52 UTC+10, J Luis wrote:
>
> Hi,
>
> I need to reproduce a similar behavior of this on command line. 
>
> cat barco.eps | gswin64c -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox -
> %%BoundingBox: 0 0 71 64
> %%HiResBoundingBox: 0.00 0.00 70.865998 63.305998
>
> What it does is to send the contents of a PostScript file (ascii file) 
> through ghostscript and get the result printed on stdout
>
> Now, instead of a file I have in Julia the contents of that file as a long 
> string and wanted to feed it to ghostscript, first to do the BoundingBox 
> query and later on to convert the ps into a raster. So I tried
>
>  run(pipeline(P.ps, `gswin64c -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox 
> -`))
> ERROR: open: no such file or directory (ENOENT)
>  in open at fs.jl:82
>
> I guess the reason lies on the *pipeline *manual mention when it says 
> that "Strings refer to filenames". So given that P.ps above is a string 
> it tries to open it as a file.
> So my question is, how can I put the string inpipeline's first argument 
> and get the output in a Julia variable?
>
> Thanks
>
> Joaquim
>

[julia-users] Help with pipes

[J Luis]

Hi,

I need to reproduce a similar behavior of this on command line. 

cat barco.eps | gswin64c -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox -
%%BoundingBox: 0 0 71 64
%%HiResBoundingBox: 0.00 0.00 70.865998 63.305998

What it does is to send the contents of a PostScript file (ascii file) 
through ghostscript and get the result printed on stdout

Now, instead of a file I have in Julia the contents of that file as a long 
string and wanted to feed it to ghostscript, first to do the BoundingBox 
query and later on to convert the ps into a raster. So I tried

 run(pipeline(P.ps, `gswin64c -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox -`
))
ERROR: open: no such file or directory (ENOENT)
 in open at fs.jl:82

I guess the reason lies on the *pipeline *manual mention when it says that 
"Strings refer to filenames". So given that P.ps above is a string it tries 
to open it as a file.
So my question is, how can I put the string inpipeline's first argument and 
get the output in a Julia variable?

Thanks

Joaquim

Re: [julia-users] My test is not failing properly

[Milan Bouchet-Valat]

Le samedi 12 mars 2016 à 12:30 -0800, Douglas Bates a écrit :
> I have been adding more tests to the MixedModels package and
> encountered a peculiar situation where, AFAICS, a test should produce
> one type of failure and it doesn't.  It fails at a later point but I
> can't see how it gets there.
> 
> To reproduce, check out a copy of the MixedModels master branch.
> 
> Pkg.add("MixedModels")
> Pkg.checkout("MixedModels")
> MixedModels.inject!(speye(4), sparse(ones(4, 4)))
> 
> The unexported function inject!(A, B) zeros A, then copies the
> contents B into A.   For sparse matrices, the nonzero positions of B
> must be a subset of those in A.  What I expect to happen in this case
> is that the code will enter the block in lines 52 - 54 of https://git
> hub.com/dmbates/MixedModels.jl/blob/master/src/inject.jl.  In fact,
> if you uncomment line 51 in that file the output from the @show macro
> shows that indeed 
> 
> kk > length(dnzrv)
> 
> the second time through the "for k in snzr" loop.  But when I run
> that example, the error thrown is a BoundsError at line 55.   What I
> don't understand is how it gets to line 55 the second time through
> the loop.
> 
> I have been looking at this for a long time trying to see if I am
> doing something stupid but I can't.  Does the BoundsError get thrown
> for others?  My versioninfo is
I was puzzled for a few minutes too, but the explanation is actually
quite simple: you need to call throw() on the error, i.e.
throw(ArgumentError("cannot inject sparse s into sparse d"))

This is indeed an easy to make and hard to spot mistake. Maybe a code
checking tool like Lint.jl would/could have detected that the
ArgumentError wasn't used at all.


Regards

> julia> versioninfo()
> Julia Version 0.4.2
> Commit bb73f34 (2015-12-06 21:47 UTC)
> Platform Info:
>   System: Linux (x86_64-linux-gnu)
>   CPU: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY Prescott)
>   LAPACK: liblapack.so.3
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
> 
> I haven't upgraded to 0.4.3 because the Ubuntu package is not yet
> available but I can test on 0.4.3 if that would help.

[julia-users] My test is not failing properly

[Douglas Bates]

I have been adding more tests to the MixedModels package and encountered a 
peculiar situation where, AFAICS, a test should produce one type of failure 
and it doesn't.  It fails at a later point but I can't see how it gets 
there.

To reproduce, check out a copy of the MixedModels master branch.

Pkg.add("MixedModels")
Pkg.checkout("MixedModels")
MixedModels.inject!(speye(4), sparse(ones(4, 4)))

The unexported function inject!(A, B) zeros A, then copies the contents B 
into A.   For sparse matrices, the nonzero positions of B must be a subset 
of those in A.  What I expect to happen in this case is that the code will 
enter the block in lines 52 - 54 
of https://github.com/dmbates/MixedModels.jl/blob/master/src/inject.jl.  In 
fact, if you uncomment line 51 in that file the output from the @show macro 
shows that indeed 

kk > length(dnzrv)

the second time through the "for k in snzr" loop.  But when I run that 
example, the error thrown is a BoundsError at line 55.   What I don't 
understand is how it gets to line 55 the second time through the loop.

I have been looking at this for a long time trying to see if I am doing 
something stupid but I can't.  Does the BoundsError get thrown for others? 
 My versioninfo is

julia> versioninfo()
Julia Version 0.4.2
Commit bb73f34 (2015-12-06 21:47 UTC)
Platform Info:
  System: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
  WORD_SIZE: 64
  BLAS: libopenblas (NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY Prescott)
  LAPACK: liblapack.so.3
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

I haven't upgraded to 0.4.3 because the Ubuntu package is not yet available 
but I can test on 0.4.3 if that would help.

[julia-users] Re: GSoC Matrix and Fast Bignums

[Jeffrey Sarnoff]

Hello Juan,

I have some experience with Julia's BigNums and have experimented with 
faster fixed precision (128 bits) floating point type implementations (and 
don't know about Julia's Matrix work, and am not involved with GSoC).  For 
a small first place, I suggest something that will increase your depth with 
BigFloats and as a nice addition may provide some generally useful 
intermediation functions.  Whatever else you may do in software that 
focuses on floating point precision and accuracy extension, you are likely 
to lean on BigFloats in development and testing of floating point math -- 
even when it does not use BigFloats directly.  You might experiment with 
BigFloat interconversion with Float64 and Float32 values (back and forth 
and forth and back) to notice situations where things seem good at first 
glance, until some values that ought be the same are not.
There are different ways to go to/from BigFloats and Float64s, it is not 
exciting -- and can be exasperating.  Let me know if that is the direction 
you want to take:  it involves no matrix work, and offers no great feats of 
algorithmic speed.  You might get a broader sense of Julia by starting with 
small but less narrowly focused task.




On Saturday, March 12, 2016 at 12:33:41 PM UTC-5, Juan Lopez wrote:

Hello everyone,

I am looking into GSoC this year and I really like your Matrix functions 
and Fast Bignums projects.

My background is in computer science, I'm in my 3rd year in Universitat 
Politècnica de Catalunya  and I've worked with MATLAB and Octave before. I 
have also taken several courses in linear algebra and have experience in 
competitive programming.

My competence level in C and C++ is good, average haskell and getting my 
hands on Julia.

I think your org is awesome because it brings high-performance and ease of 
use for technical computing and offers foreign function interface to look 
for advantages in languages like python, c, fortran, etc.

Is there anyone interested in mentoring any of these projects? Also, could 
someone point me to some issues/small projects to get started?

I look forward to your replies,
Juan López

Re: [julia-users] Error with PyPlot

[Tom Breloff]

I think you have an outdated package. Color.jl is deprecated in favor of
Colors.jl. Try Pkg.update()

On Friday, March 11, 2016, Xavier Gandibleux <
xavier.gandibl...@univ-nantes.fr> wrote:

> Dear all,
>
> I encounter a problem only under ubuntu (it is fine under OSX) with PyPlot.
> I extracted some commands hereafter to reproduce the error.
>
> nb:
> 1) the Python Matplotlib library is installed and works fine (tested).
> 2) Pkg.add("PyPlot") is imported and ready (as reported hereafter).
>
> When I invoque "using PyPlot", the error occurs (and after real numbers
> are not anymore recognized).
> An example follows below.
>
> Thanks in advance for any suggestions.
> Xavier
>
>
> xavierg@xavierg-HP-ZBook-17-G2:~/Bureau/Solveurs/Julia$ julia
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "help()" to list help topics
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.2.1 (2014-02-11 06:30 UTC)
>  _/ |\__'_|_|_|\__'_|  |
> |__/   |  x86_64-linux-gnu
>
> julia> W = 1.15
> 1.15
>
> julia> Pkg.add("PyPlot")
> INFO: Nothing to be done.
>
> julia> W = 1.15
> 1.15
>
> julia> using PyPlot
> Loading help data...
> ERROR: syntax: invalid numeric constant 1.0
>  in include at boot.jl:238
> at /home/xavierg/.julia/v0.2/Color/src/colorspaces.jl:14
> at /home/xavierg/.julia/v0.2/Color/src/Color.jl:25
> at /home/xavierg/.julia/v0.2/PyPlot/src/colormaps.jl:4
> at /home/xavierg/.julia/v0.2/PyPlot/src/PyPlot.jl:337
>
> julia> W = 1.15
> ERROR: syntax: invalid numeric constant 1.15
>
> julia>
>

Re: [julia-users] Re: Status of Plots.jl?

[jonathan . bieler]

GR seems pretty good, can it uses Gtk to display plots ?

[julia-users] GSoC Matrix and Fast Bignums

[Juan Lopez]

Hello everyone,

I am looking into GSoC this year and I really like your Matrix functions 
and Fast Bignums projects.

My background is in computer science, I'm in my 3rd year in Universitat 
Politècnica de Catalunya  and I've worked with MATLAB and Octave before. I 
have also taken several courses in linear algebra and have experience in 
competitive programming.

My competence level in C and C++ is good, average haskell and getting my 
hands on Julia.

I think your org is awesome because it brings high-performance and ease of 
use for technical computing and offers foreign function interface to look 
for advantages in languages like python, c, fortran, etc.

Is there anyone interested in mentoring any of these projects? Also, could 
someone point me to some issues/small projects to get started?

I look forward to your replies,
Juan López

[julia-users] Error with PyPlot

[Xavier Gandibleux]

Dear all,

I encounter a problem only under ubuntu (it is fine under OSX) with PyPlot.
I extracted some commands hereafter to reproduce the error.

nb:
1) the Python Matplotlib library is installed and works fine (tested).
2) Pkg.add("PyPlot") is imported and ready (as reported hereafter).

When I invoque "using PyPlot", the error occurs (and after real numbers are 
not anymore recognized).
An example follows below.

Thanks in advance for any suggestions.
Xavier


xavierg@xavierg-HP-ZBook-17-G2:~/Bureau/Solveurs/Julia$ julia
   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" to list help topics
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.2.1 (2014-02-11 06:30 UTC)
 _/ |\__'_|_|_|\__'_|  |
|__/   |  x86_64-linux-gnu

julia> W = 1.15
1.15

julia> Pkg.add("PyPlot")
INFO: Nothing to be done.

julia> W = 1.15
1.15

julia> using PyPlot
Loading help data...
ERROR: syntax: invalid numeric constant 1.0
 in include at boot.jl:238
at /home/xavierg/.julia/v0.2/Color/src/colorspaces.jl:14
at /home/xavierg/.julia/v0.2/Color/src/Color.jl:25
at /home/xavierg/.julia/v0.2/PyPlot/src/colormaps.jl:4
at /home/xavierg/.julia/v0.2/PyPlot/src/PyPlot.jl:337

julia> W = 1.15
ERROR: syntax: invalid numeric constant 1.15

julia>

Re: [julia-users] Re: Mmap allocation question

[Tim Loderhose]

Cool, Ill try that out later! I was wondering about that, but obviously I 
wasn't able to default dims::Array{Int64,1} = 0.
How do I make sure it returns a definite type? I know that it should always 
be an Array{UInt64,1}. I added the code of mdhcounters to the gist.
Thanks for the input!

On Saturday, 12 March 2016 15:15:51 UTC+1, Dan wrote:
>
> Yep, `peCounters`, `paCounters` and `dims` are not type-stable. They are 
> one type by their default values and then assigned another. Perhaps rename 
> the default parameters, and copy them to `peCounters`, `paCounters` and 
> `dims` only if they are set to something other than `0`.
>
> Also, `mdhcounters` might not return a definite type (need to check that 
> function).
> Fixing these should make the loop efficient.
>
> On Saturday, March 12, 2016 at 4:05:39 PM UTC+2, Tim Loderhose wrote:
>>
>> Here's the actual code: 
>> https://gist.github.com/timlod/0f607e311d0464fd6c63
>>
>> I am running the code from the REPL, may that be a problem? (As I read in 
>> the REPL everything is global). In the file nothing is global.
>> Also, the counters are UInt16s, but that shouldnt matter I guess.
>>
>> Thanks for the help so far!
>>
>> On Saturday, 12 March 2016 14:22:38 UTC+1, Dan wrote:
>>>
>>> It's better to have code which actually runs in the post. In any case, 
>>> the allocations at the `for` lines is suspicious - the for should basically 
>>> only allocate a counter. Are there any global variables? Is `counter1` or 
>>> `counter2` or `dims` global? Globals are always a good source of confusion 
>>> to the type-inference engine.
>>>
>>> On Saturday, March 12, 2016 at 2:28:51 PM UTC+2, Tim Loderhose wrote:

 The code is in a function. I changed the names a bit to make it more 
 understandable. The actual function is longer and has different variable 
 names.

 On Saturday, 12 March 2016 13:01:28 UTC+1, tshort wrote:
>
> Is that code in a function? (It should be.) Also, one of your variable 
> names changed to `counter1s`. Suspect a type instability.
> On Mar 12, 2016 4:12 AM, "Tim Loderhose"  wrote:
>
>> I tried around with that a bit, but then it gets much worse: From ~1s 
>> to ~6s, allocation as shown:
>>
>> 153710487 mat = Array{Complex64}(dims...)
>>   4722450   file = Mmap.mmap(filename, Array{Complex64,2}, 
>> (dims[2],length(counter1)))
>>  9568  for i = 1:dims[2]
>>  4000 for j = 1:length(counter1)
>> 1690462534  mat[counter1s[j],i,counter2[j]] = file[i,j]
>> - end
>>
>> I swapped the for loops around here, but that didn't matter. I can 
>> gain a little bit by indexing i into the first dimension of mat, but it 
>> still lags far behind.
>> Any other ideas?
>>
>> On Saturday, 12 March 2016 03:15:33 UTC+1, Greg Plowman wrote:
>>>
>>> I think array slices (on right hand side of assignment) create new 
>>> arrays, hence the allocation.
>>> Try writing an explicit loop instead, something like:
>>>
>>> for j = 1:length(counter1)
>>>for i = 1:size(file,1)
>>>mat[counter1[j],i,counter2[j]] = file[i,j]
>>>end
>>> end
>>>
>>>
>>> On Saturday, March 12, 2016 at 12:25:00 PM UTC+11, Tim Loderhose 
>>> wrote:
>>>
 Hi,

 I have a question regarding some allocation in my code I would like 
 to get rid of.
 I am memory mapping a file (which could be very large) which is 
 part of a complex 3D matrix, and then put its contents into the 
 preallocated matrix along the second dimension. I need the counters 
 because 
 the contents of file are only a subset of the full matrix.

 Here's a profiled snippet, where the file which is loaded has 
 120619520 bytes.

 153705063 mat = Array{Complex64}(dims...)
  4721282file = Mmap.mmap(filename, Array{Complex64,2}, 
 (dims[2],length(counter1)))
 16   for i = 1:length(counter1)
 148179531   mat[counter1[i],:,counter2[i]] = file[:,i]
 -  end

 Why does the code allocate so much memory inside the for-loop (even 
 more bytes than the contents of file)?
 It seems like this is a trivial matter, right now I just can't get 
 my head around it, any help is appreciated :)

 Thanks,
 Tim

>>>

Re: [julia-users] Re: Mmap allocation question

[Dan]

Yep, `peCounters`, `paCounters` and `dims` are not type-stable. They are 
one type by their default values and then assigned another. Perhaps rename 
the default parameters, and copy them to `peCounters`, `paCounters` and 
`dims` only if they are set to something other than `0`.

Also, `mdhcounters` might not return a definite type (need to check that 
function).
Fixing these should make the loop efficient.

On Saturday, March 12, 2016 at 4:05:39 PM UTC+2, Tim Loderhose wrote:
>
> Here's the actual code: 
> https://gist.github.com/timlod/0f607e311d0464fd6c63
>
> I am running the code from the REPL, may that be a problem? (As I read in 
> the REPL everything is global). In the file nothing is global.
> Also, the counters are UInt16s, but that shouldnt matter I guess.
>
> Thanks for the help so far!
>
> On Saturday, 12 March 2016 14:22:38 UTC+1, Dan wrote:
>>
>> It's better to have code which actually runs in the post. In any case, 
>> the allocations at the `for` lines is suspicious - the for should basically 
>> only allocate a counter. Are there any global variables? Is `counter1` or 
>> `counter2` or `dims` global? Globals are always a good source of confusion 
>> to the type-inference engine.
>>
>> On Saturday, March 12, 2016 at 2:28:51 PM UTC+2, Tim Loderhose wrote:
>>>
>>> The code is in a function. I changed the names a bit to make it more 
>>> understandable. The actual function is longer and has different variable 
>>> names.
>>>
>>> On Saturday, 12 March 2016 13:01:28 UTC+1, tshort wrote:

 Is that code in a function? (It should be.) Also, one of your variable 
 names changed to `counter1s`. Suspect a type instability.
 On Mar 12, 2016 4:12 AM, "Tim Loderhose"  wrote:

> I tried around with that a bit, but then it gets much worse: From ~1s 
> to ~6s, allocation as shown:
>
> 153710487 mat = Array{Complex64}(dims...)
>   4722450   file = Mmap.mmap(filename, Array{Complex64,2}, 
> (dims[2],length(counter1)))
>  9568  for i = 1:dims[2]
>  4000 for j = 1:length(counter1)
> 1690462534  mat[counter1s[j],i,counter2[j]] = file[i,j]
> - end
>
> I swapped the for loops around here, but that didn't matter. I can 
> gain a little bit by indexing i into the first dimension of mat, but it 
> still lags far behind.
> Any other ideas?
>
> On Saturday, 12 March 2016 03:15:33 UTC+1, Greg Plowman wrote:
>>
>> I think array slices (on right hand side of assignment) create new 
>> arrays, hence the allocation.
>> Try writing an explicit loop instead, something like:
>>
>> for j = 1:length(counter1)
>>for i = 1:size(file,1)
>>mat[counter1[j],i,counter2[j]] = file[i,j]
>>end
>> end
>>
>>
>> On Saturday, March 12, 2016 at 12:25:00 PM UTC+11, Tim Loderhose 
>> wrote:
>>
>>> Hi,
>>>
>>> I have a question regarding some allocation in my code I would like 
>>> to get rid of.
>>> I am memory mapping a file (which could be very large) which is part 
>>> of a complex 3D matrix, and then put its contents into the preallocated 
>>> matrix along the second dimension. I need the counters because the 
>>> contents 
>>> of file are only a subset of the full matrix.
>>>
>>> Here's a profiled snippet, where the file which is loaded has 
>>> 120619520 bytes.
>>>
>>> 153705063 mat = Array{Complex64}(dims...)
>>>  4721282file = Mmap.mmap(filename, Array{Complex64,2}, 
>>> (dims[2],length(counter1)))
>>> 16   for i = 1:length(counter1)
>>> 148179531   mat[counter1[i],:,counter2[i]] = file[:,i]
>>> -  end
>>>
>>> Why does the code allocate so much memory inside the for-loop (even 
>>> more bytes than the contents of file)?
>>> It seems like this is a trivial matter, right now I just can't get 
>>> my head around it, any help is appreciated :)
>>>
>>> Thanks,
>>> Tim
>>>
>>

[julia-users] Re: what name would you give to the functional 'complement' of trunc()?

[Jeffrey Sarnoff]

thank you

On Saturday, March 12, 2016 at 8:15:38 AM UTC-5, Tomas Lycken wrote:
>
> I think stretch was a pretty good suggestion, actually.
>
> trunc as in “truncate” makes sense for taking 3.14 -> 3 and -2.718 -> -2; 
> you quite literally truncate the decimal representation of the number by 
> chopping off the decimals. I could imagine the opposite, 3.14 -> 4 and 
> -2.718 -> -3, as either “stretching” the numbers to reach all the way to 
> the next integer, or “filling” up the remaining distance. Since fill is 
> already loaded with quite different meaning, I’d go with stretch.
>
> // T
>
> On Saturday, March 12, 2016 at 2:04:23 PM UTC+1, Dan wrote:
>
> trunc_to_inf and add an alias trunc_to_zero for regular trunc ??
>>
>> On Saturday, March 12, 2016 at 1:49:41 PM UTC+2, Jeffrey Sarnoff wrote:
>>>
>>> x = trunc(fp) yields fp rounded towards zero to the closest integer 
>>> valued float.
>>> What name would you give to the complementary function, rounding away 
>>> from zero to the closest integer valued float?
>>>
>>> stretch(fp)  = signbit(fp) ? floor(fp) : ceil(fp)   # abs(trunc(fp) - 
>>> stretch(fp)) is 0.0 when fp is integer valued and is 1.0 otherwise
>>>
>>>
>>>
>>> ​
>

Re: [julia-users] Re: Mmap allocation question

[Dan]

It's better to have code which actually runs in the post. In any case, the 
allocations at the `for` lines is suspicious - the for should basically 
only allocate a counter. Are there any global variables? Is `counter1` or 
`counter2` or `dims` global? Globals are always a good source of confusion 
to the type-inference engine.

On Saturday, March 12, 2016 at 2:28:51 PM UTC+2, Tim Loderhose wrote:
>
> The code is in a function. I changed the names a bit to make it more 
> understandable. The actual function is longer and has different variable 
> names.
>
> On Saturday, 12 March 2016 13:01:28 UTC+1, tshort wrote:
>>
>> Is that code in a function? (It should be.) Also, one of your variable 
>> names changed to `counter1s`. Suspect a type instability.
>> On Mar 12, 2016 4:12 AM, "Tim Loderhose"  wrote:
>>
>>> I tried around with that a bit, but then it gets much worse: From ~1s to 
>>> ~6s, allocation as shown:
>>>
>>> 153710487 mat = Array{Complex64}(dims...)
>>>   4722450   file = Mmap.mmap(filename, Array{Complex64,2}, 
>>> (dims[2],length(counter1)))
>>>  9568  for i = 1:dims[2]
>>>  4000 for j = 1:length(counter1)
>>> 1690462534  mat[counter1s[j],i,counter2[j]] = file[i,j]
>>> - end
>>>
>>> I swapped the for loops around here, but that didn't matter. I can gain 
>>> a little bit by indexing i into the first dimension of mat, but it still 
>>> lags far behind.
>>> Any other ideas?
>>>
>>> On Saturday, 12 March 2016 03:15:33 UTC+1, Greg Plowman wrote:

 I think array slices (on right hand side of assignment) create new 
 arrays, hence the allocation.
 Try writing an explicit loop instead, something like:

 for j = 1:length(counter1)
for i = 1:size(file,1)
mat[counter1[j],i,counter2[j]] = file[i,j]
end
 end


 On Saturday, March 12, 2016 at 12:25:00 PM UTC+11, Tim Loderhose wrote:

> Hi,
>
> I have a question regarding some allocation in my code I would like to 
> get rid of.
> I am memory mapping a file (which could be very large) which is part 
> of a complex 3D matrix, and then put its contents into the preallocated 
> matrix along the second dimension. I need the counters because the 
> contents 
> of file are only a subset of the full matrix.
>
> Here's a profiled snippet, where the file which is loaded has 
> 120619520 bytes.
>
> 153705063 mat = Array{Complex64}(dims...)
>  4721282file = Mmap.mmap(filename, Array{Complex64,2}, 
> (dims[2],length(counter1)))
> 16   for i = 1:length(counter1)
> 148179531   mat[counter1[i],:,counter2[i]] = file[:,i]
> -  end
>
> Why does the code allocate so much memory inside the for-loop (even 
> more bytes than the contents of file)?
> It seems like this is a trivial matter, right now I just can't get my 
> head around it, any help is appreciated :)
>
> Thanks,
> Tim
>

[julia-users] Re: what name would you give to the functional 'complement' of trunc()?

[Tomas Lycken]

I think stretch was a pretty good suggestion, actually.

trunc as in “truncate” makes sense for taking 3.14 -> 3 and -2.718 -> -2; 
you quite literally truncate the decimal representation of the number by 
chopping off the decimals. I could imagine the opposite, 3.14 -> 4 and 
-2.718 -> -3, as either “stretching” the numbers to reach all the way to 
the next integer, or “filling” up the remaining distance. Since fill is 
already loaded with quite different meaning, I’d go with stretch.

// T

On Saturday, March 12, 2016 at 2:04:23 PM UTC+1, Dan wrote:

trunc_to_inf and add an alias trunc_to_zero for regular trunc ??
>
> On Saturday, March 12, 2016 at 1:49:41 PM UTC+2, Jeffrey Sarnoff wrote:
>>
>> x = trunc(fp) yields fp rounded towards zero to the closest integer 
>> valued float.
>> What name would you give to the complementary function, rounding away 
>> from zero to the closest integer valued float?
>>
>> stretch(fp)  = signbit(fp) ? floor(fp) : ceil(fp)   # abs(trunc(fp) - 
>> stretch(fp)) is 0.0 when fp is integer valued and is 1.0 otherwise
>>
>>
>>
>> ​

[julia-users] Re: what name would you give to the functional 'complement' of trunc()?

[Dan]

trunc_to_inf and add an alias trunc_to_zero for regular trunc ??

On Saturday, March 12, 2016 at 1:49:41 PM UTC+2, Jeffrey Sarnoff wrote:
>
> x = trunc(fp) yields fp rounded towards zero to the closest integer valued 
> float.
> What name would you give to the complementary function, rounding away from 
> zero to the closest integer valued float?
>
> stretch(fp)  = signbit(fp) ? floor(fp) : ceil(fp)   # abs(trunc(fp) - 
> stretch(fp)) is 0.0 when fp is integer valued and is 1.0 otherwise
>
>
>
>

Re: [julia-users] Re: Mmap allocation question

[Tom Short]

Is that code in a function? (It should be.) Also, one of your variable
names changed to `counter1s`. Suspect a type instability.
On Mar 12, 2016 4:12 AM, "Tim Loderhose"  wrote:

> I tried around with that a bit, but then it gets much worse: From ~1s to
> ~6s, allocation as shown:
>
> 153710487 mat = Array{Complex64}(dims...)
>   4722450   file = Mmap.mmap(filename, Array{Complex64,2},
> (dims[2],length(counter1)))
>  9568  for i = 1:dims[2]
>  4000 for j = 1:length(counter1)
> 1690462534  mat[counter1s[j],i,counter2[j]] = file[i,j]
> - end
>
> I swapped the for loops around here, but that didn't matter. I can gain a
> little bit by indexing i into the first dimension of mat, but it still lags
> far behind.
> Any other ideas?
>
> On Saturday, 12 March 2016 03:15:33 UTC+1, Greg Plowman wrote:
>>
>> I think array slices (on right hand side of assignment) create new
>> arrays, hence the allocation.
>> Try writing an explicit loop instead, something like:
>>
>> for j = 1:length(counter1)
>>for i = 1:size(file,1)
>>mat[counter1[j],i,counter2[j]] = file[i,j]
>>end
>> end
>>
>>
>> On Saturday, March 12, 2016 at 12:25:00 PM UTC+11, Tim Loderhose wrote:
>>
>>> Hi,
>>>
>>> I have a question regarding some allocation in my code I would like to
>>> get rid of.
>>> I am memory mapping a file (which could be very large) which is part of
>>> a complex 3D matrix, and then put its contents into the preallocated matrix
>>> along the second dimension. I need the counters because the contents of
>>> file are only a subset of the full matrix.
>>>
>>> Here's a profiled snippet, where the file which is loaded has 120619520
>>> bytes.
>>>
>>> 153705063 mat = Array{Complex64}(dims...)
>>>  4721282file = Mmap.mmap(filename, Array{Complex64,2},
>>> (dims[2],length(counter1)))
>>> 16   for i = 1:length(counter1)
>>> 148179531   mat[counter1[i],:,counter2[i]] = file[:,i]
>>> -  end
>>>
>>> Why does the code allocate so much memory inside the for-loop (even more
>>> bytes than the contents of file)?
>>> It seems like this is a trivial matter, right now I just can't get my
>>> head around it, any help is appreciated :)
>>>
>>> Thanks,
>>> Tim
>>>
>>

[julia-users] what name would you give to the functional 'complement' of trunc()?

[Jeffrey Sarnoff]

x = trunc(fp) yields fp rounded towards zero to the closest integer valued 
float.
What name would you give to the complementary function, rounding away from 
zero to the closest integer valued float?

stretch(fp)  = signbit(fp) ? floor(fp) : ceil(fp)   # abs(trunc(fp) - 
stretch(fp)) is 0.0 when fp is integer valued and is 1.0 otherwise

Re: [julia-users] Status of Graphs.jl ?

[Mridul Seth]

Hi James,

I started a conversation regarding the same on the gitter 
channel https://gitter.im/JuliaGraphs/LightGraphs.jl with Seth Bromberger

Thanks :)

Mridul

On Saturday, 12 March 2016 06:51:24 UTC+5:30, James Fairbanks wrote:
>
> Hi Mridul,
>
> JuliaGraphs is a Github organization for people who are interested in 
> writing graph code.
> We primarily work on LightGraphs, which is a simple adjacency list 
> representation for graphs along with a lot of functions for processing 
> graphs.
> LightGraphs includes I/O for many common storage formats.
>
> Just this week JuliaGraphs started on graph visualization in 
> https://github.com/JuliaGraphs/GraphVisualize.jl. Although GraphLayout.jl 
> and GraphPlots.jl are more mature.
> If you want to work on graphs, check out the Github issues! :)
>
> Best,
> James Fairbanks
>
> On Friday, March 11, 2016 at 3:23:14 PM UTC-5, Tim Holy wrote:
>>
>> I think LightGraphs.jl is more active. 
>>
>> Best, 
>> --Tim 
>>
>> On Thursday, March 10, 2016 10:45:35 PM Mridul Seth wrote: 
>> > https://github.com/JuliaLang/Graphs.jl looks like a great project but 
>> there 
>> > haven't been a lot of activity (last commit Nov 1, 2015). Is there any 
>> > general interest regarding working on Graphs.jl during GSoC period? 
>> > And what the difference between https://github.com/JuliaGraphs and 
>> Graphs.jl 
>> > 
>> > Thanks, 
>> > Mridul Seth 
>>
>>

[julia-users] Re: Mmap allocation question

[Tim Loderhose]

I tried around with that a bit, but then it gets much worse: From ~1s to 
~6s, allocation as shown:

153710487 mat = Array{Complex64}(dims...)
  4722450   file = Mmap.mmap(filename, Array{Complex64,2}, 
(dims[2],length(counter1)))
 9568  for i = 1:dims[2]
 4000 for j = 1:length(counter1)
1690462534  mat[counter1s[j],i,counter2[j]] = file[i,j]
- end

I swapped the for loops around here, but that didn't matter. I can gain a 
little bit by indexing i into the first dimension of mat, but it still lags 
far behind.
Any other ideas?

On Saturday, 12 March 2016 03:15:33 UTC+1, Greg Plowman wrote:
>
> I think array slices (on right hand side of assignment) create new arrays, 
> hence the allocation.
> Try writing an explicit loop instead, something like:
>
> for j = 1:length(counter1)
>for i = 1:size(file,1)
>mat[counter1[j],i,counter2[j]] = file[i,j]
>end
> end
>
>
> On Saturday, March 12, 2016 at 12:25:00 PM UTC+11, Tim Loderhose wrote:
>
>> Hi,
>>
>> I have a question regarding some allocation in my code I would like to 
>> get rid of.
>> I am memory mapping a file (which could be very large) which is part of a 
>> complex 3D matrix, and then put its contents into the preallocated matrix 
>> along the second dimension. I need the counters because the contents of 
>> file are only a subset of the full matrix.
>>
>> Here's a profiled snippet, where the file which is loaded has 120619520 
>> bytes.
>>
>> 153705063 mat = Array{Complex64}(dims...)
>>  4721282file = Mmap.mmap(filename, Array{Complex64,2}, 
>> (dims[2],length(counter1)))
>> 16   for i = 1:length(counter1)
>> 148179531   mat[counter1[i],:,counter2[i]] = file[:,i]
>> -  end
>>
>> Why does the code allocate so much memory inside the for-loop (even more 
>> bytes than the contents of file)?
>> It seems like this is a trivial matter, right now I just can't get my 
>> head around it, any help is appreciated :)
>>
>> Thanks,
>> Tim
>>
>