|
Re: Will Perl6 be able to do this kind of logic?
by mr_mischief (Monsignor) on Feb 17, 2009 at 19:15 UTC
|
Why settle for three states when you can have a range of confidence? Read up on fuzzy sets.
There are already some calls in Perl (and other languages like C) that return yes/no/error values. This means that if you're handling errors correctly you're already handling three-state logic.
The language itself need not support three-state variables in order for you to write a program with three-state logic. It certainly could help. In the meantime, though, there are positive/negative/zero and less/equal/more available. Integers or even floating point numbers (0 to 1 instead of 0 to infinity) are very useful as truth values or condition markers in some situations.
What you're likely missing isn't a way to represent more than two states in a variable, since lots of data structures and even simple scalars can give you that. What's really handy is an N-way control flow which given/when can provide.
| [reply] |
|
|
Yeah, it would be an useful extra state on the logic chip itself. It would save having to recompute the condition of chips that definitely will not change, from those that don't, or even probability of states. Instead of 0 or 1 volts, you can have a real number range between 0 and 1. Eh....thats probably how the alien computers do it. I feel like a revelation has occurred moving me from binary logic to Real logic. Like lightening's path to the ground.:-)In programming though, the idea can still apply. Suppose everything is an object, and you want to test various scenarios. It would speed up things, if you could identify which object you might be able to change state, and which will be more resistant; you could skip by the more resistent objects, and do faster simulations. Like a "tied object system". It's probably best done in Assembly. It might more closely resemble human thought .....how we mull over various scenarios in our heads.
| [reply] |
|
|
Analog computers are often faster and even more accurate than binary computers on the same problems. The major problems are of reliability of the parts, reproducibility of results, precision (rather than inaccurate answers with good precision they tend to give accurate but imprecise answers), program flexibility (most are designed for the task at hand), space, and cost.
Next to using quantum effects, inserting analog components at just the right part of a computing task might be the best we can do. However, the costs associated with analog computers tend to relegate them to curiosities or simple, fixed applications (like the bimetal thermostat).
The real strengths of binary digital computers are low cost, compact size, and flexibility of purpose. If we could have a reliable multi-state logic gate that fit in the same space as a binary one, cost as little to produce, and took no extra power then that would be great. So far, though, the ranges of voltages idea hasn't been reliable enough. Anything that requires extra hardware for a third state could just as well be used to produce another binary gate.
The same things that are great about binary systems are the things that limit them: smaller, cheaper, faster, more flexible. Your program's logic doesn't need to be limited by
the binary nature of the hardware. You might pay an extra cost in memory use by using multi-value logic rather than boolean and you might lose some efficiencies that were offered for Boolean tests. Many things that are less efficient in some way are still worth using, though.
The use of fuzzy sets, multi-valued logic, iterative adjustment of outputs, and proportional application of expert rules can make a control system much more regular than discrete Boolean branching. Folks making embedded systems for consumer products have been making strides in this area for quite a while. Zadeh's concept of possibility vs. probability changed the way I think not just about programming but about many things in the real world.
| [reply] |
|
|
Re: Will Perl6 be able to do this kind of logic?
by moritz (Cardinal) on Feb 18, 2009 at 08:09 UTC
|
There are basically two ways to implement that.
The first method notes that Bool is just an enum, and you can just as easily define your own enum enum TristateBool <False Undecided True>; and override the functions that now coerce to Bool to then coerce to TrisateBool.
Note that there's virtually nothing in Perl 6 that a builtin type can do that a user defined one can't - it's just a matter of effort.
The second method involves Junctions and "normal" Bools, by just saying that $undecided = any(True, False) and have Perl 6 working it out (it might involve some more tweaking, depending on what you actually want to achieve) | [reply]
[d/l]
[select] |
Re: Will Perl6 be able to do this kind of logic?
by zentara (Cardinal) on Feb 18, 2009 at 13:35 UTC
|
I've seen the light :-) The model would be this:An application would have many (maybe as many as10,000) threads. Each thread would be truly thread safe, not this current "copy-on-create" crap that Perl5 has. Real separate code in each thread. The backbone of each thread would be a vector that you can grow/shrink by adding/subtracting elements.....it's the old "i,j,k,l,m,n" thing in vector spaces. Each vector element is only readable by every other thread-object in thread:shared space. The space elements being added/subtracted are orthoganal....even to the higher dimensions. Wait, did I just try to reinvent PDL ? No, because the key is the independent threads containing a self-looping object(eek! they're alive :-) ). This is probably better done in C, with the libglib of gtk+. So I guess I'm asking is Perl6 going to be cleaner on threads, without the copy-on-write spawning. Truly independent threads.
| [reply] |
Re: Will Perl6 be able to do this kind of logic?
by dwm042 (Priest) on Feb 19, 2009 at 17:43 UTC
|
zentara,
I can't help you in your quest, but I can say that this reminds me way too much of an article in an old magazine, probably Byte, by Peter Grogono. Peter wrote the influentual book, "Programming in Pascal", and his article was all about implementing multi-state logic in Pascal using sets.
David. | [reply] |
|
|
but I can say that this reminds me way too much of an article in an old magazine,There is no stopping an idea whose time has come. :-) Yeah, it makes sense...a whole bunch of us schoolboys were set on the task of mathematically modelling the universe, right down to the infinitesimal point level. Like in most things math related, eventually everyone comes to the same model...... living objects, each containing an infinite vector space. Of course, then you must consider interactions... and you come up with how sets work. I was talking to an old schoolbuddy about it, he is into Social Work, while I was into physics. We both ended up mentioning set dynamics as the key to understanding.
I find it somewhat serendipitous, that in the programming model, as well as the physical model, the basic unit is a thread. Another interesting thing, is the model also emulates humans....each our own process, with shared memories, and infinite variability. So it's almost as if we modelled ourselves to understand the cosmic. Philosopher know thyself, eh?
| [reply] |
|
|
| [reply] |