Talk:Arbitrary-precision integers (included): Difference between revisions
Content added Content deleted
| Line 27: | Line 27: | ||
:Ah well. It seems to me that the point of the task is to demonstrate the ''in-built'' facilities for arbitrary-precision integers, with however allowance for the existence of some library extension so routinely available at every installation that everyone would already be using it for such tasks. If the required number size had not been so large, the IBM1620 would have managed, but perhaps modernists with ibmpc-monocuture aren't interested. Evidently, any language can be extended to present such facilities, but the specification explicitly rejects developing such a library. If in Fortran's case there are three such libraries, and (as it appears from the above) different verbiage is required to employ each for the same calculation, we would find ourselves comparing such libraries rather than the in-built features of different languages. [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 10:29, 13 November 2016 (UTC) |
:Ah well. It seems to me that the point of the task is to demonstrate the ''in-built'' facilities for arbitrary-precision integers, with however allowance for the existence of some library extension so routinely available at every installation that everyone would already be using it for such tasks. If the required number size had not been so large, the IBM1620 would have managed, but perhaps modernists with ibmpc-monocuture aren't interested. Evidently, any language can be extended to present such facilities, but the specification explicitly rejects developing such a library. If in Fortran's case there are three such libraries, and (as it appears from the above) different verbiage is required to employ each for the same calculation, we would find ourselves comparing such libraries rather than the in-built features of different languages. [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 10:29, 13 November 2016 (UTC) |
||
::True. But then remove also the C and Ada entries, and probably others as well. Oh, wait, the point of this comment was to show that it would be necessary then to add a task to allow external libraries, since many languages don't have builtin multiprecision. It was already stated by Michael Mol in 2010 above. Now, what's most useful? A long talk about the IBM 1620, a computer from 1959 that has nothing to do with modern Fortran, or a way to do multiprecision computations in Fortran today? I am interested in history, but I am definitely interested first in practical way to do things right now: programming is not primarily about history. But, if really asking to slightly change the task (so that some entries become conformant, and not only Fortran), is too much, then I'll copy-cut to create a new task to allow this. I don't think it's particularly wise though. [[User:Arbautjc|Arbautjc]] ([[User talk:Arbautjc|talk]]) 11:41, 13 November 2016 (UTC) |
::True. But then remove also the C and Ada entries, and probably others as well. Oh, wait, the point of this comment was to show that it would be necessary then to add a task to allow external libraries, since many languages don't have builtin multiprecision. It was already stated by Michael Mol in 2010 above. Now, what's most useful? A long talk about the IBM 1620, a computer from 1959 that has nothing to do with modern Fortran, or a way to do multiprecision computations in Fortran today? I am interested in history, but I am definitely interested first in practical way to do things right now: programming is not primarily about history. But, if really asking to slightly change the task (so that some entries become conformant, and not only Fortran), is too much, then I'll copy-cut to create a new task to allow this. I don't think it's particularly wise though. [[User:Arbautjc|Arbautjc]] ([[User talk:Arbautjc|talk]]) 11:41, 13 November 2016 (UTC) |
||
:::I note the remarks in the Algol68 example about strictly speaking, and so therefore, those entries that involve external features or explicit routines for performing multi-precision should indeed be ejected as not conforming to the task's statement, strictly. Otherwise, we face mere variations of something like <include library>...<eval(5^4^3^2)> with specious differences not elucidating the language facilities. Entries for the likes of Alore and bc amount to that but without the "include" because the necessary facilities are built-in to the language. Only some libraries amount to being a part of the language, as with C's stdio.h. I'm interested in the historical changes in a language as features are introduced or removed and generality is attained or implemented with limits - so no INTEGER*2000 for example, even though in principle this could be allowed, somewhat as in Algol68 - and was amused by the thought that the IBM1620 could perhaps have succeeded, and the IBM1403 also? These represent a possible development path in this matter that was not taken and anyone interested in language comparison would be interested in such decisions. As for what's more useful, someone seeking to solve such a problem "right now" via perusal of RC to select a language for immediate use would want to know which languages had built-in facilities or not. And reading the task description, would expect to see just that, and if for example bc was available, success would be moments away. But with libraries required there would be a delay, unless the library was overwhelmingly available so as to seem a part of the language and even more delay for supplied routines. Thus I am speaking against the inclusion of libraries or specially-written routines, as per the task specification for this specific task. |
|||
:::As for organising another task with or without this or that, I leave that to others as already, many flowers bloom and I wander without guide. There does not seem to be a facility for grouping related tasks, or multiple parts of a larger task, or even cross-referencing tasks. Just a flat list of tasks ordered alphabetically and with not always helpful choices of the first word. A tree-structure? But the A.B.etc, B.X.etc ordering won't work when it is not clear which should be the first-level keywords. This is a matter for the design of RC's presentation, which I know little about, and I see a lot of scope for disagreement. [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 07:09, 14 November 2016 (UTC) |
|||
== Criteria for Non-Draft? == |
== Criteria for Non-Draft? == |
||