Loading ...
Sorry, an error occurred while loading the content.

Re: Tekno

Expand Messages
  • winglabs_inc
    Thanks, I appreciate that. For now I ll try and upload a rough schematic of the device, but I really do want to get the real thing working. I think it would
    Message 1 of 7 , Aug 30, 2013
      Thanks, I appreciate that. For now I'll try and upload a rough schematic of the device, but I really do want to get the real thing working. I think it would provide a good example of just how great the capacity ratio is between neural and digital processing. Most of the reason why BEAM is popularly conceived as inferior technology is because it's almost always realized in discreet circuitry. What most fail to see is that if a neural circuit was minimized to the scale of integrated components, its performance would far surpass any digital circuit per U^3 of space, even if it couldn't do nearly as much. Thus the only drawback is that neural networks don't mostly consist of repetitive patterns of circuitry. And problems like research grants and funding are just run-of-the-mill obstacles that I think every worthy technology has to overcome.
      So anyway, I joined "the Robotics Club" group, figuring it more likely that someone on there could help me with Tekno, only to find that no one has posted there since last year, and the posts before that were barely semi-annual. That and the message I attempted to post hasn't been posted yet, as it has to be approved first, so I'm probably looking at another year before the message even gets posted, if ever, let alone anyone seeing it.
      Also, I built a Carry-Look-Everywhere(CLE) adder/subtractor, which is a form of binary adder, and I find that it has some strange properties compared to a typical binary adder, specifically regarding subtraction. Ripple-carry adders, and every derivative thereof, will readily accept a 1's complemented integer and add a positive integer to it, resulting in basic binary subtraction. Even carry-look-ahead adders consist of congregated ripple-carry stages in conjunction with a separate CLA unit. But while in concept the idea of CLE logic is similar to CLA logic, in practice a CLE adder is built very differently than any other type of adder, as it is not a derivative of ripple-carry logic like most adders. So while it is far faster than most adders, I've encountered a unique quirk with the CLE unit: it inverts its result while in subtraction mode. So I had to add another multiplexer at the other end of the adder to un-invert differences. When I did this, however, I found that the adder is actually operating under 2's complement, whereas almost every other adder operates under 1's complement. Which also means it can translate any 1's complement integer directly into 2's complement format. I think the bug that inverts differences is caused by adder mistaking negative integers for very large positive integers. Because of this, when the adder underflows, it wraps around to the "highest" value, which is actually the lowest negative value, and the reverse occurs when the adder overflows. So it ends up outputting a value in the opposite quadrant from 0 than the correct result. It's not a problem, because a simple inversion will solve this quickly. But I still didn't realize that CLE adders worked on 2's complement. To me, that actually makes it even better that ripple-carry derived adders, because 2's complement lacks -0, and thus includes a slightly higher range of values, and also because signed negative integers are processed identically to their unsigned positive equivalents. This means that signed integers are actually ambiguous, and a programming language can refer to them either as their negative value or as their positive value, which is 2[-x]. Another weird thing about CLE logic is that it actually uses the carry-in and carry-out bits as negative indicators, allowing the system to represent twice as many integers as it normally would. Actually three times, if the par of a signed value depends on context. My adder is 8-bit, so that's 512 values, plus signed ambiguity, which adds up to 768 representable integers! Though a language would have to be specialized to provide context for ambiguous data.
      Enjoy, Connor.

      --- In beam@yahoogroups.com, Grant Nelson wrote:
      > I think part of the appeal of BEAM robots is how quickly they can be
      > prototyped and tested, compared to traditional robotics that seem to
      > require far greater up-front investment. For that reason I was drawn to
      > BEAM, and I think that if others also find that part of BEAM robotics most
      > appealing, they would also be keenly interested in prototypes, examples,
      > small built things to look at.
      > Connor, if you were to build an example of what you describe, I agree that
      > it would be incredibly cool to see. I, among others, would quickly demand
      > videos, schematics, photos, explanations, and all sorts of other things
      > that would drive discussion and generate interest. So, please take a shot
      > at it, give it your best shot. Plan a bit, build a lot, inspire others.
      > I've gotten busier but still attempt to create a new BEAM-ish bot every
      > summer or winter to add to my collection, and I always tend to adapt
      > whichever is the coolest bot I've seen lately. Wolfgang's intuition is
      > correct for what generates engagement.
      > Grant
    Your message has been successfully submitted and would be delivered to recipients shortly.