As I have understood, IEEE is responsible for standardizing computer practices and POSIX is one of the standards issued by IEEE.
I wish to know what are some other standards issued by IEEE? Is there a list somewhere?
The first one that comes to mind is the standard for floating point arithmetic behavior.
A more comprehensive list is available on Wikipeda here
Have at it.
The IEEE is the Institute of Electrical and Electronics Engineers. They have promulgated several standards related to computer programming- like IEEE 754 floating point arithmetic.
Related
As SNOMED and LOINC, I read that there is another universal standard for identifying medical terms called IEEE (whose database would also include fitness/diet/environmental data which I would particularly need for the project I am working on).
My problem is that I have been searching for the codes online but I couldn't find any. Does anybody know if you need to pay to access the code database?
I never heard about IEEE as a coding system for medical information-exchange. If I have never heard of it, I have 17 years of experience in healthcare ICT, then it probably is not very well known and therefore fails in the context of interoperability.
Also, IEEE would not be a smart name for a coding system because it conflicts with IEEE as technology standard organization (https://www.ieee.org/index.html)
I'm interested in automata theory to improve my understanding of programming and compiler design (I would like to create some simple syntax's in my own projects , for example; L-Systems, AI, neural net structures and intelligent object-object conversation 'AI dialog') but there are things I need to learn before I go forward.
There are a lot of new symbols and mathematical concepts I need to learn before studying automata theory, I could not copy and paste examples because of the symbols and
I don't have the required reputation to post an image so hears a link to a wiki article.
Context-free grammar article on Wikipedia
Under the heading "Proper CFGs" you can see some definitions. I don't understand them.
Could someone please tell me what this notation is called so I can Google it. Any other pointers or information would also be helpful but just knowing a few key words will help. Also if anyone knows of a comprehensive resource that can be accessed for free e.g, an IIT Video lecture on the subject of that notation I would be eternally grateful as I
can't afford tutoring or even text books at this time.
The resource I'm using at the moment for automata theory(for anyone who is interested) is Theory of Automata IIT Lectures on YouTube.
The symbols ∀ and ∃ are logical quantifiers, respectively meaning "for all" and "there exists".
Typically you are first introduced to them in a discrete mathematics course, though they're a part of predicate logic (also known as first-order logic); in my particular university's CS program, Discrete Math is a pre-requisite for Logic for Computer Science, which in turn is a pre-requisite for Formal Languages and Automata.
The star * symbol in the term (V union Sigma)* there is studied in formal languages/automata theory itself: it is the Kleene star operator. Its input is an alphabet (a set of symbols), and it produces the set of all strings of zero or more symbols over that alphabet.
A useful tool for studying formal languages and automata is JFLAP.
This topic, at the level that you have referred to in your link, is really only for mathematicians or graduate-level theoretical computer science students. The symbols you are referring to are just symbolic logic. If you are really interested in automata theory, I would recommend trying to find resources that explore the topic from a conceptual level and avoid using complex logical statements. OR, if you really want to dive in, you can teach yourself symbolic logic, some set theory, probably some modern algebra, and then tackle automata theory from there.
I read many books on the subject of Languages and Automata, including the Dragon books on compilers (and the much more pragmatic Jack Crenshaw's Let's Write a Compiler), but none of it really clicked until I read the classic Finite and Infinite Machines by Marvin Minsky. Being an old book, it does not cover the latest research and developments in the field at all, but he explains the state-of-the-art for the 1960s in Automata, Neural Networks, Turing Machines, Functional Programming and Lambda Calculus, and the oft-neglected third wheel of String-Rewriting Systems. And the writing is exceptionally excellent and engaging. IIRC Minksy even co-authored a robot story with Isaac Asimov, so he has some serious writing credentials.
Like I say, this book will not bring you up-to-date in any of these fields, but it's the best book I've found for explaining everything from the ground up. And it would provide a very firm basis for reading anything more recent. This book is in the bibliography of every book published since.
Recently I was seeing OpenCL EP support on some development boards like odroid XU. One thing I know is that OpenCL EP is for ARM processors, but in what features will it vary from the main desktop based OpenCL.
The main differences are enumerated below (as of OpenCL 1.2):
64-bit integer support is optional.
Support for 3D images is optional.
Support for 2D image array writes is optional. If the cles_khr_2d_image_array_writes
extension is supported by the embedded profile, writes to 2D image arrays are supported.
There are some limitations on the available channel data types for images and image arrays (in particular, images with channel data types of CL_FLOAT and CL_HALF_FLOAT only support CL_FILTER_NEAREST sampler filter modes)
There are limitations on the sampler addressing modes available to images and image arrays.
There are some floating-point rounding changes that you may need to take into account.
Floating-point addition, subtraction, and multiplication will always be correctly rounded, other operations such as division and square roots have varying accuracies. There are tons of other floating-point things to watch out for as well.
Conversions between integer data types and floating point integers are limited in precision (but there are exceptions).
In short, the main differences here are in floating-point accuracy. In other words, the embedded profile need not adhere to the IEEE 754 floating-point specification, which may be a problem if you are doing lots of numerical calculations which rely on it. Quoted from the specification:
This relaxation of the requirement to adhere to IEEE 754 requirements
for basic floating- point operations, though extremely undesirable, is
to provide flexibility for embedded devices that have lot stricter
requirements on hardware area budgets.
There is also something that is not mentioned in section 10 but is worth noting: while desktop profiles must have a compiler available to compile OpenCL kernels, embedded profiles need not provide one. This can be seen through the clGetDeviceInfo documentation, which states:
CL_DEVICE_COMPILER_AVAILABLE: Return type: cl_bool
Is CL_FALSE if the implementation does not have a compiler available
to compile the program source. Is CL_TRUE if the compiler is available.
This can be CL_FALSE for the embededed (sic) platform profile only.
For a complete and detailed list of the OpenCL Embedded Profile specification, fire up your PDF reader, download the OpenCL spec (whichever version you are developing for), and find the relevant section.
The section 10 in the standard answers your question. This section is entirely dedicated to the OCL embedded profile, ans starts by enumerating the restriction that this profile implies.
I'm not sure I understand if there is a difference between a finite state machine and a state machine? Am I thinking about this too hard?
I'm not sure I understand if there is a difference between a finite state machine and a state machine? Am I thinking about this too hard?
Yes, you are thinking about it too hard. :-) It depends on context.
Obviously, taken literally, the term "finite state machine" indicates a finite number of states, while "state machine" makes no such promise. So, yes, there is a difference.
However, I think, depending on the context of the conversation, people simply say "state machine" in short-hand without consider whether they mean "finite state machine" or "state machine". And in our field of software programming, where state machines are usually represented in code, we can often use "state machine" interchangeably with "finite state machine". So, really, no, there is no difference.
OTOH, if I were talking to a mathematician after night class on campus one evening, I may be more selective about the specific terms I used. So, yes, there is a difference (in this case).
Sure there's a difference. One has a finite number of states, and the other has an infinite number of states. It's kind of awkward to draw an infinite state machine, but the math that permits a finite state machine will permit an infinite state machine, as well.
Take a look at the mathematical model section of the Wikipedia page of FSM's. See where it says 'S is a finite, non-empty set of states'? Erase 'finite'. Your state transition function will become infinite as well, but that's ok, there are a lot of infinite functions.
"From.ME.to.YOU" is conflating Wikipedia's verbal shorthand with a real proclamation of equality.
The Finite State Machine (FSM) term has a precise definition in the textbooks on Automata Theory. FSM’s allow for the most precise and compressed representation of software entities behavior as they are programming language and data representation independent.
The term state machine is often used loosely to describe a “FSM style” set of API’s like Statecharts. It is unfortunate that software engineers seldom use the full potential of FSMs as they were often burned by a host of problems plaguing Statecharts: e.g. non determinism.
No there is not
i quote from wikipedia
finite-state machine (FSM) or
finite-state automaton (plural:
automata), or simply a state machine
http://en.wikipedia.org/wiki/Finite-state_machine
Assuming you are not in a computer languages classroom, in the context of Software it is almost always a State Machine since it doesn't fit the mathematical definition of FSM (Finite State Machine). Especially when considering Business Process Management/Workflow, the number of nodes in the transition graph is finite, but the state of the process is not limited by those and has unlimited external context.
However if someone refers to FSM in software it's pedantic to point out that it doesn't meet the math definition and they are probably using that term to refer to the simpler types of state machines vs. Petri Net, BPM, Orchestration, or any number of other ways to manage states, processes, transitions, etc. There is also a huge difference from process management, persisted state machines, and the in memory kind that are used for parsing or network state, for example.
In short, it's very ambiguous if you are not in a classroom.
it's assembler right? can someone please point out the progression that we've had in programming languages since assembler to the days of asp.net, namely the chronological order of languages?
Here's a wiki timeline of all programming languages.
I would include a FTA table, but the list is very robust and extensive.
And also, the lowest language you ever get to is assembly (aside from straight up issuing machine instructions), regardless of what other language is built on top (including ASP.NET). Other languages are really just abstractions on top of assembly. In fact, ASP.NET gets compiled into IL (Intermediate Language) code, which then get's JITed into assembly. Assembly is as close to the metal as you're going to get.
To be pedantic, "assembler" is not actually a language (any more than "compiler" is;-) -- rather, it's a program that takes a source file in "assembly language" and emits binary machine code. The binary machine code can be said to be lower-level than the assembly language, since the latter allows use of some symbols and often includes a macro processing ability as well.
"Below" binary machine code, there may be other levels, known as "microcode" (but there might not be -- the CPU might be implemented entirely in real hardware, without any microprogramming aspect). That might be relevant only if the system's architecture allowed programmers to alter the microcode, especially by adding to it, etc -- there have been machines that did that, but I don't believe any currently commercialized CPU does. So you probably don't have to care about that (and the by-now-esoteric distinctions between vertical and horizontal microcode, etc, etc;-).
Programming languages are just ways to assemble solutions to computing problems.
The argument is "assembled out of what?"
From that point of view, I'd suggest the following evolutionary curve:
Napier's Bones
Babbage's difference engine
Jacquard (card) looms
(Conceptual) Abstract Turing machines/Post Systems/Church's calculus
Relay Computers (Aiken?)
Vacuum tubes as switching elements (Eniac)
Transistor-based computers
Microprogrammed machines
Integrated Circuits
Large Scale Circuits
with "assembler" being the programming language used to
put together solutions consisting of instructions for
real machines starting with the vacuum tube systems.
(I'm not sure the relay machines actually had assemblers).
Programming langauges are just ways to put together high
level commands that reduce in effect to assembler instructions.
There are two different dimensions to consider here, what I'd call vertical growth (languages build up over time from one generation to the next) and horizontal growth (syntactic improvements and reduction in complexity.)
A good explanation of vertical change is seen here: http://web.sxu.edu/rogers/sys/generations.html
And a nice, yet incomplete, illustration of horizontal change it here: http://oreilly.com/news/graphics/prog_lang_poster.pdf