I am also interested in this problem, because many of my colleagues use Python
and "isn't Python faster?" is a common argument. (Albeit one that I think is
more of a rationalisation than an reason.)
In this case, however, I would not have thought that there's any prima facie
reason why the Python version should be faster, even compared to the "filter
and map" Racket version.
Indeed, I would have thought that the calculation time would be entirely
dominated by the test for primality, and especially what happens once the
candidate primes are bigger than 2^64 and can no longer be represented by a
single word.
(One possible explanation might be that the Racket math library is written in
Typed Racket; when calling it from untyped Racket, there is some type checking
using contracts -- it's possible, I suppose, that this is causing a performance
penalty.)
I am going to investigate but if anyone knows more than me I'd appreciate
thoughts.
Regards,
James
> On 11 Jul 2019, at 02:36, Bob Heffernan <bob.heffer...@gmail.com> wrote:
>
> On 19-07-10 02:46, Maciek Godek wrote:
>> A while ago, I wrote a booklet which used almost the same problem to
>> introduce to, what you called nicely in the title of this thread, "thinking
>> in Scheme", so if you're interested, you may want to check out the first
>> chapter ("Introduction"):
>
> Maciek,
>
> Thank you for your reply.
>
> I skimmed through your booklet some time ago. (I too dislike the R
> language, although some attempts have been made in recent years to make
> it less awful). I read through the introduction again this morning and
> enjoyed it.
>
> The reason I like racket (and scheme-like languages in general) is that
> they encourage the style of programming you are advocating (I think)
> where the program is expressive and can be read and appreciated by
> humans. In theory, my favourite style of programming is one that is
> elegant and readable by humans.
>
> My original email had to do with the problem of when this comes into
> conflict with a prosaic computational task where my main aim is simply
> to get the job done efficiently and my brain defaults to writing the
> program in something like C.
>
> For instance, another way of writing something like my original program
> might be something like:
>
> (define (f n) (- (expt 2 n) 3))
> (define (good? n) (and (positive? n) (prime? n)))
> (length (filter good? (map f (range 1 100))))
>
> which is, I think, fairly expressive. It is still, however, relatively
> inefficient. A python programmer might write something like
>
> count = 0
> for n in range(1, 1000):
> if 2 ** n - 3 >= 0 and isprime(2 ** n - 3):
> count += 1
>
> print(count)
>
> and happily report that her program ran quite a bit faster than mine.
>
> I'm not sure how I'd advocate for Racket (or scheme) in a situation like this.
>
> Regards,
> Bob
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/20190711013633.nm2jlznhzwibhsli%40bob-cit.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/627E56DD-D629-48D8-BF65-714D1F906AFE%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
