|
 |
Hey people, check it out: Attached to this post is a small program I wrote.
(The attached binary works for M$ Windoze only. I'm not sure precisely
which versions, but it DOES work for XP and DOES NOT work for NT 4.0. In
principle it could be compiled for Linux or Mac OS X. The program is
about 20 KB of Haskell source code.)
The program isn't terribly exciting; it's a predicate solver. That is,
it attempts to solve extremely simple equations.
To run the program, double-click it. You should get a window of
multicoloured terminal output, including a "Predicate>" prompt.
If you enter, say, "x = 1", then the program will respond that to solve
this predicate, you have to set x equal to 1. (DUH!)
Alternatively, if you set "4 = 4", the program will find "1 solution",
and that solution will be empty. This basically means that the predicate
*always* holds. If you do "1 = 2", the program will report "no solutions
found", indicating that the predicate can never be satisfied. So far so
good.
If you say "x = 1 & y = 2" then the program will report a self-evident
solution. If you say "x = 1 | y = 2" it will report two seperate
solutions. And if you say "x = 1 & x = 2" it will fail to find any
solutions (pretty obviously).
You can of course put predicates in brackets; by default, AND has a
higher priority than OR. You can also prefix anything with "~" to
indicate NOT (note that the engine doesn't support this quite so well).
The program understands (signed) integers and equality. It also
understands lists. Try "{1, 2, 3} = {1, 2, 3}" and you will get an empty
solution (i.e., the predicate always holds). Try "{1, 2, 3} = {3, 2, 1}"
and you will get no solutions (i.e., the predicate never holds). You can
also do "{x, y, z} = {1, 2, 3}", which yields a fairly obvious result.
Notice that, mathematically speaking, "x = 1" and "1 = x" are the same
equation, and the program treats them identically.
The fun part begins when you start using the built-in predicate
functions. There are currently just 4 of these; I plan to make it
possible to add your own, but I haven't implemented this yet.
First, the rather dull "Empty" function tests whether a list is empty:
- "@Empty[{}]" will yeild an empty result set.
- "@Empty[{1, 2, 3}]" will give no results.
The "Element" function tests whether a given element is in a list:
- "@Element[5, {1, 2, 3}]" gives no results.
- "@Element[5, {4, 5, 6}]" gives an empty result set.
The weird part is that this works backwards as well as forwards:
- "@Element[x, {1, 2, 3}]" tells you all possible values for x that will
satisfy the predicate!
Adventurers beware: Attempting to find all possible lists that 5 could
be an element of will result in an infinite loop from which only Ctrl+C
will escape.
Also of interest is the "Join" function:
- "@Join[{1, 2, 3}, {4, 5, 6}, {1, 2, 3, 4, 5, 6}]" gives an empty
result set, indicating that the 3rd list is indeed the first two joined
together.
- "@Join[{1, 2, 3}, {4, 5, 6}, z]" will set z to the join of the first
two lists.
This also works backwards:
- "@Join[{1, 2, 3}, y, {1, 2, 3, 4, 5, 6}]" will find the correct value
for y by stripping the first list off of the 3rd list.
- "@Join[x, {4, 5, 6}, {1, 2, 3, 4, 5, 6}]" works similarly.
- "@Join[x, y, {1, 2, 3}]" will find every possible way of splitting the
final list into two sublists. How neat is that?!
Again, beware that other combinations may yield an infinite number of
valid solutions [which will take an infinite amount of time to compute,
and nothing is displayed until *all* solutions are fully computed].
Finally, there is the "Subset" function, which tells you if one set is a
subset of another. For example, "@Subset[{1, 2}, {1, 2, 3}]". It
_should_ also work backwards, but currently doesn't. I'm not sure why.
Anyway, it's an amusing little diversion...
Post a reply to this message
Attachments:
Download 'logic.exe.dat' (182 KB)
|
|
|
|
Darren New wrote:
> May I suggest that perhaps dark blue on black (and similar color
> schemes) aren't the best choice? Most of it, I can't read.
Oh, OK. It's actually all very readable on my screen; I guess it has a
higher gamma or something.
> Stick to
> either bright colors on a dark background or vice versa. Or at least
> make things like the prompt dim and the results bright. :-)
Actually I made the prompt bright and the input + result dim. :-} Maybe
I should reverse that?
The mean reasoning behind all this multicoloured madness is so that if a
predicate produces 6 pages of output, you can easily find the thing you
typed in, because it's a different colour.
...and then I tried to extend this concept as far as humanly possible,
possibly resulting in a screen that's a tad too busy. ;-)
BTW, are you impressed that I got this to work? Somebody wrote a small
Haskell library that invokes windows.h under Windoze or emits ANSI
escape sequences on POSIX. Neat, eh? Also, notice the window title
bar... ;-)
> And if you say "x = y + 3 & y = 17" it says "x = y", which wouldn't seem
> to be right. Unless I have the syntax wrong or something.
Really? That shouldn't - ah, wait, I see what's happening.
Check the second line of output:
Predicate: x = y
Since "+" isn't a valid token, the parser has ignored everything after
that point. If the predicate *is* x = y, then the result you got would
be perfectly correct.
This is one of the irritating things about Parsec. It can silently fail
to parse all of the input. Like, if some prefix of the input is a valid
expression but the rest isn't, it returns just the prefix. (Obviously it
depends how you structure your parser.) I must figure out how to fix that...
Anyway, *this* is why it prints out what it thinks it parsed the
expression as. (With lots of extra brackets.) In all cases, check that
the program has parsed something that matches what you intended! o_O
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
com> wrote: