Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)R
Posts
0
Comments
96
Joined
3 yr. ago

  • There's a whole lot of math in that article, and to be honest I'm not 100% clear on what they're trying to say. I think they're talking about how standard quantization isn't making full or "accurate" use of the number space, although if you read through to the end they note that there's really nothing terribly wrong with the standard way. But here's my take.

    To simplify, I'll use an integer range 0-4 instead of 0-255, but the principle's the same.

    So, say that we're quantizing from a floating-point range of 0.0-1.0 to an integer range of 0-4. Doing things the usual way, that'd be the orange numbers on the bottom of this diagram:

    But you can see that this doesn't line up cleanly with a nice, regular division of the range into 5 equal blocks. If we just multiply by 4 (our integer max) and then round off to the nearest integer, the original value ranges represented by our integer 0 and 4 are half the size of the others. E.g. 0.0 to 0.49 become 0, but 0.5 to 1.49 become 1.

    Now, if we want to represent true 0.0 and 1.0 simply with our integer range (0-4), we should use 0 to exactly equal 0.0, and 4 to exactly equal 1.0. And converting from integer to float by calculating [value / 4] (or [value / 255] in reality) will get us exactly that. I wouldn't change that.

    What I would suggest changing--to anyone who cares enough about it--is how the numbers are converted from float to integer. If you look at the diagram again, you can see that there is one orange integer per evenly-divided block, even if they don't line up with the centers of the blocks. If we take a float (0.0-1.0) representation and multiply it by our integer max plus one, we'll get the blue numbers at the top of the diagram. Then all we have to do is round down to the nearest integer and cap the result at 4 (or 255, or whatever our integer max is), and we'll have a nice, even distribution in our conversion.

    I could have misunderstood, but it seems like all of the errors and uncertainty discussed in the article come from how the multiplied floats are truncated into integers. I think that this method eliminates that cleanly.

  • Surely it shouldn't be surprising that a technology which literally can only regurgitate bits of things which others have already made, when put into the hands of people whose imagination is limited to what already exists (or alternatively, is not meaningfully directed) precisely because they lack an understanding of the underlying principles, results in only slight variations of the things we already have.

    I can't immediately give you a smartphone app concept that completely breaks an existing, arbitrary taxonomy, but there are two good reasons for that. One; anything that can still run on a smartphone can almost certainly be shoehorned into any existing taxonomy by carefully-worded arguments. Two; by the time a break with tradition is clear enough that such arguments become impossibly tenuous, smartphones will be things that our great-grandparents used to use.

    To counterpoint the author's smartphone analogy, think of how people looked at their TVs in the early 1970s. It was a society-changing but by that time relatively established technology with high growth. And people had all sorts of ideas for "new" things to do with it. You could've made arguments regarding most of them in the same vein as the arguments in this article. Most of those ideas were half-baked and failed at the time... only to resurface decades later, altered, refined, and successful, on PCs and smartphones. But PCs and smartphones are not, in any real sense, TVs.

    Which surprisingly, once I hunkered down and pushed my way through this lengthy essay, is essentially one of the points that I think the author is making (although obliquely): That by the time this technology has evolved beyond its current limits, it will no longer be something that we recognize as "software" in the current sense.

    I suggest trying to keep the concepts of "integrated system design" and "algorithmic process definition" separate from "digital computer software" in a similar way. Which, funnily enough, are the parts of all of this at which humans arguably still beat LLMs.

  • This made me laugh out loud.

    "Click or tap on all pictures of ARMED INSURGENTS TAKING COVER IN RUINED BUILDINGS until no more are left."

  • We bought a new car a few years ago that came with a whole suite of sensors and warnings. I'd like to turn them off, but my partner insists on turning them on again every time I do, so I need to deal with them. In the first six months with the new car, I think I had four or five near-accidents caused by the "safety" system suddenly making some loud noise when I was already partway through a manoever. But after a while I became able to tune out the stream of beeps, boops, and buzzes that come about half a second too late to be of any use, when they're not false alarms.

    The car also has a "safety" feature I don't think I can disable, that restricts acceleration when proximity sensors are triggered. It was not a pleasant feeling to be in the path of a multi-ton truck, flooring the accelerator, and having the car slowly mosey forward at the pace of a quiet afternoon stroll down a country lane. Worse, I believe that it was the barrelling behemoth itself which caused this reaction. Fortunately, I found quite by accident that if you keep pumping the accelerator in a blind panic for a couple of seconds, the car decides that you might really be serious about accelerating, and that maybe it should defer to the actual human intelligence that's nominally in control of the vehicle. That, or the idiot software finally clocked that I was already in the truck's way, and needed to get out of it. But subsequent events have lent credence to the pedal-pumping theory.

    I feel like new, automated "safety" features are going to kill and injure at least as many people as they protect.

  • Great! Let's put 24/7 webcams in his house, so he'll perform spectacularly and we can get many more absolute banger ideas like this one!

    I'm just doing what the man himself says: "Fighting for a world where the watching goes both ways." But then, I suspect that when he said that he was thinking it's "us versus the government", and not "regular citizens versus billionaire tech-robber-barons".

    Why do these tech-bros always seem to act like the problem is government, and they're somehow "fighting the good fight" no matter what they do? The problem is any powerful group with the power to steamroller others. And big business is at least as bad as big government.

  • A little while ago in a retrogaming community, someone asked why Atari 2600 games always ran at 60fps when even NES games sometimes had slowdown. It was explained that the video system in the 2600 isn't independent of the main CPU as it is in other consoles, so if the game program doesn't keep updating the display with correct timing, it gets scrambled.

    Truly no choice!

  • In both cases the trading value of the currency has almost nothing to do with who originated it, and almost everything to do with how the general public feels about it.

    Just like crypto, most "government" currencies are worth what they're worth only because everyone agrees that they are. That's called "fiat" currency. And that's why fiat currency exchange markets exist. The US Dollar hasn't been "convertible" (redeemable for a fixed amount of precious metal) since 1971, and many other world currencies were already backed in some way by the US Dollar at that time.

    The real difference is in the supply.

    Government fiat currency is difficult to counterfeit, although the government (or reserve bank) can always make more whenever they want. We trust them not to print more money, increasing the money supply and devaluing the currency. However, this is exactly what has happened sometimes in the past, and no doubt will happen again in the future.

    Crypto currency is virtually impossible to counterfeit, and IIRC there's a finite (but not precisely known) amount of it that can be made, no matter who you are.

    Personally, I still use physical fiat currency and no crypto. I'd like to use crypto, but regulation in my country makes it very difficult to use without registering your details with a central authority. And although everyone's pushing e-money options which are similarly tracked, thankfully I still have the option of using anonymous cash.

    I don't do anything bad or illegal. I just believe that government and big business don't deserve to know everything I do in my life simply because they want to.

  • I presume that the code was tested for various cases where there was at least one previous password on record, but everyone forgot about new users with no previous passwords. However I'm having trouble imagining what the code could actually be doing.

    I can only imagine a dynamically typed language, and a "checkedPasswords" variable being declared but uninitialized, then a loop incrementing that variable for each non-similar password pulled from the records, and finally a check to see if checkedPasswords equals the number of stored previous passwords.

    The execution environment could type and initialize the variable by default after the first increment, but in the case of the user having no previous passwords on record that wouldn't happen, and the final equivalency check would be comparing an integer to some internal "NaN" state, thus failing.

  • I fixed it, but that is weird. I originally thought it had a double "r", but I looked it up to check and I'd swear that the results spelled it with only one. Now I check again and it's a double "r".

  • Must be arrabbiata, 'cause it's got quite a burn.

  • Your comment seems to be trying to disagree with me, but I think you wrote almost the same things that I wrote in the comment that you're replying to:

    • The Rust book is about much more than just what's in its title (my point being that this also goes for the cited C++ book).
    • C++ is a baroque and sometimes unwieldy language.
  • Initialization in C++ is so simple that somebody wrote a nearly 300-page book on the subject

    There's a book about 101 ways to cut potatoes. Perhaps that could be a real mike-drop bit of evidence that we shouldn't be cooking potatoes.

    Here's a 249-page book "just" about atomics and locks in Rust. Does a book this large about only one aspect of Rust prove that it's a terrible language? No, because as with the C++ book, if we look at the summary of contents we can see that it actually covers a great deal more, simply with a focus on those topics.

    Luckily we don't have to be compete masters of every aspect of a language in order to use it.

    Honestly, I think that modern C++ is a very piecemeal language with no clear direction, and it has many issues because of that. But the title and page count of a single book is not a convincing argument of anything.

  • I'm all for humourous roasts of things, but does anyone really find this funny? Was the author possibly being serious? I don't know. What I do know is that I stopped watching after the first four examples because they were all deliberately incorrect or misleading, but also didn't seem funny to me.

    1. Crazy initializationThat sure is a lot of ways to initialize a variable! Even though some of these variables are quite different and would be initialized differently from each other in many other languages, even only counting the initializations that are functionally equivalent, there are a bunch of abuses of syntax that I've never seen used in the wild.

    At this point I had hope that this was meant to be amusing.

    1. Printing to the consoleC++ has had a version of C's printf function from the very beginning. That weird stream syntax has some hardcore fans but many people ignore it. I did my CS degree close to 30 years ago, and the only time I used stream syntax was for one lab class exercise in which we had to show that we understood how to use stream syntax.

    They still could be going for a comedy roast, I guess.

    1. Getting a random numberMuch like the printf statement for number 2 above, C++ had its own version of C's rand function from the start. I've never even heard of the stuff that's being shown in this part of the video.

    OK that was virtually the same fake point as the previous one, and still no punchlines in sight.

    1. Having to type "static_cast" every time you recast a variableNope, you don't. You're free to ask the compiler to automagically recast your variables to another type without giving any further detail just like you can in C. In fact, they're often called "C-style casts". There are even implicit casts, where you literally don't add anything, and just cross your fingers that the compiler does what you think it should do. It's like a little bit of the thrill of dynamic typing brought into C++! By using the static_cast keyword, you can tell the compiler that you understand that there's a potential issue with this recast, but that you expect that the standard way of handling it will be fine. There are other keywords for more unusual situations; it's not just a random bit of busywork added for no reason.
  • Reading current discussion, it seems more like "You say that it's impossible to dirty your house, yet nothing's stopping anyone from dumping out this bucket of mud on your floor, curious!"

  • Sorry for not being clear; when I said "keep track automatically" I meant dynamic typing. Of course you're right that "keeping track of your variables" could also be interpreted to refer to static typing.

  • I started programming in a time when the idea that the computer could keep track of your variable types for you automatically was a fever dream, so it's wild for me to see some programmers now throwing shade at particular langages for "not implementing proper variable typing functionality".

    It feels like someone saying that low-fat milk producers are too cheap or lazy to put enough fat in their milk.

    Fashion really does go in cycles.

  • Drum memory predates the Sinclair by quite a while. But there is an often repeated story involving an impossibly-optimised Blackjack program for a drum memory computer called "The Story of Mel, a Real Programmer".

  • I sympathize with the point of the article, but if someone's seriously citing Flash, which had widespread success for a run of about 15 years before being overtaken by later developments (driven in part by a billionaire with an axe to grind), as a short-lived "dead end" that was best avoided, then how long do they think is a sensible amount of time to wait to see if something's worth spending time and effort? Nothing remains on top forever.

  • I think that the big, highlighted quote a few paragraphs down--which I believe is also by the author of the article, even though they refer to themselves in the third person--seems somewhat at odds with what they say in the rest of the article. I would guess that they started writing it to make an emotional argument, then tried to back it up with logic, but along the way they lost their emotional momentum and forgot exactly what they were supposed to be arguing.

    There's an interesting section further down, though:

    What do we do about it? This horse is not going back in the barn. The billionaires wouldn't let it, anyway.

    There's no need to get it back in the barn; the thing is lame, and only being kept propped up by a lot of (cash) injections and diversions. The facade will fall before they actually get it to work the way they pretend it works.