Talk:Transatlantic telegraph cable

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


I think it would be useful to decide what the primary units should be, and stick to it. US units with nautical miles seem to predominate, but we've got many places where SI units are given first. And many places where "miles" are specified, but it doesn't say what kind of miles. In at least one section, "Preparing a new attempt", we use both nautical and statute miles. GA-RT-22 (talk) 22:58, 19 July 2021 (UTC)[reply]

Dead Whale[edit]

I found information about the dead Sperm Whale found tangled up in the cable. The incident was in 1932 when a cable repair ship, All America, off the Pacific coast of Columbia, dragged up a cable from 3240 feet with a 40-foot whale tangled in it. Unfortunately, the two sources that I've found are juvenile books and don't have more information. The phrasing of the Wheat book hints that there may have been more instances than the 1932 one mentioned.

  • Whales and Dolphins; G. Collins Wheat (Golden Press; 1963)
  • The Great Whales; Herbert S. Zim (1951)
There is a similar incident mentioned in Submarine communications cable where a whale got caught in a cable in the Persian Gulf in 1873. Neither of those incidents are relevant to this article, which is about a different cable. SpinningSpark 09:30, 5 March 2022 (UTC)[reply]

Number format and English variety[edit]

@Mikhail Ryazanov: Can you please explain how MOS:NUMNOTES is relevant to your recent edits? Spelling out single-digit numerals is not only an acceptable style, but is actually required by MOS:NUMERAL bullet #1. I'm also inclined to challenge the change from BritEng. The template on this talk page seems to be an undiscussed drive-by addition without any accompanying edits actually establishing American English. As far as I can see, no particular variety was established until my major reqorking in April 2020 which is unarguably in BritEng.

Although a very minor issue, I also don't much care for the removal of double sentence spacing. I believe that I have requested you before not to do that. That's given me three reasons to revert your edits. SpinningSpark 10:42, 27 August 2022 (UTC)[reply]

@Spinningspark: MOS:NUMNOTES says: "Comparable values nearby one another should be all spelled out or all in figures, even if one of the numbers would normally be written differently". If you have questions about some particular edits, please be specific.
{{American English}} has been here since 2014. I see your edits of this talk page form 2015, so you must have seen it and already had a lot of time to challenge it. I personally have no preferences and was only bringing the inconsistent spelling within the article to the style declared here. (The same applies to my edits of the dates. Although in this case I personally prefer dmy, the article says {{Use mdy dates}}, so I've changed the inconsistently formatted ones according to that.)
Removing double spacing is fine as long as it's not the only purpose of an edit, but considering it as a "reasons to revert" is definitely not acceptable (see WP:Cosmetic edit), especially since most of the article wikicode used single spacing and I, again, made only minor changes in very few places (~10 among the hundreds of sentences) for consistency.
I believe that my edits (at least the vast majority of them) are according to WP:MOS and are improvements. Thus your intention to revert them based solely on your personal taste would be considered Wikipedia:Edit warring (see also WP:OWNBEHAVIO(U)R, just in case). — Mikhail Ryazanov (talk) 15:57, 27 August 2022 (UTC)[reply]
@Mikhail Ryazanov: Sorry for the slow response, I've been busy outside Wikipedia recently. No I hadn't seen the ENGVAR banner previously. I don't read all the talk page headers every time I post on a talk page. If I had seen it, I would have done something about it at the time I made the article expansion. I know it's been there for a long time, but as I say, it was a drive-by addition without any real justification. I propose to restore this article to BRITENG and since dmy is conventional in BRITENG I will change that too. I'll wait a few days to see if others have any comments. SpinningSpark 09:52, 7 September 2022 (UTC)[reply]
I've already expressed my point of view, so no need to ping me. If you've failed to notice the style templates for so many years, it's not my problem. Ask Majoreditor and Kind Tennis Fan, who have added them in 2014, and all other users (including yourself) who have edited the article since then without questioning that choice. (And frankly, I'm surprised that all these minor issues bother you so much. Have you read WP:OWNBEHAVIOR?) — Mikhail Ryazanov (talk) 01:29, 9 September 2022 (UTC)[reply]
You seem just as bothered by "these minor issues" as I am. Please don't turn a content disagreement into a behavioural issue. Your behaviour in not giving way is very much on a par. If you think it's that minor you shouldn't be bothered about not getting your way. SpinningSpark 17:35, 11 September 2022 (UTC)[reply]


I'm breaking this out into a new section because it is a quite separate issue and makes it easier to discuss. You wrote "MOS:NUMNOTES says: "Comparable values nearby one another should be all spelled out or all in figures, even if one of the numbers would normally be written differently". If you have questions about some particular edits, please be specific."

I don't see your changes as being "comparable values". MOS:NUMNOTES gives examples of numbers in a list of things of the same kind. For instance, The cable consisted of seven copper wires is not comparable, in the sense of NUMNOTES, with the the cable strands weighing 26 kg/km. The two things are "nearby" but they are not being compared. All of your changes are similar, two figures that are not being compared forced into all numerals. We even have from MOSNUM Adjacent quantities not comparable should ideally be in different formats. There are no examples of this kind in the article, but it is relevant as it shows that MOSNUM is quite happy with nearby non-comparable items being in different formats. SpinningSpark 10:08, 7 September 2022 (UTC)[reply]
I think that "7 copper wires" and "18 strands, each of 7 iron wires" discuss "comparable values". The various numbers of "words a/per minute" are even more comparable (they are, literally, compared in the article text). "Adjacent quantities" in MOS:NUMNOTES means directly adjacent numbers, as in the examples there. You can clarify at WT:MOSDATE. Or consult at WP:RD/L whether spelling out some or all numbers in these cases would improve the readability (I don't think so). — Mikhail Ryazanov (talk) 01:29, 9 September 2022 (UTC)[reply]
I don't agree with you, the two parts of the cable construction are not being compared and are not in a comparative list. Technically, comparing them is meaningless, the two parts serve entirely different functions. The steel wire armour is what makes it a cable and is for mechanical protection. The copper cores are for electrical transmission. They are made in two entirely separate factories. The words per minute figures are being compared, but they are not nearby with any sensible meaning of the term. They are not even in the same paragraph. SpinningSpark 18:17, 19 September 2022 (UTC)[reply]

Conditions for sufficiently low dispersion[edit]

Except for the heaviside condition, the article fails to mention how improvements to the cable construction reduced dispersion or improved throughput. The article also fails to tell when the heaviside condition was first met.

@User:Constant314 suggested other conditions exist, but what are they? Comfr (talk) 01:32, 14 April 2023 (UTC)[reply]

The condition has never been met on any cable anywhere. It is a hypothetical solution that only applies when R, C, G, and L are constants that are independent of frequency. That never happens. No where close. Constant314 (talk) 02:32, 14 April 2023 (UTC)[reply]
I see what you mean—Heaviside is a theoretical solution for a specific frequency. The section Transatlantic_telegraph_cable#Communication_speeds identifies only Heaviside as contributing to lower dispersion, implying that Heaviside was the main solution to the problem. The ISCPC reference is not a reliable reference and does not support the contents of the paragraph in which it is used. Do you have a reference to support your statement, " The conditions for sufficiently low dispersion are far less stringent than the heaviside condition."? If so, I would like to improve the article by telling readers how transmission speed was increased. Thanks for alerting me about the limitations of Heaviside. Comfr (talk) 12:26, 14 April 2023 (UTC)[reply]
Well, after Heaviside made his analysis, he suggested adding inductance. He was on the right track for low frequency transmission lines such as were used for telegraphy. Unfortunately, he was ignored and even ridiculed. His analysis made no contribution to the solution. It should have. The technology would have advanced faster. But it didn't. The added inductance solution was discovered independently by others. The following is speculation: at the frequencies used for communication by the trans-Atlantic telegraph cable, the transmission line can readily be analyzed as a multi-section, LCR filter. The theory of these filters was well developed by the early 20th century. From that analysis, it would be obvious that an increase in inductance was needed. Again, that is my speculation. I have read brief excerpts from discussions from back then. Unfortunately, the jargon has changed, but is sounded to me like they were talking about the theory of electrical filters.
The requirement for acceptable dispersion is simply to have a sufficiently constant velocity (or constant group delay) in the band of use. At telegraphy frequencies, this can be achieved by adding inductance, but nowhere near as much inductance as would be required to reach the Heaviside condition. Modern cables have mostly constant velocities at frequencies above a few MHz, hence no added inductance needed for high bit rate data.
I plan to open a discussion on Heaviside condition and would like to invite you to continue the discussion there. Constant314 (talk) 13:31, 14 April 2023 (UTC)[reply]