Hi everyone, I'm a Computer Science + Applied Mathematics major at a T15 CS university, focusing on machine learning, and I'll be an incoming junior this fall. My long-term goal is to land ML-focused internships and eventually work in machine learning or AI-related roles. I recently completed an introductory AI/ML course that covered the fundamentals of: * Data preprocessing (handling missing data, feature scaling, train/test splits, categorical encoding) * Regression (linear, polynomial, SVR, decision trees, random forests) * Classification (logistic regression, KNN, SVMs, Naive Bayes, decision trees, random forests) * Clustering (K-Means, hierarchical clustering) * Association rule learning (Apriori, Eclat) * Reinforcement learning (UCB, Thompson Sampling) * NLP (tokenization, bag-of-words, sentiment analysis) * Deep learning (ANNs, CNNs) * Dimensionality reduction (PCA, LDA, Kernel PCA) * Model selection and boosting (cross-validation, grid search, XGBoost) I've also completed two research/internship experiences: * Built a Human Activity Recognition model using KNN. * Developed a Louvain clustering pipeline for beauty product datasets. From a coursework perspective, I've completed Linear Algebra, Calculus III, and will soon be taking Applied Linear Algebra and Probability & Statistics. Given my current background, what projects, activities, courses, competitions, or skills would you recommend I focus on over the next year to become a stronger candidate for ML internships? Are there any gaps in my knowledge that stand out? submitted by /u/Reasonable_File663 [link] [Kommentare]

(Disclaimer: This post was drafted with the help of AI to keep it concise, but the research and work are entirely mine.) I’ve been building a spiking neural network (SNN) engine from scratch on my laptop as a solo project. To see if it was actually tracking anything useful outside of my own custom puzzles, I finally tested it on a standard benchmark: NARMA-10. It was a pretty humbling reality check. It flunked completely. The Failure NARMA-10 requires continuous time-series tracking. When I measured the spiking reservoir, its memory was barely two steps deep when the benchmark needed ten. Tweaking standard dials like input volume or cell lifespans did absolutely nothing to fix it. The Small Fix To get it out of the gutter, I tried a basic concept from neuroscience: heterogeneous wire lengths (adding discrete time delays to the inputs). This spread the past out across the network. It worked well enough to triple the memory depth and finally match a basic line-fitting baseline. It's nothing to brag about yet, but it at least made the network usable on the task. The 15x Efficiency Trade-off I want to be completely transparent—smooth, continuous units still beat this spiking net on absolute accuracy almost everywhere. Spikes are definitely not a magic shortcut to out-compute modern architectures. The only real win is pure efficiency. On a small 512-cell recognition task where the spiking net managed to tie a continuous net in accuracy, I counted the exact internal operations (multiply-and-adds): Standard continuous nets grind through every single cell on every tick, busy or not. My spiking net only does work when a cell actually fires. The rest stays silent. The tally: The spiking net used 15 times less internal arithmetic to get the exact same answer on my standard laptop hardware. Moving Forward This benchmark taught me that spikes don't think better; they just think cheaper when the problem space allows it. Instead of just grinding away trying to force prettier engineering benchmarks or out-accuracy standard models, I'm taking a step back to explore some new, creative avenues for how this engine can actually be utilized. submitted by /u/Gutbole [link] [Kommentare]

I'm starting a small robotics company (first-timer, bootstrapped right now, my only hardware is a Bambu 3D printer). The product is a humanoid focused on upper-body work: arms, shoulders, waist, neck, and an expressive head/face. Walking long distances or stairs is NOT a core requirement. I'm stuck between three architectures: Full bipedal 1:1 humanoid: most impressive, but dynamic balance looks like an enormous money/time sink for a small team. AGV/wheeled base + fixed-height humanoid upper body: stable, simpler, cheaper, but the torso can't change height (limited reach). AGV/wheeled base + a vertical rail (prismatic Z-lift) so the whole upper body slides up and down, floor-to-high-shelf reach, with the arms/neck/head working like a human. My current thinking: make #3 the target product, but get there in phases starting from #2, and treat bipedal as a long-term R&D thing (maybe never). The logic is to skip the hardest problem (balance) while keeping the valuable part (manipulation + reach + interaction). Questions for people who've actually built this stuff: - Is phasing #2 → #3 the right call, or am I missing something obvious? - For option 3, how much of a stability headache is raising mass on a rail when the arms extend? How wide/heavy does the base realistically need to be? - Biggest money traps for a first-timer? I'm planning to BUY actuators (Unitree / RobStride / CubeMars / Dynamixel-class) rather than build my own — sane? - ROS 2 + Jetson Orin + open VLA models for the brain — reasonable starting stack? Not trying to out-build Figure or Unitree. Just want to pick the smartest first product for a lean team. Happy to share progress back. Thanks in advance rather hear the hard truths now than after I've spent the budget. submitted by /u/ResponsibleCreme4620 [link] [Kommentare]

For those still not sure what's MSTR and STRC: MSTR is a tech company stock that has pivoted primarily into a "BTC treasury", primarily using leveraged debt to buy BTC. STRC is a hybrid stock/perp bond instrument pegged at $100, that pays dividend every month (11% APY). The purpose is to raise cash to buy BTC, to help MSTR. The feedback loop that everyone keeps talking about: If STRC de-pegs, Strategy will need to raise the dividend to get people back in to try to re-peg to regain confidence and avoid a "bank run". If the dividend is raised, it can come with a risk of less capital to pay the dividend over time, and less cash to buy BTC, less capital and assets for leverage, as the raised dividend drains more cash more quickly. If there's less cash to buy BTC, and STRC loses its ability to raise capital, MSTR loses its incentive and value. If MSTR loses its incentive and value, that's less money for capital and leverage. If that happens, Strategy will have to either dilute shares of MSTR to raise capital, making it lose more of its value, or sell more BTC. If that happens, it will negatively affect STRC's incentive and make it de-peg more once again, and the loop goes back in a circle. So when does this feedback loop turn into a death spiral? If BTC drops enough, for a long enough period of time, then it's gonna increase the chances of the feedback loop to turn into a death spiral. More people could panic out of MSTR and STRC. Which can amplify the feedback loop, which will get even more people to panic out. If MSTR and STRC tank too much, and start having to take drastic action, like selling BTC, then BTC's price could tank more, which could make MSTR and STRC tank even more. Not written with AI (despite being more than 1 paragraph and having titles). submitted by /u/fan_of_hakiksexydays [link] [Kommentare]

My client needs to pay me but since i don't have paypal in my country, we're going with crypto. Does exchanges allow immediate withdrawal after buying the crypto? For context the account will have to be created first, and client can do kyc but i need the payment on the same day preferably. I heard there's a cooling period or withdrawal hold in most exchanges. The client is in germany. We both have no experience with crypto. submitted by /u/Intelligent_Arm_4220 [link] [Kommentare]

How do we contact Satoshi about fixing the problem? submitted by /u/GabeSter [link] [Kommentare]

Hi everyone, For the past couple of weeks I have been working on a simulator project considering the shortcomings of MuJoCo. There are things that people like and also don't like about MuJoCo, like the CPU dependency on MuJoCo which makes the simulation not parallelizable beyond a certain limit (depending on the hardware). I know there exists MJX which is GPU accelerated, however, it is not really made for vision based RL pipelines and training. There is also NVIDIA Isaac ecosystem, but that requires a powerful GPU, thus making it limited in terms of accessibility, let alone it requires license. This is why I worked out this new simulator (still working on it, so there will be significant bugs which require fixing). I call it MuJoFil - MuJoCo + Google's Filament Render Engine. Basically I used Nvidia's Newton Physics Engine (which itself is based on MuJoCo's physics engine but is GPU native), clubbed it with Google's Filament render engine (both of these are open-source), modified Filament significantly to support working natively on GPU to render multiple simulations in parallel, and worked on optimizing it for performance. So what is MuJoFil? It is supposed to be an open-source high visual fidelity simulator optimised for a highly parallelized RL training pipeline so that users can use it to train Vision based Policies. Besides, it offers PBR textures support and also a simple to use plug and play functionality, where you can use any environments available online and support formats such as GLB, OpenUSD, etc. for setting environments for your robots. Basically, now you aren't just limited to environments native to MuJoCo, but rather you can use any environments available online from sketchfab, polyhaven, etc. and use it as a practical robot simulation environment. Check it out for yourself in the video. I would really appreciate it if you guys could tell how you feel about it and suggest ideas for what all things I can incorporate into it as this is going to be a fully open-source and free to use simulator that I have been working on for weeks. PS: While I have a couple of published research papers at top RL and AI/ML venues in the field of RL, I still consider myself a learner in this field who is continuously trying, learning, and building stuff, so there will be things in this hugely ambitious project which I might have missed to work on, and that is where I want help from you people who understand this field well. Sorry for this lengthy post and thanks if you read it till here🙇🙇🙏, I would really appreciate if you could share your thoughts on it. Also, I will make its code repo public on GitHub, but till then you can definitely check it out on PyPI. There are 2 separate packages, one can be installed using: "pip install mujofil" This is the CPU based variant, whereas there is a CUDA supporting GPU native variant about which I mentioned above, you can currently install it using: "pip install mujofil-warp" I am planning on changing its name to mujofil-cuda instead of mujofil-warp as that apparently sounds more intuitive to my direct peers but you can suggest this name as well. Thank you for the support❤️. submitted by /u/MT1699 [link] [Kommentare]

​ Executive Summary Provide a concise overview of the project, the problem being solved, the proposed solution, target users, token utility, and long-term vision. Problem Definition and Market Analysis Clearly define the existing market inefficiencies. Support claims with data, competitor analysis, user pain points, industry trends, and addressable market size. Protocol Architecture Describe the complete system architecture, including smart contracts, consensus mechanisms, network topology, data flow, node interactions, and protocol layers. Blockchain and Infrastructure Design Explain why a specific blockchain was chosen. Discuss scalability, throughput (TPS), finality, interoperability, storage requirements, gas optimization, and network security. Smart Contract Framework Detail contract modules, upgradeability mechanisms, permission structures, access controls, contract interactions, and security assumptions. Token Utility and Economic Model Define token use cases such as governance, staking, transaction fees, liquidity incentives, collateralization, rewards, and ecosystem participation. Tokenomics Include total supply, issuance schedule, inflation/deflation model, vesting schedules, treasury allocation, liquidity allocation, team allocation, investor allocation, and burn mechanisms. Security and Risk Management Explain audit plans, penetration testing, bug bounty programs, governance attack mitigation, oracle security, bridge security, and treasury protection mechanisms. Governance Framework Describe voting mechanisms, proposal creation, quorum requirements, delegation systems, treasury management, and transition toward decentralization. Roadmap and Milestones Provide measurable milestones covering MVP development, testnet deployment, audits, mainnet launch, ecosystem partnerships, protocol upgrades, and long-term expansion plans. Additional Sections Recommended for Institutional-Grade Whitepapers - Mathematical Model - Consensus Specifications - Economic Simulations - Regulatory Considerations - Technical Diagrams - API Documentation - Validator Requirements - Treasury Management Strategy - Cross-Chain Architecture - References and Research Papers A whitepaper should be technical enough for developers, transparent enough for investors, and understandable enough for users. The goal is to explain not only what the project does, but why the protocol can sustain value over time. submitted by /u/Low-Experience8986 [link] [Kommentare]

Hi everyone, I trained a self-play RL agent for Generals.io that reached superhuman-level and ranked #1 on the human 1v1 leaderboard. It began as my master's thesis where the goal was to beat a prior algorithm based agent. We succeeded using behavior cloning, RL fine-tuning and reward shaping, but the agent was still consistently beaten by the top players. So I gave it a round two and fixed the largest bottlenecks: Reimplemented the whole pipeline in JAX (from NumPy/Torch) Used Vision Transformer instead of the CNN Both are a result of the same idea: to invest in scaling rather than human priors and ad-hoc patches. The blog is written as a guide for anyone building something similar — the dead ends, the decisions, and the intuitions and tricks I picked up along the way. It's all open source, including the fast JAX simulator — handy on its own if you want an imperfect-information RTS env to play with. Links - Guide: https://kam.mff.cuni.cz/~straka/blog/generals.html - Simulator (JAX): https://github.com/strakam/generals-bots - Agent: https://github.com/strakam/AverageJoe I hope you find the blogpost entertaining! Feedback and questions welcome 🤗. submitted by /u/shrekofspeed [link] [Kommentare]

At the end of my last post, I presented an idea: what if I used the core of my last project, the cumulative matrix product, and repurposed it as a positional embedding? I just finished fleshing out the math behind HDD-RoPE and training a model with this positional embedding algorithm, and the results are excellent. When trained on the dataset TinyStories, the validation loss begins to converge a fair amount faster than the baseline transformer trained using xPos. A GPT-2-like model trained on TinyStories with hyperparameters copied from https://huggingface.co/roneneldan/TinyStories-33M (n_blocks=4, d_model=d_k=d_v=768) The repo at https://github.com/mikayahlevi/hdd-rope/ allows you to replicate the results and goes in depth about the math and details of the architecture. Standard RoPE breaks the queries and keys into groups of two and rotates each pair at a predefined rate. This allows the model to learn relative position by observing the change in basis between the queries and keys. Pairs of two make intuitive sense for a linear sequence, as a chunk can be rotated with a single degree of freedom, corresponding to linear one-dimensionally progressing position. HDD-RoPE moves past this intuition and instead says that position within a sequence is multidimensional. Therefore, the chunks can be broken into any size, such as 4 as used in the TinyStories example. Four-dimensional chunks correspond to 4 choose 2 = 6 axes of rotation (6-dimensional position.) Essentially, we're saying that a token doesn't just lie at a position within the sequence, but a position within any construct the model can learn, such as a paragraph or sentence. To facilitate this, I also make the amount of rotation along each axis data-dependent, such that it can learn how to advance the positions based on information stored in the current layer's activations. If you would like to learn more, please check out the repo. I formalize the math and lay out a roadmap. submitted by /u/mikayahlevi [link] [Kommentare]

Hi everyone, For the past couple of weeks I have been working on a simulator project considering the shortcomings of MuJoCo. There are things that people like and also don't like about MuJoCo, like the CPU dependency on MuJoCo which makes the simulation not parallelizable beyond a certain limit (depending on the hardware). I know there exists MJX which is GPU accelerated, however, it is not really made for vision based RL pipelines and training. There is also NVIDIA Isaac ecosystem, but that requires a powerful GPU, thus making it limited in terms of accessibility, let alone it requires license. This is why I worked out this new simulator (still working on it, so there will be significant bugs which require fixing). I call it **MuJoFil** \- MuJoCo + Google's Filament Render Engine. Basically I used Nvidia's Newton Physics Engine (which itself is based on MuJoCo's physics engine but is GPU native), clubbed it with Google's Filament render engine (both of these are open-source), modified Filament significantly to support working natively on GPU to render multiple simulations in parallel, and worked on optimizing it for performance. So what is MuJoFil? It is supposed to be an open-source high visual fidelity simulator optimised for a highly parallelized RL training pipeline so that users can use it to train Vision based Policies. Besides, it offers PBR textures support and also a simple to use plug and play functionality, where you can use any environments available online and support formats such as GLB, OpenUSD, etc. for setting environments for your robots. Basically, now you aren't just limited to environments native to MuJoCo, but rather you can use any environments available online from sketchfab, polyhaven, etc. and use it as a practical robot simulation environment. Check it out for yourself in the video. I would really appreciate it if you guys could tell how you feel about it and suggest ideas for what all things I can incorporate into it as this is going to be a fully open-source and free to use simulator that I have been working on for weeks. PS: While I have a couple of published research papers at top RL and AI/ML venues in the field of RL, I still consider myself a learner in this field who is continuously trying, learning, and building stuff, so there will be things in this hugely ambitious project which I might have missed to work on, and that is where I want help from you people who understand this field well. Sorry for this lengthy post and thanks if you read it till here🙇🙇🙏, I would really appreciate if you could share your thoughts on it. Also, I will make its code repo public on GitHub, but till then you can definitely check it out on PyPI. There are 2 separate packages, one can be installed using: "pip install mujofil" This is the CPU based variant, whereas there is a CUDA supporting GPU native variant about which I mentioned above, you can currently install it using: "pip install mujofil-warp" I am planning on changing its name to mujofil-cuda instead of mujofil-warp as that apparently sounds more intuitive to my direct peers but you can suggest this name as well. Thank you for the support❤️. submitted by /u/MT1699 [link] [Kommentare]