straight_stewie

Damn. Thought there was another hobby developer here interested in automated market analysis.

At only a 23km (14 mile) transmission distance, and with transmission distance being inversely proportional to bandwidth in fiber optics, I feel that it will be a very long time before this becomes viable for trans-oceanic cabling, where you need 100s of miles of cables between repeaters.

TL;DR if the latency can be reduced to a useful point, this could open up a lot of possibilities in local networks for large installations. 23 kilometers (14 miles) is pretty good to start with. I mean, it's short, but still useful in some areas with closely packed nodes (like bigger cities) without any improvement in transmission distance. Yeah, that has limited usefulness, but higher bandwidth would also reduce latency in high load scenarios (like bigger cities). More in the present, it by far beats out infiniband bandwidths. If the latency is low enough, this would probably start being used in new supercomputer/datacenter/cloud-center installations pretty quickly. If the latency can be reduced to the single digit nanosecond scale for local networks (like what you would find in one of those installations), that could make networked processor-to-processor connections possible. For reference, 1 petabit per second is 125,000 GB per second. As a reference frame, read bandwidths of L3 caches on modern processors are around 370 GB per second, so this is roughly 378 times faster than L3 cache read bandwidth. Of course, that's not quite an apple-to-apples comparison, but I suspect that it still beats out read bandwidth of modern L3 caches when you account for the overhead of building the data packets (especially if one can assume that this is a feature people want, so will be integrated with on die hardware).

Disclaimer: This reply contains a political statement, but is in no way designed to elicit political discussion or response. It is a statement of fact, with evidence, on the tariffs levied against imported goods from China, which attempts only to answer the OPs original question about whether the prices of computer components will stay high in the US. Any moderator please remove if this violates the "no-politics" rule. It is likely that the tariffs will stay around, at least for some weeks or months. Biden, who takes office in 9 days from now, says that he has no intention of immediately removing those tariffs, and instead plans to review them first. https://www.cnbc.com/2020/12/02/biden-tells-nyt-columnist-he-wont-immediately-remove-trumps-tariffs-on-china.html

I don't know much about property law in Denmark. But, at least in the US, yes. They will definitely get away with it. They bought the property legally, and because it's not a restricted item (such as a firearm, tobacco, alcohol...) can now sell it legally. Now there is some argument to be had that if they bought the graphics cards with the sole intent of selling them for profit (which I'm sure that anyone falling under the definition of "scalper" did), then they would actually be running a retail business then they should be paying atleast income tax on the gross amount of sales to the IRS. Depending on their state, they might also have to be paying sales tax, state income tax, or be entirely illegal (not every state allows you to do that from your own home with or without a business license). Additionally, not every city allows you to run a warehouse (which is what it is, even if very small) out of your private property, but that depends on many things. Like, for example, if I were to be a graphics card scalper in my city in Mississippi, I could legally do it from my house, provided that I stored the units entirely in one of the buildings that appears on the deed to the property, that I did not generate any excess amount of vehicle traffic, that none of the buyers were visiting my house, that I paid my federal income tax(es) on the income, that I paid state income tax on the income, that I remitted sales tax to the state (unless collected for me by, i.e. Amazon), that the total volume of products moved stayed below $5,000,000 USD per year for that concern (a restriction that applies only to consumer product retailers operating a home occupation out of their homes), that only people in my immediate family living on this property did any work for the concern, that I didn't give anyone (including friends living anywhere and family not living at this property) "tours" of the operation, and that I remembered to always call it a "home occupation". I know these things (for my state and city) because I run a reasonably large cricket farming operation out of my house. I'll refrain from posting the name of the LLC that I hold the concern under, so as not to dox myself.

I would think that both are clear enough: int newPopulation = oldPopulation - (oldPopulation * (1/4)) + (oldPopulation * (1/3)); // Versus int newPopulation = oldPopulation * (1 + 1/12); // Versus int newPopulation = oldPopulation * 1.0833; I might argue that options 2 and 3 are more clear than option one for this problem. Option 3 explicitly says that the population grows at a rate of 8.33%, offering far more insight to what's going on than option 1 does. In a case where the function definition would be something like: int GetPopulation(int year, float deathreate, float birthrate); The I can see your argument. Of course, with that method signature, I'd probably opt for @wanderingfool2's closed form formula.

More than likely you have a failing RAM component. Either a failing component in the processor, motherboard, or most likely, in one of your RAM sticks. Get Memtest86 and run that for a full inspection. This may take 8 hours or more. If there are any failures, then we've found the problem. If there are failures, you need to determine if it's a stick, a slot, or the processor causing the issue. The first thing I would do if MemTest86 shows a failure is remove one stick and rerun the test. Then, remove the other stick and rerun the test (regardless of the results). If you get an error in one or the other sticks, then the error is either that slot or that stick. If you only get errors with both sticks, then the problem may be the memory controller in your processor. If the error appears in one or the other sticks, reinsert the one that tested good in the slot of the stick that tested bad. If it still tests good, then the problem is in the failed stick of ram. If the stick that passed the test but is now in the failed slot fails the test, then the problem is the motherboard.

There is a slight optimization if we are being very nitpicky. If you are subtracting 1/4 and adding 1/3, then you are really adding 1/12 of the total population. So, you do not need to calculate out the number of deceased llamas and new llamas, only the new population size, which is the current population size times 1 1/12 Didn't notice this was C at first.

What you're looking for is called "rigor" and it's the primary thing they *should* teach you in engineering school. All of the other stuff amounts to proving that you can read and understand reference texts. Look up a university that you might enjoy attending, and see if they post their curriculum online. If they do, they usually also have a bookstore section where you can punch in the class code and it will tell you what textbooks they use. Then you can just buy the textbook(s) for the parts you are interested in and go from there. For example: https://www.me.msstate.edu/undergraduate/curriculum/ Is the undergraduate mechanical engineering curriculum for Mississippi State University https://msstate.bncollege.com/shop/msu/page/find-textbooks Is the page for the schools bookstore where you can punch in the course codes and it will tell you what textbooks they use.

AMD operated at a loss all the way up to 2018... So it's really 2006-2018. But whatever. Bet your money on AMD, what do I care?

You do realize that AMD can't really sell their x86 IP, right? The only IP they could sell would be x64 related, and the only really interested buyer would be Intel themselves... AMD is only still allowed to make x86 processors because Intel looks the other way so that AMD will return the favor and allow Intel to make x64 processors. Had Itanium taken off, Intel would have challenged AMD on the x86 front right then and there. If AMD tries to liquidate their x86 IP, Intel is sure to challenge, hard. The AMD-Chinese joint venture only works because the Chinese partners are only allowed to build the processors, not design their own with the IP. It's just that, unlike TSMC, the Chinese partners make money on the back end, not the front end (where TSMC profits from manufacturing the processors, the Chinese companies profit from directly selling the processors). I've excluded the VIA complication for obvious reasons. VIA has not been, and likely never will be, a worthwhile competitor in the industry.

Of course having debt is just one of the costs of doing business. What you missed was "debt-to-equity". If you have more debt than you do equity, you're in a pickle. By my math, it will take AMD three years to finish paying off their debts, and that's assuming that things keep looking up for them. Numerous things could happen in the meantime (like Alder Lake or ARM. Keep in mind that Alder Lake will be real competition even though AMD is on 7 and Intel will be on 10, because Intel's 10 gives them a transistor density higher than TSMCs 7...). Think about it like this: You are being offered the opportunity to buy a portion of a company. When you buy a portion of the company, you immediately get some amount of the companies value, and that value is not really related to the cost of acquiring it. Would you rather spend money on the company that gives you a dollar and fifty cents for every dollar you spend to by a portion of the company, or spend money on the company that costs you a dollar and sixty cents for every dollar you spend to buy a portion of the company? What I'm saying is that while the value of AMD's common stock may go up and down based on, well, nothing really, at the end of the day it's really only worth whatever percentage of the book value of the company is equivalent to whatever percentage of outstanding common stock you own, minus that portion of equity owed to debtors, minus that portion of the equity owed to preferred shareholders. And right now, AMD has negative value even though it looks like they are performing well right now. Intel has room to acquire more debt. AMD does not. AMD has a ways to go to become a worthwhile company to be interested in, Intel is more profitable now than they ever have been. Even with Intel taking on the additional debt you mentioned, their debt-to-equity ratio has still decreased, at a rate comparable to how fast AMD is decreasing theirs. Like I've been saying all along, the socketed desktop processor is not all there is to this analysis, and that market will likely not make or break Intel over the next three to five years (hence why they aren't really pushing it right now). With the end of Moore's Law at hand, and competition from other architectures creeping in, anything could happen here. But, at the moment, Intel is still ahead of AMD overall.

You're not understanding what the phrase "conducting good business" means, but that's ok. For whatever reason, people on this forum only seem to care about one single product line that Intel offers, and can't seem to see the bigger picture going on here. You're proving my point that AMD is incapable of performing over the long run. They are entirely dependent on another business, in which they are not even a controlling partner, for all of their manufacturing capabilities. Hence, they can't keep up with demand for their product, hence they can't really grow. Beyond that, AMD is now stuck at TSMC 7nm (which, for reference, is competitive to Intel's 10nm) for the foreseeable future because TSMC has decided to sell basically all of their 5nm capabilities to Apple, essentially forever. That opens up all kinds of opportunities for Intel, like moving straight to 5nm, even if it means spinning their wheels for another couple of cycles, and AMD simply won't be able to do anything about it. AMD simply does not have the cash reserves necessary to fix their supply line issues. Beyond that, they won't, for a long time, even if they magically stay profitable for longer than is likely. That entire decade of operating at a loss forced them to take on a lot of debt. The debt-to-equity ratio is calculated by taking the total claims against a businesses assets by creditors and dividing it by the total claims against a businesses assets by it's investors (owners). Basically, a debt-to-equity ratio tells us how much of each dollar of the value of a business each business owner gets after fully selling all assets at book and settling all debts. Lower is better, and a debt-to-equity ratio of 1.0 or greater means that there is not enough value to pay off all debts. Now the good stuff. AMD's debt-to-equity ratio is 1.68, meaning that the business is worth -$0.68 dollars for every dollar invested. In contrast, Intel's debt-to-equity ratio is 0.52, which means that the business is worth $0.48 cents for every dollar invested. Of course, the businesses are worth more than that, but the debt-to-equity analysis only accounts for the case where you immediately fold a business, sell all of it's assets at book value, and distribute the proceeds. Basically, what this tells us, is that AMD's investors own negative 68% of their business, while Intel investors own positive 52% of their business. Now, I don't claim to be the best investor in the world, but I will put my money where my mouth is on that one. AMD is in a hole. One that will take them at least the next 3 years to crawl out of if they can maintain their current performance. In the meantime, Intel is cash flush and moving forward, just in ways that the PC enthusiast group is having trouble seeing right now.

I'm confused about your problem. This code gives me what I would expect, which is a list of lists of strings and the first string in the first list: a = """ 08 02 22 97 38 15 00 40 00 75 04 05 07 78 52 12 50 77 91 08 49 49 99 40 17 81 18 57 60 87 17 40 98 43 69 48 04 56 62 00 81 49 31 73 55 79 14 29 93 71 40 67 53 88 30 03 49 13 36 65 52 70 95 23 04 60 11 42 69 24 68 56 01 32 56 71 37 02 36 91 22 31 16 71 51 67 63 89 41 92 36 54 22 40 40 28 66 33 13 80 24 47 32 60 99 03 45 02 44 75 33 53 78 36 84 20 35 17 12 50 32 98 81 28 64 23 67 10 26 38 40 67 59 54 70 66 18 38 64 70 67 26 20 68 02 62 12 20 95 63 94 39 63 08 40 91 66 49 94 21 24 55 58 05 66 73 99 26 97 17 78 78 96 83 14 88 34 89 63 72 21 36 23 09 75 00 76 44 20 45 35 14 00 61 33 97 34 31 33 95 78 17 53 28 22 75 31 67 15 94 03 80 04 62 16 14 09 53 56 92 16 39 05 42 96 35 31 47 55 58 88 24 00 17 54 24 36 29 85 57 86 56 00 48 35 71 89 07 05 44 44 37 44 60 21 58 51 54 17 58 19 80 81 68 05 94 47 69 28 73 92 13 86 52 17 77 04 89 55 40 04 52 08 83 97 35 99 16 07 97 57 32 16 26 26 79 33 27 98 66 88 36 68 87 57 62 20 72 03 46 33 67 46 55 12 32 63 93 53 69 04 42 16 73 38 25 39 11 24 94 72 18 08 46 29 32 40 62 76 36 20 69 36 41 72 30 23 88 34 62 99 69 82 67 59 85 74 04 36 16 20 73 35 29 78 31 90 01 74 31 49 71 48 86 81 16 23 57 05 54 01 70 54 71 83 51 54 69 16 92 33 48 61 43 52 01 89 19 67 48""" rowLists = [] rows = a.replace("\r", "").split("\n") for row in rows: if(not len(row)): continue rowLists.append(row.split()) print(rowLists) print() print(rowLists[0][0]) Is the problem possibly that you are expecting a single character but are instead getting a string? For example, rowLists[0][0] gives me "08" rather than '0'.

Just to point this out, node size is a meaningless term. TSMC 7nm node size brings a transistor density of 96.5 mtr/mm2 while Intels current 10nm process (that they use for some mobile chips) gives them 100.76 mtr/mm2 . A higher number is better here. What I mean to say, is that Intels 3nm behind process produces a transistor density competitive with the current state of the art 7nm design. Or, in other words, TSMC transistor node size names do not, in any way, relate to actual feature sizes on die. TL;DR on the above paragraph: Node sizes between different manufacturers should not be considered to be directly comparable when an allegedly 3 generation behind process is producing a higher transistor density. Beyond that, Intel isn't actually worried about having the smallest processor node. Intel is, and should be, worried about producing the most profit. Which they are. They are operating at an order of magnitude more revenue than AMD, and they are also operating at an order of magnitude higher profit margin than AMD. Believe it or not, 2020 was one of Intels highest profit years ever. This is easily fact checkable as both Intel and AMD are publicly traded companies. AMD is barely getting along, even if the general market feeling is that they are the most popular right now. Financial data shows that AMD runs an absolutely terrible business that can't possibly perform well in the long run. Seriously, look at their financial data, then look at Intels. Then realize that AMD now has to compete with Apple (the richest company ever), for manufacturing capability, all while their 10 times richer competitor doesn't have to compete for manufacturing capacity. My argument is not about whether Intel processors are currently worse/better than AMD processors, my argument is about whether Intel is running a better business than AMD, and that they might actually know how to wield that business. Statistics really talk here, and Intel still has wayyyyyyy higher financial performance than AMD.

Can we see the code where you create the list of lists of characters?

Well, you're right. It's six in one, half a dozen in the other. What I meant to say was that it might be the case that Intel is, and has been, intentionally willing to lose the short game in order to compete better on the long game: If you look at what AMD is doing, they aren't investing in themselves. Intel is till way better off in the meantime. Intel has been making (including in 2020), about a 25% profit margin on roughly $80B of revenue. In the meantime, AMD has been making a roughly 16% margin on roughly $7B of revenue, and that's only for the last two years, before that they were consistently operating at a loss. As a result, Intel has about $13B on hand, while AMD has about $1.5B on hand. AMD has been using primarily TSMC to produce their processors for them, which means they now have to compete with Apple (who is wayyyyyyy wealthier than AMD. Like not even in the same league.) for TSMC 5nm production capacity. All I'm saying is that, if I'm Intel and I'm betting on x86 staying more popular than ARM for the next two decades, I'm keeping my FABs and heading straight for 5nm.

Wait, so Intel is investing more money in trying to beat Moore's law than in competing with AMD? That's an interesting strategy.

I hope Intel won't vote to do this. Buffet refers to what Intel is experiencing as "Mr. Market". Basically, the markets view of your company will change over the short and medium term against meaningless data. Intel is still offering higher performance chips than the competition, and node size no longer matters. The only area where they are consistently behind at the moment is power consumption. It is only a matter of time until the market realizes that AMD is tying meaningless numbers to their processor nodes and that Intel is still offering higher performance products for real workloads. Intel will come back. Letting a venture capitalism firm do Soggy Cigar Butt investing on Intel (shedding assets for a quick flow of cash: "the last puff") would be a terrible mistake and would certainly bring about the permanent end of Intel being a serious competitor. Especially since there are no other fabs that can handle Intels manufacturing needs (TSMC has already dedicated nearly the entirety of it's competitive manufacturing capabilities to Apple. Intel would have to pay them to build new fabs for them, so might as well just upgrade their existing fabs. It would be cheaper and would allow them to maintain control). Intel is just as profitable this year as ever. Until that changes you'd be hard pressed to make a good argument that they should throw away the major portion of their business plan.

Can you message me your input? I want to compare your numbers to Brotli. Sucked it up and got the .zip

Alrighty. So I've been playing around and I've figured out a way that you can persist every combination of your 224 colors while only having to store any given color one time: SQL. If you put all of your colors into a single table, say Colors, then you can run the query below to get 224 sized chunks of color combinations: SELECT * FROM Colors CROSS JOIN Colors AS Alternate WHERE Alternate.Color = @chunkIndex; Effectively, what this does is save every possible combination of two colors on disk, but uses a reasonable amount of space. Chunk sizes are 16M integers, as this query returns every record of the cross join where the alternate color is equal to chunkIndex. This chunk size is a little large, so make sure that you have your RDBMS properly configured to run the table in memory, and if possible, use the query as a stored procedure (so that it is properly optimized). Make sure to index the column, so that it is faster to access. I still say that it's faster to generate the data on the fly to do your testing with, but you insist on persisting it, so there you go: A way to persist a MASSIVE amount of data in a reasonable amount of space and computational power.

Ok. So just in case you are actually doing this as a compression method, you will have to remap the colors for every new file. This isn't really hard at all, it really just requires passing around the dictionary of translations. There are better ways to do this, but that's one way to think about it. On the case that you are really trying to do some steganography, there are much better (and much more secure methods that don't rely on transporting a dictionary of translations around) out there. One such method is to shift bits of your input into the last bit of each color.

So is this really a substitution cipher?

So your compression method takes 256 character strings and compresses them into a 16 bit color?

Your plan actually multiplies the size of the image by 85 1/3 times. You are saying that you plan to compress a 3 byte number into a 256 byte string.