Re: [julia-users] Questions about the garbage collector

> > > >> The generational part of the GC is a little messy. This is mainly > >> because the new GC was designed to be an incremental GC and then > >> gradually transformed into a generational GC... (they are > >> suprisingly similar). > >> > > > > Oh I didn't even realise that LOL.

Re: [julia-users] Questions about the garbage collector

On 15 March 2016 at 20:24, Yichao Yu wrote: > > I wonder what the issue was, and whether the person who fixed it even > realised they had fixed it. :-) > > There were many GC related PRs. Some of them are for mem-leak. I don't > remember any one in particular about malloc

Re: [julia-users] Questions about the garbage collector

> > > > I see. That is a relief. We'll stick with & for now. > > > >> more than 2 collection* > > > > > > I see, so collections can happen at any time, not when some block of > memory > > is "full". > > Yes, it happens whenever the GC thinks there are enough allocation > since the last time. > So

Re: [julia-users] Questions about the garbage collector

Good to hear the problem seems to be fixed in recent 0.5. Thanks for checking this. That gives me more motivation for fixing our code so it can run on the latest 0.5. Hopefully I can find a way. I wonder what the issue was, and whether the person who fixed it even realised they had fixed it. :-)

Re: [julia-users] Questions about the garbage collector

On 15 March 2016 at 19:45, Bill Hart <goodwillh...@googlemail.com> wrote: > >> > >> > I noticed in the code that it looks like things get promoted if they >> survive >> > more than 2 generations (currently). But what happens to the objects >> betwee

Re: [julia-users] Questions about the garbage collector

On 15 March 2016 at 19:33, Yichao Yu <yyc1...@gmail.com> wrote: > On Tue, Mar 15, 2016 at 2:18 PM, 'Bill Hart' via julia-users > <julia-users@googlegroups.com> wrote: > > > > Thanks for your answers. Please see my followup questions below. > > > >

Re: [julia-users] Questions about the garbage collector

On Tuesday, 15 March 2016 19:02:41 UTC+1, Yichao Yu wrote: > > On Tue, Mar 15, 2016 at 1:45 PM, Yichao Yu <yyc...@gmail.com > > wrote: > > > > On Mar 15, 2016 11:56 AM, "'Bill Hart' via julia-users" > > <julia...@googlegroups.com > wro

Re: [julia-users] Questions about the garbage collector

Thanks for your answers. Please see my followup questions below. On 15 March 2016 at 18:45, Yichao Yu <yyc1...@gmail.com> wrote: > > On Mar 15, 2016 11:56 AM, "'Bill Hart' via julia-users" < > julia-users@googlegroups.com> wrote: > > > > We have been

Re: [julia-users] Questions about the garbage collector

will kick in from time to time and run the finalizers of the BigNum objects > that are not rooted anymore. > > > > Am Dienstag, 15. März 2016 17:20:37 UTC+1 schrieb Bill Hart: >> >> Just to clarify what I meant by "Julia can't be responsible for" I >&g

Re: [julia-users] Questions about the garbage collector

Just to clarify what I meant by "Julia can't be responsible for" I was talking about the fact that the garbage collector does a gc_collect every 23mb on my machine. If memory is allocated on the C side without calling jl_gc_counted_malloc to do so, Julia can't be expected to include these

Re: [julia-users] Questions about the garbage collector

Here is the (very primitive) example using mpn's that I mentioned. import Base: + typealias ZZ Array{UInt, 1} function +(a::ZZ, b::Int) r = ZZ(length(a)) ccall((:__gmpn_add_1, :libgmp), Void, (Ptr{UInt}, Ptr{UInt}, Int, Int), r, a, 3, b) return r end function doit(n::Int) a =

Re: [julia-users] Questions about the garbage collector

On 15 March 2016 at 17:04, Yichao Yu <yyc1...@gmail.com> wrote: > > On Mar 15, 2016 11:56 AM, "'Bill Hart' via julia-users" < > julia-users@googlegroups.com> wrote: > > > > We have been trying to understand the garbage collector behaviour, since > we

[julia-users] Questions about the garbage collector

We have been trying to understand the garbage collector behaviour, since we had some code for which our machine is running out of memory in a matter of an hour. We already realised that Julia isn't responsible for memory we allocate on the C side unless we use jl_gc_counted_malloc, which we

Re: [julia-users] Re: deepcopy_internal and arrays

Thanks. I appreciate the reply. On 26 February 2016 at 09:32, Mauro wrote: > > However, could you please explain to me what is involved in updating > dict? > > I understand an ObjectIdDict is a hash table whose keys are object ID's. > > But the documentation doesn't tell me

Re: [julia-users] Re: deepcopy_internal and arrays

Thanks. Indeed I missed this in the docs, so no ticket needs to be opened. The fact that overloading deecopy_internal is fully supported is perfectly fine. However, could you please explain to me what is involved in updating dict? I understand an ObjectIdDict is a hash table whose keys are object

Re: [julia-users] Intermittent failure on Travis in Nemo.jl? (was : Just a noob question: why are some test-failing PR merged?)

On Tuesday, 23 February 2016 15:40:50 UTC+1, Yichao Yu wrote: > > > > On Tue, Feb 23, 2016 at 9:26 AM, 'Bill Hart' via julia-users < > julia...@googlegroups.com > wrote: > >> We just had a failure of Nemo.jl on Travis on OSX which looks completely >> rand

[julia-users] Re: deepcopy_internal and arrays

Just correcting a typo in my question (the question still stands): deepcopy(A)[1] == x was not meant to be written twice. I accidentally copy and pasted it from my terminal twice. On Tuesday, 23 February 2016 15:16:08 UTC+1, Bill Hart wrote: > > In Nemo.jl we require some o

Re: [julia-users] Just a noob question: why are some test-failing PR merged?

We just had a failure of Nemo.jl on Travis on OSX which looks completely random. We replace uint with UInt in two places. Before the patch all passes. After the patch, segfault on OSX in a fairly unrelated function. The failure almost seems to random to even bother posting, but here is the

[julia-users] deepcopy_internal and arrays

In Nemo.jl we require some objects to be singleton. In other words they should never be deep copied since we require only one of them to exist. This is causing a problem with deepcopy of arrays that somewhere contain these objects. E.g. in Nemo.jl: Qx,x = PolynomialRing(QQ, "x") # here x

Re: [julia-users] Re: Embedding Julia

the binary in the right location. I'm not sure where exactly Julia looks for its sys.so, but on Ubuntu at least, it looks in the wrong place. Bill. On 9 December 2015 at 05:00, Bill Hart <goodwillh...@googlemail.com> wrote: > > > On 9 December 2015 at 04:47, Tony Kelman <t...

[julia-users] Embedding Julia

I tried the example [1] for embedding Julia in C, using the latest Julia-0.5 nightly, but have run into problems. One trivial problem I had was that jl_atexit_hook(); seems to now require a return argument. That was easy to fix. However the C program given at [1] didn't link. It claims to not

[julia-users] Re: Embedding Julia

r binary builds I link with /lib/julia/libjulia.so > > Here is a little example of my Cmake setup and c++ file: > https://github.com/KristofferC/exploration/tree/master/embed_julia > > On Tuesday, December 8, 2015 at 6:27:37 PM UTC+1, Bill Hart wrote: >> >> I tried the examp

Re: [julia-users] Re: Embedding Julia

tried it (quite some time ago now) it didn't. I figured the Ubuntu ppa's were there for a reason at the time, so didn't think much more of it. Bill. > > > On Tuesday, December 8, 2015 at 3:33:53 PM UTC-8, Bill Hart wrote: >> >> By the way, I haven't used the generic Linux binarie

Re: [julia-users] Re: Embedding Julia

users are going to prefer the ppa magic anyway. On 9 December 2015 at 00:24, Bill Hart <goodwillh...@googlemail.com> wrote: > I've searched my machine and really haven't found libjulia.so, except the > copy I mentioned, which has no symbols. > > The PPA's seemed to be very up-to-date

Re: [julia-users] Re: Embedding Julia

@Kristoffer That's because you have libjulia.so installed on your system. I've only installed Julia using an Ubuntu ppa, which is missing libjulia.so apparently. It obviously looks in the standard system library location for the libraries it needs (as it should). The problem here is that we

Re: [julia-users] Re: Embedding Julia

I've searched my machine and really haven't found libjulia.so, except the copy I mentioned, which has no symbols. The PPA's seemed to be very up-to-date with v0.4.1 being available the day it was released. They also work just fine. I think they are just missing something. Where would I even

Re: [julia-users] Re: Embedding Julia

I should add that it would still be useful if there was a Makefile to install Julia system wide after extracting the tarball. Bill. On 9 December 2015 at 03:28, Bill Hart <goodwillh...@googlemail.com> wrote: > > > On 9 December 2015 at 01:54, Tony Kelman <t...@kelman.net>

Re: [julia-users] Re: Embedding Julia

On 9 December 2015 at 04:47, Tony Kelman wrote: > I'd think a simple shell script, install-julia.sh or something, would be > better than a Makefile - you don't always have build-essential installed. > Putting something in contrib (along with a corresponding uninstall-julia.sh >

[julia-users] Fwd: [ANN] Nemo 0.4 released!

to small bits and pieces of maintenance, which we've confined to our todo.txt). Suggestions of additional projects are also very welcome. Enjoy!! And please do let us know of successful/unsuccessful builds. Best Wishes, Bill Hart Tommy Hofmann Claus Fieker Fredrik Johansson

Re: [julia-users] Fwd: [ANN] Nemo 0.4 released!

of you!! > > One question: Is there any IJulia notebook about Nemo? > > Thanks, > > Charles > > On 4 December 2015 at 23:50, 'Bill Hart' via julia-users < > julia...@googlegroups.com > wrote: > >> >> Hi all, >> >> It is with great pleasure

Re: [julia-users] Fwd: [ANN] Nemo 0.4 released!

On 5 December 2015 at 01:27, Eric Forgy wrote: > Numerous benchmarks have been added to our benchmarks page to show that >> these implementations are competitive with other systems. > > > Looking at the numbers, I call this an understatement :) > Yes, but we are cheating

Re: [julia-users] Fwd: [ANN] Nemo 0.4 released!

I should add that one thing that number theorists are very interested in is quaternion algebras, especially over number fields. I hope that will eventually be done well in Nemo. Bill. On 5 December 2015 at 01:42, Bill Hart <goodwillh...@googlemail.com> wrote: > > > On 5 Decembe

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

It would be better with Pollard Rho to list the times depending on the smallest factor. It would be interesting to compare timings for some known numbers such as Fermat numbers (F_n = 2^(2^n) + 1). Here are some timings from a Google summer of code project we had this year: F_6

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

Do you mean you are factoring something other than random numbers, or do you mean your Pollard Rho is completely deterministic? It's not a good measure of performance to time just one factorisation with Pollard Rho, since you could just pick the parameters such that it essentially succeeds

[julia-users] [OT] Assembly language position

Hi all, If anyone would be interested in writing an x86_64 assembly superoptimiser in Julia, we have a year of (academic) grant funding here in Germany that could pay someone to do it. If you are interested in the details, please contact me off list. I recognise that this is not exactly on

Re: [julia-users] [OT] Assembly language position

Thanks, I wasn't aware of it. I'll see to it that something gets posted there. Bill. On 29 October 2015 at 14:09, Yichao Yu <yyc1...@gmail.com> wrote: > On Thu, Oct 29, 2015 at 9:06 AM, Bill Hart <goodwillh...@googlemail.com> > wrote: > > Hi all, > > > > If a

[julia-users] download cache in Windows

I'm currently using download() to get dlls on Windows. This works fine, except that it has a cache and I don't know how to clear it. Even days after a file is first downloaded, and even after that file is updated at its URL, it simply copies over the cached file instead of downloading the new

[julia-users] Re: The Julia Community Standards

I've read the thread here (not the original) and am somewhat confused actually. Whilst this seems very reasonable -> In particular, do not sexualize the term “Julia” or any other aspects of the project. The following appears to invite contention. While “Julia” is a female name in many parts

Re: [julia-users] Pkg.test fails with system wide install

Thanks. In our case we made the tests a submode of Nemo, so we can use Nemo.Test.test_all() which is not so terrible. Bill. On Saturday, 10 October 2015 02:18:46 UTC+2, Yichao Yu wrote: > > On Fri, Oct 9, 2015 at 7:43 PM, Bill Hart <goodwi...@googlemail.com > > wrote: >

Re: [julia-users] How to have type parameters T less than Array{AbstractFloat} in the covariant sense?

You probably already realise this, but you can do: function f{T <: AbstractFloat}(a::Array{T}) # body end But I assume that is not what you were after. Bill. On Saturday, 10 October 2015 02:48:37 UTC+2, Mauro wrote: > > This is called triangular dispatch and is not currently supported.

[julia-users] Re: ANN: Julia v0.4.0 released!

Congratulations on the release and many thanks for all the tireless, talented, hard work!! Bill.

[julia-users] Pkg.test fails with system wide install

I have managed to install our Nemo package system wide, simply by copying the entire Nemo directory from a working Nemo build to /usr/share/julia/site/v0.4/Nemo (plus some bug fixes: corrected rpath, @__FILE__ instead of Pkg.dir()). Nemo works just fine, but when I do Pkg.test("Nemo") it says:

[julia-users] Example usage for withenv()

I managed to finally figure out how to use withenv with two arguments (the first has to be a lambda or function with no parameters). But the documentation here: http://julia.readthedocs.org/en/latest/stdlib/base/#Base.withenv indicates that withenv can also be used with a do..end block.

[julia-users] Re: Example usage for withenv()

I appreciate your help. Bill. On Saturday, 10 October 2015 02:41:18 UTC+2, Steven G. Johnson wrote: > > > > On Friday, October 9, 2015 at 8:34:19 PM UTC-4, Bill Hart wrote: >> >> indicates that withenv can also be used with a do..end block. However, >> try as I might, I c

[julia-users] Re: ANN: Julia v0.4.0 released!

Will someone post the release announcement to Hacker News? Or did I just not get up early enough today. :-) On Saturday, 10 October 2015 03:20:22 UTC+2, Bill Hart wrote: > > Congratulations on the release and many thanks for all the tireless, > talented, hard work!! > > Bill. >

[julia-users] Re: System wide package installation

I think I figured it out, actually. I can set rpath to both possibilities. One will be silently ignored. Now if only the rpath wasn't hard coded into the build scripts... Anyway, this is clearly not a Julia issue. Sorry for the noise. Bill. On 9 October 2015 at 22:17, Bill Hart <goodwi

[julia-users] System wide package installation

A system administrator is trying to install our Nemo package system wide on a VM for his users. He's located a ticket [1] which gave him the hint to put Nemo into ../ share/julia/site/v0.4 relative to the Julia binary, after Nemo has built its dependencies. The problem is, a few of Nemo's

[julia-users] Re: Accessing MSYS2 built dlls from Julia

r find another way to > communicate with it. > > > On Wednesday, October 7, 2015 at 9:27:40 PM UTC-7, Bill Hart wrote: >> >> I understand that under normal circumstances, for least difficulties, one >> wants to build dlls using the mingw-w64 gcc if one wants to use

[julia-users] Accessing MSYS2 built dlls from Julia

I understand that under normal circumstances, for least difficulties, one wants to build dlls using the mingw-w64 gcc if one wants to use it from Julia. This makes a dll which is not dependent on msys-2.0.dll. My question is: should I expect to be unable to use *any* dlls built using the MSYS2

[julia-users] Re: GC and scope

12:23:43 UTC+2, Bill Hart wrote: > > Is there any relationship between Julia's lexical scoping and garbage > collection? > > What I mean is: if I have a function inside which is a variable which is > not used from some point onwards in the function, does the object live o

[julia-users] Symbol not found in C library on OSX Yosemite (only)

We have an OSX Yosemite user who has the following message when loading our Nemo package: *using Nemo* *ERROR: InitError: cglobal: could not find symbol avma in library /Users/keithharrison/.julia/v0.4/Nemo/local/lib/libpari* * in __init__ at

Re: [julia-users] Re: Symbol not found in C library on OSX Yosemite (only)

Thanks Isaiah. Indeed the symbol avma appears to not be exported, which is obviously nothing to do with Julia. I had completely discounted this possibility, since Pari is used by other projects in precisely the same way we are using it. In fact, you can't do much of anything at all with the

[julia-users] Re: Symbol not found in C library on OSX Yosemite (only)

We've checked the following without success: * turning off precompilation * putting some traces in to check it does definitely get past the ccall without issue * dlopen'ing libpari beforehand None of these made any difference. That's all the ideas I have. It looks like a bug somewhere to me.

[julia-users] Re: Building binary dependencies from source on OSX

I've managed to ascertain that the users who were having trouble have viable toolchains (e.g. Xcode). For some reason the m4 autotools fails to find the C compiler on OSX. That's obviously nothing to do with Julia. And the OSX bison is also not up-to-date, also not to do with Julia. I don't

Re: [julia-users] Re: Building binary dependencies from source on OSX

I had a look at Homebrew, but I'm afraid it's quite beyond me. I'm going to have to wait until our OSX usership has increased enough for someone to build all the necessary recipes for us. The homebrew-science tap definitely won't have Antic, since that's brand new, and we also added quite a lot

[julia-users] Re: Double free or corruption (out)

The malloc/free functions are the ones that allocate and free blocks of memory. They are provided by the system (e.g. Linux). A double free or corruption likely means that free was called twice on the same block of memory, or that something was overwritten that shouldn't have been, e.g. an

[julia-users] Re: [ANN] Nemo: A computer algebra package for Julia

I've just tagged Nemo-0.3.1. This fixes some issues on OSX and on 32 bit platforms that were reported. Other platforms are not affected. Note that on OSX we don't provide binaries, but build from source. So you need a working build environment (a fairly recent Xcode -- is that the right

[julia-users] [ANN] Nemo: A computer algebra package for Julia

. Bill Hart. [1] http://www.math.uni-hamburg.de/DMV2015/minisymposiaschedule.html [2] http://www.singular.uni-kl.de/ [3] http://www.gap-system.org/ [4] http://www.polymake.org/doku.php [5] http://pari.math.u-bordeaux.fr/ [6] http://flintlib.org/ [7] https://github.com/wbhart/antic [8] http

Re: [julia-users] Re: cglobal library name issue

eally dumb question. >> >> Bill. >> >> On 18 September 2015 at 22:24, Jameson Nash <vtjn...@gmail.com> wrote: >> >>> That seems like an odd way to write replace(somdir, "\\", ""), but >>> no, those functions aren't const. Y

Re: [julia-users] Re: cglobal library name issue

module test suite or just using the module from the Julia > console. > > presumably running the code in the code from the test suite and running it > from the console shouldn't be rearranging your filesystem? regardless, the > intent behind Libdl.DL_LOAD_PATH was to help handle this ca

Re: [julia-users] Re: cglobal library name issue

nd split, etc? Bill. On 18 September 2015 at 20:52, Jameson Nash <vtjn...@gmail.com> wrote: > You should be able to work out everything relative to source_path() at > compile time (this is what `include` does to find files relative to the > current file being included). > > >

Re: [julia-users] Re: cglobal library name issue

;), but no, > those functions aren't const. You need to actually call them at compile > time and store the result in a global const variable. > > > On Fri, Sep 18, 2015 at 2:59 PM 'Bill Hart' via julia-users < > julia-users@googlegroups.com> wrote: > >> Thanks, but this

[julia-users] cglobal library name issue

Hi, I'm actually trying to precompile our library. This seems to necessitate putting some of the initialisation code we had in an __init__ function. But I'm having problems with the cglobal syntax. According to the documentation, it takes a tuple with exactly the same format as ccall. But this

[julia-users] Re: cglobal library name issue

at compile time as a constant, but it can't know $pkgdir (which is set earlier) until runtime. Or something. Bill. On 18 September 2015 at 13:14, Bill Hart <goodwillh...@googlemail.com> wrote: > Hi, > > I'm actually trying to precompile our library. This seems to n

[julia-users] Re: cglobal library name issue

September 2015 15:22:39 UTC+2, Bill Hart wrote: > > This improved things a bit, though there are some further issues: > > * both __init__ and our test code need to load this file, but the current > directory is different in each case, so I can't give a relative path for > d

[julia-users] Re: cglobal library name issue

This improved things a bit, though there are some further issues: * both __init__ and our test code need to load this file, but the current directory is different in each case, so I can't give a relative path for deps/deps.jl itself, which puts us back right where we were. (I've resolved this

[julia-users] Re: cglobal library name issue

I managed to get it to work. The problem was obscure. * the patch someone had come up with for putting the -rpath in libpari was faulty * I thought libgmp.so.16 was resolving (when I did ldd) because part of the procedure to put the -rpath in the library was to put the library path in

Re: [julia-users] Re: Accessing Windows 64 dll's from within Julia

mpatible with Julia > binaries. Or you can cross-compile from Cygwin, but sounds like the build > systems of the libraries you're building can't handle that. > > > On Monday, September 14, 2015 at 7:27:55 PM UTC-7, Bill Hart wrote: >> >> I simply used the "MinGW-w6

[julia-users] Re: [julia-dev] Re: Julia v0.4.0-rc1 released

All 23,000 lines of code in our Nemo package passes its extensive test suite with Julia-0.4-rc1 on Ubuntu 14.04 and Windows 10 (64 bit). Thanks all for the amazing hard work! Bill. On 11 September 2015 at 06:18, Nitin Arora wrote: > Congrats all ! > > > On Thursday,

[julia-users] Re: Accessing Windows 64 dll's from within Julia

Sorry I surely meant WinRPM not WebRPM.

Re: [julia-users] Re: Accessing Windows 64 dll's from within Julia

:30, Jameson Nash <vtjn...@gmail.com> wrote: > The shell is correct, but you will probably want to download mingw64 > separately. The julia `README.windows` file has links, I think, to the > right one to download. > > On Mon, Sep 14, 2015 at 10:27 PM 'Bill Hart' via julia-

[julia-users] Re: Accessing Windows 64 dll's from within Julia

I forgot to ask: does Julia currently expect to find .a or .dll files on Windows 64? Is anything else needed? Bill. On 15 September 2015 at 02:23, Bill Hart <goodwillh...@googlemail.com> wrote: > Hi, > > I'm currently up to working on building the dependencies for our Nemo >

Re: [julia-users] Re: Accessing Windows 64 dll's from within Julia

BinDeps next. I have dedicated web hosting for the dll's, so that isn't a problem. Just getting them running from within Julia will be enough. Bill. > >> >> On Monday, September 14, 2015 at 5:23:12 PM UTC-7, Bill Hart wrote: >>> >>> Hi, >>> >>>

[julia-users] Accessing Windows 64 dll's from within Julia

Hi, I'm currently up to working on building the dependencies for our Nemo computer algebra package for Julia: https://github.com/wbhart/Nemo.jl We have dependencies on the following C libraries: libpari (Pari/GP) Antic (https://github.com/wbhart/Antic) Flint (https://github.com/wbhart/flint2)

Re: [julia-users] Re: Accessing Windows 64 dll's from within Julia

, only for the purposes of > download_cmd and unpack_cmd: > https://github.com/stevengj/Blosc.jl/blob/master/deps/build.jl > > > On Monday, September 14, 2015 at 6:36:56 PM UTC-7, Bill Hart wrote: > >> >> >> On 15 September 2015 at 02:54, Tony Kelman <to...@kel

Re: [julia-users] Re: Accessing Windows 64 dll's from within Julia

gt; > On Mon, Sep 14, 2015 at 9:55 PM 'Bill Hart' via julia-users < > julia-users@googlegroups.com> wrote: > >> I tried two different dll's with absolute paths, built with recent >> MinGW64 and Julia's ccall does not work for either. It still says, "The >> speci

Re: [julia-users] Import statements

. is a workaround for now, so everything is apparently working again. Bill. On Friday, 1 May 2015 14:53:12 UTC+2, Bill Hart wrote: Sorry for the delay. It's a public holiday here, so won't be able to ask my coworker about this one until next week. The only thing I can add at this point

Re: [julia-users] Import statements

, Kevin On Thu, Apr 30, 2015 at 1:48 AM, Bill Hart goodwi...@googlemail.com javascript: wrote: We used to have the following in our code import Base: convert, promote_rule, show, string, parseint, serialize, deserialize, base, bin, dec, oct, hex, gcd, gcdx, lcm, div, size

[julia-users] Import statements

We used to have the following in our code import Base: convert, promote_rule, show, string, parseint, serialize, deserialize, base, bin, dec, oct, hex, gcd, gcdx, lcm, div, size, zero, one, sign, hash, abs, deepcopy, rem, mod, isequal But in the latest update something

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

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

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

not try to factor big integers with trial division. Elliptic curve or quadratic sieve methods may come later. On Monday, March 16, 2015 at 7:14:00 AM UTC+1, Bill Hart wrote: Factoring large integers is an open research problem. The issue is definitely nothing to do with Julia's handling

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

I should mention that if you want to use the factor_one_line.c file unmodified under a BSD or MIT license, I'd have to seek permission from the other copyright holder (who is unlikely to withhold permission). Reimplementing them in Julia is definitely fine. On 16 March 2015 at 07:56, Bill Hart

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

Factoring large integers is an open research problem. The issue is definitely nothing to do with Julia's handling of bignums, or its use of GMP (there is no competitive factoring algorithm in GMP). Fixing that problem properly is on the order of about 120,000 lines of C code, if you want to be

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

. Elliptic curve or quadratic sieve methods may come later. On Monday, March 16, 2015 at 7:14:00 AM UTC+1, Bill Hart wrote: Factoring large integers is an open research problem. The issue is definitely nothing to do with Julia's handling of bignums, or its use of GMP (there is no competitive

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

Bear in mind that you can get (very) lucky with Pollard's Rho. It won't perform comparably for all numbers of the same size. On 16 March 2015 at 09:15, Hans W Borchers hwborch...@gmail.com wrote: Bill, I think it has become clear what I mean. I agree that is unreasonable to exactly define up

Re: [julia-users] Re: Constructing matrices

Yeah, but that's nothing to do with the syntax. After all: julia [1, 2, 3] === [1, 2, 3] false julia [1; 2; 3] === [1; 2; 3] false On 26 February 2015 at 19:55, Luis Benet luis.bene...@gmail.com wrote: Just a tiny little note on: [1; 2; 3] is precisely the same thing as [1, 2, 3] julia

Re: [julia-users] Re: Constructing matrices

just extremely confusing and I'll bet it will bite somewhere down the track. It's especially bad for metaprogramming for example. Bill. On 24 February 2015 at 20:39, David P. Sanders dpsand...@gmail.com wrote: El martes, 24 de febrero de 2015, 8:18:28 (UTC-6), Bill Hart escribió: The specific

[julia-users] Re: Constructing matrices

Thanks. The hvcat is somewhat awkward as a matrix syntax. But from your hint I also see that [[1]'; 2; 3] or [1 2 3]' works. That's a bit ugly, but workable for now. I really wish the semicolon had been reserved for terminating the row of a matrix. Clearly Julia wants to deliberately conflate

Re: [julia-users] linking Julia with C to improve performances

One important thing to note is that if you do a + b at the top level, it won't be fast. But as soon as you do a + b inside a function, it will be as fast as C. For example a = 20 b = 10 for i = 1:10 c = a + b end takes about 34s But the following is almost instantaneous: function

Re: [julia-users] Re: Constructing matrices

The specific use case where I hit this as a problem is in wrapping external libraries like flint and pari, which unlike julia do not conflate 1xn matrices with flat arrays. However, I have just realised that Julia only conflates column vectors with flat arrays, not row vectors. Therefore I can

Re: [julia-users] Re: linking Julia with C to improve performances

I was aware of this, but I believe good C compilers also do this optimisation with link time optimisation these days. It's nice to be able to demonstrate the same behaviour in Julia. On 24 February 2015 at 14:47, Simon Danisch sdani...@gmail.com wrote: @Bill Hart small note on your example

Re: [julia-users] linking Julia with C to improve performances

On 24 February 2015 at 14:33, Milan Bouchet-Valat nalimi...@club.fr wrote: Le mardi 24 février 2015 à 05:25 -0800, Bill Hart a écrit : In answer to your original question, assuming you had a very complex C program that Julia just didn't handle efficiently (it's possible), or you had

Re: [julia-users] linking Julia with C to improve performances

best practice or not). Otherwise, on most systems the dynamic linker has various places it will look for your library. This depends on your system though, so it varies between Unix, Linux, Windows and OSX. On Tuesday, 24 February 2015 14:10:31 UTC+1, Bill Hart wrote: One important thing

Re: [julia-users] Re: Constructing matrices

:23 PM UTC-5, Bill Hart wrote: This might not be a trivial change. Presumably its done this way so that functions like linear solving do not take a column matrix as one of its inputs (which maybe has a relatively inefficient representation?), but so that they can take a flat array as input, which

Re: [julia-users] Re: Constructing matrices

that Julia uses a flat array instead. On 24 February 2015 at 23:18, Kevin Squire kevin.squ...@gmail.com wrote: I (think I) would be in favor of changing [1; 2; 3] to mean a 1-column matrix. Arguments against? Kevin On Tue, Feb 24, 2015 at 11:45 AM, Bill Hart goodwillh...@googlemail.com wrote

Re: [julia-users] Re: Constructing matrices

Sorry, I wrote 0D array, when I actually meant 0xn or nx0 arrays, (which my colleague and I agree should be 2D). On 25 February 2015 at 01:10, Bill Hart goodwillh...@googlemail.com wrote: On 25 February 2015 at 00:18, Matt Bauman mbau...@gmail.com wrote: I don't understand the distinction

[julia-users] Constructing matrices

I'm writing some code which takes 2-dimensional Julia arrays and converts them to an external matrix type. For example Mat([1 2; 3 4; 5 6]) creates a 3x2 matrix. But I cannot figure out the syntax for nx1 arrays in Julia. Note that I need to be able to construct nx1 and 1xn matrices. I assumed

Re: [julia-users] Memory leak with ccall

Random guess: someone switched of the gc when llvm-3.5 or higher is used, because of some issue. I'll try installing a fresh julia with the standard llvm, whatever that is, when I get a chance, just to confirm the issue goes away. On Saturday, 7 February 2015 12:03:31 UTC+1, Bill Hart wrote

Re: [julia-users] Memory leak with ccall

No, definitely didn't do that. On 7 February 2015 at 01:32, Stefan Karpinski ste...@karpinski.org wrote: Did you call gc_disable() at some point? On Friday, February 6, 2015, Bill Hart goodwillh...@googlemail.com wrote: Oh wait a minute. Running gc() did clean up the specific example

Re: [julia-users] Memory leak with ccall

. On 7 February 2015 at 11:52, Bill Hart goodwillh...@googlemail.com wrote: No, definitely didn't do that. On 7 February 2015 at 01:32, Stefan Karpinski ste...@karpinski.org wrote: Did you call gc_disable() at some point? On Friday, February 6, 2015, Bill Hart goodwillh...@googlemail.com

<    1   2   3   >