I spent a while as a professor of electrical engineering. As a student, I always hated when tests were a time trial to get as much done as you could in the time available. Yes, being prepared helps with that. But those tests evaluate calmness under pressure, speed of writing and effectiveness of test-taking strategies more than the material you learned in the course. And if there's only time to answer half the questions, then students only need to know half the material to get a decent grade after the curve. (I also hated mis-written test questions where there was no correct answer.) Speed tests don't predict real-world performance either, because at work you generally have enough time to think (and references), but you have to get it right.

So as a professor I always sat down and answered (and timed) every question on my tests in advance. Then I trimmed it down until there were only 17 mins of material for a 50 min exam. That eliminated speed as a major factor. So then there was also no advantage in taking extra time. If you knew the material well on test day, you would do fine, and if you didn't, you wouldn't. I wish more professors would take this approach.

I am truly dismayed at how long I had to scroll through this thread till I saw a comment that asked this

Seriously we live in The stupidest possible timeline

I honestly don't know what's worse:

The privacy implications / issue reported
or the fact that this even exists..

how is this a thing?

OK, but how did you add them together? My wife added the 9 and the 8 to get 17(0), then added the 8 and the 7 to get 15, then carried the extra 1 back to the 10s place to get 185. So basically what they taught us to do on paper in the 1970s and â80s, but working from left to right instead of right to left (which I also often do, and is probably some other named shortcut).

But I kind of smooshed 98 and 87 together in my head and visualized the 87 giving 2 to pad out the 98 to 100 and leave another 85. That is convoluted to explain but natural to do if thatâ(TM)s how your head works. Which is exactly my point â" no need to teach these shortcuts!

We have a 14-year-old, so have seen similar stuff. I think a lot of what they're trying to do with Common Core is explicitly teach kids all the shortcuts that math-literate people use instinctively, without formal instruction. The problem is, those shortcuts shouldn't really be taught, or at least not as the main technique. You should teach the basic math facts and methods as simply as possible, then let students figure out the fancy ways themselves. Otherwise you just create confusion.

For example, if I asked you, "what is 98 + 87?" you would probably intuitively subtract 2 from 87 to get 85, then add 100 to get 185. Schools are now trying to teach this as a rule called âoeMaking a Hundredâ, âoeFriendly Numbersâ, or âoeUsing Compensationâ, which is unnecessarily complex. They should just focus on the classic "add in columns and carry over" (which is easier to teach and learn), and let people figure out the weird tricks on their own. Then everyone gets some basic proficiency and the people who use a lot of math would figure out the shortcuts on their own. But when you lead with the shortcuts, it just turns into a muddle.

This is likely going to be the only way forward until they disable that option...

I know that Apple very tightly links MacOS with apple accounts, but it is still completely possible to set up a Mac with local account only.. whether you find MacOS useful without an Apple ID associated is entirely another story.

With MS I have never found a compelling reason to want/need/use a MS account directly tied to my windows login. Yes if one uses OneDrive and/OR Office365 or if you want to use your MSDN subscription etc.. but in my case I still just use local windows account and then individually connect to those things only if I want.

My work is moving to Azure/cloud Active Directory I think.. not entirely sure of the migration plan... but thus far I'm still using a "hybrid" where my account is a standard domain user that is using a local cached profile/account on my work machines.

I guess I don't mind if the account brings value as my AppleID does - the tight integration possible with my apple iCloud services is one that I do not mind. But even there, The account I use is a local account and then I just tie it in ./ log in with my Apple ID

Maybe if I had not been a windows user ever since Win 3.1 days Id feel differently about it, I don't know, but this whole you must be connected to MS with an MS account to set it up is annoying AF\ I mean what if someone is in a country / location where they can not easily or safely get online? Sure it doesn't apply to me but it just - I really like not being forced.

The more MS pushes the more I feel like rejecting them. I've drunk the Apple Kool-Aid. abit as I actually do like the integration that MacOS and iPhone have with iCloud (Especially since I use advanced encryption on my iCloud, so to get access to my photos and other stuff on desktop I have to use a Mac that is connected to the account..

But again, that was a choice I made; it was not forced on me.

Every day MS makes me more and more ready to just jump ship for MacOS and Linux /sigh.

I really liked the fact that you can share a PowerPoint presentation as an object rather than an image of the screen. This allows the presenter to see their notes and future slides, while the viewers can flip back and forth between slides and maybe zoom in on details.

But this has aspects of monopolist behavior (using the Office monopoly to support entry into videoconferencing). I wonder if the EU will require Microsoft to create free libraries or APIs for other video conferencing software to do this?

For 20 years, plus or minus, personal computers reversed that idea.

I once wrote a 6808 assembler in Microsoft Excel (to put a scrolling message on a Heathkit ET-3400 I found in the lab). I don't think it would take much more to write one for the 6502.

It's nice to see this. I expect it's like a visit from an old friend for many people on slashdot.

I got my start with computers on the Commodore PET in our middle-school lunchroom, taking apart commercial BASIC programs, changing them to do what I wanted and saving my creations to blank parts at the end of the cassette tape. Then I moved on to summer BASIC classes on a TRS-80 and eventually more serious programming in Applesoft BASIC on an Apple ][+ as a teenager.

Never realized all those BASICs were more or less the same program from Microsoft.

Anopheles mosquitoes only spend abut 2% of their time interested in biting humans (only adult females, for a few hours every few days). So potentially they are doing other important things in the ecosystem the rest of the time. As larvae, they are important filter feeders and food sources in shallow water ecosystems. As adults, they are pollinators and also convert plant sugars into food for bats, birds, frogs, spiders, dragonflies, etc.

On the other hand, one species, Anopheles gambiae, strongly prefers humans over other species, albeit for only a small part of the time. They get over 95% of their blood meals from humans in some villages and are a major vector for malaria. It seems like it might be OK to extirpate a species that cannot live without preying on humans and causes huge harm in the process.

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.