User:Wittawin Panta/sandbox

= รายการสถานที่ท่องเที่ยวในกรุงบูดาเปสต์ =

สถานที่ท่องเที่ยวที่น่าสนใจในกรุงบูดาเปสต์โดยแบ่งตามเขตเมือง

โบสถ์

 * มหาวิหารเซนต์อิชต์วาน St. Stephen's Basilica, the biggest church (1905).
 * โบสถ์แมทเธียส Matthias Church, the oldest church (1015).
 * โบสถ์ลูเธอรัน ณ จตุรัสแดอาก Lutheran Church of Deák Square, the biggest Protestant church (1799–1808).
 * โบสถ์โปรแตสแตนท์ ณ จตุรัสคาลวิน Reformed Church of Kálvin Square, the most famous Reformed church (1816–1830).
 * โบสถ์แมรี มักดาเลน Church of Mary Magdalene, ruins of the oldest churches (ca. 13th century).
 * โบสถ์ถนนโดฮาญ Dohány Street Synagogue, โบสถ์ยิวที่ใหญ่ที่สุดในทวีปยุโรป (ค.ศ. 1854–1859).
 * Inner City Parish Church in Pest (ca. 14th century).
 * Saint Peter of Alcantara Franciscan Church (ca. 1241).
 * Palace Chapel (ca. 15th century)
 * University Church (1715–1771).
 * Gellért Hill Cave, national chancel (1931).
 * Saint Anne Parish (1761).
 * St. Catherine of Alexandria Church (1749).
 * St Elizabeth of the House of Arpad Parish Church (1895–1901).
 * Our Lady of the Snows Parish Church (1694).
 * Church of Stigmatisation of Saint Francis (1757).
 * Szilágyi Dezső Square Reformed Church (1894–1896).
 * Lutheran Church of Budavár, the oldest Lutheran church of Buda (1895).
 * Tomb of Gül Baba, northernmost Islamic pilgrimage site in the world (1543–1548).
 * โบสถ์ยิวถนนรุมบาค Rumbach Street Synagogue (1869–1872).

สะพาน

 * สะพานอาร์ปาด (Árpád Bridge ), the busiest bridge (1950)
 * สะพานมอร์กิต (Margit Bridge ), the second oldest bridge (1876)
 * สะพานโซ่เซแชนยี (Széchenyi Chain Bridge ) the oldest and most famous bridge (1849)
 * สะพานแอร์เจแบ็ต (Erzsébet Bridge ) built across the narrowest part of the Danube (1903)
 * สะพานเสรีภาพ (Liberty Bridge ) the third oldest bridge (1896)
 * สะพานแปเตอฟี (Petőfi Bridge ) (1937)
 * สะพานราโคตซี (Rákóczi Bridge ) (1995)

Navigation menu

 * Wittawin Panta
 * Alerts (5)
 * Notices (9)
 * Talk
 * Sandbox
 * Preferences
 * Beta
 * Watchlist
 * Contributions
 * Log out


 * Article
 * Talk


 * Read
 * Edit source
 * View history
 * Watch

More



 * Main page
 * Contents
 * Current events
 * Random article
 * About Wikipedia
 * Contact us
 * Donate

Contribute

 * Help
 * Learn to edit
 * Community portal
 * Recent changes
 * Upload file

Tools

 * What links here
 * Related changes
 * Special pages
 * Page information
 * Wikidata item

Languages

 * Privacy policy
 * About Wikipedia
 * Disclaimers
 * Contact Wikipedia
 * Mobile view
 * Developers
 * Statistics
 * Cookie statement



* Category:Articles with example pseudocode

ประวัติศาสตร์หลัง ค.ศ.1970
History (post-1970)

Computer chips
หลังจากการประดิษฐ์ชิปวงจรรวมแบบโมโนลิทิก (Integrated circuit; IC) ในปี ค.ศ.1959 โดย Robert Noyce ที่ Fairchild และ MOSFET (ทรานซิสเตอร์ MOS) โดย Mohamed Atalla และ Dawon Kahng ที่ Bell Labs Atalla ได้เสนอแนวคิดของวงจรรวม MOS (MOS integrated circuit; MOS IC) เป็นครั้งแรก ในปี ค.ศ.1960 จากนั้น MOS IC เชิงพาณิชย์เครื่องแรกได้มีการจัดจำหน่ายโดย General Microelectronics ในปี ค.ศ.1964 การพัฒนา MOS IC นำไปสู่การประดิษฐ์ไมโครโปรเซสเซอร์โดยรวมฟังก์ชันของหน่วยประมวลผลกลาง (CPU) ของคอมพิวเตอร์ไว้ในวงจรรวมเดียว. ไมโครโปรเซสเซอร์ชิปเดี่ยวตัวแรกคือ Intel 4004 ซึ่งออกแบบและผลิตโดย Federico Faggin ร่วมกับ Ted Hoff, Masatoshi Shima และ Stanley Mazor ที่ Intel ในปี 1971 ในเดือนเมษายนปี 1974 Intel ได้เปิดตัว Intel 8080 ซึ่งเป็น "คอมพิวเตอร์บนชิป" "ไมโครโปรเซสเซอร์ตัวแรกที่ใช้งานได้จริง"

Following the 1959 inventions of the monolithic (IC) chip by  at Fairchild, and the  (MOS transistor) by  and  at Bell Labs, Atalla first proposed the concept of the  (MOS IC) chip in 1960, and then the first commercial MOS IC was introduced by  in 1964. The development of the MOS IC led to the invention of the microprocessor, incorporating the functions of a computer's central processing unit (CPU) on a single integrated circuit. The first single-chip microprocessor was the Intel 4004, designed and realized by Federico Faggin along with Ted Hoff, Masatoshi Shima and Stanley Mazor at Intel in 1971. In April 1974, Intel released the Intel 8080, a "computer on a chip", "the first truly usable microprocessor".

Homebrew Computer Club
The Homebrew Computer Club was an informal group of electronic enthusiasts and technically minded hobbyists who gathered to trade parts, circuits, and information pertaining to DIY construction of computing devices. It was started by Gordon French and Fred Moore who met at the Community Computer Center in Menlo Park. They both were interested in maintaining a regular, open forum for people to get together to work on making computers more accessible to everyone.

The first meeting was held as of March 1975 at French's garage in Menlo Park, San Mateo County, California; which was on occasion of the arrival of the MITS Altair microcomputer, the first unit sent to the area for review by People's Computer Company. Steve Wozniak and Steve Jobs credit that first meeting with inspiring them to design the original Apple I and (successor) Apple II computers. As a result, the first preview of the Apple I was given at the Homebrew Computer Club. Subsequent meetings were held at an auditorium at the Stanford Linear Accelerator Center.

Venture capital
By the early 1970s, there were many semiconductor companies in the area, computer firms using their devices, and programming and service companies serving both. Industrial space was plentiful and housing was still inexpensive. Growth during this era was fueled by the emergence of venture capital on Sand Hill Road, beginning with Kleiner Perkins and Sequoia Capital in 1972; the availability of venture capital exploded after the successful $1.3 billion IPO of Apple Computer in December 1980. Since the 1980s, Silicon Valley has been home to the largest concentration of venture capital firms in the world.

In 1971 Don Hoefler traced the origins of Silicon Valley firms, including via investments from Fairchild's eight co-founders. The key investors in Kleiner Perkins and Sequoia Capital were from the same group, directly leading to Tech Crunch 2014 estimate of 92 public firms of 130 related listed firms then worth over US$2.1 Trillion with over 2,000 firms traced back to them.

การออกเสียง

ตารางต่อไปนี้คือการออกเสียงอักษรฮังการีตามหลักภาษาฮังการีมาตรฐาน ตัวอักษร ë ไม่ได้เป็นส่วนหนึ่งของชุดตัวอักษรฮังการี อย่างไรก็ตาม นักภาษาศาสตร์ใช้ตัวอักษรนี้เพื่อจำแนกความต่างระหว่างเสียง e สั้น สองชนิด (แอะ และ เอะ) ในบางภาษาถิ่นของภาษาฮังการี มีการใช้อักษรนี้ครั้งแรกในปี ค.ศ. 1770 โดยเยิดย์ ก็อลมาร์ (György Kalmár) แต่อักษรนี้ไม่เคยเป็นส่วนหนึ่งของชุดตัวอักษรฮังการีมาตรฐาน เนื่องจากในภาษาฮังการีมาตรฐานไม่ได้จำแนกความต่างระหว่างเสียงทั้งสองนี้ (อย่างที่ในภาษาไทยแยกเสียง แอะ และ เอะ ออกจากกัน) อย่างไรก็ตาม เสียง ë (เอะ) ออกเสียงต่างจากเสียง e (แอะ) ในภาษาถิ่นของภาษาฮังการี 6 ภาษาจาก 10 ภาษา และออกเสียงอย่าง ö (เออะ) ในภาษาถิ่นของภาษาฮังการี 1 ภาษา (ภาษาถิ่นทรานซิลเวเนีย)

ทวิอักษร ch ยังปรากฏอยู่ในบางคำ (เช่น [technika] error: : text has italic markup (help), [monarchia] error:  : text has italic markup (help)) และออกเสียงเหมือนกับ h ส่วนในวิสามานยนาม ch จะออกเสียงเหมือน cs หรือบางครั้งออกเสียงเป็น h หรือ k (แบบภาษาเยอรมัน)

การเขียนแบบเดิม ที่ยังใช้ในชื่อเฉพาะและเอกสารทางประวัติศาสตร์
การเขียนแบบดั้งเดิม (บางส่วนมีความใกล้เคียงกับการเขียนแบบเยอรมัน) มีการใช้ในชื่อเฉพาะที่เป็นภาษาฮังการี โดยตารางด้านล่างจะเปรียบเทียบการเขียนแบบดั้งเดิม กับการอ่านออกเสียงแบบปัจจุบัน ตามการสะกดของภาษาฮังการีมาตรฐาน ดังนี้: [1] โดยทั่วไปแล้ว ตัว y ในการเขียนแบบดั้งเดิมนั้น มักจะอ่านเป็น i ในการอ่านแบบปัจจุบัน (ตย..: Teleky, Rákóczy, Dézsy). ด้านล่างนี้คือตัวอย่างการอ่านด้วยหลักปัจจุบัน ที่มักจะมีการอ่านผิด เนื่องจากการสะกดที่ใช้หลักต่างจากปัจจุบัน มักพบในชื่อนามสกุล

ตัวอย่าง: บทความนี้มีจุดประสงค์หลักในการแยกความเหมือนและความแตกต่างของกระบวนทัศน์การเขียนโปรแกรม (programming paradigms) ต่าง ๆ as a summary in both graphical and tabular format with links to the separate discussions concerning these similarities and differences in extant Wikipedia articles.

กระบวนทัศน์การเขียนโปรแกรม
การเขียนโปรแกรมมีกระบวนทัศน์วิธีการเขียนโปรแกรมหลัก ๆ อยู่ 2 แบบ:


 * การเขียนโปรแกรมแบบอิมพาราทีฟ (Imperative programming) – โฟกัส focuses on how to execute, defines control flow as statements that change a program state.
 * การเขียนโปรแกรมแบบดีแคลราทีฟ (Declarative programming – โฟกัส focuses on what to execute, defines program logic, but not detailed control flow.

The following are widely considered the main programming paradigms, as seen when measuring programming language popularity:


 * การเขียนโปรแกรมแบบโปรซีเจอร์ (Procedural programming, structured programming) – specifies the steps a program must take to reach a desired state.
 * Functional programming – treats programs as evaluating mathematical functions and avoids state and mutable data
 * Object-oriented programming (OOP) – organizes programs as objects: data structures consisting of datafields and methods together with their interactions.

The following are common types of programming that can be implemented using different paradigms:


 * Event-driven programming – program control flow is determined by events, such as sensor inputs or user actions (mouse clicks, key presses) or messages from other programs or threads.
 * Automata-based programming – a program, or part, is treated as a model of a finite state machine or any other formal automaton.
 * Reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change.

The subroutines that implement OOP methods may be ultimately coded in an imperative, functional, or procedural style that may, or may not, directly alter state on behalf of the invoking program. There is some overlap between paradigms, inevitably, but the main features or identifiable differences are summarized in this table:

ความแตกต่างในนิรุกศาสตร์
Despite multiple (types of) programming paradigms existing in parallel (with sometimes apparently conflicting definitions), many of the underlying fundamental components remain more or less the same (constants, variables, datafields, subroutines, calls etc.) and must somehow thus inevitably be incorporated into each separate paradigm with equally similar attributes or functions. The table above is not intended as a guide to precise similarities, but more of an index of where to look for more information, based on the different naming of these entities, within each paradigm. Further complicating matters are non-standardized implementations of each paradigm, in many programming languages, especially languages supporting multiple paradigms, each with its own jargon.

ภาษาที่สนับสนุน
Syntactic sugar is the sweetening of program functionality by introducing language features that facilitate a given usage, even if the end result could be achieved without them. One example of syntactic sugar may arguably be the classes used in object-oriented programming languages. The imperative language C can support object-oriented programming via its facilities of function pointers, type casting, and structures. However, languages such as C++ aim to make object-oriented programming more convenient by introducing syntax specific to this coding style. Moreover, the specialized syntax works to emphasize the object-oriented approach. Similarly, functions and looping syntax in C (and other procedural and structured programming languages) could be considered syntactic sugar. Assembly language can support procedural or structured programming via its facilities for modifying register values and branching execution depending on program state. However, languages such as C introduced syntax specific to these coding styles to make procedural and structured programming more convenient. Features of the language C# (C Sharp), such as properties and interfaces, similarly enable no new functions, but are designed to make good programming practices more prominent and natural.

Some programmers feel that these features are unimportant or even frivolous. For example, Alan Perlis once quipped, in a reference to bracket-delimited languages, that "syntactic sugar causes cancer of the semicolon" (see Epigrams on Programming).

An extension of this is the syntactic saccharin, or gratuitous syntax that does not make programming easier.

เปรียบเทียบประสิทธิภาพการทำงาน
In total instruction path length only, a program coded in an imperative style, using no subroutines, would have the lowest count. However, the binary size of such a program may be larger than the same program coded using subroutines (as in functional and procedural programming) and would reference more non-local physical instructions that may increase cache misses and instruction fetch overhead in modern processors.

The paradigms that use subroutines extensively (including functional, procedural, and object-oriented) and do not also use significant inline expansion (inlining, via compiler optimizations) will, consequently, use a larger fraction of total resources on the subroutine linkages. Object-oriented programs that do not deliberately alter program state directly, instead using mutator methods (or setters) to encapsulate these state changes, will, as a direct consequence, have more overhead. This is because message passing is essentially a subroutine call, but with three added overheads: dynamic memory allocation, parameter copying, and dynamic dispatch. Obtaining memory from the heap and copying parameters for message passing may involve significant resources that far exceed those needed for the state change. Accessors (or getters) that merely return the values of private member variables also depend on similar message passing subroutines, instead of using a more direct assignment (or comparison), adding to total path length.

Managed code
For programs executing in a managed code environment, such as the .NET Framework, many issues affect performance that are significantly affected by the programming language paradigm and various language features used.

Pseudocode examples comparing various paradigms
A pseudocode comparison of imperative, procedural, and object oriented approaches used to calculate the area of a circle (πr²), assuming no subroutine inlining, no macro preprocessors, register arithmetic, and weighting each instruction 'step' as only 1 instruction – as a crude measure of instruction path length – is presented below. The instruction step that is conceptually performing the state change is highlighted in bold typeface in each case. The arithmetic operations used to compute the area of the circle are the same in all three paradigms, with the difference being that the procedural and object-oriented paradigms wrap those operations in a subroutine call that makes the computation general and reusable. The same effect could be achieved in a purely imperative program using a macro preprocessor at only the cost of increased program size (only at each macro invocation site) without a corresponding pro rata runtime cost (proportional to n invocations – that may be situated within an inner loop for instance). Conversely, subroutine inlining by a compiler could reduce procedural programs to something similar in size to the purely imperative code. However, for object-oriented programs, even with inlining, messages still must be built (from copies of the arguments) for processing by the object-oriented methods. The overhead of calls, virtual or otherwise, is not dominated by the control flow alteration – but by the surrounding calling convention costs, like prologue and epilogue code, stack setup and argument passing (see here for more realistic instruction path length, stack and other costs associated with calls on an x86 platform). See also here for a slide presentation by Eric S. Roberts ("The Allocation of Memory to Variables", chapter 7) – illustrating the use of stack and heap memory use when summing three rational numbers in the Java object-oriented language.

บทความเพิ่มเติม

 * "A Memory Allocator" by Doug Lea
 * "Dynamic Memory Allocation and Linked Data Structures" by (Scottish Qualifications Authority)
 * "Inside A Storage Allocator" by Dr. Newcomer Ph.D

ลิงก์ภายนอก

 * Comparing Programming Paradigms by Dr Rachel Harrison and Mr Lins Samaraweera
 * Comparing Programming Paradigms: an Evaluation of Functional and Object-Oriented Programs by Harrison, R., Samaraweera, L. G., Dobie, M. R. and Lewis, P. H. (1996) pp. 247–254. ISSN 0268-6961
 * "The principal programming paradigms" By Peter Van Roy
 * "Concepts, Techniques, and Models of Computer Programming" (2004) by Peter Van Roy & Seif Haridi, ISBN 0-262-22069-5
 * The True Cost of Calls- from "Harder, Better, Faster, Stronger" blog by computer scientist Steven Pigeon