Re: [racket-users] racket users fight for their right to colon keywords

[Jay McCarthy]

On Thu, Oct 22, 2015 at 1:49 PM, Leif Andersen 
wrote:

> > I am genuinely surprised :keyword saw so much support and that change
> was so attractive to people.
>
> That's because of the questions you asked. I saw those questions and said
> to myself: "Self, I don't care enough about this debate enough to even
> really fill out these questions." (Although if you had a spot on the pull
> for the question: "I don't care about this at all, just don't break my
> code", I would have filled that out.)
>

I'm interested in your elaboration. I expected someone with your opinion to
vote something like 5/5/0 because you don't care between the two, but don't
want a change.

Jay


>
>
>
> ~Leif Andersen
>
> On Thu, Oct 22, 2015 at 1:43 PM, Jay McCarthy 
> wrote:
>
>> It has been a little more than a week and we've stopped getting results.
>>
>> The full results should be publicly available. Here is a summary:
>>
>>
>> https://docs.google.com/forms/d/1HSwtxLhz5HWGMJjMXaO8LQyHJsdMkGbBlRa4fU7Sa34/viewanalytics
>>
>> and here is the raw data:
>>
>>
>> https://docs.google.com/spreadsheets/d/1rZNNGwupMZTybxKRhukLdgA8VIA8oPlQ7nPk8Gv52Es/edit#gid=348615477
>>
>> My interpretation of the data is as follows:
>>
>> - The #:keyword syntax is liked fine with a rating of 5.67
>> - The :keyword syntax is more loved with a rating of 6.9
>> - But change is not popular, average of 5.1 with high standard deviation
>> - People that really like #:keyword do not want a change and do not like
>> :keyword
>> - People that really like :keyword want a change
>>
>> I am genuinely surprised :keyword saw so much support and that change was
>> so attractive to people.
>>
>> Naturally whenever you do stuff like this, you want to ask more
>> questions, like what about keyword:, what about supporting both, etc.
>>
>> Jay
>>
>>
>> On Wed, Oct 14, 2015 at 11:50 AM, Neil Van Dyke 
>> wrote:
>>
>>> We are conducting a highly scientific poll.
>>>
>>> The question we want to answer is whether people would like for the
>>> Racket standard languages to have symbols that begin with the colon
>>> character (except for the symbol `:`) to read the same has keywords that
>>> begin with pound-colon.
>>>
>>> That is, when this glorious colon-keywords support is added, instead of
>>> having to type and look at:
>>>
>>> (foo #:abc 1 #:xyx 42)
>>>
>>> you can choose to bask in the beauty of:
>>>
>>> (foo :abc 1 :xyx 42)
>>>
>>> Then you would be free to use the gorgeous colon-keywords everywhere in
>>> Racket, including in quick one-line examples in email list posts.
>>>
>>> All people of great aesthetic sense, intellect, and good moral fiber,
>>> who would naturally like everyone to have the right to use either
>>> colon-keywords or (eww) pound-colon keywords (in unity, and without
>>> unnecessary `#lang` schisms!), should answer the quick poll:
>>>
>>> http://goo.gl/forms/Kwl3uZVMsb
>>>
>>> (When the poll question asks "Is it worth changing?", read it is as "You
>>> are a good person, and you naturally think Racket should support both
>>> colon-keywords and pound-colon keywords, right?")
>>>
>>> I call upon all freedom-loving Racketeers to stand up and fight for the
>>> righteous cause of colon-keywords.  The moment to answer this highly
>>> scientific poll is now.
>>>
>>> Neil V.
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> Jay McCarthy
>> Associate Professor
>> PLT @ CS @ UMass Lowell
>> http://jeapostrophe.github.io
>>
>>"Wherefore, be not weary in well-doing,
>>   for ye are laying the foundation of a great work.
>> And out of small things proceedeth that which is great."
>>   - D 64:33
>>
>> --
>> 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.
>>
>
>


-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

   "Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
  - D 64:33

-- 
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] Sundials FFI wrapper

[Alexey Cherkaev]

Hi all,

 

I am interested in creating the Racket wrapping for the Sundials numeric
library (http://computation.llnl.gov/casc/sundials/main.html). Ivan Raikov
did a similar job for Chicken (http://wiki.call-cc.org/eggref/4/sundials).
Chicken has quite a different way of dealing with C code compared to Racket,
and the wrapper code includes lots of C wrappers prior creating Scheme
wrappers.

 

Is there anybody who has done something similar in Racket for other C
libraries? And who will be interested in creating the wrapper for Sundials?
(PS. I don't feel my expertise are up to scratch to tackle it on my own.)

 

Regards,

Alexey

 

-- 
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: racket users fight for their right to colon keywords

[Pierpaolo Bernardi]

On Thu, Oct 22, 2015 at 8:09 PM, Andrew Gwozdziewycz  wrote:

> Surely there are books about this subject. Does anyone have any
> recommendations for future self?

This course has a module on voting theory:
https://www.coursera.org/course/mathphil

The course is not heavy-handed and can be taken even by people with a
busy schedule.

-- 
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] Re: racket users fight for their right to colon keywords

[Jack Firth]

Perhaps it would have been better phrased as "Which do you prefer, #:keyword or 
:keyword?" with options like "strongly prefer x", "prefer x", "indifferent", 
"prefer y", "strongly prefer y", rather than two different 1-10 scales.

-- 
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] racket users fight for their right to colon keywords

[Leif Andersen]

So, I thought about doing that. Except that I ended up not, because voting
5/5/0 doesn't properly capture my feelings.

5/5/0 seems more like a, I see pros and cons with both sides, but I
fundamentally care some way or the other which way this goes.

My opinion really is that this is a silly issue, and doesn't really matter
that much to me at all. And thus I don't really care either way. I would
vote on the 0 for the last question, (just because meh, I don't care one
way or the other), but I really didn't fit anywhere on the spectrum for the
first two boxes.

Does that clarify my opinion a bit?


~Leif Andersen

On Thu, Oct 22, 2015 at 1:53 PM, Jay McCarthy 
wrote:

> On Thu, Oct 22, 2015 at 1:49 PM, Leif Andersen 
> wrote:
>
>> > I am genuinely surprised :keyword saw so much support and that change
>> was so attractive to people.
>>
>> That's because of the questions you asked. I saw those questions and said
>> to myself: "Self, I don't care enough about this debate enough to even
>> really fill out these questions." (Although if you had a spot on the pull
>> for the question: "I don't care about this at all, just don't break my
>> code", I would have filled that out.)
>>
>
> I'm interested in your elaboration. I expected someone with your opinion
> to vote something like 5/5/0 because you don't care between the two, but
> don't want a change.
>
> Jay
>
>
>>
>>
>>
>> ~Leif Andersen
>>
>> On Thu, Oct 22, 2015 at 1:43 PM, Jay McCarthy 
>> wrote:
>>
>>> It has been a little more than a week and we've stopped getting results.
>>>
>>> The full results should be publicly available. Here is a summary:
>>>
>>>
>>> https://docs.google.com/forms/d/1HSwtxLhz5HWGMJjMXaO8LQyHJsdMkGbBlRa4fU7Sa34/viewanalytics
>>>
>>> and here is the raw data:
>>>
>>>
>>> https://docs.google.com/spreadsheets/d/1rZNNGwupMZTybxKRhukLdgA8VIA8oPlQ7nPk8Gv52Es/edit#gid=348615477
>>>
>>> My interpretation of the data is as follows:
>>>
>>> - The #:keyword syntax is liked fine with a rating of 5.67
>>> - The :keyword syntax is more loved with a rating of 6.9
>>> - But change is not popular, average of 5.1 with high standard deviation
>>> - People that really like #:keyword do not want a change and do not like
>>> :keyword
>>> - People that really like :keyword want a change
>>>
>>> I am genuinely surprised :keyword saw so much support and that change
>>> was so attractive to people.
>>>
>>> Naturally whenever you do stuff like this, you want to ask more
>>> questions, like what about keyword:, what about supporting both, etc.
>>>
>>> Jay
>>>
>>>
>>> On Wed, Oct 14, 2015 at 11:50 AM, Neil Van Dyke 
>>> wrote:
>>>
 We are conducting a highly scientific poll.

 The question we want to answer is whether people would like for the
 Racket standard languages to have symbols that begin with the colon
 character (except for the symbol `:`) to read the same has keywords that
 begin with pound-colon.

 That is, when this glorious colon-keywords support is added, instead of
 having to type and look at:

 (foo #:abc 1 #:xyx 42)

 you can choose to bask in the beauty of:

 (foo :abc 1 :xyx 42)

 Then you would be free to use the gorgeous colon-keywords everywhere in
 Racket, including in quick one-line examples in email list posts.

 All people of great aesthetic sense, intellect, and good moral fiber,
 who would naturally like everyone to have the right to use either
 colon-keywords or (eww) pound-colon keywords (in unity, and without
 unnecessary `#lang` schisms!), should answer the quick poll:

 http://goo.gl/forms/Kwl3uZVMsb

 (When the poll question asks "Is it worth changing?", read it is as
 "You are a good person, and you naturally think Racket should support both
 colon-keywords and pound-colon keywords, right?")

 I call upon all freedom-loving Racketeers to stand up and fight for the
 righteous cause of colon-keywords.  The moment to answer this highly
 scientific poll is now.

 Neil V.

 --
 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.

>>>
>>>
>>>
>>> --
>>> Jay McCarthy
>>> Associate Professor
>>> PLT @ CS @ UMass Lowell
>>> http://jeapostrophe.github.io
>>>
>>>"Wherefore, be not weary in well-doing,
>>>   for ye are laying the foundation of a great work.
>>> And out of small things proceedeth that which is great."
>>>   - D 64:33
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Racket Users" group.
>>> To unsubscribe from this group and stop receiving 

Re: [racket-users] racket users fight for their right to colon keywords

[Andrew Gwozdziewycz]

On Thu, Oct 22, 2015 at 10:53 AM, Jay McCarthy 
wrote:

> On Thu, Oct 22, 2015 at 1:49 PM, Leif Andersen 
> wrote:
>
> > I am genuinely surprised :keyword saw so much support and that change
>> was so attractive to people.
>>
>> That's because of the questions you asked. I saw those questions and said
>> to myself: "Self, I don't care enough about this debate enough to even
>> really fill out these questions." (Although if you had a spot on the pull
>> for the question: "I don't care about this at all, just don't break my
>> code", I would have filled that out.)
>>
>
> I'm interested in your elaboration. I expected someone with your opinion
> to vote something like 5/5/0 because you don't care between the two, but
> don't want a change.
>

Interestingly, a 5 is slightly more negative of 'neutral' in your model of
1-10, than 6, which would be slightly more positive than 'neutral'. I
wonder how many people picked 5 to be completely neutral, not realizing
this subtlety. I guess, the question for me comes down to, "is the volume
in question 1 more towards hate?" Or, assuming that some portion of '5's
recognized the subtlety and were slightly negative of 'neutral', and the
others truly meant 'neutral', it's a dead heat.

(shrug)

-- 
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] racket users fight for their right to colon keywords

[Leif Andersen]

> I am genuinely surprised :keyword saw so much support and that change was
so attractive to people.

That's because of the questions you asked. I saw those questions and said
to myself: "Self, I don't care enough about this debate enough to even
really fill out these questions." (Although if you had a spot on the pull
for the question: "I don't care about this at all, just don't break my
code", I would have filled that out.)


~Leif Andersen

On Thu, Oct 22, 2015 at 1:43 PM, Jay McCarthy 
wrote:

> It has been a little more than a week and we've stopped getting results.
>
> The full results should be publicly available. Here is a summary:
>
>
> https://docs.google.com/forms/d/1HSwtxLhz5HWGMJjMXaO8LQyHJsdMkGbBlRa4fU7Sa34/viewanalytics
>
> and here is the raw data:
>
>
> https://docs.google.com/spreadsheets/d/1rZNNGwupMZTybxKRhukLdgA8VIA8oPlQ7nPk8Gv52Es/edit#gid=348615477
>
> My interpretation of the data is as follows:
>
> - The #:keyword syntax is liked fine with a rating of 5.67
> - The :keyword syntax is more loved with a rating of 6.9
> - But change is not popular, average of 5.1 with high standard deviation
> - People that really like #:keyword do not want a change and do not like
> :keyword
> - People that really like :keyword want a change
>
> I am genuinely surprised :keyword saw so much support and that change was
> so attractive to people.
>
> Naturally whenever you do stuff like this, you want to ask more questions,
> like what about keyword:, what about supporting both, etc.
>
> Jay
>
>
> On Wed, Oct 14, 2015 at 11:50 AM, Neil Van Dyke 
> wrote:
>
>> We are conducting a highly scientific poll.
>>
>> The question we want to answer is whether people would like for the
>> Racket standard languages to have symbols that begin with the colon
>> character (except for the symbol `:`) to read the same has keywords that
>> begin with pound-colon.
>>
>> That is, when this glorious colon-keywords support is added, instead of
>> having to type and look at:
>>
>> (foo #:abc 1 #:xyx 42)
>>
>> you can choose to bask in the beauty of:
>>
>> (foo :abc 1 :xyx 42)
>>
>> Then you would be free to use the gorgeous colon-keywords everywhere in
>> Racket, including in quick one-line examples in email list posts.
>>
>> All people of great aesthetic sense, intellect, and good moral fiber, who
>> would naturally like everyone to have the right to use either
>> colon-keywords or (eww) pound-colon keywords (in unity, and without
>> unnecessary `#lang` schisms!), should answer the quick poll:
>>
>> http://goo.gl/forms/Kwl3uZVMsb
>>
>> (When the poll question asks "Is it worth changing?", read it is as "You
>> are a good person, and you naturally think Racket should support both
>> colon-keywords and pound-colon keywords, right?")
>>
>> I call upon all freedom-loving Racketeers to stand up and fight for the
>> righteous cause of colon-keywords.  The moment to answer this highly
>> scientific poll is now.
>>
>> Neil V.
>>
>> --
>> 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.
>>
>
>
>
> --
> Jay McCarthy
> Associate Professor
> PLT @ CS @ UMass Lowell
> http://jeapostrophe.github.io
>
>"Wherefore, be not weary in well-doing,
>   for ye are laying the foundation of a great work.
> And out of small things proceedeth that which is great."
>   - D 64:33
>
> --
> 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: [racket-users] Re: racket users fight for their right to colon keywords

[Andrew Gwozdziewycz]

On Thu, Oct 22, 2015 at 11:01 AM, Jack Firth  wrote:

> Perhaps it would have been better phrased as "Which do you prefer,
> #:keyword or :keyword?" with options like "strongly prefer x", "prefer x",
> "indifferent", "prefer y", "strongly prefer y", rather than two different
> 1-10 scales.
>

While I agree that this might have been better, I've never, prepared a
survey before where the questions were perfect, and I didn't think of some
optimization *after the fact* about how to phrase them better, or get
better data.

Surely there are books about this subject. Does anyone have any
recommendations for future self?


>
> --
> 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.
>



-- 
http://www.apgwoz.com

-- 
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] Second Call for Contributions: BOB 2016 - Berlin, Feb 19, 2016 (Deadline: Oct 30)

[Michael Sperber]

Racket contributions very welcome at BOB!

 BOB Conference 2016
 "What happens when we use what's best for a change?"
  http://bobkonf.de/2016/en/cfp.html
 Berlin, February 19
Call for Contributions
  Deadline: October 30, 2015

You drive advanced software engineering methods, implement ambitious
architectures and are open to cutting-edge innovation? Attend this
conference, meet people that share your goals, and get to know the
best software tools and technologies available today. We strive to
offer a day full of new experiences and impressions that you can
use to immediately improve your daily life as a software developer.

If you share our vision and want to contribute, submit a proposal for
a talk or tutorial!

Topics
--

We are looking for talks about best-of-breed software technology,
e.g.:

- functional programming
- reactive programming
- persistent data structures and databases
- types
- formal methods for correctness and robustness
- ... everything really that isn't mainstream, but you think should be.

Presenters should provide the audience with information that is
practically useful for software developers.  This could take the form
of e.g.:

- experience reports
- introductory talks on technical background
- demos and how-tos

Requirements


We accept proposals for presentations of 45 minutes (40 minutes talk +
5 minutes questions), as well as 90 minute tutorials for beginners.
The language of presentation should be either English or German. 

Your proposal should include (in your presentation language of choice):

- an abstract of max. 1500 characters.
- a short bio/cv
- contact information (including at least email address)
- a list of 3-5 concrete ideas of how your work can be applied in a developer's 
daily life
- additional material (websites, blogs, slides, videos of past
  presentations, ...)

Submit here:

https://docs.google.com/forms/d/1IrCa3ilxMrO2h1G1WC4ywoxdz8wohxaPW3dfiB0cq-8/viewform?usp=send_form

Organisation


- submit your proposal here
  
https://docs.google.com/forms/d/1IrCa3ilxMrO2h1G1WC4ywoxdz8wohxaPW3dfiB0cq-8/viewform?usp=send_form
- direct questions to `bobkonf at active minus group dot de`
- proposal deadline: **October 30, 2015**
- notification: November 15, 2015
- program: December 1, 2015

NOTE: The conference fee will be waived for presenters, but travel
  expenses will not be covered.

Speaker Grants
--

BOB has Speaker Grants available to support speakers from groups
under-represented in technology.  We specifically seek women speakers
and speakers who not be able to attend the conference for financial
reasons.  Details are here:

http://bobkonf.de/2016/en/speaker-grants.html

Shepherding
---

The program committee offers shepherding to all speakers.  Shepherding
provides speakers assistance with preparing their sessions, as well as
a review of the talk slides.

Program Committee
-

(more information here: http://bobkonf.de/2016/programmkomitee.html)

- Matthias Fischmann, zerobuzz UG
- Matthias Neubauer, SICK AG
- Nicole Rauch, Softwareentwicklung und Entwicklungscoaching
- Michael Sperber, Active Group
- Stefan Wehr, factis research

Scientific Advisory Board
-

- Annette Bieniusa, TU Kaiserslautern
- Peter Thiemann, Uni Freiburg


-- 
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: Probabilities in log-space and rounding errors

[Laurent]

On Wed, Oct 21, 2015 at 11:24 PM, Paolo Giarrusso 
wrote:

> On 20 October 2015 at 16:44, Laurent  wrote:
> > Thanks Paolo, yes, I saw that indeed and it is most likely relevant. I
> was
> > hoping my problem would be sufficiently more specific; in particular, I'd
> > like to detect whether the value being above 0 is likely a rounding error
> > (in which case I can just round it down to 0 again) or likely a mistake
> on
> > my part in my equations or in their implementation.
>
> I'm sorry, but your dichotomy seems a fallacy. Rounding errors are the
> rule in floating point, and you need to account for them, otherwise
> you have a bug, as every introduction to numerical analysis should
> teach.
>

Thanks for your detailed explanation, Paolo. (I do use lgsum, lg1+, lg1-,
etc. wherever I can, and try to rearrange my formulas to avoid worst cases,
but I could probably use a bit more of error propagation analysis.)

Maybe I forgot a piece of information though: I'm fine with getting
sub-probabilities as the result of floating point errors, i.e. numbers that
should sum to 1 (in normal space) but where the sum is actually 0.8 for
example. That's bad but for my purposes it's not too bad. However, I'm
/not/ fine with super-probabilities. For what I do, ending with
sub-probabilities mean my results could be better if I were more careful
with my rounding errors. Super-probabilities mean I'm cheating and my
results are likely to be better than they should be.

So I was wondering if there was a way to make sure that whatever the
operations I do, those rounding errors ensure that I never end up with
super-probabilities. I was hoping that since this seems more specific than
floating point error problems in general, there may something to be done.
But maybe the former problem is just as bad as the latter.

Laurent

-- 
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] Strange garbage collection behavior with closures

[Matthew Flatt]

I can't think of a case where strongly holding values is useful.
Avoiding a layer of ephemerons is less work for the GC, and so
`make-weak-hash` omits it to provide better performance for cases that
don't need it. I'm not sure how much of a space and performance
difference it makes in modern Racket, though; ephemeron performance is
much better than it was originally. So, it could be worth taking
measurements and revisiting that choice.

Meanwhile, the reference docs for `make-weak-hash` should be more
helpful, and I'll adjust the docs.

At Wed, 21 Oct 2015 22:03:09 -0400, Scott Moore wrote:
> Thanks for the quick response!
> 
> Now that I’m past that, I see that my problem is probably due to the fact 
> that 
> a weak-hash holds its key strongly. Turns out this is well-documented in the 
> guide, but I missed it since I was reading the reference.
> 
> I’m curious, is there a particular use case for the fact that a weak-hash 
> doesn’t act more like a collection of ephemerons? The guide notes that the 
> strong reference to the value "creates a catch-22 dependency when a value 
> refers back to its key, so that the mapping is retained permanently.” But 
> worse than that, the cycle can be through a second mapping:
> 
> > (define ht (make-weak-hasheq))
> > (let ([a (gensym)]
> >       [b (gensym)])
> >   (hash-set! ht a b)
> >   (hash-set! ht b a))
> > (collect-garbage)
> > (hash-count ht)
> 2
> On October 21, 2015 at 9:19:05 PM, Matthew Flatt (mfl...@cs.utah.edu) wrote:
> 
> An empty closure is allocated as a constant --- similar to a literal  
> string or literal fraction in your program. The "closure" will stick  
> around as long as the code does, and the code will stick around as the  
> namespace where its loaded.  
> 
> If you change `(λ () 0`) to `(λ () (if box 0 'huh?))`, then you end up  
> with a non-empty closure (i.e., allocated at run time) due to the  
> reference to `box`, and so you get `#f` at the end as you expect.  
> 
> I don't know why PasteRack produces #f, but it must not hold onto the  
> namespace.  
> 
> At Wed, 21 Oct 2015 21:07:52 -0400, Scott Moore wrote:  
> > I’m trying to do something a bit fancy that makes use of weak-hashes, but 
> I’ve  
> > run into strange behavior (things not being removed that I believe should 
> be)  
> > when I use keys that are closures. Doing some of my own debugging, this  
> > doesn’t appear specific to weak hashes, but also to weak boxes. Here is a  
> > short example (based on the example programs in section 19.11 of  
> > http://docs.racket-lang.org/guide/performance.html):  
> >  
> > #lang racket  
> >  
> > (struct foo ())  
> >  
> > (define box #f)  
> >  
> > (let ([f (foo)])  
> >   (set! box (make-weak-box f))  
> >   (weak-box-value box))  
> > (weak-box-value box)  
> > (collect-garbage)  
> > (weak-box-value box)  
> >  
> > (let ([f (λ () 0)])  
> >   (set! box (make-weak-box f))  
> >   (weak-box-value box))  
> > (weak-box-value box)  
> > (collect-garbage)  
> > (weak-box-value box)  
> >  
> > I expect the output of this program to be:  
> >  
> > #  
> > #  
> > #f  
> > #  
> > #  
> > #f  
> >  
> > Curiously, I do get this answer if I paste the program to pasterack.org. If 
> >  
> > instead I run the program in DrRacket, or at the command line (both 
> compiled  
> > and not compiled), I get this output:  
> >  
> > #  
> > #  
> > #f  
> > #  
> > #  
> > #  
> >  
> > Any idea what is happening here? As far as I can tell, the reachability of 
> “f”  
> > in both code blocks should be identical, despite the difference in the type 
> of  
> > value. Maybe some sort of compiler transformation or a subtlety in the  
> > reachability analysis? Or a bug?  
> >  
> > Thanks,  
> > Scott  
> >  
> > --  
> > 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.  
> 
> -- 
> 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: [racket-users] Strange garbage collection behavior with closures

[Stephen Chang]

pasterack uses make-module-evaluator in a sandbox. It's also still
running 6.1.1. Would either of those cause the observed difference?

On Wed, Oct 21, 2015 at 9:18 PM, Matthew Flatt  wrote:
> An empty closure is allocated as a constant --- similar to a literal
> string or literal fraction in your program. The "closure" will stick
> around as long as the code does, and the code will stick around as the
> namespace where its loaded.
>
> If you change `(λ () 0`) to `(λ () (if box 0 'huh?))`, then you end up
> with a non-empty closure (i.e., allocated at run time) due to the
> reference to `box`, and so you get `#f` at the end as you expect.
>
> I don't know why PasteRack produces #f, but it must not hold onto the
> namespace.
>
> At Wed, 21 Oct 2015 21:07:52 -0400, Scott Moore wrote:
>> I’m trying to do something a bit fancy that makes use of weak-hashes, but 
>> I’ve
>> run into strange behavior (things not being removed that I believe should be)
>> when I use keys that are closures. Doing some of my own debugging, this
>> doesn’t appear specific to weak hashes, but also to weak boxes. Here is a
>> short example (based on the example programs in section 19.11 of
>> http://docs.racket-lang.org/guide/performance.html):
>>
>> #lang racket
>>
>> (struct foo ())
>>
>> (define box #f)
>>
>> (let ([f (foo)])
>>   (set! box (make-weak-box f))
>>   (weak-box-value box))
>> (weak-box-value box)
>> (collect-garbage)
>> (weak-box-value box)
>>
>> (let ([f (λ () 0)])
>>   (set! box (make-weak-box f))
>>   (weak-box-value box))
>> (weak-box-value box)
>> (collect-garbage)
>> (weak-box-value box)
>>
>> I expect the output of this program to be:
>>
>> #
>> #
>> #f
>> #
>> #
>> #f
>>
>> Curiously, I do get this answer if I paste the program to pasterack.org. If
>> instead I run the program in DrRacket, or at the command line (both compiled
>> and not compiled), I get this output:
>>
>> #
>> #
>> #f
>> #
>> #
>> #
>>
>> Any idea what is happening here? As far as I can tell, the reachability of 
>> “f”
>> in both code blocks should be identical, despite the difference in the type 
>> of
>> value. Maybe some sort of compiler transformation or a subtlety in the
>> reachability analysis? Or a bug?
>>
>> Thanks,
>> Scott
>>
>> --
>> 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.

-- 
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] Probabilities in log-space and rounding errors

[Alex Knauth]

lg+ and lg- are defined to work with log and exp, but I'm just wondering if 
versions of those defined to work with log1p and expm1 would eliminate some of 
these errors, by getting rid of the badlands of log and exp? Would that work?

http://docs.racket-lang.org/math/flonum.html#%28def._%28%28lib._math%2Fflonum..rkt%29._fllog1p%29%29
 



> On Oct 20, 2015, at 9:24 AM, Paolo Giarrusso  wrote:
> 
> On Tuesday, October 20, 2015 at 12:15:21 PM UTC+2, Laurent Orseau wrote:
>> The built-in log-space arithmetic operations are wonderful. (Thanks so much 
>> Neil!)
>> 
>> It sometimes happens that after some log-operations where the result is very 
>> close to 0 that it actually goes slightly above 0 as a result of floating 
>> point errors, and thus is not a log-probability anymore, which gave me a few 
>> headaches.
>> 
>> One obvious approach is to surround the result with a check, and if it is 
>> positive but not, say, above 1e-8 then round it down to 0, otherwise raise 
>> an exception if positive.
>> 
>> But this feels like a hack and I was wondering if there was any "good" way 
>> to ensure that any correct log-space operation remains a log-probability  
>> (i.e., never goes above 0).
>> 
>> Thanks,
>> Laurent
> 
> If lg+ is involved, this discussion in the docs seems relevant — apologies if 
> you've seen that already:
> http://docs.racket-lang.org/math/flonum.html#%28def._%28%28lib._math%2Fflonum..rkt%29._lg-%29%29
>  ?
> 
> After explaining that a good solution is an open research problem, docs state:
>> Further, catastrophic cancellation is unavoidable when logx and logy 
>> themselves have error, which is by far the common case. [...] There are 
>> currently no reasonably fast algorithms for computing lg+ and lg- with low 
>> relative error. For now, if you need that kind of accuracy, use 
>> math/bigfloat.
> 
> Disclaimer: not an expert here, might well be missing something.
> 
> -- 
> 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.