Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[lapeyre . math122a]

I was told that SJulia is broken on recent versions of Julia.
This is fixed now. It should work with most versions of 0.4, 0.5, and 0.6

https://github.com/jlapeyre/SJulia.jl

On Saturday, September 3, 2016 at 5:47:26 PM UTC+2, lapeyre@gmail.com 
wrote:
>
>
>
> On Saturday, September 3, 2016 at 4:13:20 PM UTC+2, Andrew Dabrowski wrote:
>>
>> But what about nested pattern matching, or destructuring, isn't that much 
>> easier in Mathematica than Julia?  For example defining a function of two 
>> lists by
>> f[{w_,x_}, {y_,z_}]:=x y/(w+z).
>>
>> I remember reading the Julia manifesto a few years ago, where the stated 
>> goal was to create a single computing language that would replace Fortran, 
>> scipy, Mathematica, Matlab, etc. simultaneously.  I thought at the time 
>> that it sounded nuts. 
>>
>> Can we all agree now that it was, in fact, nuts? 
>>
>
> This is already implemented in SJulia:
>
>   sjulia 1> f([w_,x_], [y_,z_]) := x * y/(w+z)
>
>   sjulia 2> f([a,b],[c,d])
>
>   Out(2) = b*c*((a + d)^(-1))
>
> I have implemented several of Mma's pattern matching features. But, Mma's 
> pattern matching is sophisticated. I have not implemented, for instance, 
> associative-commutative matching, which Mma considers "structural" 
> matching.  I experimented a bit with using SJulia features from julia.  
> Without looking at it now, I guess it would take some work to access the 
> pattern matching.
>
> Maybe you can also do this kind of destructuring matching with this
>
>  https://github.com/toivoh/PatternDispatch.jl
>
> which aims to add pattern matching to method dispatch.
>
>

Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[lapeyre . math122a]

On Saturday, September 3, 2016 at 4:13:20 PM UTC+2, Andrew Dabrowski wrote:
>
> But what about nested pattern matching, or destructuring, isn't that much 
> easier in Mathematica than Julia?  For example defining a function of two 
> lists by
> f[{w_,x_}, {y_,z_}]:=x y/(w+z).
>
> I remember reading the Julia manifesto a few years ago, where the stated 
> goal was to create a single computing language that would replace Fortran, 
> scipy, Mathematica, Matlab, etc. simultaneously.  I thought at the time 
> that it sounded nuts. 
>
> Can we all agree now that it was, in fact, nuts? 
>

This is already implemented in SJulia:

  sjulia 1> f([w_,x_], [y_,z_]) := x * y/(w+z)

  sjulia 2> f([a,b],[c,d])

  Out(2) = b*c*((a + d)^(-1))

I have implemented several of Mma's pattern matching features. But, Mma's 
pattern matching is sophisticated. I have not implemented, for instance, 
associative-commutative matching, which Mma considers "structural" 
matching.  I experimented a bit with using SJulia features from julia.  
Without looking at it now, I guess it would take some work to access the 
pattern matching.

Maybe you can also do this kind of destructuring matching with this

 https://github.com/toivoh/PatternDispatch.jl

which aims to add pattern matching to method dispatch.

Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Chris Rackauckas]

Someone can make a macro for Mathematica's pattern matching syntax.

On Saturday, September 3, 2016 at 7:13:20 AM UTC-7, Andrew Dabrowski wrote:
>
> But what about nested pattern matching, or destructuring, isn't that much 
> easier in Mathematica than Julia?  For example defining a function of two 
> lists by
> f[{w_,x_}, {y_,z_}]:=x y/(w+z).
>
> I remember reading the Julia manifesto a few years ago, where the stated 
> goal was to create a single computing language that would replace Fortran, 
> scipy, Mathematica, Matlab, etc. simultaneously.  I thought at the time 
> that it sounded nuts. 
>
> Can we all agree now that it was, in fact, nuts? 
>
>

Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Andrew Dabrowski]

But what about nested pattern matching, or destructuring, isn't that much 
easier in Mathematica than Julia?  For example defining a function of two lists 
by
f[{w_,x_}, {y_,z_}]:=x y/(w+z).

I remember reading the Julia manifesto a few years ago, where the stated goal 
was to create a single computing language that would replace Fortran, scipy, 
Mathematica, Matlab, etc. simultaneously.  I thought at the time that it 
sounded nuts. 

Can we all agree now that it was, in fact, nuts? 

Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Steven G. Johnson]

On Thursday, September 1, 2016 at 8:25:27 PM UTC-4, Erik Schnetter wrote:
>
> One of the strengths of Mathematica's pattern matching system is the 
> ability for structural matching, e.g. to match a list where the second 
> element is a real number. This is something that is not (yet?) possible 
> with Julia's dispatch. 
> 
>

You can do it (see e.g. Match.jl), just not at compile time, because the 
elements of an array are not known at compile time, nor are the types of 
the elements of an Array{Any}.

Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Erik Schnetter]

One of the strengths of Mathematica's pattern matching system is the
ability for structural matching, e.g. to match a list where the second
element is a real number. This is something that is not (yet?) possible
with Julia's dispatch. It would be nice to be able to write something like

```Julia
function f(x::Expr where x.args::Tuple{T, Real, ...})
```

(with a more concise syntax) to mimic this.

-erik


On Thu, Sep 1, 2016 at 7:10 PM, Chris Rackauckas  wrote:

> I think types+dispatch is the right way to go. It's what Julia is founded
> upon, and it's what leads to really fast computations. A fast type/dispatch
> based symbolic system for Julia and in pure Julia would be a huge asset.
> And while the post said not to mention the front end, when talking about
> Mathematica you have to talk about the front end. The only reason why I use
> it over other CAS' is because that notebook looks like math. Until someone
> implements something like that in Julia, I will always have a reason to
> open up Mathematica.
>
>
> On Thursday, September 1, 2016 at 3:22:12 PM UTC-7, lapeyre@gmail.com
> wrote:
>>
>>
>>
>> On Thursday, January 23, 2014 at 11:47:11 PM UTC+1, Акатер Дима wrote:
>>>
>>> It's mentioned here http://julialang.org/blog/2012
>>> /02/why-we-created-julia/ that Mathematica was one of the programs that
>>> inspired Julia. How does Julia compare to Mathematica's language?
>>>
>>> To make the question more specific,
>>>
>>> - it's about languages, not implementations, so Mathematica's FrontEnd
>>> capabilities are irrelevant (and it's also not about “which one is faster”)
>>> - it's not about free vs non-free
>>> - it's not about communities and support
>>> - it's not about anything related to OOP (feel free to write about,
>>> sure, but I will probably be very passive in discussions concerning OOP)
>>>
>>> - it's about the languages' most high-level features, like
>>> meta-programming, macros, interactions with other languages and the way it
>>> treats types
>>>
>>> For example, Wolfram language (which is now the name of Mma's core
>>> language), implements meta-programming capabilities via term-rewriting and
>>> Hold. It provides some foreign-language interfaces via MathLink (which
>>> could be WolframLink already) and also has SymbolicC. It is untyped and
>>> proud of it; types can be implemented easily but they are of little
>>> practical need in the absence of compiler.
>>>
>>>
>> - it's also about the languages' most distinctive features: are there
>>> things Julia has that WL does not have? (Which means adding them to WL
>>> would require reimplementing Julia in WL, much in spirit of Greenspun's
>>> tenth rule.)
>>>
>>> I think it is easier to go the other direction and implement
>> something like Mma in Julia. This is what I have done here:
>>
>> https://github.com/jlapeyre/SJulia.jl
>>
>> I think Julia is uniquely well suited for implementing a Mma-like
>> language.  I agree with the comment below that Mma is designed in part to
>> appeal to non-programmers. A large part of its appeal is that it collects a
>> lot of mathematics functionality that is hard to find elsewhere... all
>> kinds of algorithms and special functions. Many of these can be used with
>> one or a few lines of code. I kept the non-programmer in mind when writing
>> SJulia.
>>
>>The question of what kind of type system a language has is somewhat
>> polemic. In some sense, Mma is untyped. There is no hierarchy in
>> expressions; they all have a head and arguments. I think hierarchies of
>> mathematical objects are not well represented by hierarchies of programming
>> language types. Which hierarchy a particular mathematical object belongs to
>> and its exact definition is very fluid. Languages like Mma that attach no
>> inherent meaning to expressions are well suited for mathematics for
>> scientists and engineers. A matrix is an expression with head 'List' each
>> of whose elements is an expression of fixed length with head 'List'.  Still
>> types creep into Mma in various ways.
>>
>> Some people prefer types to play a larger role in symbolic computation.
>> For instance:
>>
>> http://www.sympy.org/en/index.html
>>
>> https://github.com/jverzani/SymPy.jl
>>
>> http://nemocas.org/
>>
>> Whether to use types depends in part on the domain of the language.  But
>> even for rather general math capabilities, language design determines in
>> part the role of types. Sympy (in python and Julia) aim to add symbolic
>> computation capability to Julia.  They are more 'typed' than Mma and
>> SJulia. But, it seems that python sympy is hybrid in this respect and also
>> supports generic expressions.
>>
>>
>>> To provide a starting point, here is the definition of type in Julia
>>> from documentation http://docs.julialang.org/en/l
>>> atest/manual/metaprogramming/
>>>
>>> type Expr
>>>   head::Symbol
>>>   args::Array{Any,1}
>>>   typend
>>>
>>>
>>> Maybe there's a typo in docs (line 4) but it doesn't really 

[julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Chris Rackauckas]

I think types+dispatch is the right way to go. It's what Julia is founded 
upon, and it's what leads to really fast computations. A fast type/dispatch 
based symbolic system for Julia and in pure Julia would be a huge asset. 
And while the post said not to mention the front end, when talking about 
Mathematica you have to talk about the front end. The only reason why I use 
it over other CAS' is because that notebook looks like math. Until someone 
implements something like that in Julia, I will always have a reason to 
open up Mathematica.

On Thursday, September 1, 2016 at 3:22:12 PM UTC-7, lapeyre@gmail.com 
wrote:
>
>
>
> On Thursday, January 23, 2014 at 11:47:11 PM UTC+1, Акатер Дима wrote:
>>
>> It's mentioned here 
>> http://julialang.org/blog/2012/02/why-we-created-julia/ that Mathematica 
>> was one of the programs that inspired Julia. How does Julia compare to 
>> Mathematica's language?
>>
>> To make the question more specific,
>>
>> - it's about languages, not implementations, so Mathematica's FrontEnd 
>> capabilities are irrelevant (and it's also not about “which one is faster”)
>> - it's not about free vs non-free
>> - it's not about communities and support
>> - it's not about anything related to OOP (feel free to write about, sure, 
>> but I will probably be very passive in discussions concerning OOP)
>>
>> - it's about the languages' most high-level features, like 
>> meta-programming, macros, interactions with other languages and the way it 
>> treats types
>>
>> For example, Wolfram language (which is now the name of Mma's core 
>> language), implements meta-programming capabilities via term-rewriting and 
>> Hold. It provides some foreign-language interfaces via MathLink (which 
>> could be WolframLink already) and also has SymbolicC. It is untyped and 
>> proud of it; types can be implemented easily but they are of little 
>> practical need in the absence of compiler.
>>  
>>
> - it's also about the languages' most distinctive features: are there 
>> things Julia has that WL does not have? (Which means adding them to WL 
>> would require reimplementing Julia in WL, much in spirit of Greenspun's 
>> tenth rule.)
>>
>> I think it is easier to go the other direction and implement 
> something like Mma in Julia. This is what I have done here:
>
> https://github.com/jlapeyre/SJulia.jl
>
> I think Julia is uniquely well suited for implementing a Mma-like 
> language.  I agree with the comment below that Mma is designed in part to 
> appeal to non-programmers. A large part of its appeal is that it collects a 
> lot of mathematics functionality that is hard to find elsewhere... all 
> kinds of algorithms and special functions. Many of these can be used with 
> one or a few lines of code. I kept the non-programmer in mind when writing 
> SJulia.
>
>The question of what kind of type system a language has is somewhat 
> polemic. In some sense, Mma is untyped. There is no hierarchy in 
> expressions; they all have a head and arguments. I think hierarchies of 
> mathematical objects are not well represented by hierarchies of programming 
> language types. Which hierarchy a particular mathematical object belongs to 
> and its exact definition is very fluid. Languages like Mma that attach no 
> inherent meaning to expressions are well suited for mathematics for 
> scientists and engineers. A matrix is an expression with head 'List' each 
> of whose elements is an expression of fixed length with head 'List'.  Still 
> types creep into Mma in various ways. 
>
> Some people prefer types to play a larger role in symbolic computation. 
> For instance:
>
> http://www.sympy.org/en/index.html
>
> https://github.com/jverzani/SymPy.jl
>
> http://nemocas.org/
>
> Whether to use types depends in part on the domain of the language.  But 
> even for rather general math capabilities, language design determines in 
> part the role of types. Sympy (in python and Julia) aim to add symbolic 
> computation capability to Julia.  They are more 'typed' than Mma and 
> SJulia. But, it seems that python sympy is hybrid in this respect and also 
> supports generic expressions.
>  
>
>> To provide a starting point, here is the definition of type in Julia from 
>> documentation http://docs.julialang.org/en/latest/manual/metaprogramming/
>>
>> type Expr
>>   head::Symbol
>>   args::Array{Any,1}
>>   typend
>>
>>
>> Maybe there's a typo in docs (line 4) but it doesn't really matter. What 
>> do Julia users do, for example, to avoid boilerplate code defining lots of 
>> types? I understand how to avoid writing boilerplate definitions in WL: it 
>> may not be easy but at least I know where to begin in case I need a program 
>> that would write new definitions or update existing ones.
>>
>

[julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[lapeyre . math122a]

On Thursday, January 23, 2014 at 11:47:11 PM UTC+1, Акатер Дима wrote:
>
> It's mentioned here 
> http://julialang.org/blog/2012/02/why-we-created-julia/ that Mathematica 
> was one of the programs that inspired Julia. How does Julia compare to 
> Mathematica's language?
>
> To make the question more specific,
>
> - it's about languages, not implementations, so Mathematica's FrontEnd 
> capabilities are irrelevant (and it's also not about “which one is faster”)
> - it's not about free vs non-free
> - it's not about communities and support
> - it's not about anything related to OOP (feel free to write about, sure, 
> but I will probably be very passive in discussions concerning OOP)
>
> - it's about the languages' most high-level features, like 
> meta-programming, macros, interactions with other languages and the way it 
> treats types
>
> For example, Wolfram language (which is now the name of Mma's core 
> language), implements meta-programming capabilities via term-rewriting and 
> Hold. It provides some foreign-language interfaces via MathLink (which 
> could be WolframLink already) and also has SymbolicC. It is untyped and 
> proud of it; types can be implemented easily but they are of little 
> practical need in the absence of compiler.
>  
>
- it's also about the languages' most distinctive features: are there 
> things Julia has that WL does not have? (Which means adding them to WL 
> would require reimplementing Julia in WL, much in spirit of Greenspun's 
> tenth rule.)
>
> I think it is easier to go the other direction and implement something 
like Mma in Julia. This is what I have done here:

https://github.com/jlapeyre/SJulia.jl

I think Julia is uniquely well suited for implementing a Mma-like 
language.  I agree with the comment below that Mma is designed in part to 
appeal to non-programmers. A large part of its appeal is that it collects a 
lot of mathematics functionality that is hard to find elsewhere... all 
kinds of algorithms and special functions. Many of these can be used with 
one or a few lines of code. I kept the non-programmer in mind when writing 
SJulia.

   The question of what kind of type system a language has is somewhat 
polemic. In some sense, Mma is untyped. There is no hierarchy in 
expressions; they all have a head and arguments. I think hierarchies of 
mathematical objects are not well represented by hierarchies of programming 
language types. Which hierarchy a particular mathematical object belongs to 
and its exact definition is very fluid. Languages like Mma that attach no 
inherent meaning to expressions are well suited for mathematics for 
scientists and engineers. A matrix is an expression with head 'List' each 
of whose elements is an expression of fixed length with head 'List'.  Still 
types creep into Mma in various ways. 

Some people prefer types to play a larger role in symbolic computation. For 
instance:

http://www.sympy.org/en/index.html

https://github.com/jverzani/SymPy.jl

http://nemocas.org/

Whether to use types depends in part on the domain of the language.  But 
even for rather general math capabilities, language design determines in 
part the role of types. Sympy (in python and Julia) aim to add symbolic 
computation capability to Julia.  They are more 'typed' than Mma and 
SJulia. But, it seems that python sympy is hybrid in this respect and also 
supports generic expressions.
 

> To provide a starting point, here is the definition of type in Julia from 
> documentation http://docs.julialang.org/en/latest/manual/metaprogramming/
>
> type Expr
>   head::Symbol
>   args::Array{Any,1}
>   typend
>
>
> Maybe there's a typo in docs (line 4) but it doesn't really matter. What 
> do Julia users do, for example, to avoid boilerplate code defining lots of 
> types? I understand how to avoid writing boilerplate definitions in WL: it 
> may not be easy but at least I know where to begin in case I need a program 
> that would write new definitions or update existing ones.
>

[julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Daniel George]

It gets even faster if you make the slight change shown below in red:

$CompilationTarget = "C";
f = Compile[{{x, _Real, 1}, {min, _Real}, {max, _Real}}, 
  Module[{count = 0},
   Do[If[min <= i <= max, count++], {i, x}]; count], 
  "RuntimeOptions" -> "Speed"];

On Monday, July 21, 2014 at 5:29:02 AM UTC-5, johan...@gmail.com wrote:
>
> On Saturday, January 25, 2014 8:41:08 PM UTC+1, Johan Sigfrids wrote:
>>
>> On Saturday, January 25, 2014 9:24:17 PM UTC+2, Jason Merrill wrote: 
>>>
>>>   mma> data = RandomReal[1.,1*^7]; min = .2; max = .3;
>>>   mma> Total@Unitize@Clip[data,{min,max},{0,0}]
>>>
>>> I claim that it takes *a lot* of experience to know that that is the 
>>> code that is going to be fast, compared to the other 15 approaches people 
>>> bring up there, because the mapping between Mathematica's core constructs 
>>> and the machine's core constructs is far more complicated and indirect than 
>>> for Julia.
>>>
>>> In contrast, it doesn't take deep familiarity with Julia's standard 
>>> library to come up with about the fastest way to write this operation.
>>>
>>>   julia> function count_range(arr, min, max)
>>>   count = 0
>>>   for elt in arr
>>> if min < elt < max count += 1 end
>>>   end
>>>   count
>>> end
>>>
>>> It takes more than one line to write, but it's *obvious*. My Mathematica 
>>> license is expired these days, so I can't run the benchmark, but I bet it 
>>> also smokes the fast solution in Mathematica.
>>>
>>
>> Having a Mathematica license and being curious I compared them. The Julia 
>> version is roughly 10x faster than the Mathematica version.  
>>
>
> I compared with Mathematica 9. Total@Unitize@Clip[data,{min,max},{0,0}] 
> was for me roughly 3x slower than the Julia version; which sounds 
> reasonable since Total, Unitize and Clip run once though the data. In 
> Mathematica 9 you also have the option to compile to C, which then runs as 
> fast as the Julia version:
>
> $CompilationTarget = "C";
> f = Compile[{{x, _Real, 1}, {min, _Real}, {max, _Real}}, 
>   Module[{count = 0},
>Do[If[min <= x[[i]] <= max, count++], {i, Length@x}]; count], 
>   "RuntimeOptions" -> "Speed"];
>

Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Tomas Lycken]

 It is only for 2-D plotting, does not do contour or density plot ( two 
types I tend to use the most). I am sure it will only get improved.

There is, actually, some functionality for contour and density plot 
already, but all the nuts and bolts aren't really tightened yet, and I 
don't know if the progress so far has been documented at all, but if you 
have a function `f = (x,y) - z(x,y)`, you can do `plot(f, xmin, xmax, 
ymin, ymax)` to get a nice contour plot. Support for contour plots of 
matrices is under construction - take a look at 
[#293](https://github.com/dcjones/Gadfly.jl/issues/293) for more details.

Density plots is sort-of implemented through 
[Geom.rectbin](http://dcjones.github.io/Gadfly.jl/geom_rectbin.html) which 
may or may not be what you need.

// T

On Monday, July 21, 2014 11:09:31 PM UTC+2, Zahirul ALAM wrote:

 Thanks Stefan. I did find out that I can type \alphatab for Unicode α. 
 My point was more to do with the traditional input / output mode. 

 btw if I am not mistaken I think in markup mode the \alphatab does not 
 work. I guess not even auto complete works in markup mode when pressed tab. 
 May be I am doing it wrong. However it works just fine once the block is 
 compiled. But I think that has nothing to do with IJulia.

 I have indeed met Gadfly. I had Gadfly in mind when I wrote that. It is 
 indeed very pretty. It is only for 2-D plotting, does not do contour or 
 density plot ( two types I tend to use the most). I am sure it will only 
 get improved. 

 On Monday, 21 July 2014 14:48:17 UTC-4, Stefan Karpinski wrote:

 On Mon, Jul 21, 2014 at 9:55 AM, Zahirul ALAM zahiru...@gmail.com 
 wrote:

 One feature I would like to see from IJulia may be is that the input of 
 greek and mathematical symbol in way that looks natural, e.g. using 
 subscript, in division, integration etc as way to input. This will 
 definitely be a significant improvement IMHO. 


 You can do Unicode input using LaTeX codes in IJulia by typing, e.g. 
 \alphatab, which will be turned into a Unicode α. That's not as fancy as 
 what you can do in Mathematica, but I'm not sure we want to go there. I 
 find editing Mathematica code pretty irritating and it's not that much 
 better looking except for the traditional output mode, which you cannot 
 use as an input format anyway.

 second feature is to be able to plot a function in a way one can do in 
 Mathematica. Plotting packages for Julia does this in very limited way 
 (unless I am missing something)


 Have you met Gadfly https://github.com/dcjones/Gadfly.jl?

Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Viral Shah]

On Tuesday, July 22, 2014 2:39:31 AM UTC+5:30, Zahirul ALAM wrote:

 I have indeed met Gadfly. I had Gadfly in mind when I wrote that. It is 
 indeed very pretty. It is only for 2-D plotting, does not do contour or 
 density plot ( two types I tend to use the most). I am sure it will only 
 get improved. 


You could also look at PyPlot, which uses Matplotlib.

-viral

Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Darwin Darakananda]

If it's possible, do you mind showing the function you were plotting that 
lead to the extra lines in Gadfly?  The current master should already be 
using the `group` aesthetic for contour lines.

On Tuesday, July 22, 2014 10:06:53 AM UTC-7, Zahirul ALAM wrote:

 Thanks Stefan, Tomas and Viral. 

 Stefan and Tomas: Contourplot definitely looks very pretty in gadfly.  

 Tomas: But I am afraid the plot contains extra lines which some of you 
 have already pointed to be aesthetic issue. It is not entirely clear how to 
 use the group aesthetic to fix it. I will read on. 

 Viral: I am currently using the PyPlot package.

 btw: on this regard, I am yet to  a straight forward manner to do find 
 dual Y axis or dual X axis plot in either Mathematica, Matlab, 
 Matplotlib, or Maple. May be in Gadfly this is a feature that can be built 
 in. 


 On Tuesday, 22 July 2014 03:08:26 UTC-4, Tomas Lycken wrote:

  It is only for 2-D plotting, does not do contour or density plot ( two 
 types I tend to use the most). I am sure it will only get improved.

 There is, actually, some functionality for contour and density plot 
 already, but all the nuts and bolts aren't really tightened yet, and I 
 don't know if the progress so far has been documented at all, but if you 
 have a function `f = (x,y) - z(x,y)`, you can do `plot(f, xmin, xmax, 
 ymin, ymax)` to get a nice contour plot. Support for contour plots of 
 matrices is under construction - take a look at [#293](
 https://github.com/dcjones/Gadfly.jl/issues/293) for more details.

 Density plots is sort-of implemented through [Geom.rectbin](
 http://dcjones.github.io/Gadfly.jl/geom_rectbin.html) which may or may 
 not be what you need.

 // T

 On Monday, July 21, 2014 11:09:31 PM UTC+2, Zahirul ALAM wrote:

 Thanks Stefan. I did find out that I can type \alphatab for Unicode α. 
 My point was more to do with the traditional input / output mode. 

 btw if I am not mistaken I think in markup mode the \alphatab does not 
 work. I guess not even auto complete works in markup mode when pressed tab. 
 May be I am doing it wrong. However it works just fine once the block is 
 compiled. But I think that has nothing to do with IJulia.

 I have indeed met Gadfly. I had Gadfly in mind when I wrote that. It is 
 indeed very pretty. It is only for 2-D plotting, does not do contour or 
 density plot ( two types I tend to use the most). I am sure it will only 
 get improved. 

 On Monday, 21 July 2014 14:48:17 UTC-4, Stefan Karpinski wrote:

 On Mon, Jul 21, 2014 at 9:55 AM, Zahirul ALAM zahiru...@gmail.com 
 wrote:

 One feature I would like to see from IJulia may be is that the input 
 of greek and mathematical symbol in way that looks natural, e.g. using 
 subscript, in division, integration etc as way to input. This will 
 definitely be a significant improvement IMHO. 


 You can do Unicode input using LaTeX codes in IJulia by typing, e.g. 
 \alphatab, which will be turned into a Unicode α. That's not as fancy as 
 what you can do in Mathematica, but I'm not sure we want to go there. I 
 find editing Mathematica code pretty irritating and it's not that much 
 better looking except for the traditional output mode, which you cannot 
 use as an input format anyway.

 second feature is to be able to plot a function in a way one can do in 
 Mathematica. Plotting packages for Julia does this in very limited way 
 (unless I am missing something)


 Have you met Gadfly https://github.com/dcjones/Gadfly.jl?

[julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[johannibrea]

On Saturday, January 25, 2014 8:41:08 PM UTC+1, Johan Sigfrids wrote:

 On Saturday, January 25, 2014 9:24:17 PM UTC+2, Jason Merrill wrote: 

   mma data = RandomReal[1.,1*^7]; min = .2; max = .3;
   mma Total@Unitize@Clip[data,{min,max},{0,0}]

 I claim that it takes *a lot* of experience to know that that is the code 
 that is going to be fast, compared to the other 15 approaches people bring 
 up there, because the mapping between Mathematica's core constructs and the 
 machine's core constructs is far more complicated and indirect than for 
 Julia.

 In contrast, it doesn't take deep familiarity with Julia's standard 
 library to come up with about the fastest way to write this operation.

   julia function count_range(arr, min, max)
   count = 0
   for elt in arr
 if min  elt  max count += 1 end
   end
   count
 end

 It takes more than one line to write, but it's *obvious*. My Mathematica 
 license is expired these days, so I can't run the benchmark, but I bet it 
 also smokes the fast solution in Mathematica.


 Having a Mathematica license and being curious I compared them. The Julia 
 version is roughly 10x faster than the Mathematica version.  


I compared with Mathematica 9. Total@Unitize@Clip[data,{min,max},{0,0}] was 
for me roughly 3x slower than the Julia version; which sounds reasonable 
since Total, Unitize and Clip run once though the data. In Mathematica 9 
you also have the option to compile to C, which then runs as fast as the 
Julia version:

$CompilationTarget = C;
f = Compile[{{x, _Real, 1}, {min, _Real}, {max, _Real}}, 
  Module[{count = 0},
   Do[If[min = x[[i]] = max, count++], {i, Length@x}]; count], 
  RuntimeOptions - Speed];

[julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Zahirul ALAM]

I have been using Mathematica regularly for five years now and I am a new 
user of Julia. As a first serious project I have used Julia to simulate a 
nonlinear optical pulse propagation problem. I originally have written the 
codes in Mathematica. The simulation time in Julia was roughly eight times 
smaller than Mathematica. I am sure I have missed many Julia tricks to make 
it even faster. In mathematica Table or ParallelTable are quite fast. I am 
disappointed that with the new version 10 Wolfram has not added any more 
parallel computation details. So for symbolic manipulation or doing a quick 
plots mathematica is unbeatable. Writing some basic parallel codes are also 
as trivial as it gets. 

One feature I would like to see from IJulia may be is that the input of 
greek and mathematical symbol in way that looks natural, e.g. using 
subscript, in division, integration etc as way to input. This will 
definitely be a significant improvement IMHO. 

second feature is to be able to plot a function in a way one can do in 
Mathematica. Plotting packages for Julia does this in very limited way 
(unless I am missing something)

Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Stefan Karpinski]

On Mon, Jul 21, 2014 at 9:55 AM, Zahirul ALAM zahirul.a...@gmail.com
wrote:

 One feature I would like to see from IJulia may be is that the input of
 greek and mathematical symbol in way that looks natural, e.g. using
 subscript, in division, integration etc as way to input. This will
 definitely be a significant improvement IMHO.


You can do Unicode input using LaTeX codes in IJulia by typing, e.g.
\alphatab, which will be turned into a Unicode α. That's not as fancy as
what you can do in Mathematica, but I'm not sure we want to go there. I
find editing Mathematica code pretty irritating and it's not that much
better looking except for the traditional output mode, which you cannot
use as an input format anyway.

second feature is to be able to plot a function in a way one can do in
 Mathematica. Plotting packages for Julia does this in very limited way
 (unless I am missing something)


Have you met Gadfly https://github.com/dcjones/Gadfly.jl?

Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Zahirul ALAM]

Thanks Stefan. I did find out that I can type \alphatab for Unicode α. My 
point was more to do with the traditional input / output mode. 

btw if I am not mistaken I think in markup mode the \alphatab does not 
work. I guess not even auto complete works in markup mode when pressed tab. 
May be I am doing it wrong. However it works just fine once the block is 
compiled. But I think that has nothing to do with IJulia.

I have indeed met Gadfly. I had Gadfly in mind when I wrote that. It is 
indeed very pretty. It is only for 2-D plotting, does not do contour or 
density plot ( two types I tend to use the most). I am sure it will only 
get improved. 

On Monday, 21 July 2014 14:48:17 UTC-4, Stefan Karpinski wrote:

 On Mon, Jul 21, 2014 at 9:55 AM, Zahirul ALAM zahiru...@gmail.com 
 javascript: wrote:

 One feature I would like to see from IJulia may be is that the input of 
 greek and mathematical symbol in way that looks natural, e.g. using 
 subscript, in division, integration etc as way to input. This will 
 definitely be a significant improvement IMHO. 


 You can do Unicode input using LaTeX codes in IJulia by typing, e.g. 
 \alphatab, which will be turned into a Unicode α. That's not as fancy as 
 what you can do in Mathematica, but I'm not sure we want to go there. I 
 find editing Mathematica code pretty irritating and it's not that much 
 better looking except for the traditional output mode, which you cannot 
 use as an input format anyway.

 second feature is to be able to plot a function in a way one can do in 
 Mathematica. Plotting packages for Julia does this in very limited way 
 (unless I am missing something)


 Have you met Gadfly https://github.com/dcjones/Gadfly.jl?

Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Stefan Karpinski]

Gadfly has recently gotten the ability to do contour plots unless I'm
mistaken, so hopefully that helps a bit. The \alphatab business is
actually a tab completion trick implemented in the Julia completion
backend, rather than in the IJulia/IPython/Jupyter frontend. In markdown
mode, you can use actual LaTeX input – as in $\alpha$.


On Mon, Jul 21, 2014 at 2:09 PM, Zahirul ALAM zahirul.a...@gmail.com
wrote:

 Thanks Stefan. I did find out that I can type \alphatab for Unicode α.
 My point was more to do with the traditional input / output mode.

 btw if I am not mistaken I think in markup mode the \alphatab does not
 work. I guess not even auto complete works in markup mode when pressed tab.
 May be I am doing it wrong. However it works just fine once the block is
 compiled. But I think that has nothing to do with IJulia.

 I have indeed met Gadfly. I had Gadfly in mind when I wrote that. It is
 indeed very pretty. It is only for 2-D plotting, does not do contour or
 density plot ( two types I tend to use the most). I am sure it will only
 get improved.

 On Monday, 21 July 2014 14:48:17 UTC-4, Stefan Karpinski wrote:

 On Mon, Jul 21, 2014 at 9:55 AM, Zahirul ALAM zahiru...@gmail.com
 wrote:

 One feature I would like to see from IJulia may be is that the input of
 greek and mathematical symbol in way that looks natural, e.g. using
 subscript, in division, integration etc as way to input. This will
 definitely be a significant improvement IMHO.


 You can do Unicode input using LaTeX codes in IJulia by typing, e.g.
 \alphatab, which will be turned into a Unicode α. That's not as fancy as
 what you can do in Mathematica, but I'm not sure we want to go there. I
 find editing Mathematica code pretty irritating and it's not that much
 better looking except for the traditional output mode, which you cannot
 use as an input format anyway.

 second feature is to be able to plot a function in a way one can do in
 Mathematica. Plotting packages for Julia does this in very limited way
 (unless I am missing something)


 Have you met Gadfly https://github.com/dcjones/Gadfly.jl?

[julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Steven G. Johnson]

On Friday, February 28, 2014 2:13:30 PM UTC-5, Tony Kelman wrote:

 On the flipside, and this isn't a language feature as much as a very 
 well-implemented functionality, is Manipulate[]. It is wonderfully simple 
 to set up and deploy interactive data exploration using Mathematica - 
 dragging a few sliders around can be a great way to explore parametric 
 sensitivities in some problems. If you've never seen this in action before, 
 have a look around demonstrations.wolfram.com for some examples. Julia 
 has some catching up to do here, but I'm confident it will happen in time.


This should be coming.  IPython just added protocol support precisely to 
support this sort of thing, which we will pick up in IJulia:

   https://github.com/ipython/ipython/pull/4195

[julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Knud Sørensen]

Here is a video demo of wolfram.

http://blog.wolfram.com/2014/02/24/starting-to-demo-the-wolfram-language/

[julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Mike Innes]

I think what this question boils down to is this: All else being equal 
(performance, price, support), which language is ultimately nicer to 
program in?

Mathematica is a fantastic - if not the best around - DSL for symbolic 
maths. It's term-rewriting paradigm is pretty much perfectly suited what it 
does, so if you're using it for quick equation plots or to cheat on your 
calculus homework, don't hold your breath waiting for a replacement. It 
also ends up having what looks a lot like Julia's multiple dispatch on 
steroids; you can match not just on type, but also on internal structure, 
or even the unevaluated expression or the function being called itself. 
This is enormously powerful; you can implement a fully-functioning 
dictionary https://gist.github.com/one-more-minute/8618047 type in seven 
lines of Mathematica, and it might not be fast but it's beautifully 
declarative. So, if you're looking for Julia to have some killer feature 
that makes it more powerful than Mathematica, you probably won't find one.

*But*. But. As cool as some of Mathematica's features are, *fundamentally it's 
a language designed to let non-programmers write one-liners*. And 
unfortunately, what are great design decisions in that context fall flat 
outside of it. For example, its syntax - writing S-Expressions as function 
calls is mostly great, until you have to write control flow statements and 
variable bindings as if they were function calls, which gets old fast. The 
syntax needs to either be simpler (a la Clojure) or more helpful (a la 
Julia) IMHO. Also, holding arguments, blurring the line between code and 
expressions; all great for short-term usability, but all that magic under 
the surface ends up being a lot of conceptual overhead for anything 
complex. Symbolic programming with no syntactical overhead is a great 
feature one percent of the time, but it gets in the way the other 
ninety-nine.

Some points for Julia: firstly, interop. You can import a C library and 
call it really easily; same for Python and soon Java. Also, Julia's code is 
generally easier to reason about than Mathematica's, especially for writing 
macros; there's no magic going on where you don't expect it. What's great 
about Julia is that despite this, it's still really powerful (thanks to 
multiple dispatch etc.). Also, it's more straightforward to generate and 
evaluate code in Julia, which is often useful. For these reasons, Julia 
would be my language of choice even if Mathematica was just as 
fast/free/whatever.

Last point: the language's approach to types has little to do with the 
presence/absence of a compiler. Yes, the Julia implementation is compiled, 
but this isn't about implementations, right? Both Julia and Mathematica are 
dynamically, strongly typed (not untyped - everything in Mathematica has a 
type, accessible via Head[]). Anyway, there's nothing stopping you from 
using lists and maps to represent your data, just as you would in 
Mathematica, and avoiding using types altogether. Persistent.jl and Lazy.jl 
give strong support for functional programming, so you're not going to be 
missing out. And you can get rid of code repetition / boilerplate by 
generating and evaluating code as above.

Oh, and there's no typo in that definition - Expr.typ will be dynamically 
typed, or equivalently have type Any.

Hope this helps.

[julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Jason Merrill]

Let's keep the conversation on the list. That way, people who know more 
about Julia than I do can tell me when I'm wrong.

On Sat, Jan 25, 2014 at 1:29 AM, Акатер Дима ... wrote:

 Thank you.

  The biggest advantage of Julia over Mathematica is that Julia tries
  to make its semantics obvious enough that you can reason about 
 performance.

 I believe this to be the matter of particular implementation, not related 
 to the core language. Mathematica is closed, so users mainly can't reason 
 about performance merely because they can't investigate the source code. 
 So, from the following point…

  The biggest advantage of Julia over Mathematica is that Julia tries to 
 make its semantics obvious enough that you can reason about performance.

 …could you elaborate on how is this related to semantics? Do you suppose 
 Disassemble symbol is impossible in a language like Wolfram's due to its 
 semantics? Or were you not really referring to the core language here?


You're right, my comment about semantics was kind of vague. But it isn't 
just an implementation issue. It's also a design/philosophy issue. What I 
was trying to express is that it's fairly straightforward to write low 
level code in Julia that maps in a simple way to the machine code that will 
actually be executed. You really can't say the same about Mathematica's 
core language. They do have facilities for compiling functions for 
particular types, or representing C symbolically, but those are far from 
the most obvious way to use the language.

You can find lots of concrete examples on the Mathematica mailing list. 
About once a month, someone writes a what is the fastest way to do x 
post, where x is some reasonably simple low level thing. Here's a random 
one I just found:

https://groups.google.com/d/topic/comp.soft-sys.math.mathematica/uiMFIOus6KU/discussion

They're discussing fast ways to count how many elements of a list fall in a 
particular range. The high level functions like Count are relatively slow 
compared to things like

  mma data = RandomReal[1.,1*^7]; min = .2; max = .3;
  mma Total@Unitize@Clip[data,{min,max},{0,0}]

I claim that it takes *a lot* of experience to know that that is the code 
that is going to be fast, compared to the other 15 approaches people bring 
up there, because the mapping between Mathematica's core constructs and the 
machine's core constructs is far more complicated and indirect than for 
Julia.

In contrast, it doesn't take deep familiarity with Julia's standard library 
to come up with about the fastest way to write this operation.

  julia function count_range(arr, min, max)
  count = 0
  for elt in arr
if min  elt  max count += 1 end
  end
  count
end

It takes more than one line to write, but it's *obvious*. My Mathematica 
license is expired these days, so I can't run the benchmark, but I bet it 
also smokes the fast solution in Mathematica.

Now you might claim that this is an implementation detail, and that with a 
Sufficiently Smart Compiler, Mathematica could generate code that's just as 
fast as Julia. But because of Julia's language design, it doesn't need a 
Sufficiently Smart Compiler--it just needs a Smarter Than Many But Still 
Completely Tractable Compiler.

Now you can write for loops in Mathematica too, but they often aren't that 
fast. Why? I don't really know, but I'm sure it has to do with Mathematica 
doing the right thing for all kinds of complicated, possibly symbolic, 
constructs that you might put inside the for loop; in other words, 
complicated semantics.
 

  The most important thing the two languages have in common is that 
 (almost?) all of the syntax maps to expressions

 This is one of the most interesting parts. How does type declaration in 
 Julia map to an expression? What can users do with type declarations, as 
 standalone objects? “RTFM” would be OK answer but I'd really prefer a 
 discussion. :-) Does “quote type […] end end” work? Is there a way to 
 investigate and edit syntax tree directly? 
 manual/metaprogramminghttp://www.google.com/url?q=http%3A%2F%2Fdocs.julialang.org%2Fen%2Flatest%2Fmanual%2Fmetaprogramming%2Fsa=Dsntz=1usg=AFQjCNHdvHRNqHrkBW6Upo3OJYZ6YuKyywdoes
  not seem to address these questions.


Maybe someone else can weight in here, but I'm inclined to say RTFM. Then 
read the implementation of some macros in the standard library.

 Does “quote type […] end end” work?

Yes... try it. You can step through the pieces of the resulting expression 
by looking at the head and the args of the returned expression, and then 
looking at the head and the args of all the args, etc. recursively.

[julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Johan Sigfrids]

On Saturday, January 25, 2014 9:24:17 PM UTC+2, Jason Merrill wrote: 

   mma data = RandomReal[1.,1*^7]; min = .2; max = .3;
   mma Total@Unitize@Clip[data,{min,max},{0,0}]

 I claim that it takes *a lot* of experience to know that that is the code 
 that is going to be fast, compared to the other 15 approaches people bring 
 up there, because the mapping between Mathematica's core constructs and the 
 machine's core constructs is far more complicated and indirect than for 
 Julia.

 In contrast, it doesn't take deep familiarity with Julia's standard 
 library to come up with about the fastest way to write this operation.

   julia function count_range(arr, min, max)
   count = 0
   for elt in arr
 if min  elt  max count += 1 end
   end
   count
 end

 It takes more than one line to write, but it's *obvious*. My Mathematica 
 license is expired these days, so I can't run the benchmark, but I bet it 
 also smokes the fast solution in Mathematica.


Having a Mathematica license and being curious I compared them. The Julia 
version is roughly 10x faster than the Mathematica version.  

[julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Knud Sørensen]

I installed wolfram  on my raspberry pi. 
Mostly to play with free-form linguistics but I couldn't get it to work.
I considred D, Julia and Wolfram for a  raspberry pi project.

But D(dmd) and  Julia is not in the apt-get archve for raspberry pi
and wolfram is behind a paywall on other platforms. 
So, I decided to go with racket. 

I don't know much about it but there is some talk about reactive 
programming. See:
http://en.wikipedia.org/wiki/Reactive_programming
https://www.coursera.org/course/reactive

One of the reasons I have had look at Julia and wolfram is that I took a 
course in systematic program design some time ago.
https://www.coursera.org/course/programdesign
It teaches that the structure of the program follow from the structure of 
the data, 
and I was looking for a programming language which uses this fact and 
places the data first. Like:

suffixTree res=(GTAGT$,[5, 2, 3, 0, 4, 1],[0, 0, 0, 2, 0, 
1]).suffixArray2suffixTree

The idé is that by placing the data first the programming envioment might 
help you find the right function or series of function (with tab complete 
?),
or maybe write some systematic code automatically.

Well, this might just be some late night rambling not much about Julia or 
Wolfram.

Knud

[julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features

[Jason Merrill]

Julia and Mathematica are very, very different languages.

Mathematica's underlying model is heavily based on pattern matching and 
term rewriting. Most function definitions in Mathematica should really be 
thought of as replacement rules

   f[x_] := Sin[x^2]

means replace any expression with the head `f` and any single argument 
with the expression on the rhs. Mathematica hardly has the concept of an 
undefined variable; it just has symbols that don't have any replacement 
rules yet. So you can make new expressions, e.g. like this:

   f[q + 1]
  Sin[(q+ 1)^2]

Mathematica makes it possible to write procedural do this, then do this, 
then do this, for-loopy code, but working that way is very much working 
against the grain. It's much more natural to structure your programs as 
successive replacements that transform symbolic expressions. This means 
that the implementers make every effort to expose any kind of data that you 
might care about as a symbolic expression of some kind. Symbolic graphics 
are a great example to study: in that case, you can do things like change 
all your points to red circles using a replacement rule.

Julia has a much more traditional evaluation model. It's totally fine and 
natural to write procedural code like you would in C, and when you do, you 
can get performance similar to C. The biggest advantage of Julia over 
Mathematica is that Julia tries to make its semantics obvious enough that 
you can reason about performance. You can also reason about the way your 
data is stored in memory. Mathematica generally tries to abstract these 
details away, and the result is that being able to write fast C code does 
not translate at all into being able to write fast Mathematica code.

Both Mathematica and Julia let you dispatch to different definitions of a 
function based on its arguments, but Julia does this according to the Type 
of all of the arguments, and Mathematica does it according to structural 
pattern matching rules.

The most important thing the two languages have in common is that (almost?) 
all of the syntax maps to expressions, where an expression is an object 
with a head and args. This uniformity makes it easier to treat code as 
data, allowing code to be generated and transformed in similar ways that 
other data structures are.

Julia typically does code transformation at parse time (or maybe 
macro-expansion time is separated from parse time?), using macros that take 
in an existing expression and return a new expression to be spliced into 
the code before compilation. See 
http://docs.julialang.org/en/latest/manual/metaprogramming/ for details.

Mathematica doesn't make a lot of distinction between parse time, compile 
time, or evaluation time. You transform code any time you want to, using 
the same pattern matching replacement rules that you use to get anything 
done at all.

I hope some of this is helpful. You've asked a very broad question, and 
it's difficult to figure out what's relevant in a summary. It's a bit like 
trying to answer the question How is Brazil different from Japan or 
something like that.

On Thursday, January 23, 2014 2:47:11 PM UTC-8, Акатер Дима wrote:

 It's mentioned here 
 http://julialang.org/blog/2012/02/why-we-created-julia/ that Mathematica 
 was one of the programs that inspired Julia. How does Julia compare to 
 Mathematica's language?

 To make the question more specific,

 - it's about languages, not implementations, so Mathematica's FrontEnd 
 capabilities are irrelevant (and it's also not about “which one is faster”)
 - it's not about free vs non-free
 - it's not about communities and support
 - it's not about anything related to OOP (feel free to write about, sure, 
 but I will probably be very passive in discussions concerning OOP)

 - it's about the languages' most high-level features, like 
 meta-programming, macros, interactions with other languages and the way it 
 treats types

 For example, Wolfram language (which is now the name of Mma's core 
 language), implements meta-programming capabilities via term-rewriting and 
 Hold. It provides some foreign-language interfaces via MathLink (which 
 could be WolframLink already) and also has SymbolicC. It is untyped and 
 proud of it; types can be implemented easily but they are of little 
 practical need in the absence of compiler.

 - it's also about the languages' most distinctive features: are there 
 things Julia has that WL does not have? (Which means adding them to WL 
 would require reimplementing Julia in WL, much in spirit of Greenspun's 
 tenth rule.)

 To provide a starting point, here is the definition of type in Julia from 
 documentation http://docs.julialang.org/en/latest/manual/metaprogramming/

 type Expr
   head::Symbol
   args::Array{Any,1}
   typend


 Maybe there's a typo in docs (line 4) but it doesn't really matter. What 
 do Julia users do, for example, to avoid boilerplate code defining lots of 
 types? I understand how to avoid writing