|
|
|
I thought it was a Jackson Pollock
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
modified 22-Nov-23 11:05am.
|
|
|
|
|
I think you're right. It's an AI transcoding of radio frequency noise from Jupiter interpreted as a single image which coincidentally resembles sheet music written by Jackson Pollock as a teenager, prescient of the rock & roll era.
Software Zen: delete this;
modified 23-Nov-23 11:00am.
|
|
|
|
|
Mike Hankey wrote: I recognize that piece, it's a Sonata in E-Minor for the Comb Kazoo.
Who is the composer? Looks like it could be P. D. Q. Bach, but I am unable to find in in the Shickele catalog.
|
|
|
|
|
|
|
So am I, but I'm also immensely glad that people did and some still do.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
If I pull a USB cable from my Android phone (Samusung Galaxy S7 edge, 2016 vintage) to my Win10 PC, I can access both the memory card and the internal phone memory as if they were local disks.
Opening the Properties of a file on the phone, I can read that it is of "Size: 419 KB (429 399.00 bytes)". Well, that makes sense, except that the correct unit would be "419 Ki bytes - we are accustomed to software developers making unit mistakes, especially binary/decimal.
But if the exact size had been reported as, say, 429 399.42 bytes, I would have stalled.
Why is the size reported down to deci- and centibytes? Do all Android phones have the same reporting format, or is is specific to a Win10 driver, or driver specific to my model Samsung phone?
|
|
|
|
|
I'd put it down to sloppy programming. A floating point value makes sense when they're scaling to KB/MB/GT/TB. They didn't bother handling the size as a simple integer when not scaling.
Software Zen: delete this;
|
|
|
|
|
I think they are missing a decimal: if your file is 429399 bytes and 1 bit that makes 429399.125 bytes. Rounding it to 429399.12 is just sloppy 
Mircea
|
|
|
|
|
I was waiting for you to make a Hellraiser reference right up to the end of your post.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
You weren't alone.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
One of my favourite horror franchises. I once made a Pinhead headgear for a party once.
I haven't seen five and above as they're hard to find.
// TODO: Insert something here Top ten reasons why I'm lazy
1.
|
|
|
|
|
0.1 byte.
Angel to some, demon to others. (Insert Windows ME image)
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Did the same on a Ubuntu 22.04LTS system and Samsung A22.
...
Size 639.7 kB (639,675 bytes)
...
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
trønderen wrote: Why is the size reported down to deci- and centibytes?
The "cost" includes taxes?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
trønderen wrote: except that the correct unit would be "419 K
Can't answer the other but that convention for storage has existed for a long time. The K for memory is 1024 and hard drives is 1000. I haven't checked (or even thought about it for a long time) but pretty sure it goes up the same way, so for example G, etc.
Someone might even had tried to create a lawsuit about that long ago?
As for the other probably would be easier to see where it shows up if someone with an IPhone tried it rather than a different Android. If it was the same then more likely something in Windows.
|
|
|
|
|
jschell wrote: Can't answer the other but that convention for storage has existed for a long time.
For hard disks, size has always been given in decimal units - at least all the ones I have ever worked with.
And: Networking people always count bits. When we 35 years ago got 64 kbps ISDN lines, some customers were complaining that they got only a fraction of the expected speed: Less than 8 KB, when they were promised 64! Well, the line transfers exactly (not less than) 8 kilooctets, as promised.
There has been a mess with decimal and binary units for more than 50 years. About 25 year ago, ISO/IEC decided to come up with a solution to clean up the mess. 24 years ago, the standard passed through the formal procedures, and were accepted as an international standard. For 24 years, there has been no reason to carry on the old ambiguity. There is a well defined, internationally recognized standard to show whether you are talking about 1024 or 1000, 1 048 576 or 1 000 000. We all know that before 1999, there was no such standard, but that is long ago! You can't today argue with old millennium lack of standards!
In the old days, some people tried to argue that 'k' is 1000, 'K' is 1024 - completely disregarding that by international standards, 'K' is degrees Kelvin. Those complaining that they got less than 8 kiloBYTES through a 64 kbps line argued that 'B' indicates 'bytes', 'b' indiates 'bits'. One problem is that they could never dig up a promise of 64 KB; only of 64 kbps. Another is that there is no recognized standard defining 'B' to mean 'byte'; if anything (such as by ISO standards), 'B' means 'Bel', a sound level unit (better known as 1/10 Bel, deciBel or dB). If you want to explicitly indicate 8-bit bytes, use the 'o' unit: A 64 kbps line transfers 8 ko per second.
In the old days, a 'byte' could (at least)be from 5 to 9 bit: The space required to store a single character. I guess that there are still machines around providing 6 or 9 bit bytes. In some newer conventions/standards (not at the level of defining general OSI prefixes/units, but e.g. in some programming language standards) 'byte' has been defined as 8 bits. These are application area specific standards - if you want to be very specific about 8 bit units, then use the well defined, standardized unit 'octet'.
Arguing against a standard defined in the previous millennium: 'But earlier in the previous millennium, everyone accepted that we mixed decimal and binary freely without any indication of which were which!', that is no good reason anno 2023 to continue messing things up. It can't be that difficult to add an 'i' after the k, M, G or T when you are talking about binary units. If it is - you don't know whether to add it or not - it proves that there is a mess that you should clean up!
|
|
|
|
|
trønderen wrote: it proves that there is a mess that you should clean up!
Give someone a foot they take a meter.
|
|
|
|
|
The display could be tied to international settings?
How does it report a MB size file like TrackingData.log?
Mac was the only platform that I knew that used 1,000 bytes to equal 1KB. This let their 1.44 3.5inch floppy disks appear even larger than the 1.2MB 5inch floppy that many DOS/Windows competitors used at the time. (circa 1986)
|
|
|
|
|
Yes, it is "international" in the sense that it honors my format preferences. I prefer grouping digits 3 by 3, I prefer a decimal comma rather a decimal point, and if I set the number of decimals to 3, an MB file size is reported like '15,9 MB (16 693 612,000 bytes)'.
The issue here is neither the use of M rather than the correct Mi, the kind of digit grouping or kind of separator, but the use of a decimal point (/comma) and fractional part when presenting an integer number. When teaching programming, I always refer to count values, which programmers like to call 'int' or 'long', and measurement values, which programmers like to call 'float' or 'double'. That makes it much easier for the students to learn when to use int and when to use float. Those programming this Property sheet obviously has not grasped the idea of the number of bytes being a count of bytes in the file. They treat it as if it were a measurement on a continuous scale.
For the Ki/k and Mi/M question (which is a different issue): All hard disks I ever have been in touch with, regardless of computer family, have had their total size specified in decimal units, like k, M, G and T. Networking people always specified line speeds in decimal units - in bits, not bytes. A 64 kbps line (56 kbps for those in North America) transfers 64000 (56000) bits per second.
Floppies arrived before ISO had defined the Ki, Mi, Gi, Ti, ... prefixes, and things were kind of messy - that is why ISO/IEC decided to clean up the mess by defining the standard binary prefixes. There are lots of examples of mixed use of e.g. decimal number of binary units. (The ISO/IEC standard is well above 20 years old now; yet there are lots of people stubbornly resisting to relate to it, insisting that 'We have been using ambiguous units for years, we insist on continuing to do that and do not want to clean up the mess!' 
For the 1.44 MB floppy disks: They did have higher capacity than the 1.2 MB floppies. Maybe it wasn't quite 1.2 times as much - I am not taking the effort to look up the historical details, but when the 3.5" floppies arrived, they did have a (real) higher capacity than the 5.25" ones.
If you go far back in history: In the 1950-60s, machines addressed memory by the word, not by the byte. Memory sizes where given by the number of addressable units: words. Then IBM came with their 360 series, the first major computer series that were byte addressable, and they marketed their memory options by the byte. But their 'kilo' was 1/4 or 1/4.5 (there were lots of 36 bits machines at the time) of the 'kilo' of the competitors. This caused a lot of uproar in the 1960s.
Another unit that has been argued: Well into the 1980s (maybe someone may say even slightly into the 1990s), a byte was recognized as the space required to store a textual character. The Univac 1100 series had two byte size options: Either 6 bit, for 'Fieldata' code, uppercase only, 6 characters to a 36 bit word. Or 9 bit code, usually for ASCII, but when 8 bit character encodings entered the scene, they could be held in a 9 bit byte. The DECsystem 10 and 20 mainframes, also 36 bit machines, went for 7 bit bytes, fitting 5 characters into a word with 1 bit to spare.
In those days, if you were a radio amateur wanting to transmit digital data over your shortwave radio, in many countries you were required to use the 5 bit bytes defined by 'Baudot' telegram code standard. I don't know if that limitation ever existed in North America, and I have never heard of it being enforced in Norway, but formally, it existed longer than anyone would believe.
|
|
|
|
|
Thanks for the followup. I have been in my current post longer than the standard!
“kibibytes” sounds like a good name for a dogfood! (kibble)
I guess comp sci graduates after 1999 will know this.
I am curious now to see if advertisements for memory modules will use the correct prefixes.
|
|
|
|
|
What to expect?
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
|
|
|
|
|
chaos, mayhem and rivers of blood.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
