Re: Value
Date: Sun, 24 Feb 2008 11:53:33 +0100
Message-ID: <11cl158crw55k.1mp379g9xtios.dlg_at_40tude.net>
On Sat, 23 Feb 2008 22:29:05 +0100, mAsterdam wrote:
>> mAsterdam wrote: >>> Dmitry A. Kazakov wrote: >>>> "Value" in this context is a CS term. >>> I am currently trying to find a helpful piece of text for the cdt >>> glossary. >>> From what I read at >>> http://en.wikipedia.org/wiki/Value_%28computer_science%29 , >>> Value looks like a rather controversial CS term. >> >> I don't see it controversial.
>
> You must have not yet read
> http://en.wikipedia.org/wiki/Talk:Value_%28computer_science%29
>
>> I understand why you might dislike it.
>
> The definiens starts with "a sequence of bits". This excludes
> analog computers.
Analog computers is an interesting beast. I am not familiar to any research on this topic, so I can only guess that they aren't Turing-complete, yet can solve some problems which digital computers cannot.
As for "sequence of bits", it can be replaced by more general "representation". Then one should try to identify higher abstraction layers in analog computer programs. Last time I saw an analog computer, they had something like reusable blocks, which we could call subprograms. No, I don't think that excludes analog computers.
Languages like MATLAB/Simulink or DiaDem resemble analog computers. It is true that they lack any elaborated type system (which makes them extremely uncomfortable). But I think a type system could be introduced there.
> I do think 'value' has meaning, within
> informatics outside the very limited context the wikipedia
> page currently adopts to define it.
>
> Is this your understanding? Clever! ;-)
No, as I said it looks clumsy, but it captures the essentials - typing and independence on the representation. The same "sequences" may mean different values.
>> I support it for the same reason: >> it clearly, though maybe clumsy, states that 1 integer is not 1 float.
>
> That is a (so ISTM) misguided attempt to hide the
> concept of 'value' behind Type. What is Type IYO?
values + operations
Yes in some sense type overshadows values, and sets of types do it even more. But note it is a general idea of programming. You write an algorithm (program) that works on any inputs (values) restricted to some set. It is an abstraction of concrete values to a more general case.
>>> Do you have a better reference? >> >> You mean one, that would support claims of DB-folks? (:-))
>
> I wouldn't have xposted if that would be the case.
> Disclosure: Though I would be happy to have a description,
> acceptable to cdt, it is not my motivation for this post
> (you are aware of that but hey, this is a public forum).
(I still saw no articulated explanation why the notion I have used would not fit DB/DBMS purpose. I guess people think that there should be objective reasons for that, I mean, apart from us (the "OO propellerheads") being idiots...)
>> ------------- >> Honestly, I wonder how one could define values otherwise >> while preserving types.
>
> Ah, ok.
>
>> Let me elaborate it a bit informally. The idea of type in >> mathematics was introduced to get rid of antinomies. In CS it is the same >> idea with antinomies extended to the cases of incomputability. We cannot >> judge about equivalences of entities. It could turn undecidable or simply >> too expensive.
>
> So far so good.
>
>> So we just don't.
>
> What 'we' don't do is define value, right?
> Who is the 'we' here? Type theorists in math and CS?
> Constructivists? OO folk? co?
'we' is a figure of speech addressed to a benevolent reader. (Should I have used "all progressive mankind" instead? (:-))
>> We define entities being values with a >> type assigned to them, merely in order to be able to distinguish them >> *without* computing P(v1=v2). That's the whole idea. Therefore if a v1 is >> of the circle type and v2 is of the ellipse type, that makes them >> automatically distinct. Just *per* construction. This has nothing to do >> with geometry. It is CS.
>
> Hm... opening the circles & ellipses wormcan again.
> LSP is about behaviour, program correctness, not about values, right?
> (I did not read the original paper)
About relations between sets of values.
Certainly some behavior could be expressed as individual values, like Euler's great exp(j Pi)+1=0.
> How would you go about explaining this to a geometrist?
> By rejecting the notion of shape (like your rejection of the notion of
> data)? This creates a whole new perspective on the Disney song:
> "Īt's a small world after all!".
I bet a geometer would immediately capture it. They don't care about individual figures. Shape is like a type. Books on geometry are full groups, equations, transformations, all the stuff 'we' could call behavior.
> The loss of rejecting notions, central to other groups is clear.
> The ability to communicate ideas outside the faculty vanishes.
> So what is the gain (except idiosyncrasy)?
I don't think it is any loss for c.d.t. Do you really care about individual records in the DB? What about RA? Does RA require "glass values?"
BTW 1. I don't claim that values do not exist, only that they are atomic and cannot be considered in isolation to the corresponding type.
BTW 2. It seems that 'you' guys simply want some sort of structural equivalence. I don't understand why, because my impression is that RA does not need this. Anyway you can have it on top plus whatever declarative stuff pleases you. (This is the type/value inference wormcan (:-))
>> Now, when applied to geometry one could reasonably wish v1 and v2 >> interchangeable in some contexts. That is called substitutability. Note >> that substitutability assumes that you substitute *one* thing for >> *another*.
>
> So, it is a desirable property in some OO contexts.
> How is this relevant to wether to define value or not?
> Where is the dreaded antinomy? Why is it so dreaded?
Structural equivalence. If you declare values same, it is an obligation to provide them same per construction or else to keep on proving differently constructed values same. As for antinomies, many things just cannot be same. For example no set can be a member of its own. Yet 'we' like to see a widget type capable to contain instances of itself. Programming is full of self-recursive constructs of all kinds. 'We' need mappings instead of physical subsetting in order to stay consistent.
>> So these are *different* things. Substitutability of circle for >> ellipse is a CS model of circles being a subset of ellipses. Note, just a >> model of. No physical subsets involved, though not excluded, when for >> example, circle would inherit the representation of ellipse. Moreover any >> such model is necessary inadequate as a trivial Circle/Ellipse analysis >> shows. So, why all this rant? >> >> Just one final stab. Observe that this framework does not exclude >> "physical" subsets. Neither it specifies the sets where values come from. >> This automatically makes it more general than any other model based on >> subsets of values. Whatever you could do on that basis is already included.
>
> No shapes, no data, no value - three victims already.
> What's the next concept we'll have to ditch avoiding antinomies?
Value is still here. Data, yes, it looks superfluous. To me what you call data is a value of some variable. Shape never was here anyway.
BTW 3. Did you notice that disgusting axiomatic set theory? What a horror, they don't even have numbers! (:-))
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Sun Feb 24 2008 - 11:53:33 CET