[Cuis-dev] Problems in class Number

[Andres Valloud]

Agreed --- thank you for your work!  I especially liked to see multiple 
techniques being put together so that the results are better than with 
just any one of them individually.

Do you want the method to have your initials?

On 10/11/19 21:58, Agustín Sansone via Cuis-dev wrote:
> Okay :)
> 
> El sáb., 12 oct. 2019 1:47 a. m., Andres Valloud via Cuis-dev 
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> escribió:
> 
>     Ok, how about we ship off the 8281 boundary code then?
> 
>     On 10/11/19 20:36, Agustín Sansone via Cuis-dev wrote:
>      > This ir what I get:
>      >
>      > "3970 boundary"
>      > Time millisecondsToRun: [10000 timesRepeat: [1 to: 8281 by: 8 do:
>     [:x |x
>      > isPrimeFast]]].  5257
>      >
>      > "8281 boundary"
>      > Time millisecondsToRun: [10000 timesRepeat: [1 to: 8281 by: 8 do:
>     [:x |x
>      > isPrimeFast2]]]. 4104
>      >
>      > El sáb., 12 oct. 2019 a las 0:02, Andres Valloud via Cuis-dev
>      > (<cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>
>     <mailto:cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>>>)
>     escribió:
>      >
>      >     I think this happened because we are measuring against
>     different number
>      >     sets so we ended up tuning to our tests.  By the way, I'm
>     having some
>      >     trouble getting reliable times, the figures seem to change by
>     ~10%
>      >     without any obvious reason.  For instance, for the last code
>     you sent,
>      >     running that through some of the tests here results in times
>     ranging
>      >     from 2272 to 2510 milliseconds --- and that's starting from a
>     clean
>      >     system after a GC, so each run starts in the same
>     conditions.  That's a
>      >     lot of difference for a computer that should be roughly stable...
>      >
>      >     Would you mind checking the numbers you get with the attached
>     method?
>      >     It just takes your latest code and increases the boundary for
>     the small
>      >     number loop to 8281.  Here's why I'd like to see what happens
>     for you:
>      >
>      >     "your latest"
>      >     Time millisecondsToRun: [10000 timesRepeat: [1 to: 8281 by: 8
>     do: [:x |
>      >     x isPrimeFast1c]]] 1647
>      >
>      >     "attached here"
>      >     Time millisecondsToRun: [10000 timesRepeat: [1 to: 8281 by: 8
>     do: [:x |
>      >     x isPrimeFast1d]]] 1565
>      >
>      >     Andres.
>      >
>      >     On 10/11/19 10:59, Agustín Sansone via Cuis-dev wrote:
>      >      > Latest code you sent:
>      >      > Time millisecondsToRun:
>      >      >         [1 to: 10000000 do: [:e | e isPrimeFast]].  16025
>      >      >
>      >      > Latest code I sent:
>      >      > Time millisecondsToRun:
>      >      >         [1 to: 10000000 do: [:e | e isPrimeFast]].  14435
>      >      >
>      >      >
>      >      > El vie., 11 oct. 2019 a las 2:09, Andres Valloud via Cuis-dev
>      >      > (<cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>
>     <mailto:cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>>
>      >     <mailto:cuis-dev at lists.cuis.st
>     <mailto:cuis-dev at lists.cuis.st> <mailto:cuis-dev at lists.cuis.st
>     <mailto:cuis-dev at lists.cuis.st>>>>)
>      >     escribió:
>      >      >
>      >      >     Euclid's gcd algorithm converges to the answer
>     exponentially
>      >     with base
>      >      >     phi.  Larger small integers help amortize the extra cost.
>      >      >
>      >      >     On 10/10/19 21:53, Phil B wrote:
>      >      >      > Was that primarily due to the 64-bit version mostly
>      >     fitting within
>      >      >      > SmallInteger?  I find many numeric performance
>     issues just
>      >     melt
>      >      >     away by
>      >      >      > staying away from Large*Integer (and Fraction)...
>     they're
>      >     great for
>      >      >      > maintaining accuracy, lousy for performance.  As in
>      >     multiples to
>      >      >     orders
>      >      >      > of magnitude worse depending on what you're doing.
>      >      >      >
>      >      >      > On Fri, Oct 11, 2019 at 12:40 AM Andres Valloud via
>     Cuis-dev
>      >      >      > <cuis-dev at lists.cuis.st
>     <mailto:cuis-dev at lists.cuis.st> <mailto:cuis-dev at lists.cuis.st
>     <mailto:cuis-dev at lists.cuis.st>>
>      >     <mailto:cuis-dev at lists.cuis.st
>     <mailto:cuis-dev at lists.cuis.st> <mailto:cuis-dev at lists.cuis.st
>     <mailto:cuis-dev at lists.cuis.st>>>
>      >      >     <mailto:cuis-dev at lists.cuis.st
>     <mailto:cuis-dev at lists.cuis.st>
>      >     <mailto:cuis-dev at lists.cuis.st
>     <mailto:cuis-dev at lists.cuis.st>> <mailto:cuis-dev at lists.cuis.st
>     <mailto:cuis-dev at lists.cuis.st>
>      >     <mailto:cuis-dev at lists.cuis.st
>     <mailto:cuis-dev at lists.cuis.st>>>>> wrote:
>      >      >      >
>      >      >      >     Fascinating --- the gcd approach was pretty bad
>     in 32
>      >     bit land.
>      >      >      >     However, in 64 bits, the gcd batches are large
>     enough to
>      >      >     amortize the
>      >      >      >     cost, and that detects most composites without
>     sending
>      >      >     sqrtFloor.  The
>      >      >      >     small integer threshold is now 91 squared.
>      >      >      >
>      >      >      >     On 10/10/19 20:37, Agustín Sansone via Cuis-dev
>     wrote:
>      >      >      >      >     Well, what do you think?  Are we done going
>      >     over this poor
>      >      >      >     method?
>      >      >      >      >
>      >      >      >      >
>      >      >      >      > Okay, I'm happy with this version.
>      >      >      >      >
>      >      >      >     --
>      >      >      >     Cuis-dev mailing list
>      >      >      > Cuis-dev at lists.cuis.st
>     <mailto:Cuis-dev at lists.cuis.st> <mailto:Cuis-dev at lists.cuis.st
>     <mailto:Cuis-dev at lists.cuis.st>>
>      >     <mailto:Cuis-dev at lists.cuis.st
>     <mailto:Cuis-dev at lists.cuis.st> <mailto:Cuis-dev at lists.cuis.st
>     <mailto:Cuis-dev at lists.cuis.st>>>
>      >      >     <mailto:Cuis-dev at lists.cuis.st
>     <mailto:Cuis-dev at lists.cuis.st>
>      >     <mailto:Cuis-dev at lists.cuis.st
>     <mailto:Cuis-dev at lists.cuis.st>> <mailto:Cuis-dev at lists.cuis.st
>     <mailto:Cuis-dev at lists.cuis.st>
>      >     <mailto:Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>>>>
>      >      >      > https://lists.cuis.st/mailman/listinfo/cuis-dev
>      >      >      >
>      >      >     --
>      >      >     Cuis-dev mailing list
>      >      > Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>     <mailto:Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>>
>      >     <mailto:Cuis-dev at lists.cuis.st
>     <mailto:Cuis-dev at lists.cuis.st> <mailto:Cuis-dev at lists.cuis.st
>     <mailto:Cuis-dev at lists.cuis.st>>>
>      >      > https://lists.cuis.st/mailman/listinfo/cuis-dev
>      >      >
>      >      >
>      >     --
>      >     Cuis-dev mailing list
>      > Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>     <mailto:Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>>
>      > https://lists.cuis.st/mailman/listinfo/cuis-dev
>      >
>      >
>     -- 
>     Cuis-dev mailing list
>     Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>     https://lists.cuis.st/mailman/listinfo/cuis-dev
> 
>