Re: Should we be touching goops?

On 2022-06-06 6:34 pm, David Kastrup wrote: I saw no point in letting the division of Moments deliver a Moment like ly:moment-div does, so ly:moment-main fetches the resulting rational. Returning a Moment would be just meaningless. While I objected to distinguishing time spans from time points

Re: Should we be touching goops?

Aaron Hill writes: > On 2022-06-06 5:24 pm, David Kastrup wrote: >> Putting a bit more meat on what this may mean: >> > > This certainly lends some brevity being able to use operators rather > than named procedures. Providing all this

Re: Should we be touching goops?

On 2022-06-06 6:19 pm, Aaron Hill wrote: That said, I did find one surprise looking at [1]. I would not have expected 1+ (increment) to work without some way of Scheme knowing how to construct unity for a given type. Am I just overlooking where such a is being specified? Or is there supposed

Re: Should we be touching goops?

On 2022-06-06 5:24 pm, David Kastrup wrote: Putting a bit more meat on what this may mean: This certainly lends some brevity being able to use operators rather than named procedures. Providing all this is firstly correct and

Re: Should we be touching goops?

David Kastrup writes: > GOOPS was supposed to cause quite a performance hit with Guile 1.8 when > used extensively. It wasn't supposed to do this with Guile 2+ so > something like this should be feasible, also for other types: > > #(use-modules (oop goops)) > > #(define (class-of

Re: Should we be touching goops?

Le 05/06/2022 à 21:52, David Kastrup a écrit : Dan Eble writes: On Jun 5, 2022, at 08:36, David Kastrup wrote: While I agree with Dan that at the current point of time Moment is definitely overloaded too much (this has historical reasons since it had been the _only_ Scheme-accessible

Re: Should we be touching goops?

Christopher Heckman writes: > David Kastrup wrote: > >> Frankly, that's academic. It reminds me of the excessive amount of >> energy placed into keeping the mathematics(!) of location vectors and >> difference vectors separate. > > When you ask the question, "What does the sum of two vectors

Re: Should we be touching goops?

Le 05/06/2022 à 22:08, Christopher Heckman a écrit : David Kastrup wrote: Frankly, that's academic. It reminds me of the excessive amount of energy placed into keeping the mathematics(!) of location vectors and difference vectors separate. You can definitely represent positions and

Re: Should we be touching goops?

Jean Abou Samra writes: > Le 05/06/2022 à 14:36, David Kastrup a écrit : >> Something like ly:moment-add has fewer implied semantics than + . Not >> just for humans (who expect + to be more-or-less commutative and >> associative even though the latter is only approximately the case with >>

Re: Should we be touching goops?

David Kastrup wrote: > Frankly, that's academic. It reminds me of the excessive amount of > energy placed into keeping the mathematics(!) of location vectors and > difference vectors separate. > You can definitely represent positions and differences in positions as vectors, but there is an

Re: Should we be touching goops?

Dan Eble writes: > On Jun 5, 2022, at 08:36, David Kastrup wrote: >> >> While I agree with Dan that at the current point of time Moment is >> definitely overloaded too much (this has historical reasons since it had >> been the _only_ Scheme-accessible version of the Rational type, with >>

Re: Should we be touching goops?

Le 05/06/2022 à 14:36, David Kastrup a écrit : Something like ly:moment-add has fewer implied semantics than + . Not just for humans (who expect + to be more-or-less commutative and associative even though the latter is only approximately the case with floating point arithmetic) but even for

Re: Should we be touching goops?

On Jun 5, 2022, at 08:36, David Kastrup wrote: > > While I agree with Dan that at the current point of time Moment is > definitely overloaded too much (this has historical reasons since it had > been the _only_ Scheme-accessible version of the Rational type, with > Rational being required before

Re: Should we be touching goops?

On Jun 5, 2022, at 08:36, David Kastrup wrote: > > Right, let me refocus. > That summary is accurate. — Dan

Re: Should we be touching goops?

On Sun, 5 Jun 2022, 17:39 David Kastrup, wrote: > Luca Fascione writes: > > > Oh yes absolutely, the growth is normally much slower than worse case > > unless the addends come from really weird-ass distributions, no doubt. > > Round to even helps a lot with that > > > > And indeed our numbers

Re: Should we be touching goops?

Luca Fascione writes: > Oh yes absolutely, the growth is normally much slower than worse case > unless the addends come from really weird-ass distributions, no doubt. > Round to even helps a lot with that > > And indeed our numbers not coming from measurements will in practice only > have low

Re: Should we be touching goops?

Oh yes absolutely, the growth is normally much slower than worse case unless the addends come from really weird-ass distributions, no doubt. Round to even helps a lot with that And indeed our numbers not coming from measurements will in practice only have low significant bits in a handful of

Re: Should we be touching goops?

Luca Fascione writes: > On Sun, Jun 5, 2022 at 2:12 PM Jean Abou Samra wrote: > >> As David already said, the part of LilyPond we're discussing is using >> rationals. Furthermore, (a + b) + c being close but not equal to >> a + (b + c) for floats is not really an issue for most parts of

Re: Should we be touching goops?

On Sun, Jun 5, 2022 at 2:12 PM Jean Abou Samra wrote: > As David already said, the part of LilyPond we're discussing is using > rationals. Furthermore, (a + b) + c being close but not equal to > a + (b + c) for floats is not really an issue for most parts of LilyPond. > Yes, agreed on all

Re: Should we be touching goops?

Thanks Jean, I had inferred the Guile/Scheme part, nice to have a direct reference to the rational class. As to making a big deal: I can't speak to the impact, was just trying to contribute to the points being raised by various folks. As we want lilypond to backtrack on a decision as little as

Re: Should we be touching goops?

Jean Abou Samra writes: > Le 05/06/2022 à 14:13, David Kastrup a écrit : >> git grep 'ly:moment-\(add\|sub\|mul\|div\|mod\)' >> puts out a good page or so, much of it in articulate.ly and swing.ly. >> Admittedly, both of those files are of the kind we would want to >> encourage people to write,

Re: Should we be touching goops?

Le 05/06/2022 à 14:13, David Kastrup a écrit : git grep 'ly:moment-\(add\|sub\|mul\|div\|mod\)' puts out a good page or so, much of it in articulate.ly and swing.ly. Admittedly, both of those files are of the kind we would want to encourage people to write, and that kind of change makes it more

Re: Should we be touching goops?

Jean Abou Samra writes: > Le 04/06/2022 à 13:16, Luca Fascione a écrit : >> On Sat, Jun 4, 2022 at 12:47 PM David Kastrup wrote: >> >>> LilyPond uses precise arithmetic. >>> >> Thanks David, just out of curiosity, where's a reference to the specific >> implementation we're using? > > > > C++

Re: Should we be touching goops?

Le 04/06/2022 à 12:01, Luca Fascione a écrit : I can't say that I completely follow all that's being discussed here, but I have seen a few statements pass by that I found confusing and it might be of some use that I share some comments based on what I myself have experienced so far. I'll

Re: Should we be touching goops?

Le 04/06/2022 à 13:16, Luca Fascione a écrit : On Sat, Jun 4, 2022 at 12:47 PM David Kastrup wrote: LilyPond uses precise arithmetic. Thanks David, just out of curiosity, where's a reference to the specific implementation we're using? C++ code uses the Rational type, which is

Re: Should we be touching goops?

Immanuel Litzroth writes: > Location vectors and Difference vectors are not kept separate as far > as I can tell. > Affine space keeps points separate from differences of points which > are vectors. > So does common parlance for places/distances and time points/durations. Paris > is not a

Re: Should we be touching goops?

Luca Fascione writes: > On Sat, Jun 4, 2022 at 12:47 PM David Kastrup wrote: > >> LilyPond uses precise arithmetic. >> > > Thanks David, just out of curiosity, where's a reference to the specific > implementation we're using? > > Further, besides the floating point math segment, does the rest

Re: Should we be touching goops?

On Sat, Jun 4, 2022 at 12:47 PM David Kastrup wrote: > LilyPond uses precise arithmetic. > Thanks David, just out of curiosity, where's a reference to the specific implementation we're using? Further, besides the floating point math segment, does the rest feel like it's on target to you?

Re: Should we be touching goops?

Luca Fascione writes: > I can't say that I completely follow all that's being discussed here, but I > have seen a few statements pass by that I found confusing and it might be > of some use that I share some comments based on what I myself have > experienced so far. I'll admit I lost track of

Re: Should we be touching goops?

I can't say that I completely follow all that's being discussed here, but I have seen a few statements pass by that I found confusing and it might be of some use that I share some comments based on what I myself have experienced so far. I'll admit I lost track of who said what, so I'll focus on

Re: Should we be touching goops?

> On Fri, Jun 3, 2022 at 7:21 AM David Kastrup wrote: > Programming languages don't offer different types for distances, > positions, weights, forces, whatnot. It's safe to say that programming languages don't typically don't offer much in the way of types, they do however usually allow you to

Re: Should we be touching goops?

Jean Abou Samra writes: > Nice! I wasn't aware that GOOPS had become faster > in Guile 2, nor even that it supported smob types. > I had stayed in the conception that it was a "don't > use" module. I am not sure how much this may have changed. One would certainly need to check how much it

Re: Should we be touching goops?

Jean Abou Samra writes: > Le 03/06/2022 à 02:32, David Kastrup a écrit : >> GOOPS was supposed to cause quite a performance hit with Guile 1.8 when >> used extensively. It wasn't supposed to do this with Guile 2+ so >> something like this should be feasible, also for other types: >> >>

Re: Should we be touching goops?

Le 03/06/2022 à 02:32, David Kastrup a écrit : GOOPS was supposed to cause quite a performance hit with Guile 1.8 when used extensively. It wasn't supposed to do this with Guile 2+ so something like this should be feasible, also for other types: #(use-modules (oop goops)) #(define (class-of

Re: Should we be touching goops?

Dan Eble writes: > On Jun 3, 2022, at 11:48, David Kastrup wrote: >> >> Programming languages don't offer different types for distances, >> positions, weights, forces, whatnot. When I equate various amounts of > > Bringing the conversation back to a Moment versus the delta between > two

Re: Should we be touching goops?

Dan Eble writes: > At a minimum, we could forego defining (+ Moment Moment) -- or is > there a need to expand the loose dealings of the past into a new area? We don't have a separate data type for time lengths, and I don't really see an expected gain for such a one. > Maybe we could globally

Re: Should we be touching goops?

On Jun 3, 2022, at 11:48, David Kastrup wrote: > > Programming languages don't offer different types for distances, > positions, weights, forces, whatnot. When I equate various amounts of Bringing the conversation back to a Moment versus the delta between two Moments, C++11 has

Re: Should we be touching goops?

On 2022-06-03 8:48 am, David Kastrup wrote: Frankly, that's academic. It reminds me of the excessive amount of energy placed into keeping the mathematics(!) of location vectors and difference vectors separate. Homogenous coordinates: "When in doubt, define a new dimension." :) -- Aaron

Re: Should we be touching goops?

Carl Sorensen writes: > On Fri, Jun 3, 2022 at 7:21 AM David Kastrup wrote: > >> Dan Eble writes: >> >> > On Jun 2, 2022, at 20:32, David Kastrup wrote: >> >> >> >> #(define-method (+ (a ) (b )) (ly:moment-add a b)) >> >> #(define-method (- (a ) (b )) (ly:moment-sub a b)) >> > >> > Could we

Re: Should we be touching goops?

On Fri, Jun 3, 2022 at 7:21 AM David Kastrup wrote: > Dan Eble writes: > > > On Jun 2, 2022, at 20:32, David Kastrup wrote: > >> > >> #(define-method (+ (a ) (b )) (ly:moment-add a b)) > >> #(define-method (- (a ) (b )) (ly:moment-sub a b)) > > > > Could we also introduce a distinction in type

Re: Should we be touching goops?

Dan Eble writes: > On Jun 2, 2022, at 20:32, David Kastrup wrote: >> >> #(define-method (+ (a ) (b )) (ly:moment-add a b)) >> #(define-method (- (a ) (b )) (ly:moment-sub a b)) > > Could we also introduce a distinction in type between points and spans > of time? "Measure 12 minus Measure 8"

Re: Should we be touching goops?

On Jun 2, 2022, at 20:32, David Kastrup wrote: > > #(define-method (+ (a ) (b )) (ly:moment-add a b)) > #(define-method (- (a ) (b )) (ly:moment-sub a b)) Could we also introduce a distinction in type between points and spans of time? "Measure 12 minus Measure 8" is 4 measures, but it is not

Should we be touching goops?

GOOPS was supposed to cause quite a performance hit with Guile 1.8 when used extensively. It wasn't supposed to do this with Guile 2+ so something like this should be feasible, also for other types: #(use-modules (oop goops)) #(define (class-of (ly:make-moment 0)))