attn cpp coders

[johnjohn]

Anyway, C++, D, or Rust are already quite advanced languages, IMO not a good choice to start learning programming with.
But it seems you already figured that out yourself.

If I may recommend you some things, my advice was:

1. Get a copy of the K&R "The C Programming Language", second edition (1988)
2. Take the chance to learn parallel the usage of the debugger (lldb if you use clang, which I think you do) Some say, printf is all the debugging you need. Others say, a debugger is all you need. I say you need both, and will learn which to choose when.
3. If not already done yet also parallel learn a version control system.

Well, hello there, Sir Maturin. We haven't crossed paths in quite some time. It's nice to hear from you

I actually looked at Rust last year and my conclusion is that someone had the idea to turn JavaScript into a compiled programming language. I swear that it is alot like JavaScript - and i hate JavaScript. I would rather learn Java than Rust. After i have learned C and Cpp, i will also look at Java.

I have a copy of The C Programming Language second edition. Excellent reference. I also have gdb and valgrind and i make use of them often.

you mentioned version control system but i had to search the web to make sure that i have the correct definition (version as in my software program version 1.0 or version control as in keeping copies of new versions and old versions?)

i currently work with the file named "mymath49.c" so yes, i save versions anytime that i make a change to the software. I keep copies of my code throughout its lifespan because i've lost code before and it made me cry I started maintaining versions when i crossed into intermediate php skill level.

one thing that i notice about C language: it is blazing fast! fast compilation and fast execution. Very impressive. But also, it has alot of cages and handcuffs. I am always trying to figure out ways to break out of cages and remove the handcuffs but i think that this point-of-view is solely based upon learning PHP (scripting language) instead of a true programming language. I have to rewire my brain now because alot of my PHP tricks absolutely do not work in C.

 

[Maturin]

We haven't crossed paths in quite some time. It's nice to hear from you

Thanks. I don't post unless I can say something useful to something - or at least what I think useful was.
I was still here all the time and also watching "your FreeBSD career" from "Windows guy 'no terminal but GUI only for me, thanks!'" over "terminal is great!" to "...I now start programming on C++ and C" . Very good! Exemplary.
I'm for sure not the only one loving it to see some one new comes to FreeBSD, being convinced to give it a shot, then digs into it, starts to love it, digging into it even deeper,...finding her/his own path.

But back to topic:

I actually looked at Rust last year and my conclusion is that someone had the idea to turn JavaScript into a compiled programming language. I swear that it is alot like JavaScript

I cannot say anything about that, since I glimpse at Rust by now just very shallowly, and I never learned neither Java nor JavaScript, since without even knowing at least the latter one to me is for programming webpages, and that's not what I'm doing. But there are always similarities between almost all programming languages, since most languages (the serious to take ones, not some experimental or 'joke' languages like e.g. Brainfuck) are started to do something better the existing ones are bad at or do not provide at all, orientating at what there already is. So of course there are similarities. The heritage tree (second picture down on the right side on Wikipedia:ALGOL gives a rough idea how it "all started" (not quite true, since there is at least one other tree issued from lisp.) And most of the times somebody presents a new programming language (not seldom self advertised as "now this one will solve all our programming issues - but it's not finished yet; in fact I just started on that...") I look at it and think, 'how this look like C again.' There have been many attempts to produce a better C. Most were not really convincing.
But programming languages do not only differ only by their syntax, that's more superficial. You need also to grasp their "philosophy" (for lack of a better word), and if you're not only learning programming languages by pure curiosity but going to be interested in really to do some serious programming - maybe join some open source project, maybe FreeBSD - you also need to learn which programming languages are used in which projects.
Could go more into details here, but there are many others by far way more experienced programmers on a professional level here could tell you better than me.

About version control there are some, and you better take at least a closer look yourself at their introduction, to understand what they are doing and what they are for. The most popular and by far most used one is of course git
Like a few others personally I use SVN, which maybe a good start for get into versioning control at all, because it's less complex than git, but it needs a central server running the repo. And if you're going to collaborate one day with others it's almost certain you need to use git anyway.
But there are others of course, like Fossil or Mercurial, which I do have no experience at all with, but others here do.
Anyway, reading for yourself a bit about versioning control enlightens you more than I write long posts.
However

currently work with the file named "mymath49.c" so yes, i save versions anytime that i make a change to the software.

That's exactly the point you better start using a VCS. This suggests you already have at least 49 files somewhere somehow stored. With a versioning control system instead you would have only mymath.c. The VCS stores all the former versions for you, provides the possibility to jump between any version anytime, and gives you a list of which versions there are, and what their core point in difference is (see writing comments at the end of this post.)

As long as you only work on single files, for doing a beginners class or just writing a very small experimental program, there is no problem. But once you say 'I could (re)use this program or that function a bit modified for something else', the chaos starts. Having programs consisting of more than one file, start creating libraries, and at the latest, when you are not working alone on some files anymore, trying to have different versions/modifications/derivates/states all as copies of files - some are in a useful state, some may be useful later for something else, but most are just in some in between "solved something but not really useful yet" state... to be "organized" in several directories ... this "system" reveals quickly its limits: chaos is predetermined.
When there is a total mess, and it's just a question of time when there will be chaos, you are confronted with the choice what to do now - happened to myself many years ago: Stop frustrated with programming at all, what was a pity, because you had so much fun and the problem ain't lacking of programming skills, but because in the lack of organization. Or to start all over again, or bite the bullet, and clean up the mess. Neither way is nice. And your programs don't have to become large to get there.
So better learn and start ASAP how to organize and prevent the mess by using a versioning control system.

Versioning Control System: learn what they are for, what they do, use the rich expertise of this forums to get more input, help and other points of view than just by me.
Then pick one, learn its basic usage, and integrate it as soon as possible as a part of your programming processes, because it is part of any serious programming beyond beginners classes.
Learning to use a VCS is not done alone by learning the usage of its UI. You need to learn at least two things you cannot learn by books or any other text or explanation by others:
When is a change worth to become a commit. And write short but catchy commit comments, so to see later quickly which was the core point of which version. This you can only learn by doing it yourself.

I'm pretty sure you will be very glad if you started on using VCS soon.

 

[johnjohn]

I absolutely love FreeBSD and i still feel the same way. The forum is really helpful, so i am definitely thankful for this place. You have also helped me early on, so i still remember your advice. And you continue to offer advice, which i also appreciate. Thank you for taking time to reply, Maturin. You are a good member of this forum

Version control is very important and learning the concept is imperative when working with other coders/programmers. I allready understand the reasoning. My project is beginning to expand and i feel the control pressure allready. I am designing my calculator to handle three scenarios: console mode only, gui and console output only (so that one may use the calculator via other languages such as php to get the output/answer only). I'm also building the program to handle various languages and user settings. A bit too much for a beginner but i'm learning as i go.

I fully intend to contribute to FreeBSD in the future (once i become skilled enough with C/C++). FreeBSD is great! I'm happy to leave Windows behind me and i've met alot of nice people in this forum, so win-win.

 

[johnjohn]

hey, i found a way to divide digits and 10 without math, bit shifting, logarithms or other math related tricks. I finished coding 2 and i works and it is fast! I do not research math related stuff, so i wonder if algorithms like mine exist? i have spent days hammering out data on paper and it has paid off. My calculator is coming along well and my coding skills are getting better.

i've attached some screen shots of my divison by two algorithm, including a googol divided by two. I am quite happy with the fruits of my labor. Too bad we can't make money with stuff like this. LOL. Anyway, i wonder what tools exist to test the speed/execution time, cpu cycles and ram usage of a c program in FreeBSD. Any suggestions? something like Valgrind.

 

[Maturin]

Anyway, i wonder what tools exist to test the speed/execution time, cpu cycles and ram usage of a c program in FreeBSD.

At first: congratulations. You are getting deeper, and having fun with it. Very good! Keep on that good work!

Exact measurement of speed/execution time is kind of a bit tricky.

You can use the time.h in C:

#include <stdio.h>
#include <time.h>

int main()
{

    int t_start, t_end;

/* other code */

    t_start = clock();
/*
....code to be measured ....
*/
    t_end = clock();
    printf("%d\n", t_end - t_start);

/* other code */

return 0;
}

You can use getrusage(2) to get RAM usage. But also the debugger can help.

For to get exact execution times - 'how many clock cycles does this part of code needs to be executed on the CPU?' it's needed to be known how many clock cycles each machine command takes, knowing the machine code of a certain part of code (objdump(1), e.g. objdump -d a.out) which delivers the number of clock cycles needed for that part, those computed with the CPU's clock frequency gives the time. The debugger can help you on that.

But the point is: As long as it's just out of pure curiosity, you may get lost into details which are not important to know as long as you don't really need to meet real time requirements or need exact timing, e.g. control some fast technical process.
The actual question is: What means exact execution time on a modern personal computer, where you not only have to deal with an OS (see coming text), but also 2 to 64 core CPUs running at 1.5 to 5GHz? And how useful is this to know, or better when is it worth the effort to get this value?
You see:
Just measuring how long a program part, or even the whole prog runs on your system is not always very meaningful.
When you place some code between both t_...=clock(); that uses to run a couple of seconds, and then run the same object code a couple of times, you will not receive the same timespan every time.

Explanation:
You are using a time sharing OS. So you're not running your prog directly on the CPU ("bare metal"), but let the OS handle this job. Doesn't matter if you're using BSD, Linux, MacOS, Windows or whetever - the principal on a time sharing OS is always the same.

Running a prog on an ts OS works this way: You tell the OS, 'Hey! Run this!' Then the OS (there is also communication between the shell and the kernel, and also the shell then has jobs to do, e.g. when you use printf; not going into details here) needs to see, when to fit it into its schedule, where to slip it between all the other jobs it currently does. Of course, under normal cicumstances (you are not currently building world parallel, which made your machine being already pretty near 100% load) there is way more capacity left to just execute a small piece of software you ask for en passant. And since you are the user, you get a higher priority for the jobs you ask for than the OS's jobs running in background when there is nothing else to do. But anyway it needs some CPU time to run, needs to slip in somewhere, needs to be loaded, and then executed, when there is time for it.

As the user infront of a machine you don't recognize anything of that. At least you shall not. (Except of course the program takes a while to run, e.g. counts a million times from zero to ten thousand, but that's not the point here) If so then those are the so called 'lags'. Commonly known as a cause of losing a player's life on a virtual battlefield, because the internet connection had a lag, and your game froze for a few tenth seconds. But it's also, when you realize your mousepointer is not running smoothly, there is a significant delay between pressing a key and seeing the letter appear, or something like that. It's when your machine's load is over 100% its capacity, and the OS gets problems to schedule enough CPU time for all the tasks asked to be done.

A modern time sharing OS has a bunch of jobs to do. Even organizing all the jobs is a job of its own. The point is, at least the jobs according directly with the user's interaction (UI) are all (shall be) done so damnd fokkin' quickly, that for a human it seems they are happening instantaneously at the same time, or at least fast enough not to be recognize there are any delays. Or delays happen very seldom and are very short so not disturbing.
While other jobs not having a direct connection to the user's interactions with the machine, the time when they are started and the timespan they need to be done are of lower priority. It doesn't matter really how long those take to be finished, as long as they are done. For example it doesn't matter if the new version of the source code file you're writing is saved to disk within 31 ms or 329 ms - anyway fast enough for the job. Of course we are talking computer's time scales. Which means a couple of seconds are "just sometime in the future, doesn't matter when."

Anyway, and that's the core point, there are delays, constantly many, many delays. Most of the times they are too short for a human to be recognized, so his work at the machine feels smooth.
<[begin side track]>
There is a neuropsychological limit of perception - a minimum time that nerves respond to a stimulus. Since there is not only a very large difference between seeing, hearing,...feeling a touch with your fingertips or with your toes, but also between individual humans, to give a general number for it is not actually correct. But to give a rough idea which for many practical applications is not complete bogus, one could say anything shorter than app. 30 ms is recognized by a human as immediately, instantaneously, not even recognized there was a delay at all.
For a modern CPU 30 ms is a small eternity - you can do a lot many things in that time.
<[end side track]>
When you let a program run on an OS, supposing a very small C program doing just some short calculations with pregiven values (named "c" here), and there is no waiting for user interaction, the time line would look something like this:
[.................................- wait for the OS to begin execution -........................................][c][...............................- wait for and then printf("", result); - ..................................]
All this waiting happens in milliseconds. So an execution of a very small program seems to happen at the very moment you hit the enter key to start it, while in fact most of the time is not needed for the program's execution, but for the shell and OS to handle its "organization."

Point is, all that scheduling by the OS, wait to fit in, wait for to run it in most of the times is by far way more than short enough, so the user is not disturbed in his workflow on an "office machine" ("personal computer"). But there are those times. And above all they not always have the exact same length. So their timespan is not predictable. And, like in this example, they can exceed the actual execution time of a small prog by several times (even if not recognized.)

Plus, modern CPUs do such things like code prediction, and running pieces of code parallel.

So, again:
As long as you don't really need to deal with exact timing, e.g. having to control some fast technical process, or need to speed up your software, because it runs to slow to meet some real time requirements (producing lags), then just do what the majority does: Don't bother much, and simply rely on the machine will run it fast enough.
Besides, you can gain way much more speed by chosing the right algorithm, or tighten your code, than finetuning at clock cycles.

"Premature optimization is the root of all evil."
[Donald Knuth]

 

[johnjohn]

Hallo Maturin,

Thank you very much for the detailed and informative post, you are a fine member of this forum I cannot stress enough how much i appreciate you and this forum (and FreeBSD).

I apologize for the very late reply. I have been so busy the past week and a half and when i had free time before bed, then i used that time to program.

I finished division by two without using math and it was relatively simple algorithm. I thought that i had three figured out but i was failing miserably. I've spent the past week and a half hammering out an algorithm and yesterday i reached the apex. Voila! my division by three without using math is fully functional today I was overthinking the algorithm and it turns out to be relatively simple when viewed correctly. I was starting to feel discouraged but i finally figured it out. I am sometimes mentally slow. I am definitely not Zweistein (word play on Einstein, LOL). I will attach some screen captures of division by three in my c99 calculator.

I believe that i can use this three algorithm to work with any number with minor adjustments. My ultimate goal is to divide without using math and floating point numbers. I am successful with digits 2 and 3. I am very happy today

 

[Maturin]

I am sometimes mentally slow.

There are two kinds of people: mentally fast and mentally slow
The mentally fast need less effort to learn new things. That's why at the first glance they seem to be the smarter ones. But they also forget faster.
For the mentally slow it's harder to grasp things. But once they got it, they got it really. And hardly forget anymore.
So, in the long term the mentally slow are the smarter ones.

My ultimate goal is to divide without using math and floating point numbers.

As long as you mean by that "not using the given math functions or by libraries" than that's okay, since you simply cannot do math without math at all. Dividing or multiplicating a number by moving its digits is math - it's within the very nature of numbers. It's very rudimentary basic, yes, but it's already math. You are digging to the original roots of computer engineering. That's exemplary. Go on!

But if you have so much fun to shove and shift bits, then you will for sure have fun to get to the lowest, most basic level there is: Assembling language.
Using C for that is possible, and for sure educative, 'cause in some ways it's needed when you use C, since C is the closest to assembling language you can get. But using a HOL to replace an assembler is kind of abuse, putting the cart before the horse, like destilling beer to get water...
Alas Assembler on today's 64bit cores with their integrated math co-processors already look like a HOL. So, to get really down, you may either get some 8bit or 16bit machine (some used Z80 machine for example was a good choice) - need to get the according assembler for it, too.
Or look for some emulator. I don't know any, but I'm pretty sure, there will be at least one running under FreeBSD.
(Maybe somebody else reading this can recommend one. There is the MMIX for example
[ mmix-20160804_1 RISC computer designed by Donald E. Knuth], but this thing already is not that primitive anymore, and makes sense only while reading his books.)
Edit: I've just found yaze-ag, a Z80 emulator. But I don't have no experience with it at all whatsoever.

Point is: On such "primitive" 8/16bit things all you get are a few commands, like load into register, move to RAM, very primitive control, but above all besides bitshift, addition and complement no math functions at all. So you need to build all the math you need - substraction, multiplication and division - all by yourself. Having those you can do any math at all, including floating point numbers, which you simply cannot avoid. It's again just the question, if you mean to use the given float by C, or do you create your own floating point numbers. But anyway they are unavoidable. Since you cannot do math with fractions without having fractions.
I've done all this by myself on 8bit Microcontrollers, and I learned a lot that helps me much today understanding many things in HOL.

You're having so much fun in learning that things - and doing it right. Do it the engineer's way: Interested in finding out how things work, what can be done elseway, experimenting, playing...exemplary!
You are on the best way for becoming a really good programmer one day.
Just keep on that good work.

P.S.: Don't wait too long to get into debugger and version control!

 

[johnjohn]

I forgot to mention something: About 15 years ago, I was trying to learn how to program and i went to the local library to see if they had any books about programming. I found a book, so i opened up to see if it was useful to me or not. LOL it was written by Donald Knuth and almost every page had calculus mathematics. I closed the book and put it back on the shelf. I never learned calculus, so it was overwhelming information. I told my Wife this story and we had a good laugh. Donald Knuth it extremely technical. A highly intelligent man. I suppose that i should learn the basics of calculus but somehow i always manage to find (or figure out) a basic arithmetic method to do the same thing as calculus. Anyway, i remember thinking "i'm too stupid to be a programmer". I decided to learn QBasic instead.

I would never be able to learn at a university because i would fail the math tests. I am okay with math but i never learned algebra and calculus. I wrote PHP grid graph code a few years ago and i did not know how to calculate how many diagonals are in a grid graph. I searched Google but nothing was useful to me as an algorithm. I found a few documents but they only had calculus examples, which i do not understand. I spent about two days trying different things until i found a basic arithmetic way to solve my problem: (m-2) plus (n-1) or (m+n) - 3, then multiplied by 2. I bet that somewhere in that calculus code is the answer but i'll never find it, so i do the work myself.

I think that by saying 'moving numbers' that you are referring to bit shifting, yes? i am not using bit shifting, math operators or libraries. 2, for example, is so easy: parity yields the number. I just have two arrays of 0-9 digits that serve as a number index. My code allready knows the answer. I just use the array index to return the correct number(-s). the digit 3 works the same way but without parity, rather a known number pattern. No math at all. I would imagine that Donald Knuth has similar code hidden within the encoded walls of calculus I had to devise my own method.

I use addition operator with addition because - why not? it is not expensive (CPU wise) and i could easily use an array to retrieve the correct number anyway. I even found an array that will tell me if a number has overflow (a number more than my array). Numbers are fascinating in many ways and i have learned alot the past few weeks. Yes, i am having fun along the way My addition function is simply the following code:

static const char DIGITS[] = "01234567890123456789";
struct metadata {
  //other metadata structures and unions here
    union regrouping {
        uint8_t carry;
        bool borrow;
    } bank;
} md;

char add(uint8_t augend, uint8_t addend) {
    uint8_t sum = (augend + addend) + md.bank.carry;
    md.bank.carry = (sum > 9) ? 1:0;
  return DIGITS[sum];
}

I could use an array and overflow to get the number but i am simply adding digits from looping over an array, so i simply add in this case. I also subtract and multiply but i could use arrays. Division on the other hand, uses only digits 0-9 arrays (no math operators, no bit shifting, no calculating in any way. I've allready calculated answers/quotients on paper.)

I always wanted to learn how to program and i think that i am finally entering this sacred realm. I am happy and i am enjoying myself in the process. I think that MIT professors would think of me as mentally slow and mathematically challenged but i am determined to learn how to program. I like programming. I want to be successful, even if i have to do it at home in my spare time. I sometimes wish that i was a millionaire so that i could spend all of my time learning - it would be nice but the lack of money doesn't deter me at all.

You are very kind. Your words of encouragement are well recieved. Thank you, Maturin. I appreciate you and i appreciate that you do not treat me like an inferior idiot. Some people have treated me that way and i usually get attacked in online forums but you are very nice and i appreciate it. And you always go out of your way to offer sound advice. Thank you for taking time to offer advice and encouragement. I appreciate it very much.

 

[drhowarddrfine]

i always manage to find (or figure out) a basic arithmetic method to do the same thing as calculus.

All math, at its core, boils down to adding, subtracting, multiplying and dividing. In fact, even multiplying and dividing is just shortcut adding and subtracting.

 

[Maturin]

I don't know, what forums you've been before.
I also knew and turned by back on several, because many I experienced are not about sharing knowledge and exchanging ideas, but are about a handful of top dogs with serious social issues fighting for order of ranks to dominate "their place", only to endorse themselves within their narrow minded way of looking at things.
You can figure out such quickly when somebody new joins, bringing expertise and being mobbed for that.

This forums here is otherwise. It partially may be "just" because of the admins doing a real good job (thanks guys!) But it's also that the majority of the established active community (many more passive readers here than the ones regulary posting) is respecting and tolerating everybody and anything but disrespect and intolerance (thanks guys!)

There are lots of causes, why somebody is treated as an idiot, or feels like he/she's seen as one. But in most cases it's just because the idiots believe they can discriminate themselves from idiots by pointing at others as being idiots.
By all I can read what you post here, you are for sure neither inferior, nor an idiot.

You started on FreeBSD app. two years ago, coming from Windows, so at zero.
And now, already being a full steam FreeBSD user, you realize your life dream to learn programming while doing it already the right way by yourself: Program. Program what you want to program. See how things work. If not, figure out why. Etc.
Programming is like writing a book. Classes, schools or universities can teach a lot of really good things. But no class, school, teacher nor book can really teach how to write a thrilling novel. This must come from yourself. You can help that a lot by reading a lot many novels by others, and of course write a lot yourself. So, you can learn programming only by doing it and reading other's code.
And again with FreeBSD you have the perfect platform for that: Since it's unix[like] it is by its very nature already a programming environment, designed for being "programmed" by its users. And if it's just editing some config files or writing some simple shell scripts for some automation.
By my idea the original core idea of Unix once based on the understanding, that every user has individual needs what to do with a computer and how. And since there is no way to create neither a one-size-fits-all system that can fully satisfy everybody, nor can be an infinite number of different tailored systems so anybody can find the perfect fit, there can only be one actual possibility: Provide a basic system that offers the users as many possibilities to tailor their own fitting suits. Which in the end also includes programming in many different languages, depending on what you know and what you want to accomplish.
And since it's Open Source you already find a lot of source code on your machine where you can read and learn a lot, and install even more.
So, a lot of novels to read to improve your writing.

You learn. And "only" that is already prove enough for not being an idiot.
What do stupid and smart people have in common?
Both make stupid mistakes. Sometimes even really stupid.
But then what differs smart people from stupid ones?
Stupid people refuse to admit made a mistake, refuse to learn.
While smart people at least trying to not repeat the same mistakes, which starts by admitting mistakes, which starts by not blaming others for their own mistakes.
Stupid people don't ask questions, because they believe asking questions reveals them as not knowing it, so being stupid.
Smart people ask questions, because they know and admit they don't know it, but they want to know, to understand, to learn it.

A valuable lesson for life programming teached me: There is no perfection.
Becoming a better programmer doesn't mean making fewer mistakes. Sure, when you have some experience you don't do so much of the noob's errors like simple syntax errors anymore. But also those never vanish to total zero. Instead the better you become the more complex the errors become you produce. By my definition being a good programmer doesn't mean making few errors. A good programmer to me is good at finding and correcting errors.
You see, writing ad hoc a correct piece of code only proves, that you can do what you've learned so far. But it teaches you nothing new. We learn by errors made. This doesn't mean producing more errors teaches more. Having errors is nothing good. You don't need to know anything to produce errors. But finding and solving the things, that brings you forward, because this way you learn.

You are having fun at what you're doing.
That's all what counts.
Where your journey may lead you one day, nobody can tell yet.
My wife and I found many of our most favorite places not by some tourist guide or Google trip advisor, but by just losing our way or simply spontaneousely leave the road, and follow an unknown sidetrack, see where it leads to. Sure, sometimes it's "Aaargh! Where the f#34 are we?! Turn back!!" That's why most stay on the main road and follow established advisors: The fear of disappointment. We learned, not so seldom we find some nice places, a nice little restaurant or café, a nice view, often nice people, or sometimes even a small paradise. And since it's nowhere mentioned in some social media, there are no masses of idiots running there just to also been there, to "check it off" their stupid "bucket list." And that's why my wife and me will not post such locations on some social media platforms. Because we're not that stupid. Let those idiots stay on the main tracks!
Torsten Sträter once said: "Life is detours. If you always only chose the fastest, direct ways or even do shortcuts in life, you miss it. "

When the OpenSource community teached me one thing, than it's, it doesn't matter who you are, where you're from, which sex, age, religion, culture, color...education or diploma you possess. There is only one thing, and one thing only, that counts:
Can you do it, or not?
Either you write useful code, or you don't.
Nothing else matters. [Metallica]

So, "Become a Programmer, Motherfucker" [Zed A. Shaw]