[julia-users] Re: Julia nightlies

[Tony Kelman]

The generic Linux binaries 
from https://status.julialang.org/download/linux-x86_64 are usually kept a 
little more up to date, the buildbots repsonsible for those aren't quite as 
picky as the Launchpad setup on Ubuntu's servers.

Travis can be fixed by switching to the more recent "language: julia" 
template, which uses the generic Linux binaries rather than the Ubuntu PPA.


On Tuesday, August 18, 2015 at 7:39:56 PM UTC-7, Yakir Gagnon wrote:
>
> OK, I'm gonna git pull & make then. That's the only way, right?
>
> On Wednesday, August 19, 2015 at 4:54:05 AM UTC+10, Uwe Fechner wrote:
>>
>> Well, removing the link from the website does not help with the travis 
>> failures:
>> https://travis-ci.org/mlubin/NaNMath.jl/jobs/76114115
>>
>> Regards: Uwe
>>
>> Am Dienstag, 18. August 2015 18:46:31 UTC+2 schrieb Viral Shah:
>>>
>>> Elliot has been busy lately, and this has not been maintained for a long 
>>> time. We should probably remove that link from our website.
>>>
>>> -viral
>>>
>>> On Tuesday, August 18, 2015 at 9:52:17 PM UTC+5:30, Uwe Fechner wrote:

 Hello,

 the nightly Julia builds from:
 https://launchpad.net/~staticfloat/+archive/ubuntu/julianightlies

 are currently quiet outdated.

 As far as I understand they should be auto-generated every night from 
 the head
 branch of the Julia repository.

 This seams to be currently broken.

 Any idea, why?

 The outdated version is causing problems with failing checks of Travis.

 Best regards:

 Uwe

>>>

[julia-users] Re: Julia installer does not put METADATA in user home

[Kevin Kunzmann]

Saved my day, thanks!

On Wednesday, 19 August 2015 08:26:57 UTC+2, Tony Kelman wrote:
>
> You may need to delete User\.julia and try Pkg.init() again.
>
>
> On Tuesday, August 18, 2015 at 10:33:21 PM UTC-7, Kevin Kunzmann wrote:
>>
>> Hi,
>>
>> I was just trying to use Juno + Julia prebundled package on a seecond 
>> machine (Win 8). It always complains about being not able to establish a 
>> connection.
>> So I tried to install pure Julia first. That works fine and I can start a 
>> Julia session in the command line. However, when I want to update the 
>> METADATA it complains about not finding it. Indeed User\.julia\v0.3 is 
>> empty!
>> How can I set up the correct METADATA structure manually?
>>
>> Best,
>>
>> Kevin
>>
>> Here is my error
>> julia> Pkg.update()
>> INFO: Updating METADATA...
>> ERROR: chdir METADATA: no such file or
>>  in cd at file.jl:11 (repeats 2 times)
>>
>>
>>

[julia-users] Re: Julia installer does not put METADATA in user home

[Tony Kelman]

You may need to delete User\.julia and try Pkg.init() again.


On Tuesday, August 18, 2015 at 10:33:21 PM UTC-7, Kevin Kunzmann wrote:
>
> Hi,
>
> I was just trying to use Juno + Julia prebundled package on a seecond 
> machine (Win 8). It always complains about being not able to establish a 
> connection.
> So I tried to install pure Julia first. That works fine and I can start a 
> Julia session in the command line. However, when I want to update the 
> METADATA it complains about not finding it. Indeed User\.julia\v0.3 is 
> empty!
> How can I set up the correct METADATA structure manually?
>
> Best,
>
> Kevin
>
> Here is my error
> julia> Pkg.update()
> INFO: Updating METADATA...
> ERROR: chdir METADATA: no such file or
>  in cd at file.jl:11 (repeats 2 times)
>
>
>

[julia-users] Julia installer does not put METADATA in user home

[Kevin Kunzmann]

Hi,

I was just trying to use Juno + Julia prebundled package on a seecond 
machine (Win 8). It always complains about being not able to establish a 
connection.
So I tried to install pure Julia first. That works fine and I can start a 
Julia session in the command line. However, when I want to update the 
METADATA it complains about not finding it. Indeed User\.julia\v0.3 is 
empty!
How can I set up the correct METADATA structure manually?

Best,

Kevin

Here is my error
julia> Pkg.update()
INFO: Updating METADATA...
ERROR: chdir METADATA: no such file or
 in cd at file.jl:11 (repeats 2 times)

[julia-users] Re: Removing the 'DIVIDES' (U+2223) from the inside of a character string

[elextr]

On Wednesday, August 19, 2015 at 1:59:13 PM UTC+10, Lauren Kersey wrote:
>
> Hi all. I have a text tool that removes punctuation from the ends of words 
> (split). This seemed to work well enough for cleaning my corpus, but I'm 
> now working with a dataset of texts published from 1600-1700. Back then, 
> printers split a lot of lines in the middle of a word. When the printer 
> came to the end of the page, he simply split the word with a hyphen. My 
> digital copies mark this symbol as a "\u2223" and I need to remove this 
> from the word to perform computational analysis. 
>
> Is there a way to remove this character from the inside of a character 
> string? 
>

Just replace it with an empty 
string 
http://docs.julialang.org/en/latest/stdlib/strings/?highlight=replace#Base.replace

Cheers
Lex

[julia-users] Removing the 'DIVIDES' (U+2223) from the inside of a character string

[Lauren Kersey]

Hi all. I have a text tool that removes punctuation from the ends of words 
(split). This seemed to work well enough for cleaning my corpus, but I'm 
now working with a dataset of texts published from 1600-1700. Back then, 
printers split a lot of lines in the middle of a word. When the printer 
came to the end of the page, he simply split the word with a hyphen. My 
digital copies mark this symbol as a "\u2223" and I need to remove this 
from the word to perform computational analysis. 

Is there a way to remove this character from the inside of a character 
string? 

[julia-users] Syntax for slicing with an array of ranges?

[John Brock]

Is there an easy way to slice an array using an array of ranges? I'm 
looking for something like the following:

foo = [2,6,2,8,4,9]
some_ranges = UnitRange{Int64}[2:3, 5:6]
foo[some_ranges] # gives error; desired output is [6,2,4,9]

[julia-users] Re: Julia nightlies

[Yakir Gagnon]

OK, I'm gonna git pull & make then. That's the only way, right?

On Wednesday, August 19, 2015 at 4:54:05 AM UTC+10, Uwe Fechner wrote:
>
> Well, removing the link from the website does not help with the travis 
> failures:
> https://travis-ci.org/mlubin/NaNMath.jl/jobs/76114115
>
> Regards: Uwe
>
> Am Dienstag, 18. August 2015 18:46:31 UTC+2 schrieb Viral Shah:
>>
>> Elliot has been busy lately, and this has not been maintained for a long 
>> time. We should probably remove that link from our website.
>>
>> -viral
>>
>> On Tuesday, August 18, 2015 at 9:52:17 PM UTC+5:30, Uwe Fechner wrote:
>>>
>>> Hello,
>>>
>>> the nightly Julia builds from:
>>> https://launchpad.net/~staticfloat/+archive/ubuntu/julianightlies
>>>
>>> are currently quiet outdated.
>>>
>>> As far as I understand they should be auto-generated every night from 
>>> the head
>>> branch of the Julia repository.
>>>
>>> This seams to be currently broken.
>>>
>>> Any idea, why?
>>>
>>> The outdated version is causing problems with failing checks of Travis.
>>>
>>> Best regards:
>>>
>>> Uwe
>>>
>>

Re: [julia-users] package compatibility for julia v0.3 and v0.4

[Steven G. Johnson]

On Tuesday, August 18, 2015 at 7:22:49 PM UTC-4, Stefan Karpinski wrote:
>
> Did you try `@compat x % UInt8`?
>

You shouldn't need the @compat macro.  The Compat package should just add 
methods to % (rem). 

[julia-users] using call() to forward related types to apply many functions

[Jeffrey Sarnoff]

I need a few examples of using call() to simplify multitype
field forwarding to many functions. The types share in a
shallow, narrow branching abstraction that groups by manner
of access or mode of use.

Tyme{specialization}  <: ... <: ... <: Base.Dates.TimeType
Tyme{Val{:A}}
  <: ...
Tyme{Val{:G}} <: ...

typealias AtomicTime Union( Tyme{Val{:A}}, Tyme{Val{:B}}, Tyme{Val{:C}} )

(-){T <: AtomicTime}(dt2::T, dt2::T) =
   (-)(dt1.DateTimeField, dt2.DateTimeField)

(-){T <: AtomicTime, U <: FineTime}(dt2::T, dt2::U) =
   (-)(dt1.DateTimeField, DateTime(unwobble(dt2.DateTimeField)))

thanks

Re: [julia-users] package compatibility for julia v0.3 and v0.4

[Yichao Yu]

On Tue, Aug 18, 2015 at 8:20 PM, Samuele Carcagno
 wrote:
> On 19/08/15 00:22, Stefan Karpinski wrote:
>>
>> Did you try `@compat x % UInt8`?
>
>
> yes, it gives the same error `ERROR: `rem` has no method matching
> rem(::Int32, ::Type{Uint8})`

Sorry, didn't realize you are converting to a smaller type. Have you
tried just `trunc(Uint8, x)`? (or `@compat trunc(UInt8, x)` if you
want to use the new type name)

>
>>
>> On Tue, Aug 18, 2015 at 7:18 PM, Samuele Carcagno
>> mailto:sam.carca...@gmail.com>> wrote:
>>
>> On 18/08/15 21:46, Yichao Yu wrote:
>>
>>
>> On Aug 18, 2015 2:54 PM, "Samuele Carcagno"
>> mailto:sam.carca...@gmail.com>
>> >>
>>
>> wrote:
>>   >
>>   > I understand that if I release a new version of a package
>> "foo" and
>> put `julia 0.4` in `REQUIRE`, the package won't be updated in
>> julia v0.3
>> installations. If, after the updated package is released,
>> somebody tries
>> to install package "foo" from julia v0.3 what happens? Will they
>> still
>> be able to install the older version of the package?
>>   >
>>   > I'm asking because I'd like to release an updated version of a
>> package to make it work with julia v0.4. The changes, however, are
>> incompatible with julia v0.3. I tried using @compat to work
>> around the
>> issues but couldn't figure out how to fix this deprecation warning
>> without breaking v0.3 compatibility:
>>   > `uint8(x::Integer) is deprecated, use x % UInt8 instead`
>>
>> @compat UInt8(x)
>>
>>
>> thanks for the suggestion but that doesn't do what I need. The
>> problem is that I need to write 32-bit integers into a 24-bit file
>> format. This requires some bit fiddling. In julia v0.3 this worked
>> without deprecation warnings:
>>
>>  write(fid, uint8(thisSample));
>>  write(fid, uint8(thisSample >> 8));
>>  write(fid, uint8(thisSample >> 16));
>>
>> `thisSample` is a 32 bit integer. In julia v0.4 `UInt8(x)` fails
>> when `x` is greater tha 2^8-1, instead the following works:
>>
>>  write(fid, thisSample % UInt8);
>>  write(fid, (thisSample >> 8) % UInt8);
>>  write(fid, (thisSample >> 16) % UInt8);
>>
>> the problem is it doesn't work in julia v0.3 `x % @compat UInt8`
>> gives:
>> `ERROR: `rem` has no method matching rem(::Int32, ::Type{Uint8})`
>>
>>
>>
>> Sam
>>
>>
>>   >
>>   > Cheers,
>>   >
>>   > Sam
>>
>>
>>
>

Re: [julia-users] package compatibility for julia v0.3 and v0.4

[Samuele Carcagno]

On 19/08/15 00:22, Stefan Karpinski wrote:

Did you try `@compat x % UInt8`?


yes, it gives the same error `ERROR: `rem` has no method matching 
rem(::Int32, ::Type{Uint8})`




On Tue, Aug 18, 2015 at 7:18 PM, Samuele Carcagno
mailto:sam.carca...@gmail.com>> wrote:

On 18/08/15 21:46, Yichao Yu wrote:


On Aug 18, 2015 2:54 PM, "Samuele Carcagno"
mailto:sam.carca...@gmail.com>
>>
wrote:
  >
  > I understand that if I release a new version of a package
"foo" and
put `julia 0.4` in `REQUIRE`, the package won't be updated in
julia v0.3
installations. If, after the updated package is released,
somebody tries
to install package "foo" from julia v0.3 what happens? Will they
still
be able to install the older version of the package?
  >
  > I'm asking because I'd like to release an updated version of a
package to make it work with julia v0.4. The changes, however, are
incompatible with julia v0.3. I tried using @compat to work
around the
issues but couldn't figure out how to fix this deprecation warning
without breaking v0.3 compatibility:
  > `uint8(x::Integer) is deprecated, use x % UInt8 instead`

@compat UInt8(x)


thanks for the suggestion but that doesn't do what I need. The
problem is that I need to write 32-bit integers into a 24-bit file
format. This requires some bit fiddling. In julia v0.3 this worked
without deprecation warnings:

 write(fid, uint8(thisSample));
 write(fid, uint8(thisSample >> 8));
 write(fid, uint8(thisSample >> 16));

`thisSample` is a 32 bit integer. In julia v0.4 `UInt8(x)` fails
when `x` is greater tha 2^8-1, instead the following works:

 write(fid, thisSample % UInt8);
 write(fid, (thisSample >> 8) % UInt8);
 write(fid, (thisSample >> 16) % UInt8);

the problem is it doesn't work in julia v0.3 `x % @compat UInt8` gives:
`ERROR: `rem` has no method matching rem(::Int32, ::Type{Uint8})`



Sam


  >
  > Cheers,
  >
  > Sam

Re: [julia-users] package compatibility for julia v0.3 and v0.4

[Stefan Karpinski]

Did you try `@compat x % UInt8`?

On Tue, Aug 18, 2015 at 7:18 PM, Samuele Carcagno 
wrote:

> On 18/08/15 21:46, Yichao Yu wrote:
>
>>
>> On Aug 18, 2015 2:54 PM, "Samuele Carcagno" > > wrote:
>>  >
>>  > I understand that if I release a new version of a package "foo" and
>> put `julia 0.4` in `REQUIRE`, the package won't be updated in julia v0.3
>> installations. If, after the updated package is released, somebody tries
>> to install package "foo" from julia v0.3 what happens? Will they still
>> be able to install the older version of the package?
>>  >
>>  > I'm asking because I'd like to release an updated version of a
>> package to make it work with julia v0.4. The changes, however, are
>> incompatible with julia v0.3. I tried using @compat to work around the
>> issues but couldn't figure out how to fix this deprecation warning
>> without breaking v0.3 compatibility:
>>  > `uint8(x::Integer) is deprecated, use x % UInt8 instead`
>>
>> @compat UInt8(x)
>>
>
> thanks for the suggestion but that doesn't do what I need. The problem is
> that I need to write 32-bit integers into a 24-bit file format. This
> requires some bit fiddling. In julia v0.3 this worked without deprecation
> warnings:
>
> write(fid, uint8(thisSample));
> write(fid, uint8(thisSample >> 8));
> write(fid, uint8(thisSample >> 16));
>
> `thisSample` is a 32 bit integer. In julia v0.4 `UInt8(x)` fails when `x`
> is greater tha 2^8-1, instead the following works:
>
> write(fid, thisSample % UInt8);
> write(fid, (thisSample >> 8) % UInt8);
> write(fid, (thisSample >> 16) % UInt8);
>
> the problem is it doesn't work in julia v0.3 `x % @compat UInt8` gives:
> `ERROR: `rem` has no method matching rem(::Int32, ::Type{Uint8})`
>
>
>
> Sam
>
>
>>  >
>>  > Cheers,
>>  >
>>  > Sam
>>
>>
>

Re: [julia-users] package compatibility for julia v0.3 and v0.4

[Samuele Carcagno]

On 18/08/15 21:46, Yichao Yu wrote:


On Aug 18, 2015 2:54 PM, "Samuele Carcagno" mailto:sam.carca...@gmail.com>> wrote:
 >
 > I understand that if I release a new version of a package "foo" and
put `julia 0.4` in `REQUIRE`, the package won't be updated in julia v0.3
installations. If, after the updated package is released, somebody tries
to install package "foo" from julia v0.3 what happens? Will they still
be able to install the older version of the package?
 >
 > I'm asking because I'd like to release an updated version of a
package to make it work with julia v0.4. The changes, however, are
incompatible with julia v0.3. I tried using @compat to work around the
issues but couldn't figure out how to fix this deprecation warning
without breaking v0.3 compatibility:
 > `uint8(x::Integer) is deprecated, use x % UInt8 instead`

@compat UInt8(x)


thanks for the suggestion but that doesn't do what I need. The problem 
is that I need to write 32-bit integers into a 24-bit file format. This 
requires some bit fiddling. In julia v0.3 this worked without 
deprecation warnings:


write(fid, uint8(thisSample));
write(fid, uint8(thisSample >> 8));
write(fid, uint8(thisSample >> 16));

`thisSample` is a 32 bit integer. In julia v0.4 `UInt8(x)` fails when 
`x` is greater tha 2^8-1, instead the following works:


write(fid, thisSample % UInt8);
write(fid, (thisSample >> 8) % UInt8);
write(fid, (thisSample >> 16) % UInt8);

the problem is it doesn't work in julia v0.3 `x % @compat UInt8` gives:
`ERROR: `rem` has no method matching rem(::Int32, ::Type{Uint8})`



Sam



 >
 > Cheers,
 >
 > Sam

Re: [julia-users] Re: help with try/catch?

[Yichao Yu]

On Aug 18, 2015 6:27 PM, "Seth"  wrote:
>
>
>
> On Tuesday, August 18, 2015 at 3:16:48 PM UTC-7, Yichao Yu wrote:
>>
>>
>> You cannot use import in local scope. Use eval or @eval
>>
>>
>
> But why do the other ones (including when the "try" returns "nothing")
work?

Didn't notice that I guess its an parser bug then

Re: [julia-users] Re: help with try/catch?

[Seth]

On Tuesday, August 18, 2015 at 3:16:48 PM UTC-7, Yichao Yu wrote:
>
>
> You cannot use import in local scope. Use eval or @eval
>
>
>
But why do the other ones (including when the "try" returns "nothing") 
work? 

Re: [julia-users] Re: help with try/catch?

[Yichao Yu]

On Aug 18, 2015 5:50 PM, "Seth"  wrote:
>
> Another followup:
>
> julia> try
>using LightGraphs
>catch y
>println("y = $y")
>end
> y = ErrorException("unsupported or misplaced expression using")
>

You cannot use import in local scope. Use eval or @eval

>
>
> On Tuesday, August 18, 2015 at 2:18:43 PM UTC-7, Seth wrote:
>>
>>
>>
>> I wasn't sure how to search for this in issues:
>>
>> julia> try
>>using LightGraphs
>>catch
>>end
>>
>>
>> julia> Graph
>> ERROR: UndefVarError: Graph not defined
>>
>>
>> but
>>
>>
>> julia> try
>>using LightGraphs
>>true
>>catch
>>false
>>end
>> true
>>
>>
>> julia> Graph
>> LightGraphs.Graph
>>
>>
>>
>>
>> Why doesn't the first one work?

[julia-users] Re: help with try/catch?

[Seth]

Another followup:

julia> try
   using LightGraphs
   catch y
   println("y = $y")
   end
y = ErrorException("unsupported or misplaced expression using")



On Tuesday, August 18, 2015 at 2:18:43 PM UTC-7, Seth wrote:
>
>
>
> I wasn't sure how to search for this in issues:
>
> julia> try
>using LightGraphs
>catch
>end
>
>
> julia> Graph
> ERROR: UndefVarError: Graph not defined
>
>
> but 
>
>
> julia> try
>using LightGraphs
>true
>catch
>false
>end
> true
>
>
> julia> Graph
> LightGraphs.Graph
>
>
>
>
> Why doesn't the first one work?
>

[julia-users] Re: help with try/catch?

[Seth]

following up,

try
using LightGraphs
nothing
catch
end

works.

On Tuesday, August 18, 2015 at 2:18:43 PM UTC-7, Seth wrote:
>
>
>
> I wasn't sure how to search for this in issues:
>
> julia> try
>using LightGraphs
>catch
>end
>
>
> julia> Graph
> ERROR: UndefVarError: Graph not defined
>
>
> but 
>
>
> julia> try
>using LightGraphs
>true
>catch
>false
>end
> true
>
>
> julia> Graph
> LightGraphs.Graph
>
>
>
>
> Why doesn't the first one work?
>

[julia-users] help with try/catch?

[Seth]

I wasn't sure how to search for this in issues:

julia> try
   using LightGraphs
   catch
   end


julia> Graph
ERROR: UndefVarError: Graph not defined


but 


julia> try
   using LightGraphs
   true
   catch
   false
   end
true


julia> Graph
LightGraphs.Graph




Why doesn't the first one work?

Re: [julia-users] ANN: SimJulia 0.3.4

[Tom Breloff]

Thanks for the detailed response Ben.  I absolutely see the value in
event-style programming.  I have my own version of this... it may not be as
feature-full, but it's pretty fast.  I use it mainly to process various
financial events (exchange messages, order book updates, etc) but it's
fairly flexible.  I have a few random things in a repo which I just made
public (but it's certainly not something that belongs in metadata)... if
you're curious at all, check out the pubsub.jl and scheduler.jl files at
https://github.com/tbreloff/CTechCommon.jl.  When I have some time I'll try
to see if it makes sense to start using SimJulia instead or in addition to
my own scheduler.

On Tue, Aug 18, 2015 at 2:36 PM, Ben Lauwens  wrote:

> Tom
>
> The event scheduling in SimJulia is based on the standard PriorityQueue*
> implementation of Julia and the overhead of SimJulia is really limited. If
> you throw away the process oriented way of defining a simulation model, you
> can do theoretically better, i.e. pure event simulation. This is certainly
> true for small models but for bigger ones you (I for sure) will end up
> developing a massive spaghetti code.
> I have used the previous version of SimJulia in some large simulation
> models and compared to SimPy or commercial simulation software (ARENA) the
> speedup I measured was often more than two orders of magnitude. We are
> right now porting two large projects (HR planning and medical battlefield
> management) from ARENA to SimJulia. The benefits of Julia are enormous. No
> more mixed code (SIMAN and Visual Basic) and being able to troubleshoot the
> internals of the simulation are for me the most important advantages.
>
> * The standard PriorityQueue is based on a binary heap and in my PhD I
> have shown that if you have no prior knowledge on the timing of the events,
> no event calendar (tree, heap, sorting, ...) can do better in a real
> implementation if you consider the extreme low overhead of its
> implementation (Vector based, no pointers and limited number of
> comparisons). I know that some other heap mechanisms (Binomial, Fibonacci,
> ...) have better time complexities but I have never found one that
> performed as well on real use cases as as binary heap.
>
> Most people are afraid of this process oriented programming. Programmers
> prefer the idea of sequential execution and the main philosophy of
> processes is asynchronous tasking. It takes my master students some weeks
> to get used to it but once they passed this difficulty, they are ready to
> tackle real world simulation problems.
>
> Often (almost always) we are doing Montecarlo simulations of 1000 or more
> repetitions and use the SimJulia framework in the inner loop. We are also
> working on simulation based optimization and the SimJulia framework is also
> used in the inner loop. To estimate the loss of speed compared to a more
> direct approach is very difficult to predict. One thing I am quite sure of
> is the ease of development when using process based simulations.
>
> I hope that I somehow answered your question. Please feel free to contact
> me if you need some assistance with your SimJulia coding.
>
> Ben
>
> On Tuesday, August 18, 2015 at 9:52:21 PM UTC+2, Tom Breloff wrote:
>>
>> Thanks for the effort Ben.  I'm curious... do you have any performance
>> comparisons of SimJulia vs other (simpler) code designs?  How much speed
>> would I be giving up if I was using events in a tight inner loop?
>>
>> On Tue, Aug 18, 2015 at 1:25 PM, Ben Lauwens  wrote:
>>
>>> Hi
>>>
>>> SimJulia, a (combined continuous time / ) discrete event process
>>> oriented simulation framework, has reached another milestone:
>>>
>>>- v0.3.4 synchronizes the API with SimPy v3 but using some specific
>>>Julia semantics
>>>- It is a complete rewrite allowing a more powerful and unified
>>>discrete event approach
>>>- 10 min tutorial is included to give users a taste of discrete
>>>event simulation with (Sim)Julia
>>>- A detailed topical guide is also written
>>>
>>> For the moment the continuous time part is not operational. A *quantized
>>> state system* (QSS) solver is being developed for continuous system
>>> simulation using the discrete event framework. Once this is done v0.4
>>> will be tagged.
>>> New ideas or interesting examples are always welcome and can be
>>> submitted as an issue or a pull request on GitHub.
>>> Enjoy!
>>>
>>> Ben
>>>
>>
>>

Re: [julia-users] package compatibility for julia v0.3 and v0.4

[Yichao Yu]

On Aug 18, 2015 2:54 PM, "Samuele Carcagno"  wrote:
>
> I understand that if I release a new version of a package "foo" and put
`julia 0.4` in `REQUIRE`, the package won't be updated in julia v0.3
installations. If, after the updated package is released, somebody tries to
install package "foo" from julia v0.3 what happens? Will they still be able
to install the older version of the package?
>
> I'm asking because I'd like to release an updated version of a package to
make it work with julia v0.4. The changes, however, are incompatible with
julia v0.3. I tried using @compat to work around the issues but couldn't
figure out how to fix this deprecation warning without breaking v0.3
compatibility:
> `uint8(x::Integer) is deprecated, use x % UInt8 instead`

@compat UInt8(x)

>
> Cheers,
>
> Sam

Re: [julia-users] ANN: SimJulia 0.3.4

[Ben Lauwens]

Tom

The event scheduling in SimJulia is based on the standard PriorityQueue* 
implementation of Julia and the overhead of SimJulia is really limited. If 
you throw away the process oriented way of defining a simulation model, you 
can do theoretically better, i.e. pure event simulation. This is certainly 
true for small models but for bigger ones you (I for sure) will end up 
developing a massive spaghetti code.
I have used the previous version of SimJulia in some large simulation 
models and compared to SimPy or commercial simulation software (ARENA) the 
speedup I measured was often more than two orders of magnitude. We are 
right now porting two large projects (HR planning and medical battlefield 
management) from ARENA to SimJulia. The benefits of Julia are enormous. No 
more mixed code (SIMAN and Visual Basic) and being able to troubleshoot the 
internals of the simulation are for me the most important advantages.

* The standard PriorityQueue is based on a binary heap and in my PhD I have 
shown that if you have no prior knowledge on the timing of the events, no 
event calendar (tree, heap, sorting, ...) can do better in a real 
implementation if you consider the extreme low overhead of its 
implementation (Vector based, no pointers and limited number of 
comparisons). I know that some other heap mechanisms (Binomial, Fibonacci, 
...) have better time complexities but I have never found one that 
performed as well on real use cases as as binary heap.

Most people are afraid of this process oriented programming. Programmers 
prefer the idea of sequential execution and the main philosophy of 
processes is asynchronous tasking. It takes my master students some weeks 
to get used to it but once they passed this difficulty, they are ready to 
tackle real world simulation problems. 

Often (almost always) we are doing Montecarlo simulations of 1000 or more 
repetitions and use the SimJulia framework in the inner loop. We are also 
working on simulation based optimization and the SimJulia framework is also 
used in the inner loop. To estimate the loss of speed compared to a more 
direct approach is very difficult to predict. One thing I am quite sure of 
is the ease of development when using process based simulations.

I hope that I somehow answered your question. Please feel free to contact 
me if you need some assistance with your SimJulia coding.

Ben

On Tuesday, August 18, 2015 at 9:52:21 PM UTC+2, Tom Breloff wrote:
>
> Thanks for the effort Ben.  I'm curious... do you have any performance 
> comparisons of SimJulia vs other (simpler) code designs?  How much speed 
> would I be giving up if I was using events in a tight inner loop?
>
> On Tue, Aug 18, 2015 at 1:25 PM, Ben Lauwens  > wrote:
>
>> Hi
>>
>> SimJulia, a (combined continuous time / ) discrete event process 
>> oriented simulation framework, has reached another milestone:
>>
>>- v0.3.4 synchronizes the API with SimPy v3 but using some specific 
>>Julia semantics
>>- It is a complete rewrite allowing a more powerful and unified 
>>discrete event approach
>>- 10 min tutorial is included to give users a taste of discrete event 
>>simulation with (Sim)Julia
>>- A detailed topical guide is also written
>>
>> For the moment the continuous time part is not operational. A *quantized 
>> state system* (QSS) solver is being developed for continuous system 
>> simulation using the discrete event framework. Once this is done v0.4 
>> will be tagged.
>> New ideas or interesting examples are always welcome and can be submitted 
>> as an issue or a pull request on GitHub.
>> Enjoy!
>>
>> Ben
>>
>
>

Re: [julia-users] ANN: SimJulia 0.3.4

[Tom Breloff]

Thanks for the effort Ben.  I'm curious... do you have any performance
comparisons of SimJulia vs other (simpler) code designs?  How much speed
would I be giving up if I was using events in a tight inner loop?

On Tue, Aug 18, 2015 at 1:25 PM, Ben Lauwens  wrote:

> Hi
>
> SimJulia, a (combined continuous time / ) discrete event process oriented
> simulation framework, has reached another milestone:
>
>- v0.3.4 synchronizes the API with SimPy v3 but using some specific
>Julia semantics
>- It is a complete rewrite allowing a more powerful and unified
>discrete event approach
>- 10 min tutorial is included to give users a taste of discrete event
>simulation with (Sim)Julia
>- A detailed topical guide is also written
>
> For the moment the continuous time part is not operational. A *quantized
> state system* (QSS) solver is being developed for continuous system
> simulation using the discrete event framework. Once this is done v0.4
> will be tagged.
> New ideas or interesting examples are always welcome and can be submitted
> as an issue or a pull request on GitHub.
> Enjoy!
>
> Ben
>

[julia-users] ANN: SimJulia 0.3.4

[Ben Lauwens]

Hi

SimJulia, a (combined continuous time / ) discrete event process oriented 
simulation framework, has reached another milestone:

   - v0.3.4 synchronizes the API with SimPy v3 but using some specific 
   Julia semantics
   - It is a complete rewrite allowing a more powerful and unified discrete 
   event approach
   - 10 min tutorial is included to give users a taste of discrete event 
   simulation with (Sim)Julia
   - A detailed topical guide is also written

For the moment the continuous time part is not operational. A *quantized 
state system* (QSS) solver is being developed for continuous system 
simulation using the discrete event framework. Once this is done v0.4 will 
be tagged.
New ideas or interesting examples are always welcome and can be submitted 
as an issue or a pull request on GitHub.
Enjoy!

Ben

Re: [julia-users] Re: JuliaCon 2015 videos

[Ismael VC]

Shashi how are you doing your presentations? They are awesome! Where can I 
find the code for that one?

El martes, 18 de agosto de 2015, 11:55:01 (UTC-5), Shashi Gowda escribió:
>
> If you have Escher installed and ready to go (See instructions on 
> escher-jl.org) you can safely skip the first 20 mins of my Escher.jl 
> video.
>
> A better talk on Escher is this one I gave recently at a conference in 
> Bangalore: https://youtu.be/UeVUsOX5rAo?t=150 it definitely packs more 
> content in lesser time.
>
> On Tue, Aug 18, 2015 at 9:42 PM, Frank Kampas  > wrote:
>
>> The optimization video is private
>>
>>
>> On Thursday, August 13, 2015 at 1:22:09 PM UTC-4, Viral Shah wrote:
>>>
>>> Folks, 
>>>
>>> I am happy to announce that the videos are almost all ready, and I will 
>>> start posting them in batches. I am starting with Jeff’s talk on our 
>>> Youtube channel: 
>>>
>>> https://www.youtube.com/user/JuliaLanguage 
>>>
>>> Direct link to the video: 
>>>
>>> https://www.youtube.com/watch?v=xUP3cSKb8sI 
>>>
>>> -viral 
>>>
>>>
>>>
>>>
>

[julia-users] Re: Julia nightlies

[Uwe Fechner]

Well, removing the link from the website does not help with the travis 
failures:
https://travis-ci.org/mlubin/NaNMath.jl/jobs/76114115

Regards: Uwe

Am Dienstag, 18. August 2015 18:46:31 UTC+2 schrieb Viral Shah:
>
> Elliot has been busy lately, and this has not been maintained for a long 
> time. We should probably remove that link from our website.
>
> -viral
>
> On Tuesday, August 18, 2015 at 9:52:17 PM UTC+5:30, Uwe Fechner wrote:
>>
>> Hello,
>>
>> the nightly Julia builds from:
>> https://launchpad.net/~staticfloat/+archive/ubuntu/julianightlies
>>
>> are currently quiet outdated.
>>
>> As far as I understand they should be auto-generated every night from the 
>> head
>> branch of the Julia repository.
>>
>> This seams to be currently broken.
>>
>> Any idea, why?
>>
>> The outdated version is causing problems with failing checks of Travis.
>>
>> Best regards:
>>
>> Uwe
>>
>

[julia-users] package compatibility for julia v0.3 and v0.4

[Samuele Carcagno]

I understand that if I release a new version of a package "foo" and put 
`julia 0.4` in `REQUIRE`, the package won't be updated in julia v0.3 
installations. If, after the updated package is released, somebody tries 
to install package "foo" from julia v0.3 what happens? Will they still 
be able to install the older version of the package?


I'm asking because I'd like to release an updated version of a package 
to make it work with julia v0.4. The changes, however, are incompatible 
with julia v0.3. I tried using @compat to work around the issues but 
couldn't figure out how to fix this deprecation warning without breaking 
v0.3 compatibility:

`uint8(x::Integer) is deprecated, use x % UInt8 instead`

Cheers,

Sam

Re: [julia-users] Re: JuliaCon 2015 videos

[Shashi Gowda]

If you have Escher installed and ready to go (See instructions on
escher-jl.org) you can safely skip the first 20 mins of my Escher.jl video.

A better talk on Escher is this one I gave recently at a conference in
Bangalore: https://youtu.be/UeVUsOX5rAo?t=150 it definitely packs more
content in lesser time.

On Tue, Aug 18, 2015 at 9:42 PM, Frank Kampas  wrote:

> The optimization video is private
>
>
> On Thursday, August 13, 2015 at 1:22:09 PM UTC-4, Viral Shah wrote:
>>
>> Folks,
>>
>> I am happy to announce that the videos are almost all ready, and I will
>> start posting them in batches. I am starting with Jeff’s talk on our
>> Youtube channel:
>>
>> https://www.youtube.com/user/JuliaLanguage
>>
>> Direct link to the video:
>>
>> https://www.youtube.com/watch?v=xUP3cSKb8sI
>>
>> -viral
>>
>>
>>
>>

[julia-users] Re: Julia nightlies

[Viral Shah]

Elliot has been busy lately, and this has not been maintained for a long 
time. We should probably remove that link from our website.

-viral

On Tuesday, August 18, 2015 at 9:52:17 PM UTC+5:30, Uwe Fechner wrote:
>
> Hello,
>
> the nightly Julia builds from:
> https://launchpad.net/~staticfloat/+archive/ubuntu/julianightlies
>
> are currently quiet outdated.
>
> As far as I understand they should be auto-generated every night from the 
> head
> branch of the Julia repository.
>
> This seams to be currently broken.
>
> Any idea, why?
>
> The outdated version is causing problems with failing checks of Travis.
>
> Best regards:
>
> Uwe
>

[julia-users] Re: JuliaCon 2015 videos

[Viral Shah]

Iain requested for it to be taken down temporarily, since it was missing 
slides.

The Geospatial analysis video is also taken down until further word from 
Yee Sian.

-viral

On Tuesday, August 18, 2015 at 9:42:36 PM UTC+5:30, Frank Kampas wrote:
>
> The optimization video is private
>
> On Thursday, August 13, 2015 at 1:22:09 PM UTC-4, Viral Shah wrote:
>>
>> Folks, 
>>
>> I am happy to announce that the videos are almost all ready, and I will 
>> start posting them in batches. I am starting with Jeff’s talk on our 
>> Youtube channel: 
>>
>> https://www.youtube.com/user/JuliaLanguage 
>>
>> Direct link to the video: 
>>
>> https://www.youtube.com/watch?v=xUP3cSKb8sI 
>>
>> -viral 
>>
>>
>>
>>

[julia-users] Re: JuliaCon 2015 videos

[Frank Kampas]

The optimization video is private

On Thursday, August 13, 2015 at 1:22:09 PM UTC-4, Viral Shah wrote:
>
> Folks, 
>
> I am happy to announce that the videos are almost all ready, and I will 
> start posting them in batches. I am starting with Jeff’s talk on our 
> Youtube channel: 
>
> https://www.youtube.com/user/JuliaLanguage 
>
> Direct link to the video: 
>
> https://www.youtube.com/watch?v=xUP3cSKb8sI 
>
> -viral 
>
>
>
>

[julia-users] Julia nightlies

[Uwe Fechner]

Hello,

the nightly Julia builds from:
https://launchpad.net/~staticfloat/+archive/ubuntu/julianightlies

are currently quiet outdated.

As far as I understand they should be auto-generated every night from the 
head
branch of the Julia repository.

This seams to be currently broken.

Any idea, why?

The outdated version is causing problems with failing checks of Travis.

Best regards:

Uwe

Re: [julia-users] Constructor or convert(), Upper case or lower case

[Matt Bauman]

On Tuesday, August 18, 2015 at 11:29:00 AM UTC-4, Sisyphuss wrote:
>
> My point is these inconsistent rules are very confusing. The experience 
> gained in one type cannot be extrapolated to another. 
>
 
I think most people here will agree with you.  The discussion on how to 
spell conversion and/or construction took 2.5 years and over 100 comments 
to reach consensus and implement the required code changes to make it 
happen (see issue #1470). Furthermore, the ability to do this only happened 
recently, so we're still settling on how to best use these new features.

It may be possible to deprecate the lowercase symbol function in favor of 
Symbol, but that'll cause a decent amount of code churn.  `float` is an 
interesting case as it's regularly used to generically mean: convert to a 
floating point number *OR* a complex number with floating point components, 
so that's why it's still here but `int` isn't.

Re: [julia-users] Metaprogramming: the use of `$`

[Yichao Yu]

On Tue, Aug 18, 2015 at 11:24 AM, Sisyphuss  wrote:
>
>
> On Tuesday, August 18, 2015 at 2:11:40 PM UTC+2, Yichao Yu wrote:
>>
>> On Tue, Aug 18, 2015 at 6:49 AM, Sisyphuss  wrote:
>> > I'm reading the documentation Metaprogramming chapter.
>> > To me, the `$` operator is different from the one in the string
>> > interpolation.
>> > In the string, `$` is a runtime interpolation.
>> > In the expression, `$` is a compile-time interpolation.
>>
>> No. Both of them happens at whenever the expression is evaluated. It
>> happens for `@eval` at "compile time" because that's when the macro
>> expansion happens.
>>
> for i in 1:3
> println("$(rand())")
> end
> It prints different values each iteration, so it's run-time interpolation.

julia> for i in 1:3
  println(:($(rand(
  end
0.0513060369910221
0.006705158934253941
0.2977791327125763

>
>>
>> >
>> > In one example provided, `ex = :(a in $:((1,2,3)) )`,
>> > I find that it's equal to `ex = :(a in (1,2,3) )`.
>> > So I do not see the intention of `$`.
>>
>> The examples are meant to show you the basic rules not necessarily the
>> best/only way to do it.
>
>
> Really don't see the rules from these examples.

The rule is to show you how to splice an expression.

> In this example, the tuple (1,2,3) is **interpolated as an expression into a 
> conditional test:**

>
>>
>>
>> >
>> > In the next example, there is `:a + :b` in the expression,
>> > but the sum of `Symbols` is not defined. Is it wrong?
>>
>> It just construct an expression and to show you that the result is
>> quoted symbol rather than the symbol themselves.

Re: [julia-users] Constructor or convert(), Upper case or lower case

[Sisyphuss]

My point is these inconsistent rules are very confusing. The experience 
gained in one type cannot be extrapolated to another. 

Again, think about `sparse()`. What will we use when we implement the 
`SparseMatrixRSC`?


On Tuesday, August 18, 2015 at 2:26:12 PM UTC+2, Yichao Yu wrote:
>
> On Tue, Aug 18, 2015 at 6:04 AM, Sisyphuss  > wrote: 
> > We use `Int8(x)` to construct an `Int8`, 
> > but use `float(x)` to convert to a floating point. 
>
> Float is not a type. FWIW, `AbstractFloat(1)` works. 
>
> > 
> > We defines `Symbol` as an object, 
> > but use `symbol()` to construct symbols. 
>
> `Symbol("a")` works, just not for arbitrary types as `symbol`. 
> However, `Int*` don't allow converting from arbitrary types either so 
> it is consistent. From what I understand, `int*` are deprecated 
> because you should be explicit about what you want to do. For symbols 
> this is less of an issue. 
>
> > 
> > I am so confusing. 
>
> Hopefully you don't literally mean this. 
>

Re: [julia-users] Metaprogramming: the use of `$`

[Sisyphuss]

On Tuesday, August 18, 2015 at 2:11:40 PM UTC+2, Yichao Yu wrote:
>
> On Tue, Aug 18, 2015 at 6:49 AM, Sisyphuss  > wrote: 
> > I'm reading the documentation Metaprogramming chapter. 
> > To me, the `$` operator is different from the one in the string 
> > interpolation. 
> > In the string, `$` is a runtime interpolation. 
> > In the expression, `$` is a compile-time interpolation. 
>
> No. Both of them happens at whenever the expression is evaluated. It 
> happens for `@eval` at "compile time" because that's when the macro 
> expansion happens. 
>
> for i in 1:3
println("$(rand())")
end
It prints different values each iteration, so it's run-time interpolation.
 

> > 
> > In one example provided, `ex = :(a in $:((1,2,3)) )`, 
> > I find that it's equal to `ex = :(a in (1,2,3) )`. 
> > So I do not see the intention of `$`. 
>
> The examples are meant to show you the basic rules not necessarily the 
> best/only way to do it. 
>

Really don't see the rules from these examples.
 

>
> > 
> > In the next example, there is `:a + :b` in the expression, 
> > but the sum of `Symbols` is not defined. Is it wrong? 
>
> It just construct an expression and to show you that the result is 
> quoted symbol rather than the symbol themselves. 
>

Re: [julia-users] Re: A cheat page for Julia

[Ian Hellström]

It says "installed" not "install", so I believe it's correct. I may write "list 
installed..." if that helps. 

[julia-users] Re: A cheat page for Julia

[Ian Hellström]

Thanks for the detailed comments, Steven. I really appreciate it.

For now I have changed what was wrong/unclear and valid for 0.3 (locally, not 
yet online). I’ll prepare a 0.4 version and put that online as soon as 0.4 is 
officially released.

I know that the naming PascalCase vs camelCase vs init-cap CamelCase is almost 
up to each dev. Microsoft seems to be most pedantic about PascalCase vs 
camelCase: https://msdn.microsoft.com/en-us/library/x2dbyw72(v=vs.71).aspx. I 
don’t mind changing it. The official documentation calls it camel case, so I’ll 
go with that to make it more consistent.

What’s the reason you say “You can override Base.show(io, ex) rather than 
Base.showerror”? The doc seems to go with the latter and I also think it 
matches the intent (exception -> showerror): 
http://julia.readthedocs.org/en/latest/manual/control-flow/. Is there an 
advantage to overriding Base.show instead of Base.showerror?

Re: [julia-users] JuliaCon 2015 videos

[Keno Fischer]

I added an annotation for my video. If you tell me a timestamp for Shashi's
I can do the same there.

On Tue, Aug 18, 2015 at 2:31 PM, Waldir Pimenta 
wrote:

> Same for Shashi's session.
>
> On Monday, August 17, 2015 at 11:32:26 PM UTC+1, Keno Fischer wrote:
>>
>> Whoever owns the youtube channel should put an annotation that allows
>> users o click on it to skip that part.
>>
>> On Mon, Aug 17, 2015 at 8:08 PM, Sisyphuss  wrote:
>>
>>> In the Keno's video, he spent more than 5 minutes to go through the
>>> technical difficulty.
>>> I think this can be cut to save time.
>>>
>>>
>>>
>>> On Monday, August 17, 2015 at 3:30:48 PM UTC+2, Viral Shah wrote:

 One more batch:

 1. Iain Dunning: JuliaOpt - Optimization related projects in Julia:
 http://youtu.be/ZibQdqR6gqc?a
 2. Yee Sian Ng: JuliaGeo - Working with Geospatial data in Julia:
 http://youtu.be/MLGFzPS4FTg?a
 3. Isaiah Norton: Automatic ccall wrapper generation with Clang.jl:
 http://youtu.be/Jt5sv-8iRGc?a
 4. Simon Kornblith: L1 regularized regression:
 http://youtu.be/z4Zcud2vE0s?a
 5. Tony Fong: Lint.jl - Building a Lint tool for Julia:
 http://youtu.be/9T3R14R3X7k?a
 6. Douglas Bates: Adventures with Statistical Models and Sparse
 Matrices: http://youtu.be/lSr0oRfyd1Y?a

 -viral

 > On 17-Aug-2015, at 2:25 am, Viral Shah  wrote:
 >
 > A few more:
 >
 > 1. Blake Johnson: Quickly building simulations of quantum systems:
 http://youtu.be/kogTKuytg1g?a
 > 2. Katharine Hyatt: Quantum Statistical Simulations with Julia:
 http://youtu.be/QThApV3HIxc?a
 > 3. Making GUIs with Escher jl: http://youtu.be/Sq7DEnV4dfI?a
 > 4. John Myles White: What needs to be done to move JuliaStats
 forward: http://youtu.be/lf1_FhMR7xA?a
 > 5. Jacob Quinn: Managing Data in Julia Old Tricks, New Tricks:
 http://youtu.be/QLWhsZ3yzBk?a
 >
 > -viral
 >
 >
 >
 >> On 16-Aug-2015, at 11:15 am, Viral Shah  wrote:
 >>
 >> Next set:
 >>
 >> 1. Avik Sengupta: A practical guide to exposing Julia APIs on the
 web: http://youtu.be/o40OpLe2k7Q?a
 >> 2. Hongbo Rong: Accelerating sparse matrix kernels in Julia:
 http://youtu.be/k40K2zJVv0A?a
 >> 3. Luis Benet: Taylor series expansions in Julia:
 http://youtu.be/6zrQuq5mODQ?a
 >> 4. Westley Hennigh: Who optimizes the optimizers:
 http://youtu.be/Qito5AGSv4s?a
 >> 5. Mauro Werder: Interfaces for Julia -Traits.jl:
 youtu.be/j9w8oHfG1Ic?a
 >> 6. David Gold: Nullable arrays - http://youtu.be/2v5k28F80BQ?a
 >>
 >> -viral
 >>
 >>
 >>
 >>> On 16-Aug-2015, at 12:01 am, Viral Shah  wrote:
 >>>
 >>> Next set:
 >>>
 >>> 1. Sebastien Martin: Taxi fleet simulation and visualization:
 http://youtu.be/MjERK9Xajrg?a
 >>> 2. Bob Carpenter: Stan.jl - Statistical Modeling and Inference Made
 Easy: http://youtu.be/YdgMJ37CDws?a
 >>> 3. Pontus Stenetorp: Suitably Naming a Child with Multiple
 Nationalities: http://youtu.be/MJzRf3Exlqc?a
 >>> 4. Chiyuan Zhang: Mocha.jl - Deep Learning for Julia:
 http://youtu.be/ljySoebYylE?a
 >>> 5. Kiran Pamnany and Ranjan Anantharaman: Multi-threading Julia:
 http://youtu.be/GvLhseZ4D8M?a
 >>> 6. St. Louis University - Text Mining Research Group:
 TextMining.jl: http://youtu.be/dgfIIZ5yA4E?a
 >>> 7. Zachary Yedidia: SFML.jl - Julia bindings for the Simple Fast:
 http://youtu.be/UKfM7EopMe0?a
 >>>
 >>> -viral
 >>>
 >>>
 >>>
  On 15-Aug-2015, at 10:07 am, Viral Shah  wrote:
 
  One more batch posted:
 
  1. Jacob Quinn: Composable streams for data transfer and
 processing - http://t.co/DPuN42F3Qu
  2. Tanmay Mohapatra: Interfacing Julia with Complex systems using
 Protocol Buffers - http://t.co/Ddxj60KL7g
  3. Eric Davies: Towards A Consistent Database Interface -
 http://t.co/vdQwFRp7aD
  4. Viral Shah: The present and future of sparse matrices in Julia
 - http://t.co/WVQY89GsiT
  5. Jake Bolewski: Staged programming in Julia -
 http://t.co/XlYl2XGB9O
  6. Robert Moss: Julia as a Specification Language for the
 next-generation Airborne Collision Avoidance System -
 http://t.co/QJN2ZfP1ZI
 
  -viral
 
  On Friday, August 14, 2015 at 7:33:04 PM UTC+5:30, Viral Shah
 wrote:
  Here are the next batch of videos. There is a JuliaCon 2015
 channel now:
 
 
 https://www.youtube.com/playlist?list=PLP8iPy9hna6Sdx4soiGrSefrmOPdUWixM
 
  This batch includes:
 
  David Sanders: Validated numerics in Julia -
 http://t.co/WRZcYGjhfl
  Patrick Sanan: Using Julia on a Cray Supercomputer -
 https://youtu.be/NwyKz2KLdtY
  Keno Fischer: Shaving the Yak - http://t.co/cEJqCqAdRC
  Spencer Lyon: Methods,

Re: [julia-users] Re: A cheat page for Julia

[Alex Ames]

For installing packages, 'Pkg.status(pkgName)' should be 'Pkg.add(pkgName)'. 

Re: [julia-users] Re: How to define an array of floating point numbers?

[Sisyphuss]

Here, my point is the word "Abstract"


On Tuesday, August 18, 2015 at 3:42:16 PM UTC+2, Kristoffer Carlsson wrote:
>
> They are the same. The vector is just a type alias for the array of size 
> 1. Personally I like vector because to me it is clearer to read.
>
> On Tuesday, August 18, 2015 at 12:09:23 PM UTC+2, Sisyphuss wrote:
>>
>> Is `function sum{T<:FloatingPoint}(x::AbstractArray{T,1}) ` or
>> `function sum{T<:FloatingPoint}(x::AbstractVector{T}) ` better?
>>
>>
>> On Tuesday, August 18, 2015 at 11:29:15 AM UTC+2, René Donner wrote:
>>>
>>> Hi, 
>>>
>>> I think this does what you want: 
>>>
>>> function sum{T<:FloatingPoint}(x::Array{T,1}) 
>>>   println("hi") 
>>> end 
>>>
>>> Cheers, 
>>>
>>> Rene 
>>>
>>>
>>>
>>>
>>>
>>>
>>> Am 18.08.2015 um 11:22 schrieb Uwe Fechner : 
>>>
>>> > Ok, the following definition works on Julia 0.4, but not with 0.3: 
>>> > 
>>> > FloatArray = Union{Array{Float32, 1}, Array{Float64, 1}} 
>>> > 
>>> > function sum(x::FloatArray). 
>>> > 
>>> > Any idea? 
>>> > 
>>> > Am Dienstag, 18. August 2015 11:07:16 UTC+2 schrieb Uwe Fechner: 
>>> > Hello, 
>>> > 
>>> > I want to write a function, that can operate on any one dimensional 
>>> array of floating point numbers. 
>>> > 
>>> > The following works, but only for Float64: 
>>> > 
>>> > function sum(x::Array{Float64,1}) 
>>> > 
>>> > The following does not work: 
>>> > 
>>> > function sum(x::Array{AbstractFloat,1}) 
>>> > 
>>> > Any idea? 
>>> > 
>>> > Uwe 
>>>
>>>

Re: [julia-users] Segmentation fault during Julia compilation

[Mahesh Waidande]

Hi Jamseson,

Thanks for explaining memory allocations on PPC and providing pointers on
resolving segmentation fault, pointers are really helpful and I am working
on those. I am able to compile Julia master branch after turning ‘MEMDEBUG‘
flag on from options.h file, compilation went smooth and I am able to see
the Julia prompt. Although I will continue to work on finding root cause of
segmentation fault, occur at a time of Julia initialization.


I think when we turn on the ‘MEMDEBUG‘ flag it will reduce a performance of
Julia bit as with MEMDEBUG no memory pools are used and all allocation is
treated as big.


Apart from performance issue, I have few questions in my mind and I would
like to discuss those,
1. Apart from performance hit, is there any other functionality has
impacted due to turning on ‘MEMDEBUG’ flag OR what are side effects of
turning ‘MEMDEBUG’ flag on?
2. Should I use these settings (turning MEMDEBUG flag on) in production
environment or in release mode?


-Mahesh

On Fri, Aug 14, 2015 at 10:03 PM, Jameson Nash  wrote:

> It's a JIT copy of a julia function named "new". The last time this error
> popped up, it was due to an error in the free_page function logic to
> compute whether it was safe to free the current page (since PPC using large
> pages). One place to check then is to ensure the invalid pointer hadn't
> accidentally being deleted by an madvise(DONTNEED) for an unrelated page
> free operations.
>
> Beyond that, I would suggest trying with the `MEMDEBUG` turned on in
> options.h (which will also disable the `free_page` function).
>
> Also, when you have gdb running, there are many more useful things to
> print than just the backtrace. For starters, I would suggest looking at
> `disassembly` and `info registers`. Also, go `up` on the stack trace and
> look at `jl_(f->linfo)`, `jl_(jl_uncompress_ast(f->linfo, f->linfo->ast))`,
> and `jl_(args[0])` / `jl_(args[1])`
>
>
> On Fri, Aug 14, 2015 at 9:07 AM Mahesh Waidande <
> mahesh.waidande1...@gmail.com> wrote:
>
>> Hi All,
>>
>> I am working on building/porting Julia on ppc64le architecture. I am
>> using Ubuntu 14.10 on top of ppc64le hardware, while compiling Julia
>> code(master branch) I am getting segmentation fault. I tried to debug
>> segmentation fault with tools like gdb/vgdb , valgrind , electric-fence
>> etc. but I not able to find a root cause of it. I need some
>> help/pointers/suggestions on how I resolve it.
>>
>> Here are some details which will help you to diagnose a problem,
>>
>> 1. Machine details :
>> $ uname -a
>> Linux pts00433-vm1 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:07:11
>> UTC 2015 ppc64le ppc64le ppc64le GNU/Linux
>> $
>>
>> 2. Snapshot of ‘make debug’ log
>> make[1]: Leaving directory '/home/test/Mahesh/julia/julia/base'
>> make[1]: Entering directory '/home/test/Mahesh/julia/julia'
>>  cd base && /home/test/Mahesh/julia/julia/usr/bin/julia-debug -C native
>> --output-ji /home/test/Mahesh/julia/julia/usr/lib/julia/inference0.ji -f
>> coreimg.jl
>>
>>   Electric Fence 2.2 Copyright (C) 1987-1999 Bruce Perens <
>> br...@perens.com>
>> Segmentation fault
>> Makefile:175: recipe for target
>> '/home/test/Mahesh/julia/julia/usr/lib/julia/inference0.ji' failed
>> make[1]: *** [/home/test/Mahesh/julia/julia/usr/lib/julia/inference0.ji]
>> Error 139
>> make[1]: Leaving directory '/home/test/Mahesh/julia/julia'
>> Makefile:64: recipe for target 'julia-inference' failed
>> make: *** [julia-inference] Error 2
>>
>> 3. gdb stack trace
>> test@pts00433-vm1:~/Mahesh/julia/julia/base$ gdb --args
>> /home/test/Mahesh/julia/julia/usr/bin/julia-debug -C native --output-ji
>> /home/test/Mahesh/julia/julia/usr/lib/julia/inference0.ji -f coreimg.jl
>> GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs
>> Copyright (C) 2014 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "powerpc64le-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from
>> /home/test/Mahesh/julia/julia/usr/bin/julia-debug...done.
>> (gdb) b repl.c:532
>> Breakpoint 1 at 0x10003a34: file repl.c, line 532.
>> (gdb) r
>> Starting program: /home/test/Mahesh/julia/julia/usr/bin/julia-debug -C
>> native --output-ji
>> /home/test/Mahesh/julia/julia/usr/lib/julia/inference0.ji -f coreimg.jl
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library
>> "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
>>
>>   Electric Fence

Re: [julia-users] Re: How to define an array of floating point numbers?

[Kristoffer Carlsson]

They are the same. The vector is just a type alias for the array of size 1. 
Personally I like vector because to me it is clearer to read.

On Tuesday, August 18, 2015 at 12:09:23 PM UTC+2, Sisyphuss wrote:
>
> Is `function sum{T<:FloatingPoint}(x::AbstractArray{T,1}) ` or
> `function sum{T<:FloatingPoint}(x::AbstractVector{T}) ` better?
>
>
> On Tuesday, August 18, 2015 at 11:29:15 AM UTC+2, René Donner wrote:
>>
>> Hi, 
>>
>> I think this does what you want: 
>>
>> function sum{T<:FloatingPoint}(x::Array{T,1}) 
>>   println("hi") 
>> end 
>>
>> Cheers, 
>>
>> Rene 
>>
>>
>>
>>
>>
>>
>> Am 18.08.2015 um 11:22 schrieb Uwe Fechner : 
>>
>> > Ok, the following definition works on Julia 0.4, but not with 0.3: 
>> > 
>> > FloatArray = Union{Array{Float32, 1}, Array{Float64, 1}} 
>> > 
>> > function sum(x::FloatArray). 
>> > 
>> > Any idea? 
>> > 
>> > Am Dienstag, 18. August 2015 11:07:16 UTC+2 schrieb Uwe Fechner: 
>> > Hello, 
>> > 
>> > I want to write a function, that can operate on any one dimensional 
>> array of floating point numbers. 
>> > 
>> > The following works, but only for Float64: 
>> > 
>> > function sum(x::Array{Float64,1}) 
>> > 
>> > The following does not work: 
>> > 
>> > function sum(x::Array{AbstractFloat,1}) 
>> > 
>> > Any idea? 
>> > 
>> > Uwe 
>>
>>

Re: [julia-users] range and NaN

[Michele Zaffalon]

Apologies and thank you.
http://docs.julialang.org/en/latest/stdlib/math/?highlight=range#Base.range


On Tue, Aug 18, 2015 at 3:11 PM, Milan Bouchet-Valat 
wrote:

> Le mardi 18 août 2015 à 06:04 -0700, Michele Zaffalon a écrit :
> > Are `collect(a:b)` and `collect(range(a, b))` supposed to give the
> > same results? Does the following make sense?
> >
> >
> > julia> typeof(NaN:5)
> > FloatRange{Float64}
> >
> > julia> collect(NaN:5)
> > 0-element Array{Float64,1}
> >
> > julia> typeof(range(NaN, 5))
> > FloatRange{Float64}
> >
> > julia> collect(range(NaN, 5))
> > 5-element Array{Float64,1}:
> >  NaN
> >  NaN
> >  NaN
> >  NaN
> >  NaN
> >
> > This is on 0.4.0, commit 6becc96 on Windows 7 64 bit.
> > michele
> The difference isn't in collect(), it's in the creation of the range.
> range() expects a length as its second argument, while the colon syntax
> takes the end value instead. So you're not creating the same range at
> all.
>
> BTW, you can use dump() to see the fields of the created range, which
> allows you to check what's actually created.
>
>
> Regards
>

[julia-users] Re: Problems with docile on travis / conditional require?

[Michael Hatherly]

>From what I can see in that travis log this is not a problem on 0.3, hence 
not really a Docile problem. It looks like the Julia 0.4 version being used 
on travis is older than the fix 
 for the

LoadError: error in method definition: function Base.sum must be explicitly 
imported to be extended

error that you’re seeing there. You'll need to wait until the version is 
updated I guess.

Also note that you only need to import Docile in Julia 0.3 if you are using 
@doc. Bare docstrings can be used without importing the package.

— Mike
On Tuesday, 18 August 2015 14:13:26 UTC+2, Uwe Fechner wrote:
>
> Hello,
>
> I solved my problems with Docile on my local machine (see: 
> https://groups.google.com/forum/#!topic/julia-users/ukvwAI52u0Y ),
> but now it appears on travis:
>
> My pull request passes on Julia 0.3, but fails on Julia 0.4:
> https://github.com/mlubin/NaNMath.jl/pull/4
>
> Here you can see the error message:
> https://travis-ci.org/mlubin/NaNMath.jl/jobs/76089910
>
> In short:
>
> ERROR: LoadError: LoadError: error in method definition: function Base.sum 
> must be explicitly imported to be extended
>
> Perhaps this would not happen, if I could say that Docile is only required 
> for Julia 0.3 and
> not for Julia 0.4, but I don't know how to specify this in the REQUIRE file.
>
> Any idea?
>
> Uwe
>
>
>

Re: [julia-users] range and NaN

[Milan Bouchet-Valat]

Le mardi 18 août 2015 à 06:04 -0700, Michele Zaffalon a écrit :
> Are `collect(a:b)` and `collect(range(a, b))` supposed to give the 
> same results? Does the following make sense?
> 
> 
> julia> typeof(NaN:5)
> FloatRange{Float64}
> 
> julia> collect(NaN:5)
> 0-element Array{Float64,1}
> 
> julia> typeof(range(NaN, 5))
> FloatRange{Float64}
> 
> julia> collect(range(NaN, 5))
> 5-element Array{Float64,1}:
>  NaN
>  NaN
>  NaN
>  NaN
>  NaN
> 
> This is on 0.4.0, commit 6becc96 on Windows 7 64 bit.
> michele
The difference isn't in collect(), it's in the creation of the range.
range() expects a length as its second argument, while the colon syntax
takes the end value instead. So you're not creating the same range at
all.

BTW, you can use dump() to see the fields of the created range, which
allows you to check what's actually created.


Regards

[julia-users] range and NaN

[Michele Zaffalon]

Are `collect(a:b)` and `collect(range(a, b))` supposed to give the same 
results? Does the following make sense?


julia> typeof(NaN:5)
FloatRange{Float64}

julia> collect(NaN:5)
0-element Array{Float64,1}

julia> typeof(range(NaN, 5))
FloatRange{Float64}

julia> collect(range(NaN, 5))
5-element Array{Float64,1}:
 NaN
 NaN
 NaN
 NaN
 NaN

This is on 0.4.0, commit 6becc96 on Windows 7 64 bit.
michele

Re: [julia-users] JuliaCon 2015 videos

[Waldir Pimenta]

Same for Shashi's session.

On Monday, August 17, 2015 at 11:32:26 PM UTC+1, Keno Fischer wrote:
>
> Whoever owns the youtube channel should put an annotation that allows 
> users o click on it to skip that part.
>
> On Mon, Aug 17, 2015 at 8:08 PM, Sisyphuss  > wrote:
>
>> In the Keno's video, he spent more than 5 minutes to go through the 
>> technical difficulty. 
>> I think this can be cut to save time.
>>
>>  
>>
>> On Monday, August 17, 2015 at 3:30:48 PM UTC+2, Viral Shah wrote:
>>>
>>> One more batch: 
>>>
>>> 1. Iain Dunning: JuliaOpt - Optimization related projects in Julia: 
>>> http://youtu.be/ZibQdqR6gqc?a 
>>> 2. Yee Sian Ng: JuliaGeo - Working with Geospatial data in Julia: 
>>> http://youtu.be/MLGFzPS4FTg?a 
>>> 3. Isaiah Norton: Automatic ccall wrapper generation with Clang.jl: 
>>> http://youtu.be/Jt5sv-8iRGc?a 
>>> 4. Simon Kornblith: L1 regularized regression: 
>>> http://youtu.be/z4Zcud2vE0s?a   
>>> 5. Tony Fong: Lint.jl - Building a Lint tool for Julia: 
>>> http://youtu.be/9T3R14R3X7k?a   
>>> 6. Douglas Bates: Adventures with Statistical Models and Sparse 
>>> Matrices: http://youtu.be/lSr0oRfyd1Y?a   
>>>
>>> -viral 
>>>
>>> > On 17-Aug-2015, at 2:25 am, Viral Shah  wrote: 
>>> > 
>>> > A few more: 
>>> > 
>>> > 1. Blake Johnson: Quickly building simulations of quantum systems: 
>>> http://youtu.be/kogTKuytg1g?a   
>>> > 2. Katharine Hyatt: Quantum Statistical Simulations with Julia: 
>>> http://youtu.be/QThApV3HIxc?a   
>>> > 3. Making GUIs with Escher jl: http://youtu.be/Sq7DEnV4dfI?a 
>>> > 4. John Myles White: What needs to be done to move JuliaStats forward: 
>>> http://youtu.be/lf1_FhMR7xA?a 
>>> > 5. Jacob Quinn: Managing Data in Julia Old Tricks, New Tricks: 
>>> http://youtu.be/QLWhsZ3yzBk?a   
>>> > 
>>> > -viral 
>>> > 
>>> > 
>>> > 
>>> >> On 16-Aug-2015, at 11:15 am, Viral Shah  wrote: 
>>> >> 
>>> >> Next set: 
>>> >> 
>>> >> 1. Avik Sengupta: A practical guide to exposing Julia APIs on the 
>>> web: http://youtu.be/o40OpLe2k7Q?a   
>>> >> 2. Hongbo Rong: Accelerating sparse matrix kernels in Julia: 
>>> http://youtu.be/k40K2zJVv0A?a   
>>> >> 3. Luis Benet: Taylor series expansions in Julia: 
>>> http://youtu.be/6zrQuq5mODQ?a 
>>> >> 4. Westley Hennigh: Who optimizes the optimizers: 
>>> http://youtu.be/Qito5AGSv4s?a 
>>> >> 5. Mauro Werder: Interfaces for Julia -Traits.jl: 
>>> youtu.be/j9w8oHfG1Ic?a   
>>> >> 6. David Gold: Nullable arrays - http://youtu.be/2v5k28F80BQ?a   
>>> >> 
>>> >> -viral 
>>> >> 
>>> >> 
>>> >> 
>>> >>> On 16-Aug-2015, at 12:01 am, Viral Shah  wrote: 
>>> >>> 
>>> >>> Next set: 
>>> >>> 
>>> >>> 1. Sebastien Martin: Taxi fleet simulation and visualization: 
>>> http://youtu.be/MjERK9Xajrg?a 
>>> >>> 2. Bob Carpenter: Stan.jl - Statistical Modeling and Inference Made 
>>> Easy: http://youtu.be/YdgMJ37CDws?a 
>>> >>> 3. Pontus Stenetorp: Suitably Naming a Child with Multiple 
>>> Nationalities: http://youtu.be/MJzRf3Exlqc?a   
>>> >>> 4. Chiyuan Zhang: Mocha.jl - Deep Learning for Julia: 
>>> http://youtu.be/ljySoebYylE?a   
>>> >>> 5. Kiran Pamnany and Ranjan Anantharaman: Multi-threading Julia: 
>>> http://youtu.be/GvLhseZ4D8M?a 
>>> >>> 6. St. Louis University - Text Mining Research Group: TextMining.jl: 
>>> http://youtu.be/dgfIIZ5yA4E?a 
>>> >>> 7. Zachary Yedidia: SFML.jl - Julia bindings for the Simple Fast: 
>>> http://youtu.be/UKfM7EopMe0?a   
>>> >>> 
>>> >>> -viral 
>>> >>> 
>>> >>> 
>>> >>> 
>>>  On 15-Aug-2015, at 10:07 am, Viral Shah  wrote: 
>>>  
>>>  One more batch posted: 
>>>  
>>>  1. Jacob Quinn: Composable streams for data transfer and processing 
>>> - http://t.co/DPuN42F3Qu 
>>>  2. Tanmay Mohapatra: Interfacing Julia with Complex systems using 
>>> Protocol Buffers - http://t.co/Ddxj60KL7g 
>>>  3. Eric Davies: Towards A Consistent Database Interface - 
>>> http://t.co/vdQwFRp7aD 
>>>  4. Viral Shah: The present and future of sparse matrices in Julia - 
>>> http://t.co/WVQY89GsiT 
>>>  5. Jake Bolewski: Staged programming in Julia - 
>>> http://t.co/XlYl2XGB9O 
>>>  6. Robert Moss: Julia as a Specification Language for the 
>>> next-generation Airborne Collision Avoidance System - 
>>> http://t.co/QJN2ZfP1ZI 
>>>  
>>>  -viral 
>>>  
>>>  On Friday, August 14, 2015 at 7:33:04 PM UTC+5:30, Viral Shah 
>>> wrote: 
>>>  Here are the next batch of videos. There is a JuliaCon 2015 channel 
>>> now: 
>>>  
>>>  
>>> https://www.youtube.com/playlist?list=PLP8iPy9hna6Sdx4soiGrSefrmOPdUWixM 
>>>  
>>>  This batch includes: 
>>>  
>>>  David Sanders: Validated numerics in Julia - http://t.co/WRZcYGjhfl 
>>>  Patrick Sanan: Using Julia on a Cray Supercomputer - 
>>> https://youtu.be/NwyKz2KLdtY 
>>>  Keno Fischer: Shaving the Yak - http://t.co/cEJqCqAdRC 
>>>  Spencer Lyon: Methods, Models, and Moments - Julian Economics with 
>>> QuantEcon.jl - http://t.co/l0f5CH6k3u 
>>>  Randy Zwitch: Everyday Analytics and Visualization - 
>>

Re: [julia-users] Constructor or convert(), Upper case or lower case

[Yichao Yu]

On Tue, Aug 18, 2015 at 6:04 AM, Sisyphuss  wrote:
> We use `Int8(x)` to construct an `Int8`,
> but use `float(x)` to convert to a floating point.

Float is not a type. FWIW, `AbstractFloat(1)` works.

>
> We defines `Symbol` as an object,
> but use `symbol()` to construct symbols.

`Symbol("a")` works, just not for arbitrary types as `symbol`.
However, `Int*` don't allow converting from arbitrary types either so
it is consistent. From what I understand, `int*` are deprecated
because you should be explicit about what you want to do. For symbols
this is less of an issue.

>
> I am so confusing.

Hopefully you don't literally mean this.

Re: [julia-users] Re: Array Index Limits

[lawrence dworsky]

This sounds like the right approach. I'll try it soon and report what I
did/didn't succeed at.​  Thanks.

On Mon, Aug 17, 2015 at 6:10 PM, Matt Bauman  wrote:

> One way to make OffsetArrays safe would be to make them index normally
> with integer indices, but introduce a *new* Integer type that gives it the
> special offset behavior.  You could name it something short, like F (for
> Fortran or oFFset) to reduce typing:
>
> `A[F(-10), F(0)]`
>
> ... and you could do even better by making it construct by multiplication
> with the typename:
>
> `A[-10F, 0F]`
>
> Or even better, you should be able to write a macro that automatically
> converts all indices to this special type:
>
> `@offset A[-10,0]` # This also could disallow the pesky end keyword!
>
> I was playing with RaggedArrays over the weekend, and there I had to solve
> a similar problem because there are two possible meanings for linear
> indexing.  So I just created a LinearIndex type that behaves differently:
> https://github.com/mbauman/RaggedArrays.jl/blob/d2b6aeb854855c7912c104cb5312c13e989f2cf4/src/core.jl#L229-L247
>
> Matt
>
> On Monday, August 17, 2015 at 4:36:27 PM UTC-4, lawrence dworsky wrote:
>>
>> Thanks for putting your time into this. Right now I'm still using 0.3.11,
>> waiting for 0.4 to be the standard release. Then I'll dig into this and see
>> if I get it to do what I want without undue aggravation. I had the same
>> indexing issue with MatLab. Sometimes I miss the brute straightforwardness
>> of Fortran.
>>
>> Larry
>>
>>
>> On Mon, Aug 17, 2015 at 1:16 PM, Matt Bauman  wrote:
>>
>>> On Monday, August 17, 2015 at 1:03:17 PM UTC-4, Sisyphuss wrote:

 I read the "interfaces
 " chapter of
 the documentation today. I learned that, if you define an iterable as a
 subtype of AbstractArray, with only defining three methods (including
 `size()`, excluding `start()`), you can iterate on it just like iterate on
 an normal Array.

>>>
>>> Iteration should work just fine in 0.4 if OffsetArray defines its own
>>> `eachindex` method.
>>>
>>> Although more and more for loops are written generically using
>>> `eachindex`, there are still a lot of methods that use the old linear
>>> indexing standby:
>>>
>>> for i=1:length(A)
>>>@inbounds A[i] = …
>>> end
>>>
>>> This is where things get really hairy for OffsetArrays.  That
>>> `@inbounds` propagates through to the inner array assignment, which will
>>> lead to silent data corruption and/or segfaults.  That's really why it
>>> shouldn't be an AbstractArray.
>>>
>>
>>

[julia-users] Problems with docile on travis / conditional require?

[Uwe Fechner]

Hello,

I solved my problems with Docile on my local machine (see: 
https://groups.google.com/forum/#!topic/julia-users/ukvwAI52u0Y ),
but now it appears on travis:

My pull request passes on Julia 0.3, but fails on Julia 0.4:
https://github.com/mlubin/NaNMath.jl/pull/4

Here you can see the error message:
https://travis-ci.org/mlubin/NaNMath.jl/jobs/76089910

In short:

ERROR: LoadError: LoadError: error in method definition: function Base.sum must 
be explicitly imported to be extended

Perhaps this would not happen, if I could say that Docile is only required for 
Julia 0.3 and
not for Julia 0.4, but I don't know how to specify this in the REQUIRE file.

Any idea?

Uwe

Re: [julia-users] Metaprogramming: the use of `$`

[Yichao Yu]

On Tue, Aug 18, 2015 at 6:49 AM, Sisyphuss  wrote:
> I'm reading the documentation Metaprogramming chapter.
> To me, the `$` operator is different from the one in the string
> interpolation.
> In the string, `$` is a runtime interpolation.
> In the expression, `$` is a compile-time interpolation.

No. Both of them happens at whenever the expression is evaluated. It
happens for `@eval` at "compile time" because that's when the macro
expansion happens.

>
> In one example provided, `ex = :(a in $:((1,2,3)) )`,
> I find that it's equal to `ex = :(a in (1,2,3) )`.
> So I do not see the intention of `$`.

The examples are meant to show you the basic rules not necessarily the
best/only way to do it.

>
> In the next example, there is `:a + :b` in the expression,
> but the sum of `Symbols` is not defined. Is it wrong?

It just construct an expression and to show you that the result is
quoted symbol rather than the symbol themselves.

Re: [julia-users] Re: A cheat page for Julia

[Scott Jones]

Well, even a Bactrian camel’s humps are in the middle, not right on top of 
his bum!

The camel case conventions IIRC were really popularized first by Smalltalk, 
then by Wirth with Pascal and Modula, and also (later) by Microsoft.

Another 
reference: https://msdn.microsoft.com/en-us/library/x2dbyw72(v=vs.71).aspx

On Tuesday, August 18, 2015 at 7:13:57 AM UTC-4, Milan Bouchet-Valat wrote:
>
> Le lundi 17 août 2015 à 22:01 -0700, Scott Jones a écrit : 
> > > On Monday, August 17, 2015 at 4:14:25 PM UTC-4, Steven G. Johnson 
> > > wrote: 
> > > I think the term "CamelCase" is more common than "Pascal case"; if 
> > > you write it as "CamelCase" it is clear that it starts with caps. 
> > > 
> > I've heard Pascal case to indicate starting out with caps, but Camel 
> > case more often refers to lower case first letter.  (i.e. there is a 
> > hump in the *middle* of the name, like a camel). 
> Well, "camel" is ambiguous. Lower case first letters certainly match 
> the dromedary camel... :-) 
>
> https://en.wikipedia.org/wiki/Camel 
>
>
> Regards 
>
> > Here's the definition from Wikipedia: 
> > > Although the first letter of a camel case compound word may or may 
> > > not be capitalized, the term camel case generally implies lowercase 
> > > first letter.[2][3] For clarity, this article calls the two 
> > > alternatives upper camel case and lower camel case. Some people and 
> > > organizations use the term camel case only for lower camel case. 
> > > Other synonyms include: 
> >   
>

Re: [julia-users] Re: A cheat page for Julia

[Milan Bouchet-Valat]

Le lundi 17 août 2015 à 22:01 -0700, Scott Jones a écrit :
> > On Monday, August 17, 2015 at 4:14:25 PM UTC-4, Steven G. Johnson 
> > wrote:
> > I think the term "CamelCase" is more common than "Pascal case"; if 
> > you write it as "CamelCase" it is clear that it starts with caps.
> > 
> I've heard Pascal case to indicate starting out with caps, but Camel 
> case more often refers to lower case first letter.  (i.e. there is a 
> hump in the *middle* of the name, like a camel).
Well, "camel" is ambiguous. Lower case first letters certainly match
the dromedary camel... :-)

https://en.wikipedia.org/wiki/Camel


Regards

> Here's the definition from Wikipedia:
> > Although the first letter of a camel case compound word may or may 
> > not be capitalized, the term camel case generally implies lowercase 
> > first letter.[2][3] For clarity, this article calls the two 
> > alternatives upper camel case and lower camel case. Some people and 
> > organizations use the term camel case only for lower camel case. 
> > Other synonyms include:
>  

[julia-users] Re: A cheat page for Julia

[Sisyphuss]

On Monday, August 17, 2015 at 10:14:25 PM UTC+2, Steven G. Johnson wrote:
>
> Comments:
>
> Your "subtype declaration" section is wrong: the abstract type does not 
> define a block (you should just have "abstract Foo", not "abstract Foo ... 
> end")
>
> The "String" type is deprecated in favor of AbstractString in 0.4
>
> [1:10] is deprecated in 0.4, in favor of [1:10;] to explicitly vcat.
>
> You can just use +, not .+, for element-wise addition.  (It doesn't hurt 
> to do .+, but it is unnecessary.)
>
> help("func") is gone in 0.4
>
> Pkg.build("Package") is useful to rebuild a package if the package build 
> failed or your system configuration changed.
>
> char(n) is deprecated in favor of Char(n) in 0.4
>
> "Beware of multi-byte Unicode characters" is a bit misleading; it is not 
> the Unicode "character" (technically you are referring to "codepoints") 
> that is multi-byte, but rather the codepoint's *encoding* in UTF-8 (the 
> default in Julia).  Maybe "Beware of multi-byte Unicode encodings in UTF-8"
>
> (Of course, there are many other subtleties with Unicode: e.g. your 
> example string "Ångström" can also be written "Ångström", which looks 
> identical but actually uses a different set of codepoints via "combining 
> characters".)
>
> UintN in Julia 0.4 is deprecated in favor of UIntN (note caps).
>
> Note there is also Complex{T}; Complex128 is just a shorthand for 
> Complex{Float64}.
>
> im is the "imaginary unit", not the "imaginary number".
>
> eps() is an abbreviation for eps(Float64).  eps(T) is also defined for 
> other types.
>
> In 0.4, TypeName(val) automatically calls convert(TypeName, val) if no 
> other constructor is available.   This also means that, when you are 
> defining your own type, you should extend Base.convert if you have new 
> conversions, rather than adding constructors.
>
> eye(N) is an NxN identity; calling it "N-dimensional" may confuse people 
> into thinking it returns an N-dimensional array.
>
> M' is a synonym for ctranspose(M) (conjugate transpose).  M.' is 
> transpose(M) without conjugation.  Of course, for real matrices they are 
> equivalent.
>
> Note that we can also do "for i in 1:10" ... this syntax is perhaps a bit 
> clearer in that it generalizes to iterating over other kinds of containers.
>
> To exit a loop you do "break", not "exit" (which is a function).
>
> Functions with ! appended mutate at least one of their arguments.   Not 
> necessarily the first one (e.g. see A_ldiv_B!), although this is the most 
> common.
>
> If you need tail-call optimization, it is more idiomatic to simply write a 
> loop.
>
> Instead of in(val,arr), you can simply do "val in arr"
>
> The dictionary syntax has changed in 0.4: use Dict(a=>b, ...)
>
> {...} is deprecated in 0.4.  Use Any[...].
>
> it is more idiomatic to put "do" on the same line:
>
> map(collection) do elem
>...
> end
>
>
> You can override Base.show(io, ex) rather than Base.showerror.
>
> "import ModuleName" does *not* import "all names".  It imports the module, 
> but the only symbol imported is ModuleName itself; everything else must be 
> accessed via ModuleName.something.
>

Or `importall MyModule` ?
 

>
> You should think of macros as being evaluated at parse-time, not run-time. 
>  Basically:
> * a macro is a function evaluated at parse-time that takes an 
> expression in and returns an expression out, and the latter is inserted 
> into the parsed code.
> * a generated function is a function evaluated at compile-time which 
> takes types in and returns an expression out, which is inserted into the 
> code and compiled
> * an ordinary function is a function evaluated at run-time which takes 
> values in and returns values out.
>
> @test_approx_eq does not check equality to machine precision.  It checks 
> equality at much lower precision.  In 0.4, you can also just use @test x ≈ 
> y, where ≈ is \approx and is a synonym for the isapprox function.
>
> The typical convention in Julia is to avoid underscores unless they are 
> needed for readability.  i.e. we have iseven, not is_even.  This does not 
> differ for variables vs. functions.
>
> I think the term "CamelCase" is more common than "Pascal case"; if you 
> write it as "CamelCase" it is clear that it starts with caps.
>
> For performance, you should avoid abstract types in collections, but also 
> as fields of types.
>

I thinks using abstract types as fields doesn't hurt much, except that the 
object will be packed into an Array.
 

[julia-users] Metaprogramming: the use of `$`

[Sisyphuss]

I'm reading the documentation Metaprogramming 
 chapter. 
To me, the `$` operator is different from the one in the string 
interpolation.
In the string, `$` is a runtime interpolation.
In the expression, `$` is a compile-time interpolation.

In one example provided, `ex = :(a in $:((1,2,3)) )`,
I find that it's equal to `ex = :(a in (1,2,3) )`.
So I do not see the intention of `$`.

In the next example, there is `:a + :b` in the expression,
but the sum of `Symbols` is not defined. Is it wrong?

Re: [julia-users] Re: How to define an array of floating point numbers?

[Sisyphuss]

Is `function sum{T<:FloatingPoint}(x::AbstractArray{T,1}) ` or
`function sum{T<:FloatingPoint}(x::AbstractVector{T}) ` better?


On Tuesday, August 18, 2015 at 11:29:15 AM UTC+2, René Donner wrote:
>
> Hi, 
>
> I think this does what you want: 
>
> function sum{T<:FloatingPoint}(x::Array{T,1}) 
>   println("hi") 
> end 
>
> Cheers, 
>
> Rene 
>
>
>
>
>
>
> Am 18.08.2015 um 11:22 schrieb Uwe Fechner  >: 
>
> > Ok, the following definition works on Julia 0.4, but not with 0.3: 
> > 
> > FloatArray = Union{Array{Float32, 1}, Array{Float64, 1}} 
> > 
> > function sum(x::FloatArray). 
> > 
> > Any idea? 
> > 
> > Am Dienstag, 18. August 2015 11:07:16 UTC+2 schrieb Uwe Fechner: 
> > Hello, 
> > 
> > I want to write a function, that can operate on any one dimensional 
> array of floating point numbers. 
> > 
> > The following works, but only for Float64: 
> > 
> > function sum(x::Array{Float64,1}) 
> > 
> > The following does not work: 
> > 
> > function sum(x::Array{AbstractFloat,1}) 
> > 
> > Any idea? 
> > 
> > Uwe 
>
>

[julia-users] Constructor or convert(), Upper case or lower case

[Sisyphuss]

We use `Int8(x)` to construct an `Int8`,
but use `float(x)` to convert to a floating point.

We defines `Symbol` as an object,
but use `symbol()` to construct symbols.

I am so confusing.

Re: [julia-users] Re: How to define an array of floating point numbers?

[Uwe Fechner]

Thank's a lot, that is cool.

Am Dienstag, 18. August 2015 11:29:44 UTC+2 schrieb Pontus Stenetorp:
>
> On 18 August 2015 at 10:22, Uwe Fechner  > wrote: 
> > 
> > Ok, the following definition works on Julia 0.4, but not with 0.3: 
> > 
> > FloatArray = Union{Array{Float32, 1}, Array{Float64, 1}} 
> > 
> > function sum(x::FloatArray). 
> > 
> > Any idea? 
>
> I would simply go with: 
>
> function mysum{T<:FloatingPoint}(x::Vector{T}) sum(x) end 
>

Re: [julia-users] Re: How to define an array of floating point numbers?

[Pontus Stenetorp]

On 18 August 2015 at 10:22, Uwe Fechner  wrote:
>
> Ok, the following definition works on Julia 0.4, but not with 0.3:
>
> FloatArray = Union{Array{Float32, 1}, Array{Float64, 1}}
>
> function sum(x::FloatArray).
>
> Any idea?

I would simply go with:

function mysum{T<:FloatingPoint}(x::Vector{T}) sum(x) end

Re: [julia-users] Re: How to define an array of floating point numbers?

[René Donner]

Hi,

I think this does what you want:

function sum{T<:FloatingPoint}(x::Array{T,1})
  println("hi")
end

Cheers,

Rene






Am 18.08.2015 um 11:22 schrieb Uwe Fechner :

> Ok, the following definition works on Julia 0.4, but not with 0.3:
> 
> FloatArray = Union{Array{Float32, 1}, Array{Float64, 1}}
> 
> function sum(x::FloatArray).
> 
> Any idea?
> 
> Am Dienstag, 18. August 2015 11:07:16 UTC+2 schrieb Uwe Fechner:
> Hello,
> 
> I want to write a function, that can operate on any one dimensional array of 
> floating point numbers.
> 
> The following works, but only for Float64:
> 
> function sum(x::Array{Float64,1})
> 
> The following does not work:
> 
> function sum(x::Array{AbstractFloat,1})
> 
> Any idea?
> 
> Uwe

[julia-users] Re: How to define an array of floating point numbers?

[Uwe Fechner]

Ok, the following works for 0.3 and 0.4:
FloatArray = Union(Array{Float32, 1}, Array{Float64, 1})

Is this the best way to define an array of floating point numbers?

Am Dienstag, 18. August 2015 11:22:50 UTC+2 schrieb Uwe Fechner:
>
> Ok, the following definition works on Julia 0.4, but not with 0.3:
>
> FloatArray = Union{Array{Float32, 1}, Array{Float64, 1}}
>
> function sum(x::FloatArray).
>
> Any idea?
>
> Am Dienstag, 18. August 2015 11:07:16 UTC+2 schrieb Uwe Fechner:
>>
>> Hello,
>>
>> I want to write a function, that can operate on any one dimensional array 
>> of floating point numbers.
>>
>> The following works, but only for Float64:
>>
>> function sum(x::Array{Float64,1})
>>
>> The following does not work:
>>
>> function sum(x::Array{AbstractFloat,1})
>>
>> Any idea?
>>
>> Uwe
>>
>

[julia-users] Re: How to define an array of floating point numbers?

[Uwe Fechner]

Ok, the following definition works on Julia 0.4, but not with 0.3:

FloatArray = Union{Array{Float32, 1}, Array{Float64, 1}}

function sum(x::FloatArray).

Any idea?

Am Dienstag, 18. August 2015 11:07:16 UTC+2 schrieb Uwe Fechner:
>
> Hello,
>
> I want to write a function, that can operate on any one dimensional array 
> of floating point numbers.
>
> The following works, but only for Float64:
>
> function sum(x::Array{Float64,1})
>
> The following does not work:
>
> function sum(x::Array{AbstractFloat,1})
>
> Any idea?
>
> Uwe
>

[julia-users] How to define an array of floating point numbers?

[Uwe Fechner]

Hello,

I want to write a function, that can operate on any one dimensional array 
of floating point numbers.

The following works, but only for Float64:

function sum(x::Array{Float64,1})

The following does not work:

function sum(x::Array{AbstractFloat,1})

Any idea?

Uwe

Re: [julia-users] type checking arrays

[Mauro]

This is invariance striking.  There should probably a FAQ entry for this
as it is often discussed:
https://groups.google.com/forum/#!searchin/julia-users/invariance

Docs:
http://docs.julialang.org/en/release-0.3/manual/types/#parametric-composite-types

On Tue, 2015-08-18 at 09:37, Kevin Kunzmann  wrote:
> Hi guys,
>
> So, I recently revisited Julia and fooled around a bit with Julia Box. 
> Amazing - this looks like the language I never actually dared dreaming of 
> ;) Keep up the greedy work!
>
> That being said, my question might be dumb, but I am struggling with the 
> type system of Julia. I want to guarantee that the arguments to a function 
> are numerical arrays of dimension 1 - how would I best do that in Julia? 
> The problem is that
>
> Array{Number, 1}
>
> exists as a type, but when I get the type system right it should not have 
> any subtypes except union. Especially
>
> Array{Float64, 1} <: Array{Number, 1}
>
> evaluates to ' false'. I think I get why this is implemented the way it is, 
> however, would it not be most intuitive to have something like
>
> function f(x::Array{Number, 1})
> x
> end
>
>
> What would be the 'Julian' way of doing this?

function f{T<:Number}(x::Array{T, 1})
x
end

Re: [julia-users] type checking arrays

[Kevin Kunzmann]

Great, thanks - that makes so much more sense x)

On Tuesday, 18 August 2015 10:10:40 UTC+2, Milan Bouchet-Valat wrote:
>
> Le mardi 18 août 2015 à 00:37 -0700, Kevin Kunzmann a écrit : 
> > Hi guys, 
> > 
> > So, I recently revisited Julia and fooled around a bit with Julia 
> > Box. Amazing - this looks like the language I never actually dared 
> > dreaming of ;) Keep up the greedy work! 
> > 
> > That being said, my question might be dumb, but I am struggling with 
> > the type system of Julia. I want to guarantee that the arguments to a 
> > function are numerical arrays of dimension 1 - how would I best do 
> > that in Julia? The problem is that 
> > 
> > Array{Number, 1} 
> > 
> > exists as a type, but when I get the type system right it should not 
> > have any subtypes except union. Especially 
> > 
> > Array{Float64, 1} <: Array{Number, 1} 
> > 
> > evaluates to ' false'. I think I get why this is implemented the way 
> > it is, however, would it not be most intuitive to have something like 
> > 
> > function f(x::Array{Number, 1}) 
> > x 
> > end 
> > 
> > 
> > What would be the 'Julian' way of doing this? 
> f{T<:Number}(x::Array{T, 1}) or 
> f{T<:Number}(x::Vecotr{T}) 
>
> You're hitting a subtle point which has to do with covariance vs. 
> invariance of types. This part of the manual should make it clearer, 
> but feel free to ask for more explanations: 
> http://docs.julialang.org/en/latest/manual/types/?highlight=covariance# 
> parametric-composite-types 
> 
>  
>
>
> Regards 
>

Re: [julia-users] type checking arrays

[Milan Bouchet-Valat]

Le mardi 18 août 2015 à 00:37 -0700, Kevin Kunzmann a écrit :
> Hi guys,
> 
> So, I recently revisited Julia and fooled around a bit with Julia 
> Box. Amazing - this looks like the language I never actually dared 
> dreaming of ;) Keep up the greedy work!
> 
> That being said, my question might be dumb, but I am struggling with 
> the type system of Julia. I want to guarantee that the arguments to a 
> function are numerical arrays of dimension 1 - how would I best do 
> that in Julia? The problem is that
> 
> Array{Number, 1}
> 
> exists as a type, but when I get the type system right it should not 
> have any subtypes except union. Especially
> 
> Array{Float64, 1} <: Array{Number, 1}
> 
> evaluates to ' false'. I think I get why this is implemented the way 
> it is, however, would it not be most intuitive to have something like
> 
> function f(x::Array{Number, 1})
> x
> end
> 
> 
> What would be the 'Julian' way of doing this?
f{T<:Number}(x::Array{T, 1}) or
f{T<:Number}(x::Vecotr{T})

You're hitting a subtle point which has to do with covariance vs.
invariance of types. This part of the manual should make it clearer,
but feel free to ask for more explanations:
http://docs.julialang.org/en/latest/manual/types/?highlight=covariance#
parametric-composite-types


Regards

[julia-users] type checking arrays

[Kevin Kunzmann]

Hi guys,

So, I recently revisited Julia and fooled around a bit with Julia Box. 
Amazing - this looks like the language I never actually dared dreaming of 
;) Keep up the greedy work!

That being said, my question might be dumb, but I am struggling with the 
type system of Julia. I want to guarantee that the arguments to a function 
are numerical arrays of dimension 1 - how would I best do that in Julia? 
The problem is that

Array{Number, 1}

exists as a type, but when I get the type system right it should not have 
any subtypes except union. Especially

Array{Float64, 1} <: Array{Number, 1}

evaluates to ' false'. I think I get why this is implemented the way it is, 
however, would it not be most intuitive to have something like

function f(x::Array{Number, 1})
x
end


What would be the 'Julian' way of doing this?

Best,

Kevin