 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/15/2010 2:59 PM, Orchid XP v8 wrote:
>
> I generally just don't code anything at that hour. It never ****ing
> works right anyway.
>
Yeah, probably good advice. ;)
> Heh, well, I did wonder. Actually, as I say, I just assumed that since
> it was *so* wrong, you must already know about it but just haven't got
> round to fixing it yet.
There are some things like that in there at the moment, but that was not
one of them.
>
> Pah. Mutable state is evil! ;-)
>
Eh, I'm thinking of a way of managing that part of the app in a much
cleaner manner, anyway.
You have to change the state of the objects somehow....
> Very, very slowly. Like, I'm having trouble making it so that I can add
> and remove wires and stuff efficiently and still be able to look up what
> connects to what efficiently and...
My progress isn't as quick (or as clean) as I would like, but yeah... I
had similar challenges. Quadtrees help if you're looking for something
at a particular location, btw ;)
> (See my post about "highly redundant data structures.)
I'll have a look at this...
> You, by comparison, have got something that *runs*. I'm still faffing
> around with design choices.
Yeah, it limps along, I suppose ;)
You're coding it in Haskell, aren't you?
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Pah. Mutable state is evil! ;-)
>
> You have to change the state of the objects somehow....
Do not try to change the state of the objects. Instead only try to
realise the truth: there is no state. Then you will see that it is not
the *state* that changes, it is only *yourself*. ;-)
>> Very, very slowly. Like, I'm having trouble making it so that I can add
>> and remove wires and stuff efficiently and still be able to look up what
>> connects to what efficiently and...
>
> My progress isn't as quick (or as clean) as I would like, but yeah... I
> had similar challenges. Quadtrees help if you're looking for something
> at a particular location, btw ;)
Oh hell, I haven't even got that far. When the inputs to a gate change,
and its output changes, it has to notify everything connected to its
output. But to do that, you have to be able to somehow look up what it's
connected to... and be able to change it later... and check that you
don't have outputs connected to other outputs... and...
>> (See my post about "highly redundant data structures.)
>
> I'll have a look at this...
There's really nothing to see. I just meant that that's what my comment
is about. ;-) Because I want to look up information five different ways,
it's in five different indexes, all of which need to agree with each
other...
>> You, by comparison, have got something that *runs*. I'm still faffing
>> around with design choices.
>
> You're coding it in Haskell, aren't you?
You trying to imply there's a causality relationship there? :-P
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/15/2010 3:41 PM, Orchid XP v8 wrote:
>>> Pah. Mutable state is evil! ;-)
>>
>> You have to change the state of the objects somehow....
>
> Do not try to change the state of the objects. Instead only try to
> realise the truth: there is no state. Then you will see that it is not
> the *state* that changes, it is only *yourself*. ;-)
>
Welcome to the Matrix, Neo.
>
> Oh hell, I haven't even got that far. When the inputs to a gate change,
> and its output changes, it has to notify everything connected to its
> output. But to do that, you have to be able to somehow look up what it's
> connected to... and be able to change it later... and check that you
> don't have outputs connected to other outputs... and...
>
Yup, been there .. still there .. still not exactly what I want. Mine is
a bit more weird than that. I start somewhere, and begin fanning out
looking at various pin states, If I see more than one output, I flag
it... and so on. It's a sucktacular process and has many, many failings.
Plus, it doesn't lend itself very well to being able to follow signals,
being able to step from gate to gate, being able to follow a particular
signal path into a subcircuit...
>>> (See my post about "highly redundant data structures.)
>>
>> I'll have a look at this...
>
> There's really nothing to see. I just meant that that's what my comment
> is about. ;-) Because I want to look up information five different ways,
> it's in five different indexes, all of which need to agree with each
> other...
>
That's ok.. I couldn't find the post anyway.
>>> You, by comparison, have got something that *runs*. I'm still faffing
>>> around with design choices.
>>
>> You're coding it in Haskell, aren't you?
>
> You trying to imply there's a causality relationship there? :-P
>
Oh, no ... But I did have to get a Haskell dig in somewhere ;)
I am interested in seeing what your Haskell implementation will be like.
(In a way, this reminds me a bit of a small friendly "competition"
between a friend of mine and I back when I was a kid. We both wrote
different implementations of the same game....)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Oh hell, I haven't even got that far. When the inputs to a gate change,
>> and its output changes, it has to notify everything connected to its
>> output. But to do that, you have to be able to somehow look up what it's
>> connected to... and be able to change it later... and check that you
>> don't have outputs connected to other outputs... and...
>>
>
> Yup, been there .. still there .. still not exactly what I want. Mine is
> a bit more weird than that. I start somewhere, and begin fanning out
> looking at various pin states, If I see more than one output, I flag
> it... and so on. It's a sucktacular process and has many, many failings.
> Plus, it doesn't lend itself very well to being able to follow signals,
> being able to step from gate to gate, being able to follow a particular
> signal path into a subcircuit...
>>> You're coding it in Haskell, aren't you?
>>
>> You trying to imply there's a causality relationship there? :-P
>>
>
> Oh, no ... But I did have to get a Haskell dig in somewhere ;)
>
> I am interested in seeing what your Haskell implementation will be like.
Coding stuff in Haskell encourages you to try to make everything
"perfect", which is possibly why I'm still designing and redesigning the
thing rather than making it actually do stuff...
Small example: Different gates have different numbers of pins. Now in an
OO language, you'd probably just have an array (or some other container)
of pins and be done with it. You *could* do that in Haskell too,
except... well... there's always the possibility of a gate ending up
with the wrong number of pins. In an OO language, you'd probably just
ignore that possibility, in which case the code will throw some kind of
exception if the number of pins is wrong. But in Haskell, you're more or
less forced to explicitly handle this possibility. And that tends to
discourage you from ignoring it, since if this happens, there's
basically no good way to recover. (You just throw an exception I guess -
which is quite frowned - or you make your functions explicitly partial,
which is quite a bit more work.)
The net result is that in Haskell, you take more notice of this problem.
And it turns out that by using ADTs, it's quite simple to statically
prevent the problem from ever occuring in the first place. So you can
design your code so that there's this problem that might happen that you
have to explicitly test for and explicitly deal with, or you can design
your program so that the problem is guaranteed to never happen in the
first place. Guess which option the typical Haskell programmer is going
to go for. ;-)
Of course, making everything "perfect" like this requires quite a lot of
think-time. Haskell strongly encourages this style of "think twice, code
once". Anyway, I believe I'm closing in on a solution, but I'll believe
it when the code actually runs properly!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I am interested in seeing what your Haskell implementation will be like.
>
> Coding stuff in Haskell encourages you to try to make everything
> "perfect", which is possibly why I'm still designing and redesigning the
> thing rather than making it actually do stuff...
>
> Of course, making everything "perfect" like this requires quite a lot of
> think-time. Haskell strongly encourages this style of "think twice, code
> once". Anyway, I believe I'm closing in on a solution, but I'll believe
> it when the code actually runs properly!
Yeah, the internal layout management code appears to be operating
correctly now. In the end, I applied a tried and tested analysis
technique: a relational-style ERD.
The problem was that I'd design a data structure, start coding away, and
then discover some query direction that wasn't easy to support. So then
I'd change the data structure, which makes half the code break, so I
have to go rewrite that... In the end, the solution was to sit down and
draw out a propper plan. Once you comprehend the exact structure of the
information you want to store and the directions in which you want to
access it, you can come up with a nice *simple* data structure which
does what you actually need.
It works a lot better now - although I'm still finding minor bugs here
and there...
Who knows? I might even get the simulation algorithm running today.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Who knows? I might even get the simulation algorithm running today.
Affirm that. After many hours' work, I have now reached the point where
I've simulated a binary half adder which correctly computed that 0 + 0 =
0 carry 0. Woo.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> The net result is that in Haskell, you take more notice of this problem.
Hate to tell you, you take notice of it in an OO language also. :-) It's not
any easier to deal with things like that.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The net result is that in Haskell, you take more notice of this problem.
>
> Hate to tell you, you take notice of it in an OO language also. :-)
I didn't intend to make any absolute statements. I just meant that in
general, Haskell tends to make you notice certain things more.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> I am interested in seeing what your Haskell implementation will be like.
OK, so I just finished the 6th complete rewrite of the LogicWorks
simulation core. And it seems to be working, as best as I can tell.
I spent a long time trying to hyper-compartmentalise the thing so that
every tiny aspect of its operation was a seperate source file, with a
tightly-controlled interface to it. The trouble is, everything depends
on everything else, so you end up going mad trying to avoid circular
module dependencies. Eventually I just put everything related to
simulation into one utterly giant module. Circular dependencies within
the same module don't matter. ;-)
Secondly, I spent ages trying to design the circuit as a dozen seperate
data structures, each representing different facets of its operation,
and several different modes of operation depending on what you want to
alter. And then I realised that in the real application, you only want
one mode: the mode where you can modify the live circuit as you simulate
it, and everything needed to do the simulation is one data object. So
instead of having dozens of datatypes, I put everything into one big
record and wrote all my functions to work on that.
The net result is what I'd consider to be utterly huge, although other
people's opinions may differ. It's a single source file, 660 lines long
(including comments) and 20 KB in size. When you compile it, it
generates a 38 KB interface file plus a 182 KB object file.
(For reference, I usually structure my programs so that each module is
about 150 lines or so.)
It's about now that an IDE starts to sound attractive. It would be nice
to be able to glance at a panel and see the sames and types of all the
functions I've written, and be able to quickly navigate to them.
Actually, hell, just some syntax hilighting would be nice! Oh well...
Anyway, I could show you the code if you _want_, but... it's kinda
large. (And most of it is just searching for or storing data, which
isn't tremendously interesting.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Eventually I just put everything related to
> simulation into one utterly giant module. Circular dependencies within
> the same module don't matter. ;-)
I assume you're doing this in Haskell? I haven't really been paying too much
attention.
> It's about now that an IDE starts to sound attractive. It would be nice
> to be able to glance at a panel and see the sames and types of all the
> functions I've written, and be able to quickly navigate to them.
Now you're getting it. :-)
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
