[julia-users] Arrays{T,N} of size = (n, 1, 1, 1, ...)

[SrAceves]

What's the use of Arrays{T,N} of size = (n, 1, 1, 1, ...)? In such cases, 
would it make sense to default to a simple Array{T,1}?

For example, rand(5, 1, 1, 1) would turn into rand(5)  (à la vec(rand(5, 1, 
1, 1))

[julia-users] Error when embedding julia in C program under Windows 7

[Tony Kelman]

A shared library that testc.exe can't be found. Figure out which one it is and 
put it somewhere that the executable can find it.

Re: [julia-users] Differential Equations Package

[Eric Forgy]

Hi Chris (et al)

It sounds like you've got a lot on your plate, but we apparently have some 
common interests.

When the smoke settles for you and you're looking for some night time 
reading (i.e. cure for insomnia), you might have a look at some of my old 
papers:

   - 
   - Noncommutative Geometry and Stochastic Calculus: Applications in 
   Mathematical Finance 
   

I'm pretty sure I am the first person to apply NCG to finance :)

I followed that one up a couple years later with a more concrete 
application for practitioners:

   - Financial Modelling Using Discrete Stochastic Calculus 
   
   
Discrete stochastic calculus provides a kind of meta algorithm. It is an 
> algorithm for generating algorithms.
>

If that doesn't cure your insomnia, this one surely will:

   -  Discrete Differential Geometry on Causal Graphs 
   
   
The above is a follow-up to work started in my dissertation at UIUC:

   - Differential Geometry in Computational Electromagnetics 
   
   
It was still a work in progress, but its not easy creating an entirely new 
framework for scientific computation, so I guess they thought it was enough 
:)

Anyway, I mention this because discrete stochastic calculus (DSC) would 
have a completely natural implementation in Julia using concepts similar to 
automatic differentiation to give you things like Ito formula for free. If 
I could clone myself, I would develop that, but I'm a "seniorpreneur", i.e. 
industry veteran (a.k.a. old man) working on my third FinTech startup, so 
it is on the back burner for now :)

My friend, John Baez, changed his academic passion from quantum gravity to 
environmental science a few years ago, which motivated me to start applying 
DSC to problems in fluid dynamics with some very cool result for Burgers 
 and Navier-Stokes equations (all unpublished). You can find a bunch of 
info about that here 

. 

Cheers

PS: Just before hitting "Send", I notice several of the links in my last 
reference are broken, which tends to happen after more than 5 years :), so 
here is one that should be good for Burgers stuff:

   - Discrete Burgers equation revisited 
   
   
The important quote:

> I did not do much more with the discrete Burgers equation for reasons 
> similar to John's. As far as I am concerned the problem is solved. I wrote 
> down and implemented in code an algorithm having the magical property that 
> the accuracy gets BETTER the longer you simulate. You cannot ask for more 
> than that.


Finally:

   -  Towards Navier-Stokes from noncommutative geometry 
   
   
Fun stuff! I miss doing research like that :)

Re: [julia-users] Initializing a new array generates unexpected results

[Matt Bauman]

Just as a small addendum to Erik's excellent answer:

One way to think about zero-dimensional arrays is by analogy with geometry. 
 Matrices are like planes, vectors are like lines, and zero-dimensional 
arrays are like points.  Points don't have any dimensions or lengths, but 
they still describe a location.

On Tuesday, June 7, 2016 at 10:01:05 PM UTC-5, Erik Schnetter wrote:
>
> The syntax for constructing arrays is `Array{Type}(size1, size2, ...)`. 
> You are not passing any values for `size`, thus you are constructing an 
> array that has no indices (zero dimensions). The way to access it is `x[]`, 
> i.e. an indexing expression without any indices. All zero-dimensional 
> arrays have one element -- there is no way for it to have zero elements; a 
> zero-dimensional array is very similar to a scalar value.
>
> Zero-dimensional arrays are confusing if you don't expect them; I assume 
> many people expect to obtain a one-dimensional array with zero elements 
> instead. (You can write `Vector{Int64}()` for this, or `Array{Int64}(0)`, 
> or Array{Int64,1}()`, or `Int64[]`.)
>
> To add to the confusion, Julia supports "linear indexing", which allows 
> you to index arrays with fewer or more (!) indices than declared. If you 
> use fewer indices, then the last index can be larger than its declared 
> bound; if there are more, then the additional indices all need to have the 
> value 1:
> ```Julia
> x = Vector{Int}(10)   # one dimension, ten elements
> x[1,1]   # this accesses the first element
> x[1,1,1,1,1]   # so does this
> ```
> This allows you to write `x[1]` in your case, although `x` actually 
> doesn't have any indices.
>
> Supporting zero-dimensional arrays is an important corner case.
>
> Linear indexing is also important, but might use a different syntax in the 
> future to avoid confusion.
>
> -erik
>
>
>
> On Tue, Jun 7, 2016 at 9:47 PM, David Parks  > wrote:
>
>> Hi Mauro, thanks for the response!
>> I get the logic behind an uninitialized array, but shouldn't such an 
>> array not return an iterable with 1 element of garbage? Why would it be 
>> initialized to having 1 random element and not 0?
>>
>> I would expect an empty constructor to do something reasonable. Perhaps 
>> it would be logical for these two statements to be equivalent (see bold 
>> lines below). I don't see the value of having a null constructor that 
>> generates an array that's iterable with exactly 1 element of garbage 
>> contents. Seems like a recipe for bugs. My bugs specifically, which is 
>> exactly what brought me to this topic. :)
>>
>> *julia> x = Array{Int64}()*
>> 0-dimensional Array{Int64,0}:
>> 2198389808
>>
>> julia> x[1]
>> 2198389808
>>
>> julia> x[2]
>> ERROR: BoundsError: attempt to access 0-dimensional Array{Int64,0}:
>> 2198389808
>>   at index [2]
>>  in getindex at array.jl:282
>>
>> *julia> x=Array{Int64}(0)*
>> 0-element Array{Int64,1}
>>
>> julia> x[1]
>> ERROR: BoundsError: attempt to access 0-element Array{Int64,1}
>>   at index [1]
>>  in getindex at array.jl:282
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> -- 
> Erik Schnetter > 
> http://www.perimeterinstitute.ca/personal/eschnetter/
>

Re: [julia-users] Initializing a new array generates unexpected results

[Erik Schnetter]

PS: `Array{Int64}()` is an array with 0 dimensions, "each" of which has
size 0 (so to say), leading to an overall length of 0^0 = 1 elements...

-erik

On Tue, Jun 7, 2016 at 11:01 PM, Erik Schnetter  wrote:

> The syntax for constructing arrays is `Array{Type}(size1, size2, ...)`.
> You are not passing any values for `size`, thus you are constructing an
> array that has no indices (zero dimensions). The way to access it is `x[]`,
> i.e. an indexing expression without any indices. All zero-dimensional
> arrays have one element -- there is no way for it to have zero elements; a
> zero-dimensional array is very similar to a scalar value.
>
> Zero-dimensional arrays are confusing if you don't expect them; I assume
> many people expect to obtain a one-dimensional array with zero elements
> instead. (You can write `Vector{Int64}()` for this, or `Array{Int64}(0)`,
> or Array{Int64,1}()`, or `Int64[]`.)
>
> To add to the confusion, Julia supports "linear indexing", which allows
> you to index arrays with fewer or more (!) indices than declared. If you
> use fewer indices, then the last index can be larger than its declared
> bound; if there are more, then the additional indices all need to have the
> value 1:
> ```Julia
> x = Vector{Int}(10)   # one dimension, ten elements
> x[1,1]   # this accesses the first element
> x[1,1,1,1,1]   # so does this
> ```
> This allows you to write `x[1]` in your case, although `x` actually
> doesn't have any indices.
>
> Supporting zero-dimensional arrays is an important corner case.
>
> Linear indexing is also important, but might use a different syntax in the
> future to avoid confusion.
>
> -erik
>
>
>
> On Tue, Jun 7, 2016 at 9:47 PM, David Parks 
> wrote:
>
>> Hi Mauro, thanks for the response!
>> I get the logic behind an uninitialized array, but shouldn't such an
>> array not return an iterable with 1 element of garbage? Why would it be
>> initialized to having 1 random element and not 0?
>>
>> I would expect an empty constructor to do something reasonable. Perhaps
>> it would be logical for these two statements to be equivalent (see bold
>> lines below). I don't see the value of having a null constructor that
>> generates an array that's iterable with exactly 1 element of garbage
>> contents. Seems like a recipe for bugs. My bugs specifically, which is
>> exactly what brought me to this topic. :)
>>
>> *julia> x = Array{Int64}()*
>> 0-dimensional Array{Int64,0}:
>> 2198389808
>>
>> julia> x[1]
>> 2198389808
>>
>> julia> x[2]
>> ERROR: BoundsError: attempt to access 0-dimensional Array{Int64,0}:
>> 2198389808
>>   at index [2]
>>  in getindex at array.jl:282
>>
>> *julia> x=Array{Int64}(0)*
>> 0-element Array{Int64,1}
>>
>> julia> x[1]
>> ERROR: BoundsError: attempt to access 0-element Array{Int64,1}
>>   at index [1]
>>  in getindex at array.jl:282
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Erik Schnetter 
> http://www.perimeterinstitute.ca/personal/eschnetter/
>



-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] Initializing a new array generates unexpected results

[Erik Schnetter]

The syntax for constructing arrays is `Array{Type}(size1, size2, ...)`. You
are not passing any values for `size`, thus you are constructing an array
that has no indices (zero dimensions). The way to access it is `x[]`, i.e.
an indexing expression without any indices. All zero-dimensional arrays
have one element -- there is no way for it to have zero elements; a
zero-dimensional array is very similar to a scalar value.

Zero-dimensional arrays are confusing if you don't expect them; I assume
many people expect to obtain a one-dimensional array with zero elements
instead. (You can write `Vector{Int64}()` for this, or `Array{Int64}(0)`,
or Array{Int64,1}()`, or `Int64[]`.)

To add to the confusion, Julia supports "linear indexing", which allows you
to index arrays with fewer or more (!) indices than declared. If you use
fewer indices, then the last index can be larger than its declared bound;
if there are more, then the additional indices all need to have the value 1:
```Julia
x = Vector{Int}(10)   # one dimension, ten elements
x[1,1]   # this accesses the first element
x[1,1,1,1,1]   # so does this
```
This allows you to write `x[1]` in your case, although `x` actually doesn't
have any indices.

Supporting zero-dimensional arrays is an important corner case.

Linear indexing is also important, but might use a different syntax in the
future to avoid confusion.

-erik



On Tue, Jun 7, 2016 at 9:47 PM, David Parks  wrote:

> Hi Mauro, thanks for the response!
> I get the logic behind an uninitialized array, but shouldn't such an array
> not return an iterable with 1 element of garbage? Why would it be
> initialized to having 1 random element and not 0?
>
> I would expect an empty constructor to do something reasonable. Perhaps it
> would be logical for these two statements to be equivalent (see bold lines
> below). I don't see the value of having a null constructor that generates
> an array that's iterable with exactly 1 element of garbage contents. Seems
> like a recipe for bugs. My bugs specifically, which is exactly what brought
> me to this topic. :)
>
> *julia> x = Array{Int64}()*
> 0-dimensional Array{Int64,0}:
> 2198389808
>
> julia> x[1]
> 2198389808
>
> julia> x[2]
> ERROR: BoundsError: attempt to access 0-dimensional Array{Int64,0}:
> 2198389808
>   at index [2]
>  in getindex at array.jl:282
>
> *julia> x=Array{Int64}(0)*
> 0-element Array{Int64,1}
>
> julia> x[1]
> ERROR: BoundsError: attempt to access 0-element Array{Int64,1}
>   at index [1]
>  in getindex at array.jl:282
>
>
>
>
>
>
>
>


-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] Initializing a new array generates unexpected results

[David Parks]

Hi Mauro, thanks for the response!
I get the logic behind an uninitialized array, but shouldn't such an array 
not return an iterable with 1 element of garbage? Why would it be 
initialized to having 1 random element and not 0?

I would expect an empty constructor to do something reasonable. Perhaps it 
would be logical for these two statements to be equivalent (see bold lines 
below). I don't see the value of having a null constructor that generates 
an array that's iterable with exactly 1 element of garbage contents. Seems 
like a recipe for bugs. My bugs specifically, which is exactly what brought 
me to this topic. :)

*julia> x = Array{Int64}()*
0-dimensional Array{Int64,0}:
2198389808

julia> x[1]
2198389808

julia> x[2]
ERROR: BoundsError: attempt to access 0-dimensional Array{Int64,0}:
2198389808
  at index [2]
 in getindex at array.jl:282

*julia> x=Array{Int64}(0)*
0-element Array{Int64,1}

julia> x[1]
ERROR: BoundsError: attempt to access 0-element Array{Int64,1}
  at index [1]
 in getindex at array.jl:282

Re: [julia-users] Re: Calling Fortran code?

[Erik Schnetter]

Charles

Can you show the complete code, including the definitions of `c` and `IER`?

Can you also show how you "call" these variables, and what the error
message is?

The more detail you give, the easier it is to help.

-erik


On Mon, Jun 6, 2016 at 8:16 PM, Charles Ll  wrote:

> Dear all,
>
> Thank you very much for you help! I've been able to write a form of gcvspl
> that seems to run, with calling:
>
> ccall( (:gcvspl_, "./libgcvspl.so"), Void,
> (Ptr{Float64},Ptr{Float64},Ptr{Cint},Ptr{Float64},Ptr{Float64},Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Float64},Ptr{Float64},Ptr{Cint},Ptr{Float64},Ptr{Cint}),x,y,&NN,wx,wy,&M,&N,&K,&MD,VAL,c,&NC,WK,IER)
>
>
> However, when I try to call the c or IER variables, the Julia kernel
> dies... :s
>
> Do you have any idea why? What am I missing?
>
> Furthermore, dear Erik, what do you mean by using 'Ref' for one-element
> arrays?
>
> Thanks in advance!
>
> Best,
> Charles.
>
> Le lundi 6 juin 2016 22:12:32 UTC+10, Erik Schnetter a écrit :
>>
>> I would use `Cint` as type, not `Int64`, as in `Ptr{Cint}`. Are you sure
>> that your Fortran code uses 64-bit integers? Technically, this violates the
>> Fortran standard. A Fortran integer is the same as a C int, except if you
>> use special flags while building the Fortran library (which you might be
>> doing).
>>
>> You can use `Ref` instead of one-element arrays.
>>
>> Your error message has nothing to do with arrays vs. pointer, but rather
>> the mismatch between `Float64` and `Int64`.
>>
>> -erik
>>
>>
>> On Mon, Jun 6, 2016 at 6:07 AM, Páll Haraldsson 
>> wrote:
>>
>>> On Monday, June 6, 2016 at 3:22:47 AM UTC, Charles Ll wrote:

 Dear all,

 I am trying to call some Fortran code in Julia, but I have a hard time
 doing so... I have read the docs, looked at the wrapping of ARPACK and
 other libraries... But I did not find any way to make it work.

 I am trying to wrap a spline function library (gcvspl.f,
 https://github.com/charlesll/Spectra.jl/tree/master/Dependencies),
 which I want to use in my project, Spectra.jl.

 I already have a wrapper in Python, but this was easier to wrap with
 using f2py. In Julia, I understand that I have to do it properly. The
 function I am trying to call is:

>>>
>>> I think, you may already have gotten the correct answer. At first I was
>>> expecting fcall, not just ccall keyword in Julia, to call Fortran.. It's
>>> not strictly needed, but in fact, there is an issue somewhere still open
>>> about fcall (keyword, or was if for a function?), and it may have been for
>>> your situation..
>>>
>>>
>>> [It might not be too helpful to know, you can call Python with
>>> PyCall.jl, so if you've already wrapped in Python..]
>>>
>>> --
>>> Palli.
>>>
>>>
>>>
>>
>>
>> --
>> Erik Schnetter 
>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>
>


-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

[julia-users] RFC: WebSocket client library

[Eric Forgy]

I'll definitely check this out. Thanks!

We're doing a lot with websockets, but have a two-language problem. I do a lot 
of server prototyping in Julia, but production server is ASP.NET MVC (driven by 
customers mostly), so having a Julia client will help a lot.

Re: [julia-users] Re: Memory corruption when using BigFloats

[Scott Jones]

Thinking further, since BigFloats are treated by convention as being 
immutable (the same as for strings), it would work to simply have 
`deepcopy(x::BigFloat)` return x, the same as `copy(x::Number)` returns x.

-Scott

On Tuesday, June 7, 2016 at 6:35:41 PM UTC-4, Scott Jones wrote:
>
> Issue #16667 wouldn't matter, if copy and deepcopy methods are added for 
> BigFloat.
>
> On Tuesday, June 7, 2016 at 6:25:59 PM UTC-4, Yichao Yu wrote:
>>
>> On Tue, Jun 7, 2016 at 6:24 PM, Chris Rackauckas  
>> wrote: 
>> > Sorry, was making benchmarks and accidentally "fixed it". It turns out 
>> to be 
>> > an issue with deepcopying BigFloats. Here's a small test case: 
>>
>> https://github.com/JuliaLang/julia/issues/16667 
>>
>> > 
>> > immutable StackedArray{T,N,A} <: AbstractArray{T,N} 
>> > data::A 
>> > dims::NTuple{N,Int} 
>> > end 
>> > StackedArray(vec::AbstractVector) = StackedArray(vec, (length(vec), 
>> > size(vec[1])...)) # TODO: ensure all elements are the same size 
>> > StackedArray{A<:AbstractVector, N}(vec::A, dims::NTuple{N}) = 
>> > StackedArray{eltype(eltype(A)),N,A}(vec, dims) 
>> > Base.size(S::StackedArray) = S.dims 
>> > Base.getindex(S::StackedArray, i::Int) = S.data[ind2sub(size(S), i)...] 
>> # 
>> > expand a linear index out 
>> > Base.getindex(S::StackedArray, i::Int, I::Int...) = S.data[i][I...] 
>> > 
>> > x = zeros(BigFloat,4) 
>> > storage = Vector{typeof(x)}(0) 
>> > for i = 1:100 
>> >   x = -.5x + randn(size(x)) 
>> >   push!(storage,deepcopy(x)) 
>> > end 
>> > 
>> > S = StackedArray(storage) 
>> > # This print will cause a segfault 
>> > println(S) 
>> > 
>> > That will segfault randomly if you get one of the bad bigfloats in 
>> there 
>> > (with the loop at 1000, that is pretty much every time). 
>> > 
>> > 
>> > 
>> > On Tuesday, June 7, 2016 at 2:59:09 PM UTC-7, Jeffrey Sarnoff wrote: 
>> >> 
>> >> also -- this may or may not be relevant: 
>> >> 
>> >> from http://www.mpfr.org/mpfr-current/ 
>> >>> 
>> >>> Warning! Due to the fact that Thread Local Storage (TLS) support is 
>> now 
>> >>> detected automatically, the MPFR build can be incorrect on some 
>> platforms 
>> >>> (compiler or system bug). Indeed, the TLS implementation of some 
>> >>> compilers/platforms is buggy, and MPFR cannot detect every problem at 
>> >>> configure time. Please run make check to see if your build is 
>> affected. If 
>> >>> you get failures, you should try the --disable-thread-safe configure 
>> option 
>> >>> to disable TLS and see if this solves these failures. But you should 
>> not use 
>> >>> an MPFR library with TLS disabled in a multithreaded program (unless 
>> you 
>> >>> know what you are doing). 
>> >> 
>> >> 
>> >> And it may be worth checking that you are not mixing Float64 values 
>> with 
>> >> BigFloat math (that can lead to Float64 overflow which looks as if it 
>> were a 
>> >> BigFloat problem). 
>> >> 
>> >> On Tuesday, June 7, 2016 at 5:49:09 PM UTC-4, Jeffrey Sarnoff wrote: 
>>  
>>  e.g. 
>>  
>>  bigpi = BigFloat(pi); 
>>  
>>  dump( bigpi ) 
>>  
>>  string( bigpi )# if possible 
>> >>> 
>> >>> 
>> >>> 
>> >>> 
>> >>> On Tuesday, June 7, 2016 at 2:05:34 PM UTC-4, Pablo Zubieta wrote: 
>>  
>>  It would help to have all the fields of the BigFloat, not only d 
>> (but 
>>  also prec, sign and exp). I think it can be a problem with the 
>> printing 
>>  functions, so having all that might help to figure where the problem 
>> is. 
>>  
>>  On Tuesday, June 7, 2016 at 7:26:02 PM UTC+2, Chris Rackauckas 
>> wrote: 
>> > 
>> > That's the main issue here. I do have a way of creating them... in 
>> a 
>> > private branch that I cannot share right now (give it a month?). 
>> It's not 
>> > easy to create them either: essentially you can solve a really 
>> stiff SDE and 
>> > get them, so think about repeatedly taking random numbers in a 
>> loop, 
>> > multiplying them by small numbers, and accumulate them. Every once 
>> in awhile 
>> > these may pop up, but I don't have a minimal example right now that 
>> does it. 
>> > It's dependent on the chosen precision, so maybe my minimal 
>> examples just 
>> > weren't tough enough for it. 
>> > 
>> >  However, I can dump the contents of the BigFloat: 
>> > 
>> > b = [unsafe_load(A[76].d,i) for i in 1:8] 
>> > 
>> > 
>> > 
>> Any[0x255f4da0,0x,0x6f702323,0x32363923,0x696c0030,0x6f635f61,0x335f7970,0x00343230]
>>  
>>
>> > 
>> >   Other than that, it's hard to share since if it hits the REPL in 
>> any 
>> > way (printing, or default displaying) it segfaults. I only found 
>> them 
>> > because they show up as random zeros if you try to plot an array 
>> that has 
>> > them on Windows (on Linux Python just throws an error). If a Julia 
>> Dev wants 
>> > to take a look at it in more detail I'll give them temporary access 
>> to the 
>> > branch. 
>> > 
>> >   Othe

Re: [julia-users] Re: Using Julia for real time astronomy

[Islam Badreldin]

Hi John,

Please see below ..

On Tuesday, June 7, 2016 at 5:26:32 AM UTC-4, John leger wrote:
>
> Hi Islam,
>
> I like the definition of 95% hard real time; it suits my needs. Thanks for 
> this good paper.
>
> Le lundi 6 juin 2016 18:45:35 UTC+2, Islam Badreldin a écrit :
>>
>> Hi John,
>>
>> I am currently pursuing similar effort. I got a GPIO pin on the 
>> BeagleBone Black embedded board toggling in hard real-time and verified the 
>> jitter with an oscilloscope. For that, I used a vanilla Linux 4.4.11 kernel 
>> with the PREEMPT_RT patch applied. I also released an initial version of a 
>> Julia package that wraps the clock_nanosleep() and clock_gettime() 
>> functions from the POSIX real-time extensions. Please see this other thread:
>> https://groups.google.com/forum/#!topic/julia-users/0Vr2rCRwJY4
>>
>> I tested that package both on Intel-based laptop and on the BeagleBone 
>> Black. I am giving some of the relevant details below..
>>
>> On Monday, June 6, 2016 at 5:41:29 AM UTC-4, John leger wrote:
>>>
>>> Since it seems you have a good overview in this domain I will give more 
>>> details:
>>> We are working in signal processing and especially in image processing. 
>>> The goal here is just the adaptive optic: we just want to stabilize the 
>>> image and not get the final image.
>>> The consequence is that we will not store anything on the hard drive: we 
>>> read an image, process it and destroy it. We stay in RAM all the time.
>>> The processing is done by using/coding our algorithms. So for now, no 
>>> need of any external library (for now, but I don't see any reason for that 
>>> now)
>>>
>>> First I would like to apologize: just after posting my answer I went to 
>>> wikipedia to search the difference between soft and real time. 
>>> I should have done it before so that you don't have to spend more time 
>>> to explain.
>>>
>>> In the end I still don't know if I am hard real time or soft real time: 
>>> the timing is given by the camera speed and the processing should be done 
>>> between the acquisition of two images.
>>> We don't want to miss an image or delay the processing, I still need to 
>>> clarify the consequences of a delay or if we miss an image.
>>> For now let's just say that we can miss some images so we want soft real 
>>> time.
>>>
>>
>> The real-time performance you are after could be 95% hard real-time. See 
>> e.g. here: https://www.osadl.org/fileadmin/dam/rtlws/12/Brown.pdf
>>  
>>
>>>
>>> I'm making a benchmark that should match the system in term of 
>>> complexity, these are my first remarks:
>>>
>>> When you say that one allocation is unacceptable, I say it's shockingly 
>>> true: In my case I had 2 allocations done by:
>>> A +=1 where A is an array
>>> and in 7 seconds I had 600k allocations. 
>>> Morality :In closed loop you cannot accept any alloc and so you have to 
>>> explicit all loops.
>>>
>>
>> Yes, try to completely avoid memory allocations while developing your own 
>> algorithms in Julia. Pre-allocations and in-place operations are your 
>> friends! The example script available on the POSIXClock package is one way 
>> to do this (
>> https://github.com/ibadr/POSIXClock.jl/blob/master/examples/rt_histogram.jl).
>>  
>> The real-time section of the code is marked by a ccall to mlockall() in 
>> order to cause immediate failure upon memory allocations in the real-time 
>> section. You can also use the --track-allocation option to hunt down 
>> memory allocations while developing your algorithm. See e.g. 
>> http://docs.julialang.org/en/release-0.4/manual/profile/#man-track-allocation
>>  
>>
>
> I discovered --track-allocation not so long ago and it is a good tool. 
> For now I think I will rely on tracking allocation manually. I am a little 
> afraid of using mlockall(): In soft or real time crashing (failure) is not 
> a good option for me...
> Since you are talking about --track-allocation I have a question:
>
>
> - function deflat(v::globalVar)
> 0 @simd for i in 1:v.len_sub
> 0 @inbounds v.sub_imagef[i] = v.flat[i]*v.image[i]
> - end
> - 
> 0 @simd for i in 1:v.len_ref
> 0 @inbounds v.ref_imagef[i] = v.flat[i]*v.image[i]
> - end
> 0 return
> - end
> - 
> - # get min max
> - # apply norm_coef
> - # MORE TO DO HERE
> - function normalization(v::globalVar)
> 0 min::Float32 = Float32(4095)
> 0 max::Float32 = Float32(0)
> 0 tmp::Float32 = Float32(0)
> 0 norm_fact::Float32 = Float32(0)
> 0 norm_coef::Float32 = Float32(0)
> - # find min max
> 0 @simd for i in 1:v.nb_mat
> 0 # Doing something with no allocs
> 0 end
> 0 end
> 0 
>   1226415 # SAD[70] 16x16 de Ref_Image sur Sub

Re: [julia-users] Differential Equations Package

[Christoph Ortner]

Hi Chris: I did say I like your package, I think it is really nice work. I 
just have issues with such generic names, that is all. Maybe 
`DifferentialEquations` would have been the name for an organisation 
collecting several ODE and PDE related packages. I thought on the one hand 
your package is incredibly broad (ODEs, PDEs, SDEs, . . .; FE, FD, ...) it 
is also specific in that it is restricted in which DEs you have 
implemented. But maybe I am missing a key point somewhere? 

Actually I'd be interested in a `DifferentialEquations` organisation 
collecting Julia packages for ODE solvers, SDE solvers, FEM, etc. 

[julia-users] RFC: WebSocket client library

[Marcus Appelros]

Awesome! At a glance it seems more user friendly than the existing websockets 
package, which ought to be the case if a full server implementation is not the 
goal.

Re: [julia-users] Differential Equations Package

[digxx]

Hey,
Thx for your answer and sorry for that question, but what is ODE.jl
Probably some other package, which?

And I was looking to solve a similar poisson type equation mainly a 
conservation equation

div(v*Y - D grad Y) = 0
where Y is scalar, v an arbitrary specifyable vector field and D a scalar 
function also specifyable.
Also instead of casting it in cartesian form I wanted to use spherical 
coordinates.
See Ya

Re: [julia-users] Re: Memory corruption when using BigFloats

[Scott Jones]

Issue #16667 wouldn't matter, if copy and deepcopy methods are added for 
BigFloat.

On Tuesday, June 7, 2016 at 6:25:59 PM UTC-4, Yichao Yu wrote:
>
> On Tue, Jun 7, 2016 at 6:24 PM, Chris Rackauckas  > wrote: 
> > Sorry, was making benchmarks and accidentally "fixed it". It turns out 
> to be 
> > an issue with deepcopying BigFloats. Here's a small test case: 
>
> https://github.com/JuliaLang/julia/issues/16667 
>
> > 
> > immutable StackedArray{T,N,A} <: AbstractArray{T,N} 
> > data::A 
> > dims::NTuple{N,Int} 
> > end 
> > StackedArray(vec::AbstractVector) = StackedArray(vec, (length(vec), 
> > size(vec[1])...)) # TODO: ensure all elements are the same size 
> > StackedArray{A<:AbstractVector, N}(vec::A, dims::NTuple{N}) = 
> > StackedArray{eltype(eltype(A)),N,A}(vec, dims) 
> > Base.size(S::StackedArray) = S.dims 
> > Base.getindex(S::StackedArray, i::Int) = S.data[ind2sub(size(S), i)...] 
> # 
> > expand a linear index out 
> > Base.getindex(S::StackedArray, i::Int, I::Int...) = S.data[i][I...] 
> > 
> > x = zeros(BigFloat,4) 
> > storage = Vector{typeof(x)}(0) 
> > for i = 1:100 
> >   x = -.5x + randn(size(x)) 
> >   push!(storage,deepcopy(x)) 
> > end 
> > 
> > S = StackedArray(storage) 
> > # This print will cause a segfault 
> > println(S) 
> > 
> > That will segfault randomly if you get one of the bad bigfloats in there 
> > (with the loop at 1000, that is pretty much every time). 
> > 
> > 
> > 
> > On Tuesday, June 7, 2016 at 2:59:09 PM UTC-7, Jeffrey Sarnoff wrote: 
> >> 
> >> also -- this may or may not be relevant: 
> >> 
> >> from http://www.mpfr.org/mpfr-current/ 
> >>> 
> >>> Warning! Due to the fact that Thread Local Storage (TLS) support is 
> now 
> >>> detected automatically, the MPFR build can be incorrect on some 
> platforms 
> >>> (compiler or system bug). Indeed, the TLS implementation of some 
> >>> compilers/platforms is buggy, and MPFR cannot detect every problem at 
> >>> configure time. Please run make check to see if your build is 
> affected. If 
> >>> you get failures, you should try the --disable-thread-safe configure 
> option 
> >>> to disable TLS and see if this solves these failures. But you should 
> not use 
> >>> an MPFR library with TLS disabled in a multithreaded program (unless 
> you 
> >>> know what you are doing). 
> >> 
> >> 
> >> And it may be worth checking that you are not mixing Float64 values 
> with 
> >> BigFloat math (that can lead to Float64 overflow which looks as if it 
> were a 
> >> BigFloat problem). 
> >> 
> >> On Tuesday, June 7, 2016 at 5:49:09 PM UTC-4, Jeffrey Sarnoff wrote: 
>  
>  e.g. 
>  
>  bigpi = BigFloat(pi); 
>  
>  dump( bigpi ) 
>  
>  string( bigpi )# if possible 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> On Tuesday, June 7, 2016 at 2:05:34 PM UTC-4, Pablo Zubieta wrote: 
>  
>  It would help to have all the fields of the BigFloat, not only d (but 
>  also prec, sign and exp). I think it can be a problem with the 
> printing 
>  functions, so having all that might help to figure where the problem 
> is. 
>  
>  On Tuesday, June 7, 2016 at 7:26:02 PM UTC+2, Chris Rackauckas wrote: 
> > 
> > That's the main issue here. I do have a way of creating them... in a 
> > private branch that I cannot share right now (give it a month?). 
> It's not 
> > easy to create them either: essentially you can solve a really stiff 
> SDE and 
> > get them, so think about repeatedly taking random numbers in a loop, 
> > multiplying them by small numbers, and accumulate them. Every once 
> in awhile 
> > these may pop up, but I don't have a minimal example right now that 
> does it. 
> > It's dependent on the chosen precision, so maybe my minimal examples 
> just 
> > weren't tough enough for it. 
> > 
> >  However, I can dump the contents of the BigFloat: 
> > 
> > b = [unsafe_load(A[76].d,i) for i in 1:8] 
> > 
> > 
> > 
> Any[0x255f4da0,0x,0x6f702323,0x32363923,0x696c0030,0x6f635f61,0x335f7970,0x00343230]
>  
>
> > 
> >   Other than that, it's hard to share since if it hits the REPL in 
> any 
> > way (printing, or default displaying) it segfaults. I only found 
> them 
> > because they show up as random zeros if you try to plot an array 
> that has 
> > them on Windows (on Linux Python just throws an error). If a Julia 
> Dev wants 
> > to take a look at it in more detail I'll give them temporary access 
> to the 
> > branch. 
> > 
> >   Otherwise I'll keep this in the back of my mind and when I release 
> > this part of the code I'll show exactly how bigfloats (and only 
> bigfloats) 
> > fail here, and cause a segfault. I wish I can be more open but my 
> adviser 
> > wants this code private until published, so I am sticking with it 
> (again, 
> > everything works except not sufficiently high precision bigs, so 
> it's not 
> > necessary for the paper at a

Re: [julia-users] Re: Memory corruption when using BigFloats

[Chris Rackauckas]

That's exactly the issue. Thanks for pointing that out. I guess it's been 
known for a few days now. That makes some nasty bugs to track down. Funny 
that the people at ODE.jl also ran into this!

On Tuesday, June 7, 2016 at 3:25:59 PM UTC-7, Yichao Yu wrote:
>
> On Tue, Jun 7, 2016 at 6:24 PM, Chris Rackauckas  > wrote: 
> > Sorry, was making benchmarks and accidentally "fixed it". It turns out 
> to be 
> > an issue with deepcopying BigFloats. Here's a small test case: 
>
> https://github.com/JuliaLang/julia/issues/16667 
>
> > 
> > immutable StackedArray{T,N,A} <: AbstractArray{T,N} 
> > data::A 
> > dims::NTuple{N,Int} 
> > end 
> > StackedArray(vec::AbstractVector) = StackedArray(vec, (length(vec), 
> > size(vec[1])...)) # TODO: ensure all elements are the same size 
> > StackedArray{A<:AbstractVector, N}(vec::A, dims::NTuple{N}) = 
> > StackedArray{eltype(eltype(A)),N,A}(vec, dims) 
> > Base.size(S::StackedArray) = S.dims 
> > Base.getindex(S::StackedArray, i::Int) = S.data[ind2sub(size(S), i)...] 
> # 
> > expand a linear index out 
> > Base.getindex(S::StackedArray, i::Int, I::Int...) = S.data[i][I...] 
> > 
> > x = zeros(BigFloat,4) 
> > storage = Vector{typeof(x)}(0) 
> > for i = 1:100 
> >   x = -.5x + randn(size(x)) 
> >   push!(storage,deepcopy(x)) 
> > end 
> > 
> > S = StackedArray(storage) 
> > # This print will cause a segfault 
> > println(S) 
> > 
> > That will segfault randomly if you get one of the bad bigfloats in there 
> > (with the loop at 1000, that is pretty much every time). 
> > 
> > 
> > 
> > On Tuesday, June 7, 2016 at 2:59:09 PM UTC-7, Jeffrey Sarnoff wrote: 
> >> 
> >> also -- this may or may not be relevant: 
> >> 
> >> from http://www.mpfr.org/mpfr-current/ 
> >>> 
> >>> Warning! Due to the fact that Thread Local Storage (TLS) support is 
> now 
> >>> detected automatically, the MPFR build can be incorrect on some 
> platforms 
> >>> (compiler or system bug). Indeed, the TLS implementation of some 
> >>> compilers/platforms is buggy, and MPFR cannot detect every problem at 
> >>> configure time. Please run make check to see if your build is 
> affected. If 
> >>> you get failures, you should try the --disable-thread-safe configure 
> option 
> >>> to disable TLS and see if this solves these failures. But you should 
> not use 
> >>> an MPFR library with TLS disabled in a multithreaded program (unless 
> you 
> >>> know what you are doing). 
> >> 
> >> 
> >> And it may be worth checking that you are not mixing Float64 values 
> with 
> >> BigFloat math (that can lead to Float64 overflow which looks as if it 
> were a 
> >> BigFloat problem). 
> >> 
> >> On Tuesday, June 7, 2016 at 5:49:09 PM UTC-4, Jeffrey Sarnoff wrote: 
>  
>  e.g. 
>  
>  bigpi = BigFloat(pi); 
>  
>  dump( bigpi ) 
>  
>  string( bigpi )# if possible 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> On Tuesday, June 7, 2016 at 2:05:34 PM UTC-4, Pablo Zubieta wrote: 
>  
>  It would help to have all the fields of the BigFloat, not only d (but 
>  also prec, sign and exp). I think it can be a problem with the 
> printing 
>  functions, so having all that might help to figure where the problem 
> is. 
>  
>  On Tuesday, June 7, 2016 at 7:26:02 PM UTC+2, Chris Rackauckas wrote: 
> > 
> > That's the main issue here. I do have a way of creating them... in a 
> > private branch that I cannot share right now (give it a month?). 
> It's not 
> > easy to create them either: essentially you can solve a really stiff 
> SDE and 
> > get them, so think about repeatedly taking random numbers in a loop, 
> > multiplying them by small numbers, and accumulate them. Every once 
> in awhile 
> > these may pop up, but I don't have a minimal example right now that 
> does it. 
> > It's dependent on the chosen precision, so maybe my minimal examples 
> just 
> > weren't tough enough for it. 
> > 
> >  However, I can dump the contents of the BigFloat: 
> > 
> > b = [unsafe_load(A[76].d,i) for i in 1:8] 
> > 
> > 
> > 
> Any[0x255f4da0,0x,0x6f702323,0x32363923,0x696c0030,0x6f635f61,0x335f7970,0x00343230]
>  
>
> > 
> >   Other than that, it's hard to share since if it hits the REPL in 
> any 
> > way (printing, or default displaying) it segfaults. I only found 
> them 
> > because they show up as random zeros if you try to plot an array 
> that has 
> > them on Windows (on Linux Python just throws an error). If a Julia 
> Dev wants 
> > to take a look at it in more detail I'll give them temporary access 
> to the 
> > branch. 
> > 
> >   Otherwise I'll keep this in the back of my mind and when I release 
> > this part of the code I'll show exactly how bigfloats (and only 
> bigfloats) 
> > fail here, and cause a segfault. I wish I can be more open but my 
> adviser 
> > wants this code private until published, so I am sticking with it 
> (again, 
> > ev

Re: [julia-users] Re: Calling Fortran code?

[Charles Ll]

Ok thanks!

I think I need to embed my ccall in a Julia function with indicating arrays 
for output like DX::Union{Ptr{$elty},DenseArray{$elty}} in the function 
declaration. I will try something like that and see the result.

Those things are pretty obscur in the Julia doc for ccall... Maybe we could 
ask for more explicit Fortran examples in the doc?

Charles.



Le mercredi 8 juin 2016 00:56:02 UTC+10, Paulo Jabardo a écrit :
>
> I haven't done this often but when I did I looked at how it is done in the 
> lapack and blas interfaces. There are several examples
>
> https://github.com/JuliaLang/julia/blob/master/base/linalg/blas.jl
>
> https://github.com/JuliaLang/julia/blob/master/base/linalg/lapack.jl
>
>
> Paulo
>
> On Monday, June 6, 2016 at 9:16:27 PM UTC-3, Charles Ll wrote:
>>
>> Dear all,
>>
>> Thank you very much for you help! I've been able to write a form of 
>> gcvspl that seems to run, with calling:
>>
>> ccall( (:gcvspl_, "./libgcvspl.so"), Void, 
>> (Ptr{Float64},Ptr{Float64},Ptr{Cint},Ptr{Float64},Ptr{Float64},Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Float64},Ptr{Float64},Ptr{Cint},Ptr{Float64},Ptr{Cint}),x,y,&NN,wx,wy,&M,&N,&K,&MD,VAL,c,&NC,WK,IER)
>>
>>
>> However, when I try to call the c or IER variables, the Julia kernel 
>> dies... :s
>>
>> Do you have any idea why? What am I missing?
>>
>> Furthermore, dear Erik, what do you mean by using 'Ref' for one-element 
>> arrays?
>>
>> Thanks in advance!
>>
>> Best,
>> Charles.
>>
>> Le lundi 6 juin 2016 22:12:32 UTC+10, Erik Schnetter a écrit :
>>>
>>> I would use `Cint` as type, not `Int64`, as in `Ptr{Cint}`. Are you sure 
>>> that your Fortran code uses 64-bit integers? Technically, this violates the 
>>> Fortran standard. A Fortran integer is the same as a C int, except if you 
>>> use special flags while building the Fortran library (which you might be 
>>> doing).
>>>
>>> You can use `Ref` instead of one-element arrays.
>>>
>>> Your error message has nothing to do with arrays vs. pointer, but rather 
>>> the mismatch between `Float64` and `Int64`.
>>>
>>> -erik
>>>
>>>
>>> On Mon, Jun 6, 2016 at 6:07 AM, Páll Haraldsson  
>>> wrote:
>>>
 On Monday, June 6, 2016 at 3:22:47 AM UTC, Charles Ll wrote:
>
> Dear all,
>
> I am trying to call some Fortran code in Julia, but I have a hard time 
> doing so... I have read the docs, looked at the wrapping of ARPACK and 
> other libraries... But I did not find any way to make it work.
>
> I am trying to wrap a spline function library (gcvspl.f, 
> https://github.com/charlesll/Spectra.jl/tree/master/Dependencies), 
> which I want to use in my project, Spectra.jl.
>
> I already have a wrapper in Python, but this was easier to wrap with 
> using f2py. In Julia, I understand that I have to do it properly. The 
> function I am trying to call is:
>

 I think, you may already have gotten the correct answer. At first I was 
 expecting fcall, not just ccall keyword in Julia, to call Fortran.. It's 
 not strictly needed, but in fact, there is an issue somewhere still open 
 about fcall (keyword, or was if for a function?), and it may have been for 
 your situation..


 [It might not be too helpful to know, you can call Python with 
 PyCall.jl, so if you've already wrapped in Python..]

 -- 
 Palli.



>>>
>>>
>>> -- 
>>> Erik Schnetter  
>>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>>
>>

[julia-users] Re: Memory corruption when using BigFloats

[Scott Jones]

It turns out, that copy is also equally broken.
To correctly copy a BigFloat, it should be creating a new BigFloat with the 
same precision as the BigFloat being copied (not the current precision), 
copy the fields exp and sign, and copy the limbs pointed to by the d field.
Finally, it needs to add a finalizer for the copy.

I can write the fix, if somebody else can merge it in.

Scott

On Tuesday, June 7, 2016 at 6:24:26 PM UTC-4, Chris Rackauckas wrote:
>
> Sorry, was making benchmarks and accidentally "fixed it". It turns out to 
> be an issue with deepcopying BigFloats. Here's a small test case:
>
> immutable StackedArray{T,N,A} <: AbstractArray{T,N}
> data::A
> dims::NTuple{N,Int}
> end
> StackedArray(vec::AbstractVector) = StackedArray(vec, (length(vec), 
> size(vec[1])...)) # TODO: ensure all elements are the same size
> StackedArray{A<:AbstractVector, N}(vec::A, dims::NTuple{N}) = 
> StackedArray{eltype(eltype(A)),N,A}(vec, dims)
> Base.size(S::StackedArray) = S.dims
> Base.getindex(S::StackedArray, i::Int) = S.data[ind2sub(size(S), i)...] # 
> expand a linear index out
> Base.getindex(S::StackedArray, i::Int, I::Int...) = S.data[i][I...]
>
> x = zeros(BigFloat,4)
> storage = Vector{typeof(x)}(0)
> for i = 1:100
>   x = -.5x + randn(size(x))
>   push!(storage,deepcopy(x))
> end
>
> S = StackedArray(storage)
> # This print will cause a segfault
> println(S)
>
> That will segfault randomly if you get one of the bad bigfloats in there 
> (with the loop at 1000, that is pretty much every time). 
>
>
> On Tuesday, June 7, 2016 at 2:59:09 PM UTC-7, Jeffrey Sarnoff wrote:
>>
>> also -- this may or may not be relevant:
>>
>> from http://www.mpfr.org/mpfr-current/
>>
>>> *Warning! Due to the fact that Thread Local Storage (TLS) support is now 
>>> detected automatically, the MPFR build can be incorrect on some platforms* 
>>> (compiler 
>>> or system bug). Indeed, the TLS implementation of some 
>>> compilers/platforms is buggy 
>>> , and MPFR cannot 
>>> detect every problem at configure time. Please run make check to see if 
>>> your build is affected. If you get failures, you should try the 
>>> --disable-thread-safe configure option to disable TLS and see if this 
>>> solves these failures. But you should not use an MPFR library with TLS 
>>> disabled 
>>> in a multithreaded program (unless you know what you are doing).
>>>
>>
>> And it may be worth checking that you are not mixing Float64 values with 
>> BigFloat math (that can lead to Float64 overflow which looks as if it were 
>> a BigFloat problem).
>>
>> On Tuesday, June 7, 2016 at 5:49:09 PM UTC-4, Jeffrey Sarnoff wrote:
>>>
>>> e.g.

>>> bigpi = BigFloat(pi); 
>>>
>>> dump( bigpi )
>>>
>>> string( bigpi )# if possible
>>>
>>>  
>>>  
>>>
>>> On Tuesday, June 7, 2016 at 2:05:34 PM UTC-4, Pablo Zubieta wrote:

 It would help to have all the fields of the BigFloat, not only d (but 
 also prec, sign and exp). I think it can be a problem with the printing 
 functions, so having all that might help to figure where the problem is.

 On Tuesday, June 7, 2016 at 7:26:02 PM UTC+2, Chris Rackauckas wrote:
>
> That's the main issue here. I do have a way of creating them... in a 
> private branch that I cannot share right now (give it a month?). It's not 
> easy to create them either: essentially you can solve a really stiff SDE 
> and get them, so think about repeatedly taking random numbers in a loop, 
> multiplying them by small numbers, and accumulate them. Every once in 
> awhile these may pop up, but I don't have a minimal example right now 
> that 
> does it. It's dependent on the chosen precision, so maybe my minimal 
> examples just weren't tough enough for it.
>
>  However, I can dump the contents of the BigFloat:
>
> b = [unsafe_load(A[76].d,i) for i in 1:8]
>
> Any[0x255f4da0,0x,0x6f702323,0x32363923,0x696c0030,0x6f635f61,
> 0x335f7970,0x00343230]
>
>   Other than that, it's hard to share since if it hits the REPL in any 
> way (printing, or default displaying) it segfaults. I only found them 
> because they show up as random zeros if you try to plot an array that has 
> them on Windows (on Linux Python just throws an error). If a Julia Dev 
> wants to take a look at it in more detail I'll give them temporary access 
> to the branch.
>
>   Otherwise I'll keep this in the back of my mind and when I release 
> this part of the code I'll show exactly how bigfloats (and only 
> bigfloats) 
> fail here, and cause a segfault. I wish I can be more open but my adviser 
> wants this code private until published, so I am sticking with it (again, 
> everything works except not sufficiently high precision bigs, so it's not 
> necessary for the paper at all).
>
> On Tuesday, June 7, 2016 at 9:58:23 AM UTC-7, Pablo Zubieta 

[julia-users] Re: Memory corruption when using BigFloats

[Chris Rackauckas]

Forgot to mention that if you change the deepcopy in the loop to copy, it 
works. 

Re: [julia-users] Re: Memory corruption when using BigFloats

[Yichao Yu]

On Tue, Jun 7, 2016 at 6:24 PM, Chris Rackauckas  wrote:
> Sorry, was making benchmarks and accidentally "fixed it". It turns out to be
> an issue with deepcopying BigFloats. Here's a small test case:

https://github.com/JuliaLang/julia/issues/16667

>
> immutable StackedArray{T,N,A} <: AbstractArray{T,N}
> data::A
> dims::NTuple{N,Int}
> end
> StackedArray(vec::AbstractVector) = StackedArray(vec, (length(vec),
> size(vec[1])...)) # TODO: ensure all elements are the same size
> StackedArray{A<:AbstractVector, N}(vec::A, dims::NTuple{N}) =
> StackedArray{eltype(eltype(A)),N,A}(vec, dims)
> Base.size(S::StackedArray) = S.dims
> Base.getindex(S::StackedArray, i::Int) = S.data[ind2sub(size(S), i)...] #
> expand a linear index out
> Base.getindex(S::StackedArray, i::Int, I::Int...) = S.data[i][I...]
>
> x = zeros(BigFloat,4)
> storage = Vector{typeof(x)}(0)
> for i = 1:100
>   x = -.5x + randn(size(x))
>   push!(storage,deepcopy(x))
> end
>
> S = StackedArray(storage)
> # This print will cause a segfault
> println(S)
>
> That will segfault randomly if you get one of the bad bigfloats in there
> (with the loop at 1000, that is pretty much every time).
>
>
>
> On Tuesday, June 7, 2016 at 2:59:09 PM UTC-7, Jeffrey Sarnoff wrote:
>>
>> also -- this may or may not be relevant:
>>
>> from http://www.mpfr.org/mpfr-current/
>>>
>>> Warning! Due to the fact that Thread Local Storage (TLS) support is now
>>> detected automatically, the MPFR build can be incorrect on some platforms
>>> (compiler or system bug). Indeed, the TLS implementation of some
>>> compilers/platforms is buggy, and MPFR cannot detect every problem at
>>> configure time. Please run make check to see if your build is affected. If
>>> you get failures, you should try the --disable-thread-safe configure option
>>> to disable TLS and see if this solves these failures. But you should not use
>>> an MPFR library with TLS disabled in a multithreaded program (unless you
>>> know what you are doing).
>>
>>
>> And it may be worth checking that you are not mixing Float64 values with
>> BigFloat math (that can lead to Float64 overflow which looks as if it were a
>> BigFloat problem).
>>
>> On Tuesday, June 7, 2016 at 5:49:09 PM UTC-4, Jeffrey Sarnoff wrote:

 e.g.

 bigpi = BigFloat(pi);

 dump( bigpi )

 string( bigpi )# if possible
>>>
>>>
>>>
>>>
>>> On Tuesday, June 7, 2016 at 2:05:34 PM UTC-4, Pablo Zubieta wrote:

 It would help to have all the fields of the BigFloat, not only d (but
 also prec, sign and exp). I think it can be a problem with the printing
 functions, so having all that might help to figure where the problem is.

 On Tuesday, June 7, 2016 at 7:26:02 PM UTC+2, Chris Rackauckas wrote:
>
> That's the main issue here. I do have a way of creating them... in a
> private branch that I cannot share right now (give it a month?). It's not
> easy to create them either: essentially you can solve a really stiff SDE 
> and
> get them, so think about repeatedly taking random numbers in a loop,
> multiplying them by small numbers, and accumulate them. Every once in 
> awhile
> these may pop up, but I don't have a minimal example right now that does 
> it.
> It's dependent on the chosen precision, so maybe my minimal examples just
> weren't tough enough for it.
>
>  However, I can dump the contents of the BigFloat:
>
> b = [unsafe_load(A[76].d,i) for i in 1:8]
>
>
> Any[0x255f4da0,0x,0x6f702323,0x32363923,0x696c0030,0x6f635f61,0x335f7970,0x00343230]
>
>   Other than that, it's hard to share since if it hits the REPL in any
> way (printing, or default displaying) it segfaults. I only found them
> because they show up as random zeros if you try to plot an array that has
> them on Windows (on Linux Python just throws an error). If a Julia Dev 
> wants
> to take a look at it in more detail I'll give them temporary access to the
> branch.
>
>   Otherwise I'll keep this in the back of my mind and when I release
> this part of the code I'll show exactly how bigfloats (and only bigfloats)
> fail here, and cause a segfault. I wish I can be more open but my adviser
> wants this code private until published, so I am sticking with it (again,
> everything works except not sufficiently high precision bigs, so it's not
> necessary for the paper at all).
>
> On Tuesday, June 7, 2016 at 9:58:23 AM UTC-7, Pablo Zubieta wrote:
>>
>> Do you happen to have a minimal reproducible example?
>>
>> On Tuesday, June 7, 2016 at 6:23:05 PM UTC+2, Scott Jones wrote:
>>>
>>> I've been trying to help @ChrisRackaukus (of DifferentialEquations.jl
>>> fame!) out with a nasty bug he's been running into.
>>> He is using `BigFloat`s, and keeps getting numbers that, when
>>> printed, cause an MPFR assertion failure.
>>> When I looked at thes

[julia-users] Re: Memory corruption when using BigFloats

[Chris Rackauckas]

Sorry, was making benchmarks and accidentally "fixed it". It turns out to 
be an issue with deepcopying BigFloats. Here's a small test case:

immutable StackedArray{T,N,A} <: AbstractArray{T,N}
data::A
dims::NTuple{N,Int}
end
StackedArray(vec::AbstractVector) = StackedArray(vec, (length(vec), 
size(vec[1])...)) # TODO: ensure all elements are the same size
StackedArray{A<:AbstractVector, N}(vec::A, dims::NTuple{N}) = 
StackedArray{eltype(eltype(A)),N,A}(vec, dims)
Base.size(S::StackedArray) = S.dims
Base.getindex(S::StackedArray, i::Int) = S.data[ind2sub(size(S), i)...] # 
expand a linear index out
Base.getindex(S::StackedArray, i::Int, I::Int...) = S.data[i][I...]

x = zeros(BigFloat,4)
storage = Vector{typeof(x)}(0)
for i = 1:100
  x = -.5x + randn(size(x))
  push!(storage,deepcopy(x))
end

S = StackedArray(storage)
# This print will cause a segfault
println(S)

That will segfault randomly if you get one of the bad bigfloats in there 
(with the loop at 1000, that is pretty much every time). 


On Tuesday, June 7, 2016 at 2:59:09 PM UTC-7, Jeffrey Sarnoff wrote:
>
> also -- this may or may not be relevant:
>
> from http://www.mpfr.org/mpfr-current/
>
>> *Warning! Due to the fact that Thread Local Storage (TLS) support is now 
>> detected automatically, the MPFR build can be incorrect on some platforms* 
>> (compiler 
>> or system bug). Indeed, the TLS implementation of some 
>> compilers/platforms is buggy 
>> , and MPFR cannot 
>> detect every problem at configure time. Please run make check to see if 
>> your build is affected. If you get failures, you should try the 
>> --disable-thread-safe configure option to disable TLS and see if this 
>> solves these failures. But you should not use an MPFR library with TLS 
>> disabled 
>> in a multithreaded program (unless you know what you are doing).
>>
>
> And it may be worth checking that you are not mixing Float64 values with 
> BigFloat math (that can lead to Float64 overflow which looks as if it were 
> a BigFloat problem).
>
> On Tuesday, June 7, 2016 at 5:49:09 PM UTC-4, Jeffrey Sarnoff wrote:
>>
>> e.g.
>>>
>> bigpi = BigFloat(pi); 
>>
>> dump( bigpi )
>>
>> string( bigpi )# if possible
>>
>>  
>>  
>>
>> On Tuesday, June 7, 2016 at 2:05:34 PM UTC-4, Pablo Zubieta wrote:
>>>
>>> It would help to have all the fields of the BigFloat, not only d (but 
>>> also prec, sign and exp). I think it can be a problem with the printing 
>>> functions, so having all that might help to figure where the problem is.
>>>
>>> On Tuesday, June 7, 2016 at 7:26:02 PM UTC+2, Chris Rackauckas wrote:

 That's the main issue here. I do have a way of creating them... in a 
 private branch that I cannot share right now (give it a month?). It's not 
 easy to create them either: essentially you can solve a really stiff SDE 
 and get them, so think about repeatedly taking random numbers in a loop, 
 multiplying them by small numbers, and accumulate them. Every once in 
 awhile these may pop up, but I don't have a minimal example right now that 
 does it. It's dependent on the chosen precision, so maybe my minimal 
 examples just weren't tough enough for it.

  However, I can dump the contents of the BigFloat:

 b = [unsafe_load(A[76].d,i) for i in 1:8]

 Any[0x255f4da0,0x,0x6f702323,0x32363923,0x696c0030,0x6f635f61,
 0x335f7970,0x00343230]

   Other than that, it's hard to share since if it hits the REPL in any 
 way (printing, or default displaying) it segfaults. I only found them 
 because they show up as random zeros if you try to plot an array that has 
 them on Windows (on Linux Python just throws an error). If a Julia Dev 
 wants to take a look at it in more detail I'll give them temporary access 
 to the branch.

   Otherwise I'll keep this in the back of my mind and when I release 
 this part of the code I'll show exactly how bigfloats (and only bigfloats) 
 fail here, and cause a segfault. I wish I can be more open but my adviser 
 wants this code private until published, so I am sticking with it (again, 
 everything works except not sufficiently high precision bigs, so it's not 
 necessary for the paper at all).

 On Tuesday, June 7, 2016 at 9:58:23 AM UTC-7, Pablo Zubieta wrote:
>
> Do you happen to have a minimal reproducible example?
>
> On Tuesday, June 7, 2016 at 6:23:05 PM UTC+2, Scott Jones wrote:
>>
>> I've been trying to help @ChrisRackaukus (of DifferentialEquations.jl 
>> fame!) out with a nasty bug he's been running into.
>> He is using `BigFloat`s, and keeps getting numbers that, when 
>> printed, cause an MPFR assertion failure.
>> When I looked at these corrupted `BigFloat`s, I found the following 
>> strings (they always started off corrupted at the location of the 
>> pointer + 
>> 8)
>>
>> *"##

[julia-users] is the L in (L,U,p) = lu(A) in guaranteed to have 1's on the diagonal when A is not full rank?

[Gabriel Goh]

A simple question as posed in the title, this is guaranteed by LAPACK

  The factorization has the form
 A = P * L * U
  where P is a permutation matrix, L is lower triangular with unit diagonal
  elements (lower trapezoidal if m > n), and U is upper triangular (upper
  trapezoidal if m < n).


but is not part of the official Julia documentation. Just wanted to make sure 
that was the case because it's a useful feature in understanding the null space 
of the matrix

[julia-users] Re: Memory corruption when using BigFloats

[Jeffrey Sarnoff]

also -- this may or may not be relevant:

from http://www.mpfr.org/mpfr-current/

> *Warning! Due to the fact that Thread Local Storage (TLS) support is now 
> detected automatically, the MPFR build can be incorrect on some platforms* 
> (compiler 
> or system bug). Indeed, the TLS implementation of some 
> compilers/platforms is buggy 
> , and MPFR cannot 
> detect every problem at configure time. Please run make check to see if 
> your build is affected. If you get failures, you should try the 
> --disable-thread-safe configure option to disable TLS and see if this 
> solves these failures. But you should not use an MPFR library with TLS 
> disabled 
> in a multithreaded program (unless you know what you are doing).
>

And it may be worth checking that you are not mixing Float64 values with 
BigFloat math (that can lead to Float64 overflow which looks as if it were 
a BigFloat problem).

On Tuesday, June 7, 2016 at 5:49:09 PM UTC-4, Jeffrey Sarnoff wrote:
>
> e.g.
>>
> bigpi = BigFloat(pi); 
>
> dump( bigpi )
>
> string( bigpi )# if possible
>
>  
>  
>
> On Tuesday, June 7, 2016 at 2:05:34 PM UTC-4, Pablo Zubieta wrote:
>>
>> It would help to have all the fields of the BigFloat, not only d (but 
>> also prec, sign and exp). I think it can be a problem with the printing 
>> functions, so having all that might help to figure where the problem is.
>>
>> On Tuesday, June 7, 2016 at 7:26:02 PM UTC+2, Chris Rackauckas wrote:
>>>
>>> That's the main issue here. I do have a way of creating them... in a 
>>> private branch that I cannot share right now (give it a month?). It's not 
>>> easy to create them either: essentially you can solve a really stiff SDE 
>>> and get them, so think about repeatedly taking random numbers in a loop, 
>>> multiplying them by small numbers, and accumulate them. Every once in 
>>> awhile these may pop up, but I don't have a minimal example right now that 
>>> does it. It's dependent on the chosen precision, so maybe my minimal 
>>> examples just weren't tough enough for it.
>>>
>>>  However, I can dump the contents of the BigFloat:
>>>
>>> b = [unsafe_load(A[76].d,i) for i in 1:8]
>>>
>>> Any[0x255f4da0,0x,0x6f702323,0x32363923,0x696c0030,0x6f635f61,
>>> 0x335f7970,0x00343230]
>>>
>>>   Other than that, it's hard to share since if it hits the REPL in any 
>>> way (printing, or default displaying) it segfaults. I only found them 
>>> because they show up as random zeros if you try to plot an array that has 
>>> them on Windows (on Linux Python just throws an error). If a Julia Dev 
>>> wants to take a look at it in more detail I'll give them temporary access 
>>> to the branch.
>>>
>>>   Otherwise I'll keep this in the back of my mind and when I release 
>>> this part of the code I'll show exactly how bigfloats (and only bigfloats) 
>>> fail here, and cause a segfault. I wish I can be more open but my adviser 
>>> wants this code private until published, so I am sticking with it (again, 
>>> everything works except not sufficiently high precision bigs, so it's not 
>>> necessary for the paper at all).
>>>
>>> On Tuesday, June 7, 2016 at 9:58:23 AM UTC-7, Pablo Zubieta wrote:

 Do you happen to have a minimal reproducible example?

 On Tuesday, June 7, 2016 at 6:23:05 PM UTC+2, Scott Jones wrote:
>
> I've been trying to help @ChrisRackaukus (of DifferentialEquations.jl 
> fame!) out with a nasty bug he's been running into.
> He is using `BigFloat`s, and keeps getting numbers that, when printed, 
> cause an MPFR assertion failure.
> When I looked at these corrupted `BigFloat`s, I found the following 
> strings (they always started off corrupted at the location of the pointer 
> + 
> 8)
>
> *"##po#9620\0lia_copy_3024\0"*
>
> *"julia_annotations_3495\0\0"*
>
>
> This corruption occurred both running on 64-bit Windows, and on Linux 
> (Centos), on Julia v0.4.5.
>
>
> Thanks in advance for any clues as to what is causing this corruption!
>
>
>

[julia-users] Re: Memory corruption when using BigFloats

[Jeffrey Sarnoff]

>
> e.g.
>
bigpi = BigFloat(pi); 

dump( bigpi )

string( bigpi )# if possible

 
 

On Tuesday, June 7, 2016 at 2:05:34 PM UTC-4, Pablo Zubieta wrote:
>
> It would help to have all the fields of the BigFloat, not only d (but also 
> prec, sign and exp). I think it can be a problem with the printing 
> functions, so having all that might help to figure where the problem is.
>
> On Tuesday, June 7, 2016 at 7:26:02 PM UTC+2, Chris Rackauckas wrote:
>>
>> That's the main issue here. I do have a way of creating them... in a 
>> private branch that I cannot share right now (give it a month?). It's not 
>> easy to create them either: essentially you can solve a really stiff SDE 
>> and get them, so think about repeatedly taking random numbers in a loop, 
>> multiplying them by small numbers, and accumulate them. Every once in 
>> awhile these may pop up, but I don't have a minimal example right now that 
>> does it. It's dependent on the chosen precision, so maybe my minimal 
>> examples just weren't tough enough for it.
>>
>>  However, I can dump the contents of the BigFloat:
>>
>> b = [unsafe_load(A[76].d,i) for i in 1:8]
>>
>> Any[0x255f4da0,0x,0x6f702323,0x32363923,0x696c0030,0x6f635f61,
>> 0x335f7970,0x00343230]
>>
>>   Other than that, it's hard to share since if it hits the REPL in any 
>> way (printing, or default displaying) it segfaults. I only found them 
>> because they show up as random zeros if you try to plot an array that has 
>> them on Windows (on Linux Python just throws an error). If a Julia Dev 
>> wants to take a look at it in more detail I'll give them temporary access 
>> to the branch.
>>
>>   Otherwise I'll keep this in the back of my mind and when I release this 
>> part of the code I'll show exactly how bigfloats (and only bigfloats) fail 
>> here, and cause a segfault. I wish I can be more open but my adviser wants 
>> this code private until published, so I am sticking with it (again, 
>> everything works except not sufficiently high precision bigs, so it's not 
>> necessary for the paper at all).
>>
>> On Tuesday, June 7, 2016 at 9:58:23 AM UTC-7, Pablo Zubieta wrote:
>>>
>>> Do you happen to have a minimal reproducible example?
>>>
>>> On Tuesday, June 7, 2016 at 6:23:05 PM UTC+2, Scott Jones wrote:

 I've been trying to help @ChrisRackaukus (of DifferentialEquations.jl 
 fame!) out with a nasty bug he's been running into.
 He is using `BigFloat`s, and keeps getting numbers that, when printed, 
 cause an MPFR assertion failure.
 When I looked at these corrupted `BigFloat`s, I found the following 
 strings (they always started off corrupted at the location of the pointer 
 + 
 8)

 *"##po#9620\0lia_copy_3024\0"*

 *"julia_annotations_3495\0\0"*


 This corruption occurred both running on 64-bit Windows, and on Linux 
 (Centos), on Julia v0.4.5.


 Thanks in advance for any clues as to what is causing this corruption!

[julia-users] Re: How to get the particular value from the table

[Marcus Appelros]

Alternatively readdlm("file.text",',') might be sufficient.

[julia-users] Re: How to get the particular value from the table

[Marcus Appelros]

If it is in text format you can do readall("file.text") then call split (a few 
times) on the string(s)

[julia-users] Re: How to get the particular value from the table

[tannirind]

Thank you David,

Basically I want to solve a simple optimization problem for the cost of the 
grid. So I want to to to import the forecasting file(file.text) for the 
power consumption (p1,p2...p24) and the cost (c1,c2c24)of the energy 
for the 24hrs. Cost and power is different at every hour.

with this formula
@objective(m, Max, sum{p[i]*c[i], i=1:24})

Is this right approach ? or if you have any idea then please suggest me how 
can I handle this problem ? 


On Tuesday, June 7, 2016 at 7:23:00 PM UTC+2, David P. Sanders wrote:
>
>
>
> El martes, 7 de junio de 2016, 12:39:47 (UTC-4), tann...@gmail.com 
> escribió:
>>
>> According to time interval (hours) I want to access different power 
>> values 
>>
>> like sum{p[t]*c[t]}, t = 1:N
>>
>
> This should be the dot product of the two vectors,
>
> dot(p, c)
>
> But you really need to provide more information: what is p, what is c.
>
> You also did not answer my question: how do you import the data? (And what 
> format do you have it in?
>
>  
>
>>
>>
>> On Tuesday, June 7, 2016 at 5:57:16 PM UTC+2, tann...@gmail.com wrote:
>>>
>>> Hello,
>>>
>>> If I have this kind of table attached here. How can I access the 
>>> particular value to use in problem after importing in the julia. Thank you 
>>>
>>

[julia-users] remotecall_wait hangs when called on a worker under heavy CPU load

[David Parks]

The example below demonstrates `remotecall_fetch` hanging when the remote 
worker is under heavy CPU load.

It seems like the listener thread on the remote machine doesn't have high 
enough priority to ensure that the remote call interrupts the busy while 
loop. 

This is of course disastrous since the remote call is an attempt to tell 
the worker to take a break, and the worker is too busy to take heed.

*Is there anything that can be done in this case?* 
This seems very bad for distributed technical computing.

Notes: Julia v0.4.5. Workers are on remote hosts. CentOS. I didn't 
encounter this with all processes on one host (using a Windows 10 OS). This 
only happened when I transferred code that works in my local environment to 
an HPC cluster environment.

julia> workers()  # These are all 
on a remote host
12-element Array{Int64,1}:
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25

julia> @everywhere module Test
   stop_flag = false
   function runner() global stop_flag; while(!stop_flag) 
x=rand(5000,5000); end end
   function stopper() global stop_flag; stop_flag = true; end
   end
WARNING: replacing module Test

julia> r = remotecall(14, Test.runner)
RemoteRef{Channel{Any}}(14,1,148)

julia> r
RemoteRef{Channel{Any}}(14,1,148)

julia> r = remotecall_fetch(14, Test.stopper)

# Hangs here indefinitely



I attempted a fix, thinking that only 1 remote call might be allowed at a 
time, but that proved a failure as well:

julia> @everywhere module Test
   stop_flag = false
   function runner() @async(begin global stop_flag; while(!stop_flag) 
x=rand(5000,5000); end; end); println("runner running"); end
   function stopper() global stop_flag; stop_flag = true; end
   end

julia> remotecall_fetch( 2, Test.runner)

julia> remotecall_fetch(2, gethostname)

# Hangs indefinitely also

Re: [julia-users] Differential Equations Package

[Chris Rackauckas]

On my private branch I already switched all coefficients to rational so any 
precision can be used (that's where the testing with bigfloats issue comes 
up, but on the SDE side). Maybe I should push that over to master? I solved 
an entire ODE using Rational{BigInt} as a test, and got a massive rational 
number which approximated the output :).  

I must've used an older version of ODE.jl, but if they are using Array of 
arrays, that is not good for performance. Instead you want to keep it as 
one contiguous array to not slow things down (it's a few orders of 
magnitude slower than the fastest way of doing it). This is why I use the 
.. notation (EllipsisNotation.jl 
). Because you 
brought this up I'll make a blog post on the benchmarks/shootouts and how 
EllipsisNotation.jl, GrowableArrays.jl, and ChunkedArrays.jl can be used to 
improve performance. [FYI you can just throw the Array of arrays into a 
StackedArray and call copy(arr) to make it a contiguous array (thanks @Matt 
B 

).] 

I think the main thing though about improving the API will be via code 
re-writing macros. I already gathered some information on how to do it here. 
 
I 
think that for lots of variables it's much nicer to write the math/science 
names, but internally it should make them into contiguous arrays for the 
solvers, though there should then be some helper functionality so that way 
the user doesn't even have to know that.

On Tuesday, June 7, 2016 at 10:28:15 AM UTC-7, Gabriel Gellner wrote:
>
> Don't feel bad about being outed! This package is shaping up to be 
> absolutely amazing! Your work speaks for itself. I will file some issues as 
> requested.
>
> One point, to be fair about ODE.jl, does support pretty general arrays. 
> Maybe you looked at an older version? mauro3 moved heaven and earth to make 
> the solvers stupid general (maybe too general ... I still can not stand the 
> array of arrays output ... but they had lengthy discussion for why ...), I 
> think their rk-solvers are actually really neat pieces of code for 
> generality (casting the Rational tableaus into any given type etc). When I 
> look at your code you seem to be hard coding Float64 at the moment. So 
> maybe down the road we can port some of the ODE.jl code over if required.
>
> I agree that the solver api is way too matlab-y, but using their code it 
> isn't that hard to switch around, I did the same for myself in a non repo 
> package.
>
> Any one last time, your are a hero for getting this going. I am dying to 
> start using it in my own work as I love diff.eqs :) 
>
> On Tuesday, June 7, 2016 at 9:23:55 AM UTC-7, Chris Rackauckas wrote:
>>
>> There is a chance I will be adding some bifurcation analysis soon. One of 
>> the projects I'm working on may need to do a bifurcation analysis soon, and 
>> when that happens I am going to make some arclength 
>> and homotopy continuation bifurcation diagram(mers?). It will take the same 
>> ODEProblem type that the ODE solvers use, though I need some good way of 
>> specifying the bifurcation parameter(s) that would bloat the function 
>> definitions.
>>
>> I do hope that this is able to replace "most" people's needs like the 
>> general MATLAB packages. However, I dumped the idea of just working on 
>> ODE.jl for a few reasons. I think they are too close to MATLAB, and it's 
>> restricting. I'm not just talking about the naming, but a library for 
>> something like solving differential equations should really be using types 
>> to have more functionality. ode45 is limited by MATLAB having to use 
>> function handles. A problem type is much more general: you can define your 
>> SDE problem, do a bifurcation analysis, have it solve trajectories of the 
>> SDE, have it solve the Forward Kolmogorov equations for it, etc., just by 
>> passing the problem to different functions. ODE.jl also has some other 
>> limitations that stem from being basically a MATLAB re-implementation: it 
>> only works with vectors instead of arbitrary arrays, it "fixes" types to 
>> floats instead of letting you use any number implementation, it always 
>> saves every value of the trajectory, and since it doesn't handle the 
>> solutions in an arbitrary type, it does not have a way to easily add extra 
>> functionality like default plots for solutions, error / convergence 
>> calculations, etc. Since I want all of these for the research I'm doing 
>> (numerical methods for SDEs/SPDEs/SDDEs), I decided to just start clean and 
>> do it.
>>
>> If you would like to chat about naming problems, find me in the Gitter. 
>> If the community wants the names switched around to match some other 
>> convention, I'd gladly follow that convention (I just did camelCase since 
>> it's what I'm familiar wi

[julia-users] Re: Memory corruption when using BigFloats

[Pablo Zubieta]

It would help to have all the fields of the BigFloat, not only d (but also 
prec, sign and exp). I think it can be a problem with the printing 
functions, so having all that might help to figure where the problem is.

On Tuesday, June 7, 2016 at 7:26:02 PM UTC+2, Chris Rackauckas wrote:
>
> That's the main issue here. I do have a way of creating them... in a 
> private branch that I cannot share right now (give it a month?). It's not 
> easy to create them either: essentially you can solve a really stiff SDE 
> and get them, so think about repeatedly taking random numbers in a loop, 
> multiplying them by small numbers, and accumulate them. Every once in 
> awhile these may pop up, but I don't have a minimal example right now that 
> does it. It's dependent on the chosen precision, so maybe my minimal 
> examples just weren't tough enough for it.
>
>  However, I can dump the contents of the BigFloat:
>
> b = [unsafe_load(A[76].d,i) for i in 1:8]
>
> Any[0x255f4da0,0x,0x6f702323,0x32363923,0x696c0030,0x6f635f61,
> 0x335f7970,0x00343230]
>
>   Other than that, it's hard to share since if it hits the REPL in any way 
> (printing, or default displaying) it segfaults. I only found them because 
> they show up as random zeros if you try to plot an array that has them on 
> Windows (on Linux Python just throws an error). If a Julia Dev wants to 
> take a look at it in more detail I'll give them temporary access to the 
> branch.
>
>   Otherwise I'll keep this in the back of my mind and when I release this 
> part of the code I'll show exactly how bigfloats (and only bigfloats) fail 
> here, and cause a segfault. I wish I can be more open but my adviser wants 
> this code private until published, so I am sticking with it (again, 
> everything works except not sufficiently high precision bigs, so it's not 
> necessary for the paper at all).
>
> On Tuesday, June 7, 2016 at 9:58:23 AM UTC-7, Pablo Zubieta wrote:
>>
>> Do you happen to have a minimal reproducible example?
>>
>> On Tuesday, June 7, 2016 at 6:23:05 PM UTC+2, Scott Jones wrote:
>>>
>>> I've been trying to help @ChrisRackaukus (of DifferentialEquations.jl 
>>> fame!) out with a nasty bug he's been running into.
>>> He is using `BigFloat`s, and keeps getting numbers that, when printed, 
>>> cause an MPFR assertion failure.
>>> When I looked at these corrupted `BigFloat`s, I found the following 
>>> strings (they always started off corrupted at the location of the pointer + 
>>> 8)
>>>
>>> *"##po#9620\0lia_copy_3024\0"*
>>>
>>> *"julia_annotations_3495\0\0"*
>>>
>>>
>>> This corruption occurred both running on 64-bit Windows, and on Linux 
>>> (Centos), on Julia v0.4.5.
>>>
>>>
>>> Thanks in advance for any clues as to what is causing this corruption!
>>>
>>>
>>>

[julia-users] RFC: WebSocket client library

[Erik Edin]

Hello!

I made a WebSocket client package for Julia. If possible I would like 
comments and suggestions on it, and if at all possible, bug reports.
My plan is to submit this package to the official package repo, sometime 
soon.
The package is functioning, as I'm currently using it in a chat bot (see 
the back story below), and it supports WebSocket over TLS. It's not quite 
feature complete yet, but has most things.

It's available on GitHub at
https://github.com/dandeliondeathray/DandelionWebSockets.jl

I can't submit it quite yet, because this package requires a specific 
commit in Requests.jl, which hasn't made it into a release, but I expect it 
will soon. The commit added support for HTTP connection upgrades, necessary 
for the WebSocket protocol. It's already in master though, so I expect it 
will be part of the next release. If you're going to test 
DandelionWebSockets.jl, ensure that you have the commit "support for HTTP 
upgrade", with commit id f67347564dea1a20c27acec03947e74d4ff37c08, in your 
Requests.jl repo. Using the latest in master should do it.

Documentation of DandelionWebSockets.jl is still minimal. I plan to add 
more before it's properly released. No good examples are available, but 
I'll make some when I have time. It's being used in DandelionSlack.jl, but 
that's hardly a good example.

Back story:
I decided to make a chat bot in Julia, as a way of learning the language. I 
needed a WebSocket client package for the Slack package I made for the chat 
bot. I decided it was a good learning experience, both for learning Julia 
and WebSockets.

Thanks
Erik Edin

[julia-users] Re: Memory corruption when using BigFloats

[Chris Rackauckas]

That's the default precision. 

get_bigfloat_precision()

256


On Tuesday, June 7, 2016 at 11:01:05 AM UTC-7, Pablo Zubieta wrote:
>
> What is the precision of the BigFloat you wrote above?
>
> On Tuesday, June 7, 2016 at 7:26:02 PM UTC+2, Chris Rackauckas wrote:
>>
>> That's the main issue here. I do have a way of creating them... in a 
>> private branch that I cannot share right now (give it a month?). It's not 
>> easy to create them either: essentially you can solve a really stiff SDE 
>> and get them, so think about repeatedly taking random numbers in a loop, 
>> multiplying them by small numbers, and accumulate them. Every once in 
>> awhile these may pop up, but I don't have a minimal example right now that 
>> does it. It's dependent on the chosen precision, so maybe my minimal 
>> examples just weren't tough enough for it.
>>
>>  However, I can dump the contents of the BigFloat:
>>
>> b = [unsafe_load(A[76].d,i) for i in 1:8]
>>
>> Any[0x255f4da0,0x,0x6f702323,0x32363923,0x696c0030,0x6f635f61,
>> 0x335f7970,0x00343230]
>>
>>   Other than that, it's hard to share since if it hits the REPL in any 
>> way (printing, or default displaying) it segfaults. I only found them 
>> because they show up as random zeros if you try to plot an array that has 
>> them on Windows (on Linux Python just throws an error). If a Julia Dev 
>> wants to take a look at it in more detail I'll give them temporary access 
>> to the branch.
>>
>>   Otherwise I'll keep this in the back of my mind and when I release this 
>> part of the code I'll show exactly how bigfloats (and only bigfloats) fail 
>> here, and cause a segfault. I wish I can be more open but my adviser wants 
>> this code private until published, so I am sticking with it (again, 
>> everything works except not sufficiently high precision bigs, so it's not 
>> necessary for the paper at all).
>>
>> On Tuesday, June 7, 2016 at 9:58:23 AM UTC-7, Pablo Zubieta wrote:
>>>
>>> Do you happen to have a minimal reproducible example?
>>>
>>> On Tuesday, June 7, 2016 at 6:23:05 PM UTC+2, Scott Jones wrote:

 I've been trying to help @ChrisRackaukus (of DifferentialEquations.jl 
 fame!) out with a nasty bug he's been running into.
 He is using `BigFloat`s, and keeps getting numbers that, when printed, 
 cause an MPFR assertion failure.
 When I looked at these corrupted `BigFloat`s, I found the following 
 strings (they always started off corrupted at the location of the pointer 
 + 
 8)

 *"##po#9620\0lia_copy_3024\0"*

 *"julia_annotations_3495\0\0"*


 This corruption occurred both running on 64-bit Windows, and on Linux 
 (Centos), on Julia v0.4.5.


 Thanks in advance for any clues as to what is causing this corruption!

[julia-users] Re: Memory corruption when using BigFloats

[Pablo Zubieta]

What is the precision of the BigFloat you wrote above?

On Tuesday, June 7, 2016 at 7:26:02 PM UTC+2, Chris Rackauckas wrote:
>
> That's the main issue here. I do have a way of creating them... in a 
> private branch that I cannot share right now (give it a month?). It's not 
> easy to create them either: essentially you can solve a really stiff SDE 
> and get them, so think about repeatedly taking random numbers in a loop, 
> multiplying them by small numbers, and accumulate them. Every once in 
> awhile these may pop up, but I don't have a minimal example right now that 
> does it. It's dependent on the chosen precision, so maybe my minimal 
> examples just weren't tough enough for it.
>
>  However, I can dump the contents of the BigFloat:
>
> b = [unsafe_load(A[76].d,i) for i in 1:8]
>
> Any[0x255f4da0,0x,0x6f702323,0x32363923,0x696c0030,0x6f635f61,
> 0x335f7970,0x00343230]
>
>   Other than that, it's hard to share since if it hits the REPL in any way 
> (printing, or default displaying) it segfaults. I only found them because 
> they show up as random zeros if you try to plot an array that has them on 
> Windows (on Linux Python just throws an error). If a Julia Dev wants to 
> take a look at it in more detail I'll give them temporary access to the 
> branch.
>
>   Otherwise I'll keep this in the back of my mind and when I release this 
> part of the code I'll show exactly how bigfloats (and only bigfloats) fail 
> here, and cause a segfault. I wish I can be more open but my adviser wants 
> this code private until published, so I am sticking with it (again, 
> everything works except not sufficiently high precision bigs, so it's not 
> necessary for the paper at all).
>
> On Tuesday, June 7, 2016 at 9:58:23 AM UTC-7, Pablo Zubieta wrote:
>>
>> Do you happen to have a minimal reproducible example?
>>
>> On Tuesday, June 7, 2016 at 6:23:05 PM UTC+2, Scott Jones wrote:
>>>
>>> I've been trying to help @ChrisRackaukus (of DifferentialEquations.jl 
>>> fame!) out with a nasty bug he's been running into.
>>> He is using `BigFloat`s, and keeps getting numbers that, when printed, 
>>> cause an MPFR assertion failure.
>>> When I looked at these corrupted `BigFloat`s, I found the following 
>>> strings (they always started off corrupted at the location of the pointer + 
>>> 8)
>>>
>>> *"##po#9620\0lia_copy_3024\0"*
>>>
>>> *"julia_annotations_3495\0\0"*
>>>
>>>
>>> This corruption occurred both running on 64-bit Windows, and on Linux 
>>> (Centos), on Julia v0.4.5.
>>>
>>>
>>> Thanks in advance for any clues as to what is causing this corruption!
>>>
>>>
>>>

[julia-users] Re: Memory corruption when using BigFloats

[Scott Jones]

Since this is a case of memory corruption, I had hoped that somebody (one 
of the core developers?) would recognize the code that creates strings like 
"julia_annotations_" or "julia_copy_", or "##po#".
Knowing that, we might be able to better figure out how the memory might 
have been incorrectly freed (and then reallocated), or for something to 
store something to a location it doesn't really own.

Scott

On Tuesday, June 7, 2016 at 12:58:23 PM UTC-4, Pablo Zubieta wrote:
>
> Do you happen to have a minimal reproducible example?
>
> On Tuesday, June 7, 2016 at 6:23:05 PM UTC+2, Scott Jones wrote:
>>
>> I've been trying to help @ChrisRackaukus (of DifferentialEquations.jl 
>> fame!) out with a nasty bug he's been running into.
>> He is using `BigFloat`s, and keeps getting numbers that, when printed, 
>> cause an MPFR assertion failure.
>> When I looked at these corrupted `BigFloat`s, I found the following 
>> strings (they always started off corrupted at the location of the pointer + 
>> 8)
>>
>> *"##po#9620\0lia_copy_3024\0"*
>>
>> *"julia_annotations_3495\0\0"*
>>
>>
>> This corruption occurred both running on 64-bit Windows, and on Linux 
>> (Centos), on Julia v0.4.5.
>>
>>
>> Thanks in advance for any clues as to what is causing this corruption!
>>
>>
>>

Re: [julia-users] Differential Equations Package

[Gabriel Gellner]

Don't feel bad about being outed! This package is shaping up to be 
absolutely amazing! Your work speaks for itself. I will file some issues as 
requested.

One point, to be fair about ODE.jl, does support pretty general arrays. 
Maybe you looked at an older version? mauro3 moved heaven and earth to make 
the solvers stupid general (maybe too general ... I still can not stand the 
array of arrays output ... but they had lengthy discussion for why ...), I 
think their rk-solvers are actually really neat pieces of code for 
generality (casting the Rational tableaus into any given type etc). When I 
look at your code you seem to be hard coding Float64 at the moment. So 
maybe down the road we can port some of the ODE.jl code over if required.

I agree that the solver api is way too matlab-y, but using their code it 
isn't that hard to switch around, I did the same for myself in a non repo 
package.

Any one last time, your are a hero for getting this going. I am dying to 
start using it in my own work as I love diff.eqs :) 

On Tuesday, June 7, 2016 at 9:23:55 AM UTC-7, Chris Rackauckas wrote:
>
> There is a chance I will be adding some bifurcation analysis soon. One of 
> the projects I'm working on may need to do a bifurcation analysis soon, and 
> when that happens I am going to make some arclength 
> and homotopy continuation bifurcation diagram(mers?). It will take the same 
> ODEProblem type that the ODE solvers use, though I need some good way of 
> specifying the bifurcation parameter(s) that would bloat the function 
> definitions.
>
> I do hope that this is able to replace "most" people's needs like the 
> general MATLAB packages. However, I dumped the idea of just working on 
> ODE.jl for a few reasons. I think they are too close to MATLAB, and it's 
> restricting. I'm not just talking about the naming, but a library for 
> something like solving differential equations should really be using types 
> to have more functionality. ode45 is limited by MATLAB having to use 
> function handles. A problem type is much more general: you can define your 
> SDE problem, do a bifurcation analysis, have it solve trajectories of the 
> SDE, have it solve the Forward Kolmogorov equations for it, etc., just by 
> passing the problem to different functions. ODE.jl also has some other 
> limitations that stem from being basically a MATLAB re-implementation: it 
> only works with vectors instead of arbitrary arrays, it "fixes" types to 
> floats instead of letting you use any number implementation, it always 
> saves every value of the trajectory, and since it doesn't handle the 
> solutions in an arbitrary type, it does not have a way to easily add extra 
> functionality like default plots for solutions, error / convergence 
> calculations, etc. Since I want all of these for the research I'm doing 
> (numerical methods for SDEs/SPDEs/SDDEs), I decided to just start clean and 
> do it.
>
> If you would like to chat about naming problems, find me in the Gitter. If 
> the community wants the names switched around to match some other 
> convention, I'd gladly follow that convention (I just did camelCase since 
> it's what I'm familiar with). The only thing that I am shutting down are 
> requests to make things more like MATLAB that are based on MATLAB's 
> non-capabilities. That doesn't mean I don't want to make it easy for 
> MATLAB-users (maybe I should add in the documentation or tutorial that it 
> by default uses Dormand-Prince == ode45). 
>
> Also, feel free to open up issues with feature requests / naming changes / 
> extra documentation. Remember the package is less than a month old so it 
> does not implement even close to what I am aiming for, and issues will help 
> prioritize the work. I am currently finishing up some parts for 
> higher-order SDEs since I am giving a presentation in Barcelona on them at 
> the end of June, but after that I am going to keep implementing more 
> solvers. When the paper that's associated with it is published, the 
> presentation is done, and Plots.jl tags its new version, I will make sure 
> the documentation is up to date and do a v0.1 release sometime in July.
>
> I was hoping to do a big v0.1 release where I'd announce to julia-users 
> with explanation of scope, some tutorials on my blog (you can see some 
> extra example animations already in /src/examples) and better 
> documentation, but I guess this is how things go.
>
> On Tuesday, June 7, 2016 at 6:43:23 AM UTC-7, Gabriel Gellner wrote:
>>
>> I think the name makes a tonne of sense given the scope, and fits in the 
>> line with many standard packages: Calculus, Optim, Distributions, etc.
>> There is no reason that if a great Bifurcation suite grows it couldn't be 
>> part of DifferentialEquations (though that feels weird to me personally).
>>
>> Also I for one feel we should all be stupid thankful that someone is 
>> pushing on this issue. I find diffeq solvers are one of the weakest areas 
>> of Julia currently. Gr

[julia-users] Re: Memory corruption when using BigFloats

[Chris Rackauckas]

That's the main issue here. I do have a way of creating them... in a 
private branch that I cannot share right now (give it a month?). It's not 
easy to create them either: essentially you can solve a really stiff SDE 
and get them, so think about repeatedly taking random numbers in a loop, 
multiplying them by small numbers, and accumulate them. Every once in 
awhile these may pop up, but I don't have a minimal example right now that 
does it. It's dependent on the chosen precision, so maybe my minimal 
examples just weren't tough enough for it.

 However, I can dump the contents of the BigFloat:

b = [unsafe_load(A[76].d,i) for i in 1:8]

Any[0x255f4da0,0x,0x6f702323,0x32363923,0x696c0030,0x6f635f61,
0x335f7970,0x00343230]

  Other than that, it's hard to share since if it hits the REPL in any way 
(printing, or default displaying) it segfaults. I only found them because 
they show up as random zeros if you try to plot an array that has them on 
Windows (on Linux Python just throws an error). If a Julia Dev wants to 
take a look at it in more detail I'll give them temporary access to the 
branch.

  Otherwise I'll keep this in the back of my mind and when I release this 
part of the code I'll show exactly how bigfloats (and only bigfloats) fail 
here, and cause a segfault. I wish I can be more open but my adviser wants 
this code private until published, so I am sticking with it (again, 
everything works except not sufficiently high precision bigs, so it's not 
necessary for the paper at all).

On Tuesday, June 7, 2016 at 9:58:23 AM UTC-7, Pablo Zubieta wrote:
>
> Do you happen to have a minimal reproducible example?
>
> On Tuesday, June 7, 2016 at 6:23:05 PM UTC+2, Scott Jones wrote:
>>
>> I've been trying to help @ChrisRackaukus (of DifferentialEquations.jl 
>> fame!) out with a nasty bug he's been running into.
>> He is using `BigFloat`s, and keeps getting numbers that, when printed, 
>> cause an MPFR assertion failure.
>> When I looked at these corrupted `BigFloat`s, I found the following 
>> strings (they always started off corrupted at the location of the pointer + 
>> 8)
>>
>> *"##po#9620\0lia_copy_3024\0"*
>>
>> *"julia_annotations_3495\0\0"*
>>
>>
>> This corruption occurred both running on 64-bit Windows, and on Linux 
>> (Centos), on Julia v0.4.5.
>>
>>
>> Thanks in advance for any clues as to what is causing this corruption!
>>
>>
>>

[julia-users] Re: How to get the particular value from the table

[David P. Sanders]

El martes, 7 de junio de 2016, 12:39:47 (UTC-4), tann...@gmail.com escribió:
>
> According to time interval (hours) I want to access different power values 
>
> like sum{p[t]*c[t]}, t = 1:N
>

This should be the dot product of the two vectors,

dot(p, c)

But you really need to provide more information: what is p, what is c.

You also did not answer my question: how do you import the data? (And what 
format do you have it in?

 

>
>
> On Tuesday, June 7, 2016 at 5:57:16 PM UTC+2, tann...@gmail.com wrote:
>>
>> Hello,
>>
>> If I have this kind of table attached here. How can I access the 
>> particular value to use in problem after importing in the julia. Thank you 
>>
>

Re: [julia-users] Re: Julia Plugins

[Uwe Fechner]

You wrote:
> if I've understood your suggestions, I must create a directory structure 
> for each module ('src' dir under a dir with same name than module), but 
> I should load a single file without constraint on dirs > 
No, you do not need any directory structure. The only requirement is, that
the directory of the module, that you want to load (it can be a single 
file) is in you
load path.

Once you have loaded this module, you can use anything, that is defined
within it (and exported).

Uwe

[julia-users] Re: Memory corruption when using BigFloats

[Pablo Zubieta]

Do you happen to have a minimal reproducible example?

On Tuesday, June 7, 2016 at 6:23:05 PM UTC+2, Scott Jones wrote:
>
> I've been trying to help @ChrisRackaukus (of DifferentialEquations.jl 
> fame!) out with a nasty bug he's been running into.
> He is using `BigFloat`s, and keeps getting numbers that, when printed, 
> cause an MPFR assertion failure.
> When I looked at these corrupted `BigFloat`s, I found the following 
> strings (they always started off corrupted at the location of the pointer + 
> 8)
>
> *"##po#9620\0lia_copy_3024\0"*
>
> *"julia_annotations_3495\0\0"*
>
>
> This corruption occurred both running on 64-bit Windows, and on Linux 
> (Centos), on Julia v0.4.5.
>
>
> Thanks in advance for any clues as to what is causing this corruption!
>
>
>

[julia-users] Re: How to get the particular value from the table

[tannirind]

According to time interval (hours) I want to access different power values 

like sum{p[t]*c[t]}, t = 1:N


On Tuesday, June 7, 2016 at 5:57:16 PM UTC+2, tann...@gmail.com wrote:
>
> Hello,
>
> If I have this kind of table attached here. How can I access the 
> particular value to use in problem after importing in the julia. Thank you 
>

Re: [julia-users] Differential Equations Package

[Chris Rackauckas]

There is a chance I will be adding some bifurcation analysis soon. One of 
the projects I'm working on may need to do a bifurcation analysis soon, and 
when that happens I am going to make some arclength 
and homotopy continuation bifurcation diagram(mers?). It will take the same 
ODEProblem type that the ODE solvers use, though I need some good way of 
specifying the bifurcation parameter(s) that would bloat the function 
definitions.

I do hope that this is able to replace "most" people's needs like the 
general MATLAB packages. However, I dumped the idea of just working on 
ODE.jl for a few reasons. I think they are too close to MATLAB, and it's 
restricting. I'm not just talking about the naming, but a library for 
something like solving differential equations should really be using types 
to have more functionality. ode45 is limited by MATLAB having to use 
function handles. A problem type is much more general: you can define your 
SDE problem, do a bifurcation analysis, have it solve trajectories of the 
SDE, have it solve the Forward Kolmogorov equations for it, etc., just by 
passing the problem to different functions. ODE.jl also has some other 
limitations that stem from being basically a MATLAB re-implementation: it 
only works with vectors instead of arbitrary arrays, it "fixes" types to 
floats instead of letting you use any number implementation, it always 
saves every value of the trajectory, and since it doesn't handle the 
solutions in an arbitrary type, it does not have a way to easily add extra 
functionality like default plots for solutions, error / convergence 
calculations, etc. Since I want all of these for the research I'm doing 
(numerical methods for SDEs/SPDEs/SDDEs), I decided to just start clean and 
do it.

If you would like to chat about naming problems, find me in the Gitter. If 
the community wants the names switched around to match some other 
convention, I'd gladly follow that convention (I just did camelCase since 
it's what I'm familiar with). The only thing that I am shutting down are 
requests to make things more like MATLAB that are based on MATLAB's 
non-capabilities. That doesn't mean I don't want to make it easy for 
MATLAB-users (maybe I should add in the documentation or tutorial that it 
by default uses Dormand-Prince == ode45). 

Also, feel free to open up issues with feature requests / naming changes / 
extra documentation. Remember the package is less than a month old so it 
does not implement even close to what I am aiming for, and issues will help 
prioritize the work. I am currently finishing up some parts for 
higher-order SDEs since I am giving a presentation in Barcelona on them at 
the end of June, but after that I am going to keep implementing more 
solvers. When the paper that's associated with it is published, the 
presentation is done, and Plots.jl tags its new version, I will make sure 
the documentation is up to date and do a v0.1 release sometime in July.

I was hoping to do a big v0.1 release where I'd announce to julia-users 
with explanation of scope, some tutorials on my blog (you can see some 
extra example animations already in /src/examples) and better 
documentation, but I guess this is how things go.

On Tuesday, June 7, 2016 at 6:43:23 AM UTC-7, Gabriel Gellner wrote:
>
> I think the name makes a tonne of sense given the scope, and fits in the 
> line with many standard packages: Calculus, Optim, Distributions, etc.
> There is no reason that if a great Bifurcation suite grows it couldn't be 
> part of DifferentialEquations (though that feels weird to me personally).
>
> Also I for one feel we should all be stupid thankful that someone is 
> pushing on this issue. I find diffeq solvers are one of the weakest areas 
> of Julia currently. Graphs, Stats, Optimization all feel at a level that is 
> very comfortable to replace general packages like Matlab for me (at a first 
> approximation) but man solving these kinds of equations in julia feels 
> barely passible. It is a herculean task to get this support in and Chris 
> seems to be doing it with crazy determination. He could call the pacakge 
> the OneTrueSolutionToSolvingEverything and I would support it!
>
> It will kill me that it will be camelCase mind you ... Julia needs a PEP8 
> linter bad ;)
>
> On Tuesday, June 7, 2016 at 1:48:51 AM UTC-7, jonatha...@alumni.epfl.ch 
> wrote:
>>
>> Your package is about computing numerical solutions of differential 
>> equations. Differential equations are something a bit more general, for 
>> example a package for bifurcation analysis could also want to call itself 
>> "DifferentialEquations". I don't really have a better name... 
>> NSolveDiffEqus ? That said I don't think you really need to rename it.
>>
>

[julia-users] Memory corruption when using BigFloats

[Scott Jones]

I've been trying to help @ChrisRackaukus (of DifferentialEquations.jl 
fame!) out with a nasty bug he's been running into.
He is using `BigFloat`s, and keeps getting numbers that, when printed, 
cause an MPFR assertion failure.
When I looked at these corrupted `BigFloat`s, I found the following strings 
(they always started off corrupted at the location of the pointer + 8)

*"##po#9620\0lia_copy_3024\0"*

*"julia_annotations_3495\0\0"*


This corruption occurred both running on 64-bit Windows, and on Linux 
(Centos), on Julia v0.4.5.


Thanks in advance for any clues as to what is causing this corruption!

[julia-users] Re: How to get the particular value from the table

[David P. Sanders]

El martes, 7 de junio de 2016, 11:57:16 (UTC-4), tann...@gmail.com escribió:
>
> Hello,
>
> If I have this kind of table attached here. How can I access the 
> particular value to use in problem after importing in the julia. Thank you 
>


How do you import the data into Julia? 

Re: [julia-users] How do I find out which package is causing problems running Pkg.update()

[Michael Krabbe Borregaard]

Thanks! After a bit if experimenting I could Pkg.checkout("Atom",
"julia-0.4"), which solved the issue.

Re: [julia-users] Re: Calling Fortran code?

[Paulo Jabardo]

I haven't done this often but when I did I looked at how it is done in the 
lapack and blas interfaces. There are several examples

https://github.com/JuliaLang/julia/blob/master/base/linalg/blas.jl

https://github.com/JuliaLang/julia/blob/master/base/linalg/lapack.jl


Paulo

On Monday, June 6, 2016 at 9:16:27 PM UTC-3, Charles Ll wrote:
>
> Dear all,
>
> Thank you very much for you help! I've been able to write a form of gcvspl 
> that seems to run, with calling:
>
> ccall( (:gcvspl_, "./libgcvspl.so"), Void, 
> (Ptr{Float64},Ptr{Float64},Ptr{Cint},Ptr{Float64},Ptr{Float64},Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Float64},Ptr{Float64},Ptr{Cint},Ptr{Float64},Ptr{Cint}),x,y,&NN,wx,wy,&M,&N,&K,&MD,VAL,c,&NC,WK,IER)
>
>
> However, when I try to call the c or IER variables, the Julia kernel 
> dies... :s
>
> Do you have any idea why? What am I missing?
>
> Furthermore, dear Erik, what do you mean by using 'Ref' for one-element 
> arrays?
>
> Thanks in advance!
>
> Best,
> Charles.
>
> Le lundi 6 juin 2016 22:12:32 UTC+10, Erik Schnetter a écrit :
>>
>> I would use `Cint` as type, not `Int64`, as in `Ptr{Cint}`. Are you sure 
>> that your Fortran code uses 64-bit integers? Technically, this violates the 
>> Fortran standard. A Fortran integer is the same as a C int, except if you 
>> use special flags while building the Fortran library (which you might be 
>> doing).
>>
>> You can use `Ref` instead of one-element arrays.
>>
>> Your error message has nothing to do with arrays vs. pointer, but rather 
>> the mismatch between `Float64` and `Int64`.
>>
>> -erik
>>
>>
>> On Mon, Jun 6, 2016 at 6:07 AM, Páll Haraldsson  
>> wrote:
>>
>>> On Monday, June 6, 2016 at 3:22:47 AM UTC, Charles Ll wrote:

 Dear all,

 I am trying to call some Fortran code in Julia, but I have a hard time 
 doing so... I have read the docs, looked at the wrapping of ARPACK and 
 other libraries... But I did not find any way to make it work.

 I am trying to wrap a spline function library (gcvspl.f, 
 https://github.com/charlesll/Spectra.jl/tree/master/Dependencies), 
 which I want to use in my project, Spectra.jl.

 I already have a wrapper in Python, but this was easier to wrap with 
 using f2py. In Julia, I understand that I have to do it properly. The 
 function I am trying to call is:

>>>
>>> I think, you may already have gotten the correct answer. At first I was 
>>> expecting fcall, not just ccall keyword in Julia, to call Fortran.. It's 
>>> not strictly needed, but in fact, there is an issue somewhere still open 
>>> about fcall (keyword, or was if for a function?), and it may have been for 
>>> your situation..
>>>
>>>
>>> [It might not be too helpful to know, you can call Python with 
>>> PyCall.jl, so if you've already wrapped in Python..]
>>>
>>> -- 
>>> Palli.
>>>
>>>
>>>
>>
>>
>> -- 
>> Erik Schnetter  
>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>
>

[julia-users] Error when embedding julia in C program under Windows 7

[martin . otter]

 

It seems not possible to call Julia from a C-main program under Windows 7. 

I am aware of issues #11419 
, #15194 
. I have the following 
C-Program testc.c to perform a minimal test. testc.c is stored under \bin:


#include "julia.h"
int main(int argc, char *argv[])
{
jl_init(NULL);  
jl_eval_string("display(2.0)");
jl_atexit_hook(0);
return 0;
}


All the following is performed under Windows 7 with MSYS2 and MINGW as 
adviced in https://github.com/JuliaLang/julia/blob/master/README.windows.md.
In all experiments, I start with a fresh MSYS2 shell and execute the 
following commands:


JULIA_DIR=
JULIA_HOME=$JULIA_DIR/bin
export PATH=$JULIA_DIR/bin:$PATH
export PATH=/usr/x86_64-w64-mingw32/sys-root/mingw/bin:$PATH
cd $JULIA_DIR/bin


Executing the following command with a standard Julia 0.4.5 Windows 64 bit 
installation


gcc -I$JULIA_DIR/include/julia -L$JULIA_DIR/bin -L$JULIA_DIR/lib -ljulia 
-lopenlibm testc.c -o testc


is successful. Executing the generated testc.exe gives the following error:


Please submit a bug report with steps to reproduce this fault, and any error 
messages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION at 0x0 -- unknown function (ip: 
)
unknown function (ip: )


Running Julia 0.5.0-dev:


Julia Version 0.5.0-dev+4536
Commit 44d778a (2016-06-05 01:30 UTC)
Platform Info:
  System: NT (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7-4800MQ CPU @
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, haswell)


again with


gcc -I$JULIA_DIR/include/julia -L$JULIA_DIR/bin -L$JULIA_DIR/lib -ljulia 
-lopenlibm testc.c -o testc


is successful. Executing the generated testc.exe gives the following error:


LLVM ERROR: Program used external function 'rint' which could not be resolved!


>From #11419 , libopenlibm 
should be statically linked (especially since rint is a symbol in 
libopenlibm). Trying to generate a libopenlibm.dll.a stub library for this:


dlltool -z libopenlibm.dll.def --export-all-symbol libopenlibm.dll
dlltool -d libopenlibm.dll.def -l libopenlibm.dll.a
gcc -I$JULIA_DIR/include/julia -L$JULIA_DIR/bin -L$JULIA_DIR/lib -ljulia 
-lopenlibm testc.c -o testc


gives error messages due to multiple defintiions of


atexit, _encode_pointer, __mingw_init_ehandler, _gnu_exception_handler


Removed these symbols in libopenlibm.dll.def and running again:


dlltool -d libopenlibm.dll.def -l libopenlibm.dll.a
gcc -I$JULIA_DIR/include/julia -L$JULIA_DIR/bin -L$JULIA_DIR/lib -ljulia 
-lopenlibm testc.c -o testc


This is successful. Running the generated testc.exe gives the following 
error:


testc.exe: error while loading shared libraries:
(null): cannot open shared object file: No such file or directory
 

Either I make a mistake or Julia has a bug and it is currently not possible 
to call Julia (standard Windows distribution) from a C-program. Advice is 
appreciated

Re: [julia-users] How do I find out which package is causing problems running Pkg.update()

[Tony Kelman]

Check Pkg.status, you probably have something checked out to a master 
branch that you need to call Pkg.free on to get back to a supported release 
version.


On Tuesday, June 7, 2016 at 6:23:16 AM UTC-7, Yichao Yu wrote:
>
> On Tue, Jun 7, 2016 at 9:08 AM, Michael Krabbe Borregaard 
> > wrote: 
> > Sorry for being slow but I am not sure I understand what you suggest? 
>
> I'm not sure how you installed Atom but you need to switch to 
>
> >> the 0.4 branch or the latest tag 
>
> of Atom instead of the master branch. 
>
> > 
> > On Tue, Jun 7, 2016 at 2:38 PM, Yichao Yu  > wrote: 
> >> 
> >> On Tue, Jun 7, 2016 at 8:06 AM, Michael Borregaard 
> >> > wrote: 
> >> > Hi, 
> >> > I cannot Pkg.update(), I get the error message: 
> >> > 
> >> > ERROR: ASTInterpreter can't be installed because it has no versions 
> that 
> >> > support 0.4.5 of julia. You may need to update METADATA by running 
> >> > `Pkg.update()` 
> >> >  in error at error.jl:22 
> >> >  in resolve at 
> >> > 
> >> > 
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib 
> >> >  in update at 
> >> > 
> >> > 
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib 
> >> >  in anonymous at pkg/dir.jl:31 
> >> >  in cd at file.jl:22 
> >> >  in cd at pkg/dir.jl:31 
> >> >  in update at 
> >> > 
> >> > 
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib 
> >> > 
> >> > I do not have ASTInterpreter installed, neither do I have Gallium, 
> which 
> >> > apparently references it. I would like to know which package is 
> causing 
> >> > the 
> >> > issue, so I can create an issue on their github or uninstall it. I 
> >> > downloaded the newest stable version of julia and installed it, but 
> it 
> >> > did 
> >> > not help. 
> >> > 
> >> > The problem means that e.g. my Atom package is in an unstable state, 
> so 
> >> > I 
> >> > cannot use my normal julia workflow. Please refer me to if this 
> should 
> >> > be an 
> >> > issue somewhere else, but I guess the issue of finding out the 
> criminal 
> >> > package (that tries to install ASTInterpreter) is general enough for 
> >> > this 
> >> > mailing list. 
> >> 
> >> IIRC the Atom master doesn't support 0.4 and you need the 0.4 branch 
> >> or the latest tag. 
> >> 
> >> > 
> >> > 
> >> > Thanks a lot, 
> >> > Michael 
> > 
> > 
>

Re: [julia-users] Differential Equations Package

[Gabriel Gellner]

I think the name makes a tonne of sense given the scope, and fits in the 
line with many standard packages: Calculus, Optim, Distributions, etc.
There is no reason that if a great Bifurcation suite grows it couldn't be 
part of DifferentialEquations (though that feels weird to me personally).

Also I for one feel we should all be stupid thankful that someone is 
pushing on this issue. I find diffeq solvers are one of the weakest areas 
of Julia currently. Graphs, Stats, Optimization all feel at a level that is 
very comfortable to replace general packages like Matlab for me (at a first 
approximation) but man solving these kinds of equations in julia feels 
barely passible. It is a herculean task to get this support in and Chris 
seems to be doing it with crazy determination. He could call the pacakge 
the OneTrueSolutionToSolvingEverything and I would support it!

It will kill me that it will be camelCase mind you ... Julia needs a PEP8 
linter bad ;)

On Tuesday, June 7, 2016 at 1:48:51 AM UTC-7, jonatha...@alumni.epfl.ch 
wrote:
>
> Your package is about computing numerical solutions of differential 
> equations. Differential equations are something a bit more general, for 
> example a package for bifurcation analysis could also want to call itself 
> "DifferentialEquations". I don't really have a better name... 
> NSolveDiffEqus ? That said I don't think you really need to rename it.
>

Re: [julia-users] How do I find out which package is causing problems running Pkg.update()

[Yichao Yu]

On Tue, Jun 7, 2016 at 9:08 AM, Michael Krabbe Borregaard
 wrote:
> Sorry for being slow but I am not sure I understand what you suggest?

I'm not sure how you installed Atom but you need to switch to

>> the 0.4 branch or the latest tag

of Atom instead of the master branch.

>
> On Tue, Jun 7, 2016 at 2:38 PM, Yichao Yu  wrote:
>>
>> On Tue, Jun 7, 2016 at 8:06 AM, Michael Borregaard
>>  wrote:
>> > Hi,
>> > I cannot Pkg.update(), I get the error message:
>> >
>> > ERROR: ASTInterpreter can't be installed because it has no versions that
>> > support 0.4.5 of julia. You may need to update METADATA by running
>> > `Pkg.update()`
>> >  in error at error.jl:22
>> >  in resolve at
>> >
>> > /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
>> >  in update at
>> >
>> > /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
>> >  in anonymous at pkg/dir.jl:31
>> >  in cd at file.jl:22
>> >  in cd at pkg/dir.jl:31
>> >  in update at
>> >
>> > /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
>> >
>> > I do not have ASTInterpreter installed, neither do I have Gallium, which
>> > apparently references it. I would like to know which package is causing
>> > the
>> > issue, so I can create an issue on their github or uninstall it. I
>> > downloaded the newest stable version of julia and installed it, but it
>> > did
>> > not help.
>> >
>> > The problem means that e.g. my Atom package is in an unstable state, so
>> > I
>> > cannot use my normal julia workflow. Please refer me to if this should
>> > be an
>> > issue somewhere else, but I guess the issue of finding out the criminal
>> > package (that tries to install ASTInterpreter) is general enough for
>> > this
>> > mailing list.
>>
>> IIRC the Atom master doesn't support 0.4 and you need the 0.4 branch
>> or the latest tag.
>>
>> >
>> >
>> > Thanks a lot,
>> > Michael
>
>

Re: [julia-users] Re: Can I somehow get Julia without standard library?

[Scott Jones]

Thanks for mentioning it!  There've been so many changes recently in master 
lately, that I've let it get a bit behind, I'll try to get it back to 
keeping pace with v0.5.

I've tried to make it so that you can select which parts of Julia that you 
want in (like Sparse arrays, LinAlg, BigInt, BigFloat, Complex, Rational, 
with build flags in Make.user)

One of the hardest parts has been that a lot of the documentation is still 
stored in docs/helpdb/Base.jl, and haven't yet been moved to the files 
where the functions actually are defined.
The other problem is similar, there are a lot of unit tests where it would 
be much easier to deal with if the tests were in files corresponding to the 
source files in Base (last summer, some of the tests did get reorganized 
that way, which helped)

On Tuesday, June 7, 2016 at 4:57:38 AM UTC-4, Nils Gudat wrote:
>
> Don't know whether this is something you'd be interested in, but Scott 
> Jones has worked on building a Julia "lite" version with fewer components: 
> https://groups.google.com/forum/?fromgroups#!searchin/julia-users/raspberry$20pi/julia-users/WStpLtrKiFA/JhiAbc-vAwAJ
>

Re: [julia-users] How do I find out which package is causing problems running Pkg.update()

[Michael Krabbe Borregaard]

Sorry for being slow but I am not sure I understand what you suggest?

On Tue, Jun 7, 2016 at 2:38 PM, Yichao Yu  wrote:

> On Tue, Jun 7, 2016 at 8:06 AM, Michael Borregaard
>  wrote:
> > Hi,
> > I cannot Pkg.update(), I get the error message:
> >
> > ERROR: ASTInterpreter can't be installed because it has no versions that
> > support 0.4.5 of julia. You may need to update METADATA by running
> > `Pkg.update()`
> >  in error at error.jl:22
> >  in resolve at
> >
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
> >  in update at
> >
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
> >  in anonymous at pkg/dir.jl:31
> >  in cd at file.jl:22
> >  in cd at pkg/dir.jl:31
> >  in update at
> >
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
> >
> > I do not have ASTInterpreter installed, neither do I have Gallium, which
> > apparently references it. I would like to know which package is causing
> the
> > issue, so I can create an issue on their github or uninstall it. I
> > downloaded the newest stable version of julia and installed it, but it
> did
> > not help.
> >
> > The problem means that e.g. my Atom package is in an unstable state, so I
> > cannot use my normal julia workflow. Please refer me to if this should
> be an
> > issue somewhere else, but I guess the issue of finding out the criminal
> > package (that tries to install ASTInterpreter) is general enough for this
> > mailing list.
>
> IIRC the Atom master doesn't support 0.4 and you need the 0.4 branch
> or the latest tag.
>
> >
> >
> > Thanks a lot,
> > Michael
>

Re: [julia-users] How do I find out which package is causing problems running Pkg.update()

[Yichao Yu]

On Tue, Jun 7, 2016 at 8:06 AM, Michael Borregaard
 wrote:
> Hi,
> I cannot Pkg.update(), I get the error message:
>
> ERROR: ASTInterpreter can't be installed because it has no versions that
> support 0.4.5 of julia. You may need to update METADATA by running
> `Pkg.update()`
>  in error at error.jl:22
>  in resolve at
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
>  in update at
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
>  in anonymous at pkg/dir.jl:31
>  in cd at file.jl:22
>  in cd at pkg/dir.jl:31
>  in update at
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
>
> I do not have ASTInterpreter installed, neither do I have Gallium, which
> apparently references it. I would like to know which package is causing the
> issue, so I can create an issue on their github or uninstall it. I
> downloaded the newest stable version of julia and installed it, but it did
> not help.
>
> The problem means that e.g. my Atom package is in an unstable state, so I
> cannot use my normal julia workflow. Please refer me to if this should be an
> issue somewhere else, but I guess the issue of finding out the criminal
> package (that tries to install ASTInterpreter) is general enough for this
> mailing list.

IIRC the Atom master doesn't support 0.4 and you need the 0.4 branch
or the latest tag.

>
>
> Thanks a lot,
> Michael

[julia-users] How do I find out which package is causing problems running Pkg.update()

[Michael Borregaard]

Hi,
I cannot Pkg.update(), I get the error message:

ERROR: ASTInterpreter can't be installed because it has no versions that 
support 0.4.5 of julia. You may need to update METADATA by running 
`Pkg.update()`
 in error at error.jl:22
 in resolve at 
/Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
 in update at 
/Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
 in anonymous at pkg/dir.jl:31
 in cd at file.jl:22
 in cd at pkg/dir.jl:31
 in update at 
/Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib

I do not have ASTInterpreter installed, neither do I have Gallium, which 
apparently references it. I would like to know which package is causing the 
issue, so I can create an issue on their github or uninstall it. I 
downloaded the newest stable version of julia and installed it, but it did 
not help. 

The problem means that e.g. my Atom package is in an unstable state, so I 
cannot use my normal julia workflow. Please refer me to if this should be 
an issue somewhere else, but I guess the issue of finding out the criminal 
package (that tries to install ASTInterpreter) is general enough for this 
mailing list.


Thanks a lot,
Michael

Re: [julia-users] Re: Reconstruct a string from a Clang.jl generated looong type

[J Luis]

Just to tell that the NTuples way works beautifully, specially because we 
no longer are tied to an immutable that made the communication Julia -> C 
quite painfull.

Thanks

Joaquim

segunda-feira, 6 de Junho de 2016 às 21:09:32 UTC+1, Steven G. Johnson 
escreveu:
>
> On Monday, June 6, 2016 at 1:11:53 PM UTC-4, Milan Bouchet-Valat wrote:
>>
>> > tuples yes, but when I search for ``NTuples`` in the docs there is 
>> > barely any hit and all that come show it being used as a type 
>> > dfinition but found no mention of what it is. Yes, a ``ntuple`` 
>> > function is documented but I guess it's not the same thing. 
>> The codes could be improved, but basically NTuple is a standard tuple 
>> with all elements being of the same type: 
>
>
> https://github.com/JuliaLang/julia/pull/16791 
>

Re: [julia-users] Re: Using Julia for real time astronomy

[John leger]

Hi Islam,

I like the definition of 95% hard real time; it suits my needs. Thanks for 
this good paper.

Le lundi 6 juin 2016 18:45:35 UTC+2, Islam Badreldin a écrit :
>
> Hi John,
>
> I am currently pursuing similar effort. I got a GPIO pin on the BeagleBone 
> Black embedded board toggling in hard real-time and verified the jitter 
> with an oscilloscope. For that, I used a vanilla Linux 4.4.11 kernel with 
> the PREEMPT_RT patch applied. I also released an initial version of a Julia 
> package that wraps the clock_nanosleep() and clock_gettime() functions from 
> the POSIX real-time extensions. Please see this other thread:
> https://groups.google.com/forum/#!topic/julia-users/0Vr2rCRwJY4
>
> I tested that package both on Intel-based laptop and on the BeagleBone 
> Black. I am giving some of the relevant details below..
>
> On Monday, June 6, 2016 at 5:41:29 AM UTC-4, John leger wrote:
>>
>> Since it seems you have a good overview in this domain I will give more 
>> details:
>> We are working in signal processing and especially in image processing. 
>> The goal here is just the adaptive optic: we just want to stabilize the 
>> image and not get the final image.
>> The consequence is that we will not store anything on the hard drive: we 
>> read an image, process it and destroy it. We stay in RAM all the time.
>> The processing is done by using/coding our algorithms. So for now, no 
>> need of any external library (for now, but I don't see any reason for that 
>> now)
>>
>> First I would like to apologize: just after posting my answer I went to 
>> wikipedia to search the difference between soft and real time. 
>> I should have done it before so that you don't have to spend more time to 
>> explain.
>>
>> In the end I still don't know if I am hard real time or soft real time: 
>> the timing is given by the camera speed and the processing should be done 
>> between the acquisition of two images.
>> We don't want to miss an image or delay the processing, I still need to 
>> clarify the consequences of a delay or if we miss an image.
>> For now let's just say that we can miss some images so we want soft real 
>> time.
>>
>
> The real-time performance you are after could be 95% hard real-time. See 
> e.g. here: https://www.osadl.org/fileadmin/dam/rtlws/12/Brown.pdf
>  
>
>>
>> I'm making a benchmark that should match the system in term of 
>> complexity, these are my first remarks:
>>
>> When you say that one allocation is unacceptable, I say it's shockingly 
>> true: In my case I had 2 allocations done by:
>> A +=1 where A is an array
>> and in 7 seconds I had 600k allocations. 
>> Morality :In closed loop you cannot accept any alloc and so you have to 
>> explicit all loops.
>>
>
> Yes, try to completely avoid memory allocations while developing your own 
> algorithms in Julia. Pre-allocations and in-place operations are your 
> friends! The example script available on the POSIXClock package is one way 
> to do this (
> https://github.com/ibadr/POSIXClock.jl/blob/master/examples/rt_histogram.jl). 
> The real-time section of the code is marked by a ccall to mlockall() in 
> order to cause immediate failure upon memory allocations in the real-time 
> section. You can also use the --track-allocation option to hunt down 
> memory allocations while developing your algorithm. See e.g. 
> http://docs.julialang.org/en/release-0.4/manual/profile/#man-track-allocation
>  
>

I discovered --track-allocation not so long ago and it is a good tool. For 
now I think I will rely on tracking allocation manually. I am a little 
afraid of using mlockall(): In soft or real time crashing (failure) is not 
a good option for me...
Since you are talking about --track-allocation I have a question:


- function deflat(v::globalVar)
0 @simd for i in 1:v.len_sub
0 @inbounds v.sub_imagef[i] = v.flat[i]*v.image[i]
- end
- 
0 @simd for i in 1:v.len_ref
0 @inbounds v.ref_imagef[i] = v.flat[i]*v.image[i]
- end
0 return
- end
- 
- # get min max
- # apply norm_coef
- # MORE TO DO HERE
- function normalization(v::globalVar)
0 min::Float32 = Float32(4095)
0 max::Float32 = Float32(0)
0 tmp::Float32 = Float32(0)
0 norm_fact::Float32 = Float32(0)
0 norm_coef::Float32 = Float32(0)
- # find min max
0 @simd for i in 1:v.nb_mat
0 # Doing something with no allocs
0 end
0 end
0 
  1226415 # SAD[70] 16x16 de Ref_Image sur Sub_Image[60]
- function correlation_SAD(v::globalVar)
0 
- end
- 

In the mem output file I have this information: at the end of normalization 
I have no alloc and in front of the SAD comment and before the em

Re: [julia-users] Re: Can I somehow get Julia without standard library?

[Nils Gudat]

Don't know whether this is something you'd be interested in, but Scott 
Jones has worked on building a Julia "lite" version with fewer 
components: 
https://groups.google.com/forum/?fromgroups#!searchin/julia-users/raspberry$20pi/julia-users/WStpLtrKiFA/JhiAbc-vAwAJ

Re: [julia-users] Differential Equations Package

[jonathan . bieler]

Your package is about computing numerical solutions of differential 
equations. Differential equations are something a bit more general, for 
example a package for bifurcation analysis could also want to call itself 
"DifferentialEquations". I don't really have a better name... 
NSolveDiffEqus ? That said I don't think you really need to rename it.

[julia-users] Compose.jl animation

[Ford O.]

I was trying to follow the steps from reactive 
 simple 
animation tutorial, but no window with the ball image pops up ( I have done 
it from REPL on my personal computer on windows 8).