Re: object system...
- From: "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx>
- Date: Thu, 15 Jan 2009 13:13:18 +0100
On Thu, 15 Jan 2009 10:13:54 +1000, cr88192 wrote:
"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:12cbzc4j7mkdd.1hdv3ksqztptf.dlg@xxxxxxxxxxxxx
On Thu, 15 Jan 2009 00:23:07 +1000, cr88192 wrote:
now, as for the barber:
it is a paradox if both possibilities are to be considered at the same
time (as in an axiom), however if on each day he makes this same decision
(using the prior day as his current status, as is more typical in procedural
logic), then he will only shave every-other day (the axiom will be true
at one try, but false at the next, then true, then false, ...).
He does not make decisions, he makes a statement about decisions. This
statement is self contradictory and thus cannot be used as a basis for
decision making. Other statements could be.
yes, I guess one would have to change the "does" to "did" to really make
this work...
Yes, but then it becomes uninteresting because it lacks its prediction
power. When you write +, you know that + will yield a result in a certain
way. This is the whole idea of programing. If you knew the result, you
would not need to program with +. If + is already executed then you also
know the result. So programming is a promise. But if the promise is that
"it will shave everybody except those who don't shave themselves," then you
or your customers have a problem.
however, as can also be noted, software is based on code, not on abstract
logic...
Well, that is an interesting statement. It is business logic I guess? If
your software is not based on formal logic, then you cannot reason about
it in formal terms. My condolences...
it is based on behavior...
one considers the behaviors that will be exhibited as one feeds in a whole
range of inputs, abstractly considering the input space and the output
space, much like light through a lens or prism...
so, the central aspect is the algorithm, anything works so long as an
algorithm can be made for it, ...
Yes, but you have to define what it does do. You canot do it outside formal
logic. Even the above is actually a logcal statement:
IF P does B AND A is defined as doing B THEN P implements A
if we say that in reality the types do not exist, but are merely
manifestations of the present state, then there is not a problem with
saying that a type is represented by a type...
Where that follows from? Existence in "reality" is irrelevant to the issue
of consistence. Does reality exist?
a type is a logical construct, rather than a physical one, and so if a type
is in conflict, but the physical object exists, one opts with the physical
object. logic is naturally opposed to cyclic dependencies and systems,
whereas physical reality contains them in abundance (as self-reinforcing
patterns...).
In that case you break semantical mapping that a computational object (or
state) corresponds to some definite value. The mapping is the context of
the program. When broken, the computer continues to exist and maybe is
computing something, but nobody can say what. It becomes a chunk of
silicon, plastic and some toxic heavy metals.
but, yes, a relevant phrase here is "I think therefor I am", which could be
reworded: "if I did not exist I could not consider whether or not I exist".
and, so, the existence of reality can be asserted, even as lacking as the
substance of this existence would seem to be at times (for example, that
everything that exists, has this existance based primarily on state, and
that apart from state there is no form either...).
so, taken further, existance can be asserted to exist as an "absolute",
because if it did not exist at any other point along the chain, it would not
exist "here" either...
similar reasoning can also be used for the existence of morals, ...
but, then one can debate whether or not this existence is absolute or
relative, the structure and form in which it all exists, ... (allowing for a
world/truth which is at the same time both relative and absolute, where the
form becomes relative, and anything can be considered as true so long as it
can be reconciled with those things which can be said to exist...).
for example, it is reasonable to describe the sun and stars from a
geocentric perspective, or through the use of analogies and symbolism, and
still regard this as true, but this is limited at which point they come in
conflict with the actual sun and stars (so, a person can correctly describe
them by analogies, but at which point they say that these analogies ARE the
objects they refer to, then the statements are no longer correct).
so, the sun could be said to rise in the east and set in the west, but it is
incorrect to say that the sun orbits the earth (and it is not in conflict to
assert at the same time that the earth orbits the sun, and also that the sun
rises and sets).
There is a fundamental principle that a logical system cannot reason about
itself. So any proposition like exists (self) as well as not esits (self)
is automatically either inconsistent or undecidable. It is a wonder how
humans managed to do this stuff all the time in the history of pilosophy...
(:-))
do you use an interface to access static methods?...
Static method? If you mean C++ static member, that is an artefact of its
poor design, which confuses visibility issues with types.
close enough... I meant like Java and C# static methods, where the class
can be accessed apart from its instance...
What for? If type is not a first-class citizen you cannot do anything
useful with it anyway.
both allow some methods and fields to be called without instancing the
object, these being static fields and methods (in contrast to
instance-fields or virtual functions, which require an instance...).
but, one can't use an interface to access a class by itself, and it does not
make much sense to do so...
Interface too can have some properties defined in terms of third types
which can be queried without any instances. For example an interface of an
abstract modular number, might have a property the modulus. The result is
of a different type of course, than the instances of the interface. Or
consider an array interface. It has an operation that returns the interface
of its index.
In general, types and iterfaces may have operations defined on them as on
first-class objects. These operations comprise type algebra. Usually they
are compile-time functions when types are static.
It makes little sense to allow the programmer to introduce new operations
of this kind. Unless, types become trully first-class.
yet, both tend to use built-in fixed-size types, so the question is whether
the feature in question can deliver these benefits over, for example, what
is possible in the JVM or CIL?...
This is a wrong question. A numeric type is like any other type. Do you
have predefined "emploee" type? It is like to quest what benefits offer
programming, over what? Not programming? It is the program semantics that
determines the type, not the language or its target.
in most mainstream languages, they are not discouraged.
in fact, they are the only things offered.
(:-)) You know, the mainstream languages are quite miserable, and the
current state of software developing is even worse.
maybe, but it goes forwards at a fast pace...
Yes it worsens fast...
lots of people writing software, then rewriting software, making more
software, ...
Writing software to adopt other software, software to maintain software
etc. 80% of this software is just not needed. The system feeds and produces
itself...
Nope, you forgot the rest of ring arithmetic:
a+b mod 20
a*b mod 20
...
20 bits, not base 20...
Yes. 2**20
(a+b)&((1<<20)-1)
(a*b)&((1<<20)-1)
That works only when N = 2**n. It would not do with a week day: Sunday +
one day = Monday.
And sorry, do you call it a language?
?...
I call it MESS.
Anyway, the point is, when you add values to the type, you get another
type. The argument about safe ranges is bogus.
The right technical term is substitutability = preservation of all
propositions about all possible programs using the type. Substitutability
does not hold even with safe ranges. That means, each time when you
replace one type with a machine type you have to analyse each use case of.
one can consider that a 32-bit integer has 32 bits, and usually that seems
sufficient to consider its behavior...
part of its behavior may also be overflow, although personally I feel it is
not a good idea to base algos around particular overflow behavior / ...
(apart from the use of explicit masking), since it could introduce bugs if
more bits are used internally (for example, smaller types may actually
periodically be represented as bigger types, and then re-contracted later,
creating the possibility that overflowed bits might still be in use).
If you ignore overflow exceptions, then necessary, the semantics becomes
one of arbitrary precision integer number. This is a possible way and some
languages go it. But it might be very inefficient and anyway, some
applications need ranged numbers from the application domain.
so, we may have a few rare algos which use 32-bit integers but confine the
operating range to 28 or 30 bits (or even 16 bits for some operations). but,
mostly this is when implementing bignums, which are something better off
implemented in assembler if possible (an ASM-based int128 multiply or divide
is almost invariably faster than a C-based multiply or divide).
another option then is to use 32 bit values, but implement some algos using
64 bit values internally (it is a tradeoff on x86...).
sadly, float128 operations are a bit more complicated, and so I have yet to
write specific ASM versions of the operations...
Yes this is complicated so long you are trying to put it all together into
one numeric type. That is impossible.
So let the programmer decide. Give him ranged numbers, modular numbers and
arbitrary precision ones. He will choose what he actually need. Don't give
him any built-in integer. People are lazy to think. He must be forced to
scratch his head each time he feels a numeric type is necessary. It is a
design decision he must made. If he chooses a ranged integer, then he also
must specify the range, it is a part of the program, not of the language or
an implementation of.
it can also be noted that most processors wont have built-in operations
for these cases anyways (and many expressions in the above would likely be
reduced to constants by the compiler).
Exactly, this is why I want the compiler to implement the semantics of,
instead of writing tons of macros, so typical to C.
but, these sort of features don't come free...
I don't see why. OK, there is certainly language complexity issue and
compiler design ones. However, the text of the Ada language standard is
shorter than one of C++, being much more precise regarding the semantics.
So actually I think that a cleaner semantics pays off both for compiler
vendors and programmers.
Well, if your customers accepted any rubbish, you could use random
generator in order to produce code... (:-))
actually... some of my algos are based on using random number generators...
These use it as an input.
much like hash tables can have almost magical abilities to make code faster,
random number generators can have almost magical ability to make many
self-organizing constructs...
I don't like hash tables. They have an unpredictable behaviour and creating
good hash function requires a lot of work. It cannot be done routinely.
Then binary search containers have some advantages, such as ordering. This
allows to match, say, text against table looking for the longest prefix. To
me this pays off a minor performance hit.
one can also use genetic algorithms, but the problem with these is that they
are both too slow and too limited to really be of much use for solving most
practical problems...
Genetic algorithms is a hype, a very old one, by the way. If I correctly
remember they were first proposed under a different name in 40s-50s, I
don't have the book at hand. They simply cannot work. The problem is that
you need a selection function that decides whether a try was good. In AI
area the complexity of this function is same as one of plain
classification, which was the whole goal of learning. Otherwise any other
method of learning will do better. (:-))
none the less I include some code for both GAs and NNs in my library code,
as there are rare cases where they are useful (one just doesn't want to use
GAs for anything where they need the answer in a reasonable amount of time,
and NNs aren't really applicable to most problems...).
Right, because that was known in 50s too. NN is just another name for that
time "perceptron" which is a linear classifier. As such it simply cannot
separate classes with non-linear edges, for example like one circle put in
another. What do guys do? They use a kernel that linearizes the problem.
And how to find the kernel for a given problem? Right, to think it out and
then to try it on. A great idea, it is the kernel which in fact does the
job. They could try arbitrary classifiers instead, with far less efforts
saving the community and rain forests from tons of quasi-scientific papers
on NN...
The answer is much less efforts. This is the major reason why we chose
Ada.
now, can you convince the rest of the world of this?...
It would be quite useless to try. Software developing industry works in a
way that selects technologically inferior solutions. This includes
languages and libraries. There is no way anybody could change this. Maybe
US Congress could, by making all vendors of commercial software fully
liable. Since we have a global crisis, and many software vendors will
vanish anyway, so it would less painful to do this right now, but surely
they would not. So far I am glad to be able to convince some of our
customers not to push for C. This alone took years for work.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.
- Follow-Ups:
- Re: object system...
- From: cr88192
- Re: object system...
- References:
- object system...
- From: cr88192
- Re: object system...
- From: Dmitry A. Kazakov
- Re: object system...
- From: cr88192
- Re: object system...
- From: Dmitry A. Kazakov
- Re: object system...
- From: cr88192
- Re: object system...
- From: Dmitry A. Kazakov
- Re: object system...
- From: cr88192
- Re: object system...
- From: Dmitry A. Kazakov
- Re: object system...
- From: cr88192
- Re: object system...
- From: Dmitry A. Kazakov
- Re: object system...
- From: cr88192
- Re: object system...
- From: Dmitry A. Kazakov
- Re: object system...
- From: cr88192
- Re: object system...
- From: Dmitry A. Kazakov
- Re: object system...
- From: cr88192
- Re: object system...
- From: Dmitry A. Kazakov
- Re: object system...
- From: cr88192
- Re: object system...
- From: Dmitry A. Kazakov
- Re: object system...
- From: cr88192
- Re: object system...
- From: Dmitry A. Kazakov
- Re: object system...
- From: cr88192
- object system...
- Prev by Date: Re: A hopefully interesting design question ...
- Next by Date: Re: object system...
- Previous by thread: Re: object system...
- Next by thread: Re: object system...
- Index(es):
Relevant Pages
|