Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.prolog > #14662

Corr. Re: Pointed intervals to the rescue [Make CLAM great again] (Was: Can CLAM do bidrectional rounding?)

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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