Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.prolog > #14662
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Newsgroups | comp.lang.prolog |
| Subject | Corr. Re: Pointed intervals to the rescue [Make CLAM great again] (Was: Can CLAM do bidrectional rounding?) |
| Date | 2025-07-15 01:28 +0200 |
| Message-ID | <10543q1$27vr6$2@solani.org> (permalink) |
| References | (4 earlier) <1050d61$26q6h$1@solani.org> <1050dhh$26qc0$1@solani.org> <1053362$27ctr$1@solani.org> <10533em$27d2s$1@solani.org> <10543ms$27vr6$1@solani.org> |
Typo: Forgot division by two: > 145.6 ~~> [145.55 .. 145.65) ~~> (145.55 + 145.65) = 145.6 > 90 ~~> [89.5 ..90.5) ~~> (89.5 + 90.5) = 90 Should read: 145.6 ~~> [145.55 .. 145.65) ~~> (145.55 + 145.65)/2 = 145.6 90 ~~> [89.5 ..90.5) ~~> (89.5 + 90.5)/2 = 90 Mild Shock schrieb: > Hi, > > My recent thinking is such rounding could have > a place in CLAM (Constraint Logic Abstract Machine), > as part of some interval arithmetic. Particularly > pointed intervals, like 145.6 is basically the > interval [145.55 .. 145.65), > > including the lower bound excluding the upper bound. > The value 145.6 is associated with the interval, and > not some midpoint, has to do that the rounded value is > the associated point. So all values in the interval round to > > the associated rounded value. But I didn’t do a thorough > research yet. It would basically give a different rationalize > and associated interval computation from input, a more business > like rationalize that requires that the number > > scanner tokenizer also records the number of fractional > digits in the input. So that for example 90 and 90.0 are > not the same when it comes to rationalize and associated > interval computation from some given input. > > Most fixnum rounding have midpoint = rounded value: > > 145.6 ~~> [145.55 .. 145.65) ~~> (145.55 + 145.65) = 145.6 > 90 ~~> [89.5 ..90.5) ~~> (89.5 + 90.5) = 90 > > But some rounding, like for example automatically > choosing a scale, i.e. going from bytes to kilo bytes, > mega bytes, giga bytes etc.., many directory listings > can do that when they show a file size, > > I guess the associated intervals and > rounded values are more exotic. > > Bye > > Mild Shock schrieb: >> The conversion factor in the units database is: >> >> ?- qeval(X*1 is mi/km). >> X = 1.609344. >> >> I had first used 1.60934, but then used >> 1.609344. But I think this here is not a >> symmetric answer, and a symmetric answer >> using constraint logic programming >> >> maybe impossible: >> >> ?- qeval((145.6*km =:= 90*usc:mile+quantity Eps, SIEps is Eps in km)). >> Eps = 0.4716455897558234*kind_of(isq:length)[usc:mile], >> SIEps = 0.7590399999999958*kind_of(isq:length)[si:kilo(si:metre)]. >> >> Do you have intervals associated with >> units, so you can write “in km”? >> >> I computes 145.6*km - 90*mile in terms of km, so it computes: >> >> /* Windows 11 Calcultator */ >> 145.6 - 90*1.609344 = 0.75904 >> >> /* SWI-Prolog Evaluator */ >> ?- X is 145.6 - 90*1.609344. >> X = 0.7590399999999988 >> >> So to be correctly rounded to one digit after >> the period, the eps would need to be smaller. But for >> the other direction, whether the conversion >> from km to mile was correct, I guess a >> >> 2nd query would be needed. But still I would >> be interested whether constraint logic programming >> can answer such questions in one query, like >> whether CLAM (the idea of Constraint Logic >> >> Abstract Machines) has a rounding bidirectionality? >> Giving new momentum to the dream that >> CLAM is a silver bullet. >> >> Mild Shock schrieb: >>> Do these units packages define rounding? Is this correct: >>> >>> https://www.shutterstock.com/de/image-photo/road-sign-longest-straight-australia-548866177 >>> >>> >>> I think one way its correct: >>> >>> 145.6 km ÷ 1.609344 km/mile = 90.47 miles >>> >>> The other way its incorrect: >>> >>> 90 miles × 1.609344 km/mile = 144.84 km >>> >>> Mild Shock schrieb: >>>> Hi, >>>> >>>> So how does academic purity compare to industrial >>>> success? Well this talk by Martin Odersky has some >>>> interesting slides comparing past and present: >>>> >>>> Evolving Scala by Martin Odersky | Scalar Conference 2025 >>>> https://www.youtube.com/watch?v=DI0NOh9r1f8 >>>> >>>> Where Scala ranked in 2014, versus where Scala >>>> ranks in 2025. Haskell gone, Clojure gone. >>>> >>>> LoL >>>> >>>> Bye >> >
Back to comp.lang.prolog | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
comp.lang.prolog Frequently Asked Questions Markus Triska <triska@logic.at> - 2024-11-16 05:58 +0000
Amzi! Retirement: 2026 is only next year (Was: comp.lang.prolog Frequently Asked Questions) Mild Shock <janburse@fastmail.fm> - 2025-07-13 15:11 +0200
What does the "Red Tape" on Wayback Machine mean? (Was: Amzi! Retirement: 2026 is only next year) Mild Shock <janburse@fastmail.fm> - 2025-07-13 15:14 +0200
Prolog can keep up with the AI Boom [Forget about CLAM] (Was: What does the "Red Tape" on Wayback Machine mean?) Mild Shock <janburse@fastmail.fm> - 2025-07-13 15:27 +0200
The cult of CLAM / Clojure rewrite utility (Was: Prolog can keep up with the AI Boom [Forget about CLAM]) Mild Shock <janburse@fastmail.fm> - 2025-07-13 15:43 +0200
Australian Longest Straight Road in Prolog (Was: Clojure hasn't gained momentum [Martin Odersky 2025 Talk]) Mild Shock <janburse@fastmail.fm> - 2025-07-14 16:11 +0200
Can CLAM do bidrectional rounding? (Was: Australian Longest Straight Road in Prolog) Mild Shock <janburse@fastmail.fm> - 2025-07-14 16:15 +0200
Pointed intervals to the rescue [Make CLAM great again] (Was: Can CLAM do bidrectional rounding?) Mild Shock <janburse@fastmail.fm> - 2025-07-15 01:26 +0200
Corr. Re: Pointed intervals to the rescue [Make CLAM great again] (Was: Can CLAM do bidrectional rounding?) Mild Shock <janburse@fastmail.fm> - 2025-07-15 01:28 +0200
Sleepy Joe SWI-Prolog still waiting for a PR (Was: Prolog can keep up with the AI Boom [Forget about CLAM]) Mild Shock <janburse@fastmail.fm> - 2025-11-12 01:26 +0100
deep preprocessor =\= term_expansion and/or goal_expansion [SWI-Prolog dicts] Mild Shock <janburse@fastmail.fm> - 2025-11-12 02:18 +0100
There is something like SuperPrologs ? [SWI, ECLiPSe, etc..] (Was: comp.lang.prolog Frequently Asked Questions) Mild Shock <janburse@fastmail.fm> - 2025-07-15 13:24 +0200
Is ISO itself not simply a dialect? (Was: There is something like SuperPrologs ? [SWI, ECLiPSe, etc..]) Mild Shock <janburse@fastmail.fm> - 2025-07-15 13:26 +0200
Pet project Prolog-Omnibus I don't have any time (Was: Is ISO itself not simply a dialect?) Mild Shock <janburse@fastmail.fm> - 2025-07-15 13:31 +0200
ANN: Go Fund Me for ISO Core Standard of Prolog (Re: Is ISO itself not simply a dialect?) Mild Shock <janburse@fastmail.fm> - 2025-10-09 18:10 +0200
Fuck Around and Find Out : SWI-Prolog Forum [Newline FAFO] (Was: ANN: Go Fund Me for ISO Core Standard of Prolog) Mild Shock <janburse@fastmail.fm> - 2025-10-10 09:36 +0200
Most Prolog Systems didn't solve it yet [Timer Trash] (Was: Fuck Around and Find Out : SWI-Prolog Forum) Mild Shock <janburse@fastmail.fm> - 2025-10-10 09:48 +0200
Moron @jp-diegidio clueless about Unicode (UAX#14) [Re: Most Prolog Systems didn't solve it yet [Timer Trash] (Was: Fuck Around and Find Out : SWI-Prolog Forum) Mild Shock <janburse@fastmail.fm> - 2025-10-10 10:22 +0200
ECliPSe Prolog not a SuperProlog (Was: There is something like SuperPrologs ? [SWI, ECLiPSe, etc..]) Mild Shock <janburse@fastmail.fm> - 2025-08-06 08:30 +0200
csiph-web