Re: APL\360
Counting in binary on ones fingers was something I first ran into at age 11 when found a book on Military Electronics in a surplus store. Everything simplified, but in computer section found binary system explained with using fingers to represent bits. That was something that I used immediately as used to count steps to various places but after 1000+ steps would often forget where I was so would increment my binary digital counter every 100 steps. At that age 1 mile was probably about 2500 steps so I my counter would have overflowed at about 40.9 miles. Also LSB was my left small finger which seems weird now but suspect that's what illustration in book showed of how to count in binary on your fingers. Found manual method easier to use than a pedometer. I too count sheep with my fingers, but I never get past zero due to the lack of sheep.:-) Tom Hunter On Mon, Feb 1, 2021 at 5:34 PM Tor Arntsen via cctalk wrote: > On Sat, 30 Jan 2021 at 03:27, dwight via cctalk > wrote: > > If we'd thought about it we could count to 1023 on our fingers. > > Dwight > > Some sheep herders in (IIRC) the Caucasus do, or did at least. I > learned about that some decades ago. Counting sheep on their fingers. > I use the system sometimes. > > -Tor >
Re: APL\360
I too count sheep with my fingers, but I never get past zero due to the lack of sheep.:-) Tom Hunter On Mon, Feb 1, 2021 at 5:34 PM Tor Arntsen via cctalk wrote: > On Sat, 30 Jan 2021 at 03:27, dwight via cctalk > wrote: > > If we'd thought about it we could count to 1023 on our fingers. > > Dwight > > Some sheep herders in (IIRC) the Caucasus do, or did at least. I > learned about that some decades ago. Counting sheep on their fingers. > I use the system sometimes. > > -Tor >
Re: OT: pints, pounds (Was: APL\360
On 01/02/2021 20:07, Fred Cisin via cctalk wrote: A US pint of water weighs 1.043 pounds. One "fluid ounce" (volume) of water weighs 1.043 ounces (weight)! The nit-picker in me would say "you mean mass", except that there's an even bigger nit to pick - the density of water is not constant but varies with temperature! That's also a US measure. An imperial fluid ounce is 28.4ml and a floz of water weighs 28.4g, same as an avoirdupois ounce. In fact it's defined (or was) as the volume of water that weighs one ounce. The volume that weighs one ounce at what temperature? I think it may be 4°C - the temperature of maximum density. I often wondered why the US fluid ounce wasn't the same size as ours. I always assumed that it was measured at a different temperature, until someone said it was from a different definition of the ounce - not avoirdupois, but one of the other systems. The other day I looked up to see whether the density (assuming one ounce avdp) corresponded to a temperature that made sense, and it turns out it corresponds to water at 100°C. Not that my data tables gave a density for water at 100 degrees - but you can extend the line and there it is. I have no idea whether that is how the unit is derived. The definition is in terms of cubic inches, which doesn't help settle the question. Philip.
APOLOGIES; was not meant to be to the list (Was: PRIVATE: OT: pints, pounds (Was: APL\360
Sorry about that. I didn't pay close enough attention to my outgoing header.
PRIVATE: OT: pints, pounds (Was: APL\360
I may use metric when I am measuring things myself, but I got my motorbike licence in 1991 and my car licence in 2005. I was solely taught and tested in MPH. For estimating stopping distances by eye, a metre is a yard, near enough -- and of course "car lengths" and seconds aren't affected. Keep 2 car lengths back under 30mph, and over that, maintain 2 seconds' braking distance, is metric-independent. But, none of those are accurate for the physics. Can an Isetta follow much closer than a Cadillac? I don't have an Isetta. I'd like one. I'd love to get the Micro-Lino (a current Swiss electric replica of an Isetta), but they don't plan to export to USA. Stopping distance is also certainly not a constant of 2 seconds, even if talking about both vehicles making a panic stop. My current car (a Prius "Prime") can stop in significantly less distance than my early VWs did. In a panic stop, a VW 2 seconds behind me would plow right into me. How much do you suppose a "pint" of ice cream weighs? Wouldn't know. I have never in my life seen such a unit on sale, I think. Ice Cream used to be sold in 1/2 gallon. The half gallon container has been reduced to "1.5 quarts/1.41L". "The reduction in size is to avoid raising the price" (which went up ALSO) Half gallon carton of milk (64 fluid oz) is now a 54 oz carton. Tiny cartons of ice cream exit, and used to be called "Pints": 16 fluid oz/473ml DELIVERY of ice cream is pretty risky; good if you are one of the first stops of the delivery, . . . Yet more reason to burn imperial measurements in a fire and throw the ashes in the sea. YES Despite very minor variances in gravity, Earth is MOSTLY HARMLESS. ;-) DNA once told aspiring writers, "Never blow up the planet in the first chapter; you are likely to find that you need it later." Did you know that the Central African Republic covers one of the largest magnetic anomalies in the world? It's so big it's named after the capital of the CAR, which will of course make it trivial for you all to look it up. Interesting. And never noticed until 1950? I can get beer delivered! Coincidentally, it is Corona beer! Oh my word. My deepest condolences. It's a Mexican American beer. I drink very little. If I were a drnker, I'd have to find something else. -- Grumpy Ol' Fred ci...@xenosoft.com
Re: OT: pints, pounds (Was: APL\360
On Mon, 1 Feb 2021 at 21:07, Fred Cisin via cctalk wrote: > > That is what it MEANS. > But, it's not quite right. It's off by about 4%. > A US pint of water weighs 1.043 pounds. > One "fluid ounce" (volume) of water weighs 1.043 ounces (weight)! Close enough for government work. With all the off-hand mental approximations people use to convert units, including some I think mentioned here, 4% is pretty good. I may use metric when I am measuring things myself, but I got my motorbike licence in 1991 and my car licence in 2005. I was solely taught and tested in MPH. For estimating stopping distances by eye, a metre is a yard, near enough -- and of course "car lengths" and seconds aren't affected. Keep 2 car lengths back under 30mph, and over that, maintain 2 seconds' braking distance, is metric-independent. > How much do you suppose a "pint" of ice cream weighs? Wouldn't know. I have never in my life seen such a unit on sale, I think. > And, not all beer has the same specific gravity. Alcohol is less dense > than water. > And, of course, further variation with temperature and atmospheric > pressure. Indeed so. It does get worse. When I emigrated, I had no problem adapting to buying half litres of beer -- or even, just once in a brewery in Slovakia, a litre of beer. But the strengths...! Czech beer comes in 10º, 11º, or 12º, and very occasionally 13º, 14º or even 17º-18º. I have almost never seen anything stronger. But what the heck is a ten-degree beer?! I'd never heard of degrees in beer before. Degrees proof, yes, but just halve that for %ABV, which is far more meaningful for me. But while a 10º beer being 5% alcohol by volume was just about believable, a 15% ABV beer seems unlikely. Well, it is. The system is "degrees Plato", a system so obscure there isn't even a Wikipedia page for it. And all I knew about Plato's drinking habits was: « Plato, they say, could stick it away Half a crate of whiskey every day » It's horribly complicated in use: http://8degreesplato.com/2017/05/31/so-what-is-degrees-plato/ No wonder nobody much outside Central Europe uses it. But this country is the world capital of beer -- they consume more per capita than anyone else. There are good reasons I like it here, and it's not the language. https://news.expats.cz/czech-food-drink/the-czech-republic-leads-all-nations-in-beer-consumption-per-capita-by-a-whopping-78/ The USA drinks 12x as much in total -- but has nearly 40x as many people. > And, if you are in England, > "A pint of water weighs a pound and a quarter." I believe I have heard that. Maybe this is why it is meaningless to me -- it doesn't work with UK Imperial units, only with American Imperial units. Yet more reason to burn imperial measurements in a fire and throw the ashes in the sea. > Despite very minor variances in gravity, Earth is MOSTLY HARMLESS. ;-) Did you know that the Central African Republic covers one of the largest magnetic anomalies in the world? It's so big it's named after the capital of the CAR, which will of course make it trivial for you all to look it up. > Instead, it just means that British pubs are not as stingy with their > beer. And, it doesn't need to be chilled to almost frozen to make it > drinkable. Very true. British beer is often served with very little foam on top, so the capacity of the glass is measured to the brim. A Czech beer without at least a few centimetres of foam is considered defective and most drinkers would send it back -- so Czech beer glasses are lined instead, to leave plenty of space for the froth on top. > I wish that there were a pub open. Oh gods, me too. > But, "The Albatross" (pub in Berkeley) > has closed down. forever. Can't stay in business with a lockdown. Sorry to hear that. > I can get beer delivered! Coincidentally, it is Corona beer! Oh my word. My deepest condolences. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: APL\360
On Tue, Feb 02, 2021 at 08:50:56PM -0700, ben via cctalk wrote:
> On 2/1/2021 6:07 AM, Peter Corlett via cctalk wrote:
[...]
>> You're describing a failing in C and similar languages stuck in the
>> 1960s. Here's a Rust method that does add-exposing-carry:
>> https://doc.rust-lang.org/nightly/std/primitive.u32.html#method.overflowing_add
> So why could this not have been done 30 earlier?
(I assume you mean "30 years earlier" here.)
Two reasons, one of which I was already aware of back then in 1991, and one
which is only obvious in hindsight.
The first is simple toxic masculinity. It's more manly to write stuff in
machine code (then) or C (now), apparently.
The second is a combination of Moore's Law and computer science. To handwave
wildly, Rust is what you get when you look at C++'s mistakes of the last
forty years and start again. If you've used a C++ compiler from the 1980s or
early 1990s, you'll have found the experience harrowing: computers were
still too slow and too small to do a good job, and various important
language design and code-generation techniques were not yet known and/or
were too impractical to implement. It all improved rapidly in the 1990s and
2000s, bringing us more or less to the top of the sigmoid curve.
u32::overflowing_add() returns a (u32, bool), i.e. a two-member struct.
Those early compilers cannot return structs directly, so the caller would
have to reserve space (on the stack, probably) and pass the address for the
function to fill in. That simple add-producing-carry has just become a
function with a half-dozen instructions, several of which are needed to
check the carry flag and convert it into a integer, plus many memory
accesses, just to provide a C wrapper around a simple add instruction. At
that point it does make sense to toss the compiler and write assembly
language.
Modern compilers do a lot of heavy inlining as a matter of course, will
split structs and perform dataflow analysis on individual elements, and
generally avoid memory access unless they absolutely have to.
u32::overflowing_add() should turn into a single add instruction and the
carry flag will probably be tested directly by a branch instruction and
never get converted to a boolean variable. It'll be as good as if not better
than hand-written assembler.
This is a particularly trivial function as well. Rust just wouldn't be
viable with 30 year old compiler technology.
>> The documentation doesn't explicitly say "carry" because Rust is
>> architecture-neutral and it's down to LLVM to decide how to express it in
>> machine code, but on x86 (and probably ARM) the boolean return value
>> comes directly from the carry flag.
> mincing words, sigh.
RISC-V doesn't have a carry flag. It handles overflow by e.g. using the BLT
instruction to branch if the result is smaller than the number being added
to. So documentation which assumes the world is x86 will not make sense here.
[...]
>> You "don't believe in objects" yet then describe a problem which only
>> exists due to the lack of them and then present OO pseudocode to solve
>> it. A lot of OO languages suck of course, but the fundamental idea of
>> encapsulation is not the bit that sucks.
> Are objects? they only way to solve this problem. I see a object as data
> structure tied to some code. What I would like to see data structures
> having fixed constants like array start and end of a structure for a array
> as variables when called into use.
There's no real difference between a "constant ... when called into use" and
a pure function which returns a value based on the structure elements.
>> Here's it in Rust, where it takes in an arbitrary
>> array (pedantically, "slice", a (pointer, element count)-tuple) and
>> determines its length at runtime:
>>
>> pub fn clear_indexed(array: [usize]) {
>>for index in 0 .. array.len() {
>> array[index] = 0;
>>}
>> }
> I don't want Information hiding, I want to know what it does clearly. If I
> can't figure it out how can a computer program do it. Where does ".len()"
> find the size?
That is an implementation detail which you don't need to know to be able to
write Rust code. However, the len() method actually just returns the element
count from the (pointer, element count)-tuple. The function is so trivial
that it is guaranteed to be inlined so it's exactly the same as if you had
accessed the field directly.
Before you ask, no, you can't access the field directly for all of the
excellent reasons explained by every "introduction to OOP" tutorial which I
don't need to repeat.
[...]
>> pub fn clear_iterator(array: [usize]) {
>>for elem in array {
>> *elem = 0;
>>}
>> }
>> Both code fragments generate equivalent assembly in this trivial example
>> because the Rust compiler could prove at compile time that the index
>> variable can't go out-of-bounds. In more complex real-world code it
>> cannot reliably do so and will insert a run-time check which aborts if
>> the index is
Re: APL\360
On 2/1/2021 6:07 AM, Peter Corlett via cctalk wrote:
On Wed, Jan 20, 2021 at 02:05:37PM -0700, ben via cctalk wrote:
[...]
I don't see languages in general have improved since the the mid
1960's. Hardware and language models don't reflect each other,
and don't have extendable data sizes and types.
PL/I seems to have been the best,but too tied to IBM.
C standard 2131 complex numbers
C standard 2143 dubble complex numbers
Every machine I can think of had a carry flag of some type
yet no language uses that to extend it self.
You're describing a failing in C and similar languages stuck in the 1960s.
Here's a Rust method that does add-exposing-carry:
https://doc.rust-lang.org/nightly/std/primitive.u32.html#method.overflowing_add
So why could this not have been done 30 earlier?
The documentation doesn't explicitly say "carry" because Rust is
architecture-neutral and it's down to LLVM to decide how to express it in
machine code, but on x86 (and probably ARM) the boolean return value comes
directly from the carry flag.
mincing words, sigh.
I don't believe in objects because data structures don't have classes, but
are more similar to each other. A window A structure is like window B but
details are different. That makes things look portable when they are not.
Constants still
seem to be embedded in data structures, rather than abstract.
-- zero array
define LIMIT abc
blah array[LIMIT]
...
i = 0 while i< LIMIT array[i] = 0 i = i + 1 endw
I would like say
let LIMIT = abc
blah array[LIMIT]
i = 0 while i< array:LIMIT array[i] = 0 i = i + 1 endw
You "don't believe in objects" yet then describe a problem which only exists
due to the lack of them and then present OO pseudocode to solve it. A lot of
OO languages suck of course, but the fundamental idea of encapsulation is
not the bit that sucks.
Are objects? they only way to solve this problem.
I see a object as data structure tied to some code.
What I would like to see data structures having fixed constants like
array start and end of a structure for a array as variables
when called into use.
Here's it in Rust, where it takes in an arbitrary
array (pedantically, "slice", a (pointer, element count)-tuple) and
determines its length at runtime:
pub fn clear_indexed(array: [usize]) {
for index in 0 .. array.len() {
array[index] = 0;
}
}
I don't want Information hiding, I want to know what it does clearly. If
I can't figure it out how can a computer program do it. Where does
".len()" find the size?
(The code for C-style fixed-length arrays looks broadly similar but has a
bit more boilerplate because they're less useful.)
Iterating over indices is generally discouraged for a number of reasons, not
least being that the index may be out-of-bounds, but also because it can
inhibit vectorisation or parallelisation. You have no choice in broken
languages such as C, but many languages provide some notion of iteration
which guarantees to not go out-of-bounds:
I say the 0 index in C is broken. ... for array size is better.
pub fn clear_iterator(array: [usize]) {
for elem in array {
*elem = 0;
}
}
Both code fragments generate equivalent assembly in this trivial example
because the Rust compiler could prove at compile time that the index
variable can't go out-of-bounds. In more complex real-world code it cannot
reliably do so and will insert a run-time check which aborts if the index is
out-of-bounds. Or if it's C, trundle on and corrupt things.
Why prove it? Just test it at runtime.
C was quick and dirty language that had to shoe horn into UNIX, with
structures tacked on at the last minute. It was up to the programmer not
the language
to check things, and I still see that valid.
Oddly enough, the state of the art has moved on a bit in the half-century
since C was invented. It's just that quite a lot of programmers haven't yet
noticed.
More like SEARCH programming languages
USE JAVA USE C SPONSORED BY
SEARCH RUST PROGRAM
not many items with 'program' ignoring keyword
"Ford truck 5K miles for sale, some rust on the fender"
I have not done programming since about 1990, so modern stuff
don't have clue,nor do I have large powerful machine.
Ben.
Re: APL\360
On 2/1/2021 12:15 PM, Liam Proven via cctalk wrote: On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk wrote: I had always been told, "A pint is a pound, the world around." Aha! Does that mean a pint of water weighs 1lb? Interesting. I did not know. Who Knows? It just works of beer or ale. :) Ben.
NOT "Re: APL\360"
TL;DR: getting tired of separating the wheat from the chaff I have an odd but potentially useful idea for the list server ... Until we have an AI that can properly read a message and re-write the subject line, perhaps the list server would *auto generate* a new subject line after, say, the 29th reply with the same "Re:". After 29 "Re: APL\360", the next such msg would have subject line rewritten to "New topic 1", and the next (up to) 28 "Re: APL\360" would be similarly re-written (the '28' is decremented for every "Re: APL\360" and every "Re: New topic 1"). At that point, the next "Re: APL\360" or next "Re: New topic 1" gets rewritten as "New topic 2". (After a reuse counter for a subject has been 0 for two weeks, it could be reset to 20, to allow much later legitimate replies.) Yeah, tired of getting hopeful seeing "Re: APL\360" and seeing instead a discussion of pints, or endianness (big rules, for a number of reasons ... *even the creator of Intels's memory chip admitted that*), or bit numbering, or counting sheep! :) (And I'm not even complaining about the needless copying of the entire prior post :)
Re: APL\360
On Mon, Feb 01, 2021 at 08:15:25PM +0100, Liam Proven via cctalk wrote: > On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk > wrote: >> I had always been told, "A pint is a pound, the world around." "The world" meaning "the USA", of course. > Aha! Does that mean a pint of water weighs 1lb? Yes, to within the massive margins of error involved in prehistoric units. A fluid ounce of fluid weighs an ounce, oddly enough. This equivalence applies to both British and American units. Although it seems obvious that this is how it's defined, it turns out that it's actually derived from the gallon, because rationality goes out of the window when it comes to this trainwreck of a system. There are 16floz to an American pint and 16oz to a pound, which lines up nicely and gives that rhyme. A British pint is 20floz whereas the pound remains 16oz, hence the alternative rhyme "a pint of water weighs a pound and a quarter". As a bonus, different reference fluids are used, so the floz also differs by roughly 4% as it crosses the Pond. The Dutch haven't quite let go of "ons", "pond" and "pijnt". The latter two have been fudged to 500g and 500ml. I think "ons" might just be used in stock phrases now. Some products ae also dual-labelled and include a floz conversion; I did the maths because the number looked a bit off and it turned out to be American floz. > Interesting. I did not know. >> I had already assumed that pub prices had inflated to higher than a pound. The rhyme refers to weight, not currency... The last pint of Real Ale I had before using my one-way Eurostar ticket the hell out of the place was £4.20. Or four guineas if we're harking back to the era of that rhyme. > It was under £1 for ½litre of beer when I got here. In fact it was under > US$1/ US 1pt. Now it's a bit more. I did enjoy lining them up at €1.40/500ml in Bratislava, and in a tourist trap at that. At some point I should spend more than six hours in Eastern Europe, and a smaller proportion in a pub. Slovakia looked worth a visit outside of the touristy bits, but my companion was being grumpy. > Cheapest I had was CzK 17 for half a litre. At the time that was about 50¢. It was €4.40 for a Happy Hour pijnt when I was last in one of my favourite Amsterdam boozers, which was rather a long time ago now thanks to Rutte's general incompetence at running the country. At today's exchange rate, the €9.49 crate of beer from my local supermarket works out at €0.60/500ml. >> Such worries call for having a few pints. > It is one of the things I miss most in lockdown. And there's no > electricity supply in my man-cave/basement so I can't even go down there > and play with my old computers. :-( Eh, at least the beer will be at cellar temperature.
Re: OT: pints, pounds (Was: APL\360
On 01/02/2021 20:24, Chuck Guzis via cctalk wrote: Thank heavens that the Brits didn't come out with the 5150--we might have had to deal with Whitworth (BSW) fasteners. Nah, too many of them are similar to UNC/UNF, which would have just caused confusion. We'd have used BA sizes. -- Pete Pete Turnbull
Re: OT: pints, pounds (Was: APL\360
On 01/02/2021 20:07, Fred Cisin via cctalk wrote: A US pint of water weighs 1.043 pounds. One "fluid ounce" (volume) of water weighs 1.043 ounces (weight)! That's also a US measure. An imperial fluid ounce is 28.4ml and a floz of water weighs 28.4g, same as an avoirdupois ounce. In fact it's defined (or was) as the volume of water that weighs one ounce. -- Pete Pete Turnbull
Re: OT: pints, pounds (Was: APL\360
On 2/1/21 12:07 PM, Fred Cisin via cctalk wrote: > Instead, it just means that British pubs are not as stingy with their > beer. And, it doesn't need to be chilled to almost frozen to make it > drinkable. No, as I said, it's that Americans (of the US variety) are authentically English, using the 1588 standard, than their overseas cousins, who use the Imperial 1824 one. Simple, that. Importing the IBM PC 5150 into Europe must have caused a bit of a kerfuffle. All of those SAE fasteners--e.g. 6-32 bolt used extensively. #6 bolt size with 32 threads per inch. It wasn't really until the clone makers got into the picture with their metric hardware. The result is that most recent PCs employ a macaronic assortment of fasteners. Thank heavens that the Brits didn't come out with the 5150--we might have had to deal with Whitworth (BSW) fasteners. --Chuck
bit numbering (Was: APL\360
From: Chuck Guzis Numbering of bits in a word is also interesting. Is the high order bit in a 64 bit word, bit 0 or bit 63? Both conventions have been employed. On Mon, 1 Feb 2021, John Ames via cctalk wrote: This one has always boggled me, because it's the one aspect of the Endian Wars where there's a simple, straightforward answer grounded in basic mathematics - base ^ digit-number only gives the correct place-value when the lowest-order bit is numbered zero. It's beyond my ken how anybody thought the reverse was *valid,* let alone a good idea. It probably originated from our system of writing numbers with most significant on the left, least significant on the right. Then combined with somebody not even thinking in terms of "one's place"/"ten's place", or "one's place"/"two's place"/"four's place" etc. and simply numbering from left to right. It is unfortunate that they were permitted to do so.
OT: pints, pounds (Was: APL\360
I had always been told, "A pint is a pound, the world around." On Mon, 1 Feb 2021, Liam Proven via cctalk wrote: Aha! Does that mean a pint of water weighs 1lb? Interesting. I did not know. That is what it MEANS. But, it's not quite right. It's off by about 4%. A US pint of water weighs 1.043 pounds. One "fluid ounce" (volume) of water weighs 1.043 ounces (weight)! How much do you suppose a "pint" of ice cream weighs? And, not all beer has the same specific gravity. Alcohol is less dense than water. And, of course, further variation with temperature and atmospheric pressure. And, if you are in England, "A pint of water weighs a pound and a quarter." Fortunately, that is NOT a difference in the force of gravity! Or, at least MOSTLY not. THAT heavy thought would be difficult to work around. Despite very minor variances in gravity, Earth is MOSTLY HARMLESS. Instead, it just means that British pubs are not as stingy with their beer. And, it doesn't need to be chilled to almost frozen to make it drinkable. I wish that there were a pub open. But, "The Albatross" (pub in Berkeley) has closed down. forever. Can't stay in business with a lockdown. I can get beer delivered! Coincidentally, it is Corona beer! -- Grumpy Ol' Fred
Re: APL\360
> On Feb 1, 2021, at 2:34 PM, Dave Wade G4UGM via cctalk > wrote: > >>> ... >>> I had always been told, "A pint is a pound, the world around." >> >> Aha! Does that mean a pint of water weighs 1lb? >> >> Interesting. I did not know. > > Typical American statement, where "world" means "United States". Its only a > pound in the USA. In the UK it’s 1.25 lbs and even in Canada, before > metrication, it was 20floz same as UK. > In many metric countries the old word for a pound, so in German for example > "pfund" informally refers to 500 grams, a little more than an American pint > and rather less than UK pint... > It gets worse because I understand that in the Caribbean (which as an English > man I pronounce differently to the rest of the world) you will find both size > pint in use That would fit tradition. A lot of the Imperial unit names were at one time also used in the rest of Europe. But their definition varied randomly, often from town to town. I have a book about sailing ships that gives the dimensions in "Amsterdam feet", which by the way have 11 inches per foot, not 12. My father, a metrologist, had a history book discussing the pre-metric systems of units of Europe. The units were often set by the ruler of the day (e.g., the "ell" might match the arm of the prince in charge at that time). Sometimes not, though. The book had a lovely picture showing the way the standard "foot" was estabished in one German principality: officials gathered outside the town church in some town, stopped the first 12 adult males leaving Mass, and had them line up their feet. They captured that measurement, divided by 12, presto, the standard foot. For that place and time, anyway. So don't be surprised that there are lots of pounds, ounces, etc. -- that's just how it's always been done. Much later, there were three different inches: the UK one, the US one, and the Canadian one. At least in theory. In reality they were so close that it's unlikely any instrument could tell the difference. And precision calibration was done with Johansson blocks, which followed the Canadian definition (25.4 mm exactly). paul
Re: APL\360
> On Feb 1, 2021, at 2:13 PM, David Bridgham via cctalk > wrote: > > ... > Sure, one can get into the story that our numbers come from Arabic and > Arabic is written right-to-left so in fact they were originally > little-endian and just didn't get flipped around when incorporated into > left-to-right languages but that's all lost in the past. Today, we > write numbers, in English, big-endian so it's no surprise at all that > some computers followed that common practice. In Hebrew at least, numbers are written left to right. Also, as I understand it, in Arabic our numbers are called "Indian numbers" in recognition of the fact that they originated in India. They came to Europe via Arabia, but that's not their point of origin apparently. paul
RE: APL\360
> -Original Message- > From: cctalk On Behalf Of Liam Proven via > cctalk > Sent: 01 February 2021 19:15 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: APL\360 > > On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk > wrote: > > > > I had always been told, "A pint is a pound, the world around." > > Aha! Does that mean a pint of water weighs 1lb? > > Interesting. I did not know. Typical American statement, where "world" means "United States". Its only a pound in the USA. In the UK it’s 1.25 lbs and even in Canada, before metrication, it was 20floz same as UK. In many metric countries the old word for a pound, so in German for example "pfund" informally refers to 500 grams, a little more than an American pint and rather less than UK pint... It gets worse because I understand that in the Caribbean (which as an English man I pronounce differently to the rest of the world) you will find both size pint in use > > > I had already assumed that pub prices had inflated to higher than a pound. > > It was under £1 for ½litre of beer when I got here. In fact it was under US$1/ > US 1pt. Now it's a bit more. > > Cheapest I had was CzK 17 for half a litre. At the time that was about 50¢. > > > Such worries call for having a few pints. > > It is one of the things I miss most in lockdown. And there's no electricity > supply in my man-cave/basement so I can't even go down there and play > with my old computers. :-( > > > > -- > Liam Proven – Profile: https://about.me/liamproven > Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com > Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven > UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 Dave G4UGM Still stresssed after talking about mail routing at a USA Microsoft Exchange Conference
Re: APL\360
On 2/1/21 1:59 PM, John Ames via cctech wrote: > This one has always boggled me, because it's the one aspect of the > Endian Wars where there's a simple, straightforward answer grounded in > basic mathematics - base ^ digit-number only gives the correct > place-value when the lowest-order bit is numbered zero. It's beyond my > ken how anybody thought the reverse was *valid,* let alone a good > idea. For all that I agree with you that little-endian is clearly the right answer and for exactly the reason you state, it's pretty easy to see where big-endian representation came from. That's how we write numbers in English, we write them big-endian. There ya go, it's as simple as that. Sure, one can get into the story that our numbers come from Arabic and Arabic is written right-to-left so in fact they were originally little-endian and just didn't get flipped around when incorporated into left-to-right languages but that's all lost in the past. Today, we write numbers, in English, big-endian so it's no surprise at all that some computers followed that common practice. Dave
Re: APL\360
> From: Chuck Guzis > Numbering of bits in a word is also interesting. Is the high order bit > in a 64 bit word, bit 0 or bit 63? Both conventions have been employed. This one has always boggled me, because it's the one aspect of the Endian Wars where there's a simple, straightforward answer grounded in basic mathematics - base ^ digit-number only gives the correct place-value when the lowest-order bit is numbered zero. It's beyond my ken how anybody thought the reverse was *valid,* let alone a good idea.
Re: APL\360
On 2/1/21 11:00 AM, Fred Cisin via cctalk wrote: >> On 2021-02-01 10:59, Liam Proven via cctalk wrote: >>> I do not know what a fluid ounce is, or how many are in a pint. > On Mon, 1 Feb 2021, emanuel stiebler via cctalk wrote: >> not enough? >> ;-) > > I had always been told, "A pint is a pound, the world around." > I had already assumed that pub prices had inflated to higher than a pound. Or for that matter, fluid ounces, of which there are 20 UK ounces to a UK pint, but only 16 US ounces to a US pint. It all derives from the 1824 Weights and Measures Act in the UK. By that time, the US had elected to stay with the Elizabethan Exchequer standard (ca. 1588). It might be argued that, as far as measurement goes, the US is more authentically English than the UK. Three barleycorns, dry and round... --Chuck
Re: APL\360
On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk wrote: > > I had always been told, "A pint is a pound, the world around." Aha! Does that mean a pint of water weighs 1lb? Interesting. I did not know. > I had already assumed that pub prices had inflated to higher than a pound. It was under £1 for ½litre of beer when I got here. In fact it was under US$1/ US 1pt. Now it's a bit more. Cheapest I had was CzK 17 for half a litre. At the time that was about 50¢. > Such worries call for having a few pints. It is one of the things I miss most in lockdown. And there's no electricity supply in my man-cave/basement so I can't even go down there and play with my old computers. :-( -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: APL\360
My point was that the metric system is easier because we chose to use a decimal number system. Things like using fractional measurements as in the Imperial system are actually better for designing with. Fractional numbers work better with things like cross sectional areas and strength. Look at typical metric bolt sizes. I agree things like ounces per pound are broken thinking. Giving up fractional dimensions to make it easer to match our decimal number system is also broken. Dwight From: cctalk on behalf of Liam Proven via cctalk Sent: Monday, February 1, 2021 7:59 AM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: APL\360 On Sat, 30 Jan 2021 at 02:56, dwight via cctalk wrote: > I constantly see people claiming how much better decimal is than the English > system of meassurment. Um. I am a native English speaker, as well as an English citizen, and I count in decimal. Do you mean metric (SI / Systeme Internationale) versus Imperial measurements? If so, I 100% aver that metric is far better. I am 53 years old. I did not learn Imperial at school, in any of the 3 countries where I went to school (UK, Nigeria, Isle of Man.) I know some of the units; I think of a few things, such as human beings, computer screens, and pizzas, in Imperial units. People's height in feet & inches is more meaningful to me than in metres, but I can cope. People's weight in stones. Beer in pints. Speeds in MPH. But that's about all. I have never managed to learn how many ounces in a pound, or pounds in an stone, or stones in a hundredweight. I do not know what a fluid ounce is, or how many are in a pint. I do not know how many yards in a mile. They're all arbitrary numbers and it makes no sense. SI units are 100% easier by any metric. Yes, that is intentional. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: APL\360
On 2021-02-01 10:59, Liam Proven via cctalk wrote: I do not know what a fluid ounce is, or how many are in a pint. On Mon, 1 Feb 2021, emanuel stiebler via cctalk wrote: not enough? ;-) I had always been told, "A pint is a pound, the world around." I had already assumed that pub prices had inflated to higher than a pound. And more recently, through tangents on this list, I realized that a pint wasn't even the same size, the world around. Such worries call for having a few pints.
Re: APL\360
We don't need another big-endian/little-endian battle On Mon, 1 Feb 2021, Peter Corlett via cctalk wrote: Little-endian tends to be more useful when doing multi-word arithmetic. Big-endian is handy for text and human-readable numbers. That there are heated arguments over which endianness is best mainly tells us that there's bugger all in it either way. After all, the word "endian" is a satirical device in Gulliver's Travels. But, since computers weren't common among his readers in 1726, they wouldn't have understood the competing computer architectures of Lilliput and Blefescu, so he had to rewrite the issue in terms of opening eggs. https://www.ling.upenn.edu/courses/Spring_2003/ling538/Lecnotes/ADfn1.htm
Re: APL\360
On Sat, 30 Jan 2021 at 03:27, dwight via cctalk wrote: If we'd thought about it we could count to 1023 on our fingers. On Mon, 1 Feb 2021, Tor Arntsen via cctalk wrote: Some sheep herders in (IIRC) the Caucasus do, or did at least. I learned about that some decades ago. Counting sheep on their fingers. I use the system sometimes. counting sheep, . . . My ex asked me whether I was playing piano in my sleep.
Re: APL\360
On 2021-02-01 11:40, Chuck Guzis via cctalk wrote: > Whose pint? UK Imperial pint = 568 ml. US liquid pint = 473 ml. That explains some conversations I had with people there ;-)
Re: APL\360
On 2/1/21 5:26 AM, Peter Corlett via cctalk wrote: > On every CPU I've used, LSB has always been bit 0. Unlike endianness, this > is clearly better than the other way round since the value is 2**bit_number > and the bit number doesn't change if the value is converted into a different > word width. I take it then, that you've never programmed a S/360 CPU? --Chuck
Re: APL\360
It's actually 568.26. Easy to work out, in Canada the gallon is defined as being 454609 ten millionths of a cubic metre, Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.john...@ieee.org On 2021-02-01 11:40 a.m., Chuck Guzis via cctalk wrote: > On 2/1/21 8:10 AM, emanuel stiebler via cctalk wrote: >> On 2021-02-01 10:59, Liam Proven via cctalk wrote: >>> I do not know what a fluid ounce is, or how many are in a pint. >> not enough? >> ;-) >> > Whose pint? UK Imperial pint = 568 ml. US liquid pint = 473 ml. > > Both are one-eighth of a gallon, but US and UK gallons differ. > > Trivia for today. > > --Chuck
Re: APL\360
On 2/1/21 8:10 AM, emanuel stiebler via cctalk wrote: > On 2021-02-01 10:59, Liam Proven via cctalk wrote: >> I do not know what a fluid ounce is, or how many are in a pint. > > not enough? > ;-) > Whose pint? UK Imperial pint = 568 ml. US liquid pint = 473 ml. Both are one-eighth of a gallon, but US and UK gallons differ. Trivia for today. --Chuck
Re: APL\360
On 2021-02-01 10:59, Liam Proven via cctalk wrote: > I do not know what a fluid ounce is, or how many are in a pint. not enough? ;-)
Re: APL\360
On Sat, 30 Jan 2021 at 02:56, dwight via cctalk wrote: > I constantly see people claiming how much better decimal is than the English > system of meassurment. Um. I am a native English speaker, as well as an English citizen, and I count in decimal. Do you mean metric (SI / Systeme Internationale) versus Imperial measurements? If so, I 100% aver that metric is far better. I am 53 years old. I did not learn Imperial at school, in any of the 3 countries where I went to school (UK, Nigeria, Isle of Man.) I know some of the units; I think of a few things, such as human beings, computer screens, and pizzas, in Imperial units. People's height in feet & inches is more meaningful to me than in metres, but I can cope. People's weight in stones. Beer in pints. Speeds in MPH. But that's about all. I have never managed to learn how many ounces in a pound, or pounds in an stone, or stones in a hundredweight. I do not know what a fluid ounce is, or how many are in a pint. I do not know how many yards in a mile. They're all arbitrary numbers and it makes no sense. SI units are 100% easier by any metric. Yes, that is intentional. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: APL\360
On Fri, 29 Jan 2021 at 22:14, Fred Cisin via cctalk wrote: > such as 42 > WHATDOYOUGETWHENYOUMULTIPLYSIXBYNINE -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: APL\360
On Fri, Jan 29, 2021 at 01:12:55PM -0800, Chuck Guzis via cctalk wrote: [...] > Most old (pre S/360) digit/character-addressable architectures were > big-endian (i.e. higher-order characters occupied lower addresses) > Even PDP-11 isn't strictly little-endian, though Intel X86 definitely is. I note that modern x86 and ARM have big-endian load and store operations, so while both architectures are little-endian by default, there is no extra overhead for handling big-endian data. Little-endian tends to be more useful when doing multi-word arithmetic. Big-endian is handy for text and human-readable numbers. That there are heated arguments over which endianness is best mainly tells us that there's bugger all in it either way. After all, the word "endian" is a satirical device in Gulliver's Travels. > Numbering of bits in a word is also interesting. Is the high order bit in > a 64 bit word, bit 0 or bit 63? Both conventions have been employed. On every CPU I've used, LSB has always been bit 0. Unlike endianness, this is clearly better than the other way round since the value is 2**bit_number and the bit number doesn't change if the value is converted into a different word width. When it comes to I/O devices which don't do arithmetic, either convention may appear. Hardware people rarely pick names or conventions that make sense to software people.
Re: APL\360
On Mon, 1 Feb 2021 at 10:34, Tor Arntsen via cctalk wrote: > > Some sheep herders in (IIRC) the Caucasus do, or did at least. I > learned about that some decades ago. Counting sheep on their fingers. > I use the system sometimes. Fred Pohl's short story "Digits and Dastards" explains it well. I used to use it at my fencing club. Matches are normally first to 15 points -- first to 10 if we were busy. I'd keep score on my fingers in binary, left for one player, right for the other.. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: APL\360
On Wed, Jan 20, 2021 at 02:05:37PM -0700, ben via cctalk wrote:
[...]
> I don't see languages in general have improved since the the mid
> 1960's. Hardware and language models don't reflect each other,
> and don't have extendable data sizes and types.
> PL/I seems to have been the best,but too tied to IBM.
> C standard 2131 complex numbers
> C standard 2143 dubble complex numbers
> Every machine I can think of had a carry flag of some type
> yet no language uses that to extend it self.
You're describing a failing in C and similar languages stuck in the 1960s.
Here's a Rust method that does add-exposing-carry:
https://doc.rust-lang.org/nightly/std/primitive.u32.html#method.overflowing_add
The documentation doesn't explicitly say "carry" because Rust is
architecture-neutral and it's down to LLVM to decide how to express it in
machine code, but on x86 (and probably ARM) the boolean return value comes
directly from the carry flag.
> I don't believe in objects because data structures don't have classes, but
> are more similar to each other. A window A structure is like window B but
> details are different. That makes things look portable when they are not.
> Constants still
> seem to be embedded in data structures, rather than abstract.
> -- zero array
> define LIMIT abc
> blah array[LIMIT]
> ...
> i = 0 while i< LIMIT array[i] = 0 i = i + 1 endw
> I would like say
> let LIMIT = abc
> blah array[LIMIT]
> i = 0 while i< array:LIMIT array[i] = 0 i = i + 1 endw
You "don't believe in objects" yet then describe a problem which only exists
due to the lack of them and then present OO pseudocode to solve it. A lot of
OO languages suck of course, but the fundamental idea of encapsulation is
not the bit that sucks. Here's it in Rust, where it takes in an arbitrary
array (pedantically, "slice", a (pointer, element count)-tuple) and
determines its length at runtime:
pub fn clear_indexed(array: [usize]) {
for index in 0 .. array.len() {
array[index] = 0;
}
}
(The code for C-style fixed-length arrays looks broadly similar but has a
bit more boilerplate because they're less useful.)
Iterating over indices is generally discouraged for a number of reasons, not
least being that the index may be out-of-bounds, but also because it can
inhibit vectorisation or parallelisation. You have no choice in broken
languages such as C, but many languages provide some notion of iteration
which guarantees to not go out-of-bounds:
pub fn clear_iterator(array: [usize]) {
for elem in array {
*elem = 0;
}
}
Both code fragments generate equivalent assembly in this trivial example
because the Rust compiler could prove at compile time that the index
variable can't go out-of-bounds. In more complex real-world code it cannot
reliably do so and will insert a run-time check which aborts if the index is
out-of-bounds. Or if it's C, trundle on and corrupt things.
Oddly enough, the state of the art has moved on a bit in the half-century
since C was invented. It's just that quite a lot of programmers haven't yet
noticed.
Re: APL\360
On Sat, 30 Jan 2021 at 03:27, dwight via cctalk wrote: > If we'd thought about it we could count to 1023 on our fingers. > Dwight Some sheep herders in (IIRC) the Caucasus do, or did at least. I learned about that some decades ago. Counting sheep on their fingers. I use the system sometimes. -Tor
Re: APL\360
It was thus said that the Great Bill Gunshannon via cctalk once stated: > On 1/29/21 4:12 PM, Will Cooke via cctalk wrote: > > > >>On 01/29/2021 2:58 PM Fred Cisin via cctalk wrote: > >> > > > >>'=' and '==' makes possible what is probably the most common error, and > >>which the compiler doesn't catch: > >>if (x = 3) . . . /* sets x to 3 and gives TRUE for the condition */ > >>I imagine that there are probably some pre-processors that would return a > >>WARNING for it. > >> > > > >Modern Visual Studio and GCC both flag the "=" in a condition, I believe. > >But if you're shipping code with 260+ warnings, who would see one more. > > And the problem here is really quite plain and simple. > Why are you shipping code with any warnings? Because sometimes they aren't. Example: gcc -std=c99 -g -Wall -Wextra -pedantic -fPIC -g -shared -o lib/tcc.so src/tcc.c -ltcc src/tcc.c: In function cclua_get_symbol': src/tcc.c:528: warning: ISO C forbids assignment between function pointer and `void *' ISO C may forbid that, but POSIX requires it, and I'm compiling on a POSIX system, but there isn't (to my knowledge) a way to state that. Yes, I could probably surpresss that one warning, but for me, it's easier to ignore on POSIX systems. Also, have you tried clang with the highest warning level? It's useless. I tried it once, only to be told "warning: struct foo has padding bytes added" (or something to that effect). Okay, so I pack the structure, only to get "Warning: struct foo doesn't have any padding". Yean, real useful that. -spc
Re: APL\360
On 1/30/21 1:57 PM, Nemo Nusquam via cctalk wrote: On 30/01/2021 12:45, Bill Gunshannon via cctalk wrote: On 1/29/21 4:25 PM, Nemo Nusquam via cctalk wrote: On 01/29/21 15:58, Fred Cisin via cctalk wrote (in part): '=' and '==' makes possible what is probably the most common error, and which the compiler doesn't catch: if (x = 3) . . .  /* sets x to 3 and gives TRUE for the condition */ I imagine that there are probably some pre-processors that would return a WARNING for it. Henry's first commandment: Thou shalt run lint frequently and study its pronouncements with care, for verily its perception and judgement oft exceed thine. N. Which Henry was that? Henry Spencer perhaps? Yes, Henry Spencer (formerly of zoo.toronto.edu). N. Another blast from the past. I haven't seen anything of or spoken with him in nearly 30 years. bill
Re: APL\360 (Was: cctalk Digest, Vol 76, Issue 29
On 1/30/21 1:38 PM, Fred Cisin via cctalk wrote: > Actually, that was Chuck who said that "there be monsters" when > languages use whitespace rather than punctuation to denote boundaries. And then there's "make", where a hard tab must be used for indentation, unless it's a recipe, then spaces must be used for indentation. One of those cases where one asks "Who wrote this (*&@#?"? --Chuck
APL\360 (Was: cctalk Digest, Vol 76, Issue 29
Actually, that was Chuck who said that "there be monsters" when languages
use whitespace rather than punctuation to denote boundaries.
I use both indentation for my readability AND brackets to be explicit.
Consider:
if condition
{ do this;
do that;
}
VS:
if (condition)
do this;
do that; /* will be done disunirregardless of condition */
On Sat, 30 Jan 2021, Mark Moulding via cctalk wrote:
On 1/29/21 12:58 PM, Fred Cisin via cctalk wrote:
I like indentation, and demanded it from my students.
That's fine, but when you have a language that makes indentation part of
the language (i.e. no braces, brackets or keywords denoting boundaries
of the block) , there be monsters.
And yes, there are such languages.
Uh - Python comes to mind...
~~
Mark Moulding
Re: APL\360
On 1/30/21 9:52 AM, Chuck Guzis via cctalk wrote: On 1/29/21 10:03 PM, Guy Sotomayor via cctalk wrote: And unfortunately some industries it is prohibited. Those industries *require* conformance to MISRA, CERT-C, ISO-26262 and others. There is *no* choice since the code has to be audited and compliance is *not* optional. Just an illustration of what happens when you take a "portable alternative to assembly" and put lipstick on it. I've been programming C since System III Unix and I still consider it to be a portable (sort of) alternative to assembly. One of the problems with C, in my view, is a lack of direction. There are plenty of languages that aim for specific ends. (e.g. COBOL = business/commercial, FORTRAN = scientific, Java = web applications, etc.). But whence C or C++? In my dotage, I do a fair amount of MCU programming nowadays, and C is the lingua franca in that world; the only real alternative is assembly, so that makes some sense. Python, Ada, etc. never really managed to make much headway there. C is far more prevalent than C++ in that world, FWIW. Does standard C have vector extensions yet? I was an alternate rep for my firm for F90 (was supposed to be F88) for vector extensions; it's just a matter of curiosity. I've been writing in C since 1977 (Unix V6 days and went through the =+ to += conversion in V7). I've seen *a lot* of changes in C over that time. Most of what I do is low level stuff (OS, RTOS, etc) and actually *rarely* even use the C library (most of what I build is built with -nostdlibs). I typically build using -c99 but I'm looking at C11 because of atomics that were introduced then but I have to see what's native compiler generated versus what it relies on for the atomic operations. I haven't yet seen what's in C17 yet. I've also been known to write a special hand crafted function so that an entire portion of the C library doesn't get pulled in. Not only did it save a bunch of space but it was *much* faster too. TTFN - Guy
Re: APL\360
On 30/01/2021 12:45, Bill Gunshannon via cctalk wrote: On 1/29/21 4:25 PM, Nemo Nusquam via cctalk wrote: On 01/29/21 15:58, Fred Cisin via cctalk wrote (in part): '=' and '==' makes possible what is probably the most common error, and which the compiler doesn't catch: if (x = 3) . . .  /* sets x to 3 and gives TRUE for the condition */ I imagine that there are probably some pre-processors that would return a WARNING for it. Henry's first commandment: Thou shalt run lint frequently and study its pronouncements with care, for verily its perception and judgement oft exceed thine. N. Which Henry was that? Henry Spencer perhaps? Yes, Henry Spencer (formerly of zoo.toronto.edu). N.
Re: APL\360
> On 01/30/2021 11:50 AM Bill Gunshannon via cctalk > wrote: > > > On 1/29/21 6:08 PM, Sean Conner via cctalk wrote: > > It was thus said that the Great Will Cooke via cctalk once stated: > > > > >>> On 01/29/2021 4:42 PM David Barto via cctalk > >>> wrote: > >> > >>> Whenever I start a new job the first thing I do today is enable -Werror; > >>> all warnings are errors. And I’ll fix every one. Even when everyone > >>> claims that “These are not a problem”. Before that existed, I’d do the > >>> same with lint, and FlexeLint when I could get it. > >> > >> That's exactly what I did. I was promptly told I was likely to get fired > >> for it. > > WHY? Why would you get fired for fixing warnings? Would it make some > > manager upstream look bad or something? > They would see you as wasting valuable time fixing non-problems. > I would not work in a place like that. Worse sti8ll is when you > work in a place point out logic errors that result in bad answers > that, obviously, don't get flagged by the compiler and nobody wants > to hear it. > > bill That happened too, with similar results. "Don't touch it. You might 'break' it." "It's already broken." "But it 'works'" That code is running maybe 25% of all mid-sized commercial heat pumps in use today. "A person who never made a mistake never tried anything new." -- Albert Einstein
Re: APL\360
On 1/29/21 9:19 PM, Chuck Guzis via cctalk wrote: On 1/29/21 5:55 PM, dwight via cctalk wrote: My problem with words such as DAA is that I constantly have to look them up to see exactly what they actually do. Finding alternate uses it all about knowing what they actually do. I know what they were put there for ( to keep banker happy ). I constantly see people claiming how much better decimal is than the English system of meassurment. I don't really think that much of the decimal number system. If we'd only been born with 8 fingers on each hand, computers would have been so much easier. Thing like powers of 2 are easier to understand in binary. Such is life. If only we'd known. Dwight Such as 24 hours in a day, 60 minutes in an hour, and 50 seconds in a minute? Although decimal time has been proposed numerous times, somehow we can't shake our Babylonian roots, even if we don't have 60 fingers. And what's with these 12 months of different lengths? :-) bill
Re: APL\360
On 1/29/21 10:03 PM, Guy Sotomayor via cctalk wrote: > > And unfortunately some industries it is prohibited. Those industries > *require* conformance to MISRA, CERT-C, ISO-26262 and others. There is > *no* choice since the code has to be audited and compliance is *not* > optional. Just an illustration of what happens when you take a "portable alternative to assembly" and put lipstick on it. I've been programming C since System III Unix and I still consider it to be a portable (sort of) alternative to assembly. One of the problems with C, in my view, is a lack of direction. There are plenty of languages that aim for specific ends. (e.g. COBOL = business/commercial, FORTRAN = scientific, Java = web applications, etc.). But whence C or C++? In my dotage, I do a fair amount of MCU programming nowadays, and C is the lingua franca in that world; the only real alternative is assembly, so that makes some sense. Python, Ada, etc. never really managed to make much headway there. C is far more prevalent than C++ in that world, FWIW. Does standard C have vector extensions yet? I was an alternate rep for my firm for F90 (was supposed to be F88) for vector extensions; it's just a matter of curiosity. --Chuck
Re: APL\360
On 1/29/21 6:08 PM, Sean Conner via cctalk wrote: It was thus said that the Great Will Cooke via cctalk once stated: On 01/29/2021 4:42 PM David Barto via cctalk wrote: Whenever I start a new job the first thing I do today is enable -Werror; all warnings are errors. And I’ll fix every one. Even when everyone claims that “These are not a problem”. Before that existed, I’d do the same with lint, and FlexeLint when I could get it. That's exactly what I did. I was promptly told I was likely to get fired for it. WHY? Why would you get fired for fixing warnings? Would it make some manager upstream look bad or something? They would see you as wasting valuable time fixing non-problems. I would not work in a place like that. Worse sti8ll is when you work in a place point out logic errors that result in bad answers that, obviously, don't get flagged by the compiler and nobody wants to hear it. bill
Re: APL\360
> On 01/30/2021 11:42 AM Bill Gunshannon via cctalk > wrote: > > Modern Visual Studio and GCC both flag the "=" in a condition, I believe. > > But if you're shipping code with 260+ warnings, who would see one more. > And the problem here is really quite plain and simple. > Why are you shipping code with any warnings? > The short answer, as I replied earlier, is that they deemed the code too fragile to touch. When I told them I removed the warnings they said to put them back or I would likely be fired. > > There's a pretty good chance the heat pump you're using right now has those > > warnings. Alas... > Just because some other programmer is an idiot doesn't mean I have > to be. They only wanted idiots. So I immediately started looking for another job. I might be an idiot, but I don't want to be associated with the rest of them :-) Will "A person who never made a mistake never tried anything new." -- Albert Einstein
Re: APL\360
On 1/29/21 4:25 PM, Nemo Nusquam via cctalk wrote: On 01/29/21 15:58, Fred Cisin via cctalk wrote (in part): '=' and '==' makes possible what is probably the most common error, and which the compiler doesn't catch: if (x = 3) . . . /* sets x to 3 and gives TRUE for the condition */ I imagine that there are probably some pre-processors that would return a WARNING for it. Henry's first commandment: Thou shalt run lint frequently and study its pronouncements with care, for verily its perception and judgement oft exceed thine. N. Which Henry was that? Henry Spencer perhaps? bill
Re: APL\360
On 1/29/21 4:12 PM, Will Cooke via cctalk wrote: On 01/29/2021 2:58 PM Fred Cisin via cctalk wrote: '=' and '==' makes possible what is probably the most common error, and which the compiler doesn't catch: if (x = 3) . . . /* sets x to 3 and gives TRUE for the condition */ I imagine that there are probably some pre-processors that would return a WARNING for it. Modern Visual Studio and GCC both flag the "=" in a condition, I believe. But if you're shipping code with 260+ warnings, who would see one more. And the problem here is really quite plain and simple. Why are you shipping code with any warnings? There's a pretty good chance the heat pump you're using right now has those warnings. Alas... Just because some other programmer is an idiot doesn't mean I have to be. bill
Re: APL\360
On 1/29/21 2:20 PM, Fred Cisin via cctalk wrote: On Fri, 29 Jan 2021, Paul Koning via cctalk wrote: BTW, I don't really know Hebrew but doesn't it still write math LTR? I know they write numbers that way. CAREFUL. We don't need another BIG-endian/little-endian debate! (when a 16 bit number is stored in bytes, does the high order byte come first, or the low order byte?) (cf. intel V Motorola) Yes, it does. :-) bill
Re: APL\360
> On Jan 29, 2021, at 8:27 PM, dwight via cctalk wrote: > > [EXTERNAL EMAIL] > > If we'd thought about it we could count to 1023 on our fingers. > Dwight My kids actually do that (because I did think about it when they were growing up). And not just to impress me, I was watching the elder daughter in an orchestra concert via streaming cam one time. The camera happened to catch her during a really long rest, and I could see her hand resting on her knee, counting out measures in binary. As far as I know, none of the kids have learned to control their toes individually, so they can’t actually count up to 1,048,575 :-). - Mark
Re: APL\360
I was responsible for the Macintosh version and hence was both permitted to address the changes and criticized for impacting the Windows builds - the changes were in shared code. I would probably face legal issues if I named names. [You can always look me up in LinkedIn and, with minor detective skills, guess which product...] From: "cctalk" To: "cctalk" Sent: Friday, January 29, 2021 6:57:28 PM Subject: Re: APL\360 It was thus said that the Great Norman Jaffe via cctalk once stated: > > It happened to me as well - I found hundreds of warnings in the code and, > after getting permission to address them, I was fired Wait ... you got *permission* and were still *fired*? Have I just been fortunate in where I've worked my entire career? [1] > because 'we would > have to recompile the Windows version due to the changes you made'; the > source code was reverted to the state before I made the changes. Wouldn't you have to recompile the Windows version for updates? Or was the company too cheap (or was unable to) run regression tests? > I refuse > to have their product on any system that I have involvement with... Can you name names? Or do you need to protect yourself? -spc [1] Possibly yes.
Re: APL\360
On 1/29/21 4:32 PM, Fred Cisin via cctalk wrote: if ( !(myfile = fopen( filename, "r")) On Fri, 29 Jan 2021, Guy Sotomayor via cctalk wrote: In a lot of industry standard coding practices (MISRA, CERT-C) that type of statement is prohibited and *will* result in an error being reported by the checker/scanner. The if statement in your example has at least 2 errors from MISRA's perspective: * assignment within a conditional statement * the conditional not being a boolean type (that is you can't assume 0 is false and non-0 is true...you actually need to compare...in this case against NULL) That particular structure has become an industry standard. MOST dialects of C return a NULL pointer on fopen error. Similarly the code in strcpy has an assignment and is using the numeric valus of each character as if it were boolean, with the terminating NULL ending the while condition. And unfortunately some industries it is prohibited. Those industries *require* conformance to MISRA, CERT-C, ISO-26262 and others. There is *no* choice since the code has to be audited and compliance is *not* optional. -- TTFN - Guy
Re: APL\360
It was thus said that the Great Norman Jaffe via cctalk once stated: > > It happened to me as well - I found hundreds of warnings in the code and, > after getting permission to address them, I was fired Wait ... you got *permission* and were still *fired*? Have I just been fortunate in where I've worked my entire career? [1] > because 'we would > have to recompile the Windows version due to the changes you made'; the > source code was reverted to the state before I made the changes. Wouldn't you have to recompile the Windows version for updates? Or was the company too cheap (or was unable to) run regression tests? > I refuse > to have their product on any system that I have involvement with... Can you name names? Or do you need to protect yourself? -spc [1] Possibly yes.
Re: APL\360
It was thus said that the Great Fred Cisin via cctalk once stated: > >Whenever I start a new job the first thing I do today is enable > >-Werror; all warnings are errors. And I’ll fix every one. Even > >when everyone claims that “These are not a problem”. Before > >that existed, I’d do the same with lint, and FlexeLint when I > >could get it. > > On Fri, 29 Jan 2021, wrco...@wrcooke.net wrote: > >That's exactly what I did and was then told I was likely to get fired for > >it. I left that job soon after. > >"A person who never made a mistake never tried anything new." -- Albert > >Einstein > > > Similarly, "You don't have time to write comments as you go along. You > can go back and add them in AFTER the program is working." Of course, as > soon as it "seems to be working", "We're not paying you to mess with stuff > that's already DONE. We have ANOTHER project that you have to get on > immediately." > > It's not good to be in a job where they won't let you be thorough in error > checking nor let you write comments. I had a manager that told me not to be so pedantic about verifying the incoming SIP messages because otherwise we (the Company) were going to go out of business in six months if we didn't get the product OUT THE DOOR! I compromised on it---I didn't remove the checks, but for those that didn't matter to our processing the message, I just logged the violation and continued processing. No one in the department was familiar with SIP at the time so I figured tha was at least help us debug any issues. Of course, said manager left six months later because of burnout [1], and two, I'm still at the same job five years later. -spc [1] He was originally a developer who was forced into a management role, something he was *very bad at*, and he still did development work, not fully trusting anyone underneath him (nor operations, but that's a whole other story).
Re: APL\360
> On 01/29/2021 7:55 PM dwight via cctalk wrote: > > > I constantly see people claiming how much better decimal is than the English > system of meassurment. I don't really think that much of the decimal number > system. If we'd only been born with 8 fingers on each hand, computers would > have been so much easier. Thing like powers of 2 are easier to understand in > binary. > Such is life. If only we'd known. > Dwight > Some knew https://en.wikipedia.org/wiki/Octal#Usage
Re: APL\360
On Sat, 30 Jan 2021, dwight via cctalk wrote: If we'd thought about it we could count to 1023 on our fingers. If the more dominant/aggressive of our ancestors had come from warmer climates where feet don't stink too much to expose in public, then we could have had 20 binary digits.
Re: APL\360
On 1/29/21 4:13 PM, Guy Sotomayor via cctalk wrote: > In a lot of industry standard coding practices (MISRA, CERT-C) that type > of statement is prohibited and *will* result in an error being reported > by the checker/scanner. > > The if statement in your example has at least 2 errors from MISRA's > perspective: > > * assignment within a conditional statement > * the conditional not being a boolean type (that is you can't assume 0 > is false and non-0 is true...you actually need to compare...in this > case against NULL) Or zero; but then many current C (not C++) implementations do not define an intrinsic boolean type. When writing using gcc, for example, I have to #include So, that leaves us with the value of NULL: 3.2.2.3 Pointers An integral constant expression with the value 0, or such an expression cast to type void * , is called a null pointer constant. If a null pointer constant is assigned to or compared for equality to a pointer, the constant is converted to a pointer of that type. Such a pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. --Chuck
Re: APL\360
If we'd thought about it we could count to 1023 on our fingers. Dwight From: cctalk on behalf of Chuck Guzis via cctalk Sent: Friday, January 29, 2021 6:19 PM To: dwight via cctalk Subject: Re: APL\360 On 1/29/21 5:55 PM, dwight via cctalk wrote: > My problem with words such as DAA is that I constantly have to look them up > to see exactly what they actually do. Finding alternate uses it all about > knowing what they actually do. I know what they were put there for ( to keep > banker happy ). > I constantly see people claiming how much better decimal is than the English > system of meassurment. I don't really think that much of the decimal number > system. If we'd only been born with 8 fingers on each hand, computers would > have been so much easier. Thing like powers of 2 are easier to understand in > binary. > Such is life. If only we'd known. > Dwight Such as 24 hours in a day, 60 minutes in an hour, and 50 seconds in a minute? Although decimal time has been proposed numerous times, somehow we can't shake our Babylonian roots, even if we don't have 60 fingers. --Chuck
Re: APL\360
On 1/29/21 5:55 PM, dwight via cctalk wrote: > My problem with words such as DAA is that I constantly have to look them up > to see exactly what they actually do. Finding alternate uses it all about > knowing what they actually do. I know what they were put there for ( to keep > banker happy ). > I constantly see people claiming how much better decimal is than the English > system of meassurment. I don't really think that much of the decimal number > system. If we'd only been born with 8 fingers on each hand, computers would > have been so much easier. Thing like powers of 2 are easier to understand in > binary. > Such is life. If only we'd known. > Dwight Such as 24 hours in a day, 60 minutes in an hour, and 50 seconds in a minute? Although decimal time has been proposed numerous times, somehow we can't shake our Babylonian roots, even if we don't have 60 fingers. --Chuck
Re: APL\360
My problem with words such as DAA is that I constantly have to look them up to see exactly what they actually do. Finding alternate uses it all about knowing what they actually do. I know what they were put there for ( to keep banker happy ). I constantly see people claiming how much better decimal is than the English system of meassurment. I don't really think that much of the decimal number system. If we'd only been born with 8 fingers on each hand, computers would have been so much easier. Thing like powers of 2 are easier to understand in binary. Such is life. If only we'd known. Dwight From: cctalk on behalf of Fred Cisin via cctalk Sent: Friday, January 29, 2021 4:32 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: APL\360 >>> if ( !(myfile = fopen( filename, "r")) On Fri, 29 Jan 2021, Guy Sotomayor via cctalk wrote: > In a lot of industry standard coding practices (MISRA, CERT-C) that type of > statement is prohibited and *will* result in an error being reported by the > checker/scanner. > The if statement in your example has at least 2 errors from MISRA's > perspective: > * assignment within a conditional statement > * the conditional not being a boolean type (that is you can't assume 0 > is false and non-0 is true...you actually need to compare...in this > case against NULL) That particular structure has become an industry standard. MOST dialects of C return a NULL pointer on fopen error. Similarly the code in strcpy has an assignment and is using the numeric valus of each character as if it were boolean, with the terminating NULL ending the while condition. There are some situations where some code might not be obvious to all, in which case good comments provide the explanation. For example, when I use DAA or AAM, etc. in X86 assembly language, I always comment heavily since my uses for breaking up and/or printing numbers are not the original intent for those instructions.
Re: APL\360
if ( !(myfile = fopen( filename, "r")) On Fri, 29 Jan 2021, Guy Sotomayor via cctalk wrote: In a lot of industry standard coding practices (MISRA, CERT-C) that type of statement is prohibited and *will* result in an error being reported by the checker/scanner. The if statement in your example has at least 2 errors from MISRA's perspective: * assignment within a conditional statement * the conditional not being a boolean type (that is you can't assume 0 is false and non-0 is true...you actually need to compare...in this case against NULL) That particular structure has become an industry standard. MOST dialects of C return a NULL pointer on fopen error. Similarly the code in strcpy has an assignment and is using the numeric valus of each character as if it were boolean, with the terminating NULL ending the while condition. There are some situations where some code might not be obvious to all, in which case good comments provide the explanation. For example, when I use DAA or AAM, etc. in X86 assembly language, I always comment heavily since my uses for breaking up and/or printing numbers are not the original intent for those instructions.
Re: APL\360
On 30/01/2021 00:13, Guy Sotomayor via cctalk wrote:
In a lot of industry standard coding practices (MISRA, CERT-C) that
type of statement is prohibited and *will* result in an error being
reported by the checker/scanner.
The if statement in your example has at least 2 errors from MISRA's
perspective:
* assignment within a conditional statement
* the conditional not being a boolean type (that is you can't assume 0
is false and non-0 is true...you actually need to compare...in this
case against NULL)
On 1/29/21 3:59 PM, Fred Cisin via cctalk wrote:
On Fri, 29 Jan 2021, Chuck Guzis via cctalk wrote:
In the past (and occasionally today, I use the following construct:
FILE *myfile;
if ( !(myfile = fopen( filename, "r"))
{
fprintf( stderr, "Couldn\'t open %s - exiting\n", filename);
exit (1);
}
Yes, it only saves a line, but neatly describes what's being done.
--Chuck
Yes.
That is another excellent example of where you DO want to do an
assignment AND a comparison (to zero). A better example than my
strcpy one, although yours does not need to save that extra line, but
a string copy can't afford to be slowed down even a little.
That is why it MUST be a WARNING, not an ERROR.
Of course, the error is when that wasn't what you intended to do.
I'm pretty sure that while modern compilers will correctly complain
about an assignment in a conditional, they also recognise the idiom and
don't warn when the extra set of brackets is present. So when you really
do want an assignment and a conditional all in one go, you use the extra
set of brackets and everyone (you, the compiler, future you) know that
you really meant it.
Antonio
--
Antonio Carlini
anto...@acarlini.com
Re: APL\360
In a lot of industry standard coding practices (MISRA, CERT-C) that type
of statement is prohibited and *will* result in an error being reported
by the checker/scanner.
The if statement in your example has at least 2 errors from MISRA's
perspective:
* assignment within a conditional statement
* the conditional not being a boolean type (that is you can't assume 0
is false and non-0 is true...you actually need to compare...in this
case against NULL)
On 1/29/21 3:59 PM, Fred Cisin via cctalk wrote:
On Fri, 29 Jan 2021, Chuck Guzis via cctalk wrote:
In the past (and occasionally today, I use the following construct:
FILE *myfile;
if ( !(myfile = fopen( filename, "r"))
{
fprintf( stderr, "Couldn\'t open %s - exiting\n", filename);
exit (1);
}
Yes, it only saves a line, but neatly describes what's being done.
--Chuck
Yes.
That is another excellent example of where you DO want to do an
assignment AND a comparison (to zero). A better example than my
strcpy one, although yours does not need to save that extra line, but
a string copy can't afford to be slowed down even a little.
That is why it MUST be a WARNING, not an ERROR.
Of course, the error is when that wasn't what you intended to do.
--
TTFN - Guy
Re: APL\360
On Fri, 29 Jan 2021, Chuck Guzis via cctalk wrote:
In the past (and occasionally today, I use the following construct:
FILE *myfile;
if ( !(myfile = fopen( filename, "r"))
{
fprintf( stderr, "Couldn\'t open %s - exiting\n", filename);
exit (1);
}
Yes, it only saves a line, but neatly describes what's being done.
--Chuck
Yes.
That is another excellent example of where you DO want to do an assignment
AND a comparison (to zero). A better example than my strcpy one, although
yours does not need to save that extra line, but a string copy can't
afford to be slowed down even a little.
That is why it MUST be a WARNING, not an ERROR.
Of course, the error is when that wasn't what you intended to do.
Re: APL\360
In the past (and occasionally today, I use the following construct:
FILE *myfile;
if ( !(myfile = fopen( filename, "r"))
{
fprintf( stderr, "Couldn\'t open %s - exiting\n", filename);
exit (1);
}
Yes, it only saves a line, but neatly describes what's being done.
--Chuck
Re: APL\360
Whenever I start a new job the first thing I do today is enable -Werror; all warnings are errors. And I’ll fix every one. Even when everyone claims that “These are not a problem”. Before that existed, I’d do the same with lint, and FlexeLint when I could get it. On Fri, 29 Jan 2021, wrco...@wrcooke.net wrote: That's exactly what I did and was then told I was likely to get fired for it. I left that job soon after. "A person who never made a mistake never tried anything new." -- Albert Einstein Similarly, "You don't have time to write comments as you go along. You can go back and add them in AFTER the program is working." Of course, as soon as it "seems to be working", "We're not paying you to mess with stuff that's already DONE. We have ANOTHER project that you have to get on immediately." It's not good to be in a job where they won't let you be thorough in error checking nor let you write comments. And, of course, "Don't waste space with more than two decimal digits for year. NOTHING that we are doing now will still be in use 30 years from now." One of the tasks that I was assigned (working for a contractor at GSFC) was to work on converting a wall of punch-card subroutines for plotting on Calcomp plotters that needed to be changed to work on Stromberg-Carlson (later Stromberg Datagraphics). It was budgeted for a LONG project to rewrite all of them. I realized that all of the subroutines for Calcomp called lower and lower level routines, on down to a small number of primitives. It was easy to write primitives for those lowest level ones, that worked on the SC/SD. I got some help with the JCL to link my primitives to the routines for the Calcomps. All of the routines for Calcomp worked fine calling their lower level routines, and ultimately calling MY primitives. The company got a small bonus for getting it all done way sooner than planned, and I got a private major reprimand for getting it all done way sooner than it was budgeted for. Many others earned bonuses for the company. The company distributed the bonuses as BIG bonuses to upper executives (I think that the top guy got a car), and gave each of us a gift certificate/coupon for a turkey.
Re: APL\360
On 1/29/2021 1:58 PM, Fred Cisin wrote:
You COULD design a language around your favorite pseudo-code structures
I did that already, since I can not find a easy to port C compiler
with structures, and a small memory footprint like 64Kb. I found LCC 3.x
off a old CD rom archive, but I can't find the book at
a low cost.
Since the Architecture is still in flux, the compiler is rather rough.
The C code for cross compiler is a simple subset with no structures
making it easy to port when the time. comes to able to self host.
I got rid most of all the annoying ;'s ,'s }'s {'s
unary operands are a hack at the movement.
control is just
IF cond statements { EIF exp statements }* { ELSE statements } ENDIF
WHILE cond statements REPEAT
I like indentation, and demanded it from my students.
while (k)
{ if (foo)
{ ..do this thing
..do that thing
}
else
{ ..something here
}
}
Even K and R did not agree on indentation styles.
--
Grumpy Ol' Fred ci...@xenosoft.com
Re: APL\360
It happened to me as well - I found hundreds of warnings in the code and, after getting permission to address them, I was fired because 'we would have to recompile the Windows version due to the changes you made'; the source code was reverted to the state before I made the changes. I refuse to have their product on any system that I have involvement with... From: "cctalk" To: "cctalk" Sent: Friday, January 29, 2021 3:08:28 PM Subject: Re: APL\360 It was thus said that the Great Will Cooke via cctalk once stated: > > > On 01/29/2021 4:42 PM David Barto via cctalk wrote: > > > Whenever I start a new job the first thing I do today is enable -Werror; > > all warnings are errors. And I’ll fix every one. Even when everyone > > claims that “These are not a problem”. Before that existed, I’d do the > > same with lint, and FlexeLint when I could get it. > > That's exactly what I did. I was promptly told I was likely to get fired > for it. WHY? Why would you get fired for fixing warnings? Would it make some manager upstream look bad or something? -spc
Re: APL\360
> On 01/29/2021 5:08 PM Sean Conner via cctalk wrote: > > > > WHY? Why would you get fired for fixing warnings? Would it make some > manager upstream look bad or something? > > -spc Because the code was so fragile and "worked" that making the code "correct" was likely to break it. "A person who never made a mistake never tried anything new." -- Albert Einstein
Re: APL\360
It was thus said that the Great Will Cooke via cctalk once stated: > > > On 01/29/2021 4:42 PM David Barto via cctalk wrote: > > > Whenever I start a new job the first thing I do today is enable -Werror; > > all warnings are errors. And I’ll fix every one. Even when everyone > > claims that “These are not a problem”. Before that existed, I’d do the > > same with lint, and FlexeLint when I could get it. > > That's exactly what I did. I was promptly told I was likely to get fired > for it. WHY? Why would you get fired for fixing warnings? Would it make some manager upstream look bad or something? -spc
Re: APL\360
> On 01/29/2021 4:42 PM David Barto via cctalk wrote: > > Whenever I start a new job the first thing I do today is enable -Werror; all > warnings are errors. And I’ll fix every one. Even when everyone claims that > “These are not a problem”. Before that existed, I’d do the same with lint, > and FlexeLint when I could get it. That's exactly what I did. I was promptly told I was likely to get fired for it. I left there very soon after. They are most likely still shipping units, but now it probably has more warnings. Sad. Will "A person who never made a mistake never tried anything new." -- Albert Einstein
Re: APL\360
> On Jan 29, 2021, at 2:08 PM, Fred Cisin via cctalk > wrote: > > On Fri, 29 Jan 2021, wrco...@wrcooke.net wrote: >> Modern Visual Studio and GCC both flag the "=" in a condition, I believe. >> But if you're shipping code with 260+ warnings, who would see one more. > > In some cases, it is possible to put in preprocessor directives to alert the > compiler that you are aware of it, and to NOT generate the WARNING. > Or, in many cases to modify the code, such as EXPLICIT typedefs to not > generate warnings. > int X = PI; /* should give a warning */ > int x = (int)PI; /* should be OK, without a loss of efficiency */ > > > It's scary that code gets shipped as soon as it "seems to be working", > without confirming that ALL of the 260+ WARNINGS are deliberately over-ridden. > Whenever I start a new job the first thing I do today is enable -Werror; all warnings are errors. And I’ll fix every one. Even when everyone claims that “These are not a problem”. Before that existed, I’d do the same with lint, and FlexeLint when I could get it. And in every case, every single time I did this, for some reason the various “mysterious crash” problems would go away. Every time. But it couldn’t be those warnings, they weren’t the problem. David
Re: APL\360
'=' and '==' makes possible what is probably the most common error, and which the compiler doesn't catch: if (x = 3) . . . /* sets x to 3 and gives TRUE for the condition */ I imagine that there are probably some pre-processors that would return a WARNING for it. On Fri, 29 Jan 2021, wrco...@wrcooke.net wrote: Modern Visual Studio and GCC both flag the "=" in a condition, I believe. But if you're shipping code with 260+ warnings, who would see one more. Yet, '=' in a condition is not necessarily a fault. while (*T++ = *S++); /* is the guts of strcpy */ But, it can certainly still blow up in your face. If you want to insert a character at the beginning of a string pointed to by P1, P2 = P1 + 1; strcpy(P2,P1);/* What went wrong? :-) */ For beginners, it would be nice to use a "SANDBOX" C with runtime error checking. such that Z = X / Y ; would do aif (Y == 0) . . . Z = X / Y ; But, that would slow down stuff in the situations where it isn't needed. Y = 2; if (condition) Y = 3; Z = X / Y ; does NOT need that runtime error check. An assumption in C (whether or not it is a valid assumption) is that the programmer KNOWS where and what runtime checking is needed, and will manually add it in where needed. The problem, of course, is that they DON'T. There's a pretty good chance the heat pump you're using right now has those warnings. Alas... In some cases, it is possible to put in preprocessor directives to alert the compiler that you are aware of it, and to NOT generate the WARNING. Or, in many cases to modify the code, such as EXPLICIT typedefs to not generate warnings. int X = PI; /* should give a warning */ int x = (int)PI; /* should be OK, without a loss of efficiency */ It's scary that code gets shipped as soon as it "seems to be working", without confirming that ALL of the 260+ WARNINGS are deliberately over-ridden.
Re: APL\360
On 01/29/21 15:58, Fred Cisin via cctalk wrote (in part): '=' and '==' makes possible what is probably the most common error, and which the compiler doesn't catch: if (x = 3) . . . /* sets x to 3 and gives TRUE for the condition */ I imagine that there are probably some pre-processors that would return a WARNING for it. Henry's first commandment: Thou shalt run lint frequently and study its pronouncements with care, for verily its perception and judgement oft exceed thine. N.
Re: APL\360
On 1/29/21 12:58 PM, Fred Cisin via cctalk wrote:
>>> Without OTHER changes in parsing arithmetic expressions, that may or
> I like indentation, and demanded it from my students.
> while (k)
> { if (foo)
> { ..do this thing
> ..do that thing
> }
> else
> { ..something here
> }
> }
>
That's fine, but when you have a language that makes indentation part of
the language (i.e. no braces, brackets or keywords denoting boundaries
of the block) , there be monsters.
And yes, there are such languages.
--Chuck
Re: APL\360
Early versions of BASIC had a keyword "LET". LET X = 3 is devoid of most of the ambiguity, and LET 3 = X is much less likely to be attempted. 'Course, changing the values of constants opens up some strange possibilities! On Fri, 29 Jan 2021, Chuck Guzis via cctalk wrote: SUBROUTINE FOO(X) INTEGER X X=15 RETURN END ... CALL FOO(10) Lots of fun, there. I said that LET made redefining constants LESS likely, just because it clarifies that it is an assignment to be done. There are other ways. Redefining constants permits fixing a number of things, such as 42 WHATDOYOUGETWHENYOUMULTIPLYSIXBYNINE
Re: APL\360
On 1/29/21 11:40 AM, Nemo Nusquam via cctalk wrote: > On 29/01/2021 14:20, Fred Cisin via cctalk wrote: >> We don't need another BIG-endian/little-endian debate! >> (when a 16 bit number is stored in bytes, does the high order byte >> come first, or the low order byte?) (cf. intel V Motorola) > Amen to that (but did it not originate with DEC vs. IBM?) > > N. It was the result of sub-word addressable architecures. Most old (pre S/360) digit/character-addressable architectures were big-endian (i.e. higher-order characters occupied lower addresses) Even PDP-11 isn't strictly little-endian, though Intel X86 definitely is. Numbering of bits in a word is also interesting. Is the high order bit in a 64 bit word, bit 0 or bit 63? Both conventions have been employed. This really gets interesting on bit-addressable architectures. STAR for example, is bit addressable, but big-endian, with alignment of data dependent on the data type (e.g. bytes must have the lower 3 bits of their address as 000; halfwords as 0 and so on. However, it's possible to extract any group of bits from a bit-addressed datum. --Chuck --Chuck
Re: APL\360
> On 01/29/2021 2:58 PM Fred Cisin via cctalk wrote: > > '=' and '==' makes possible what is probably the most common error, and > which the compiler doesn't catch: > if (x = 3) . . . /* sets x to 3 and gives TRUE for the condition */ > I imagine that there are probably some pre-processors that would return a > WARNING for it. > Modern Visual Studio and GCC both flag the "=" in a condition, I believe. But if you're shipping code with 260+ warnings, who would see one more. There's a pretty good chance the heat pump you're using right now has those warnings. Alas... Will
Re: APL\360
On 1/29/21 11:59 AM, Fred Cisin via cctalk wrote: > Early versions of BASIC had a keyword "LET". LET X = 3 is devoid of > most of the ambiguity, and LET 3 = X is much less likely to be > attempted. 'Course, changing the values of constants opens up some > strange possibilities! SUBROUTINE FOO(X) INTEGER X X=15 RETURN END ... CALL FOO(10) Lots of fun, there. --Chuck
Re: APL\360
Without OTHER changes in parsing arithmetic expressions, that may or may
not be warranted, just replacing the '=' being used for assignment with an
arrow ELIMINATED that particular confusion. Well, mostly. You can't use
a right pointing arrow to fix 3 = X
On Fri, 29 Jan 2021, ben via cctalk wrote:
Blame K with C with the '=' and '==' mess because assignment is a
operation. I never hear that C or PASCAL have problems.
I think that it was Ritchie and Thompson who created C;
Kernighan and Ritchie documented it.
'=' and '==' makes possible what is probably the most common error, and
which the compiler doesn't catch:
if (x = 3) . . . /* sets x to 3 and gives TRUE for the condition */
I imagine that there are probably some pre-processors that would return a
WARNING for it.
I find the pseudo code often less confusing than real languages.
the one I like best uses indentation for structure.
while k do
.if foo then
..do this thing
..do that thing
.else
..something here
.!end if
! end while
You COULD design a language around your favorite pseudo-code structures.
I like indentation, and demanded it from my students.
while (k)
{ if (foo)
{ ..do this thing
..do that thing
}
else
{ ..something here
}
}
Even K and R did not agree on indentation styles.
--
Grumpy Ol' Fred ci...@xenosoft.com
Re: APL\360
On 1/29/21 12:21 PM, ben via cctalk wrote: On 1/29/2021 12:59 PM, Fred Cisin via cctalk wrote: Without OTHER changes in parsing arithmetic expressions, that may or may not be warranted, just replacing the '=' being used for assignment with an arrow ELIMINATED that particular confusion. Well, mostly. You can't use a right pointing arrow to fix 3 = X Blame K with C with the '=' and '==' mess because assignment is a operation. I never hear that C or PASCAL have problems. We complained bitterly about this in the early days (Unix v6 days). They at least listened and fixed the = (e.g. =+, =-) because of ambiguity but refused to change assignment. I find it annoying that a type-o of forgetting an '=' in a comparison can result in a hard to find bug. TTFN - Guy
Re: APL\360
On 1/29/2021 12:59 PM, Fred Cisin via cctalk wrote: Without OTHER changes in parsing arithmetic expressions, that may or may not be warranted, just replacing the '=' being used for assignment with an arrow ELIMINATED that particular confusion. Well, mostly. You can't use a right pointing arrow to fix 3 = X Blame K with C with the '=' and '==' mess because assignment is a operation. I never hear that C or PASCAL have problems. I find the pseudo code often less confusing than real languages. the one I like best uses indentation for structure. while k do .if foo then ..do this thing ..do that thing .else ..something here .!end if ! end while -- Grumpy Ol' Fred ci...@xenosoft.com
Re: APL\360
We don't need another BIG-endian/little-endian debate! (when a 16 bit number is stored in bytes, does the high order byte come first, or the low order byte?) (cf. intel V Motorola) On Fri, 29 Jan 2021, Nemo Nusquam via cctalk wrote: Amen to that (but did it not originate with DEC vs. IBM?) Yes. I was talking about more recent. I don't know what other predecessors there were befor DEC V IBM.
Re: APL\360
On Fri, 29 Jan 2021, Chuck Guzis via cctalk wrote: Well, part of the confusion lies in the difference of "=" in mathematics indicating a property or state, as opposed to computer languages using it as an operator. It's a subtle distinction, but important. D = 4AC in mathematics establishes a property of D, whereas D = 4*A*C in BASIC, etc. means "multiply 4 by A, then take that result and multiply it by the value of C and store the result into D. APL treats the assignment as what it is--an operation. Why the RTL of APL was chosen by Iverson, is a mystery; I agree. He was, as far as I know, not native writer of Hebrew. I suppose we should be grateful that he didn't specify APL as a boustrophedon. We already have Forth. Therein lies one of the largest problems for first exposure to programming. NO! We are NOT talking about "first exposure" as meaning a few years; we are talking about the first few DAYS (for most students, but up to weeks/months for some). By the time that you got HERE, you had forgotten what you struggled with on your first day(s). They have been brought up with enough math that they "understand" that X = 3 means that X has a value of 3. But why not 3 = X ? As Chuck said, it is the fundamental difference between equality (property) and assignment (operation). To a programming language, 3 = X is a request to take the current value of X, and assign that as the NEW value of the "constant" 3. And the compiler won't cooperate! Early versions of BASIC had a keyword "LET".LET X = 3 is devoid of most of the ambiguity, and LET 3 = X is much less likely to be attempted. 'Course, changing the values of constants opens up some strange possibilities! A few other languages have used other different symbols for assignment, to avoid the confusion of "equality" Without OTHER changes in parsing arithmetic expressions, that may or may not be warranted, just replacing the '=' being used for assignment with an arrow ELIMINATED that particular confusion. Well, mostly. You can't use a right pointing arrow to fix 3 = X I spent years introducing students to their first contact with computers. MY first was FORTRAN. My father handled the statistics for the "CBS National Driver's Test". IBM provided the computers, the port-a-punch cards for mail-in responses (printed with a box for where to put a stamp!), and the programming. One of the early percentages in the LIVE show didn't add up to 100! If you look over Walter Cronkite's shoulder, you can see my father frantically manually recalculating the numbers. The next morning, my father had the dining room table covered with manuals, and we started to try to learn FORTRAN. IIRC, over a short time, we settled on the books by McCracken and Decima Anderson. BTW, I consider BASIC to be very good for "FIRST EXPOSURE", IFF it is limited to that, and other languages are soon introduced. I don't agree with Dijkstra: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." -Edsger Dijkstra It takes a substantial OVER-exposure to cause the damage. -- Grumpy Ol' Fred ci...@xenosoft.com
Re: APL\360
On 1/29/2021 8:19 AM, Liam Proven via cctalk wrote: On Fri, 29 Jan 2021 at 13:11, Peter Corlett via cctalk wrote: It is *also* the use of symbols. Firstly, some people are just symbol-blind and prefer stuff spelled out in words. It's just how brains are wired. Agreed. I submit this is also why some people find Lisp (and perhaps Forth and Postscript) straightforward, while to others it remains ineffable. Symbols I can live with. I can never remember them but that is not the point. ^\# is lot better than to say "invert matrix on diagonal". I like words because they tend to mean one thing, not like Icons that imply something but never tell you just what. In Car ~~ is that windshield wipers, flashing lights, or parking brake? GUI's are more a problem, they change every software revision. You can't use the online help, because you can't find where they moved it to in the menu, if can find the new menu. Still annoyed at ASCII removing the -> (arrow) to something else. you could write a+3 -> c leaving = for equal. Why they needed all those control characters defined, but nobody used them? Ben.
Re: APL\360
On 29/01/2021 14:20, Fred Cisin via cctalk wrote: We don't need another BIG-endian/little-endian debate! (when a 16 bit number is stored in bytes, does the high order byte come first, or the low order byte?) (cf. intel V Motorola) Amen to that (but did it not originate with DEC vs. IBM?) N.
Re: APL\360
On Fri, 29 Jan 2021, Paul Koning via cctalk wrote: BTW, I don't really know Hebrew but doesn't it still write math LTR? I know they write numbers that way. CAREFUL. We don't need another BIG-endian/little-endian debate! (when a 16 bit number is stored in bytes, does the high order byte come first, or the low order byte?) (cf. intel V Motorola)
Re: APL\360
On Fri, Jan 15, 2021 at 11:21:11AM -0500, Nemo Nusquam via cctalk wrote: [...] > In 1999, a fellow student in a UML course worked for a large information > company (Reuters, I think?) and told me that they had embarked on an > expensive s/w conversion project. Their back-end systems were implemented > in APL and they could not find programmers -- even ones willing to learn > APL for pay. I'd have taken it if the price was right. Heck, I seem to have spent most of my career wading through fossilised Perl, so it's not as if I'd notice much difference. Companies moaning that they can't find staff inevitably turn out to be offering less than the going rate for what they're demanding and/or the company is toxic. Usually both.
Re: APL\360
> On Jan 29, 2021, at 12:12 PM, Chuck Guzis via cctalk > wrote: > > On 1/29/21 6:27 AM, Paul Koning via cctalk wrote: > >> True, although right to left is not a natural way to read mathematical >> formulas. The reason APL uses right to left is that the designers >> apparently were unwilling to change the direction of the assignment >> operator, so everything else had to follow. Another language that doesn't >> have precedence avoided this issue by changing assignment to match the >> others, i.e., everything is left to right. That is POP-2, a language out of >> the U of Edinborough I remember from an AI class. So it would do stuff like: >> >> a + 1 * 5 -> b >> >> which in C would be >> >> b = (a + 1) * 5; >> >> and is definitely easier to read than the APL equivalent. > > Well, part of the confusion lies in the difference of "=" in mathematics > indicating a property or state, as opposed to computer languages using > it as an operator. It's a subtle distinction, but important. > > D = 4AC in mathematics establishes a property of D, whereas > D = 4*A*C in BASIC, etc. means "multiply 4 by A, then take that result > and multiply it by the value of C and store the result into D. > > APL treats the assignment as what it is--an operation. Why the RTL of > APL was chosen by Iverson, is a mystery; I agree. He was, as far as I > know, not native writer of Hebrew. I suppose we should be grateful > that he didn't specify APL as a boustrophedon. You're correct about equality or identity vs. assignment, but that wasn't my point. I should have used ALGOL rather than C as the "other language" example to avoid introducing that angle. Yes, the right to left thing is really strange, since it requires changing the usual order of hundreds of operators to preserve the usual order of a single one, rather than serving the majority as POP-2 does. BTW, I don't really know Hebrew but doesn't it still write math LTR? I know they write numbers that way. paul
Re: APL\360
On Friday, January 29, 2021, 10:19:54 AM EST, Liam Proven via cctalk wrote: >On Fri, 29 Jan 2021 at 13:11, Peter Corlett via cctalk >wrote: >> >> It is *also* the use of symbols. Firstly, some people are just symbol-blind >> and prefer stuff spelled out in words. It's just how brains are wired. > > Agreed. I submit this is also why some people find Lisp (and perhaps > Forth and Postscript) straightforward, while to others it remains ineffable. This reminds me of something I once heard Grace Hopper say. Now this won't be an exact quote since I'm relying on some rather old memory. As I remember it, she said: "There are basically two kinds of people in the world. The first is those of use who are Mathematicians at heart. We want to take all the words and turn them into symbols. Everyone else wants to take all the symbols and turn them into words. COBOL is for them." BLS
Re: APL\360
On 1/29/21 6:27 AM, Paul Koning via cctalk wrote: > True, although right to left is not a natural way to read mathematical > formulas. The reason APL uses right to left is that the designers apparently > were unwilling to change the direction of the assignment operator, so > everything else had to follow. Another language that doesn't have precedence > avoided this issue by changing assignment to match the others, i.e., > everything is left to right. That is POP-2, a language out of the U of > Edinborough I remember from an AI class. So it would do stuff like: > > a + 1 * 5 -> b > > which in C would be > > b = (a + 1) * 5; > > and is definitely easier to read than the APL equivalent. Well, part of the confusion lies in the difference of "=" in mathematics indicating a property or state, as opposed to computer languages using it as an operator. It's a subtle distinction, but important. D = 4AC in mathematics establishes a property of D, whereas D = 4*A*C in BASIC, etc. means "multiply 4 by A, then take that result and multiply it by the value of C and store the result into D. APL treats the assignment as what it is--an operation. Why the RTL of APL was chosen by Iverson, is a mystery; I agree. He was, as far as I know, not native writer of Hebrew. I suppose we should be grateful that he didn't specify APL as a boustrophedon. We already have Forth. --Chuck
Re: APL\360
On Fri, 29 Jan 2021 at 13:11, Peter Corlett via cctalk wrote: > > It is *also* the use of symbols. Firstly, some people are just symbol-blind > and prefer stuff spelled out in words. It's just how brains are wired. Agreed. I submit this is also why some people find Lisp (and perhaps Forth and Postscript) straightforward, while to others it remains ineffable. > It may > have even been inspired to do this by APL given the manual says Sinclair > BASIC was written by a "Cambridge mathematician". Specifically, this one, I believe: https://en.wikipedia.org/wiki/Steve_Vickers_(computer_scientist) > Yes, well, a lot of BASIC programmers have even more fundamental problems > with understanding important programming concepts, such as recursion Good BASICs had that. > and > pointers/references. ... Fair. :-( > Modern x86-64 (and ARM etc) also (finally!) has useful vector instructions. > Unfortunately, the popular languages do not make their use terribly simple, > and mostly rely on compilers recognising idiomatic loop patterns over > scalars and transforming them. This works about as well as you might expect. Very interesting paper, IMHO: https://queue.acm.org/detail.cfm?id=3212479 « C Is Not a Low-level Language Your computer is not a fast PDP-11. » It does imply the question, though, as to what a high-level language designed for multithreaded partly-parallel CPUs with SIMD extensions would look like, and whether this kind of logic is easily expressed for people who do not have an APL sort of mind... -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: APL\360
On 1/29/21 7:27 AM, Gavin Scott via cctalk wrote: On Fri, Jan 29, 2021 at 6:11 AM Peter Corlett via cctalk wrote: Secondly, beyond BODMAS, the meaning and precedence of random symbols is unclear to casual readers. An issue that plagues other operator-rich languages, but not APL since APL follows a strict right-to-left evaluation order for ALL operators (no BODMAS in sight). You can use parentheses to affect it, but it's not as hard to figure out a complex APL expression as one might naively expect at first glance. The symbols did greatly limit the growth of APL in its early years just because it made the cost of entry higher so not as many people were exposed to it, and it also suffered the related "small proprietary language" issue that has plagued pretty much every language whose developers tried to get rich off the language itself. Curiously, in the very early 80's, it was the language of choice for teaching computers at Marist College. My understanding of the symbols was that they are quite explanatory to a mathematician. While I don't have them in my head as most of the APL's I used worked on ASCII terminals using Di-graphs and Tri-graphs, I can still understand and even write APL. It's fun to play with every once in a while. bill
Re: APL\360
> On Jan 29, 2021, at 7:27 AM, Gavin Scott via cctalk > wrote: > > On Fri, Jan 29, 2021 at 6:11 AM Peter Corlett via cctalk > wrote: >> Secondly, beyond BODMAS, the meaning and precedence of random symbols is >> unclear to casual readers. > > An issue that plagues other operator-rich languages, but not APL since > APL follows a strict right-to-left evaluation order for ALL operators > (no BODMAS in sight). You can use parentheses to affect it, but it's > not as hard to figure out a complex APL expression as one might > naively expect at first glance. True, although right to left is not a natural way to read mathematical formulas. The reason APL uses right to left is that the designers apparently were unwilling to change the direction of the assignment operator, so everything else had to follow. Another language that doesn't have precedence avoided this issue by changing assignment to match the others, i.e., everything is left to right. That is POP-2, a language out of the U of Edinborough I remember from an AI class. So it would do stuff like: a + 1 * 5 -> b which in C would be b = (a + 1) * 5; and is definitely easier to read than the APL equivalent. paul
Re: APL\360
On Fri, Jan 29, 2021 at 6:11 AM Peter Corlett via cctalk wrote: > Secondly, beyond BODMAS, the meaning and precedence of random symbols is > unclear to casual readers. An issue that plagues other operator-rich languages, but not APL since APL follows a strict right-to-left evaluation order for ALL operators (no BODMAS in sight). You can use parentheses to affect it, but it's not as hard to figure out a complex APL expression as one might naively expect at first glance. The symbols did greatly limit the growth of APL in its early years just because it made the cost of entry higher so not as many people were exposed to it, and it also suffered the related "small proprietary language" issue that has plagued pretty much every language whose developers tried to get rich off the language itself.
Re: APL\360
On Thu, Jan 14, 2021 at 07:43:13PM -0800, Chuck Guzis via cctalk wrote: [...] > APL was difficult for those used to traditional programming languages, not > primarily because of the character set, but because it's basically a > vector/matrix programming language. It is *also* the use of symbols. Firstly, some people are just symbol-blind and prefer stuff spelled out in words. It's just how brains are wired. Secondly, beyond BODMAS, the meaning and precedence of random symbols is unclear to casual readers. Calls to named functions tend to be more descriptive -- "map" and "filter" mean the same sort of thing across functional(-inspired) languages -- and the precedence is obvious thanks to the parentheses. At a guess, part of the reason APL does this is so that the programmer pre-tokenises the input to make it easier for the language to process. Sinclair BASIC did this too, to much wailing and gnashing of teeth. It may have even been inspired to do this by APL given the manual says Sinclair BASIC was written by a "Cambridge mathematician". The "modern" vector/matrix programming language most commonly used by contemporary programmers use is probably SQL. It's amazing how many people use it inefficiently as a key-value store when it's really a matrix-transformation language even though it *looks* like an imperative language. The 1970s has a lot to answer for. > It's a different world from BASIC, for sure. Yes, well, a lot of BASIC programmers have even more fundamental problems with understanding important programming concepts, such as recursion and pointers/references. Without those, a lot of important algorithms cannot be implemented, or even understood. > Neil maintained that its strength lay in thinking about things in a > non-scalar way. I'll give him that--programming on STAR, where a scalar > was treated by the hardware as a vector of length 1 (and thus very slow > because of startup overhead) certainly led you toward thinking about > things in vector operations, just like APL. Modern x86-64 (and ARM etc) also (finally!) has useful vector instructions. Unfortunately, the popular languages do not make their use terribly simple, and mostly rely on compilers recognising idiomatic loop patterns over scalars and transforming them. This works about as well as you might expect.
Re: APL\360
On 1/20/2021 10:16 AM, Bill Gunshannon via cctalk wrote: Learning many different paradigms makes it easier to and more likely that you will choose the right tool for the job. In the world of general purpose languages all you have is a hammer and so all tasks look like nails. bill I don't see languages in general have improved since the the mid 1960's. Hardware and language models don't reflect each other, and don't have extendable data sizes and types. PL/I seems to have been the best,but too tied to IBM. C standard 2131 complex numbers C standard 2143 dubble complex numbers Every machine I can think of had a carry flag of some type yet no language uses that to extend it self. I don't believe in objects because data structures don't have classes, but are more similar to each other. A window A structure is like window B but details are different. That makes things look portable when they are not. Constants still seem to be embedded in data structures, rather than abstract. -- zero array define LIMIT abc blah array[LIMIT] ... i = 0 while i< LIMIT array[i] = 0 i = i + 1 endw I would like say let LIMIT = abc blah array[LIMIT] i = 0 while i< array:LIMIT array[i] = 0 i = i + 1 endw Ben.
