Yes, you're right. Sorry for that confusion. I don't have that confusion
with positive? and +0.0, after all!
Robby
On Fri, Mar 1, 2013 at 10:50 AM, Eric Dobson wrote:
> Why is Nonnegative-Real not suggestive of the right thing? To me that
> means (and/c real? (not/c (lambda (x) (< x 0 which
Why is Nonnegative-Real not suggestive of the right thing? To me that
means (and/c real? (not/c (lambda (x) (< x 0 which is exactly what
it is.
I think the confusing part is that -0.0 has a minus sign in front
which means that you think it is negative, but this isn't true.
On Fri, Mar 1, 2013
Is there perhaps a more suggestive name? (Not that I'm coming up with
one...)
Robby
On Fri, Mar 1, 2013 at 10:22 AM, Vincent St-Amour wrote:
> At Fri, 01 Mar 2013 09:05:21 +0100,
> Marijn wrote:
> > On 27-02-13 21:51, Neil Toronto wrote:
> >
> > > (An example that came up in the implementation
At Fri, 01 Mar 2013 09:05:21 +0100,
Marijn wrote:
> On 27-02-13 21:51, Neil Toronto wrote:
>
> > (An example that came up in the implementation of matrix norms: the
> > type of (sqrt (/ 1 x)) isn't Nonnegative-Real if x :
> > Nonnegative-Real, but Complex. Consider x = -0.0. Without TR's
> > compl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27-02-13 21:51, Neil Toronto wrote:
> (An example that came up in the implementation of matrix norms: the
> type of (sqrt (/ 1 x)) isn't Nonnegative-Real if x :
> Nonnegative-Real, but Complex. Consider x = -0.0. Without TR's
> complaints, `matrix-
On 02/27/2013 01:51 PM, Neil Toronto wrote:
On Sunday, Eli Barzilay wrote:
According to my rough count (and running setup with a "-j 1"),
compiling `math' takes 40% of the whole tree compilation.
I'm running my own timing tests. So far, I've got 917s (about 15
minutes) to compile the math lib
On 02/27/2013 09:17 AM, Jens Axel Søgaard wrote:
2013/2/27 Eli Barzilay :
On Sunday, Eli Barzilay wrote:
According to my rough count (and running setup with a "-j 1"),
compiling `math' takes 40% of the whole tree compilation.
I'm surprised that nobody finds this disturbing. Maybe it was the
2013/2/27 Eli Barzilay :
> On Sunday, Eli Barzilay wrote:
>> According to my rough count (and running setup with a "-j 1"),
>> compiling `math' takes 40% of the whole tree compilation.
>
> I'm surprised that nobody finds this disturbing. Maybe it was the
> lack of bangs in the subject.
Disturbing
On Sunday, Eli Barzilay wrote:
> According to my rough count (and running setup with a "-j 1"),
> compiling `math' takes 40% of the whole tree compilation.
I'm surprised that nobody finds this disturbing. Maybe it was the
lack of bangs in the subject.
--
((lambda (x) (x x)) (lambda (x
According to my rough count (and running setup with a "-j 1"),
compiling `math' takes 40% of the whole tree compilation.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_
I just read the documentation. This is great stuff.
Some choices quotes and comments:
"[sum] is like (apply + xs), but incurs rounding error only once when
adding inexact numbers. (In fact, the inexact numbers in xs are summed
separately using flsum.)"
"Use (random-natural k) instead of (random
Hi All,
Thanks to Asumu, Erich and a few others on the irc channel
I got it working.
I tried rebasing, but couldn't make it work. I am not sure why.
The resulting pull request still had the entire history.
Then I tried making a new branch. Reseting to a point before
Neils initial commit. Then fe
Well, you can also use git rebase. It basically the same as that, but easier.
Robby
On Sat, Nov 17, 2012 at 12:29 PM, Kevin Tew wrote:
> Use git format-patch to create patch files for your range of commits and
> then apply them to the current head using git am
>
> Kevin
>
>
> On 11/17/2012 06:57
Use git format-patch to create patch files for your range of commits and
then apply them to the current head using git am
Kevin
On 11/17/2012 06:57 AM, Jens Axel Søgaard wrote:
2012/11/16 Neil Toronto :
I've just made the initial commit for the math library. You will all notice
the build time
2012/11/16 Neil Toronto :
> I've just made the initial commit for the math library. You will all notice
> the build time increase. Some will notice that "(require math)" imports a
> bunch of goodies that Racket didn't have before.
>
> About half is documented so far, and half has coverage in the te
>From the cheap seats. Built clean. Except for warning below. Test failed
as libffi as initially was not found by the dynamic load. After adjusting
version in mpfr.rkt. Test produced pi ... 4888
Applicable lib version on Ubuntu 12.10.
/usr/lib/x86_64-linux-gnu/libmpfr.so.4
/usr/lib/x86_64-l
I'll add version numbers along with other changes.
At Fri, 16 Nov 2012 18:26:20 -0500, Ryan Culpepper wrote:
> I get this message (during doc build, actually):
>
> raco setup: error running: (lib math/scribblings/math.scrbl)
> ffi-lib: couldn't open "libmpfr.so" (libmpfr.so: cannot open shared
>
I get this message (during doc build, actually):
raco setup: error running: (lib math/scribblings/math.scrbl)
ffi-lib: couldn't open "libmpfr.so" (libmpfr.so: cannot open shared
object file: No such file or directory)
I have /usr/lib/libmpfr.so.1, which is symlinked to
/usr/lib/libmpfr.so.1.2
A fix is even better!
Thanks,
Jens Axel
2012/11/16 Matthew Flatt :
> At Fri, 16 Nov 2012 21:21:29 +0100, Jens Axel Søgaard wrote:
>> 2012/11/16 Matthew Flatt :
>>
>> > * require: unknown module
>> > module name: #> > "/Users/mflatt/proj/plt/collects/math/special-functions.rkt"
>> typed-
At Fri, 16 Nov 2012 21:21:29 +0100, Jens Axel Søgaard wrote:
> 2012/11/16 Matthew Flatt :
>
> > * require: unknown module
> > module name: # > "/Users/mflatt/proj/plt/collects/math/special-functions.rkt"
> typed-module5)>
> >
> >So far, this one looks like a problem with finding a su
2012/11/16 Matthew Flatt :
> * require: unknown module
> module name: # "/Users/mflatt/proj/plt/collects/math/special-functions.rkt"
> typed-module5)>
>
>So far, this one looks like a problem with finding a submodule in a
>".zo" file --- that is, a bug that I will have to track d
I'm seeing two build problems on Mac OS X:
* No "libmpfr.dylib"
This looks like a problem with `math/private/matrix/matrix-sequences'
importing `math/matrix' at too many phases. Removing the `for-syntax'
and `for-template' imports let me get past this one.
(I won't be able to run `m
I've just made the initial commit for the math library. You will all
notice the build time increase. Some will notice that "(require math)"
imports a bunch of goodies that Racket didn't have before.
About half is documented so far, and half has coverage in the test
cases. Some things are known
On 10/01/2012 02:06 PM, Sam Tobin-Hochstadt wrote:
On Mon, Oct 1, 2012 at 2:26 PM, Neil Toronto wrote:
* `math/base' re-exports `racket/math', but with extra constants (like
`phi.0') and functions (like `power-of-two?'). It also exports improved
hyperbolic functions, such as a new `sinh' that
I think this idea is worth exploring. Sam and Eli should implement it.
On Oct 5, 2012, at 8:39 AM, Eli Barzilay wrote:
> Yesterday, Matthias Felleisen wrote:
>>
>> I know
>>
>> What I mean is an _abstraction mechanism_ inside of TR. Possibly
>> something that nobody else has.
>
> +18.59
>
Yesterday, Matthias Felleisen wrote:
>
> I know
>
> What I mean is an _abstraction mechanism_ inside of TR. Possibly
> something that nobody else has.
+18.59
And a quick reminder -- below is the ancient hack I once did for such
things, maybe something like this would be easier now. Possibly m
On Oct 4, 2012, at 5:34 PM, Sam Tobin-Hochstadt wrote:
> On Thu, Oct 4, 2012 at 5:31 PM, Matthias Felleisen
> wrote:
>>
>> On Oct 1, 2012, at 2:26 PM, Neil Toronto wrote:
>>
>>>
>>> (case-> (Zero -> Zero)
>>> (Flonum -> Flonum)
>>> (Real -> Real)
>>> (Float-Complex ->
On Thu, Oct 4, 2012 at 5:31 PM, Matthias Felleisen wrote:
>
> On Oct 1, 2012, at 2:26 PM, Neil Toronto wrote:
>
>>
>> (case-> (Zero -> Zero)
>> (Flonum -> Flonum)
>> (Real -> Real)
>> (Float-Complex -> Float-Complex)
>> (Complex -> Complex))
>>
>> I haven't bee
On Oct 1, 2012, at 2:26 PM, Neil Toronto wrote:
>
> (case-> (Zero -> Zero)
> (Flonum -> Flonum)
> (Real -> Real)
> (Float-Complex -> Float-Complex)
> (Complex -> Complex))
>
> I haven't been able to give it a type as specific as the type of the `sinh'
> exp
On Mon, Oct 1, 2012 at 6:49 PM, Neil Toronto wrote:
>
> This is similar to the testing code I wrote, and it also exhibits quadratic
> behavior. The `apply*' macro generates the simplest deep expression
> possible. It's used to repeatedly apply a function with the simplest
> one-argument floating-p
;Sam Tobin-Hochstadt"
To: "J. Ian Johnson"
Cc: "dev" , "Neil Toronto"
Sent: Tuesday, October 2, 2012 10:02:50 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Math library initial commit almost ready; comments on
issues welcome
On Tue, Oct 2, 2012 at 9:55 A
; To: "Neil Toronto"
> Cc: ""
> Sent: Tuesday, October 2, 2012 9:44:13 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] Math library initial commit almost ready; comments
> on issues welcome
>
> On Mon, Oct 1, 2012 at 9:44 PM, Neil Toronto
er 2, 2012 9:44:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Math library initial commit almost ready; comments on
issues welcome
On Mon, Oct 1, 2012 at 9:44 PM, Neil Toronto wrote:
> The only bit that bothers me is the (begin (not (flonum-wrapper? x)) ...)
> stuff left lying a
On Mon, Oct 1, 2012 at 9:44 PM, Neil Toronto wrote:
> The only bit that bothers me is the (begin (not (flonum-wrapper? x)) ...)
> stuff left lying around after TR's optimizer eliminates the branches in the
> expansions of `fw+'. IIRC, they cause futures to sync, but I'm going to
> believe that the
On 10/01/2012 06:29 PM, Sam Tobin-Hochstadt wrote:
On Mon, Oct 1, 2012 at 6:49 PM, Neil Toronto wrote:
#lang typed/racket
(: plus (Flonum Flonum -> Flonum))
(define (plus a b)
(+ a b))
(module provider racket
(require (submod ".."))
(provide inline-plus)
(define-syntax-rule (inlin
On Mon, Oct 1, 2012 at 6:49 PM, Neil Toronto wrote:
> On 10/01/2012 04:20 PM, Sam Tobin-Hochstadt wrote:
>>
>> On Mon, Oct 1, 2012 at 6:08 PM, Neil Toronto
>> wrote:
>>>
>>> On 10/01/2012 02:06 PM, Sam Tobin-Hochstadt wrote:
On Mon, Oct 1, 2012 at 2:26 PM, Neil Toronto
wrote:
On 10/01/2012 04:20 PM, Sam Tobin-Hochstadt wrote:
On Mon, Oct 1, 2012 at 6:08 PM, Neil Toronto wrote:
On 10/01/2012 02:06 PM, Sam Tobin-Hochstadt wrote:
On Mon, Oct 1, 2012 at 2:26 PM, Neil Toronto
wrote:
My timing tests also show that typechecking is apparently quadratic in the
depth of e
On Mon, Oct 1, 2012 at 6:08 PM, Neil Toronto wrote:
> On 10/01/2012 02:06 PM, Sam Tobin-Hochstadt wrote:
>>
>> On Mon, Oct 1, 2012 at 2:26 PM, Neil Toronto
>> wrote:
>> PR 13098 isn't really fixable, in some sense. There's just more data
>> there with broader types, so it will always take longer
On 10/01/2012 02:06 PM, Sam Tobin-Hochstadt wrote:
On Mon, Oct 1, 2012 at 2:26 PM, Neil Toronto wrote:
PR 13098 isn't really fixable, in some sense. There's just more data
there with broader types, so it will always take longer than for more
specific types. All of the things I'd do to fix the p
On Mon, Oct 1, 2012 at 2:26 PM, Neil Toronto wrote:
> * Compile time. It currently takes 1m20s to compile `math' without docs on
> my beefy laptop. That's down from 2m30s, with the reduction from replacing
> general functions with flonum-specific functions in over half of the flonum
> code (e.g.
On Mon, Oct 1, 2012 at 1:26 PM, Neil Toronto wrote:
> I think I'm about a week away from having the math library's initial commit
> ready. It just needs some more docs and test cases.
>
> Here are the high-level issues, for which I'm soliciting comments,
> suggestions, questions, and answers:
>
>
I think I'm about a week away from having the math library's initial
commit ready. It just needs some more docs and test cases.
Here are the high-level issues, for which I'm soliciting comments,
suggestions, questions, and answers:
* Compile time. It currently takes 1m20s to compile `math' w
On 07/07/2012 01:39 PM, Matthias Felleisen wrote:
Neil, do you intend to provide differentiat and integrate and possibly
> adjoin operations on operators from your math collection?
I've considered numerical differentiation and integration. If you want
them, I'll make sure they (eventu
Neil, do you intend to provide differentiat and integrate and possibly adjoin
operations on operators from your math collection? -- Matthias
_
Racket Developers list:
http://lists.racket-lang.org/dev
Sorry.
On Thu, Jun 28, 2012 at 3:51 PM, Matthias Felleisen
wrote:
>
> On Jun 28, 2012, at 3:52 PM, Robby Findler wrote:
>
>> "well, I want to limit access to this because I know that X writes this code
>> and thus can I can be sure that things work
>
> This is of course a caricature of what I am
On Jun 28, 2012, at 3:52 PM, Robby Findler wrote:
> "well, I want to limit access to this because I know that X writes this code
> and thus can I can be sure that things work
This is of course a caricature of what I am saying, a strawman at best, and not
worth discussing any further -- Matthia
At Thu, 28 Jun 2012 14:24:04 -0600,
Neil Toronto wrote:
> Also, I just had an idea. Vincent, how hard would it be to use something
> like the current randomized testing to *search* for a more precise type?
> I'm thinking of an algorithm that iteratively 1) makes a type like (Real
> -> Real) more
On 06/28/2012 01:52 PM, Robby Findler wrote:
One more comment (even tho I promised not (and even worse this is a
kind of repetition)): I think it is easy to fall into the trap of
thinking "well, I want to limit access to this because I know that X
writes this code and thus can I can be sure that
One more comment (even tho I promised not (and even worse this is a
kind of repetition)): I think it is easy to fall into the trap of
thinking "well, I want to limit access to this because I know that X
writes this code and thus can I can be sure that things work"; we
should really be thinking abou
On Thu, Jun 28, 2012 at 10:21 AM, Jay McCarthy wrote:
> I also would like to see a macro-like compiler extension API for
> hooking into optimizations and different specialized JITing. Things
> like that are a very effective use of template meta-programming in C++
> that I think we could do better.
Thanks for your correction. I think we're saying the same thing.
Although I think that the safety we claim to have isn't really there
with unsafe ops and the FFI. I can copy the definition of a closure
out of the C headers into an FFI struct, cast the _racket pointer to a
_closure-pointer, and rea
I found your message strange and I contemplated whether I should reply on 'dev'
at all.
In the interest of sharing and evolving the Racket idea, I am going with a
response on 'dev'. Your central claim is that "the programming language
implementer is not a member of an elite, enlightened caste
FWIW, I agree with Robby and have had similar conversations with Sam
in person. (Although for me it is that I wish I had the ability to
claim that macro pieces had certain types regardless of what TR could
infer from the generated code.)
I think a big part of the Racket philosophy is that the prog
Consider me done!
Robby
On Tue, Jun 26, 2012 at 11:05 PM, Neil Toronto wrote:
> I haven't got a clue what you two are arguing about anymore. If you both
> stop, maybe Sam can implement that perfectly safe change to the typed ->
> untyped contract barrier that he said he could do. That would be n
I haven't got a clue what you two are arguing about anymore. If you both
stop, maybe Sam can implement that perfectly safe change to the typed ->
untyped contract barrier that he said he could do. That would be nice.
;)
Neil ⊥
On 06/26/2012 09:23 PM, Robby Findler wrote:
On Tue, Jun 26, 2012
On Tue, Jun 26, 2012 at 10:08 PM, Sam Tobin-Hochstadt wrote:
> On Tue, Jun 26, 2012 at 10:44 PM, Robby Findler
> wrote:
>> On Tue, Jun 26, 2012 at 9:25 PM, Sam Tobin-Hochstadt
>> wrote:
>>> On Tue, Jun 26, 2012 at 9:29 PM, Robby Findler
>>> wrote:
This sounds like a terrible solution.
>>>
On Tue, Jun 26, 2012 at 10:44 PM, Robby Findler
wrote:
> On Tue, Jun 26, 2012 at 9:25 PM, Sam Tobin-Hochstadt
> wrote:
>> On Tue, Jun 26, 2012 at 9:29 PM, Robby Findler
>> wrote:
>>> This sounds like a terrible solution.
>>>
>>> There are lots of places in our system where we just declare facts
On Tue, Jun 26, 2012 at 9:25 PM, Sam Tobin-Hochstadt wrote:
> On Tue, Jun 26, 2012 at 9:29 PM, Robby Findler
> wrote:
>> This sounds like a terrible solution.
>>
>> There are lots of places in our system where we just declare facts and
>> don't prove them and then use them for lots of things (oft
On Tue, Jun 26, 2012 at 9:29 PM, Robby Findler
wrote:
> This sounds like a terrible solution.
>
> There are lots of places in our system where we just declare facts and
> don't prove them and then use them for lots of things (often
> optimizations). Why should this one be special?
I don't know of
On Tue, Jun 26, 2012 at 9:36 PM, Robby Findler
wrote:
> The safety in this case doesn't generalize to contracts like the one
> Neil is suggesting when you go from an untyped value to a typed one,
> tho, right?
Right, if we have an untyped value which we'd like to give the
`case->` type that Neil
Do you only use code that uses the FFI that people you trust wrote?
How about code in the runtime system? Both of these have lots of
people contributing code that can (and does) easily undermine basic
Racket guarantees, and you don't complain about that. Do you care
about type system guarantees mor
If even the few people who understand the type basis properly
get types wrong, why should you have programmers open up loopholes
into types that are supposed to "harden" their programs? When I have
just a few implementors manipulate the type base I can stick to the
allusion that the language is
The safety in this case doesn't generalize to contracts like the one
Neil is suggesting when you go from an untyped value to a typed one,
tho, right?
Robby
On Tue, Jun 26, 2012 at 8:32 PM, Sam Tobin-Hochstadt wrote:
> Certainly the dependent contract approach will work, but the 'Real -> Real'
>
I agree with that, to a point. Here were are now considering a very
concrete tradeoff, however: asking the user to cope with code
duplication in return for ... what? Very little, I claim. In
particular, I think that TR already has lots of type+contracts that
are asserted (not proven) to be equivale
Certainly the dependent contract approach will work, but the 'Real -> Real'
contract is also safe, so I'll see about generating that.
Sam
On Jun 26, 2012 8:37 PM, "Robby Findler"
wrote:
> In this case, the contract could turn into a dependent one with the
> same semantics. Does it make sense for
I'm saying that people can make mistakes in Racket currently that
undermine the guarantees of the type system. But lets continue the
other line first.
On Tue, Jun 26, 2012 at 8:28 PM, Matthias Felleisen
wrote:
>
> Huh?
>
> On Jun 26, 2012, at 9:27 PM, Robby Findler wrote:
>
>> Well, you wouldn't.
Because the point of types is to have something proven.
On Jun 26, 2012, at 9:29 PM, Robby Findler wrote:
> This sounds like a terrible solution.
>
> There are lots of places in our system where we just declare facts and
> don't prove them and then use them for lots of things (often
> optimiz
Huh?
On Jun 26, 2012, at 9:27 PM, Robby Findler wrote:
> Well, you wouldn't. Are the implementations of the contracts proven to
> be equivalent currently? Or do you just have a theorem that matches up
> the ones in some model somewhere?
>
> Robby
>
> On Tue, Jun 26, 2012 at 8:05 PM, Matthias
This sounds like a terrible solution.
There are lots of places in our system where we just declare facts and
don't prove them and then use them for lots of things (often
optimizations). Why should this one be special?
Robby
On Tue, Jun 26, 2012 at 8:16 PM, Matthias Felleisen
wrote:
>
> On Jun 2
Well, you wouldn't. Are the implementations of the contracts proven to
be equivalent currently? Or do you just have a theorem that matches up
the ones in some model somewhere?
Robby
On Tue, Jun 26, 2012 at 8:05 PM, Matthias Felleisen
wrote:
>
> How would you check soundness between a type and it
On Jun 26, 2012, at 9:12 PM, Neil Toronto wrote:
> I'm addicted to optimizations. If I use Real -> Real, TR can't prove that
> (log1p 1.0) is Float and... hmm. I'll let Vincent explain why that's bad. :)
>
> Another option is to provide both log1p and fllog1p. I just wrote fllog1p
> anyway.
I'm addicted to optimizations. If I use Real -> Real, TR can't prove
that (log1p 1.0) is Float and... hmm. I'll let Vincent explain why
that's bad. :)
Another option is to provide both log1p and fllog1p. I just wrote
fllog1p anyway.
Neil ⊥
On 06/26/2012 07:05 PM, Matthias Felleisen wrote:
How would you check soundness between a type and its contract?
Types, like theorem provers, are addictive. The more expressivity
they provide, the more programmers want to play with them.
Use Real -> Real and you'll be fine. -- Matthias
On Jun 26, 2012, at 8:37 PM, Robby Findler wrote:
>
In this case, the contract could turn into a dependent one with the
same semantics. Does it make sense for TR to allow a user to declare
the equivalent contract?
Robby
On Tue, Jun 26, 2012 at 7:17 PM, Neil Toronto wrote:
> Ten minutes in, I've hit a snag. I'd like the stuff in math/functions to
Ten minutes in, I've hit a snag. I'd like the stuff in math/functions to
have precise types. For example, log1p could have the type
(case-> (Zero -> Zero)
(Float -> Float)
(Real -> Real))
It was easy to get the implementation to typecheck, but when I tried to
plot it in u
75 matches
Mail list logo
