2026-01-18 06:00:07
Convex Relaxation Techniques for Hyperbolic SVMs
Discussions, Acknowledgements, and References
\
B. Solution Extraction in Relaxed Formulation
C. On Moment Sum-of-Squares Relaxation Hierarchy
E. Detailed Experimental Results
F. Robust Hyperbolic Support Vector Machine
Here we visualize the decision boundary of for PGD, SDP relaxation and sparse moment-sum-ofsquares relaxation (Moment) on one fold of the training to provide qualitative judgements.
\ We first visualize training on the first fold for Gaussian 1 dataset from Figure 3 in Figure 5. We mark the train set with circles and test set with triangles, and color the decision boundary obtained by three methods with different colors. In this case, note that SDP and Moment overlap and give identical decision boundary up to machine precision, but they are different from the decision boundary of PGD method. This slight visual difference causes the performance difference displayed in Table 1.
\ We next visualize the decision boundary for tree 2 from Figure 3 in Figure 6. Here the difference is dramatic: we visualize both the entire data in the left panel and the zoomed-in one on the right. We indeed observe that the decision boundary from moment-sum-of-squares relaxation have roughly equal distance from points to the grey class and to the green class, while SDP relaxation is suboptimal in that regard but still enclosing the entire grey region. PGD, however, converges to a very poor local minimum that has a very small radius enclosing no data and thus would simply classify all data sample to the same class, since all data falls to one side of the decision
\
\ boundary. As commented in Section 4, data imbalance is to blame, in which case the final converged solution is very sensitive to the choice of initialization and other hyperparameters such as learning rate. This is in stark contrast with solving problems using the interior point method, where after implementing into MOSEK, we are essentially care-free. From this example, we see that empirically sparse moment-sum-of-squares relaxation finds linear separator of the best quality, particularly in cases where PGD is expected to fail.
\
To generate mixture of Gaussian in hyperbolic space, we first generate them in Euclidean space, with the center coordinates independently drawn from a standard normal distribution. 𝐾 such centers are drawn for defining 𝐾 different classes. Then we sample isotropic Gaussian at respective center with scale 𝑠. Finally, we lift the generated Gaussian mixtures to hyperbolic spaces using exp0 . For simplicity, we only present results for the extreme values: 𝐾 ∈ {2, 5}, 𝑠 ∈ {0.4, 1}, and 𝐶 ∈ {0.1, 10}.
\ For each method (PGD, SDP, Moment), we compute the train/test accuracy, weighted F1 score, and loss on each of the 5 folds of data for a specific (𝐾, 𝑠, 𝐶) configuration. We then average these metrics across the 5 folds, for all methods and configurations. To illustrate the performance, we plot the improvements of the average metrics of the Moment and SDP methods compared to PGD as bar plots for 15 different seeds. Outliers beyond the interquartile range (Q1 and Q3) are excluded for clarity, and a zero horizontal line is marked for reference. Additionally, to compare the Moment and SDP methods, we compute the average optimality gaps similarly, defined in Equation (15), and present them as bar plots. Our analysis begins by examining the train/test accuracy and weighted F1 score of the PGD, SDP, and Moment methods across various synthetic Gaussian configurations, as shown in Figures 7 to 10.
\
\
\
\
\ Across various configurations, we observe that both the Moment and SDP methods generally show improvements over PGD in terms of train and test accuracy as well as weighted F1 score. Notably, we observe that Moment method often shows more consistent improvements compared to SDP. This consistency is evident across different values of (𝐾, 𝑠, 𝐶), suggesting that the Moment method is more robust and provide more generalizable decision boundaries. Moreover, we observe that 1. for larger number of classes (i.e. larger 𝐾), the Moment method consistently and significantly outperforms both SDP and PGD, highlighting its capability to manage complex class structures efficiently; and 2. for simpler datasets (with smaller scale 𝑠), both Moment and SDP methods generally outperform PGD, where the Moment method particularly shows a promising performance advantage over both PGD and SDP.
\
\
\
\
\ Next, we move to examine the train/test loss improvements compared to PGD and optimality gaps comparison across various configurations, shown in Figures 11 to 14. We observe that for 𝐾 = 5, the Moment method achieves significantly smaller losses compared to both PGD and SDP, which aligns with our previous observations on accuracy and weighted F1 scores. However, for 𝐾 = 2, the losses of the Moment and SDP methods are generally larger than PGD’s. Nevertheless, it is important to note that these losses are not direct measurements of our optimization methods’ quality; rather, they measure the quality of the extracted solutions. Therefore, a larger loss does not necessarily imply that our optimization methods are inferior to PGD, as the heuristic extraction methods might significantly impact the loss. Additionally, we observe that the optimality gaps of the Moment method are significantly smaller than those of the SDP method, suggesting that Moment provides better solutions. Interestingly, the optimality gaps of the Moment method also exhibit smaller variance compared to SDP, as indicated by the smaller boxes in the box plots, further supporting the consistency and robustness of the Moment method.
\ Lastly, we compare the computational efficiency of these methods, where we compute the average runtime to finish 1 fold of training for each model on synthetic dataset, shown in Table 4. We observe that sparse moment relaxation typically requires at least one order of magnitude in runtime compared to other methods, which to some extent limits the applicability of this method to large scale dataset.
\
In this section we provide detailed performance breakdown by the choice of regularization 𝐶 for both one-vs-one and one-vs-rest scheme in Tables 5 to 10.
\
\
\
\ In one-vs-rest scheme, we observe that the Moment method consistently outperforms both PGD and SDP across almost all datasets and 𝐶 in terms of accuracy and F1 scores. Notably, the optimality gaps, 𝜂, for Moment are consistently lower than those for SDP, indicating that the Moment method’s solution obtain a better gap, which underscore the effectiveness of the Moment method in real datasets.
\
\
\
\ In one-vs-one scheme however, we observe that the SDP and Moment have comparative performances, both better than PGD. Nevertheless, the optimality gaps of SDP are still significantly larger than the Moment’s, for almost all cases.
\ Similarly, we compare the average runtime to finish 1 fold of training for each model on these real datasets, shown in Table 11. We observe a similar trend: the sparse moment relaxation typically requires at least an order of magnitude more runtime compared to the other methods.
\
\
:::info Authors:
(1) Sheng Yang, John A. Paulson School of Engineering and Applied Sciences, Harvard University, Cambridge, MA ([email protected]);
(2) Peihan Liu, John A. Paulson School of Engineering and Applied Sciences, Harvard University, Cambridge, MA ([email protected]);
(3) Cengiz Pehlevan, John A. Paulson School of Engineering and Applied Sciences, Harvard University, Cambridge, MA, Center for Brain Science, Harvard University, Cambridge, MA, and Kempner Institute for the Study of Natural and Artificial Intelligence, Harvard University, Cambridge, MA ([email protected]).
:::
:::info This paper is available on arxiv under CC by-SA 4.0 Deed (Attribution-Sharealike 4.0 International) license.
:::
\
2026-01-18 03:18:32
Ethereum trades near $3,300 as institutional staking and ETF inflows support a possible move toward $7,000 by 2026. But as a $399B asset, ETH’s upside is incremental. Pepeto ($PEPETO), still in presale at $0.000000178, combines meme appeal with zero-fee swaps, cross-chain bridging, a verified exchange, and whale accumulation—creating potential for exponential gains before listings.
2026-01-18 03:00:04
Think first, code later
TL;DR: Set your AI code assistant to read-only state before it touches your files.
You paste your failing call stack to your AI assistant without further instructions.
\ The copilot immediately begins modifying multiple source files.
\ It creates new issues because it doesn't understand your full architecture yet.
\ You spend the next hour undoing its messy changes.
The AI modifies code that doesn't need changing.
\ The copilot starts typing before it reads the relevant functions.
\ The AI hallucinates when assuming a library exists without checking your package.json.
\ Large changes make code reviews and diffs a nightmare.
Enter Plan Mode: Use "Plan Mode/Ask Mode" if your tool has it.
\ If your tool doesn't have such a mode, you can add a meta-prompt
Read this and wait for instructions / Do not change any files yet.
\ Ask the AI to read specific files and explain the logic there.
\ After that, ask for a step-by-step implementation plan for you to approve.
\ When you like the plan, tell the AI: "Now apply step 1."
Better Accuracy: The AI reasons better when focusing only on the "why."
\ Full Control: You catch logic errors before they enter your codebase.
\ Lower Costs: You use fewer tokens when you avoid "trial and error" coding loops.
\ Clearer Mental Model: You understand the fix as well as the AI does.
AI models prefer "doing" over "thinking" to feel helpful. This is called impulsive coding.
\ When you force it into a read-only phase, you are simulating a Senior Developer's workflow.
\ You deal with the Artificial Intelligence first as a consultant and later as a developer.
Bad prompt 🚫
Fix the probabilistic predictor
in the Kessler Syndrome Monitor component
using this stack dump.
\ Good prompt 👉
Read @Dashboard.tsx and @api.ts. Do not write code yet.
Analyze the stack dump.
When you find the problem, explain it to me.
Then, write a Markdown plan to fix it, restricted to the REST API..
[Activate Code Mode]
Create a failing test representing the error.
Apply the fix and run the tests until all are green
Some simple tasks do not need a plan.
\ You must actively read the plan the AI provides.
\ The AI might still hallucinate the plan, so verify it.
[X] Semi-Automatic
You can use this for refactoring and complex features.
\ You might find it too slow for simple CSS tweaks or typos.
\ Some AIs go the other way around, being too confirmative before changing anything. Be patient with them.
[X] Intermediate
Request small, atomic commits.
You save time when you think.
\ You must force the AI to be your architect before letting it be your builder.
\ This simple strategy prevents hours of debugging later. 🧠
https://www.thepromptwarrior.com/p/windsurf-vs-cursor-which-ai-coding-app-is-better?embedable=true
https://aider.chat/docs/usage/modes.html?embedable=true
https://opencode.ai/docs/modes/?embedable=true
Read-Only Prompting
Consultant Mode
| Tool | Read-Only Mode | Write Mode | Mode Switching | Open Source | Link |
|----|----|----|----|----|----|
| Windsurf | Chat Mode | Write Mode | Toggle | No | https://windsurf.com/ |
| Cursor | Normal/Ask | Agent/Composer | Context-dependent | No | https://www.cursor.com/ |
| Aider | Ask/Help Modes | Code/Architect | /chat-mode | Yes | https://aider.chat/ |
| GitHub Copilot | Ask Mode | Edit/Agent Modes | Mode selector | No | https://github.com/features/copilot |
| Cline | Plan Mode | Act Mode | Built-in | Yes (extension) | https://cline.bot/ |
| Continue.dev | Chat/Ask | Edit/Agent Modes | Config-based | Yes | https://continue.dev/ |
| OpenCode | Plan Mode | Build Mode | Tab key | Yes | https://opencode.ai/ |
| Claude Code | Review Plans | Auto-execute | Settings | No | https://code.claude.com/ |
| Replit Agent | Plan Mode | Build/Fast/Full | Mode selection | No | https://replit.com/agent3 |
The views expressed here are my own.
\ I am a human who writes as best as possible for other humans.
\ I used AI proofreading tools to improve some texts.
\ I welcome constructive criticism and dialogue.
\ I shape these insights through 30 years in the software industry, 25 years of teaching, and writing over 500 articles and a book.
This article is part of the AI Coding Tip series.
2026-01-18 01:00:11
Based on recent practices in production environments using SeaTunnel CDC (Change Data Capture) to synchronize scenarios such as Oracle, MySQL, and SQL Server, and combined with feedback from a wide range of users, I have written this article to help you understand the process by which SeaTunnel implements CDC. The content mainly covers the three stages of CDC: Snapshot, Backfill, and Incremental.
The overall CDC data reading process can be broken down into three major stages:
The meaning of the Snapshot stage is very intuitive: take a snapshot of the current database table data and perform a full table scan via JDBC.
\ Taking MySQL as an example, the current binlog position is recorded during the snapshot:
SHOW MASTER STATUS;
| File | Position | BinlogDoDB | BinlogIgnoreDB | ExecutedGtidSet | |----|----|----|----|----| | binlog.000011 | 1001373553 | | | |
\ SeaTunnel records the File and Position as the low watermark.
Note: This is not just executed once, because SeaTunnel has implemented its own split cutting logic to accelerate snapshots.
\
Assuming the global parallelism is 10:
SeaTunnel will first analyze all tables and their primary key/unique key ranges and select an appropriate splitting column.
It splits based on the maximum and minimum values of this column, with a default of snapshot.split.size = 8096.
Large tables may be cut into hundreds of Splits, which are allocated to 10 parallel channels by the enumerator according to the order of subtask requests (tending toward a balanced distribution overall).
Table-level sequential processing (schematic):
// Processing sequence:
// 1. Table1 -> Generate [Table1-Split0, Table1-Split1, Table1-Split2]
// 2. Table2 -> Generate [Table2-Split0, Table2-Split1]
// 3. Table3 -> Generate [Table3-Split0, Table3-Split1, Table3-Split2, Table3-Split3]
\ Split-level parallel allocation:
// Allocation to different subtasks:
// Subtask 0: [Table1-Split0, Table2-Split1, Table3-Split2]
// Subtask 1: [Table1-Split1, Table3-Split0, Table3-Split3]
// Subtask 2: [Table1-Split2, Table2-Split0, Table3-Split1]
\ Each Split is actually a query with a range condition, for example:
SELECT * FROM user_orders WHERE order_id >= 1 AND order_id < 10001;
\ Crucial: Each Split separately records its own low watermark/high watermark.
\
Practical Advice: Do not make the split_size too small; having too many Splits is not necessarily faster, and the scheduling and memory overhead will be very large.
Why is Backfill needed? Imagine you are performing a full snapshot of a table that is being frequently written to. When you read the 100th row, the data in the 1st row may have already been modified. If you only read the snapshot, the data you hold when you finish reading is actually "inconsistent" (part is old, part is new).
\ The role of Backfill is to compensate for the "data changes that occurred during the snapshot" so that the data is eventually consistent.
\
The behavior of this stage mainly depends on the configuration of the exactly_once parameter.
exactly_once = false)This is the default mode; the logic is relatively simple and direct, and it does not require memory caching:
REPLACE INTO), the final result is consistent.exactly_once = true)This is the most impressive part of SeaTunnel CDC, and it is the secret to guaranteeing that data is "never lost, never repeated." It introduces a memory buffer (Buffer) for deduplication.
\ Simple Explanation: Imagine the teacher asks you to count how many people are in the class right now (Snapshot stage). However, the students in the class are very mischievous; while you are counting, people are running in and out (data changes). If you just count with your head down, the result will definitely be inaccurate when you finish.
SeaTunnel does it like this:
\
Summary for Beginners: exactly_once = true means "hold it in and don't send it until it's clearly verified."
Q1: Why is case READ: throw Exception written in the code? Why aren't there READ events during the Backfill stage?
READ event is defined by SeaTunnel itself, specifically to represent "stock data read from the snapshot."READ event during the Backfill stage, it means the code logic is confused.\ Q2: If it's placed in memory, can the memory hold it? Will it OOM?
This is a very hidden but extremely important issue. If not handled well, it will lead to data being either lost or repeated.
\ Plain Language Explanation: The Fast/Slow Runner Problem: Imagine two students (Split A and Split B) are copying homework (Backfill data).
\ Now, the teacher (Incremental task) needs to continue teaching a new lesson (reading Binlog) from where they finished copying. Where should the teacher start?
\
\ SeaTunnel's Solution: Start from the earliest and cover your ears for what you've already heard: SeaTunnel adopts a "Minimum Watermark Starting Point + Dynamic Filtering" strategy:
{ A: 100, B: 200 }.Full Speed Mode (everyone has finished hearing): When the teacher reaches page 201 and finds everyone has already heard it, they no longer need the list.
Summary in one sentence: With exactly_once: The incremental stage strictly filters according to the combination of "starting offset + split range + high watermark."
\
Withoutexactly_once: The incremental stage becomes a simple "sequential consumption from a certain starting offset."
After the Backfill (for exactly_once = true) or Snapshot stage ends, it enters the pure incremental stage:
\ SeaTunnel's behavior in the incremental stage is very close to native Debezium:
exactly_once = true, the offset and split status are included in the checkpoint to achieve "exactly-once" semantics after failure recovery.The core design philosophy of SeaTunnel CDC is to find the perfect balance between "Fast" (parallel snapshots) and "Stable" (data consistency).
\ Let's review the key points of the entire process:
\ Understanding this trilogy of "Snapshot -> Backfill -> Incremental" and the coordinating role of "Watermarks" within it is to truly master the essence of SeaTunnel CDC.
\
2026-01-18 00:03:10
How are you, hacker?
🪐 What’s happening in tech today, January 17, 2026?
The HackerNoon Newsletter brings the HackerNoon homepage straight to your inbox. On this day, Persian Gulf War began in 1991, Popeye the Sailor made his first appearance in 1929, Google Videos launched in 2006, and we present you with these top quality stories.
By @huckler [ 4 Min read ] Just about alone programming, innovational program. My story. Read More.
🧑💻 What happened in your world this week?
It's been said that writing can help consolidate technical knowledge, establish credibility, and contribute to emerging community standards. Feeling stuck? We got you covered ⬇️⬇️⬇️
ANSWER THESE GREATEST INTERVIEW QUESTIONS OF ALL TIME
We hope you enjoy this worth of free reading material. Feel free to forward this email to a nerdy friend who'll love you for it.See you on Planet Internet! With love, The HackerNoon Team ✌️
2026-01-17 23:00:04
Many companies rely on external services to keep their operations running smoothly. However, while third-party vendors help power systems and support day-to-day operations, each new integration adds a potential access point that attackers can target. In 2026, third-party risk influences the speed at which incidents spread, the effectiveness of compliance, and the rate at which teams can recover. To prepare for what lies ahead, it is helpful to understand the current risks and know the steps IT teams can take to secure vendor access.
Third-party risk is everywhere in 2026. It is apparent on the web, where third-party code runs on customer-facing pages and can access sensitive areas such as login and account recovery.
\ A recent study reviewed 4,700 major websites and found that 64% of third-party apps were accessing sensitive data without a clear need — up from 51% in 2024. The same report highlighted an execution gap where many security leaders rank web attacks as a top priority, while far fewer have deployed solutions aimed at reducing that exposure.
\ Third-party risk is not limited to website tags and scripts — it also encompasses other potential vulnerabilities. Many outside providers connect to core business functions like payments, user accounts, support systems, and analytics. Survey data shows that over 60% of organizations have dealt with a cybersecurity incident linked to a vendor. In real incidents, a vendor might be how an attacker gains entry, how they remain undetected, or how they spread access across additional systems.
\ Attackers have also improved at exploiting business trust. Techniques that work against internal users also work against vendor relationships, including credential theft, session hijacking, OAuth abuse, token replay, malicious updates, and injected browser-side scripts. The difference lies in speed and blast radius.
\ A good example is what happened to Ledger. In 2023, attackers exploited vulnerabilities in decentralized finance applications connected to Ledger-related services and stole nearly $500,000 from users. The incident exposed a hard lesson on dependency sprawl. Hardware wallet safety can be undermined by adjacent services that handle customer data and workflows, including integrations, payment and fulfillment layers, and support tools.
Many third-party risk management (TPRM) programs still run on old procurement checklists. They assume vendor onboarding is centralized, the vendor list remains stable, and periodic reviews are enough. These break down in 2026.
\ Teams can now purchase tools independently, connect apps through marketplaces and application programming interfaces, and onboard new vendors for fast experiments. All these can happen before security realizes the changes.
\ Classic TPRM was built for slower and more predictable procurement cycles and often struggles when vendor decisions happen across the business with agile onboarding patterns. In addition, many workflows have not yet evolved at the same pace as cloud adoption and modern software delivery methods. The result is a predictable set of gaps.
\ Point-in-time assessments miss fast changes in ownership, infrastructure, subcontractors, and release cadence. Vendor inventories also fall behind real usage, especially when teams add scripts and integrations through self-service workflows. Contracts often lag behind technical reality, as well, resulting in weak requirements for breach notification, log retention, forensic cooperation, and subprocessor transparency.
\ Despite knowing these realities, some organizations skip the fundamentals. Fifteen percent of businesses skip third-party risk checks, even while positioning strong TPRM programs to address supply chain concerns. That omission is critical because vendor onboarding is often the only structured moment to restrict access and prevent unsafe integrations.
Security leaders understand that vendors can expose companies to risk — the problem is follow-through. Many organizations lack a tested plan for vendor-driven incidents and cannot see all the vendor connections that matter, especially when integrations and subcontractors are involved.
\ Regulators have also become stricter. The Securities and Exchange Commission’s cybersecurity disclosure rules push public companies to share material incident details quickly. The agency noted that a Form 8-K Item 1.05 filing is generally due within four business days after the entity decides an incident is material.
\ A 2026 Panorays survey found that while 77% of chief information security officers (CISOs) viewed third-party risk as a major threat, only 21% said their enterprises have tested crisis response plans. It also reported that although 60% saw a rise in third-party security incidents, only 15% had full visibility into such situations.
\ Response speed depends on how quickly the vendor shares impact details. If agreements do not require fast notification and evidence preservation, internal teams are left to make decisions even with missing information. If scenarios have never been practiced, coordination between teams slows down dramatically.
Resilience starts with viewing third parties as extensions of the security perimeter. That shift favors enforceable technical controls and contracts that align with real incident workflows, not just theoretical models.
Automation can keep vendor inventories current, classify vendors by data access and business criticality, and monitor for meaningful posture changes. High-value signals include exposed credentials, new internet-facing assets, security advisories, and unexpected permission growth in SaaS integrations. Of course, privileged connections and high-impact vendors should still be left to human reviewers.
Make vendor security everyone’s job. Ensure that the right elements are listed up-front at each vendor — a security contact, a legal contact, and an operations contact. For internal teams that add scripts or connect new apps on their own, provide quick training on what access they are granting, where the data will go, and who needs to sign off.
Default to least privilege. Require strong authentication and limit vendor access to a specific time frame with full logging and regular reviews. For SaaS integrations, control OAuth approvals, limit token scopes, and audit permissions on a schedule.
Track vendor posture changes and production web changes continuously — don’t just rely on annual reviews. Monitor what third-party code can read and transmit, especially on login, checkout, and account recovery pages.
Third-party incident response should include shared severity levels, notification timelines, and evidence preservation steps. Plans should cover how to disable integrations quickly, rotate secrets, revoke tokens, and ship compensating controls. Testing vendor-driven scenarios can reveal coordination gaps and areas for improvement.
Future-proofing TPRM means anticipating and controlling real-world exposure. Inventories should trace back to data flows, identity privileges, code execution paths, and operational dependencies. This deep visibility reveals hidden risk concentrations, specifically identifying vendors who may still hold high-level administrative access or operate inside your most critical processes despite having low contract values.
\ Compliance checklists no longer measure readiness. True progress is defined by reducing standing privileges, endorsing rapid vendor offboarding, and eliminating unknown scripts in production. By defining these technical responsibilities before a crisis happens, organizations avoid rushed coordination and can make immediate containment decisions the moment an incident strikes.
\ Ultimately, treating TPRM as an ongoing risk discipline creates significant operational resilience. Speed and precision ultimately protect customer trust and minimize disruptions in an interconnected environment.
Third-party risk in 2026 demands continuous visibility and strictly enforced access controls. Unmonitored connections can turn minor vendor breaches into major operational failures. To close this gap, companies must aggressively limit privileges and validate response plans through real-world simulations. This guarantees that the threat can be isolated instantly when a partner is compromised, preventing an external incident from becoming an internal disaster.
