Home    LittleBigPlanet 2 - 3 - Vita - Karting    LittleBigPlanet 2    [LBP2] Help!
#1

Feedback Looping Problems

Archive: 22 posts


Before I get too far, I just want to preface this in saying that this is a pretty advanced issue I'm having. I've hit a wall and I could use some help!

I was working with feedback loops, trying to make a currency system that wouldn't be limited by 100% signals. Sure, I can go smaller than 1% (and I do that already), but there are accuracy errors with those values, thanks to how they are created.

(Side note: Does anyone have a better method for making .5% or .1% signals than using a timer? Mine come out to be inaccurate because of the limitations of using a timer.)

My idea was to create a system where I could escape the 100% barrier, by recording overflow and running it back through my feedback loop. I ran into problems with doing this, though, and I think it has to do with limitations in the LBP editor. I'm waiting for someone to come along and prove me wrong!

Consider that my feedback loop was storing an 80% signal, and by pulse-adding a 25% signal to it, I would expect the to sum to be 100%, with a 5% overflow.

What I wanted to do then was discard the 100% signal and instead loop the 5% overflow back through the system to be stored. By recognizing that I had experienced an overflow, I could add a 1% signal to another loop to handle higher order digits. By doing this, I would be able to correctly interpret the result as 105% by having two different feedback loops:

One loop showing 01% and one loop showing 05%. By smashing them together (via some display), it would read 0105, or 105.

I thought I had a solution, and it was able to correctly wrap past 100%, but then then trying to add again would cause issues. I would actually end with a wire showing a 0% signal that when inverted was still a 0% signal. It wasn't making any sense; I got sad.

This was my solution:

http://i2.lbp.me/img/ft/cd2d4f5fde7d8bf7011a93a4d1a0bdf4feebef0c.jpg

The bottom-left components pulsed the 25% signal that would be added. The top direction combiner and splitter were the basic feedback loop, and the rest was just used to add the signals and modify which one was looping (it would replace the 100% signal with the overflow.

Can anybody make sense of this, or perhaps pitch an alternative solution? I'm at a loss.

Thanks!
2011-06-18 17:25:00

Author:
comphermc
Posts: 5338


If you check out my logic level, I've made a digital display that rounds each decimal to retain accuracy. It has a range of 1-10000, and from my tests, is completely accurate (did about 20 changes in value, ranging from 1 to 9999).

If you want to do it yourself, all you need to do is separate each decimal by multiplying by 10 for each, and add whatever value you need to make it accurate (since each decimal seems to be off by the same amount).

Since you do the rounding outside of the actual analog value formation, all you need to do to create the value is a timer X / 1000.0. Using a feedback loop, you can then modify it using similar Y / 1000.0 timers.

It's all in the second prize in my logic level, but the display is very simplistic (just hologram blocks), so you might want to make your own.

EDIT: I use it for a currency system and it works brilliantly. I imagine that with excessive use, you would eventually find you're +/- 1 from the desired value, but that shouldn't really be an issue.

You should also be able to increase the number of decimals that can be displayed, but then you risk more serious issues with rounding.
2011-06-18 17:41:00

Author:
SSTAGG1
Posts: 1136


If you check out my logic level, I've made a digital display that rounds each decimal to retain accuracy. It has a range of 1-10000, and from my tests, is completely accurate (did about 20 changes in value, ranging from 1 to 9999).

If you want to do it yourself, all you need to do is separate each decimal by multiplying by 10 for each, and add whatever value you need to make it accurate (since each decimal seems to be off by the same amount).

Since you do the rounding outside of the actual analog value formation, all you need to do to create the value is a timer X / 1000.0. Using a feedback loop, you can then modify it using similar Y / 1000.0 timers.

It's all in the second prize in my logic level, but the display is very simplistic (just hologram blocks), so you might want to make your own.

EDIT: I use it for a currency system and it works brilliantly. I imagine that with excessive use, you would eventually find you're +/- 1 from the desired value, but that shouldn't really be an issue.

You should also be able to increase the number of decimals that can be displayed, but then you risk more serious issues with rounding.

Thanks. I will check it out, but I don't think it addresses the problem I'm having. I've used a different technique already to make a currency system that goes from 1-100,000. Granted, the small digits aren't very accurate, since I am using strictly analogue signals. I'm trying to escape the 100% maximum so that I can go above 100,000.

Edit: I was able to escape the 100% already, but it's tedious to add another level, so I'm trying a different solution.

Edit2: Yeah, I can see that your display is nearly identical to phort's logic probe. I used the same model. In fact, your feedback loop is pretty much the same as well. You have additional components to quickly reset it back to max, and your timer display is over-engineered. So yeah - this is basically what I have already. I added additional steps to the system, so that filling beyond 100% would spillover to a new loop. I added 10 of these loops end-to-end, so that I could get another order of magnitude, but I don't feel like making 100 loops.

That's why I tried a different technique.
2011-06-18 17:55:00

Author:
comphermc
Posts: 5338


Is there any reason you're using analog over digital?2011-06-18 18:20:00

Author:
Ayneh
Posts: 2454


Is there any reason you're using analog over digital?

Using it as a currency system, I can make purchases or gain money at many different increments when using analogue signals. Different items can easily have different values.
2011-06-18 18:35:00

Author:
comphermc
Posts: 5338


Does anyone have a better method for making .5% or .1% signals than using a timer? Mine come out to be inaccurate because of the limitations of using a timer.

From this page (http://wiki.lbpcentral.com/Talk:Timer)...


Another point worth noting is that the analog output of a Timer is exactly equal (or as close as you can get with floating point arithmetic) to the number of frames in the list mapped from "Current Time", divided by the number of frames mapped from "Target Time". For example, a Timer set to a "Current Time" of 0.5, and a "Target Time" of 0.8 is equal to 14/24 or 0.5833333...

There's three accuracy issues you have to contend with:-

The first is the known problem with timers, but you can work around that by examining the table on that page, and finding two framecounts which exactly divide to the number you want. Also note that when you place a fresh timer (which defaults to 4.0 seconds) its framecount is 120, but once you change it to something else and back to 4.0 again it's only 119 frames.

The second is due to numbers representable in floating-point math. IIRC for values less than one (which applies to all analog signals), you can only accurately represent fractions whose denominators are powers of two.

The third is that none of the analog signal probes currently available are entirely accurate. The closest is probably tetsujin's (https://lbpcentral.lbp-hub.com/index.php?t=51859-Big-Dumb-Probe).



My idea was to create a system where I could escape the 100% barrier, by recording overflow and running it back through my feedback loop.

Not quite sure why you'd want to do it that way, assuming it's possible to create accurate fractions, unless the idea is to have one loop for dollars and one for cents, so you can display them separately, or somesuch.



Using it as a currency system, I can make purchases or gain money at many different increments when using analogue signals. Different items can easily have different values.

You can do the same thing using digital logic instead - a 32-bit buffer would give you more accuracy than any analog system (up to ~4 billion discrete values), but it's a bit heavier on the thermo.
2011-06-18 19:11:00

Author:
Aya042
Posts: 2870


alright alright i just saw your tutorial last night so in terms of actually knowing how to do what you asked for i am clueless but im pretty good at figuring things out so i will give this a go when i get out of work tonight2011-06-18 19:23:00

Author:
Unknown User


Using it as a currency system, I can make purchases or gain money at many different increments when using analogue signals. Different items can easily have different values.
I'm not suggesting you use base 2 for your shop XD

You'd have to use multiple digital signals to represent different values. For a single decimal number 4 is ideal since 2^3=8 and 2^4=16. You could handle overflow caused by addition by adding 6 when necessary. For handling bigger numbers it's more or less a case of cascading components which makes it super-easy.
2011-06-18 19:42:00

Author:
Ayneh
Posts: 2454


Not quite sure why you'd want to do it that way, assuming it's possible to create accurate fractions, unless the idea is to have one loop for dollars and one for cents, so you can display them separately, or somesuch.

I guess my motivations were because I didn't have accurate fractions. Perhaps I can abandon this now, assuming I can get to those accurate fractions.

I would like to be able to make an accurate .5% and .1% if possible, but I'm at a loss for how these missing frames are accounted for. The bare minimum timer for a .05 signal would be 20.0 seconds, but I don't know if that has a frame loss or not. How do I check that?

If it doesn't, then I have to proceed with checking:

.2 of 40.0
.3 of 60.0
.4 of 80.0 and so on...

Then I'd have to do a similar thing for 1% with:

.1 of 100.0
.2 of 200.0
.3 of 300.0 and so on...

If I can get those to be accurate, I'm fine with abandoning high order numbers. I am using phort's logic probe as a display, but I see that there are better solutions. I don't understand them, so I've been staying away.

Tl;dr - how do I determine which timer values exhibit frame lossage?
2011-06-18 19:44:00

Author:
comphermc
Posts: 5338


I would like to be able to make an accurate .5% and .1% if possible...

...which would be 0.005 and 0.001. I'd have to re-read IEEE 754 (http://en.wikipedia.org/wiki/IEEE_754-1985) to see how close you can get to those. Even if you can't get it exactly, it may be close enough to make no odds.



The bare minimum timer for a .05 signal would be 20.0 seconds, but I don't know if that has a frame loss or not. How do I check that?

Well, I built a custom frame counter to do that, but it only goes up to 255 before resetting to zero.

At a guess, I'd say if 12.0s is accurate, then any integer multiple of 12.0s will be too, so given that 1.2s is also good, then 1.2 of 1200.0 ought to get you your 0.1%.

For 0.5%, try 0.6 of 120.0, or (in theory) adding the 0.1% to itself repeatedly up to 0.5% ought to work too.
2011-06-18 20:28:00

Author:
Aya042
Posts: 2870


At a guess, I'd say if 12.0s is accurate, then any integer multiple of 12.0s will be too, so given that 1.2s is also good, then 1.2 of 1200.0 ought to get you your 0.1%.

Worked pretty dang well:

http://i8.lbp.me/img/ft/4880f820b914b13671a276bfd9b6b32e66685652.jpg

If you can't read them, they say .000999987151 and .004999935891, using Tyger's probe. For all I know, they are perfectly accurate, but the probe has limitations. Tetsujin's hung my PS3.

Cheers!
2011-06-18 21:00:00

Author:
comphermc
Posts: 5338


Tetsujin's hung my PS3.

Yeah. It hangs for several seconds (maybe 30), but will become responsive eventually.

A good accuracy test might be to add 5 copies of your 0.1% together, and see if it matches your 0.5%.
2011-06-18 21:26:00

Author:
Aya042
Posts: 2870


Yeah. It hangs for several seconds (maybe 30), but will become responsive eventually.

A good accuracy test might be to add 5 copies of your 0.1% together, and see if it matches your 0.5%.

I left it load for about 2 minutes. Had to manually shut it down.

I am fine with the minimal inaccuracy I might get with those. Your test likely wouldn't work since I added the .1% 5 times to get the .5%. Heh. At any rate, I'm satisfied.
2011-06-18 21:54:00

Author:
comphermc
Posts: 5338


Your test likely wouldn't work since I added the .1% 5 times to get the .5%.

Pfft. Okay, so compare it to 0.6 of 120.0 then.
2011-06-18 22:03:00

Author:
Aya042
Posts: 2870


Well, I had a play with everything and was satisfied with the accuracy overall. I didn't come across any issues from my testing - but who knows how thorough it was.

At any rate, I published what I have: http://lbp.me/v/1qyxk-

It does what it says on the tin: Currency system that goes from 1 to 100,000. Making purchases/payments in the ten-thousands has latency, but in practice it's hardly noticeable. I packaged it in a little shop interface to show how you could disallow purchases for which you have insufficient funds. Copy it and use it if you like... or don't. Heh.

http://i0.lbp.me/img/ft/7602ae5bebbb17d0dbc43712303860a1b3bb1571.jpg
2011-06-19 03:39:00

Author:
comphermc
Posts: 5338


When you make a purchase, perhaps you could just randomize the digit display, to act as if it were changing. It'd cover up the latency, though you say it's only minor so prob not needed.

I'm curious as to how well this works compared to other methods. It has a nice range, but how thermo intensive is it?
2011-06-19 04:41:00

Author:
SSTAGG1
Posts: 1136


I'm curious as to how well this works compared to other methods. It has a nice range, but how thermo intensive is it?

It's very low. I don't have any estimates, but it's really not much more complex than phort's analogue display.
2011-06-19 05:17:00

Author:
comphermc
Posts: 5338


don't know how i missed this thread. that's the exact problem I ran into back in february that lead me to build a digital solution. I tried for a week to get the overflow to feed back in properly. Once I finally got one problem fixed with the feedback, another jumped up in its place.

It'll be interesting to see how you solved it.
2011-10-25 20:43:00

Author:
tdarb
Posts: 689


I am sorry for being behind the curve here and possibly adding no solution to the issue at hand but I'd like to knwo whether I have understood CompherMC's dilemma here.

A system that is based on one FB loop and fractions of percentages is preferrable because of the simplicity of the system, if indeed the accuracy of the fractions can be guaranteed. However, I am leaning in favor of Comph's second idea to use a system based on non-fractioned values and multiple FB loops representing powers, each overflowing into another. Why? Because the first idea means creating ever smaller fractions in order to upgrade the range of the system (inward) and the second idea only needs new loops added to increase greater ranges (outward).

I think the approach of the second idea that Comph is taking makes complete sense; in essence it is what a selector based counter does, but by using FB loops. Will have to find some time to understand why this isn't working, though.
2011-10-26 09:50:00

Author:
Antikris
Posts: 1340


I think the approach of the second idea that Comph is taking makes complete sense; in essence it is what a selector based counter does, but by using FB loops. Will have to find some time to understand why this isn't working, though.

i showed comph a working version of that setup, but he had already created the currency system using values lower than 1% so he didn't end up using it, i didnt end up working out why his setup didn't work, i just made one from scratch
2011-10-26 10:41:00

Author:
evret
Posts: 612


You can do the same thing using digital logic instead - a 32-bit buffer would give you more accuracy than any analog system (up to ~4 billion discrete values), but it's a bit heavier on the thermo.

I couldn't imagine it would be much heavier considering the extra overhead needed for overflow and simply scaling input values that comes in with this analog system.

I haven't tried 32 bit, but it would be interesting to see what the thermo cost on that is.

Just to test it out I built a 17 bit digital analog to this (pun intended) . It comes in at just over half of the first bubble on the thermo. Granted, that is just the register/adders, conversion logic, and display, but I wouldn't think this setup is much cheaper on thermo.

I'm curious. What are the benefits of doing this in analog vs digital?
2011-10-26 15:24:00

Author:
tdarb
Posts: 689


Can I wake this post again? I like how comphermc solved his problem. Me and fly_4_a_jedi just wired the "discard negative signal" of the addition in another feedback loop's addition, and wired that second loop's "discard negative signal" of subtraction to the first loop's subtraction. Basically, instead of having one loop which represents hundreds, we got two loops, each represent 100%. So for 300% we need 3 loops. Less effective, but using the timer overdide system, we can use 1 timer to display each loop, meaning that we can make a health meter out of multiple chained timers.

Just wanted to share my hapiness (yay, I can reply to a question submitted by comphermc!!!). Oh and, you can make 0.1 signals using a speed sensor and a mover, it seems to be better than timers! That's how I made the ones inside my Health Meter Toolkit - which works as described, you can now chain meters.

(ha, my friends never understand me when I come in the bus saying "oh my god, I just built an or gate out of NAND gates out of NOR gates..." - they just play COD)
2012-02-29 02:29:00

Author:
Unknown User


LBPCentral Archive Statistics
Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Datenschutz
Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.