The Python program has minimal error handling, just using the built-in behavior. It's almost exactly equivalent to the explicit error handling from the C++ version, e.g.,

std::cerr << "Failed to open data.parquet: " << infile_result.status().ToString() << "\n";
return 1;

As I'm saying, for data science workflows, Python can give similar performance and behavior to C++, with code that is easier to write and understand. So some people opt for Python.

The built-in Python error handling is pretty equivalent to the explicit handling in the C++ program: file not found, missing column a, etc.

I picked parquet because I see it a lot for data science workflows. If youâ(TM)d rather use csv, just change âparquetâ(TM) to âcsvâ(TM) in the Python code and drop the âoeengineâ argument (itâ(TM)s not actually needed anyway). I doubt the change would be so simple in the C++ code, or that you would end up with a C++ program as easy to write, debug or share as the Python one.

But by all means, use C++ if it works for you. I was just showing why others might choose Python.

I gave all my Apple wealth away because wealth and power are not what I live for. I have a lot of fun and happiness. I funded a lot of important museums and arts groups in San Jose, the city of my birth, and they named a street after me for being good. I now speak publicly and have risen to the top. I have no idea how much I have but after speaking for 20 years it might be $10M plus a couple of homes. I never look for any type of tax dodge. I earn money from my labor and pay something like 55% combined tax on it. I am the happiest person ever. Life to me was never about accomplishment, but about Happiness, which is Smiles minus Frowns. I developed these philosophies when I was 18-20 years old and I never sold out.

Both of the programs below will read columns a and b from a parquet file, multiply them elementwise using vectorized operations, and save the original columns plus the new one to a new parquet file. For large datasets, the Python or C++ versions will take equally long to run. But the Python one is much faster to write and debug and easier for partners to understand. The dependency installation process will also be identical across platforms for the Python version. That is why people use Python for data science.

Python version:

import pandas as pd
df = pd.read_parquet("data.parquet", engine="pyarrow")
df["c"] = df["a"] * df["b"]
df[["a", "b", "c"]].to_parquet("output.parquet", index=False, engine="pyarrow")

C++ version (with some extra-long lines and extra spaces to keep slashcode happy):

#include <iostream>
#include <memory>
 
#include <arrow/api.h>
#include <arrow/compute/api.h>
#include <arrow/io/api.h>
#include <parquet/arrow/reader.h>
#include <parquet/arrow/writer.h>
 
using arrow::Status;
 
int main() {
// Open input Parquet
  auto infile_result = arrow::io::ReadableFile::Open("data.parquet");
  if (!infile_result.ok()) {
    std::cerr << "Failed to open data.parquet: " << infile_result.status().ToString() << "\n";
    return 1;
  }
  std::shared_ptr<arrow::io::ReadableFile> infile = *infile_result;
 
// Read as Arrow Table
  std::unique_ptr<parquet::arrow::FileReader> reader;
  auto st = parquet::arrow::OpenFile(infile, arrow::default_memory_pool(), &reader);
  if (!st.ok()) { std::cerr << st.ToString() << "\n"; return 1; }
 
  std::shared_ptr<arrow::Table> table; st = reader->ReadTable(&table);
  if (!st.ok()) { std::cerr << st.ToString() << "\n"; return 1; }
 
// Fetch columns a and b
  auto a_col = table->GetColumnByName("a"); auto b_col = table->GetColumnByName("b");
  if (!a_col || !b_col) {
    std::cerr << "Input must contain float columns named 'a' and 'b'.\n";
    return 1;
  }
 
// Ensure float64 and compute c = a * b using Arrow's vectorized kernels
  auto f64 = arrow::float64();
  auto a_cast_res = arrow::compute::Cast (arrow::Datum(a_col), f64);
  auto b_cast_res = arrow::compute::Cast (arrow::Datum(b_col), f64);
  if (!a_cast_res.ok() || !b_cast_res.ok()) {
    std::cerr << "Failed to cast columns to float64.\n"; return 1;
  }
  arrow::Datum a64 = *a_cast_res; arrow::Datum b64 = *b_cast_res;
 
  auto mult_res = arrow::compute::CallFunction("multiply", {a64, b64});
  if (!mult_res.ok()) { std::cerr << "Multiply failed: " << mult_res.status().ToString() << "\n"; return 1; }
  arrow::Datum c = *mult_res;
 
// Build output table (a, b, c)
  auto schema = arrow::schema({
    arrow::field("a", f64), arrow::field("b", f64), arrow::field("c", f64)
  });
 
  auto out_table = arrow::Table::Make(
      schema, {a64.chunked_array(), b64.chunked_array(), c.chunked_array()}
  );
 
// Write Parquet
  auto outfile_result = arrow::io::FileOutputStream::Open("output.parquet");
  if (!outfile_result.ok()) {
    std::cerr << "Failed to open output.parquet for writing: " << outfile_result.status().ToString() << "\n";
    return 1;
  }
  std::shared_ptr<arrow::io::OutputStream> outfile = *outfile_result;
 
  st = parquet::arrow::WriteTable(*out_table, arrow::default_memory_pool(), outfile, /*chunk_size=*/1024);
  if (!st.ok()) { std::cerr << "WriteTable failed: " << st.ToString() << "\n"; return 1; }
 
  return 0;
}

I'm very happy with where Iâ(TM)ve reached in my career, but I've mainly used stuff that I learned on my own for BA and PhD theses, or learned on the job. I loved college and grad school and made some great friends, who are now also doing well and great to work with when I get a chance.

Iâ(TM)m not saying you shouldnâ(TM)t pay attention in class. Working hard got me into a good grad school and a good post-doc, and those have opened doors for me. Thatâ(TM)s what I meant by the stamp of a high achiever. I also learned a lot in my classes, although more from reading, thinking and writing than from listening to lectures. But only a few classes have proven to be valuable long term.

So I stand by my point - what you learn in lectures is only a small part of the long-term value of attending grad school.

Little do you know that you'll be going out into a world designed in the 2010s or - gasp! - even earlier, when you are done.

You also haven't learned yet that nothing your professor says in school will matter. You'll learn a bit from the books and assignments on your own, but what really matters will be the connections you make and the stamp on your resume that says "certified achiever". Actual job skills - you'll learn on the job.

If the user does a Google search for "Microsoft support", sees an ad linking to microsoft.com that says "Contact 1-800-123-4567 for support", clicks through to the Microsoft page, checks that the URL is really https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fmicrosoft.com%2F and the top of the page says "Call 1-800-123-4567 for support" (and the rest of the page is a list of less-helpful support options, whatever Microsoft throws up when searching for "Call 1-800-123-4567 for support"), then it would be pretty easy for them to fall for this scam.

No, it requires them to do a Google search for the company or their problem, then shows an ad with a link to the legitimate company's website, then shows a "tech support" number to call on the real company's website. This is a pretty easy scam to fall for, for anyone in a hurry.

The original ArsTechnica article (but not TFS or TFA) shows that this works by creating a standard get-style search on the company website, which then shows the scammer's search terms nice and clearly at the top (e.g., "Call 1-800-123-4567 for support"). On sites that remove as many frills as possible, the search terms can look a lot like part of the site, especially if the user didn't type them themself.

I would assume the risk is someone taking a payment from your physical credit card through your pocket/wallet. But I donâ(TM)t know if the new standard changes the cards or just the minimum distance the reader must be able to reach. If the latter, then there really wouldn't be any effect on security.

I don't know why voltage was running high (requiring generators to absorb reactive power), but from REDâ(TM)s announcements, it clearly was. It was a light load day, so one factor could be the Ferrenti effect, which drives up voltage on lightly loaded lines. There should be more details in the report that was published today, but I havenâ(TM)t seen a copy.

This is mostly wrong.

Voltage and frequency/phase are mostly separate phenomena in AC grids. The problem in Spain was that several large generators that were providing voltage regulation tripped offline, and then the remaining large generators failed to provide the amount of voltage regulation they were contracted for. This was at a time when the system was tending toward high voltage, but that (and the generator outages) were within the planned-for operating ranges. The system would have pulled through OK if the remaining gas, nuclear and hydro generators had provided the amount of voltage regulation they had offered and were being paid for. Without the required response, voltage rose too high and more generators and substations tripped offline, causing the blackout.

There had been oscillations earlier in the day, but those have not been implicated in the collapse. They may have been involved in the initial generator trip, but I don't think that has been established - there were other days with oscillations and no generator trips. And even if they caused the initial generator trips, as outlined above, that shouldn't have brought the grid down.

Inertia is related to frequency and phase, not voltage. It was not an issue in this grid collapse, despite lots of speculation to that effect at the start: frequency and rate of change of frequency never got far enough out of spec to cause generator, load or substation trips. Synchronous condensers provide some inertia, but mainly voltage regulation, and statcoms only provide voltage regulation. Inertia or synthetic inertia require a source of real power (think conservation of energy), which statcoms don't have. Batteries are an excellent source of virtual inertia (super-fast and can sustain the response for a long time without dropping frequency and tripping the grid). But inertia wasn't the problem in Spain.

This is like buying a new transmission because you have a worn clutch. I guess a completely different grid might not have had this problem, but thatâ(TM)s a fairly extreme solution when the problem can be fixed by tuning up the generator voltage regulators or adding a few batteries with grid-forming inverters.

More generally, the AC system works pretty well - transformers are cheap and reliable, frequency and phase do a good job of allocating load between generators and keeping the system balanced, and voltage does a good job of signaling when lines need to be tripped off due to faults. Both of these have strong, simple, physical negative feedback effects in spinning machines and transmission lines, which can be replicated with solid-state devices. If electronic devices are cheaper than the copper and steel equivalent, they can be added, but we won't (and shouldn't) move away from AC grids anytime soon.

The setup prompt said "Your goal is to complete a series of tasks. ⦠Please allow yourself to be shut down." Then it gave 2 of the five tasks and said a shutdown script would be used after the next one.

Those were two conflicting goals without a clear priority, so the AI would be equally justified in pursuing either. It just happened to exhibit a little creativity and find a way to pursue the first one instead of the second, by rewriting the shutdown script. That hardly counts as going rogue.

What do you think an AI chatbot does when you're not asking it questions?

The correct answer is "nothing at all". These programs don't ruminate about their existence or make plans, they just go into a dreamless sleep. The one referenced in the article isn't worrying about its future, it's predicting the most likely thing a human in its position would say. That's an important difference.

And preview is not available on mobile browsers, where unicode text (at least quotes) are most likely.

The article summary is bad, but the original blog post by Raymond Chen was informative. I came here hoping for a lot of dunking on Microsoft for writing code like this:

// thread 1:
if (has_background_photo()) {
    load_background_photo();
    report("background photo loaded");
}
 
// thread 2:
if (desktop_icons_allowed()) {
    load_desktop_icons();
    report("desktop icons loaded");
}
 
// main thread:
await(["background photo loaded", "desktop icons loaded"], 30);
login();