You don't really need extended precision (for a while), which makes it 
obviously a lot faster.

   foo=: 3 : '*/p^<.y^.~p=.p:i._1 p:y'
   100000(-:&foo)100000x
1


R.E. Boss


> -----Oorspronkelijk bericht-----
> Van: Programming <programming-boun...@forums.jsoftware.com>
> Namens Don Guinn
> Verzonden: maandag 11 maart 2019 17:38
> Aan: Programming forum <programm...@jsoftware.com>
> Onderwerp: Re: [Jprogramming] LCM performance
> 
> 6!:2 'n=:*/p^<.y^.~p=.p:i._1 p:y=.100000x'
> 
> 0.690272
> 
> 40{.":n
> 
> 6952838362417071970003075865264183883398
> 
> On Mon, Mar 11, 2019 at 10:07 AM 'Mike Day' via Programming <
> programm...@jsoftware.com> wrote:
> 
> > As mentioned (indirectly) in my second attempt to comment, the _ q:
> > version failed (on my Windows 10 laptop, with 16Gb memory!) for
> > 100000, while yours was ok. As, of course, you know, your approach
> > avoids factoring by predicting the maximum prime powers.
> >
> > Cheers,
> >
> > Mike
> >
> > Please reply to mike_liz....@tiscali.co.uk.
> > Sent from my iPad
> >
> > > On 11 Mar 2019, at 15:50, Raul Miller <rauldmil...@gmail.com> wrote:
> > >
> > > And, that said, after playing with this, lcmseq 100000x seems to be
> > > significantly faster than >./&.(_&q:) 1+i. 100000x (at least on this
> > > machine).
> > >
> > > FYI,
> > >
> > > --
> > > Raul
> > >
> > > P.S. if you are reading this in a context where the rest of this
> > > thread is not available, the definition of lcmseq was:
> > >
> > > lcmseq=: 3 : 0
> > >  primes=. i.&.(p:inv) y
> > >  maxsq=. 1+primes I.%:y
> > >  */primes^x:1>.(#primes){.<.(maxsq{.primes)^.y
> > > )
> > >
> > >> On Mon, Mar 11, 2019 at 10:08 AM Raul Miller
> > >> <rauldmil...@gmail.com>
> > wrote:
> > >>
> > >> Wasn’t thinking clearly though because the _ q: representation is
> > >> much
> > nicer...
> > >>
> > >> Sorry about the noise...
> > >>
> > >> —
> > >> Raul
> > >>
> > >>> On Monday, March 11, 2019, Raul Miller <rauldmil...@gmail.com>
> wrote:
> > >>>
> > >>> __ q: I meant..
> > >>>
> > >>> Thanks,
> > >>>
> > >>> —
> > >>> Raul
> > >>>
> > >>>> On Monday, March 11, 2019, Raul Miller <rauldmil...@gmail.com>
> wrote:
> > >>>>
> > >>>> That’s a good approach.
> > >>>>
> > >>>> The _ q: representation is really nice for this task.
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> —
> > >>>> Raul
> > >>>>
> > >>>>> On Monday, March 11, 2019, Eugene Nonko <eno...@gmail.com>
> wrote:
> > >>>>>
> > >>>>> Here's the solution I ended up using:
> > >>>>>
> > >>>>> _&q:^:_1 >./ _ q: >: i. 10000x
> > >>>>>
> > >>>>> Just factorize to prime exponents representation, find maximums
> > >>>>> and
> > convert
> > >>>>> back from prime exponent representation.
> > >>>>>
> > >>>>>> On Sun, Mar 10, 2019 at 2:35 PM Raul Miller
> > >>>>>> <rauldmil...@gmail.com>
> > wrote:
> > >>>>>>
> > >>>>>> J's extended precision integer implementation is part of it.
> > >>>>>> But floating point numbers don't really work for this kind of
> > >>>>>> problem
> > for
> > >>>>>> anything longer than i.11
> > >>>>>>
> > >>>>>> But, also, I imagine a part of this also might be that Haskell
> > >>>>>> has optimizations which improve performance of this kind of
> > >>>>>> problem,
> > which
> > >>>>>> we don't have in J.
> > >>>>>>
> > >>>>>> Here's a J approach that gets the solution to this kind of
> > >>>>>> problem
> > a bit
> > >>>>>> faster:
> > >>>>>>
> > >>>>>> lcmseq=:3 :0
> > >>>>>>  primes=. i.&.(p:inv) y
> > >>>>>>  maxsq=. 1+primes I.%:y
> > >>>>>>  */primes^x:1>.(#primes){.<.(maxsq{.primes)^.y
> > >>>>>> )
> > >>>>>>
> > >>>>>>   lcmseq 100000x
> > >>>>>>
> > >>>>>>
> >
> 6952838362417071970003075865264183883398742917680351135360275375615
> 0414421750212375062579868286020477636128776978764548927336600810587
> 0757535968316298519927347209547516689789186138157883056062709938348
> 3382709560516260628624180504874681127372319705939469099...
> > >>>>>>   6!:2'lcmseq 100000x'
> > >>>>>> 0.398073
> > >>>>>>
> > >>>>>> I hope this helps,
> > >>>>>>
> > >>>>>> --
> > >>>>>> Raul
> > >>>>>>
> > >>>>>> --
> > >>>>>> Raul
> > >>>>>>
> > >>>>>> On Sun, Mar 10, 2019 at 5:10 PM james faure
> > >>>>>> <james.fa...@epitech.eu
> > >
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>> That, I suspect, can be blamed mostly on the abysmally slow
> > extended
> > >>>>>> precision integers in J, and the fact that *. must manipulate
> > >>>>>> these extended precision integers more often than other verbs.
> > >>>>>>>
> > >>>>>>> Indeed, If you remove the 'x', it runs extremely fast.
> > >>>>>>> ________________________________
> > >>>>>>> From: Programming <programming-
> boun...@forums.jsoftware.com>
> > >>>>>>> on
> > behalf
> > >>>>>> of Eugene Nonko <eno...@gmail.com>
> > >>>>>>> Sent: Sunday, March 10, 2019 9:00 PM
> > >>>>>>> To: programm...@jsoftware.com
> > >>>>>>> Subject: [Jprogramming] LCM performance
> > >>>>>>>
> > >>>>>>> I need to find the smallest number that divides all numbers
> > >>>>>>> from 1
> > to n.
> > >>>>>>> The solution, of course is this:
> > >>>>>>>
> > >>>>>>> *./ >: i. n
> > >>>>>>>
> > >>>>>>> What I don't understand is why this solution seems to scale so
> > poorly:
> > >>>>>>>
> > >>>>>>>   6!:2 '*./ >: i.10000x'
> > >>>>>>> 0.326128
> > >>>>>>>   6!:2 '*./ >: i.11000x'
> > >>>>>>> 1.00384
> > >>>>>>>   6!:2 '*./ >: i.12000x'
> > >>>>>>> 4.133
> > >>>>>>>   6!:2 '*./ >: i.13000x'
> > >>>>>>> 11.8082
> > >>>>>>>
> > >>>>>>> When I perform similar calculation in Haskell it produces
> > >>>>>>> result in negligible time, even when n = 100,000.
> > >>>>>>>
> > >>>>>>> λ: foldr1 lcm [1 .. 100000]
> > >>>>>>> 695283836241707197000307586...
> > >>>>>>>
> > >>>>>>> If I use a verb other than *. it runs very quickly, as expected.
> > >>>>>>>
> > >>>>>>> What's so special about LCM?
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> Eugene
> > >>>>>>>
> > ----------------------------------------------------------------------
> > >>>>>>> For information about J forums see
> > http://www.jsoftware.com/forums.htm
> > >>>>>>>
> > ----------------------------------------------------------------------
> > >>>>>>> For information about J forums see
> > http://www.jsoftware.com/forums.htm
> > >>>>>>
> > ----------------------------------------------------------------------
> > >>>>>> For information about J forums see
> > http://www.jsoftware.com/forums.htm
> > >>>>>
> > ----------------------------------------------------------------------
> > >>>>> For information about J forums see
> > http://www.jsoftware.com/forums.htm
> > > --------------------------------------------------------------------
> > > -- For information about J forums see
> > > http://www.jsoftware.com/forums.htm
> >
> > ----------------------------------------------------------------------
> > For information about J forums see
> http://www.jsoftware.com/forums.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to