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

[Robby Findler]

I see that I was misled by raco demod, which suggests that this:

(define (f x)
  (match-define (cons a b) x)
  (+ a b))

compiles into this:

(define-values
 (_f)
 (lambda (arg0-21)
   '#(f # 2 0 14 54 #f)
   '(flags: preserves-marks single-result)
   '(captures:
 (val/ref #%modvars)
 (|_match:error:P@(lib "racket/match/runtime.rkt")|
  |_syntax-srclocs:P@(lib "racket/match/runtime.rkt")|
  #%syntax))
   (let ((localv22 ?) (localv23 ?))
 (begin
   (set!-values (localv22 localv23)
 (if (pair? arg0-21)
   (values (unsafe-car arg0-21) (unsafe-cdr arg0-21))
   (|_match:error:P@(lib "racket/match/runtime.rkt")|
(#%sfs-clear arg0-21)
(|_syntax-srclocs:P@(lib "racket/match/runtime.rkt")| stx19)
'match-define)))
   (+ localv22 localv23)

and I figured that match introduced the set! (without checking).

It make sense to me that it wouldn't be matches job to eliminate those
multiple values. Probably not worth doing more here.

Robby



On Tue, Aug 8, 2017 at 6:34 PM, Sam Tobin-Hochstadt
 wrote:
> On Thu, Jul 27, 2017 at 8:36 PM, Robby Findler
>  wrote:
>> I see from raco demod that match-define does not generate very
>> beautiful code, which leads me to this version (which is what I think
>> match-define should have expanded into). It seems to be about 4x
>> faster on my computer.
>
> Unfortunately, I don't think `match-define` can avoid the use of
> multiple values here. What you're seeing is the difference between:
>
> (define-values (a b) (if (pair? x) (values (car x) (cdr x)) (error 'fail)))
>
> and
>
> (unless (pair? x) (error 'fail))
> (define a (car x))
> (define b (cdr x))
>
> `match-define` generates the first snippet, but the second performs
> significantly faster. I would like the optimizer to transform the
> first into the second, however, since `match-define` has to support
> this program:
>
> (match-define (list (cons a b)) ...)
>
> which would expand to:
>
> (define-values (a b) (if (and (pair? x) (null? (cdr x)) (let ([car-x
> (car x)]) (if (pair? car-x) (values (car car-x) (cdr car-x)) (error
> 'fail)) (error 'fail2)
>
> which is much harder (although of course not impossible) to transform
> into a series of definitions.
>
> `match-define` also has the additional complication that the
> identifiers being defined should be in scope in the expression
> defining them, which also makes doing this transformation in
> `match-define` harder.
>
> Sam

-- 
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] Get number of CPUs / Cores

[Zelphir Kaltstahl]

Yes that seems to be it, thanks!

-- 
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: Decision Tree in Racket - Performance

[Sam Tobin-Hochstadt]

On Thu, Jul 27, 2017 at 8:36 PM, Robby Findler
 wrote:
> I see from raco demod that match-define does not generate very
> beautiful code, which leads me to this version (which is what I think
> match-define should have expanded into). It seems to be about 4x
> faster on my computer.

Unfortunately, I don't think `match-define` can avoid the use of
multiple values here. What you're seeing is the difference between:

(define-values (a b) (if (pair? x) (values (car x) (cdr x)) (error 'fail)))

and

(unless (pair? x) (error 'fail))
(define a (car x))
(define b (cdr x))

`match-define` generates the first snippet, but the second performs
significantly faster. I would like the optimizer to transform the
first into the second, however, since `match-define` has to support
this program:

(match-define (list (cons a b)) ...)

which would expand to:

(define-values (a b) (if (and (pair? x) (null? (cdr x)) (let ([car-x
(car x)]) (if (pair? car-x) (values (car car-x) (cdr car-x)) (error
'fail)) (error 'fail2)

which is much harder (although of course not impossible) to transform
into a series of definitions.

`match-define` also has the additional complication that the
identifiers being defined should be in scope in the expression
defining them, which also makes doing this transformation in
`match-define` harder.

Sam

-- 
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] Help: How to check a typed/racket type in an untyped Racket contract?

[Sam Tobin-Hochstadt]

One other suggestion: you can use `define-predicate` in a Typed Racket
module to create a predicate for any type that can be checked
immediately. So

```
(define-predicate dist? (Discrete-Dist Your-Type-Here))
```

should define the predicate you want.

Sam

On Fri, Jul 28, 2017 at 10:23 AM, James Geddes  wrote:
> This is likely a typed-untyped interface newbie question.
>
> Briefly, how can I write a contract that asserts that some value has a type 
> that is defined in an imported typed/racket library?
>
> In more detail, I am using the math/distributions library, which is written 
> in typed/racket. My module is written in untyped Racket, and I'm figuring out 
> how to use contacts:
>
> #lang racket
> (require math/distributions) ;; this is a typed/racket library
>
> (define my-dist (discrete-dist '(thing-one thing-two)))
>
> (provide (contract-out [my-dist ???]))
>
>
> The question is: what should ??? be?. There is a distribution? predicate but 
> I'd quite like to be more specific: namely, that my-dist is a discrete 
> distribution. In the source of math/distributions, the following type is 
> defined:
>
> (define-type (Discrete-Dist A) (discrete-dist-struct A A))
>
> but I don't know how this might translate into my untyped module.
>
>
> Any help much appreciated!
>
> James
>
>
>
>
> ---
> James Geddes
>
> --
> 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.

-- 
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] A bug in the Typed Racket system?

[Sam Tobin-Hochstadt]

The reason that Typed Racket chooses the istantiation `Nothing` here
is that because `a` is used in both a positive and negative position
(both as an input and an output) in the type of the `val` field,
there's no way to pick a "best" choice for `a`. `(Foo Integer)` is not
a subtype of `(Foo Any)`, for example. Furthermore, whatever Typed
Racket chooses for `a`, the function application will type check.
Typed Racket therefore picks the smallest type that works, which is
`Nothing`.

This actually tells you more about your second program -- in
particular, you can't ever call the `val` function from the `(Foo a)`,
because you can't construct a value of type `a`.

Sam

On Fri, Jul 21, 2017 at 1:40 PM, Sourav Datta  wrote:
> On Friday, July 21, 2017 at 9:06:16 PM UTC+5:30, Ben Greenman wrote:
>> Type inference is failing you again.
>
> Yes, well, that seems to be a common theme whenever I hover around the these 
> type of areas which are uncommon but works perfectly fine in untyped Racket.
>
>>
>>
>> If you instantiate `foo/s`, you get the type you expect:
>>
>>
>>
>> #lang typed/racket
>>
>>
>> (struct (a) Foo ([val : (-> a a)]))
>>
>>
>> (: foo/s (All (a b)
>>   (-> (-> a b)
>>   (-> (Foo a)
>>   (Foo b)
>>   (Foo b)
>> (define (foo/s f)
>>   (λ ([f1 : (Foo a)]
>>   [f2 : (Foo b)])
>> f2))
>>
>>
>>
>>
>> (define r1 (#{foo/s @ Integer String} (λ ([x : Integer]) (format "~a" x
>>
>> ;> r1
>> ;- : (-> (Foo Integer) (Foo String) (Foo String))
>
> Yes, that works fine. For my personal use it is good enough, but exporting 
> that function as a library would require every user to annotate the type 
> whenever they want to call it, even for very simple types - which is not a 
> very good experience for a typed language.
>
>>
>>
>>
>>
>> I wouldn't call this a bug, but it's definitely a program that a better type 
>> inferencer should accept.
>
> In other cases where type inference fails, the compiler bails out with an 
> error (even though that is a confusing one like `expected: (Seq a) given: 
> (Seq Integer)`). But here:
>
> 1. The inference did not fail but assumed it's Nothing just because I changed 
> the function signature from (-> a) to (-> a a). I can't understand why the 
> inference fails for this change. And on top of this,
>
> 2. The function type is clearly specified as (-> (Foo a) (Foo b) (Foo b)) and 
> it can unify a = Integer, b = String, from the first argument alone. So, even 
> though a is Integer, it still produces a = Nothing, without a compile error. 
> Integer =/= Nothing. Seems very close to a bug in the type deduction 
> algorithm.
>
>
>>
>>
>> On Fri, Jul 21, 2017 at 5:19 AM, Sourav Datta  wrote:
>> Consider this program,
>>
>>
>>
>> #lang typed/racket
>>
>>
>>
>> (struct (a) Foo ([val : (-> a)]))
>>
>>
>>
>> (: foo/s (All (a b)
>>
>>   (-> (-> a b)
>>
>>   (-> (Foo a)
>>
>>   (Foo b)
>>
>>   (Foo b)
>>
>> (define (foo/s f)
>>
>>   (λ ([f1 : (Foo a)]
>>
>>   [f2 : (Foo b)])
>>
>> f2))
>>
>>
>>
>>
>>
>> (define r1 (foo/s (λ ([x : Integer]) (format "~a" x
>>
>>
>>
>> The type of r1 is correctly deduced as:
>>
>>
>>
>> - : (-> (Foo Integer) (Foo String) (Foo String))
>>
>> #
>>
>>
>>
>> However, if I slightly change the struct Foo and do the same, like this:
>>
>>
>>
>> #lang typed/racket
>>
>>
>>
>> (struct (a) Foo ([val : (-> a a)]))
>>
>>
>>
>> (: foo/s (All (a b)
>>
>>   (-> (-> a b)
>>
>>   (-> (Foo a)
>>
>>   (Foo b)
>>
>>   (Foo b)
>>
>> (define (foo/s f)
>>
>>   (λ ([f1 : (Foo a)]
>>
>>   [f2 : (Foo b)])
>>
>> f2))
>>
>>
>>
>>
>>
>> (define r1 (foo/s (λ ([x : Integer]) (format "~a" x
>>
>>
>>
>> Now, r1 has this type:
>>
>>
>>
>> - : (-> (Foo Nothing) (Foo String) (Foo String))
>>
>> #
>>
>>
>>
>> Surprisingly (Foo Integer) has changed to (Foo Nothing)! Is this a possible 
>> bug in the type system? Or, may be I'm missing something?
>>
>>
>>
>> Thanks!
>>
>>
>>
>> --
>>
>> 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...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.

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

Re: [racket-users] Get number of CPUs / Cores

[Jon Zeppieri]

On Tue, Aug 8, 2017 at 4:56 PM, Zelphir Kaltstahl
 wrote:
> I want to parallelize some program using places, so actually using multiple 
> cores.
>
> To parallelize as much as possible on any given machine, I'd like to know how 
> many cores + effect of hyperthreading there are.
>
> For example I have a CPU with 2 cores, but it supports hyperthreading, so 
> that I can run 4 processes concurrently. The desired result would then be 4 
> instead of 2.

I think `processor-count` does that:
http://docs.racket-lang.org/reference/futures.html?q=processor-count#%28def._%28%28lib._racket%2Ffuture..rkt%29._processor-count%29%29

-- 
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] Get number of CPUs / Cores

[Zelphir Kaltstahl]

I want to parallelize some program using places, so actually using multiple 
cores.

To parallelize as much as possible on any given machine, I'd like to know how 
many cores + effect of hyperthreading there are.

For example I have a CPU with 2 cores, but it supports hyperthreading, so that 
I can run 4 processes concurrently. The desired result would then be 4 instead 
of 2.

At the moment I have the following code, but don't know if this code is at all 
reliable or a good practice:

~~~
(require cpuinfo)
(define (get-number-parallel-units)
  (define (find-siblings remaining-core-info)
(cond [(empty? remaining-core-info) empty]
  [(equal? (car (first remaining-core-info)) 'siblings)
   (string->number (cdr (first remaining-core-info)))]
  [else
   (displayln "not:")
   (displayln (car (first remaining-core-info)))
   (find-siblings (rest remaining-core-info))]))
  (find-siblings (car (get-cpuinfo
~~~

Then with the number of possible maximum number of concurrent processes, I want 
to dynamically create places:

~~~
(let
  ;; dynamically create places
  ([places (for/list ([i (in-range PLACES-COUNT)])
 (dynamic-place "place-worker.rkt" 'place-main))]
   [chunk-size (/ MAX PLACES-COUNT)])
;; give places work to do ...
)
~~~

So what is the best and most reliable way to figure out how many processes can 
run concurrently? (I assume that is the same number as "How many places are 
worth it?")

-- 
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] DSLDI 2017: Final Call for Talk Proposals (deadline extended)

[Lindsey Kuper]

*
FINAL CALL FOR TALK PROPOSALS

DSLDI 2017

Fifth Workshop on
Domain-Specific Language Design and Implementation

October 22, 2017
Vancouver, Canada
Co-located with SPLASH

http://2017.splashcon.org/track/dsldi-2017
https://twitter.com/wsdsldi
*

**Deadline for talk proposals extended to Friday, 11 August 2017**

Well-designed and implemented domain-specific languages (DSLs) can
achieve both usability and performance benefits over general-purpose
programming languages. By raising the level of abstraction and
exploiting domain knowledge, DSLs can make programming more
accessible, increase programmer productivity, and support
domain-specific optimizations.

## Workshop Goal

Domain-Specific Language Design and Implementation (DSLDI) is a
workshop intended to bring together researchers and practitioners
interested in discussing how DSLs should be designed, implemented,
supported by tools, and applied in realistic contexts. The focus of
the workshop is on all aspects of this process, from soliciting domain
knowledge from experts, through the design and implementation of the
language, to evaluating whether and how a DSL is successful. More
generally, we are interested in continuing to build a community that
can drive forward the development of modern DSLs.

## Workshop Format

DSLDI is a single-day workshop and will consist of an invited speaker
followed by moderated audience discussions structured around a series
of short talks. The role of the talks is to facilitate interesting and
substantive discussion. Therefore, we welcome and encourage talks that
express strong opinions, describe open problems, propose new research
directions, and report on early research in progress.

Proposed talks should be on topics within DSLDI’s area of interest,
which include but are not limited to:

  * solicitation and representation of domain knowledge
  * DSL design principles and processes
  * DSL implementation techniques and language workbenches
  * domain-specific optimizations
  * human factors of DSLs
  * tool support for DSL users
  * community and educational support for DSL users
  * applications of DSLs to existing and emerging domains
  * studies of usability, performance, or other benefits of DSLs
  * experience reports of DSLs deployed in practice

## Call for Talk Proposals

We solicit talk proposals in the form of short abstracts (max. 2
pages). A good talk proposal describes an interesting position, open
problem, demonstration, or early achievement. The submissions will be
reviewed on relevance and clarity, and used to plan the mostly
interactive sessions of the workshop day. Publication of accepted
abstracts and slides on the website is voluntary.

* Deadline for talk proposals: August 11th, 2017
* Notification: September 11th, 2017
* Workshop: October 22nd, 2017
* Submission website: https://dsldi17.hotcrp.com/

## Workshop Organization

Co-chairs:

* Lindsey Kuper (lind...@composition.al), Intel Labs
* Eric Walkingshaw (eric.walkings...@oregonstate.edu), Oregon State
University

Follow us on Twitter at https://twitter.com/wsdsldi

Program committee:

* Nada Amin (EPFL/University of Cambridge)
* Eric Holk (Google)
* Gabriele Keller (Data61, CSIRO (formerly NICTA) and UNSW)
* Rebekah Leslie-Hurd (Intel Labs)
* Chris Martens (NCSU)
* Lee Pike (Galois)
* Jonathan Ragan-Kelley (UC Berkeley)
* Jesús Sánchez Cuadrado (Autonomous University of Madrid)
* Vincent St-Amour (Northwestern University)
* Philip Wadler (University of Edinburgh)

-- 
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] table lookup shorthands?

[Luis Sanjuán]

On Tuesday, August 8, 2017 at 3:16:46 PM UTC+2, Alex Knauth wrote:
> > On Aug 8, 2017, at 8:15 AM, Luis Sanjuán  wrote:
> > 
> > Hi, phillip
> > 
> > As far as I'm concerned, professional musician too, I wrote a little app, 
> > just a prototype, using a similar representation of pitch classes and 
> > intervals for basic chord analysis. Since actual chords can be seen as 
> > sequences of intervals, its analysis can be reduced to determine the chord 
> > patterns actual chords match. This leads to at least all possible 
> > interpretations. Further work, some AI for sure, would be needed to select 
> > proper interpretations. Without that, though, a summary of possible matches 
> > cuold be as is useful for students in the first years of Harmony
> 
> I've been trying to do something similar, representing chord-kinds as 
> sequences of intervals and matching the possible chord patterns to the notes.
> 
> I've been basing it on the chord-labeling algorithm in a paper I found, 
> "Algorithms for Chordal Analysis" by Bryan Pardo and William P. Birmingham, 
> but there are a few situations where this doesn't label the correct chord. In 
> particular when there are something like short arpeggios in the harmony and 
> longer passing tones or suspensions in the melody, it gives more weight to 
> the passing tones and suspensions.
> 
> Is that similar to the strategy you used? Is there any way to deal with 
> passing tones like this?
> 
> Alex Knauth

Hi Alex.

BTW, I have just skim over your music-theory code in github. You have already 
done a really great work there! Hope having the time to look into it deeper. 
Thanks for sharing.

-- 
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] table lookup shorthands?

[Luis Sanjuán]

On Tuesday, August 8, 2017 at 3:16:46 PM UTC+2, Alex Knauth wrote:
> > On Aug 8, 2017, at 8:15 AM, Luis Sanjuán  wrote:
> > 
> > Hi, phillip
> > 
> > As far as I'm concerned, professional musician too, I wrote a little app, 
> > just a prototype, using a similar representation of pitch classes and 
> > intervals for basic chord analysis. Since actual chords can be seen as 
> > sequences of intervals, its analysis can be reduced to determine the chord 
> > patterns actual chords match. This leads to at least all possible 
> > interpretations. Further work, some AI for sure, would be needed to select 
> > proper interpretations. Without that, though, a summary of possible matches 
> > cuold be as is useful for students in the first years of Harmony
> 
> I've been trying to do something similar, representing chord-kinds as 
> sequences of intervals and matching the possible chord patterns to the notes.
> 
> I've been basing it on the chord-labeling algorithm in a paper I found, 
> "Algorithms for Chordal Analysis" by Bryan Pardo and William P. Birmingham, 
> but there are a few situations where this doesn't label the correct chord. In 
> particular when there are something like short arpeggios in the harmony and 
> longer passing tones or suspensions in the melody, it gives more weight to 
> the passing tones and suspensions.
> 
> Is that similar to the strategy you used? Is there any way to deal with 
> passing tones like this?
> 
> Alex Knauth

Regarding passing notes and suspensions, it occurs to me that one could try to 
mimic the way musicians cope with them. If your chord patterns don't include 
too many varieties, one would get more than a few 'unknown' chords. Still one 
could later decide from the context, so if, for instance, most of the chord 
progression in which the unknown chord is inserted can be labeled, one could 
discard or label those added notes in the unknown chord as 'ornaments' and 
label the chord accordingly.

-- 
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: Does anyone have experience with GObject Introspection?

[David Storrs]

Thanks, Greg.  This looks useful; we'll check through it and then probably
come back with more questions.

On Mon, Aug 7, 2017 at 3:58 PM, Greg Trzeciak  wrote:

> On Monday, August 7, 2017 at 8:07:02 PM UTC+2, David K. Storrs wrote:
> > We're trying to work with the gir module and GOI in general and finding
> it pretty heavy going.  Can anyone recommend a really good tutorial on GOI
> in general and ideally on using it from Racket?  Also, can anyone explain
> how to generate a typelib file?  For the life of me I cannot figure that
> one out.
>
> Have you seen https://github.com/mwunsch/overscan ?
> One of it's module provides dynamic Racket bindings to GObject
> Introspection.
>
> --
> 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.
>

-- 
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] table lookup shorthands?

[Luis Sanjuán]

On Tuesday, August 8, 2017 at 3:16:46 PM UTC+2, Alex Knauth wrote:
> > On Aug 8, 2017, at 8:15 AM, Luis Sanjuán  wrote:
> > 
> > Hi, phillip
> > 
> > As far as I'm concerned, professional musician too, I wrote a little app, 
> > just a prototype, using a similar representation of pitch classes and 
> > intervals for basic chord analysis. Since actual chords can be seen as 
> > sequences of intervals, its analysis can be reduced to determine the chord 
> > patterns actual chords match. This leads to at least all possible 
> > interpretations. Further work, some AI for sure, would be needed to select 
> > proper interpretations. Without that, though, a summary of possible matches 
> > cuold be as is useful for students in the first years of Harmony
> 
> I've been trying to do something similar, representing chord-kinds as 
> sequences of intervals and matching the possible chord patterns to the notes.
> 
> I've been basing it on the chord-labeling algorithm in a paper I found, 
> "Algorithms for Chordal Analysis" by Bryan Pardo and William P. Birmingham, 
> but there are a few situations where this doesn't label the correct chord. In 
> particular when there are something like short arpeggios in the harmony and 
> longer passing tones or suspensions in the melody, it gives more weight to 
> the passing tones and suspensions.
> 
> Is that similar to the strategy you used? Is there any way to deal with 
> passing tones like this?
> 
> Alex Knauth

Looks interesting! Mine, written in a couple of days, is much simpler. It just 
arranges chords to match chord patterns (what Pardo an Birmingham call 
templates, as I read) and labels them accordingly. First, it assumes chord 
boundaries are given, say, for instance, each arpeggio of Bach's Prelude I in 
das Wohltemperierte Klavier, and there is no attempt to score alternatives.

The task in a real world scenario looks really demanding. Although I've never 
thought of it, for what I've skim-read I agree with P and B that, first, we 
need ways to determine chord boundaries, and secondly, algorithms to score 
possible interpretations. And, at first glance, it seems to me that both tasks 
cannot be completely isolated, since boundaries may depend on the 
interpretation. On the other hand, even chord patterns (which of them are 
suitable and the probability of its occurrence) may differ according to the 
historic and stylistic context, even by composer, as it is actually the case in 
real music.

-- 
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] table lookup shorthands?

[Alex Knauth]

> On Aug 8, 2017, at 8:15 AM, Luis Sanjuán  wrote:
> 
> Hi, phillip
> 
> As far as I'm concerned, professional musician too, I wrote a little app, 
> just a prototype, using a similar representation of pitch classes and 
> intervals for basic chord analysis. Since actual chords can be seen as 
> sequences of intervals, its analysis can be reduced to determine the chord 
> patterns actual chords match. This leads to at least all possible 
> interpretations. Further work, some AI for sure, would be needed to select 
> proper interpretations. Without that, though, a summary of possible matches 
> cuold be as is useful for students in the first years of Harmony

I've been trying to do something similar, representing chord-kinds as sequences 
of intervals and matching the possible chord patterns to the notes.

I've been basing it on the chord-labeling algorithm in a paper I found, 
"Algorithms for Chordal Analysis" by Bryan Pardo and William P. Birmingham, but 
there are a few situations where this doesn't label the correct chord. In 
particular when there are something like short arpeggios in the harmony and 
longer passing tones or suspensions in the melody, it gives more weight to the 
passing tones and suspensions.

Is that similar to the strategy you used? Is there any way to deal with passing 
tones like this?

Alex Knauth

-- 
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: table lookup shorthands?

[Luis Sanjuán]

Hi, phillip

As far as I'm concerned, professional musician too, I wrote a little app, just 
a prototype, using a similar representation of pitch classes and intervals for 
basic chord analysis. Since actual chords can be seen as sequences of 
intervals, its analysis can be reduced to determine the chord patterns actual 
chords match. This leads to at least all possible interpretations. Further 
work, some AI for sure, would be needed to select proper interpretations. 
Without that, though, a summary of possible matches cuold be as is useful for 
students in the first years of Harmony

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