Re: [racket-users] DSL to C code generation with symbolic computations en route

['John Clements' via users-redirect]

> On Apr 19, 2016, at 3:18 PM, Hendrik Boom  wrote:
> 
> On Mon, Apr 18, 2016 at 08:04:32PM +0200, Jerzy Karczmarczuk wrote:
>> Dmitry Pavlov wants "adult" numerics in Racket, and he adds:
>> 
>>> - I need to take derivatives of equations that I wrote in my DSL,
>>> symbolically, and have them converted to C too.
>> 
>> And then, people (Robby Findler and John Clements) mentioned Siskind. Good.
>> 
>> However, you should know that Jeffrey worked NOT on /symbolic/
>> derivatives, but mainly on the "automatic differentiation" stuff;
>> this is numeric, but fast and exact (in the sense: no differential
>> quotient approximations). There is plenty of valuable papers written
>> by Jeffrey and Barak Pearlmutter... (But some are quite difficult).
> 
> I am baffled how you can do differentiation numerically and get it exact.

I think that calling it “numeric” may call to mind something that is not exact 
(e.g., choose a small dx, take two nearby values, divide the difference by dx). 
This is definitely not exact.  Automatic differentiation—and be forewarned, I’m 
going to biff some important detail or other—is instead an algorithm that 
computes the same answer as symbolic differentiation without having to take the 
extra step of actually constructing the formula. I think, however, that it is 
“morally equivalent” to symbolic differentiation.

So, for instance, suppose you’re computing 3x^2+x. This might involve 
multiplying 3 by x by x and adding x. Suppose further that x=4. Automatic 
differentiation associates with each term computation a side computation that 
represents the derivative of that term, using an inductive computation. In this 
example, we start by multiplying 3 by x. If we know that the derivative of 3 is 
0 and the derivative of x is 1 (we’re using the inductive hypothesis here), 
then for not much more than the cost of multiplying 3 by x we can also have (3 
* 1)+(0 * 4), so we now know that the value of this term is 12 and that the 
derivative of this term is 3, and we’re ready for the next inductive step.

Can I now just say “et cetera” ?

I believe these are the basic ideas behind automatic differentiation.

John


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


signature.asc
Description: PGP signature

Re: [racket-users] Package catalog - can't connect

[Jordan Johnson]

> At Mon, 18 Apr 2016 14:32:20 -0700, Jordan Johnson wrote:
>> ssl-connect: connect failed (error:14090086:SSL 
>> routines:ssl3_get_server_certificate:certificate verify failed)
>>  context…: [stack trace follows]
> 
> I've seen these kinds of problems where the set of trusted certificates
> had not been updated recently enough. Maybe there's an update for the
> "ca-certificates" package for your installation?

Possibly; I may have to kick this over to my ISP’s support, since it’s a 
managed VPS on which I can’t install packages system-wide.

> You could also try setting the `PLT_PKG_SSL_NO_VERIFY` environment
> variable. As a workaround, that's a last resort, but it might help
> clarify whether it issue is with the set of trusted root certificates.

Ah! OK, I tried that, and got:

>>> ssl-connect: connect failed (error:14090086:SSL 
>>> routines:ssl3_get_server_certificate:certificate verify failed)

Same error, suggesting the problem isn’t failure to verify. Is there any way to 
get more info from raco about the cause of failure? I looked for a “verbose” 
option to raco pkg install, but AFAICT there is none.

Best,
jmj

-- 
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: Hidden a list

[Héctor Mc]

I followed the recommendation with hash tables and used
a struct to wrapping the data. I will check this code and will look the 
efficiency.

Thanks for the time.

Héctor.

-- 
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] DSL to C code generation with symbolic computations en route

[Hendrik Boom]

On Mon, Apr 18, 2016 at 08:04:32PM +0200, Jerzy Karczmarczuk wrote:
> Dmitry Pavlov wants "adult" numerics in Racket, and he adds:
> 
> >- I need to take derivatives of equations that I wrote in my DSL,
> >symbolically, and have them converted to C too.
> 
> And then, people (Robby Findler and John Clements) mentioned Siskind. Good.
> 
> However, you should know that Jeffrey worked NOT on /symbolic/
> derivatives, but mainly on the "automatic differentiation" stuff;
> this is numeric, but fast and exact (in the sense: no differential
> quotient approximations). There is plenty of valuable papers written
> by Jeffrey and Barak Pearlmutter... (But some are quite difficult).

I am baffled how you can do differentiation numerically and get it exact.

> 
> If Dmitry is interested in numerical computations, and the "symbolic
> layer" would serve just to code some horrible "C", or similar, then
> please, the automatic differentiation /*is*/ the direction to
> follow.
> 
> Symbolic derivatives used then in numeric computations need a strong
> simplification package, otherwise the computations usually become
> very inefficient.

I understand needing a simplification pass -- naive symbolic 
differentiation tends to copy a lot of subexpressions.

-- hendrik

-- 
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] DSL to C code generation with symbolic computations en route

[Dmitry Pavlov]

All,

Thank you very much for the provided references.

Robby, John, Jerzy: thanks for the pointer to Jeff Siskind.
His works on automatic differentiation are very interesting.
I should look at his Stalingrad software.
I did not think about automatic vs symbolic differentiation
before; now I am convinced that I need the former.

(Maybe the latter, too, in specific simple cases,
with racket-cas, thanks Jens Axel)

I agree that nothing that already exists can fullfill
my needs completely (and did not expect that); however,
some projects I can use, either directly or as examples.

For DSL, Honu seems underdone; Magnolisp is richer, but
not complete too (for instance, it does not have vectors).
Lush is nice, but I wanted something statically typed.
Terra is better as it has types. I see no reason
not to look outside of the Racket world for DSL-s
to be implemented in Racket.

For code generation: I am yet to understand whether
Fulmar will actually help (it seems to me now that the
Fulmar code itself is supposed to be generated).
Nanopass seems great, thanks again Jens Axel.

Konrad, Neil: I think completely the same way as you do.
It is just that I am not quite advanced in doing new
and fancy Racket stuff, so I am going to be slow.
First I have to focus on one project, and after that,
on general use.

RAI seems to be the closest to what I need to do. It has
a DSL with arrays and matrices, it generates C code,
and it even has automatic differentiation, according
to the docs. It is designed for DSP, but probably
can be extended to non-DSP programming. I should
look at it closer.


Regards,

Dmitry

--
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] User/installation scope issues for --skip-installed

[Jonathan Schuster]

Currently, "raco pkg install -u --skip-installed foobar" will error if
foobar is already installed at the installation scope. I can understand why
that might be good, but in my case I'm perfectly happy to use that version
of the package. Is there an option that would allow packages from different
scopes to be be considered installed? Or should --skip-installed perhaps
adopt this behavior?

Thanks,
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] DSL to C code generation with symbolic computations en route

[Konrad Hinsen]

Jay McCarthy  writes:

> Another thing in this realm is the Terra language ---
> http://terralang.org --- and its associated projects, which are all
> quite beautiful.

Terra was indeed one of my inspirations. Another one, older but closer
to our own universe, is Lush (http://lush.sourceforge.net/).

Konrad.

-- 
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] DSL to C code generation with symbolic computations en route

[Jay McCarthy]

This is something that comes up over and over on the list. I believe
that there are others at U(U) that are working on this problem
presently as a way to help port the runtime system from C. Perhaps it
would be good to connect everyone up more efficiently.

On the more boring end, I'm working right now on a language with very
overtly C-semantics for getting some of the benefits of pretty macros
in C. I suspect that there is a connection between what I'm doing and
Fulmar. But I can't seem to understand Fulmar from the docs and I have
nothing doc-like to speak of us. Another thing in this realm is the
Terra language --- http://terralang.org --- and its associated
projects, which are all quite beautiful.

Jay

On Tue, Apr 19, 2016 at 3:18 AM, Konrad Hinsen
 wrote:
> On 18/04/2016 19:20, Dmitry Pavlov wrote:
>
>> I, as a programmer in the area of numerics, just evolved to the state
>> where the following task seem reasonable to work on:
>
> ...
>
>> I suspect I am not the only one who wants that.
>
>
> Me too!
>
>> There must be some work already done.
>> What would you advise to start with?
>
>
> I am not aware of anything very close to your goals in Racketland, but there
> are people much more knowledgeable than me on this list.
>
> I have played with similar ideas as well, but never found the means to work
> on this seriously. But I'd participate in a collaborative project.
>
> My idea for this is:
>
>  1) Define a language with C-level semantics but S-expression syntax. A
> language that can be easily compiled to C, Fortran, LLVM byte code, and
> perhaps even JVM bytecode, in a way that the performance implications of
> each statement are understandable to a software developer.
>
>  2) Develop whatever backends (C, Fortran, LLVM, ...) people find most
> useful. But make sure that at least one backend integrates transparently
> with Racket's FFI, so that one can "just run" such code from Racket.
>
>  3) Develop DSLs that compile to this language.
>
> In the long run, the low-level language could be extended by optimization
> hints, similar to #pragmas as used in OpenMP.
>
> Symbolic derivatives and similar transformations would be part of the DSL
> implementations. For the specific case of derivates, Jerzy's remark is
> important: automatic derivatives are often the better choice. But for the
> big picture, that's a secondary question; a numeric DSL framework should
> support both approaches.
>
> Konrad.
>
>
> --
> 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.

Re: [racket-users] Re: Accessing Undo/Redo History directly?

[WarGrey Gyoudmon Ju]

I think it's impossible to access written texts since what inside the
undo/redo history are functions, not the content entities.
So you have to manage texts on your own.

-- 
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: Accessing Undo/Redo History directly?

[Normal Loone]

Any ideas?

-- 
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] Custodian/Will question

[Deren Dohoda]

Hi Racketeers,

I'm a little unclear on the right way to use custodians and wills.

I have a thread that can only be shut down during certain points: it does
some writing operations on a port and this write must finish under normal
circumstances. I worry that if this thread is managed by a custodian and
custodian-shutdown-all is called that the thread may die in the middle of a
write operation on a port. Is this where I would use a will? I don't quite
understand how this behavior is intended to be supported.

Thanks for any advice,
Deren

-- 
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] Functional Art, Music, Modelling and Design 2016: 2nd Call For Papers

[Michael Sperber]

4th ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and 
Design
Co-located with ICFP
Nara, Japan, 24 September, 2016

Call for Papers and Demos

The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and 
Design (FARM) gathers together people who are harnessing functional techniques 
in the pursuit of creativity and expression.

Functional Programming has emerged as a mainstream software development 
paradigm, and its artistic and creative use is booming. A growing number of 
software toolkits, frameworks and environments for art, music and design now 
employ functional programming languages and techniques. FARM is a forum for 
exploration and critical evaluation of these developments, for example to 
consider potential benefits of greater consistency, tersity, and closer mapping 
to a problem domain.

FARM encourages submissions from across art, craft and design, including 
textiles, visual art, music, 3D sculpture, animation, GUIs, video games, 3D 
printing and architectural models, choreography, poetry, and even VLSI layouts, 
GPU configurations, or mechanical engineering designs. Theoretical foundations, 
language design, implementation issues, and applications in industry or the 
arts are all within the scope of the workshop.  The language used need not be 
purely functional ("mostly functional" is fine), and may be manifested as a 
domain specific language or tool.  Moreover, submissions focusing on questions 
or issues about the use of functional programming are within the scope.

We welcome submissions from academic, professional, and independent programmers 
and artists.
Submissions are invited in three categories:

1) Original papers

We solicit original papers in the following categories:

* original research
* overview / state of the art
* technology tutorial

All submissions must propose an original contribution to the FARM theme. FARM 
2016 is an interdisciplinary conference, so a wide range of approaches are 
encouraged. An original paper should have 5 to 12 pages, be in portable 
document format (PDF), using the ACM SIGPLAN style guidelines and use the ACM 
SIGPLAN template (http://www.sigplan.org/Resources/Author/). Accepted papers 
will be published in the ACM Digital Library as part of the FARM 2016 
proceedings. See http://authors.acm.org/main.cfm for information on the options 
available to authors. Authors are encouraged to submit auxiliary material for 
publication along with their paper (source code, data, videos, images, etc.); 
authors retain all rights to the auxiliary material.

2) Demo proposals

Demo proposals should describe a demonstration to be given at the FARM workshop 
and its context, connecting it with the themes of FARM. A demo could be in the 
form of a short (10-20 minute) tutorial, presentation of work-in-progress, an 
exhibition of some work, or even a performance.  Demo proposals should be in 
plain text, HTML or Markdown format, and not exceed 2000 words. A demo proposal 
should be clearly marked as such, by prepending `Demo Proposal:` to the title. 
Demo proposals will be published on the FARM website.  A summary of the demo 
performances will also be published as part of the conference proceedings, to 
be prepared by the program chair.

3) Calls for collaboration

Calls for collaboration should describe a need for technology or expertise 
related to the FARM theme. Examples may include but are not restricted to:

* art projects in need of realization
* existing software or hardware that may benefit from functional programming
* unfinished projects in need of inspiration

Calls for collaboration should be in plain text, HTML or Markdown format, and 
not exceed 5000 words. A call for collaboration should be clearly marked as 
such, by prepending `Call for Collaboration:` to the title. Calls for 
collaboration will be published on the FARM website.

AUTHORS TAKE NOTE: The official publication date is the date the proceedings 
are made available in the ACM Digital Library. This date may be up to two weeks 
prior to the first day of your conference. The official publication date 
affects the deadline for any patent filings related to published work.

If you have any questions about what type of contributions that might be 
suitable, or anything else regarding submission or the workshop itself, please 
contact the organizers at: farm-2...@functional-art.org

All presentations at FARM 2016 will be recorded.  Permission to publish the 
resulting video (in all probability on YouTube, along with the videos of ICFP 
itself and the other ICFP-colocated events) will be requested on-site.

Key Dates:
Submission deadline - June 24
Author Notification - 15 July
Camera Ready - 31 July
Workshop - September 24, 2016

Submit at :
https://easychair.org/conferences/?conf=farm2016

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails 

Re: [racket-users] Package catalog - can't connect

[Matthew Flatt]

At Mon, 18 Apr 2016 14:32:20 -0700, Jordan Johnson wrote:
> So I tried downloading a newer version of OpenSSL 
> (1.0.2g 1 Mar 2016), and now it fails with:
> 
> ssl-connect: connect failed (error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed)
>   context…: [stack trace follows]

I've seen these kinds of problems where the set of trusted certificates
had not been updated recently enough. Maybe there's an update for the
"ca-certificates" package for your installation?

You could also try setting the `PLT_PKG_SSL_NO_VERIFY` environment
variable. As a workaround, that's a last resort, but it might help
clarify whether it issue is with the set of trusted root certificates.

-- 
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] DSL to C code generation with symbolic computations en route

[Konrad Hinsen]

On 18/04/2016 19:20, Dmitry Pavlov wrote:


I, as a programmer in the area of numerics, just evolved to the state
where the following task seem reasonable to work on:

...


I suspect I am not the only one who wants that.


Me too!


There must be some work already done.
What would you advise to start with?


I am not aware of anything very close to your goals in Racketland, but 
there are people much more knowledgeable than me on this list.


I have played with similar ideas as well, but never found the means to 
work on this seriously. But I'd participate in a collaborative project.


My idea for this is:

 1) Define a language with C-level semantics but S-expression syntax. A 
language that can be easily compiled to C, Fortran, LLVM byte code, and 
perhaps even JVM bytecode, in a way that the performance implications of 
each statement are understandable to a software developer.


 2) Develop whatever backends (C, Fortran, LLVM, ...) people find most 
useful. But make sure that at least one backend integrates transparently 
with Racket's FFI, so that one can "just run" such code from Racket.


 3) Develop DSLs that compile to this language.

In the long run, the low-level language could be extended by 
optimization hints, similar to #pragmas as used in OpenMP.


Symbolic derivatives and similar transformations would be part of the 
DSL implementations. For the specific case of derivates, Jerzy's remark 
is important: automatic derivatives are often the better choice. But for 
the big picture, that's a secondary question; a numeric DSL framework 
should support both approaches.


Konrad.

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