> `first` and `rest` need to check if the input is a list.
Why is that?
On Fri, Jul 28, 2017 at 1:09 PM, Gustavo Massaccesi
wrote:
> I was convinced that case-lambas were much slower.
>
> I made some tests, but I replaced first/rest with car/cdr beause it's
> much faster. Also I repeated the ca
I was convinced that case-lambas were much slower.
I made some tests, but I replaced first/rest with car/cdr beause it's
much faster. Also I repeated the call 1000 times. I got almost 1/2
second of difference.
opt cpu time: 12266 real time: 12264 gc time: 0
acc cpu time: 11750 real time: 11745 gc
On Thu, Jul 27, 2017 at 8:13 PM, Philip McGrath
wrote:
> ; timed in DrRacket w/ debugging
This is probably not a good idea. More information here:
http://docs.racket-lang.org/guide/performance.html
Robby
--
You received this message because you are subscribed to the Google Groups
"Racket Use
`first` and `rest` need to check if the input is a list (a linear-time
but memoized test), whereas `car` and `cdr` check only if the inputs
are `pair?`s, and match-define uses unsafe operations, doing the pair
check only once.
I see from raco demod that match-define does not generate very
beautifu
`match-define` seems to be the real source of the speedup for me:
#lang racket
(define (as)
(build-list 100 (λ (n) (random 100
(define (bs)
(build-list 100 (λ (n) (random 100
(define (f as bs [acc 0])
(if (or (null? as) (null? bs))
acc
(f (rest as) (rest bs) (+
The performance hit of first / rest vs car / cdr is a little disquieting
from a readability POV.
Very informative discussion, though!
Dan
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails
> On Jul 27, 2017, at 9:18 PM, Matthew Flatt wrote:
>
> I don't think optional arguments are all that slow.
This isn’t just Matthew’s opinion. Vincent’s feature-specific profiler could
not detect a significant impact of optional or keyword arguments. (See Compiler
Construction paper, London
At Thu, 27 Jul 2017 22:08:33 -0300, Gustavo Massaccesi wrote:
> Functions with optional arguments are slow. They are expanded to a
> case-lambda and an if. This version with an auxiliary function is
> faster:
I don't think optional arguments are all that slow.
You're seeing the result of `list?`
*Slightly too significant, since I wrote g incorrectly. This is right:
#lang racket
(collect-garbage)
(collect-garbage)
(collect-garbage)
(define as (build-list 100 (λ (n) (random 100
(define bs (build-list 100 (λ (n) (random 100
(define (f as bs [acc 0])
(if (or (null? as) (n
Eliminating the optional argument and using match-define to avoid any
redundant checking on first and rest gets me a significant speedup:
#lang racket
(collect-garbage)
(collect-garbage)
(collect-garbage)
(define as (build-list 100 (λ (n) (random 100
(define bs (build-list 100 (λ (n)
Functions with optional arguments are slow. They are expanded to a
case-lambda and an if. This version with an auxiliary function is
faster:
#lang racket
(define as (build-list 100 (λ (n) (random 100
(define bs (build-list 100 (λ (n) (random 100
(define (f/opt as bs [acc 0])
You can get better performance out of the recursive function by using
car/cdr instead of first/rest; first/rest require their arguments to
be lists, whereas car/cdr require theirs to be pairs, which is a lot
cheaper to check. Also, using an optional argument (in a loop,
especially) makes a differen
Revised to collect garbage before each timing shows the recursive function
isn't too bad (but not great):
cpu time: 405 real time: 404 gc time: 0
2452578471
cpu time: 368 real time: 368 gc time: 0
2452578471
cpu time: 50 real time: 50 gc time: 0
2452578471
cpu time: 194 real time: 195 gc time:
To dramatise Gustavo's point, here's a quick comparison of some different
methods:
#lang racket
(collect-garbage)
(collect-garbage)
(collect-garbage)
(define as (build-list 100 (λ (n) (random 100
(define bs (build-list 100 (λ (n) (random 100
(define (f as bs [acc 0])
(if (or (
I agree with the in-list explanation, but I want to remark a few details.
>> I don't really understand the (in-list ...) thing. This seems to be internal
>> magic to me.
`in-list` is not a function, it's a macro that looks like a function.
`for` is another macro (that doesn't look like a functio
Zelphir:
> I don't really understand the (in-list ...) thing. This seems to be
internal magic to me. Maybe it informs about the type of what is iterated
over and that makes it faster?
Pretty much. Here's a program that constructs a lot of random numbers and
adding them up in a few different ways.
Before each `time` call, so that you're not getting really bad data due
to GC costs of other code, do this:
(collect-garbage)
(collect-garbage)
(collect-garbage)
The three times, like "there's no place like home", is a bit of folklore
that I'm not certain is still necessary or sufficient, with
> Wow, are those timings for the "big" data set?!
I use 1/5 of the data as a training set, in line with my understanding of
the original article, which splits it in 5.
I use the remaining 4/5 as a single validation set rather than four
separate sets (because I got lazy). That won't impact the spe
On Thu, Jul 27, 2017 at 4:01 PM, Zelphir Kaltstahl
wrote:
> Wow, are those timings for the "big" data set?!
>
Unless I'm mistaken, Daniel's times are for 274 rows of the big data
set, not the whole thing.
--
You received this message because you are subscribed to the Google Groups
"Racket User
I had another idea for the implementation, which I tried to implement. I tried
to store in each node a procedure, which can be used when predicting data point
labels, so that I can simply get that from the struct and call it with the data
point and get back, whether I should go left or right at
On Wednesday, July 26, 2017 at 3:17:46 PM UTC+2, gustavo wrote:
> I read the solution of Daniel Prager and I have a few minor changes.
>
> * First I added a test that repeats `build-tree` 20 times, so the run
> time is approximately 1-2 seconds. This is not necessary, but times
> smaller than 1 se
At Wed, 26 Jul 2017 14:44:05 -0700 (PDT), Thomas Dickerson wrote:
> Looking at this code specifically:
>
> | mz_jmp_buf * volatile save, fresh;
> | save = scheme_current_thread->error_buf;
> | scheme_current_thread->error_buf = &fresh;
> |
> | if (scheme_setjmp(scheme_error_buf)) {
> |/* T
For now I've just written a quick batch script that I execute via system
```
#!/bin/bash
for f in 'tmp/sql'/*.sql
do
echo "Filename: $f"
./sqlite3.exe output.sq3 < $f
echo ""
done
```
It works, but I'd still like to figure out exactly what's wrong. I'm relatively
new to racket,
> OMG!!! Does the term "normalization" ring a bell?
Yes but these are encoded file outputs. I'm only using SQL as an alternative to
using a text editor.
> Have you tried removing the terminating semi-colon?
I just tried, same error
> I'm not sure what's causing your issue. What version of
Thanks!
That's a useful technique, and your adjutant utilities look handy.
There should (could?) be an annual poll for promotion of the best
conveniences into the mainstream of Racket!
Dan
On 27 Jul. 2017 1:43 pm, "Philip McGrath" wrote:
> Re multiple return values, you can write (call-with-v
25 matches
Mail list logo
