Re: [racket-users] Re: Decision Tree in Racket - Performance

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

Re: [racket-users] Re: Decision Tree in Racket - Performance

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

Re: [racket-users] Re: Decision Tree in Racket - Performance

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

Re: [racket-users] Re: Decision Tree in Racket - Performance

`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

Re: [racket-users] Re: Decision Tree in Racket - Performance

`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) (+

Re: [racket-users] Re: Decision Tree in Racket - Performance

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

Re: [racket-users] Re: Decision Tree in Racket - Performance

> 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

Re: [racket-users] Re: Decision Tree in Racket - Performance

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?`

Re: [racket-users] Re: Decision Tree in Racket - Performance

*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)

Re: [racket-users] Re: Decision Tree in Racket - Performance

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 (λ

Re: [racket-users] Re: Decision Tree in Racket - Performance

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])

Re: [racket-users] Re: Decision Tree in Racket - Performance

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

Re: [racket-users] Re: Decision Tree in Racket - Performance

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:

Re: [racket-users] Re: Decision Tree in Racket - Performance

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

Re: [racket-users] Re: Decision Tree in Racket - Performance

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

Re: [racket-users] Re: Decision Tree in Racket - Performance

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.

Re: [racket-users] Re: Decision Tree in Racket - Performance

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,

Re: [racket-users] Re: Decision Tree in Racket - Performance

> 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

Re: [racket-users] Re: Decision Tree in Racket - Performance

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

[racket-users] Re: Decision Tree in Racket - Performance

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

Re: [racket-users] Re: Decision Tree in Racket - Performance

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

Re: [racket-users] Correctly executing a source file from embedded Racket

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 = > | > | if (scheme_setjmp(scheme_error_buf)) { > |/* There

[racket-users] Re: query-exec SQLite3 multiple statements

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-users] Re: query-exec SQLite3 multiple statements

> 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

Re: [racket-users] Re: Decision Tree in Racket - Performance

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,