from:"lapeyre . math122a"

You can try this branch https://github.com/jlapeyre/julia/tree/gjl/replhooks

In .juliarc.jl, you can include code like this:

if isdefined(Base, :atreplrun)
Base.atreplrun( (repl)->repl.interface.modes[1].prompt = "newprompt>" )
end

to install a hook. Call atreplrun repeatedly to push hooks, all of which 
are run (more or less) just before the loop is entered.

John


On Wednesday, April 20, 2016 at 5:54:22 AM UTC+2, Rafael Fourquet wrote:
>
> > Again, I don't know if there is any demand for adding a general 
> > facility for this. 
>
> If you have in mind to make a PR, I would be a client for such a 
> facility. IIUC, this would e.g. allow me to change automatically the 
> prompt by calling a function from .juliarc.jl ? (which I do manually 
> now with "Base.active_repl.interface.modes[1].prompt = ..."). 
>

Re: [julia-users] Re: Change bold text in REPL to normal

Good, this works. But, I don't think the preference for expressions over 
strings is mentioned in the Metaprogramming section of the manual.

John

On Wednesday, April 20, 2016 at 4:19:18 PM UTC+2, Yichao Yu wrote:
>
> On Wed, Apr 20, 2016 at 10:11 AM,   
> wrote: 
> > I see. To get normal weight, red, warn() text, this works for me: 
> > 
> > Base.text_colors[:rednormal] = "\033[0m\033[31m" 
> > Base.eval(parse("default_color_warn = :rednormal")) 
>
> Base.eval(:(default_color_warn = :rednormal)) 
>
> at least. You almost never want to use `parse` and then `eval`. 
>
> > 
> > text_colors is defined in base/client.jl 
> > 
> > On Wednesday, April 20, 2016 at 3:10:19 PM UTC+2, cormu...@mac.com 
> wrote: 
> >> 
> >> Thanks, useful info. Although, I don't mind the colors. It's the forced 
> >> bolding that looks so bad... :( 
>

Re: [julia-users] How to change REPL mode on startup?

Yes, AFAIK it is not possible to modify the REPL in .juliarc.jl because it 
is executed before the REPL runs. A tedious workaround is to use 
.juliarc.jl to create a REPL and then exit() upon completion before the 
usual REPL is started. I hadn't thought about a PR, but I can take a look 
at it.
John

On Wednesday, April 20, 2016 at 5:54:22 AM UTC+2, Rafael Fourquet wrote:
>
> > Again, I don't know if there is any demand for adding a general 
> > facility for this. 
>
> If you have in mind to make a PR, I would be a client for such a 
> facility. IIUC, this would e.g. allow me to change automatically the 
> prompt by calling a function from .juliarc.jl ? (which I do manually 
> now with "Base.active_repl.interface.modes[1].prompt = ..."). 
>

[julia-users] Re: Change bold text in REPL to normal

I see. To get normal weight, red, warn() text, this works for me:

Base.text_colors[:rednormal] = "\033[0m\033[31m"
Base.eval(parse("default_color_warn = :rednormal"))

text_colors is defined in base/client.jl

On Wednesday, April 20, 2016 at 3:10:19 PM UTC+2, cormu...@mac.com wrote:
>
> Thanks, useful info. Although, I don't mind the colors. It's the forced 
> bolding that looks so bad... :(
>>
>>

[julia-users] Re: Change bold text in REPL to normal

2016-04-19 Thread lapeyre . math122a

As a partial solution, this makes warnings print in black rather than red.

julia> Base.eval(parse("default_color_warn = :black"))

I just had a problem in which I wanted to do the opposite, restore coloring 
and bold to a new REPL.

Also, this gives a black, plain typeface to warning and error messages:

 Base.eval(parse("have_color = false"))

John

On Monday, February 8, 2016 at 9:10:28 AM UTC+1, cormu...@mac.com wrote:
>
> I'm trying to improve the appearance of text in my Julia REPL. According 
> to this PR (https://github.com/JuliaLang/julia/pull/11250) (which sadly 
> seems to have ground to a halt), it should be possible to control the 
> appearance of text in the REPL by adding lines to the .juliarc.jl file. 
>
> I've tried adding stuff like:
>
> ENV["JULIA_WARN_COLOR"] = :normal
> ENV["JULIA_INFO_COLOR"] = :normal
>
> to the .juliarc.jl. I've also tried various commands in the REPL, such as:
>
> julia> Base.active_repl.prompt_color = Base.text_colors[:normal]
>
> and various other things, but nothing has yet worked. But I feel I'm 
> close! :). 
>
> Anybody successfully controlled the colors in the REPL?
>
>

Re: [julia-users] How to change REPL mode on startup?

2016-04-19 Thread lapeyre . math122a

Thanks. I got it working. I copied much of the code in client.jl. In the 
end I wrote the new mode directly into a copy of REPL.setup_interface.  
There is probably an easier way to get the REPL to start in the new mode 
rather than julia, but this was faster for me.  There were many details, eg 
to get warn and error colors working. For me, it would have been far easier 
to use a hook after the REPL is created, but before it runs. But, I guess 
there is probably not much demand for that.

I also copied four functions, changing only `Base.parse_input_line(line)' 
in each (to support dumb terminals, etc.),  to include a macro to 
post-process the AST.  Again, I don't know if there is any demand for 
adding a general facility for this.

John

On Friday, April 15, 2016 at 6:07:00 PM UTC+2, Keno Fischer wrote:
>
> You can call REPL.setup_inferface yourself and add your own REPL mode. You 
> can also look at 
> https://github.com/JuliaLang/julia/blob/master/base/client.jl to see how 
> the active_repl gets created.
>
> On Fri, Apr 15, 2016 at 9:16 AM,  
> wrote:
>
>> I have a REPL mode for an application: 
>> https://github.com/jlapeyre/SJulia.jl/blob/master/src/sjulia_repl.jl
>>
>> I start julia in a terminal,  load the package with 'using SJulia', and 
>> then press '=' to enter the alternative mode.  This works fine.
>>
>> I would like to do this in one step. e.g.  enter 'sjulia' in a terminal 
>> and then start in the alternative mode. Problems are:
>>
>> 1. I have to execute a julia function to start the REPL mode 'after' the 
>> REPL starts and I see the julia prompt. Otherwise there is no active REPL. 
>> Using .juliarc.jl or julia -e apparently loads and runs code before 
>> starting the REPL.  I would like the alternative REPL mode to be created 
>> without entering anything at the julia prompt.
>>
>> 2. Once I create the alternative REPL, I am still in the standard julia 
>> REPL mode. To switch to the alternative mode, I enter '='. I would like to 
>> enter this mode automatically. There is a function Base.LineEdit.transition 
>> that seems to do this. But, it takes a data structure (of type 
>> Base.LineEdit.MIState' ) as an argument that I don't know how to get at.  I 
>> can probably find it buried somewhere in Base.active_repl, but, I have not 
>> been able to so far.
>>
>> -John
>>
>
>

[julia-users] How to change REPL mode on startup?

2016-04-15 Thread lapeyre . math122a

I have a REPL mode for an application: 
https://github.com/jlapeyre/SJulia.jl/blob/master/src/sjulia_repl.jl

I start julia in a terminal,  load the package with 'using SJulia', and 
then press '=' to enter the alternative mode.  This works fine.

I would like to do this in one step. e.g.  enter 'sjulia' in a terminal and 
then start in the alternative mode. Problems are:

1. I have to execute a julia function to start the REPL mode 'after' the 
REPL starts and I see the julia prompt. Otherwise there is no active REPL. 
Using .juliarc.jl or julia -e apparently loads and runs code before 
starting the REPL.  I would like the alternative REPL mode to be created 
without entering anything at the julia prompt.

2. Once I create the alternative REPL, I am still in the standard julia 
REPL mode. To switch to the alternative mode, I enter '='. I would like to 
enter this mode automatically. There is a function Base.LineEdit.transition 
that seems to do this. But, it takes a data structure (of type 
Base.LineEdit.MIState' ) as an argument that I don't know how to get at.  I 
can probably find it buried somewhere in Base.active_repl, but, I have not 
been able to so far.

-John

[julia-users] Re: parallel threads broken, replacing module

2015-07-30 Thread lapeyre . math122a

Thanks Seth.

On Thursday, July 30, 2015 at 2:46:42 AM UTC+2, Seth wrote:

 Reference: https://github.com/JuliaLang/julia/issues/12381

 On Wednesday, July 29, 2015 at 5:35:14 PM UTC-7, Seth wrote:

 For what it's worth, I'm seeing the same thing:

 julia @everywhere using LightGraphs
 WARNING: replacing module LightGraphs
 WARNING: replacing module LightGraphs
 WARNING: replacing module LightGraphs
 WARNING: replacing module LightGraphs
 exception on 4:
 ...
 (Lots of error messages / backtraces removed)
 ...
 ERROR: ProcessExitedException()
  in wait at /usr/local/julia-latest/lib/julia/sys.dylib
  in sync_end at /usr/local/julia-latest/lib/julia/sys.dylib
  in anonymous at multi.jl:348



 On Wednesday, July 29, 2015 at 4:54:30 PM UTC-7, lapeyre@gmail.com 
 wrote:

 I can file a bug report. But, I'm not entirely sure what to write.

 Simpler case:

  julia -p 4
  @everywhere using ZChop (simple modules)

 The following version is from a completely fresh build today. I don't 
 get a crash immediately, but I do get
 WARNING: replacing module ZChop (4 times)
 Version 0.4.0-dev+6394 (2015-07-29 21:58 UTC)
 Commit a2a218b* (0 days old master)

 Five days ago, i did git pull and built from an older clone
 Version 0.4.0-dev+6202 (2015-07-24 01:47 UTC)
 Commit 53a7f2e* (5 days old master)
 This version prints the same warning and spews many errors including
 unknown function (ip: 0x7fe94d596ff7)
 ERROR (unhandled task failure): EOFError: read end of file

 The following version will load ZChop with no problem, but when loading 
 Distributions, it still prints many errors
 and fails.  It loads some other modules (i.e with @everywhere, as above),
 such as Roots with no apparent errors.
 Version 0.4.0-dev+3965 (2015-03-22 12:24 UTC)
 Commit e1f0310* (129 days old master)

 A fresh build today on another machine gives errors with @everywhere 
 using Roots.
 It fails to load Distributions even with no parallel threads, but this 
 appears to be unrelated.

 On the same (other) machine, the following version loads and runs 
 parallel code using the modules
 mentioned above, and more.
 Version 0.4.0-dev+4096 (2015-03-31 08:05 UTC)
 Commit a3c0743* (120 days old master)

 I see no error with 0.3.5-pre+121 (2015-01-07 00:19 UTC)


 On Wednesday, July 29, 2015 at 11:24:55 PM UTC+2, lapeyre@gmail.com 
 wrote:

 Parallel threads has stopped working for me. Any ideas ?
 Code using addprocs and @everywhere include has stopped working (is 
 broken) on one machine. Code that used to work now causes a number of 
 varying errors to be printed, crashes, runaway processes, etc. when it is 
 loaded. Both a recent v0.4 and a 2 month old version that did run the code 
 in the past cause the failure. The same code on a different machine 
 continues to run normally. Maybe my user Julia environment has a problem ? 
 Or maybe I upgraded a system library ?

 If I use just 2 processes, the code will sometimes  both load and run 
 correctly.

 A minimal example

 test.jl
 --
 using Distributions
 --

 julia -p 4
  @everywhere include(test.jl)

 WARNING: replacing module Distributions   ( 4 times )
 signal (11): Segmentation fault
 unknown function (ip: 0x7f235c7ffd98)
 jl_module_import at /usr/local/julia-0.4a/bin/../lib/julia/libjulia.so 
 (unknown line)

 etc.

 I am running unstable debian linux.

 Thanks, John

[julia-users] VoronoiCells.jl

2015-07-29 Thread lapeyre . math122a

Here is some code to manipulate Voronoi cells in 2D.

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

I am developing these recent packages more or less just enough to get some 
research done. When things cool down (i.e. baby is grown and I get an 
endowed chair of free creativity) I plan to make them proper packages. I'm 
putting them out in case someone happens to have the same need I did, (or 
wants to contribute or comment).  If you do use something and have a 
question, or want something specific documented, let me know. Of course, 
this should eventually be integrated into the Julia geometry packages.

This code uses VoronoiDelaunay.jl to generate a tesselation. Then the 
objects representing cells are built from the triangles. There are a lot of 
choices about what to store and what to compute. The current choice is 
driven by my current need. The cell containing a random (as in access) 
point can be retrieved quickly using a standard bucket scheme. The cell 
stores the generator and the vertices.  A simpler (undocumented) structure 
is provided if you don't need to lookup by random point. A few features 
such as area of cells are provided.

John

[julia-users] parallel threads broken, replacing module

2015-07-29 Thread lapeyre . math122a

Parallel threads has stopped working for me. Any ideas ?
Code using addprocs and @everywhere include has stopped working (is broken) 
on one machine. Code that used to work now causes a number of varying 
errors to be printed, crashes, runaway processes, etc. when it is loaded. 
Both a recent v0.4 and a 2 month old version that did run the code in the 
past cause the failure. The same code on a different machine continues to 
run normally. Maybe my user Julia environment has a problem ? Or maybe I 
upgraded a system library ?

If I use just 2 processes, the code will sometimes  both load and run 
correctly.

A minimal example

test.jl
--
using Distributions
--

julia -p 4
 @everywhere include(test.jl)

WARNING: replacing module Distributions   ( 4 times )
signal (11): Segmentation fault
unknown function (ip: 0x7f235c7ffd98)
jl_module_import at /usr/local/julia-0.4a/bin/../lib/julia/libjulia.so 
(unknown line)

etc.

I am running unstable debian linux.

Thanks, John

[julia-users] Re: parallel threads broken, replacing module

2015-07-29 Thread lapeyre . math122a

I can file a bug report. But, I'm not entirely sure what to write.

Simpler case:

 julia -p 4
 @everywhere using ZChop (simple modules)

The following version is from a completely fresh build today. I don't get a 
crash immediately, but I do get
WARNING: replacing module ZChop (4 times)
Version 0.4.0-dev+6394 (2015-07-29 21:58 UTC)
Commit a2a218b* (0 days old master)

Five days ago, i did git pull and built from an older clone
Version 0.4.0-dev+6202 (2015-07-24 01:47 UTC)
Commit 53a7f2e* (5 days old master)
This version prints the same warning and spews many errors including
unknown function (ip: 0x7fe94d596ff7)
ERROR (unhandled task failure): EOFError: read end of file

The following version will load ZChop with no problem, but when loading 
Distributions, it still prints many errors
and fails.  It loads some other modules (i.e with @everywhere, as above),
such as Roots with no apparent errors.
Version 0.4.0-dev+3965 (2015-03-22 12:24 UTC)
Commit e1f0310* (129 days old master)

A fresh build today on another machine gives errors with @everywhere using 
Roots.
It fails to load Distributions even with no parallel threads, but this 
appears to be unrelated.

On the same (other) machine, the following version loads and runs parallel 
code using the modules
mentioned above, and more.
Version 0.4.0-dev+4096 (2015-03-31 08:05 UTC)
Commit a3c0743* (120 days old master)

I see no error with 0.3.5-pre+121 (2015-01-07 00:19 UTC)


On Wednesday, July 29, 2015 at 11:24:55 PM UTC+2, lapeyre@gmail.com 
wrote:

 Parallel threads has stopped working for me. Any ideas ?
 Code using addprocs and @everywhere include has stopped working (is 
 broken) on one machine. Code that used to work now causes a number of 
 varying errors to be printed, crashes, runaway processes, etc. when it is 
 loaded. Both a recent v0.4 and a 2 month old version that did run the code 
 in the past cause the failure. The same code on a different machine 
 continues to run normally. Maybe my user Julia environment has a problem ? 
 Or maybe I upgraded a system library ?

 If I use just 2 processes, the code will sometimes  both load and run 
 correctly.

 A minimal example

 test.jl
 --
 using Distributions
 --

 julia -p 4
  @everywhere include(test.jl)

 WARNING: replacing module Distributions   ( 4 times )
 signal (11): Segmentation fault
 unknown function (ip: 0x7f235c7ffd98)
 jl_module_import at /usr/local/julia-0.4a/bin/../lib/julia/libjulia.so 
 (unknown line)

 etc.

 I am running unstable debian linux.

 Thanks, John

[julia-users] Re: Generalized Gamma Distribution

2015-07-26 Thread lapeyre . math122a

Yes, I think the other distributions in Distributions.jl check parameters, 
as well.

On Sunday, July 26, 2015 at 6:43:02 PM UTC+2, andrew cooke wrote:


 maybe you should assert sign(d) == sign(p) (or whatever the correct julia 
 equivalent is?)

 (sorry if this is dumb - i was just looking at the code out of curiousity 
 and don't know the maths)

 andrew


 On Friday, 24 July 2015 09:29:27 UTC-3, lapeyre@gmail.com wrote:

 Here is a generalized gamma distribution. 

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

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

 Only rand() and mean() are implemented, and again no tests. This depends 
 on Distributions. The authors of Distributions may want to include 
 something like this. The parameters may be chosen  to get the Amoroso 
 distribution (inverse generalized gamma distribution) mentioned in the 
 Wikipedia article.

 John

[julia-users] Re: Generalized Gamma Distribution

2015-07-26 Thread lapeyre . math122a

Since there is interest and you offer to review it, I want to. Not sure 
when I can do it, I am drowning in chores. It will take a bit of time to 
implement everything according to Distributions.jl, but it doesn't look 
hard.

John

On Sunday, July 26, 2015 at 6:11:07 PM UTC+2, Dahua Lin wrote:

 Great stuff.

 Can you make a PR to Distributions.jl? I'd be happy to review the codes 
 and merge when it is ready.

 Dahua


 On Friday, July 24, 2015 at 8:29:27 PM UTC+8, lapeyre@gmail.com wrote:

 Here is a generalized gamma distribution. 

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

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

 Only rand() and mean() are implemented, and again no tests. This depends 
 on Distributions. The authors of Distributions may want to include 
 something like this. The parameters may be chosen  to get the Amoroso 
 distribution (inverse generalized gamma distribution) mentioned in the 
 Wikipedia article.

 John

Re: [julia-users] Re: Inverse Laplace Transform

Sounds good to me.

On Friday, July 24, 2015 at 4:14:57 PM UTC+2, Stefan Karpinski wrote:

 Cool. Just to get an early start on package name bikeshedding, maybe 
 InverseLaplace.jl?

 On Fri, Jul 24, 2015 at 8:07 AM, lapeyre@gmail.com javascript: 
 wrote:

 The link 

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

Re: [julia-users] Re: Inverse Laplace Transform

New url:  
https://github.com/jlapeyre/InverseLaplace.jl/blob/master/src/InverseLaplace.jl

On Friday, July 24, 2015 at 4:14:57 PM UTC+2, Stefan Karpinski wrote:

 Cool. Just to get an early start on package name bikeshedding, maybe 
 InverseLaplace.jl?

 On Fri, Jul 24, 2015 at 8:07 AM, lapeyre@gmail.com javascript: 
 wrote:

 The link 

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

[julia-users] Inverse Laplace Transform

Hi,

Here is a numeric Inverse Laplace Transform. It needs some tests and stuff 
before making an ANN:,
That may not happen for a while, due to the standard excuses: baby, avoid 
getting fired. (Unless someone else writes them ;) )

-John

[julia-users] Generalized Gamma Distribution

Here is a generalized gamma distribution. 

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

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

Only rand() and mean() are implemented, and again no tests. This depends on 
Distributions. The authors of Distributions may want to include something 
like this. The parameters may be chosen  to get the Amoroso distribution 
(inverse generalized gamma distribution) mentioned in the Wikipedia article.

John

[julia-users] Re: Inverse Laplace Transform

The link 

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

[julia-users] Re: performance problem with factor

2015-05-25 Thread lapeyre . math122a


This package has a fast factoring function.

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

But it uses an external library. The code mentioned by Steven Johnson
is probably much faster (in general) than the current Julia code, but slower
than the code in PrimeSieve. But, the new code is a great step in the right 
direction
because it is in native Julia.



On Saturday, May 23, 2015 at 6:35:48 PM UTC+2, harven wrote:

 The factor function seems to be slow.

 julia @time factor(147573952589676412927)   # 2^67-1;  Cole
   elapsed time: 4.955545116 seconds (6 MB allocated, 6.82% gc time in 
 1 pauses with 0 full sweep)
   Dict{Int128,Int64} with 2 entries:
 761838257287 = 1
 193707721= 1

 This is even worse if a bigint is taken as argument (e.g. big(2)^67-1).
 In contrast, here is the timing for the unix factor utility (instant)

   $ time factor 147573952589676412927
   147573952589676412927: 193707721 761838257287

   real0m0.043s
   user0m0.000s
   sys 0m0.004s

 Is there a way to speed up the factorisation with julia?

Re: [julia-users] Re: Symbolic relations package

2015-04-21 Thread lapeyre . math122a



El martes, 21 de abril de 2015, 7:52:19 (UTC+2), Marcus Appelros escribió:

 Thank you for offering to help. I would like to phase out SymPy, but I 
 don't see it happening in the foreseeable future. I'm not sure how to 
 quantify the amount of capability in SymPy, but it is more or less 
 enormous. I think I could work 8 hours a day for a year and not duplicate 
 it in Julia.
 A better approach might be to complement SymPy, what would you say is 
 missing from SymPy? Also keeping it from entangling with the core like it 
 is now easy to disable SymPy by commenting two lines.


Yes, it would be nice to make SymPy optional, but that would take some 
work. In fact, the native Julia/SJulia Expand is much faster than SymPy, 
but handles fewer cases. Currently, the native version is disabled in favor 
of SymPy. Using the native version when possible would be better, but the 
logic would be quite a chore maybe its better to wait until there is a 
full replacement for Expand. Regarding what's missing, I don't really know. 
You could hang out on their lists. They are developing.  Maybe an example 
is  SJullia 'Count'. It takes a pattern as an argument. I don't think SymPy 
does something like this now, but they have some pattern matching and there 
is talk about doing something new. The way pattern matching is used in 
functions like 'Count' needs to be generalized. But really a better thing 
would be to spend some time looking at SymPy and SJulia (and maybe other 
things) and see what interests you. Or maybe what you are trying to do with 
Equations (I  didn;t look at it yet carefully) is really complementary to 
SJulila. I really think the most important thing is to improve the Julia 
-- SymPy AST translation. But, this is free software; I expect that 
you'll do, like everyone else, what you are motivated to do and what you 
find interesting.

Good plans for the future involve letting SJulia and Equations with 
 offsprings mingle behind the scenes, at the base there will certainly be 
 some duplicated functionality however am intending to quickly progress to 
 very specialized implementations.


Sure, it's good not to duplicate effort, and to get things to play well 
together. If you keep up with Equations, I am interested in helping it 
communicate with SJulia.  I may have said it before, but my primary 
interest with SJulia is making something like Mathematica that is useful of 
r 'the masses' and not only computer enthusiasts, ie something for people 
who want to get an integral quickly and hate hearing 'everything is an 
object' and 'homoiconic'. The Julia and Python ecosystems and support for 
interfacing are awesome, which is really something to take advantage of. 
I'm glad I took Francesco Bonazzi's advice (and help) about translating the 
SymPy AST sooner rather than later. Interfacing with Maxima (and maybe, eg. 
Axiom) might be very useful as well, but I'm not going to investigate 
writing a CL interface at the moment.
 

 Your example does work for me using  Version 0.4.0-dev+3965 (2015-03-22 
 12:24 UTC),
 but things break fast with 0.4.0 !
 Alright will have to get access to recent versions of everything, 
 configuring a cloud computer to handle julia comfortably, it is currently 
 running with minimum resources.


I just tried SJulia on a recent Julia v0.4 build. I mostly works, but there 
are some new errors.
 

 You shouldn't need to do all that. I'll have to build a new v 0.4.0 and 
 see if there is a problem.
 Was looking for the source code for the expansion, expanding large 
 polynomials is currently a problem in Equations.

 Yes, the macro is expanded when it is entered. Julia functions can be 
 used with SJulia, but it is not integrated to this extent. I think I do 
 have a Julia-side interface to Expand, but it is disabled. I need to find a 
 more organized way to make some SJulia functionality available from Julia.
 How do julia functions work at sjulia... ?

 The SJulia command line mode is now built into the module, you no longer 
 need to build the fork of Julia (thanks Keno).
 Superduper!

Re: [julia-users] Re: Symbolic relations package

2015-04-21 Thread lapeyre . math122a



El martes, 21 de abril de 2015, 13:16:02 (UTC+2), Marcus Appelros escribió:

 Which cases can not be handled by your native expander?


A lot of cases, IIRC it only does binomial expansion.
 

 Currently 
 Equations should handle all standard cases 


I checked it out tried a few things. It's very nice. The expansion worked 
fine,
and no mystery about how to use it.
 

 (it is training to be able 
 to revert an expansion into a Pow) but it isn't feasible for stuff 
 like (:x+:y+:z)^100. Am writing a generalized expression matcher to 
 create chains of equations, will develop structures for 
 equationchaining in non-commutative geometry and quantum gravity, in 
 collaboration with Vietnam national university. 

 We share goals, want Equations to be so simple that essentially only 
 one function needs to be called, then an AI handles that function and 
 the user tells the AI what they have and where they want to go from 
 which the AI delivers the closest match. 

 Have been building the current master since morning, there is some 
 build error at osutils and have just ran a distupgrade+reclone, will 
 file and clone your fork if that doesn't work. 


I'm trying in on a few machines and I'm a bit confused on requirements and 
compatibility. Some of it
might depend on the version of SymPy that is installed. I think it needs to 
be a recent one.
 

 On 21 April 2015 at 13:35,  lapeyre@gmail.com javascript: wrote: 
  
  
  El martes, 21 de abril de 2015, 7:52:19 (UTC+2), Marcus Appelros 
 escribió: 
  
  Thank you for offering to help. I would like to phase out SymPy, but I 
  don't see it happening in the foreseeable future. I'm not sure how to 
  quantify the amount of capability in SymPy, but it is more or less 
  enormous. I think I could work 8 hours a day for a year and not 
 duplicate 
  it in Julia. 
  A better approach might be to complement SymPy, what would you say is 
  missing from SymPy? Also keeping it from entangling with the core like 
 it is 
  now easy to disable SymPy by commenting two lines. 
  
  
  Yes, it would be nice to make SymPy optional, but that would take some 
 work. 
  In fact, the native Julia/SJulia Expand is much faster than SymPy, but 
  handles fewer cases. Currently, the native version is disabled in favor 
 of 
  SymPy. Using the native version when possible would be better, but the 
 logic 
  would be quite a chore maybe its better to wait until there is a 
 full 
  replacement for Expand. Regarding what's missing, I don't really know. 
 You 
  could hang out on their lists. They are developing.  Maybe an example is 
  SJullia 'Count'. It takes a pattern as an argument. I don't think SymPy 
 does 
  something like this now, but they have some pattern matching and there 
 is 
  talk about doing something new. The way pattern matching is used in 
  functions like 'Count' needs to be generalized. But really a better 
 thing 
  would be to spend some time looking at SymPy and SJulia (and maybe other 
  things) and see what interests you. Or maybe what you are trying to do 
 with 
  Equations (I  didn;t look at it yet carefully) is really complementary 
 to 
  SJulila. I really think the most important thing is to improve the Julia 
  -- SymPy AST translation. But, this is free software; I expect that 
 you'll 
  do, like everyone else, what you are motivated to do and what you find 
  interesting. 
  
  Good plans for the future involve letting SJulia and Equations with 
  offsprings mingle behind the scenes, at the base there will certainly 
 be 
  some duplicated functionality however am intending to quickly progress 
 to 
  very specialized implementations. 
  
  
  Sure, it's good not to duplicate effort, and to get things to play well 
  together. If you keep up with Equations, I am interested in helping it 
  communicate with SJulia.  I may have said it before, but my primary 
 interest 
  with SJulia is making something like Mathematica that is useful of r 
 'the 
  masses' and not only computer enthusiasts, ie something for people who 
 want 
  to get an integral quickly and hate hearing 'everything is an object' 
 and 
  'homoiconic'. The Julia and Python ecosystems and support for 
 interfacing 
  are awesome, which is really something to take advantage of. I'm glad I 
 took 
  Francesco Bonazzi's advice (and help) about translating the SymPy AST 
 sooner 
  rather than later. Interfacing with Maxima (and maybe, eg. Axiom) might 
 be 
  very useful as well, but I'm not going to investigate writing a CL 
 interface 
  at the moment. 
  
  
  Your example does work for me using  Version 0.4.0-dev+3965 
 (2015-03-22 
  12:24 UTC), 
  but things break fast with 0.4.0 ! 
  Alright will have to get access to recent versions of everything, 
  configuring a cloud computer to handle julia comfortably, it is 
 currently 
  running with minimum resources. 
  
  
  I just tried SJulia on a recent Julia v0.4 build. I mostly works, but 
 there 
  are some new errors.

Re: [julia-users] Symbolic relations package

I think it would be great to submit the REPL mod, but it is not acceptable 
as it is, although, for the most part, it is pretty solid. Currently, a 
period as the first character switches both in and out of SJulia mode. Some 
advice from the REPL authors would be useful. I was not able to implement 
switching out of SJulia with backspace, you have to type the period again. 
Also, the mod introduces a bug that causes Julia to crash when greek 
symbols are entered in a certain context, even in normal Julia mode. I am 
not able to get command line completion to work in a clean way in SJulia. 
As Marcus suggested, making a general facility for passing input through a 
macro seems like the way to go. It probably would not be too hard for 
someone who understands the REPL code. I might find time to do it, with 
some help.

--John

El lunes, 20 de abril de 2015, 20:08:17 (UTC+2), Viral Shah escribió:

 It would be great to have the REPL.jl fork submitted as a PR. Even if it 
 is not accepted, something good will certainly come out of it. 

 -viral 



  On 20-Apr-2015, at 11:34 pm, Marcus Appelros marcus@gmail.com 
 javascript: wrote: 
  
  Currently some modifications to REPL.jl are needed, there is a fork 
  made which does exactly that. 
  
  Am trying to test some of the examples in the SJulia readme, keep in 
  mind that this is on a old sourcebuilt 0.4 master. 
  
  ``` 
  julia m= @ex Expand((a+b)^10) 
  Expand((a + b) ^ 10) 
  
  julia m[2] 
  ERROR: BoundsError() 
  in getindex at /home/quin/SJulia/src/mxpr_type.jl:267 
  ``` 
  
  Apparently the only method found is: 
  
  ``` 
  julia t= @ex (a+b)^10 
  (a + b) ^ 10 
  
  julia typeof(t) 
  Mxpr{Power} 
  
  julia tt=SJulia.mxpr(:Expand,t) 
  Expand((a + b) ^ 10) 
  
  julia ttt=typeof(tt) 
  Mxpr{Expand} 
  
  julia methods(SJulia.apprules,(ttt,)) 
  1-element Array{Any,1}: 
  apprules(x) at /home/quin/SJulia/src/apprules.jl:9 
  ``` 
  
  Which is set to equal x. Also there's this: 
  
  ``` 
  julia function f(n);@ex Expand((a+b)^n);end 
  f (generic function with 1 method) 
  
  julia f(3) 
  Expand((a + b) ^ n) 
  ``` 
  
  The Fibbonacci example does work. 
  
  On 20 April 2015 at 19:14, Viral Shah vi...@mayin.org javascript: 
 wrote: 
  Would it be possible to install SJulia as a Julia package, and switch 
  between SJulia and Julia - kind of like how we have the help and the 
 shell 
  prompts, which can be activated with ? and ; 
  
  -viral 
  
  
  On Monday, April 20, 2015 at 5:46:08 PM UTC+5:30, lapeyre@gmail.com 
  wrote: 
  
  Here is SJulia 
  
  https://github.com/jlapeyre/SJulia 
  
  sjulia f = (x^y + y^z + z^x)^3 
  (x ^ y + y ^ z + z ^ x) ^ 3 
  
  sjulia f = (x^y + y^z)^3 
  (x ^ y + y ^ z) ^ 3 
  
  sjulia g = Expand(f) 
  x ^ (3 * y) + 3 * (x ^ (2 * y)) * (y ^ z) + 3 * (x ^ y) * (y ^ (2 * 
 z)) + 
  y ^ (3 * z) 
  
  SJulia is very close in spirit to Mathematica (Wolfram). This is more 
 or 
  less a language written in Julia, 
  although it can be made to communicate well with Julia. From the 
 user's 
  perspective, there are advantages and disadvantages to 
  implementing symbolic capability as an extension to languages like 
 Julia 
  or Python rather than as 
  another language. I think it is possible to have a language that 
 supports 
  both. 
  
  Also, CAS can describe various software tools that are designed to do 
 very 
  different things. For instance, a CAS may  be intended to implement 
 more or 
  less mathematical rigor. It may have a hierarchy of computer language 
 types 
  meant to represent mathematical objects. Or 
  it may (like Mathematica, Maple, and Maxima) be based on 'expressions' 
  that are essentially devoid of meaning. All of these distinctions, 
  particularly the latter, regarding purpose, are typically confused in 
  discussions on internet fora. 
  
  I think that Julia is a great language for symbolic computation. Have 
 fun! 
  --John 
  
  
  On Sunday, April 19, 2015 at 7:47:34 PM UTC+2, Marcus Appelros wrote: 
  
  Hi Kevin, thanks for the link! From the end of that thread: 
  
  Has anybody written pure Julia symbolic math for things like: 
  
  f = (x**y + y**z + z**x)**100 
  g = f.expand() 
  
  As far as I know there is no Julia package which supports such 
 symbolic 
  expressions and manipulation. 
  
  Now there is! 
  
  Saw a more recent dev discussion calling for someone to write a 
 package 
  like this. Have looked through the package list many times and never 
 found 
  anything that appeared alike the vision of Equations, SymPy has some 
 common 
  functionality however certainly didn't start developing in Julia to 
 use 
  Python. 
  
  Developing this code is indeed very enjoying and as more of the 
 planned 
  features become released a solid user base will be established, have 
  expanded the todolist with an impelling to read the discussion in 
 your link 
  so as to hasten the construction of such a foundation, as per your 
  recommendation. 
  
  With love.

Re: [julia-users] Re: Symbolic relations package

SJulia already works as a package (Jim Garrison made the changes). I just 
learned that it should be possible to add a mode to the REPL in the package 
code, so that the fork/PR-to-Julia is no longer necessary. I hope to get to 
this soon.

--John

El lunes, 20 de abril de 2015, 18:14:27 (UTC+2), Viral Shah escribió:

 Would it be possible to install SJulia as a Julia package, and switch 
 between SJulia and Julia - kind of like how we have the help and the 
 shell prompts, which can be activated with ? and ;

 -viral

 On Monday, April 20, 2015 at 5:46:08 PM UTC+5:30, lapeyre@gmail.com 
 wrote:

 Here is SJulia

 https://github.com/jlapeyre/SJulia

 sjulia f = (x^y + y^z + z^x)^3
 (x ^ y + y ^ z + z ^ x) ^ 3

 sjulia f = (x^y + y^z)^3
 (x ^ y + y ^ z) ^ 3

 sjulia g = Expand(f)
 x ^ (3 * y) + 3 * (x ^ (2 * y)) * (y ^ z) + 3 * (x ^ y) * (y ^ (2 * z)) + 
 y ^ (3 * z)

 SJulia is very close in spirit to Mathematica (Wolfram). This is more or 
 less a language written in Julia,
 although it can be made to communicate well with Julia. From the user's 
 perspective, there are advantages and disadvantages to
 implementing symbolic capability as an extension to languages like Julia 
 or Python rather than as
 another language. I think it is possible to have a language that supports 
 both.

 Also, CAS can describe various software tools that are designed to do 
 very different things. For instance, a CAS may  be intended to implement 
 more or less mathematical rigor. It may have a hierarchy of computer 
 language types meant to represent mathematical objects. Or
 it may (like Mathematica, Maple, and Maxima) be based on 'expressions' 
 that are essentially devoid of meaning. All of these distinctions, 
 particularly the latter, regarding purpose, are typically confused in 
 discussions on internet fora.

 I think that Julia is a great language for symbolic computation. Have fun!
 --John


 On Sunday, April 19, 2015 at 7:47:34 PM UTC+2, Marcus Appelros wrote:

 Hi Kevin, thanks for the link! From the end of that thread:

 Has anybody written pure Julia symbolic math for things like:

 f = (x**y + y**z + z**x)**100
 g = f.expand()

 As far as I know there is no Julia package which supports such symbolic 
 expressions and manipulation.

 Now there is!

 Saw a more recent dev discussion calling for someone to write a package 
 like this. Have looked through the package list many times and never found 
 anything that appeared alike the vision of Equations, SymPy has some common 
 functionality however certainly didn't start developing in Julia to use 
 Python.

 Developing this code is indeed very enjoying and as more of the planned 
 features become released a solid user base will be established, have 
 expanded the todolist with an impelling to read the discussion in your link 
 so as to hasten the construction of such a foundation, as per your 
 recommendation. 

 With love. 3

Re: [julia-users] Re: Symbolic relations package



El lunes, 20 de abril de 2015, 20:04:25 (UTC+2), Marcus Appelros escribió:

 Currently some modifications to REPL.jl are needed, there is a fork 
 made which does exactly that. 

 Am trying to test some of the examples in the SJulia readme, keep in 
 mind that this is on a old sourcebuilt 0.4 master. 

 ``` 
 julia m= @ex Expand((a+b)^10) 
 Expand((a + b) ^ 10) 

 julia m[2] 
 ERROR: BoundsError() 
  in getindex at /home/quin/SJulia/src/mxpr_type.jl:267 
 ``` 

 Your example does work for me using  Version 0.4.0-dev+3965 (2015-03-22 
12:24 UTC),
but things break fast with 0.4.0 !
 

 Apparently the only method found is: 

 ``` 
 julia t= @ex (a+b)^10 
 (a + b) ^ 10 

 julia typeof(t) 
 Mxpr{Power} 

 julia tt=SJulia.mxpr(:Expand,t) 
 Expand((a + b) ^ 10) 

 julia ttt=typeof(tt) 
 Mxpr{Expand} 

 julia methods(SJulia.apprules,(ttt,)) 
 1-element Array{Any,1}: 
  apprules(x) at /home/quin/SJulia/src/apprules.jl:9 
 ``` 

  
You shouldn't need to do all that. I'll have to build a new v 0.4.0 and see 
if there is a problem.
 

 Which is set to equal x. Also there's this: 

 ``` 
 julia function f(n);@ex Expand((a+b)^n);end 
 f (generic function with 1 method) 

 julia f(3) 
 Expand((a + b) ^ n) 
 ``` 


Yes, the macro is expanded when it is entered. Julia functions can be used 
with SJulia, but it is not integrated to this extent. I think I do have a 
Julia-side interface to Expand, but it is disabled. I need to find a more 
organized way to make some SJulia functionality available from Julia.

 

 The Fibbonacci example does work. 

 On 20 April 2015 at 19:14, Viral Shah vi...@mayin.org javascript: 
 wrote: 
  Would it be possible to install SJulia as a Julia package, and switch 
  between SJulia and Julia - kind of like how we have the help and the 
 shell 
  prompts, which can be activated with ? and ; 
  
  -viral 
  
  
  On Monday, April 20, 2015 at 5:46:08 PM UTC+5:30, lapeyre@gmail.com 
  wrote: 
  
  Here is SJulia 
  
  https://github.com/jlapeyre/SJulia 
  
  sjulia f = (x^y + y^z + z^x)^3 
  (x ^ y + y ^ z + z ^ x) ^ 3 
  
  sjulia f = (x^y + y^z)^3 
  (x ^ y + y ^ z) ^ 3 
  
  sjulia g = Expand(f) 
  x ^ (3 * y) + 3 * (x ^ (2 * y)) * (y ^ z) + 3 * (x ^ y) * (y ^ (2 * z)) 
 + 
  y ^ (3 * z) 
  
  SJulia is very close in spirit to Mathematica (Wolfram). This is more 
 or 
  less a language written in Julia, 
  although it can be made to communicate well with Julia. From the user's 
  perspective, there are advantages and disadvantages to 
  implementing symbolic capability as an extension to languages like 
 Julia 
  or Python rather than as 
  another language. I think it is possible to have a language that 
 supports 
  both. 
  
  Also, CAS can describe various software tools that are designed to do 
 very 
  different things. For instance, a CAS may  be intended to implement 
 more or 
  less mathematical rigor. It may have a hierarchy of computer language 
 types 
  meant to represent mathematical objects. Or 
  it may (like Mathematica, Maple, and Maxima) be based on 'expressions' 
  that are essentially devoid of meaning. All of these distinctions, 
  particularly the latter, regarding purpose, are typically confused in 
  discussions on internet fora. 
  
  I think that Julia is a great language for symbolic computation. Have 
 fun! 
  --John 
  
  
  On Sunday, April 19, 2015 at 7:47:34 PM UTC+2, Marcus Appelros wrote: 
  
  Hi Kevin, thanks for the link! From the end of that thread: 
  
  Has anybody written pure Julia symbolic math for things like: 
  
  f = (x**y + y**z + z**x)**100 
  g = f.expand() 
  
  As far as I know there is no Julia package which supports such 
 symbolic 
  expressions and manipulation. 
  
  Now there is! 
  
  Saw a more recent dev discussion calling for someone to write a 
 package 
  like this. Have looked through the package list many times and never 
 found 
  anything that appeared alike the vision of Equations, SymPy has some 
 common 
  functionality however certainly didn't start developing in Julia to 
 use 
  Python. 
  
  Developing this code is indeed very enjoying and as more of the 
 planned 
  features become released a solid user base will be established, have 
  expanded the todolist with an impelling to read the discussion in your 
 link 
  so as to hasten the construction of such a foundation, as per your 
  recommendation. 
  
  With love. 3

Re: [julia-users] Re: Symbolic relations package

The SJulia command line mode is now built into the module, you no longer 
need to build the fork of Julia (thanks Keno).

https://github.com/jlapeyre/SJulia

julia  using SJulia 
sjulia  Integrate(Exp(-x^2),[x,0,Infinity])# hit '' to enter SJulia 
mode
(1//2) * (π ^ (1//2))


El lunes, 20 de abril de 2015, 18:14:27 (UTC+2), Viral Shah escribió:

 Would it be possible to install SJulia as a Julia package, and switch 
 between SJulia and Julia - kind of like how we have the help and the 
 shell prompts, which can be activated with ? and ;

 -viral

 On Monday, April 20, 2015 at 5:46:08 PM UTC+5:30, lapeyre@gmail.com 
 wrote:

 Here is SJulia

 https://github.com/jlapeyre/SJulia

 sjulia f = (x^y + y^z + z^x)^3
 (x ^ y + y ^ z + z ^ x) ^ 3

 sjulia f = (x^y + y^z)^3
 (x ^ y + y ^ z) ^ 3

 sjulia g = Expand(f)
 x ^ (3 * y) + 3 * (x ^ (2 * y)) * (y ^ z) + 3 * (x ^ y) * (y ^ (2 * z)) + 
 y ^ (3 * z)

 SJulia is very close in spirit to Mathematica (Wolfram). This is more or 
 less a language written in Julia,
 although it can be made to communicate well with Julia. From the user's 
 perspective, there are advantages and disadvantages to
 implementing symbolic capability as an extension to languages like Julia 
 or Python rather than as
 another language. I think it is possible to have a language that supports 
 both.

 Also, CAS can describe various software tools that are designed to do 
 very different things. For instance, a CAS may  be intended to implement 
 more or less mathematical rigor. It may have a hierarchy of computer 
 language types meant to represent mathematical objects. Or
 it may (like Mathematica, Maple, and Maxima) be based on 'expressions' 
 that are essentially devoid of meaning. All of these distinctions, 
 particularly the latter, regarding purpose, are typically confused in 
 discussions on internet fora.

 I think that Julia is a great language for symbolic computation. Have fun!
 --John


 On Sunday, April 19, 2015 at 7:47:34 PM UTC+2, Marcus Appelros wrote:

 Hi Kevin, thanks for the link! From the end of that thread:

 Has anybody written pure Julia symbolic math for things like:

 f = (x**y + y**z + z**x)**100
 g = f.expand()

 As far as I know there is no Julia package which supports such symbolic 
 expressions and manipulation.

 Now there is!

 Saw a more recent dev discussion calling for someone to write a package 
 like this. Have looked through the package list many times and never found 
 anything that appeared alike the vision of Equations, SymPy has some common 
 functionality however certainly didn't start developing in Julia to use 
 Python.

 Developing this code is indeed very enjoying and as more of the planned 
 features become released a solid user base will be established, have 
 expanded the todolist with an impelling to read the discussion in your link 
 so as to hasten the construction of such a foundation, as per your 
 recommendation. 

 With love. 3

Re: [julia-users] Re: Symbolic relations package

Thank you for offering to help. I would like to phase out SymPy, but I 
don't see it happening in the foreseeable future. I'm not sure how to 
quantify the amount of capability in SymPy, but it is more or less 
enormous. I think I could work 8 hours a day for a year and not duplicate 
it in Julia. At the moment, I'm able to invest zero hours per day, but I 
hope that will change in the summer. More important now is phasing SymPy 
in: Translating the two AST's works quite well, but it is not complete. 
But, there is a lot of stuff to work on that is not in SymPy, like 
improving pattern matching.  If one were serious about removing the 
SymPy dependency, the best thing to do would be to work on improving the 
SymPy interface because this is the fastest way to make SJulia useful, 
which would attract users, and therefore developers.

--John

El lunes, 20 de abril de 2015, 16:42:02 (UTC+2), Marcus Appelros escribió:

 Awesome! Do you have plans to eventually phase out the SymPy dependency? 
 We can collaborate on that!

 On Monday, 20 April 2015 15:16:08 UTC+3, lapeyre@gmail.com wrote:

 Here is SJulia

 https://github.com/jlapeyre/SJulia

Re: [julia-users] Symbolic relations package

Great!  This will allow me to include the SJulia REPL in the SJulia package 
(IIUC), so that one doesn't need to build a fork of Julia. --John

El lunes, 20 de abril de 2015, 23:14:31 (UTC+2), Keno Fischer escribió:

 The REPL code was designed to have new modes added externally. See e.g. 
 the RunCxxREPL function here: 
 https://github.com/Keno/Cxx.jl/blob/master/src/CxxREPL/replpane.jl

 On Mon, Apr 20, 2015 at 5:04 PM, lapeyre@gmail.com javascript: 
 wrote:

 I think it would be great to submit the REPL mod, but it is not 
 acceptable as it is, although, for the most part, it is pretty solid. 
 Currently, a period as the first character switches both in and out of 
 SJulia mode. Some advice from the REPL authors would be useful. I was not 
 able to implement switching out of SJulia with backspace, you have to type 
 the period again. Also, the mod introduces a bug that causes Julia to crash 
 when greek symbols are entered in a certain context, even in normal Julia 
 mode. I am not able to get command line completion to work in a clean way 
 in SJulia. As Marcus suggested, making a general facility for passing input 
 through a macro seems like the way to go. It probably would not be too hard 
 for someone who understands the REPL code. I might find time to do it, with 
 some help.

 --John

 El lunes, 20 de abril de 2015, 20:08:17 (UTC+2), Viral Shah escribió:

 It would be great to have the REPL.jl fork submitted as a PR. Even if it 
 is not accepted, something good will certainly come out of it. 

 -viral 



  On 20-Apr-2015, at 11:34 pm, Marcus Appelros marcus@gmail.com 
 wrote: 
  
  Currently some modifications to REPL.jl are needed, there is a fork 
  made which does exactly that. 
  
  Am trying to test some of the examples in the SJulia readme, keep in 
  mind that this is on a old sourcebuilt 0.4 master. 
  
  ``` 
  julia m= @ex Expand((a+b)^10) 
  Expand((a + b) ^ 10) 
  
  julia m[2] 
  ERROR: BoundsError() 
  in getindex at /home/quin/SJulia/src/mxpr_type.jl:267 
  ``` 
  
  Apparently the only method found is: 
  
  ``` 
  julia t= @ex (a+b)^10 
  (a + b) ^ 10 
  
  julia typeof(t) 
  Mxpr{Power} 
  
  julia tt=SJulia.mxpr(:Expand,t) 
  Expand((a + b) ^ 10) 
  
  julia ttt=typeof(tt) 
  Mxpr{Expand} 
  
  julia methods(SJulia.apprules,(ttt,)) 
  1-element Array{Any,1}: 
  apprules(x) at /home/quin/SJulia/src/apprules.jl:9 
  ``` 
  
  Which is set to equal x. Also there's this: 
  
  ``` 
  julia function f(n);@ex Expand((a+b)^n);end 
  f (generic function with 1 method) 
  
  julia f(3) 
  Expand((a + b) ^ n) 
  ``` 
  
  The Fibbonacci example does work. 
  
  On 20 April 2015 at 19:14, Viral Shah vi...@mayin.org wrote: 
  Would it be possible to install SJulia as a Julia package, and switch 
  between SJulia and Julia - kind of like how we have the help and the 
 shell 
  prompts, which can be activated with ? and ; 
  
  -viral 
  
  
  On Monday, April 20, 2015 at 5:46:08 PM UTC+5:30, 
 lapeyre@gmail.com 
  wrote: 
  
  Here is SJulia 
  
  https://github.com/jlapeyre/SJulia 
  
  sjulia f = (x^y + y^z + z^x)^3 
  (x ^ y + y ^ z + z ^ x) ^ 3 
  
  sjulia f = (x^y + y^z)^3 
  (x ^ y + y ^ z) ^ 3 
  
  sjulia g = Expand(f) 
  x ^ (3 * y) + 3 * (x ^ (2 * y)) * (y ^ z) + 3 * (x ^ y) * (y ^ (2 * 
 z)) + 
  y ^ (3 * z) 
  
  SJulia is very close in spirit to Mathematica (Wolfram). This is 
 more or 
  less a language written in Julia, 
  although it can be made to communicate well with Julia. From the 
 user's 
  perspective, there are advantages and disadvantages to 
  implementing symbolic capability as an extension to languages like 
 Julia 
  or Python rather than as 
  another language. I think it is possible to have a language that 
 supports 
  both. 
  
  Also, CAS can describe various software tools that are designed to 
 do very 
  different things. For instance, a CAS may  be intended to implement 
 more or 
  less mathematical rigor. It may have a hierarchy of computer 
 language types 
  meant to represent mathematical objects. Or 
  it may (like Mathematica, Maple, and Maxima) be based on 
 'expressions' 
  that are essentially devoid of meaning. All of these distinctions, 
  particularly the latter, regarding purpose, are typically confused 
 in 
  discussions on internet fora. 
  
  I think that Julia is a great language for symbolic computation. 
 Have fun! 
  --John 
  
  
  On Sunday, April 19, 2015 at 7:47:34 PM UTC+2, Marcus Appelros 
 wrote: 
  
  Hi Kevin, thanks for the link! From the end of that thread: 
  
  Has anybody written pure Julia symbolic math for things like: 
  
  f = (x**y + y**z + z**x)**100 
  g = f.expand() 
  
  As far as I know there is no Julia package which supports such 
 symbolic 
  expressions and manipulation. 
  
  Now there is! 
  
  Saw a more recent dev discussion calling for someone to write a 
 package 
  like this. Have looked through the package list many times and 
 never found 
  anything that appeared alike the

[julia-users] Re: BinDeps, C libraries in packages

It would complicate Example.jl quite a bit. On the other hand, because it's 
so simple, I look at other packages, not Example.jl, when I need an ... 
example.

--John


El lunes, 20 de abril de 2015, 18:12:29 (UTC+2), Viral Shah escribió:

 This seems like it is something useful to have in Example.jl. Perhaps 
 people will then have a reason to use Example.jl for something!

 -iral

 On Monday, April 20, 2015 at 6:24:35 PM UTC+5:30, lapeyre@gmail.com 
 wrote:

 Here is an example of using BinDeps to download and build C libraries 
 when building your Julia package.

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

 This file includes a lot of comments:

 https://github.com/jlapeyre/PrimeSieve.jl/blob/master/deps/build.jl

 I am posting this here because it may be useful for people trying to use 
 BinDeps, since it seems there was a lack of
 examples, at least examples that could be located easily.

 I meant to post this a few months ago, but didn't get around to it.

 --John

[julia-users] BinDeps, C libraries in packages

Here is an example of using BinDeps to download and build C libraries when 
building your Julia package.

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

This file includes a lot of comments:

https://github.com/jlapeyre/PrimeSieve.jl/blob/master/deps/build.jl

I am posting this here because it may be useful for people trying to use 
BinDeps, since it seems there was a lack of
examples, at least examples that could be located easily.

I meant to post this a few months ago, but didn't get around to it.

--John

Re: [julia-users] Re: Symbolic relations package

Here is SJulia

https://github.com/jlapeyre/SJulia

sjulia f = (x^y + y^z + z^x)^3
(x ^ y + y ^ z + z ^ x) ^ 3

sjulia f = (x^y + y^z)^3
(x ^ y + y ^ z) ^ 3

sjulia g = Expand(f)
x ^ (3 * y) + 3 * (x ^ (2 * y)) * (y ^ z) + 3 * (x ^ y) * (y ^ (2 * z)) + y 
^ (3 * z)

SJulia is very close in spirit to Mathematica (Wolfram). This is more or 
less a language written in Julia,
although it can be made to communicate well with Julia. From the user's 
perspective, there are advantages and disadvantages to
implementing symbolic capability as an extension to languages like Julia or 
Python rather than as
another language. I think it is possible to have a language that supports 
both.

Also, CAS can describe various software tools that are designed to do very 
different things. For instance, a CAS may  be intended to implement more or 
less mathematical rigor. It may have a hierarchy of computer language types 
meant to represent mathematical objects. Or
it may (like Mathematica, Maple, and Maxima) be based on 'expressions' that 
are essentially devoid of meaning. All of these distinctions, particularly 
the latter, regarding purpose, are typically confused in discussions on 
internet fora.

I think that Julia is a great language for symbolic computation. Have fun!
--John


On Sunday, April 19, 2015 at 7:47:34 PM UTC+2, Marcus Appelros wrote:

 Hi Kevin, thanks for the link! From the end of that thread:

 Has anybody written pure Julia symbolic math for things like:

 f = (x**y + y**z + z**x)**100
 g = f.expand()

 As far as I know there is no Julia package which supports such symbolic 
 expressions and manipulation.

 Now there is!

 Saw a more recent dev discussion calling for someone to write a package 
 like this. Have looked through the package list many times and never found 
 anything that appeared alike the vision of Equations, SymPy has some common 
 functionality however certainly didn't start developing in Julia to use 
 Python.

 Developing this code is indeed very enjoying and as more of the planned 
 features become released a solid user base will be established, have 
 expanded the todolist with an impelling to read the discussion in your link 
 so as to hasten the construction of such a foundation, as per your 
 recommendation. 

 With love. 3

[julia-users] Re: building Julia could not allocate pools

2015-03-22 Thread lapeyre . math122a

I confirm that removing  ulimit -Sv 500 from .bashrc allows me to 
build Julia, or at least advances me to the next, unrelated problem.
Thanks.

On Tuesday, March 3, 2015 at 4:40:40 PM UTC+1, Jonathan Anderson wrote:

 I have the same problem (user janders cannot build julia: 
 https://gist.github.com/JonathanAnderson/7fa10f187c564c864817). I thought 
 it might be related to a ulimit restriction placed on my userid so I built 
 with a different userid that has no limit.

 This userid is able to build everything successfully on the same host that 
 my build failed on.

 The following data point is also interesting 

 I copied the built software onto a NFS partition that ignores ownership 
 and everything is a+rwx
 * When I run this build as the userid that built the software, I can run 
 the build
 * If I run as the userid researcher, I can run this build
 * If I run as my original userid (janders) I get the could not allocate 
 pools

 Here is janders' ulimit -a

 ulimit -a
 -t: cpu time (seconds) unlimited
 -f: file size (blocks) unlimited
 -d: data seg size (kbytes) unlimited
 -s: stack size (kbytes)8192
 -c: core file size (blocks)unlimited
 -m: resident set size (kbytes) unlimited
 -u: processes  256722
 -n: file descriptors   1024
 -l: locked-in-memory size (kb) unlimited
 -v: address space (kb) 800
 -x: file locks unlimited
 -i: pending signals256722
 -q: bytes in POSIX msg queues  819200
 -e: max nice   40
 -r: max rt priorityunlimited
 -N 15: unlimited

 What else can I provide to debug this?

 On Friday, February 27, 2015 at 7:18:55 AM UTC-6, lapeyre@gmail.com 
 wrote:

 Anyone know something about this ?

 I did not build the latest Julia (master branch) since about 30 days.
 Now, when I do 'git pull' and 'make' I am getting various error messages:

could not allocate pools
Aborted
Makefile:165: recipe for target 
 '/home/jlapeyre/software_source/julia/usr/lib/julia/sys0.o' failed

 This was a few days ago, so I 'pulled' every once in a while, hoping the 
 problem would go away.
 I tried make clean, make cleanall, make distcleanall. Then dependencies 
 also fail to build
 I removed even the packages with   make -C deps distcleanall.

 I have not changed my tool chain since the last successful build. I can't 
 recall, but there is a
 chance (but, I think not) that I moved the entire repository from one 
 place to another.

 Since I don't see any noise about this, something tells me its not a 
 common problem.

 --John

[julia-users] Re: Factorization of big integers is taking too long

2015-03-19 Thread lapeyre . math122a

Tim is correct in a sense. I translated some big int code a while ago, I 
think it was the pollard rho method (don't quite remember the details) and 
the inability to reuse storage for a bigint caused a big performance hit. 
(I thought about some workaround, but unfortunately I don't remember what 
it was or if I even tried it)

Stefan wrote a simple stop-gap factor() routine and noted in a comment that 
it needs to be improved. But Bill Hart is correct: It can't do 3^100 + 2 no 
matter how efficient bigint arithmetic is.

The Maxima routines and the perl module by Dana Jacobsen are good, but they 
would require translating and asking the authors to liberalize the license.

I wrapped the msieve c library.

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

It does 3^100 + 2 in less than a second on my machine

On Friday, March 13, 2015 at 6:20:16 PM UTC+1, Hans W Borchers wrote:

 I got interested in factorizing some larger integers such as N = 3^100 + 2 
 .
 In all tries, factor(N) did not return and had to be interrupted:

 julia N = big(3)^100 + 2
 julia factor(N)
 ^CERROR: interrupt
  in finalizer at ./base.jl:126
  in + at gmp.jl:243
  in factor at primes.jl:111

 It is calling GMP, but the GMP software cannot be the reason as this works 
 with the GMP package in R and returns the factorization within seconds:

 R library(gmp)
 R N - bigz(3)^100
 R factorize(N)
 Big Integer ('bigz') object of length 3:
 [1] 31721   246451584544723 65924521656039679831393482841
 R system.time(factorize(N))
  user  system elapsed 
 3.738   0.000   3.730

 Is this a bug? Did I do something wrong?
 The first factor, 31721, is not even large. Mathematical software such as 
 GAP or PARI/GP will factorize this in much less than a second.

 PS: Versioninfo
 Julia Version 0.3.6; System: Linux (x86_64-linux-gnu)
 CPU: Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz; WORD_SIZE: 64
 BLAS: libblas.so.3; LAPACK: liblapack.so.3
 LIBM: libopenlibm; LLVM: libLLVM-3.3

[julia-users] building Julia could not allocate pools

Anyone know something about this ?

I did not build the latest Julia (master branch) since about 30 days.
Now, when I do 'git pull' and 'make' I am getting various error messages:

   could not allocate pools
   Aborted
   Makefile:165: recipe for target 
'/home/jlapeyre/software_source/julia/usr/lib/julia/sys0.o' failed

This was a few days ago, so I 'pulled' every once in a while, hoping the 
problem would go away.
I tried make clean, make cleanall, make distcleanall. Then dependencies 
also fail to build
I removed even the packages with   make -C deps distcleanall.

I have not changed my tool chain since the last successful build. I can't 
recall, but there is a
chance (but, I think not) that I moved the entire repository from one place 
to another.

Since I don't see any noise about this, something tells me its not a common 
problem.

--John

[julia-users] Re: building Julia could not allocate pools

Ok. I'll get to it ASAP. I also tried a completely fresh clone, and I get
the same error.

On Friday, February 27, 2015 at 3:59:52 PM UTC+1, Ivar Nesje wrote:

Thanks for reporting

The error seems to be coming from /src/gc.c#L482
https://github.com/JuliaLang/julia/blob/32aee08d0b833233cd22b7b1de01ae769395b3b8/src/gc.c#L482,

which was added in #8699 https://github.com/JuliaLang/julia/pull/8699 which
was merged 24 Ja
https://github.com/JuliaLang/julia/pull/8699#event-224146648n
https://github.com/JuliaLang/julia/pull/8699#event-224146648 (~30 days
ago)

As nobody else has reported this, someone will probably need more
information about your system in order to debug this properly, as it likely
is system dependent. Can you try to download any of the pre-buildt binaries
to see if they work?

Ivar

fredag 27. februar 2015 14.18.55 UTC+1 skrev lapeyre@gmail.com
følgende:

Anyone know something about this ?

I did not build the latest Julia (master branch) since about 30 days.
Now, when I do 'git pull' and 'make' I am getting various error messages:

could not allocate pools
Aborted
Makefile:165: recipe for target
'/home/jlapeyre/software_source/julia/usr/lib/julia/sys0.o' failed

This was a few days ago, so I 'pulled' every once in a while, hoping the
problem would go away.
I tried make clean, make cleanall, make distcleanall. Then dependencies
also fail to build
I removed even the packages with make -C deps distcleanall.

I have not changed my tool chain since the last successful build. I can't
recall, but there is a
chance (but, I think not) that I moved the entire repository from one
place to another.

Since I don't see any noise about this, something tells me its not a
common problem.

--John

Re: [julia-users] Re: ANN: Symbolic computation with Julia

Thanks for the info Ondrej and John.

On Friday, February 27, 2015 at 4:31:46 AM UTC+1, j verzani wrote:

 I think PyCall already has what you need for conversion:

 PyObject(big(pi)) will create a an mpf instance of a big float, like 
 big(pi)
 convert(BigFloat, PyObject(big(pi)))  will return a BigFloat from an mpf 
 instance.

[julia-users] Re: Julia users @ APS March Meeting?

What do you think about making a doodle or some web thingy  to arrange a 
time ?

On Monday, February 23, 2015 at 8:39:23 PM UTC+1, Jim Garrison wrote:

 The annual March Meeting of the American Physical Society is next week in 
 San Antonio, and I am wondering if any Julia users would be interested in 
 getting together there to chat for a bit.  I already know of 4-5 Julia 
 users attending, but surely there will be others I don't yet know of.  Let 
 me know if you'd be interested in joining us.

 Cheers,
 - Jim

Re: [julia-users] Re: ANN: Symbolic computation with Julia

2015-02-26 Thread lapeyre . math122a

(I am resending because, this my message to Ondřej did not go to the list)

Hi Ondřej,

The various sympy projects are very interesting, your work porting Rubi 
especially.

SJulia is using SymPy for a lot of features (Integrate, Solve, ...) . Here 
is some test code

 https://github.com/jlapeyre/SJulia/blob/master/test/sympy_test.jl

Francesco Bonazzi prompted me and started the code. From the little I've 
seen,
Sympy has impressive capabilities and the performance is good.

--John


On Thursday, February 26, 2015 at 4:30:04 AM UTC+1, Ondřej Čertík wrote:

 Hi John, 

 I just discovered this thread, some comments: 

 On Wed, Jan 28, 2015 at 9:53 AM,  lapeyre@gmail.com javascript: 
 wrote: 
  
  
  On Wednesday, January 28, 2015 at 10:20:08 AM UTC+1, Francesco Bonazzi 
  wrote: 
  
  
  
  On Tuesday, January 27, 2015 at 12:34:43 PM UTC+1, John Lapeyre wrote: 
  
   I read that the next version of Rubi will feature a decision tree, 
 no 
   longer pattern matching. 
  
  Interesting. I don't see it, do you have a link? 
  
  
  https://github.com/sympy/sympy/issues/7749#issuecomment-54830230 
  
  
 This looks great (at least based on the linked post) It no longer 
 relies 

 I wrote that post. I also created a PR with actual SymPy code here: 

 https://github.com/sympy/sympy/pull/8036 

 It seems to work great so far. I am waiting for more code from Albert 
 (I CCed him) and also I need to polish the PR some more. 

 I also tested Rubi using Mathematica, and it seems faster and more 
 robust (it can also do more integrals) than Mathematica's Integrate[] 
 function. Albert said that on his benchmarks, the if/then/else form is 
 massively faster than the pattern matching (maybe up to 100x on some 
 examples). 

  on the sophisticated part of the core Mma language, so it greatly 
 broadens 
  number of languages able to run Rubi. (Its only one now: Mma itself)  I 
  guess it's not too much trouble to emit sympy code. I'm pretty sure this 
  could be easily adapted to Maxima. In fact I wrote an Mma to Maxima 
  translator a while ago (Hmm I should put it on github) so it might work 
  immediately.  It uses RJF's  CL  Mma parser (uhh. too many acronyms). 
 The 
  translator can't handle Mma patterns (maybe just a liitle, I don't 
 remember) 
  My translator could translate and pass tests for a fair size quantum 
  information package. It also translated and correctly ran some symbolic 
  quantum mechanics code used in research that was written by a colleague. 
  But, it was unacceptably slow, because Maxima uses linked lists for 
  expressions, which require fundamentally different algorithms, not just 
  translation... I'm digressing. 
  
   I guess Albert Rich still maintains the data in some other form ? Or is 
 he 
  editing these big nested conditional statements ... 

 My understanding is that unfortunately he edits the nested conditional 
 statements. Apparently it is not easy to automatically translate the 
 pattern matching rules into a polished if/then/else form, though 
 ultimately it would be nice to have that. The if/then/else is nice, 
 that you can step through it easily via a debugger, and the only way 
 this might not finish is if the functions call each other recursively. 

 If you are interested in helping out with Rubi, please write to 
 Albert. He might really use some help with this, and lots of projects 
 would benefit. He maintains it in Mathematica, and then have automatic 
 translators to other codes, including Maxima and SymPy. 

  By the way, I was thinking about the syntax, what about instead of 
  
  @ex f(x_, y_Integer, z) := ... 
  
  Well, I kind of tried different things, including :: at one point. I 
  gradually moved away from a Julia extension to really another language: 
 I 
  just wanted the patterns, but they need support from expressions, but 
 that 
  requires a consistent evaluation sequence, etc. But, because I am 
 relying on 
  Julia's parser, the options are limited: the parser has to believe it's 
  valid Julia code (although it won't eval). So, if I disallow underscores 
 in 
  identifiers and interpret them instead as signifying patterns, I don't 
  consume any of the limited available Julia syntax. In Mma  you can have 
 one, 
  two, or three underscores before and/or after an identifier, each 
  combination of which means something different. All of that has to be 
  encoded in Julia syntax. By disallowing underscores, the whole problem 
 is 
  solved. I started to implement the Mma Condition, which is yet another 
  essential feature of the pattern matching. I tried :: for *that*, but it 
 has 
  high precedence, so you need to use parens, which I don't like. For now, 
 I 
  decided on just Condition(a,b). Furthermore, I stopped implementing 
  Condition because it is relatively easy to do. AC matching is a b$%h. 
  For 
  me, there's no sense in continuing the experiment unless I'm convinced 
 the 
  harder stuff can be done.  Of course if you, or

Re: [julia-users] Re: ANN: Symbolic computation with Julia

2015-02-26 Thread lapeyre . math122a

BTW.

Do you know much about the SymPy interface ? (or maybe the authors are 
reading this ?)
Francesco has already supplied a lot of information, but I am new to sympy.

Here, I ask for an integer to be converted with _to_mpmath

https://github.com/jlapeyre/SJulia/blob/master/src/sympy.jl#L89

And find that if the integer is actually a machine integer, then I get an 
Int64. So big
integers go to big integers and machine integers to machine integers.

Is there something similar I can do to get big float and machine floating 
point to map correctly
to Julia ?   I'm not sure how SymPy encodes  complex and rationals, but the 
code I have seems
to handle all of these correctly. 

On Thursday, February 26, 2015 at 4:30:04 AM UTC+1, Ondřej Čertík wrote:

 Hi John, 

 I just discovered this thread, some comments: 

 On Wed, Jan 28, 2015 at 9:53 AM,  lapeyre@gmail.com javascript: 
 wrote: 
  
  
  On Wednesday, January 28, 2015 at 10:20:08 AM UTC+1, Francesco Bonazzi 
  wrote: 
  
  
  
  On Tuesday, January 27, 2015 at 12:34:43 PM UTC+1, John Lapeyre wrote: 
  
   I read that the next version of Rubi will feature a decision tree, 
 no 
   longer pattern matching. 
  
  Interesting. I don't see it, do you have a link? 
  
  
  https://github.com/sympy/sympy/issues/7749#issuecomment-54830230 
  
  
 This looks great (at least based on the linked post) It no longer 
 relies 

 I wrote that post. I also created a PR with actual SymPy code here: 

 https://github.com/sympy/sympy/pull/8036 

 It seems to work great so far. I am waiting for more code from Albert 
 (I CCed him) and also I need to polish the PR some more. 

 I also tested Rubi using Mathematica, and it seems faster and more 
 robust (it can also do more integrals) than Mathematica's Integrate[] 
 function. Albert said that on his benchmarks, the if/then/else form is 
 massively faster than the pattern matching (maybe up to 100x on some 
 examples). 

  on the sophisticated part of the core Mma language, so it greatly 
 broadens 
  number of languages able to run Rubi. (Its only one now: Mma itself)  I 
  guess it's not too much trouble to emit sympy code. I'm pretty sure this 
  could be easily adapted to Maxima. In fact I wrote an Mma to Maxima 
  translator a while ago (Hmm I should put it on github) so it might work 
  immediately.  It uses RJF's  CL  Mma parser (uhh. too many acronyms). 
 The 
  translator can't handle Mma patterns (maybe just a liitle, I don't 
 remember) 
  My translator could translate and pass tests for a fair size quantum 
  information package. It also translated and correctly ran some symbolic 
  quantum mechanics code used in research that was written by a colleague. 
  But, it was unacceptably slow, because Maxima uses linked lists for 
  expressions, which require fundamentally different algorithms, not just 
  translation... I'm digressing. 
  
   I guess Albert Rich still maintains the data in some other form ? Or is 
 he 
  editing these big nested conditional statements ... 

 My understanding is that unfortunately he edits the nested conditional 
 statements. Apparently it is not easy to automatically translate the 
 pattern matching rules into a polished if/then/else form, though 
 ultimately it would be nice to have that. The if/then/else is nice, 
 that you can step through it easily via a debugger, and the only way 
 this might not finish is if the functions call each other recursively. 

 If you are interested in helping out with Rubi, please write to 
 Albert. He might really use some help with this, and lots of projects 
 would benefit. He maintains it in Mathematica, and then have automatic 
 translators to other codes, including Maxima and SymPy. 

  By the way, I was thinking about the syntax, what about instead of 
  
  @ex f(x_, y_Integer, z) := ... 
  
  Well, I kind of tried different things, including :: at one point. I 
  gradually moved away from a Julia extension to really another language: 
 I 
  just wanted the patterns, but they need support from expressions, but 
 that 
  requires a consistent evaluation sequence, etc. But, because I am 
 relying on 
  Julia's parser, the options are limited: the parser has to believe it's 
  valid Julia code (although it won't eval). So, if I disallow underscores 
 in 
  identifiers and interpret them instead as signifying patterns, I don't 
  consume any of the limited available Julia syntax. In Mma  you can have 
 one, 
  two, or three underscores before and/or after an identifier, each 
  combination of which means something different. All of that has to be 
  encoded in Julia syntax. By disallowing underscores, the whole problem 
 is 
  solved. I started to implement the Mma Condition, which is yet another 
  essential feature of the pattern matching. I tried :: for *that*, but it 
 has 
  high precedence, so you need to use parens, which I don't like. For now, 
 I 
  decided on just Condition(a,b). Furthermore, I stopped implementing 
  Condition

Re: [julia-users] Re: workflow for devloping large modules

I usually edit files and 'include' them, sometimes copy and paste. Thanks 
for posting the information on ESS.

Cheers, John

On Wednesday, February 25, 2015 at 1:04:09 PM UTC+1, Tamas Papp wrote:

 ESS _does_ support Julia at the moment: 

 1. editing Julia code works fine, even though the aforementioned commit 
 from Wilfred Hughes will improve it and will also make it easier to 
 follow improvements in julia-mode, 

 2. interacting with the REPL is functional, but does not support all the 
 extras I mentioned. But still, you lose nothing compared to manually 
 copy/pasting into a REPL (which I am assume is what you are doing), so I 
 would advise that you try ESS, even at its current state of Julia support. 

 Best, 

 Tamas 

 On Wed, Feb 25 2015, lapeyre@gmail.com javascript: wrote: 

  Great. I have not tried ESS yet, but definitely will when it supports 
  Julia.  I am not completely happy with emacs and julia-mode now. 
  julia-mode seems to insert a lot of trailing whitespace when 
  killing/yanking. And I can't 
  find a decent terminal mode/ shell buffer, unless I am running something 
  that doesn't even have readline. 
  
  --John 
  
  On Wednesday, February 25, 2015 at 12:44:48 AM UTC+1, 
 lapeyre@gmail.com 
  wrote: 
  
  I'm looking for a workflow, maybe someone can point me to a thread or 
  a document. 
  
  I was developing a large module without actually putting it in a 
  module. It is 7500 lines of code (counting every newline) and the 
  test suite is about 700 lines. I arranged things so the module loads 
  in about 2-3 seconds and the test suite runs the first time in about 
  20 seconds and subsequently in less than a second (or more if I reload 
  some code) I had to restart very rarely. So for the majority of 
  changes, I could reload one file and run the entire test suite in, 
  maybe 1 to 8 seconds, occasionally longer 
  
  Recently, I decided to depend on SymPy, which takes 20 seconds to 
  load. Now, starting from zero and running my module's test suite is 45 
  seconds. 
  
  I already have a single file MyModule.jl that includes all the other 
  code. So now I wrap all the 'includes' inside a 'module' block in 
  MyModule.jl.  Now my workflow is so slow that for practical purposes, 
  I can no longer work on the module. 
  
  When I am working on core code, for every change I make. I have to 
  restart and wait 45 seconds. 
  
  I spent a few hours, now, and in the past, reading threads on 
  workflows.  I tried a few things, but no luck. I didn't try all the 
  secret recipes. 
  
  I don't understand how people get around the need to reload the 
  entire module each time they make a change to it, and what the 
  potential problems from doing this are. My test suite 
  fails to run if I load the module twice. I spent some time trying 
  to understand why. Maybe finding this problem is the only solution? 
  
  Here are two possible solutions: 
  
  1. Fully qualify all identifiers in the module. Then, if I understand, 
  I can reload pieces of the code. 
  
  2. Break the code into several modules, polluting the namespace at 
  the module level

[julia-users] Re: workflow for devloping large modules

I found a solution. If something is wrong, please correct it in this thread.

-- To make a module, you must put code in a single module expression 
'module MyModule ... end'.
You may 'include' other files within this expression which has the 
effect of literally writing the contents
inside the module expression.
--  Once the module expression is executed, you cannot add functions (or 
other things, like global constants ?) 
to the module. If you again load code with a module expression naming 
the same module, it will overwrite
the original module. (you can have a submodule MyModule within 
MyModule. You will get a warning that
MyModule is being overwritten, but in fact it is not. But, this may 
have been fixed by now.)  So if you
change anything in a module, you must reload the entire module. But, 
this is not quite true. If a function
already exists from the previous module expression, you can redefine it 
by qualifying it with
'MyModule.funcname(...'.  In this function, you also have to qualify 
all types that were defined inside the
module, (and maybe other things ?)
--  Reloading the module may cause warnings to be printed at the repl. For 
instance, for me, methods that extend
 base functions cause 'new definition is ambiguous with' warnings, and 
'Method definition ... overwritten' warnings.
 I don't know the significance of these warnings. But you may have 
problems (see below). I don't know if they
 are related to the warnings printed at the repl.
--   After reloading the entire module, code, in particular test code, may 
fail with error messages printed. Restarting
 Julia, of course will fix this.
--   But, here is a solution that lets me edit a line in a module, reload 
it and run the tests relatively quickly:
 Run the test code. At the line number named in the error message, 
qualify calls to a macro with the name
 of the module, eg. 'MyModule.@mymacro'. Probably the same applies to 
function calls. You may need to
 qualify calls in some preceding lines, as well. Run the test suite 
again, and repeat the previous step. In the
 end, I am able to run the entire test suite with about 5 percent of 
the calls (every call in this test suite is to
 one of two macros) qualified.  If you understand the problem better, 
you may be able to predict which calls
 need to be qualified. Anyway, after doing this, my workflow is 
unstuck!  I read a lot of posts on how to deal
 with this problem. Fortunately, there is a line in a post by Tim Holy 
mentioning qualifying calls to module
 functions in test code. Thanks, Tim!
 
   -- John

Re: [julia-users] Re: workflow for devloping large modules

I guess you mean using the module's eval to add functions/variables ?  This 
sounds like an excellent
option.

I am using emacs/julia mode + konsole.

On Wednesday, February 25, 2015 at 11:39:31 AM UTC+1, Tamas Papp wrote:

 Hi John, 

 In fact you can eval into a module and thus add functions/variables 
 without reloading the whole thing. Juno supports this, I am working on 
 ESS to provide the same functionality. What IDE are you using? 

 Best, 

 Tamas 

 On Wed, Feb 25 2015, lapeyre@gmail.com javascript: wrote: 

  I found a solution. If something is wrong, please correct it in this 
 thread. 
  
  -- To make a module, you must put code in a single module expression 
  'module MyModule ... end'. 
  You may 'include' other files within this expression which has the 
  effect of literally writing the contents 
  inside the module expression. 
  --  Once the module expression is executed, you cannot add functions (or 
  other things, like global constants ?) 
  to the module. If you again load code with a module expression 
 naming 
  the same module, it will overwrite 
  the original module. (you can have a submodule MyModule within 
  MyModule. You will get a warning that 
  MyModule is being overwritten, but in fact it is not. But, this may 
  have been fixed by now.)  So if you 
  change anything in a module, you must reload the entire module. But, 
  this is not quite true. If a function 
  already exists from the previous module expression, you can redefine 
 it 
  by qualifying it with 
  'MyModule.funcname(...'.  In this function, you also have to qualify 
  all types that were defined inside the 
  module, (and maybe other things ?) 
  --  Reloading the module may cause warnings to be printed at the repl. 
 For 
  instance, for me, methods that extend 
   base functions cause 'new definition is ambiguous with' warnings, 
 and 
  'Method definition ... overwritten' warnings. 
   I don't know the significance of these warnings. But you may have 
  problems (see below). I don't know if they 
   are related to the warnings printed at the repl. 
  --   After reloading the entire module, code, in particular test code, 
 may 
  fail with error messages printed. Restarting 
   Julia, of course will fix this. 
  --   But, here is a solution that lets me edit a line in a module, 
 reload 
  it and run the tests relatively quickly: 
   Run the test code. At the line number named in the error message, 
  qualify calls to a macro with the name 
   of the module, eg. 'MyModule.@mymacro'. Probably the same applies 
 to 
  function calls. You may need to 
   qualify calls in some preceding lines, as well. Run the test suite 
  again, and repeat the previous step. In the 
   end, I am able to run the entire test suite with about 5 percent of 
  the calls (every call in this test suite is to 
   one of two macros) qualified.  If you understand the problem 
 better, 
  you may be able to predict which calls 
   need to be qualified. Anyway, after doing this, my workflow is 
  unstuck!  I read a lot of posts on how to deal 
   with this problem. Fortunately, there is a line in a post by Tim 
 Holy 
  mentioning qualifying calls to module 
   functions in test code. Thanks, Tim! 
  
 -- John

[julia-users] Re: workflow for devloping large modules

Great. I have not tried ESS yet, but definitely will when it supports 
Julia.  I am not completely happy with emacs and julia-mode now.
julia-mode seems to insert a lot of trailing whitespace when 
killing/yanking. And I can't
find a decent terminal mode/ shell buffer, unless I am running something 
that doesn't even have readline.

--John

On Wednesday, February 25, 2015 at 12:44:48 AM UTC+1, lapeyre@gmail.com 
wrote:

 I'm looking for a workflow, maybe someone can point me to a thread or
 a document.

 I was developing a large module without actually putting it in a
 module. It is 7500 lines of code (counting every newline) and the
 test suite is about 700 lines. I arranged things so the module loads
 in about 2-3 seconds and the test suite runs the first time in about
 20 seconds and subsequently in less than a second (or more if I reload
 some code) I had to restart very rarely. So for the majority of
 changes, I could reload one file and run the entire test suite in,
 maybe 1 to 8 seconds, occasionally longer

 Recently, I decided to depend on SymPy, which takes 20 seconds to
 load. Now, starting from zero and running my module's test suite is 45 
 seconds.

 I already have a single file MyModule.jl that includes all the other
 code. So now I wrap all the 'includes' inside a 'module' block in
 MyModule.jl.  Now my workflow is so slow that for practical purposes,
 I can no longer work on the module.

 When I am working on core code, for every change I make. I have to
 restart and wait 45 seconds.

 I spent a few hours, now, and in the past, reading threads on
 workflows.  I tried a few things, but no luck. I didn't try all the
 secret recipes.

 I don't understand how people get around the need to reload the
 entire module each time they make a change to it, and what the
 potential problems from doing this are. My test suite
 fails to run if I load the module twice. I spent some time trying
 to understand why. Maybe finding this problem is the only solution?

 Here are two possible solutions:

 1. Fully qualify all identifiers in the module. Then, if I understand,
 I can reload pieces of the code.

 2. Break the code into several modules, polluting the namespace at
 the module level

[julia-users] workflow for devloping large modules

2015-02-24 Thread lapeyre . math122a

I'm looking for a workflow, maybe someone can point me to a thread or
a document.

I was developing a large module without actually putting it in a
module. It is 7500 lines of code (counting every newline) and the
test suite is about 700 lines. I arranged things so the module loads
in about 2-3 seconds and the test suite runs the first time in about
20 seconds and subsequently in less than a second (or more if I reload
some code) I had to restart very rarely. So for the majority of
changes, I could reload one file and run the entire test suite in,
maybe 1 to 8 seconds, occasionally longer

Recently, I decided to depend on SymPy, which takes 20 seconds to
load. Now, starting from zero and running my module's test suite is 45 
seconds.

I already have a single file MyModule.jl that includes all the other
code. So now I wrap all the 'includes' inside a 'module' block in
MyModule.jl.  Now my workflow is so slow that for practical purposes,
I can no longer work on the module.

When I am working on core code, for every change I make. I have to
restart and wait 45 seconds.

I spent a few hours, now, and in the past, reading threads on
workflows.  I tried a few things, but no luck. I didn't try all the
secret recipes.

I don't understand how people get around the need to reload the
entire module each time they make a change to it, and what the
potential problems from doing this are. My test suite
fails to run if I load the module twice. I spent some time trying
to understand why. Maybe finding this problem is the only solution?

Here are two possible solutions:

1. Fully qualify all identifiers in the module. Then, if I understand,
I can reload pieces of the code.

2. Break the code into several modules, polluting the namespace at
the module level

[julia-users] Re: Julia users @ APS March Meeting?

2015-02-23 Thread lapeyre . math122a

I'm interested.

On Monday, February 23, 2015 at 8:39:23 PM UTC+1, Jim Garrison wrote:

 The annual March Meeting of the American Physical Society is next week in 
 San Antonio, and I am wondering if any Julia users would be interested in 
 getting together there to chat for a bit.  I already know of 4-5 Julia 
 users attending, but surely there will be others I don't yet know of.  Let 
 me know if you'd be interested in joining us.

 Cheers,
 - Jim

[julia-users] Loading code from base without building Julia

2015-02-22 Thread lapeyre . math122a

Hi,

Is it possible to copy code from the base directory, modify it, and reload 
it ? I suppose this depends on exactly what you want to do. I have modified 
REPL.jl. At present, the only way I know how to use this is to build Julia. 
There is the added complication that the modified version would have to be 
loaded before the REPL is initialized. With some smaller bits of code from 
other files, I can get what I want by qualifying the names and maybe 
'using' some modules (IIRC). But, the modifications to REPL are not well 
localized.

If I just do
include(REPL.jl)
the first error, I get is UndefVarError: Terminals not defined

The reason I want to do this is to make the symbolic Julia code easier to 
use. At present, you either wrap every line in a macro, or download and 
build Julia, with the only modification being in REPL.jl.

--John

[julia-users] symbolic computation in Julia (again)

2015-02-21 Thread lapeyre . math122a

Hi,

Here is more on the experiment in symbolic computation. Some results and 
timing are given in the README.

https://github.com/jlapeyre/SJulia

The focus is still on a Mathematica-like language, although I think it's 
possible and desirable to write routines with an interface so that they can 
be used in a different way.

The results are encouraging. Many things are relatively fast compared to 
other software. (I consider half as fast as Mathematica 3 in many cases to 
be very fast) Despite the large number of functions, a coherent language to 
build on is not there yet. There is a language and you can write functions 
easily, but it needs a lot of work.

The main thing  I have been looking at recently is allocation, which is 
relatively slow (compared to Mathematica and Maxima, not to python 
projects).  This shows up in particular when creating a large number of 
small expressions.  I don't know how Mathematica does it, but in Maxima 
creating an expression is it is little more than creating a a few cons 
cells. In SJulia each expression has a Dict containing the unbound 
variables that appear in it. This slows down creating an empty expression 
by somewhat less than a factor of two. But, even eliminating this, 
allocation is a bit slow. Allocation is not always a big factor in 
performance. For many reasonable tasks, SJulia is faster (sometimes much 
faster) than Maxima and sometimes as fast as Mathematica 3. (18 years old, 
but a milestone for Mma after about 10 years as a commercial product.)

To reiterate (I think I said this), I think there is a big need for 
something like this code, and Julia is by far the best choice for 
implementing it. Maxima is perhaps the closest open source project. But, it 
has many problems, for instance the CL ecosystem (compared to Julia, this 
is a really big deal), and a heterogeneous, very old code base.

I was never convinced that the Sage model would be useful. I'm not sure 
about Python in general, but I think many of the arguments for Julia 
compared to python apply. Eg, Implementing Mma-like expressions using a 
hierarchy of types seems difficult. Also, there is far more overlap between 
SJulia (Mma-like) needs and Julia, than python (and certainly CL). Mathics, 
as the developers admit, is very slow. It may have some good ideas (but the 
code is GPL).  I don't have enough experience to compare SJulia well with 
SymPy.  SymPy is 100 times slower with the one task I benchmarked. But, 
there are so many unknowns, that I can't draw any conclusions yet.

--John

[julia-users] Re: symbolic computation in Julia (again)

2015-02-21 Thread lapeyre . math122a


Regarding python and SymPy: I meant to say implementing Mma-like 
expressions via a hierarchy of *classes*,  not types

[julia-users] Re: Levi-Civita symbol/tensor

2015-02-16 Thread lapeyre . math122a

Maybe its too late, but here is a fast implementation giving the signature 
of the output of randperm(n)

https://github.com/jlapeyre/PermPlain.jl/blob/master/src/PermPlain.jl#L271


On Monday, February 9, 2015 at 8:41:58 PM UTC+1, Blake Johnson wrote:

 I keep writing code that needs the Levi-Civita symbol, i.e.:

 \epsilon_{ijk} = { 1 if (i,j,k) is an even permutation, -1 if (i,j,k) is 
 an odd permutation, otherwise 0 }

 It is used frequently in physics, so I keep expecting it to be in Julia's 
 stdlib, perhaps under a different name (in Mathematica, it is called 
 Signature[]). But, if it is there, I haven't found it yet. Is it there 
 and I just can't find it?

[julia-users] Re: Levi-Civita symbol/tensor

2015-02-16 Thread lapeyre . math122a

I should note that a couple of routines in PermPlain are not MIT license 
compatible.  But all the code to compute
the signature of a permutation most definitely is MIT compatible. I wrote 
it, although the algorithm is well known.

There is also this code which calls PermPlain:
https://github.com/jlapeyre/PermutationsA.jl

On Monday, February 16, 2015 at 4:12:10 PM UTC+1, lapeyre@gmail.com 
wrote:

 Maybe its too late, but here is a fast implementation giving the signature 
 of the output of randperm(n)

 https://github.com/jlapeyre/PermPlain.jl/blob/master/src/PermPlain.jl#L271


 On Monday, February 9, 2015 at 8:41:58 PM UTC+1, Blake Johnson wrote:

 I keep writing code that needs the Levi-Civita symbol, i.e.:

 \epsilon_{ijk} = { 1 if (i,j,k) is an even permutation, -1 if (i,j,k) is 
 an odd permutation, otherwise 0 }

 It is used frequently in physics, so I keep expecting it to be in Julia's 
 stdlib, perhaps under a different name (in Mathematica, it is called 
 Signature[]). But, if it is there, I haven't found it yet. Is it there 
 and I just can't find it?

Re: [julia-users] Re: ANN: Symbolic computation with Julia

2015-01-28 Thread lapeyre . math122a


Francesco, I just realized that Mathics is actually aiming to implement the 
Mma language. For some reason I thought it was only using the same syntax. 
So, this is indeed similar to what I am trying to do. Except that I 
consider the code that I have now to be an experiment.

On Wednesday, January 28, 2015 at 10:20:08 AM UTC+1, Francesco Bonazzi 
wrote:



 On Tuesday, January 27, 2015 at 12:34:43 PM UTC+1, John Lapeyre wrote:

   I read that the next version of Rubi will feature a decision tree, no 
 longer pattern matching.

 Interesting. I don't see it, do you have a link? 


 https://github.com/sympy/sympy/issues/7749#issuecomment-54830230 

 By the way, I was thinking about the syntax, what about instead of

 @ex f(x_, y_Integer, z) := ...

 to use a more Julia-friendly one like

 @ex f(x, y::Integer, :z) := ...

 This does not need any string processing for underscore signs, colon 
 prepended to the symbol (e.g. :z) to mark that *z* is not a wildcard 
 pattern.

 Anyways, it looks like on your patterns you are implicitly introducing an 
 Mxpr - type correspondence, i.e. if in *x_A* the expression *A* were 
 considered both as the head of an Mxpr and as a Julia type.

 Any thoughts about interpolation of Julia variables in the *@ex* macro? I 
 tried to call *a=3; @ex f($a)* but it doesn't work.

Re: [julia-users] Re: ANN: Symbolic computation with Julia

2015-01-26 Thread lapeyre . math122a



On Monday, January 26, 2015 at 7:20:54 PM UTC+1, Francesco Bonazzi wrote:




 A Mathematica parser could be used as an optional addition, such as what 
 Mathics is to SymPy.

 Anyways, there are various options for Julia:

- use Expr and operate on them, this is similar to how Maxima works.


One experiment in the code I posted does this. And the main code does 
essentially the same thing, but it is not an Expr, but a Mxpr that
carries some additional fields.

 declare symbolic types and use operator overloading: this is the approach 
by SymPy and Axiom.


This is interesting and has advantages, but is not what I am looking for, 
at least not now. I  suppose hybridizing etc. is possible


  create a DSL invoked by a macro, this appears to be the case for SJulia

Yes, the macro is just a way to allow more syntax than nested expressions. 
And this is really the same as your first item, as well.

Using the macro is much easier than writing or modifying a parser.

I expect that at some point,  all of these options will be tried with Julia.

[julia-users] Re: ANN: Symbolic computation with Julia

2015-01-26 Thread lapeyre . math122a

Hello Jim,
Thanks for the long response. I looked at the papers; I think they are 
worth studying. I found that I can progress most quickly modeling on 
Mathematica. The design is fairly simple and consistent. Of course the 
documentation is vague in some places, but so far, it is not a problem. Of 
course, even if you know logically what the rules should do, there is still 
the matter of building data structures and applying them.  I am more 
concerned now in getting correct logical behavior than efficient 
application of rules. I want to see a cohesive system. A lot of risk is 
reduced, because we know Mathematica works. But, it is good to develop 
ideas about efficient implementation at the same time, and there is no 
avoiding it when doing commutative matching.

I installed sympy, but have not played with it yet, but I definitely will. 
I've looked just a bit at the code. If you have any experience optimizing 
pattern matching, or other resources, I'd like to hear about it.

Another resource is Richard Fateman's  mma4max 
http://www.cs.berkeley.edu/~fateman/lisp/mma4max/, which I see has 
updates since I last built it. It aims more or less to implement mma in 
common lisp. In fact it has a Julia-compatible license and a complete 
parser written in common lisp. IIRC the comments show that the pattern 
matcher is not perfect, but I think it is complete.

--John
On Monday, January 26, 2015 at 3:07:22 AM UTC+1, lapeyre@gmail.com 
wrote:

 Hi,

 Here is some code I have been working on. It is for symbolic computation 
 based on pattern matching.
 If you find it interesting, any feedback is welcome!

 https://github.com/jlapeyre/SJulia

 --John

Re: [julia-users] Re: ANN: Symbolic computation with Julia

2015-01-26 Thread lapeyre . math122a


(My posts are not appearing where I want. Hope this one does!)

On Monday, January 26, 2015 at 6:57:48 PM UTC+1, James Crist wrote:

 Maybe the parser could be useful if rewritten in Julia:


 Side tracking a bit, but one of the reasons I use SymPy instead of 
 something like Maxima is that it meshes seamlessly into the language 
 infrastructure. By writing a parser and creating another system means that 
 it can't use julia's ecosystem without modification. I'd rather see a CAS 
 work within Julia's parser framework. But that's just me.


Yes, I played with both ideas. I think what I am looking for is a 
fundamentally different language from Julia. I can't see a way to make it 
an extension of Julia in the way that a normal package is. Although it may 
be possible to use it from within Julia in a convenient way. Writing 
classes to handle mathematical structures is more efficient in memory and 
runtime, but is less flexible than expressions.

 

 I am more concerned now in getting correct logical behavior than efficient 
 application of rules.


 Making it just *work* is certainly a priority, but design decisions made 
 now can make things tricky later on. Especially with the design of your 
 internal representation. How you represent expression trees and assumptions 
 can seriously affect the performance of matching/traversals/replacements. 


I agree. But, the right decision is not always clear to me. So I am 
interested in the representation, not performance, because there is a good 
chance that parts will be thrown away.  I am fairly certain that I want to 
represent expressions in a way similar to a Julia, Mathematica, Maxima, or 
Lisp expression (arrays of pointers vs. linked list is another matter). 
Mathematica rules and patterns are also represented this way. Of course, I 
am sure they are used at some point to build data structures composed of 
types in some language. But, logically, and at the language level, 
everything is an expression.


 

 On Mon, Jan 26, 2015 at 11:47 AM, Francesco Bonazzi franz@gmail.com 
 javascript: wrote:



 On Monday, January 26, 2015 at 6:11:33 PM UTC+1, lapeyre@gmail.com 
 wrote:


 Another resource is Richard Fateman's  mma4max 
 http://www.cs.berkeley.edu/~fateman/lisp/mma4max/, which I see has 
 updates since I last built it. It aims more or less to implement mma in 
 common lisp. In fact it has a Julia-compatible license and a complete 
 parser written in common lisp. IIRC the comments show that the pattern 
 matcher is not perfect, but I think it is complete.


 Maybe the parser could be useful if rewritten in Julia:
 http://www.cs.berkeley.edu/~fateman/lisp/mma4max/parser.lisp

[julia-users] ANN: Symbolic computation with Julia

2015-01-25 Thread lapeyre . math122a

Hi,

Here is some code I have been working on. It is for symbolic computation 
based on pattern matching.
If you find it interesting, any feedback is welcome!

https://github.com/jlapeyre/SJulia

--John

[julia-users] Does TypeCheck specify which methods failed ?

2015-01-08 Thread lapeyre . math122a

I see this when I use TypeCheck:

 checkreturntypes(ModuleName)
blah blah
The total number of failed methods in ModuleName is 2

But I can't see which methods failed. Am I missing something ?

--John

[julia-users] Re: Notice about coverage results

2015-01-07 Thread lapeyre . math122a

Is there already a bug report for this ?

(Linux)
$ julia --version
julia version 0.3.5-pre+121
$ julia --code-coverage
Segmentation fault

This version of julia was giving the same segfault. But, now mysteriously 
is not.

$ julia-0.4 --version
julia version 0.4.0-dev+2470

On Wednesday, January 7, 2015 12:19:23 AM UTC+1, Tim Holy wrote:

 To package authors  users: 

 Those of you who are using Coverage  Coveralls should be prepared for 
 some 
 large changes to your coverage statistics. Until now, the mechanisms we've 
 been using to count coverage percentage were pretty badly broken; while 
 we're 
 still far from perfect, some recent changes in the Coverage package appear 
 to 
 have made those measurements considerably more accurate. In most cases, 
 you'll 
 see your coverage percentages drop, in some cases by a large amount. Those 
 changes to Coverage were just merged and tagged, so the next time you push 
 a 
 commit, your numbers may plummet. Unless, of course, you're simply awesome 
 about writing tests, or plan to become so :-). 

 References: 
 https://groups.google.com/d/msg/julia-dev/NFVvSQvd-Dk/Nyr8IXGQaTIJ 
 How to use Coverage to measure your coverage percentage, and find those 
 functions in your package that need testing: 
 https://github.com/IainNZ/Coverage.jl 

 Best, 
 --Tim

[julia-users] Julia vs C++-11 for random walks

Hi, here is a comparison of Julia and C++ for simulating a random walk 
https://github.com/jlapeyre/ranwalk-Julia-vs-Cxx.

It is the first Julia program I wrote. I just pushed it to github.

--John

Re: [julia-users] Re: Julia vs C++-11 for random walks

 It may be in part the implementation of the RNG. I think it is also in 
part whether the abstraction is optimized away.
Notice that Julia v0.3 is faster than v0.4. This is probably randbool() vs. 
rand(Bool).

On Monday, January 5, 2015 4:50:56 PM UTC+1, Isaiah wrote:

 Very neat. Just in case this gets posted to the interwebz, it is worth 
 pointing out that the performance advantage for Julia can probably be 
 explained by differences in the underlying RNG. We use dsFMT, which is 
 known to be one of (if not the?) fastest MT libraries around. I could not 
 find any published comparisons in a quick google, but based on this test 
 harness [1], dsFMT may be significantly faster than std::mt19937:

 ```
 ihnorton@julia:~/tmp/cpp-random-test$ ./random-real
 C++11 : 2.34846
 Boost : 0.371674
 dSFMT : 0.281255
 GSL   : 0.649981
 ```

 [1] https://github.com/yomichi/cpp-random-test


 On Mon, Jan 5, 2015 at 10:12 AM, lapeyre@gmail.com javascript: 
 wrote:

 Oh, and, (I forgot to mention!)  the Julia code runs much faster.


 On Monday, January 5, 2015 3:56:07 PM UTC+1, lapeyre@gmail.com wrote:

 Hi, here is a comparison of Julia and C++ for simulating a random walk 
 https://github.com/jlapeyre/ranwalk-Julia-vs-Cxx.

 It is the first Julia program I wrote. I just pushed it to github.

 --John

Re: [julia-users] Re: Julia vs C++-11 for random walks

I meant randbool() in v0.3, where it was a more direct call, not randbool() 
in v0.4.
Anyway, I just found the problem and patched it. Adding one '@inline' now 
makes rand(Bool) in v0.4
about as fast as randbool() in v0.3.

Should I open an issue (bug report), or just make a PR ? 

On Monday, January 5, 2015 8:59:02 PM UTC+1, Viral Shah wrote:

 I doubt that rand(Bool) is any slower, since randbool() calls rand(Bool). 
 It is worth filing this as a performance regression.

 -viral

 On Monday, January 5, 2015 9:41:45 PM UTC+5:30, lapeyre@gmail.com 
 wrote:

  It may be in part the implementation of the RNG. I think it is also in 
 part whether the abstraction is optimized away.
 Notice that Julia v0.3 is faster than v0.4. This is probably randbool() 
 vs. rand(Bool).

 On Monday, January 5, 2015 4:50:56 PM UTC+1, Isaiah wrote:

 Very neat. Just in case this gets posted to the interwebz, it is worth 
 pointing out that the performance advantage for Julia can probably be 
 explained by differences in the underlying RNG. We use dsFMT, which is 
 known to be one of (if not the?) fastest MT libraries around. I could not 
 find any published comparisons in a quick google, but based on this test 
 harness [1], dsFMT may be significantly faster than std::mt19937:

 ```
 ihnorton@julia:~/tmp/cpp-random-test$ ./random-real
 C++11 : 2.34846
 Boost : 0.371674
 dSFMT : 0.281255
 GSL   : 0.649981
 ```

 [1] https://github.com/yomichi/cpp-random-test


 On Mon, Jan 5, 2015 at 10:12 AM, lapeyre@gmail.com wrote:

 Oh, and, (I forgot to mention!)  the Julia code runs much faster.


 On Monday, January 5, 2015 3:56:07 PM UTC+1, lapeyre@gmail.com 
 wrote:

 Hi, here is a comparison of Julia and C++ for simulating a random walk 
 https://github.com/jlapeyre/ranwalk-Julia-vs-Cxx.

 It is the first Julia program I wrote. I just pushed it to github.

 --John

[julia-users] Re: Julia vs C++-11 for random walks

Oh, and, (I forgot to mention!)  the Julia code runs much faster.

On Monday, January 5, 2015 3:56:07 PM UTC+1, lapeyre@gmail.com wrote:

 Hi, here is a comparison of Julia and C++ for simulating a random walk 
 https://github.com/jlapeyre/ranwalk-Julia-vs-Cxx.

 It is the first Julia program I wrote. I just pushed it to github.

 --John

Re: [julia-users] Re: Julia vs C++-11 for random walks

Ok. It's done.  Just to be sure I understood what I read on a github forum; 
there is no way for me to attach a label to the PR. So the labels are 
always added by someone else ?

--John

On Monday, January 5, 2015 9:25:18 PM UTC+1, Viral Shah wrote:

 Thanks. Do create a PR. 

 -viral 



  On 06-Jan-2015, at 1:53 am, lapeyre@gmail.com javascript: wrote: 
  
  I meant randbool() in v0.3, where it was a more direct call, not 
 randbool() in v0.4. 
  Anyway, I just found the problem and patched it. Adding one '@inline' 
 now makes rand(Bool) in v0.4 
  about as fast as randbool() in v0.3. 
  
  Should I open an issue (bug report), or just make a PR ? 
  
  On Monday, January 5, 2015 8:59:02 PM UTC+1, Viral Shah wrote: 
  I doubt that rand(Bool) is any slower, since randbool() calls 
 rand(Bool). It is worth filing this as a performance regression. 
  
  -viral 
  
  On Monday, January 5, 2015 9:41:45 PM UTC+5:30, lapeyre@gmail.com 
 wrote: 
   It may be in part the implementation of the RNG. I think it is also in 
 part whether the abstraction is optimized away. 
  Notice that Julia v0.3 is faster than v0.4. This is probably randbool() 
 vs. rand(Bool). 
  
  On Monday, January 5, 2015 4:50:56 PM UTC+1, Isaiah wrote: 
  Very neat. Just in case this gets posted to the interwebz, it is worth 
 pointing out that the performance advantage for Julia can probably be 
 explained by differences in the underlying RNG. We use dsFMT, which is 
 known to be one of (if not the?) fastest MT libraries around. I could not 
 find any published comparisons in a quick google, but based on this test 
 harness [1], dsFMT may be significantly faster than std::mt19937: 
  
  ``` 
  ihnorton@julia:~/tmp/cpp-random-test$ ./random-real 
  C++11 : 2.34846 
  Boost : 0.371674 
  dSFMT : 0.281255 
  GSL   : 0.649981 
  ``` 
  
  [1] https://github.com/yomichi/cpp-random-test 
  
  
  On Mon, Jan 5, 2015 at 10:12 AM, lapeyre@gmail.com wrote: 
  Oh, and, (I forgot to mention!)  the Julia code runs much faster. 
  
  
  On Monday, January 5, 2015 3:56:07 PM UTC+1, lapeyre@gmail.com 
 wrote: 
  Hi, here is a comparison of Julia and C++ for simulating a random walk. 
  
  It is the first Julia program I wrote. I just pushed it to github. 
  
  --John

Re: [julia-users] Julia vs C++-11 for random walks

Good. This is fine with me.Thanks.
--John


On Monday, January 5, 2015 9:52:58 PM UTC+1, Viral Shah wrote:

 I believe the labels can only be attached by those who have read/write 
 access. 

 -viral 



  On 06-Jan-2015, at 2:20 am, lapeyre@gmail.com javascript: wrote: 
  
  Ok. It's done.  Just to be sure I understood what I read on a github 
 forum; there is no way for me to attach a label to the PR. So the labels 
 are always added by someone else ? 
  
  --John 
  
  On Monday, January 5, 2015 9:25:18 PM UTC+1, Viral Shah wrote: 
  Thanks. Do create a PR. 
  
  -viral 
  
  
  
   On 06-Jan-2015, at 1:53 am, lapeyre@gmail.com wrote: 
   
   I meant randbool() in v0.3, where it was a more direct call, not 
 randbool() in v0.4. 
   Anyway, I just found the problem and patched it. Adding one '@inline' 
 now makes rand(Bool) in v0.4 
   about as fast as randbool() in v0.3. 
   
   Should I open an issue (bug report), or just make a PR ? 
   
   On Monday, January 5, 2015 8:59:02 PM UTC+1, Viral Shah wrote: 
   I doubt that rand(Bool) is any slower, since randbool() calls 
 rand(Bool). It is worth filing this as a performance regression. 
   
   -viral 
   
   On Monday, January 5, 2015 9:41:45 PM UTC+5:30, lapeyre@gmail.com 
 wrote: 
It may be in part the implementation of the RNG. I think it is also 
 in part whether the abstraction is optimized away. 
   Notice that Julia v0.3 is faster than v0.4. This is probably 
 randbool() vs. rand(Bool). 
   
   On Monday, January 5, 2015 4:50:56 PM UTC+1, Isaiah wrote: 
   Very neat. Just in case this gets posted to the interwebz, it is worth 
 pointing out that the performance advantage for Julia can probably be 
 explained by differences in the underlying RNG. We use dsFMT, which is 
 known to be one of (if not the?) fastest MT libraries around. I could not 
 find any published comparisons in a quick google, but based on this test 
 harness [1], dsFMT may be significantly faster than std::mt19937: 
   
   ``` 
   ihnorton@julia:~/tmp/cpp-random-test$ ./random-real 
   C++11 : 2.34846 
   Boost : 0.371674 
   dSFMT : 0.281255 
   GSL   : 0.649981 
   ``` 
   
   [1] https://github.com/yomichi/cpp-random-test 
   
   
   On Mon, Jan 5, 2015 at 10:12 AM, lapeyre@gmail.com wrote: 
   Oh, and, (I forgot to mention!)  the Julia code runs much faster. 
   
   
   On Monday, January 5, 2015 3:56:07 PM UTC+1, lapeyre@gmail.com 
 wrote: 
   Hi, here is a comparison of Julia and C++ for simulating a random 
 walk. 
   
   It is the first Julia program I wrote. I just pushed it to github. 
   
   --John

[julia-users] Re: Constructing Expr from s-expressions

2015-01-04 Thread lapeyre . math122a

Not sure, but maybe this is what you are looking for,

https://gist.github.com/toivoh/4121122

On Sunday, January 4, 2015 6:49:39 AM UTC+1, Darwin Darakananda wrote:

 Hi everyone,

 Is there currently a function that converts s-expressions into Expr 
 structures (basically the reverse of Base.Meta.show_sexpr)?

 I just started playing around with metaprogramming in Julia, so I'm 
 probably doing things wrong.  But there are a lot of times where I end up 
 creating highly nested Expr objects, ending up with code that is 
 indecipherable.  I've found that the output from show_sexpr is sometimes 
 easier to read that that of dump or xdump (which only seems to display the 
 first couple of levels).  So I'm curious to see if the reverse 
 (s-expression - Expr) is also true.  

 If this function does not exist, would it be something that people would 
 find useful?

 Thanks and Happy New Years!

 Darwin

[julia-users] Re: Julia takes 2nd place in Delacorte Numbers competition

2015-01-04 Thread lapeyre . math122a

Congratulations! Awesome. Don't know if this is Arch D or Arch S. The 
scores look even closer than
track and field 
http://www.blonzonics.us/home/robison-family/2014_4x800_relay_team times.

On Sunday, January 4, 2015 6:35:46 PM UTC+1, Arch Robison wrote:

 FYI, I won 2nd place in the recent Al Zimmerman programming contest 
 Delacorte 
 Numbers http://trdb.org/Contest/DelacorteNumbers/Standings, using only 
 Julia and a quad-core MonkeyStation Pro 
 http://www.blonzonics.us/odd/monkeystation-pro.   Julia worked out well 
 because it had:

- interactivity to study the problem
- quick prototyping to try ideas
- fast scalar code
- fast SIMD loops 

 I've working on a paper that will describe the experience in more detail.

 - Arch

[julia-users] Re: bug in jacobisymbol Combinatorics.jl

2015-01-03 Thread lapeyre . math122a

Changing the line that calls libgmp like this ( Int is replaced with Int32 )
   
 return convert(Int,ccall((:__gmpz_jacobi, :libgmp), Int32,

gives correct results. The C header and code says the return type is 'int'.
All values that should be -1, come out 4294967295.  This may be system
dependent, but I only have one laptop available at the moment.


On Saturday, January 3, 2015 6:44:40 PM UTC+1, lapeyre@gmail.com wrote:

 This is not correct

 julia jacobisymbol(10,7)
 4294967295

 This happens in v0.3 and v0.4
 I can send more information, and have a possible fix. I tried to find a 
 way to make a comment or issue or something at
 https://github.com/jiahao/Combinatorics.jl,
 but was unable to find a button for it.  Better to talk before issuing a 
 PR.

 --John

[julia-users] bug in jacobisymbol Combinatorics.jl

2015-01-03 Thread lapeyre . math122a

This is not correct

julia jacobisymbol(10,7)
4294967295

This happens in v0.3 and v0.4
I can send more information, and have a possible fix. I tried to find a way 
to make a comment or issue or something at
https://github.com/jiahao/Combinatorics.jl,
but was unable to find a button for it.  Better to talk before issuing a PR.

--John

Re: [julia-users] Re: bug in jacobisymbol Combinatorics.jl

2015-01-03 Thread lapeyre . math122a

Great,  thanks. Cint make more sense. Also, the same change needs to be 
made for
 legendresymbol.


On Saturday, January 3, 2015 7:11:19 PM UTC+1, Jiahao Chen wrote:

 Thanks for the report and the fix.

 I've updated the code and strengthened the test; the only change was to 
 use Cint instead of Int32 for consistency with our C calling code:


 http://docs.julialang.org/en/release-0.3/manual/calling-c-and-fortran-code/#type-correspondences

 I've also enabled the issue tracker; didn't realize it was off.

 On Sat Jan 03 2015 at 12:52:41 PM lapeyre@gmail.com javascript: 
 wrote:

 Changing the line that calls libgmp like this ( Int is replaced with 
 Int32 )

  return convert(Int,ccall((:__gmpz_jacobi, :libgmp), Int32,

 gives correct results. The C header and code says the return type is 
 'int'.
 All values that should be -1, come out 4294967295.  This may be system
 dependent, but I only have one laptop available at the moment.



 On Saturday, January 3, 2015 6:44:40 PM UTC+1, lapeyre@gmail.com 
 wrote:

 This is not correct

 julia jacobisymbol(10,7)
 4294967295

 This happens in v0.3 and v0.4
 I can send more information, and have a possible fix. I tried to find a 
 way to make a comment or issue or something at
 https://github.com/jiahao/Combinatorics.jl,
 but was unable to find a button for it.  Better to talk before issuing a 
 PR.

 --John

Re: [julia-users] Static type fields

2015-01-02 Thread lapeyre . math122a

I guess that many people coming from a common OO language will look for 
this and it seems natural to look in the
manual in the sections 'Types' or 'Methods'.  Maybe somewhere near the 
discussion of fields in
 Composite Types 
http://julia.readthedocs.org/en/latest/manual/types/#composite-types.  It 
looks like before Immutable Composite Types 
http://julia.readthedocs.org/en/latest/manual/types/#immutable-composite-types
 
would be good. For instance: (with existing surrounding text)

 You can also change the values as one would expect:
blah
blah

You can associate static data with a type like this:
   static_data(::Type{MyObj}) = 1
   static_data(::Type{MyOtherObj}) = 2

Composite types with no fields are singletons 


On Thursday, January 1, 2015 8:34:48 AM UTC+1, ele...@gmail.com wrote:



 On Thursday, January 1, 2015 11:45:00 AM UTC+10, Jameson wrote:

 method dispatch on the object type does a remarkably good job at 
 providing this functionality without needing a specialized feature:

 static_data(::Type{MyObj}) = 1
 static_data(::Type{MyOtherObj}) = 2


 Would like to document this, but not sure where it should go?
  



 On Wed Dec 31 2014 at 8:23:40 PM Josh Langsfeld jdl...@gmail.com wrote:

 I currently am trying to solve a problem where I have many composite 
 types and I would like to associate some data with each type, such that 
 every instance has access to it. Obviously, in C++ I would just create a 
 static member variable. 

 Is there a good way to go about this in Julia? Currently, I have it 
 working by using a global Dict mapping DataType objects to their associated 
 data but I really don't like this. Something more naive like just adding 
 that field to every object instance also strikes me as unnecessary and 
 wasteful. I haven't seen any significant discussion about static fields on 
 the lists or on github so is this something that could be considered for 
 addition to the language?

 Thanks,
 Josh

[julia-users] Re: Static type fields

2015-01-02 Thread lapeyre . math122a

And more generally, sections for C++ and java in Noteworthy Differences 
http://julia.readthedocs.org/en/latest/manual/noteworthy-differences/ 
would be useful. Except, I'm thinking of not only syntactic differences, 
but rather how very common features or idioms in C++ are done in Julia. A 
colleague asked if Julia supports objects. I said; yes, well not really, 
but you do it like this. A section like that could quickly show whether you 
can do what you want with Julia.

On Thursday, January 1, 2015 2:23:39 AM UTC+1, Josh Langsfeld wrote:

 I currently am trying to solve a problem where I have many composite types 
 and I would like to associate some data with each type, such that every 
 instance has access to it. Obviously, in C++ I would just create a static 
 member variable. 

 Is there a good way to go about this in Julia? Currently, I have it 
 working by using a global Dict mapping DataType objects to their associated 
 data but I really don't like this. Something more naive like just adding 
 that field to every object instance also strikes me as unnecessary and 
 wasteful. I haven't seen any significant discussion about static fields on 
 the lists or on github so is this something that could be considered for 
 addition to the language?

 Thanks,
 Josh

Re: [julia-users] Re: checking a version number?

Apparently it's important to get it right from the beginning:

version numbers should be boring 
http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/


On Wednesday, December 31, 2014 2:25:54 PM UTC+1, Tim Holy wrote:

 Yes, dealing with version numbers is really sweet in julia. I believe 
 Stefan 
 deserves credit for this. Incidentally, if you parse C library version 
 numbers 
 into a VersionNumber type, you can use all the same machinery. 

 --Tim 

 On Wednesday, December 31, 2014 04:19:44 AM Andreas Lobinger wrote: 
  I see. The a = Base.VERSION and then looking at a.major a.minor is 
 already 
  enough in my case. I wasn't aware you could do even comparisions with 
 the 
  v string.

[julia-users] Re: Declaring variables in julia

Yes, the short answer is that the Julia manual is full of talk about types.

Whether to specify type information, and if so, how depends on what you are 
trying to do. So an example of what you are trying to write would be 
helpful.

Exact type correspondences 
http://julia.readthedocs.org/en/latest/manual/calling-c-and-fortran-code/#type-correspondences
 
are listed in the Julia manual, but these are normally only useful for 
interfacing with Fortran or C libraries. 

--John

On Wednesday, December 31, 2014 1:57:25 PM UTC+1, sadhanapriya...@vit.ac.in 
wrote:

 hi


 Please let me know how to declare float, double, long int, unsigned long 
 and unsigned char to some variable in julia( Please mention syntax)
   


 Thanks

[julia-users] Re: ANN: ApproxFun v0.05 with support for piecewise and singular functions

Pkg.add(ApproxFun) did not give me v0.0.5 for some reason
$ git  tag
v0.0.1
v0.0.2
v0.0.3
v0.0.4

So your first examples failed. But, this is very impressive!

--John

On Wednesday, December 31, 2014 4:54:06 AM UTC+1, Sheehan Olver wrote:


 ApproxFun is a package for approximating functions and solving 
 differential equations.  ApproxFun v0.05 adds support for piecewise and 
 singular functions.  For example, we can sample a function with semicircle 
 or other Jacobi singularities:

 x=Fun(identity,[-1,1])
 sample(exp(x)*sqrt(1-x^2),100)
 sample((1-x)^0.123/(1+x)^0.567,100)


 Or integrate the absolute value of sin:

 x=Fun(identity,[-5,5])
 sum(abs(sin(x)))


 Or even solve PDEs with discontinuous coefficients.  Other improvements 
 include 2-5x faster ODE solving, so that now an ODE requiring a million 
 unknowns can be solved in one second, and preliminary support for high 
 precision functions.  

 Thanks go to Gustavo Goretkin (MIT) and Mikael Slevinsky (Oxford) for many 
 contributions!

 Note: Julia v0.4 is not supported due to issue #9378

Re: [julia-users] Re: ANN: ApproxFun v0.05 with support for piecewise and singular functions