Re: [julia-users] Range to Array with power functions fails
Thanks.
On Friday, September 5, 2014 1:02:55 PM UTC+2, Milan Bouchet-Valat wrote:
>
> Le vendredi 05 septembre 2014 à 03:29 -0700, Földes László a écrit :
>
> This works fine:
>
> julia> x = 1:5
> 1:5
>
> julia> y = [z^2 for z in x]
> 5-element Array{Any,1}:
> 1
> 4
> 9
> 16
> 25
>
>
> and I can use similar solution with a simplified form:
>
> julia> y = [x*2]
> 5-element Array{Int64,1}:
> 2
> 4
> 6
> 8
> 10
>
>
> so I got brave and tried this, but it failed:
>
> julia> x = 1:5
> 1:5
>
> julia> y = [x^2]
> ERROR: `*` has no method matching *(::UnitRange{Int64}, ::UnitRange{Int64
> })
> in power_by_squaring at intfuncs.jl:56
> in ^ at intfuncs.jl:86
>
>
> or:
>
> julia> y = [x*x]
> ERROR: `*` has no method matching *(::StepRange{Int64,Int64}, ::StepRange{
> Int64,Int64})
>
> Actually it's even simpler than that:
>
> julia> x = 1:5
> 1:5
>
> julia> x*x
> ERROR: `*` has no method matching *(::UnitRange{Int64}, ::UnitRange{Int64})
>
>
> You want to use .* instead of *, and .^ instead of ^:
> julia> x .* x
> 5-element Array{Int64,1}:
> 1
> 4
> 9
> 16
> 25
>
> julia> x.^2
> 5-element Array{Int64,1}:
> 1
> 4
> 9
> 16
> 25
>
>
> Regards
>
[julia-users] Range to Array with power functions fails
This works fine:
julia> x = 1:5
1:5
julia> y = [z^2 for z in x]
5-element Array{Any,1}:
1
4
9
16
25
and I can use similar solution with a simplified form:
julia> y = [x*2]
5-element Array{Int64,1}:
2
4
6
8
10
so I got brave and tried this, but it failed:
julia> x = 1:5
1:5
julia> y = [x^2]
ERROR: `*` has no method matching *(::UnitRange{Int64}, ::UnitRange{Int64})
in power_by_squaring at intfuncs.jl:56
in ^ at intfuncs.jl:86
or:
julia> y = [x*x]
ERROR: `*` has no method matching *(::StepRange{Int64,Int64}, ::StepRange{
Int64,Int64})
Re: [julia-users] julia nightlies current version
Thanks, it seems that I cannot dodge the upgrade procedure, which is a clean reinstall and re-configure... On Wednesday, April 23, 2014 1:24:07 PM UTC+2, K leo wrote: > > I think you are running Xubuntu Raring, which reached end of life, and > so they stopped building nightly for that OS. I am on Trusty and am > getting the nightly for Saucy. > > On 04/23/2014 06:26 PM, Földes László wrote: > > Is the Julia nightlies update every day as it used to do around > > January/February? I don't receive updates for a long time now, and I > > want to investigate whether it is a failed Xubuntu upgrade that killed > > the Sources, or the package really don't update. > > > > Thanks > > > > > versioninfo() > > Julia Version 0.3.0-prerelease > > Platform Info: > > System: Linux (i686-linux-gnu) > > CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz > > WORD_SIZE: 32 > > BLAS: libblas.so.3 > > LAPACK: liblapack.so.3 > > LIBM: libopenlibm > > > >
[julia-users] julia nightlies current version
Is the Julia nightlies update every day as it used to do around January/February? I don't receive updates for a long time now, and I want to investigate whether it is a failed Xubuntu upgrade that killed the Sources, or the package really don't update. Thanks > versioninfo() Julia Version 0.3.0-prerelease Platform Info: System: Linux (i686-linux-gnu) CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz WORD_SIZE: 32 BLAS: libblas.so.3 LAPACK: liblapack.so.3 LIBM: libopenlibm
[julia-users] Re: Julia computational efficiency vs C vs Java vs Python vs Cython
Sorry for the wrong info, I was switching between a 32 bit and a 64 bit machine (SSH terminal), and I just happened to run the script on the 32 bit machine... On Wednesday, January 15, 2014 12:37:07 AM UTC+1, Przemyslaw Szufel wrote: > > Foldes, > > I went for your solution and got a time increase from > 2.1 seconds (64bit integers) to 17.78 seconds (32 bit dow-casting). > Seems like casting is no cheap... > > Any other ideas possibilities? > > All best, > Przemyslaw > > P.S. > Naturally I realize that this is toy example and normally in a typical > production code we would rather use real numbers for computations not ints. > I am asking just out of curiosity ;-) > > > On Wednesday, 15 January 2014 00:25:20 UTC+1, Földes László wrote: >> >> You can force the literals by enclosing them in int32(): >> >> p = [int32(0) for i=1:2] >> result = [int32(0) for i=1:2] >> k = int32(0) >> n = int32(2) >> while k < int32(2) >> i = int32(0) >> >> >> >> On Wednesday, January 15, 2014 12:04:23 AM UTC+1, Przemyslaw Szufel wrote: >>> >>> Simon, >>> Thanks! >>> I changed in Cython to >>> def primes_list(int kmax): >>> cdef int k, i >>> cdef long long n >>> cdef long long p[2] >>> and now I am getting 2.1 seconds - exactly the same time as Julia and >>> Java with longs... >>> >>> Since the computational difference between 64bit longs and 32bit ints is >>> soo high - is there any way to rewrite my toy example to force Julia to do >>> 32 bit int calculations? >>> >>> All best, >>> Przemyslaw Szufel >>> >>> >>> On Tuesday, 14 January 2014 23:55:12 UTC+1, Simon Kornblith wrote: >>>> >>>> In C long is only guaranteed to be at least 32 bits (IIRC it's 64 bits >>>> on 64-bit *nix but 32-bit on 64-bit Windows). long long is guaranteed >>>> to be at least 64 bits (and is 64 bits on all systems I know of). >>>> >>>> Simon >>>> >>>> On Tuesday, January 14, 2014 5:46:04 PM UTC-5, Przemyslaw Szufel wrote: >>>>> >>>>> Simon, >>>>> Thanks for the explanation! >>>>> In Java int is 32 bit as well. >>>>> I have just replaced ints with longs in Java and found out that now I >>>>> get the Java speed also very similar to Julia. >>>>> >>>>> However I tried in Cython: >>>>> def primes_list(int kmax): >>>>> cdef int k, i >>>>> cdef long n >>>>> cdef long p[2] >>>>> ... >>>>> >>>>> and surprisingly the speed did not change...at first I thought that >>>>> maybe something did not compile or is in cache - but I made sure - it's >>>>> not >>>>> the cache. >>>>> Cython speed remains unchanged regardles using int or long? >>>>> I know that now it becomes other language question...but maybe someone >>>>> can explain? >>>>> >>>>> All best, >>>>> Przemyslaw Szufel >>>>> >>>>> >>>>> On Tuesday, 14 January 2014 23:29:40 UTC+1, Simon Kornblith wrote: >>>>>> >>>>>> With a 64-bit build, Julia integers are 64-bit unless otherwise >>>>>> specified. In C, you use ints, which are 32-bit. Changing them to long >>>>>> long >>>>>> makes the C code perform similarly to the Julia code on my system. >>>>>> Unfortunately, it's hard to operate on 32-bit integers in Julia, since + >>>>>> promotes to 64-bit by default (am I missing something)? >>>>>> >>>>>> Simon >>>>>> >>>>>> On Tuesday, January 14, 2014 4:32:16 PM UTC-5, Przemyslaw Szufel >>>>>> wrote: >>>>>>> >>>>>>> Dear Julia users, >>>>>>> >>>>>>> I am considering using Julia for computational projects. >>>>>>> As a first to get a feeling of the new language a I tried to >>>>>>> benchmark Julia speed against other popular languages. >>>>>>> I used an example code from the Cython tutorial: >>>>>>> http://docs.cython.org/src/tutorial/cython_tutorial.html [ the code >>>>>>> for finding n first p
[julia-users] Re: Julia computational efficiency vs C vs Java vs Python vs Cython
You can force the literals by enclosing them in int32():
p = [int32(0) for i=1:2]
result = [int32(0) for i=1:2]
k = int32(0)
n = int32(2)
while k < int32(2)
i = int32(0)
On Wednesday, January 15, 2014 12:04:23 AM UTC+1, Przemyslaw Szufel wrote:
>
> Simon,
> Thanks!
> I changed in Cython to
> def primes_list(int kmax):
> cdef int k, i
> cdef long long n
> cdef long long p[2]
> and now I am getting 2.1 seconds - exactly the same time as Julia and Java
> with longs...
>
> Since the computational difference between 64bit longs and 32bit ints is
> soo high - is there any way to rewrite my toy example to force Julia to do
> 32 bit int calculations?
>
> All best,
> Przemyslaw Szufel
>
>
> On Tuesday, 14 January 2014 23:55:12 UTC+1, Simon Kornblith wrote:
>>
>> In C long is only guaranteed to be at least 32 bits (IIRC it's 64 bits
>> on 64-bit *nix but 32-bit on 64-bit Windows). long long is guaranteed to
>> be at least 64 bits (and is 64 bits on all systems I know of).
>>
>> Simon
>>
>> On Tuesday, January 14, 2014 5:46:04 PM UTC-5, Przemyslaw Szufel wrote:
>>>
>>> Simon,
>>> Thanks for the explanation!
>>> In Java int is 32 bit as well.
>>> I have just replaced ints with longs in Java and found out that now I
>>> get the Java speed also very similar to Julia.
>>>
>>> However I tried in Cython:
>>> def primes_list(int kmax):
>>> cdef int k, i
>>> cdef long n
>>> cdef long p[2]
>>> ...
>>>
>>> and surprisingly the speed did not change...at first I thought that
>>> maybe something did not compile or is in cache - but I made sure - it's not
>>> the cache.
>>> Cython speed remains unchanged regardles using int or long?
>>> I know that now it becomes other language question...but maybe someone
>>> can explain?
>>>
>>> All best,
>>> Przemyslaw Szufel
>>>
>>>
>>> On Tuesday, 14 January 2014 23:29:40 UTC+1, Simon Kornblith wrote:
With a 64-bit build, Julia integers are 64-bit unless otherwise
specified. In C, you use ints, which are 32-bit. Changing them to long
long
makes the C code perform similarly to the Julia code on my system.
Unfortunately, it's hard to operate on 32-bit integers in Julia, since +
promotes to 64-bit by default (am I missing something)?
Simon
On Tuesday, January 14, 2014 4:32:16 PM UTC-5, Przemyslaw Szufel wrote:
>
> Dear Julia users,
>
> I am considering using Julia for computational projects.
> As a first to get a feeling of the new language a I tried to benchmark
> Julia speed against other popular languages.
> I used an example code from the Cython tutorial:
> http://docs.cython.org/src/tutorial/cython_tutorial.html [ the code
> for finding n first prime numbers].
>
> Rewriting the code in different languages and measuring the times on
> my Windows laptop gave me the following results:
>
> Language | Time in seconds (less=better)
>
> Python: 65.5
> Cython (with MinGW): 0.82
> Java : 0.64
> Java (with -server option) : 0.64
> C (with MinGW): 0.64
> Julia (0.2): 2.1
> Julia (0.3 nightly build): 2.1
>
> All the codes for my experiments are attached to this post (Cython i
> Python are both being run starting from the prim.py file)
>
> The thing that worries me is that Julia takes much much longer than
> Cython ,,,
> I am a beginner to Julia and would like to kindly ask what am I doing
> wrong with my code.
> I start Julia console and use the command include ("prime.jl") to
> execute it.
>
> This code looks very simple and I think the compiler should be able to
> optimise it to at least the speed of Cython?
> Maybe I my code has been written in non-Julia style way and the
> compiler has problems with it?
>
> I will be grateful for any answers or comments.
>
> Best regards,
> Przemyslaw Szufel
>
[julia-users] It is not easy to search for a Julia fractal implementation in Julia :-)
Just letting you know :-)
Re: [julia-users] Re: Any coding style to avoid native type overflows?
I was just throwing in a value to stop a calculation if the result is under
that value, I could as well choose 2^16, it just happened to be 2^32.
On Sunday, January 12, 2014 5:50:23 PM UTC+1, Alessandro Andrioni wrote:
>
> In this case, you just need either one of the values converted to a
> BigInt, and big(2)^32 is marginally more efficient than 2^big(32),
> since it allocates one less BigInt.
>
> Also, wouldn't typemax(Int)/typemax(Uint) be what you want here?
>
> On 12 January 2014 14:29, Ivar Nesje >
> wrote:
> > I really agree that this is a mistake that is easily made. There is a
> FAQ
> > answer that explains why we use integer arithmetic with silent overflow.
> >
> > I think Julia would benefit from a simpler way to express numerical
> > constants with type than to first create a Float64 / Int32/64 and then
> send
> > to constructor, but I have not (yet) found a syntax to suggest that
> would
> > get approval.
> >
> > One idea might be to implement a @big macro that would allow you to
> write
> > @big(2^32)
> > and it would be automatically translated to
> > big(2)^big(32)
> >
> > The problem is that it will not work (in a sensible way) for floating
> point,
> > because the macro will not be able to see the string representation, but
> the
> > closest Float64 version. This means that 0.1 will be
> > 1.55511151231257827021181583404541015625e-01 instead of
> >
> 1.02e-01
>
>
> >
> > kl. 17:02:25 UTC+1 søndag 12. januar 2014 skrev Földes László følgende:
> >>
> >> This little piece of code tricked me:
> >>
> >> if value < big(2^32)
> >> println("Finished!")
> >> break
> >> end
> >>
> >> The println was never executed and couldn't find the problem for about
> 3
> >> minutes when I tried it on a 64 bit OS, where it worked.
> >> The problem is that on 32-bit OS 2^32 equals to zero. I'm just getting
> >> used to Julia internals and it is not really a problem if it is
> apparent,
> >> but I clearly need more time with the language to spot these kind of
> error.
> >>
> >> if value < big(2)^big(32)
> >> println("Finished!")
> >> break
> >> end
> >> solve this. But this is ugly and it looks like something that can be
> >> automated.
> >>
> >> is there any coding style that can prevent this error? I would better
> >> receive an overflow error (if it is turned on with a flag to the Julia
> >> executable maybe) than a silent, never running piece of code.
>
[julia-users] Re: Any coding style to avoid native type overflows?
:-) I just realized that you gave me a link to what I already read here in
the mailinglist (probably when I searched for similar questions)
I was just thinking on the macro as well and putting everything inside
quotation marks as: big("2")^big("32") that would sorta work for float, but
I realized this *issue* is not about production code. I totally accept that
production code should use native integer arithmetics without added
checkings/type promotions, I thought that in development phase Julia could
throw an error when such overflow occurs (this feature turned on with an
argument to the julia executable).
On Sunday, January 12, 2014 5:29:05 PM UTC+1, Ivar Nesje wrote:
>
> I really agree that this is a mistake that is easily made. There is a FAQ
> answer<http://docs.julialang.org/en/latest/manual/faq/#why-does-julia-use-native-machine-integer-arithmetic>
> that
> explains why we use integer arithmetic with silent overflow.
>
> I think Julia would benefit from a simpler way to express numerical
> constants with type than to first create a Float64 / Int32/64 and then send
> to constructor, but I have not (yet) found a syntax to suggest that would
> get approval.
>
> One idea might be to implement a @big macro that would allow you to write
> @big(2^32)
> and it would be automatically translated to
> big(2)^big(32)
>
> The problem is that it will not work (in a sensible way) for floating
> point, because the macro will not be able to see the string representation,
> but the closest Float64 version. This means that 0.1 will
> be 1.55511151231257827021181583404541015625e-01 instead
> of
> 1.0000000002e-01
>
> kl. 17:02:25 UTC+1 søndag 12. januar 2014 skrev Földes László følgende:
>>
>> This little piece of code tricked me:
>>
>> if value < big(2^32)
>> println("Finished!")
>> break
>> end
>>
>> The println was never executed and couldn't find the problem for about 3
>> minutes when I tried it on a 64 bit OS, where it worked.
>> The problem is that on 32-bit OS 2^32 equals to zero. I'm just getting
>> used to Julia internals and it is not really a problem if it is apparent,
>> but I clearly need more time with the language to spot these kind of error.
>>
>> if value < big(2)^big(32)
>> println("Finished!")
>> break
>> end
>> solve this. But this is ugly and it looks like something that can be
>> automated.
>>
>> is there any coding style that can prevent this error? I would better
>> receive an overflow error (if it is turned on with a flag to the Julia
>> executable maybe) than a silent, never running piece of code.
>>
>
[julia-users] Any coding style to avoid native type overflows?
This little piece of code tricked me:
if value < big(2^32)
println("Finished!")
break
end
The println was never executed and couldn't find the problem for about 3
minutes when I tried it on a 64 bit OS, where it worked.
The problem is that on 32-bit OS 2^32 equals to zero. I'm just getting used
to Julia internals and it is not really a problem if it is apparent, but I
clearly need more time with the language to spot these kind of error.
if value < big(2)^big(32)
println("Finished!")
break
end
solve this. But this is ugly and it looks like something that can be
automated.
is there any coding style that can prevent this error? I would better
receive an overflow error (if it is turned on with a flag to the Julia
executable maybe) than a silent, never running piece of code.
