Topic: Amateur hour - page 3. (Read 8295 times)

Wait, I think I've seen this advert before!

[quote Television]
As a busy mum...
[/quote]

That's it!!

That is very good. I did not think of using Euclid's algorithm. I should send you a bitcoin for that one.

Here is the code for factor:

   /** Factor a number.
    *  Example: 24 will return { 4, 2, 2, 2, 3 } where 4 is the number of factors and 2 x 2 x 2 x 3 = 24
    *  @param iNumberToFactor
    *  @return The factors in a one-based array.

• = count of factors. Null in the event of an error or invalid input.

    */
   public final static int[] factor( int iNumberToFactor ){
      if( iNumberToFactor < 1 ) return null;
      int iCapacity = 100;
      int[] factors = new int[iCapacity + 1];
      int xPrime = -1;
      int iMaxFactor = (int)(java.lang.Math.sqrt( (double)iNumberToFactor )) + 1;
      int iRemainder = iNumberToFactor;
      while( true ){
         xPrime++;
         if( primes[xPrime] > iMaxFactor || primes[xPrime] == iRemainder || iRemainder % primes[xPrime] == 0 ){
            if( factors.length == iCapacity + 1 ){ // expand buffer
               iCapacity *= 2;
               int[] factors_new = new int[iCapacity + 1];
               System.arraycopy( factors, 0, factors_new, 0, factors.length );
               factors = factors_new;
            }
            factors[0]++;
            if( primes[xPrime] > iMaxFactor ){
               factors[factors[0]] = iRemainder;
            } else {
               factors[factors[0]] = primes[xPrime];
            }
            if( primes[xPrime] > iMaxFactor || primes[xPrime] == iRemainder ){
               int[] factors_exact_size = new int[factors[0] + 1];
               System.arraycopy( factors, 0, factors_exact_size, 0, factors[0] + 1);
               return factors_exact_size;
            }
            iRemainder /= primes[xPrime];
            xPrime = -1;
         }
      }
   }


Factor depends on a table of primes which is this:


final public static int[] primes = {
   2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97,
   101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229,
   233, 239, 241, 251, 257, 263, 269, 271, 277, 281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, 353, 359, 367, 373, 379,
   383, 389, 397, 401, 409, 419, 421, 431, 433, 439, 443, 449, 457, 461, 463, 467, 479, 487, 491, 499, 503, 509, 521, 523, 541,
.....
   49667, 49669, 49681, 49697, 49711, 49727, 49739, 49741, 49747, 49757, 49783, 49787, 49789, 49801, 49807, 49811, 49823, 49831, 49843, 49853, 49871, 49877, 49891, 49919, 49921,
   49927, 49937, 49939, 49943, 49957, 49991, 49993, 49999 };   
}

I have not included the entire table because it is large, but you can easily fill in the missing values yourself from online sources.

What, visa has two paid devs?!?! Cheaters! No wonder they're ahead of us. No fair!

-MarkM-

You dont think that as bitcoin scales the velocity of developer incentives would also scale ?

Or do you envisage a network the size of visa having only 1  dev still being paid from donations ?

So java is bloatware compared to C ? This is news?

Or could the java have been written as concisely without loss of efficiency?

-MarkM-

WTF is a Mercier cycle?  I know Hamiltonian cycles, but I've never heard of a Mercier cycle, and google (regular and scholar) doesn't have a clue either.

Also, just because you make that much now doesn't mean you need that much.  What you're trying to say is you are greedy and aren't willing to give up your cushy paycheck to push forward the state of the art of public technology.  You'd rather suck the teat of the corporate monstrosity and empower the already powerful.  I hope you have some survival skills for when the shit hits the fan.  You may be okay if you are with a defense contractor, but your conscience won't be.

Apply the multiplier to the coins being transacted?  Then people would most certainly be sending coins to themselves!  The multiplier is public information, so any time the multiplier is greater than 1, people would send themselves coins constantly, to continually increase the number of coins they have.  Which would, in turn, increase the multiplier even further, and it'd just spiral upward in fake inflation forever.

It seems like the longer this discussion continues, the more elementary the mistakes you are making in your logic.

OP

I am spending my time writing this not because I care anything about you but because I am offended at your graceless attitude towards our current devs who are working hard and doing a great job.  And they should know that "we the people" are merely amused by people like you.


On intelligence:
You seem to have no contextual social awareness.  So if you are smart it is only in narrow subdomains. 

And you seem to have actually taken an IQ test and are boasting your scores; 2 behaviors rarely exhibited by the group in which you claim membership.

Domain knowledge (hamiltonian cycle etc) is no measure of intelligence as it is easily acquired but you seem unaware of this.

You seem to be unaware of the massive gaps in your own proposals.

You seem to have no real understanding of project longevity -- of how the evolution of the importance and criticality of a project creates problems.  You are completely unwilling to contribute, but you seem to be unable to recognize that all projects and contributors juggle similar time constraints and so often the implemented solution is not optimal, simply expedient.  And some shortcuts which are irrelevant when bitcoin is valued at .02 can become very important when it is 50 bucks.


Your ideas...

have already been considered and implemented in alt-coins as some have suggested.  At least the ones that aren't totally stupid.

ignore the hard problems... like how to spontaneously derive a trust metric using an algorithm that cannot be defeated even if examined.


Also, adjusting the balance in everybody's account rather then the price of goods will fool absolutely nobody.

And FYI, Bitcoin transfer or txn volume has no causal correlation to the price of a bitcoin in USD and only a large-time statistical correlation.  And the price of BTC/USD vs BTC/silver vs BTC/web hosting are also not correlated so your single adjustment cannot hold more then one commodity steady.  And it cannot even do that, because you are suggesting a maximum adjustment of what was it, .5% but we are seeing 25% volatility on a daily basis. 

You have made absolutely zero consideration of self-interested (i.e. antagonistic) agents.  And miss completely obvious strategies like "calculate the same algorithm (its FOSS) just before the network does.  If it is going to reduce your coins, sell to another currency/commodity, if it will increase them buy coins."  You have obviously only coded in an environment where all the programs are essentially considered to be benignly working towards the same goal -- that is, a normal corporate project.

When you were asked what you have done, a reasonable response would have been to point to a large OSS project that you have contributed to instead of your silly code snippets that have no applicability.


In the end you present yourself as rude and stupid.  Truly this is amateur hour -- you are presenting yourself as such.  At the same time, thx for the laughs!

sd, I believe what we have here is a hang up due to semantics. Let me quote your earlier text:


Bold emphasis mine. By saying "exactly the same" as far as value is concerned and including that major companies do it all the time you suggest to the reader the consequences of moving the decimal for currency and stocks is the same. It is not.

If you double the amount of currency in a system the per unit purchasing power of each holder is essentially reduced by half, but if amount of currency is doubled equally among holders net purchasing power stays the same; so all you've done is change the numbers, not value. I'm sure we agree. If you do a 2 for 1 stock split of a strong company then the total market value of the shares each holder has will be roughly the same since the market will value each share at half the pre-split price; again all you've done is change the numbers, not value.

To this point I'm sure we are in agreement. However, as time goes on the holders of currency maintain the same net purchasing power, yet something different happens for owners of stock split shares; what usually happens is they find by doing absolutely nothing the value of each of their shares regains its pre-split price, making them twice as wealthy in shares as they were. This is due to the external affect of the market (notably, in an inflationary environment). So while stock split holders gain wealth, holders of a doubled currency do not. That is a key difference. There are also other factors which may severely affect market price such as company mismanagement etc. This is why I said the comparison of stocks to currency isn't apt.

But this appears to be over semantics. If I reword your text as follows I believe we are in complete agreement:

"Yes it's exactly the same as moving the decimal place as far as [initial] value is concerned but it's still done by major companies all the time."

I hesitated to respond because I don't want to distract from the exchange between Blitzen and glitch003 so I'll repost the challenge of the latter:

On the leaderboard, we have Greyhawk.

You bring up an interesting point, and the market has already come up with a solution for this with futures contracts.

Instead of worrying about fluctuations in the value of bitcoin, it should be possible to place your bitcoins in escrow and make a deal with a broker to pay you some price for your bitcoins on some pre-agreed date.  The value for the price should be at least equal to the value on the date you place the coins in escrow plus the money market interest rate you could get at a bank, potentially more.

Now the person entering into a contract with you to buy the coins would be taking the risk if the value dropped, but I think there is plenty of demand to do this given the price history for the past several years.

I'm not sure what effect this would have on the volatility of BTC at the exchanges (I suspect it would reduce it, but that's just a guess), but it would relieve merchants from having to worry about it and even allow them to make some small returns on their coins rather than paying a company like bitpay to convert their bitcoins into fiat currency on a daily (or more frequent) basis.

This would make Adam the first man in history to keep 75% of his wealth away from his wife, and Eve the first woman in history to hold onto everything she did manage to get.

Ok, post the code for your factor() method so that I can create a runnable demo.  I will prove to you that I can make your code run faster.

You are proposing an exchange rate mechanism that can only be based on inputs that can be gamed by false transactions. There is no way a cryptocurrency can tell the difference between a hedge fund buying ten thousand coins for a few million and me buying a single pizza from a guy on these forums for the same number of coins. It can't tell the entire transaction thoughput of visa worth billions from a bunch of kids gambling fractions of a cent on something like satoshidice.

The Eurozone tried an exchange rate mechanism and it fell apart. And that's with knowledgeable people actively managing it.

Well, in the beginning one person would have the entire pool which could be started at some convenient number of coins, say 1000. Then the Adam would pay some of them to Eve, say 250. So on and so forth.

Now, in thinking about this, I see there is a mistake in my plan because if the multiplier were applied to all coins equally then Eve's pool (imagine she held onto it) would always be worth 25% of the total which would mean her wallet would grow in value. So, to make it work we need to only apply the multiplier to the coins being transacted. That way the value of Eve's coins stays the same if she holds onto them. Now, as you said above this seems to create a situation where you can increase the number of coins you have just by doing fake transactions, but this is not strictly true because remember that the multiplier can be positive or negative, so if you did your transaction during a downturn then the value of the coins might decrease slightly instead of increase. In any case, the hope would be that the change on any one transaction would be so small that it would not be worth creating fake transactions. In fact, using a transaction processing fee linked to the multiplier might prevent the benefit entirely.

You can see one of the advantages of this system compared to bitcoins the way they are now: if Eve were to hold onto her btc which the capitalization grew, her 25% could turn into millions of dollars even though the original value of the transaction might be, say $20. But with a multiplier her coins will never be worth more than the original $20, because they are price stable.

In the context of moving the decimal point so the number of units of a thing a person has changes whilst the value they hold doesn't change you are saying that currencies and stocks behave differently. You are either mistaken or deliberately trolling.

How about the non-psychological effect of cheating my car dealer out of 91 BTC?  Even though you don't see it in the price, the value that a person is holding still fluctuates.

You said that in practice, even if someone tried to game it, the daily changes might be 0.5% or less.  I don't have enough of a predictive spirit to know whether that is true, which is why I think this would be an interesting experiment, to see what would really happen.  If the multiplier doesn't change quickly enough, it won't be a true enough indicator of economic activity, and the price could vary greatly.  If the multiplier changes too quickly, it would be too easy to game.  There would certainly need to be some sort of balance between the two.

If the vendor sets up a link to an exchange, it doesn't matter if they sell 100 items or 10,000, it's the same amount of work to set up said link.  Not really a game-changer IMO.

You still haven't really touched on how you would initially distribute a currency like this.  If not through mining, then how?

You are right, there is a psychological effect of, gee I had 100 btc yesterday, and today I only have 90, but the dollar value should remain roughly the same if the multiplier is doing its job. So if your 100 btc were worth $1000, then your 90 btc should be worth approximately the same, $1000.

Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage.