Re: [racket-users] Are fixnums guaranteed to be `eq?` whenever they are `=`/`equal?` ?

[Matthew Flatt]

At Mon, 14 Mar 2016 19:59:51 -0400, Tony Garnock-Jones wrote:
> On 03/14/2016 07:53 PM, Matthew Flatt wrote:
> > [fixnum eqness is guaranteed by the docs.
> > [...] And keywords [are also guaranteed].
> > [...] [And] Booleans, void, and characters with a scalar value under 256.
> > 
> > Opaque objects like custodians and inspectors are also `equal?` only
> > when they are `eq?`, but I'm not sure if that's the kind of thing
> > you're looking for.
> 
> Great, thank you.
> 
> I am building up a list of things safe-to-use-eq? on because I want to
> sometimes skip expensive hashconsing-by-equal?. If I know that eq? is
> already the right predicate, then the value is effectively already
> hashconsed.
> 
> If there were a predicate `eq-applicable?` (or something), I could skip
> using a hand-coded list of special cases, and could systematically avoid
> the expense of hashconsing for a wider range of values.
> 
> Any thoughts on the possibility of such a predicate existing in Racket? :-)

That sounds like a good addition. I'll put it on my list.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Are fixnums guaranteed to be `eq?` whenever they are `=`/`equal?` ?

[Matthew Flatt]

At Mon, 14 Mar 2016 19:43:51 -0400, Tony Garnock-Jones wrote:
> Can I rely on the truth of the following:
> 
>   (implies (and (fixnum? x) (fixnum? y) (= x y))
>(eq? x y))
> 
> ?

Yes, that's guaranteed by the docs.


> I know I can rely on something similar for symbols.

And keywords.


> What other sorts of values can I rely on eq? being an appropriate
> equivalence predicate for?

Booleans, void, and characters with a scalar value under 256.

Opaque objects like custodians and inspectors are also `equal?` only
when they are `eq?`, but I'm not sure if that's the kind of thing
you're looking for.

Literal numbers, characters, strings, byte strings, or regular
expressions in a program are also `eq?` when they are `equal?`, since
they're interned. That's an property of where the values came from,
though, as opposed to a property of the kind of value.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Are fixnums guaranteed to be `eq?` whenever they are `=`/`equal?` ?

[Tony Garnock-Jones]

Hi all,

Can I rely on the truth of the following:

  (implies (and (fixnum? x) (fixnum? y) (= x y))
   (eq? x y))

?

I know I can rely on something similar for symbols.

What other sorts of values can I rely on eq? being an appropriate
equivalence predicate for?

Tony

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] custom input ports

[Jon Zeppieri]

Almost every time I've created a custom input port, I've run up against the
rule: "The read-in procedure must not block indefinitely." And each time,
I've either:

- ignored it (with the suspicion that I've just written code that can block
the whole process, though I've never actually verified this);
- written a state machine that buffers data from the underlying port until
it has enough to work with; or
- created a new thread that reads from the underlying port and pipes data
back.

(By the way, `filter-read-input-port` doesn't help here, since the filter
is called in the context of the above-mentioned `read-in` procedure, so,
even though the docs don't mention it, presumably it shouldn't do blocking
I/O either.)

The last of these is the least painful (if you count the psychological pain
of option 1), but it raises another problem. If the data turns out to be
malformed, I want to raise an exception. (Or, at least, I think I do.) But
I want to raise it in the reader's thread, and I don't think there's a way
to do this, short of an explicit pre-arrangement.

Has anyone else dealt with this problem (and come up with a nice solution)?
I haven't yet tried using generators. They might make it a bit easier to do
a variation on option 2, at the cost of a bunch of stack-copying.

- Jon

-- 
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.
For more options, visit https://groups.google.com/d/optout.

RE: [racket-users] Re: Sequential vs. Parallel 13-Queens program

[Jos Koot]

I have looked up a N-queens program I made a long time ago. It finds all
solutions.
My timings are faster I think. I need 2 seconds (in DrRacket) for N=12.
14200 solutions of which 1787 are not symmetrically equivalent.
If you want I send you the code privately. 83 lines.
Finding the solutions takes less lines, but after finding the solutions
an analysys of symmetries is made, requiring more lines and more time.
This allows me to report one solution only for each set of up to 8 solutions
that can be transformed into each other by symmetry operations.

It would not be difficult to parallelize the basic code such as to use up to
N processors.
I try every rank in the first file to start with.
In fact the code can be speeded up by almost a factor 2 by
trying the first (ceiling (/ N 2)) ranks only.
The solutions starting from another rank in the first file
are easily found by symmetry (reflection) for solutions that do not have
this symmetry.
These trials can be done parallelly.
Jos
 

-Original Message-
From: racket-users@googlegroups.com [mailto:racket-users@googlegroups.com]
On Behalf Of Brian Adkins
Sent: sábado, 12 de marzo de 2016 18:51
To: Racket Users
Subject: [racket-users] Re: Sequential vs. Parallel 13-Queens program

On Friday, March 11, 2016 at 9:01:38 PM UTC-5, Brian Adkins wrote:
> On Friday, March 11, 2016 at 7:42:22 PM UTC-5, Brian Adkins wrote:
> > I coded up a sequential and parallel version of N-Queens, then did a ton
of benchmark runs of 13-Queens to compare the time. For each configuration
(sequential or parallel w/ M workers), I ran the programs 6 times, threw out
the high two & low two and averaged the middle two numbers.
> > 
> > The spreadsheet with timings is here:
> > 
> >
https://docs.google.com/spreadsheets/d/1LFwdZbBveaARY_AquGXY9jgaSJlOA03NQCV9
TeYQ-l8/edit?usp=sharing
> > 
> > The code is here:
> > 
> > https://gist.github.com/lojic/aef0aec491d3dc9cb40b
> > 
> > I didn't spend any time refining/optimizing, so it's fairly crude, but
informative nonetheless.
> > 
> > The executive summary of timings for the parallel version:
> > 
> > # PlacesTime
> > 1   34.9
> > 2   19.7
> > 3   13.8
> > 4   12.3
> > 5   11.9
> > 6   12.9
> > 7   12.1
> > 8   12.2
> > 
> > The sequential version took 31.3 seconds.
> > 
> > The basic idea for the parallel version is to place the first 13
starting positions in a queue that the place workers will pull from and
produce a set of solutions with that starting position. Both the parallel
and sequential versions collect all 73,712 solutions in a list and compute
the length of it. I hardcoded the number of solutions as a quick & dirty way
of determining completion in the parallel version just to allow me to get
the timings easily.
> > 
> > It was great to finally write some Racket code that got all my cores
heated up :)
> > 
> > Brian
> 
> Interesting. My first parallel version had the workers write each
solutions (list of N queen positions) to the parent as they were computed. I
just changed the program to collect all the solutions for a given prefix
(closer to the way the sequential version works) and send that list to the
parent.
> 
> The result is a modest 4% speeedup. I had assumed that creating the extra
intermediate lists would be slower.
> 
> I thought I read something about the implementation of Places that allows
data to be moved efficiently from one Place to another via virtual memory
pages - maybe something like that is going on. Regardless, I'm happy that
the more natural algorithm (to me anyway) is also more efficient. I guess
the overhead of many place-channel-put/get calls is more expensive than the
allocation & garbage collection of the intermediate lists.
> 
> The second parallel version referred to above is here:
https://gist.github.com/lojic/957828ce7c67c0376a23

I cleaned up the code a bit (removed hardcoded completion checks, etc.) and
moved the code to a git repo:

https://github.com/lojic/LearningRacket/tree/master/miscellaneous

I was hoping to get more than a 3x speedup, but my final results show a 2.8x
speedup on 4 cores. I suppose the amount of work per solution isn't large
enough for a better speedup.

In the N=13 case that takes 11 seconds, there are 6,700 solutions per second
being sent across a place-channel with each solution being a list of 13
structs of 2 elements.

Still, 2.8x is appreciated :)

-- 
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.
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.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [racket-users] Pattern Matching in Macros | Meaning of dot

[Jens Axel Søgaard]

Yes, lambda expression have an implicit begin in the body.

> (begin . (1 2 3))
3

> (begin (1 2 3))
application: not a procedure;
expected a procedure that can be applied to arguments
given: 1
 arguments...:

Here (begin . (1 2 3)) is the same as (begin 1 2 3).

The docs for lambda are here:

http://docs.racket-lang.org/reference/lambda.html?q=lambda#%28form._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._lambda%29%29

Note the body ...+ which means 1 or more bodies are allowed.

/Jens Axel







2016-03-14 18:37 GMT+01:00 Pedro Caldeira :

> Does that mean that lambda expressions have an implicit (begin …) block
> in them?
>
> (begin ((displayln 1) (displayln 2) (displayln 3))) leads to an error
>
> (begin . ((displayln 1) (displayln 2) (displayln 3))) displays to 1 2 3
>
> Thank you for the detailed explanation I think I get it now.
>
> On 13 Mar 2016, at 19:48, Jens Axel Søgaard  wrote:
>
> If we use
>
> (define-syntax define/memoized
>   (syntax-rules ()
> ((_ (name . args) . body)
>  (define name (memoize (lambda args  body))
>
> and body is bound to((displayln x) (displayln y) (displayz))
> then
>
> (lambda args  body)
>
> will become
>
> (lambda  ((displayln x) (displayln y) (displayz)))
>
> And when this function is called you will get an error since
>
> ((displayln x) ...)
>
> means apply the result of (displayln x) to (displayln y) (displayln x).
>
> /Jens Axel
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- 
Jens Axel Søgaard

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [racket-users] Pattern Matching in Macros | Meaning of dot

[Pedro Caldeira]

Does that mean that lambda expressions have an implicit (begin …) block in them?

(begin ((displayln 1) (displayln 2) (displayln 3))) leads to an error

(begin . ((displayln 1) (displayln 2) (displayln 3))) displays to 1 2 3

Thank you for the detailed explanation I think I get it now.

> On 13 Mar 2016, at 19:48, Jens Axel Søgaard  > wrote:
> 
> If we use
> 
> (define-syntax define/memoized
>   (syntax-rules ()
> ((_ (name . args) . body)
>  (define name (memoize (lambda args  body))
> 
> and body is bound to((displayln x) (displayln y) (displayz)) 
> then
> 
> (lambda args  body)
> 
> will become
> 
> (lambda  ((displayln x) (displayln y) (displayz)))
> 
> And when this function is called you will get an error since
> 
> ((displayln x) ...) 
> 
> means apply the result of (displayln x) to (displayln y) (displayln x).
> 
> /Jens Axel

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Sequential vs. Parallel 13-Queens program

[Jerry Jackson]

This is a bit off-topic (though it is about N-queens) but I've long wanted to 
ask people if an idea I had once is a well-known one. It once occurred to me 
that solutions to N-rooks can be viewed as linear transformations that 
correspond to permutations of a vector. So, then I wondered to what sort of 
transformations solutions to N-queens correspond. I'll leave a gap in case 
anyone wants to think about it...

















Okay, N-queens solutions correspond to transformations in which no two entries 
in the permuted vector are the same distance apart as they were before. This 
leads to a simple algorithm for finding solutions. Fill a vector with the 
digits 1 to veclen, generate permutations, and see if the difference between 
any two element indices is the same as the difference between their contents. 
You can then easily reverse engineer the board.

Is this well known?

Thanks,

--Jerry Jackson

-- 
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.
For more options, visit https://groups.google.com/d/optout.