Thanks, that works great. Looks really cool!
Sam
On Mon Jan 26 2015 at 2:27:44 PM Xiangqi Li wrote:
> Right now Medic doesn't support directly running "med.rkt" to get the
> results (has to know the set of medic programs to execute and which source
> file to start debugging). We need to write an
Right now Medic doesn't support directly running "med.rkt" to get the
results (has to know the set of medic programs to execute and which source
file to start debugging). We need to write another program to debug the
source code. The program should be in the same directory of medic programs:
#lang
Hi Xiangqui,
I just tried to run this, but it didn't show anything.
I put this in /tmp/src.rkt:
#lang racket
(for/fold ([v 0]) ([x (in-range 100)])
(+ v (/ x 100)))
(for/fold ([v 0]) ([x (in-range 100)])
(+ v (/ x (- 100 x
and this in /tmp/med.rkt:
#lang medic
(layer layer1
For the testing program provided by Matthew, we can also use *(timeline v)*
(an enhanced version of displayln) to compare the value of v at each
iteration and see the results in a better way:
If you want to try it out yourself, you can go to
https://github.com/lixiangqi/medic and install the Med
At Sat, 24 Jan 2015 19:14:18 +0100, Daniel Kvasnička wrote:
> >> What about the segmentation fault? Am I doing something wrong?
> >
> > You're missing an conversion from fixnum to flonum in the second
> > argument to `unsafe-fl/`:
>
> At first I thought the same but (unsafe-fl/ 3.0 4) works and (
>> What about the segmentation fault? Am I doing something wrong?
>
> You're missing an conversion from fixnum to flonum in the second
> argument to `unsafe-fl/`:
At first I thought the same but (unsafe-fl/ 3.0 4) works and (flonum? 4) is #f
…what am I missing?
Dan
Racket
At Sat, 24 Jan 2015 18:14:39 +0100, Daniel Kvasnička wrote:
> What about the segmentation fault? Am I doing something wrong?
You're missing an conversion from fixnum to flonum in the second
argument to `unsafe-fl/`:
> (time (exact->inexact (for/sum ([x (in-range 1)]) (unsafe-fl/ (->fl x)
> (
Thanks guys, feeling embarrased now :) A little more basic math reasoning could
have helped me ;) Makes sense.
What about the segmentation fault? Am I doing something wrong?
Daniel
> On 24. 1. 2015, at 17:56, Matthew Flatt wrote:
>
> Jens Axel and Alexander have provided the answer, but in cas
Jens Axel and Alexander have provided the answer, but in case it helps
to see what they mean, try these loops that display the intermediate
results:
(for/fold ([v 0]) ([x (in-range 100)])
(displayln v)
(+ v (/ x 100)))
(for/fold ([v 0]) ([x (in-range 100)])
(displayln v)
(+ v (/ x (
I’m not sure, but if I understand correctly (and someone please correct me if I
don’t),
summing up lots of things with the same denominator (in this case 1) means
that the denominator of the result of the sum never grows, but if the
denominator is changing from 1 to to 9998 etc. the
Adding two fractions with different denominators requires a computation
of the common denominator. For large denominators this can take time.
The time needed to compute your sum will depend on the order of the terms.
If you only need an inexact result, then use floating points:
(for/sum ([x (
Hi, I'm observing the following difference in performance:
> (time (exact->inexact (for/sum ([x (in-range 1)]) (/ x 1
cpu time: 6 real time: 6 gc time: 0
4999.5
> (time (exact->inexact (for/sum ([x (in-range 1)]) (/ x (- 1 x)
cpu time: 3624 real time: 3622 gc time: 39
87876
12 matches
Mail list logo
