Re: The IDS, the EDS and the DBMS
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Tue, 14 Sep 2004 08:34:17 +0200
Message-ID: <414690ee$0$78738$e4fe514c_at_news.xs4all.nl>
> Yes.
>
>
> There is only one way to do it, which is not to evaluate the expression,
> but keep it as an expression: so sqrt(2) remains exactly "sqrt(2)" internally,
> so that if you were to square that expression, you'd get exactly two.
> No programming language I know of does this,
>
> If it provides no particular benefits, and adds complexity, then
> it shouldn't be done. I'm not clear whether it provides any
> benefits; it certainly adds complexity, and the canonical
> example doesn't work!
>
> Au contraire! Any language with a true rational type
> will handle this just fine. I believe Lisp and various
> other languages provide this.
>
> IIRC TTM explicitly states that the implementation of a UDT
> should be in a different language than the application language.
Date: Tue, 14 Sep 2004 08:34:17 +0200
Message-ID: <414690ee$0$78738$e4fe514c_at_news.xs4all.nl>
Marshall Spight wrote:
> mAsterdam wrote:
>>Marshall Spight wrote: >>>erk wrote: >>> >>>>Type implementation; I think Date had it right in suggesting that type >>>>implementations could be done in a variety of languages, and even that >>>>those languages might be different than those used in the rest of the >>>>app... >>> >>>I don't see any value to Date's position here. His canonical polar/rectangular >>>point example is uninspiring: you can't even represent (1,1) precisely >>>in polar; you can't represent (45 degrees, 1) in rectangular. >> >> > type definition is an area where you can't get away from the >> > limitations of the underlying data structure. >> >>Is this your reasoning? : >>To represent polar(45,1) as a cartesian(x,x) we would need an exact >>way to represent the square root of 2. We don't have that so >>"you can't represent (45 degrees, 1) in rectangular."
> Yes.
>
>>That begs the question: why, exactly? or: is it really impossible?
>
> There is only one way to do it, which is not to evaluate the expression,
> but keep it as an expression: so sqrt(2) remains exactly "sqrt(2)" internally,
> so that if you were to square that expression, you'd get exactly two.
> No programming language I know of does this,
The generalized notion would be: Inverse operations are not to be relied upon to result in the original value. ("It's inverse operations, Jim, but not as we know it"). It appears that a type system using multiple possible representations needs reliable inversion of operations.
> but I believe Mathematica does.
>
> Other than that, yes, it really is impossible.
>
>>And, related: is this an implementation issue or a type-model issue? >>And: is the (current) impossibilty of an implementation enough >>reason to abandon a model?
>
> If it provides no particular benefits, and adds complexity, then
> it shouldn't be done. I'm not clear whether it provides any
> benefits; it certainly adds complexity, and the canonical
> example doesn't work!
Yet?
>>((10 divided by 3) times 3) does not give you 10 in any >>programming language (barring optimization effects :-) >>It does not realy stop us from thinking of these operators >>as the ones we are familiar with from math.
>
> Au contraire! Any language with a true rational type
> will handle this just fine. I believe Lisp and various
> other languages provide this.
Ah! Good. Thanks.
> The difference here is between rationals and irrationals;
> rationals present no huge difficulties but irrationals
> cannot be represented extensionally in finite space.
>> >>>And Date's idea that there *not be* a way to define new types in >>>the application language is disastrous! >> >>Are you sure? >>D&D Tutorial D supports UDT's (User Defined Types) - >>or am I misunderstanding your statement?
>
> IIRC TTM explicitly states that the implementation of a UDT
> should be in a different language than the application language.
I won't outguess you :-) Anyone has a reference? Received on Tue Sep 14 2004 - 08:34:17 CEST