On Feb 15, 3:10 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> On Tue, Feb 15, 2011 at 2:53 PM, MS <5lvqbw...@sneakemail.com> wrote:
> > Because I'm not sure how else to use (for example) a graph library and
> > still have it look like a circuit, rather than a graph.
>
> Almost any such graph library is going to be a bunch of functions that
> operate on a data structure. Your circuit can be that data structure
> so you can simply use the functions on it. I suspect you're assuming a
> level of type checking, from statically typed OO languages, that just
> doesn't need to be there?
>
> > The specialization of changing the abstract thing
> > into the concrete thing is basically to reduce some of the graph
> > functionality (for example in a circuit a node can't have more than
> > one unique edge on it) and renaming things so they match the domain
> > (eg "vertex" become "node", "edge" become "net"), and add extra stuff
> > such as PCB layer, simulation model, etc.
>
> Sounds like you just need a set of functions that match your domain,
> which wrap the graph library (which in turn operates on the underlying
> graph data structure that represents your circuit).
>
> > Yes, I finally figured out how to have a cyclic structure using refs
> > and dosyncs.
>
> I was thinking of something much simpler - a pure data structure.
At first it was simple, but I want a net to point to its nodes, and
the nodes to point to its parent net.
Actually what originally started this was I wanted a way to pre-sort
the circuit database (for example resistors, capacitors, and their
associated parameters) in a way that allowed for constant time
access... so (this was in python...) I figured out how to create a map
where the parameters were the keys, so if you wanted to search for a
given parameter you'd have to pick the right map. Then I realized
this is probably not necessary or practical even for extremely large
circuits. This turned into figuring out how to wire up the
components, and here I am :)
>
> > In clojure there is a defstruct...
>
> This is why I think you're trying to apply a strict type system which
> will get in the way of a simple solution. You want named types with
> specific behaviors because that's more like the OO you're used to?
Yes that's what I'm used to, and what's funny is that this is almost
exactly what the samples in SICP were moving towards, with tag-based
dispatch and functions associated with lists of stuff.
In a way just having a "to the metal" type of data structure feels a
little loosy goosy.... I think I want to be able to ask about what
type of structure this is... but I suppose I could tag it with a
{:type :ckt} or something. Kind of feels like I should have more
infrastructure... so maybe this is just the mental shift I need to
move away from OO :)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
