User talk:Adrianwn

Welcome to my talk page. Please adhere to the talk page guidelines and particularly the following:

Please post your new topic at the bottom of this page.
Please sign and date your entry by inserting "~~~~" at the end.
Please specify a descriptive "Subject/headline" for a new topic and separate subtopics by ===heading=== lines, if needed.
Please indent your posts with one more ":" than what you are replying to, i.e. begin with ":" if replying to an existing topic and "::" if replying to a reply.

I will generally respond here to comments that are posted here, rather than replying via your Talk page (or the article Talk page, if you are writing to me here about an article), so you may want to watch this page until you are responded to, or specifically let me know where you'd prefer the reply.

Adding back a link that I created to the TRUE history of spreadsheets[edit]

You deleted a (longstanding) link to the TRUE history of spreadsheets (as I predicted about two years ago would eventually happen). You also deleted a new link I recently added - pointing to a YOUTUBE video personal testimony supporting the earlier link. You have now helped to entirely remove all references to the genuine history of spreadsheets on Wikipedia. This leaves the fictitious history of spreadsheets (from 1979 onwards) as the only information on Wikipedia - further adding to the public view that what is to be found on Wikipedia is not valid/true. Congratulations, Well done, Bravo ! Of course, if you now added back the links yourself, it would not be me that added them back (and so the links to my material published elsewhere on the web would presumably be OK!) It's your decision - truth or falsehood, fact or fiction. The truth will out eventually ken (talk) 09:28, 19 May 2010 (UTC)[reply]

Wikipedia is not a place to publish your original research or to promote your personal views. For further information, see Verifiability, Original Research and External Links. If you have further questions or objections, please feel free to discuss them on the talk page of the Spreadsheet article. – Adrianwn (talk) 10:44, 19 May 2010 (UTC)[reply]

Life is too short to argue this point. Let it lie (literally) —Preceding unsigned comment added by Kdakin (talk • contribs) 13:29, 19 May 2010 (UTC)[reply]

Thanks for the tip![edit]

Under the star... well hidden! But now I know where it is! Thanks. --FvdP (talk) 20:58, 19 May 2010 (UTC)[reply]

Comparison of programming paradigms - paradox of objects devoid of methods[edit]

The paradox I was referring to was the fact that - since an OOP object is defined as "data plus its method(s)" - when those methods are no longer around (e.g. after serialization), they are still regarded as (distributed) "objects". Whether a class method (i.e. applying to all the objects in the class) or an instance method (applying to just one instance) has no bearing on the paradox. The method(s) that were hitherto regarded as an essential part of the object have disappeared. The ubiquitous "Timmie the dog" (or sometimes Lassie) carries his barks around with him and Colt45's carry their firing mechanism too. An iphone containing a friends phone number (the data) can be activated by pressing the "call" button. Once the phone number is written to a piece of paper, the method changes (find a phone box & insert money , find a landline or another mobile, type in the number). The data can be changed, burnt or thrown away - without invoking any of these new methods - and even the memory of the number fades over time.

To use your own line of reasoning, if class methods are the reason why serialization "abandons" methods - precisely what is it about these class methods that cannot be serialized along with their class objects? Is it that there is, as yet, no fully portable (i.e. platform, language and paradigm independent) method? Is it that serializing methods with data would cause down-the-line versioning problems? Or could it be simply that artificially combining data and methods is a bad idea in the first place (except in environments that persist and have real substance)?

Of course, I might be wrong to look at it this way, in which case, how should I look at it in your opinion?ken (talk) 07:51, 23 May 2010 (UTC)[reply]

There are at least two reasons why this is not a paradox:

The pragmatical one: serializing all the methods of an object together with its data is extremely wasteful. If a collection of objects of the same type is serialized, it would suffice to save their methods only once. If an object is serialized, only to be deserialized by the same program, it would suffice not to save its methods at all. Furthermore, there are the reasons you already mentioned: versioning (maybe the deserializing program has a new implementation with fewer bugs. Besides, if you serialize an object x of type T1, and the deserializing programm has extended T1 by other methods, what type should object x have after deserialization?) and compatibility (the deserializing program has to be able to execute the language of the method, which might be far from trivial).
The ideological one: serializing an object results in its representation (not in an object). In order to use this data in a computation, it has to be deserialized again, creating an object that is identical to the original. Thus, there never exists an object without its associated methods.

Either way, I don't see any paradox, altough I must admit that I have not thought about it in depth. However, if your point of view is shared by at least a significant minority of computer scientists, you can add it provided that you cite verifiable, notable sources (in this case, however, Serialization would be a better place for this). – Adrianwn (talk) 10:07, 23 May 2010 (UTC)[reply]

I just thought of another reason: although objects combine methods and data logically, they don't have to combine them physically. So as long as the serialized data describes the type of the original object, methods and data will still be an entity. Think of it this way: the type description contains a pointer to a list of methods belonging to the respective object. – Adrianwn (talk) 10:17, 23 May 2010 (UTC)[reply]

Unlike you ("..I must admit that I have not thought about it in depth"), I have thought about it in depth and always knew there was something deeply suspicious about objects and OOP in general. It is only recently that I put my finger on one of the things that disturbed me - persistence. A well designed database can physically tie together data and programs/subroutines/methods - because it is one unit and persists beyond the scope of any one program. As I see it, OOP programs attempt to build a temporary "memory resident" version of this idealized database with the same attributes but fail precisely because the methods are not properly encapsulated (as with a serialized/distributed "object") as claimed.

I deliberately ommitted to say that serializing method(s) might be extremely wasteful - so you would then see it for yourself (so I wouldn't have to convince you of it). I was of course aware that a class method would have to be serialized only once (for each version). Your observation about deserialization for the same program was also deliberately ommitted so I could then make the point about code re-use being spurious - particularly regarding distributed systems. The other, more complex, arguments that you raised strengthens my larger comment about OOP being a bad idea in the first place.

Your "ideological argument" is really my precise point concerning the paradox: namely that "there never exists an object without its associated methods", so serialization destroys an OO object. "A pointer to a list of methods belonging to the respective object" is not the same as a series of serialized methods. There is definitely a requirement for physical connectiveness whatever you say (just as a disembodied bark from some "quantum entangled" dog might be somewhat disturbing if it was actually experienced)

Your final point "they don't have to combine them physically....methods and data will still be an entity" is sheer nonsense. How can you predict or resurect the precise logic of a method from a type?

By the way, the versioning problem (related to structures at least) is one I have long had my own solutions for but, so far, has not, apparently, been solved by the general IT community. It could easily be extended to versioning of methods and would support platform independence - but why try to support a failed paradigm that has so many problems already?

I note that you have already abandoned discussing my other wikipedia edits (spreadsheet, JIT etc etc) for reasons I don't agree with but do understand. It is just somewhat sad to see the population so misled by the volume of tripe on wikipedia without some corrections. Shovelling s*** uphill is however very exhaustive. —Preceding unsigned comment added by 86.142.18.55 (talk) 16:10, 23 May 2010 (UTC)[reply]

To be frank, I don't care whether you like OOP or not, and I'm not in the mood to discuss this topic in length with you (I could argue that your counter arguments to mine are flawed, you claim that they are not, and so on – but I have more interesting things to do). Fact is, you can't use Wikipedia to promote your personal point of view if you can't back it up with notable, reliable sources. You know that, and we have been over that.

Regarding me having "already abandoned discussing [your] other wikipedia edits (spreadsheet, JIT etc etc) for reasons [you] don't agree with but do understand": indeed I have, because there is nothing more to discuss. You know that your links and content were original research and self published material, and you know the policies on that. That's all there is to it. If you don't like it, you can always try to change the respective policies. – Adrianwn (talk) 05:43, 24 May 2010 (UTC)[reply]

To my mind, the paradox is self evident. Let it lie however - for others to discover for themselvesken (talk) 09:49, 24 May 2010 (UTC)[reply]

Exactly – to your mind. I've searched the web for your alleged paradox, and I haven't found anything supporting your point of view. If you're so convinced of it, why don't you publish it? But please don't do it on Wikipedia. – Adrianwn (talk) 10:52, 24 May 2010 (UTC)[reply]

KiBs & GiBs[edit]

Your NTFS edit is moving in the wrong direction. The sources quoted all use binary units KB, MB, GB (see discussion page). Also, Windows reports sizes using binary units, not decimal, making your change all the more inconsistent and distracting. Please make your changes consistent w/ WP:COMPUNITS. Thanks. Jeberle (talk) 19:00, 31 May 2010 (UTC)[reply]

You do have a point, and I thought about it for a while (and tried keeping a neutral POV the best I could). However, keep in mind that WP:MOS is a guideline, not a policy, and should be ignored whenever it is in the way of improving Wikipedia. In my personal opinion, this is the case, for the following reasons:

Most of the other filesystem articles already use binary prefices.
It is immediately clear what is meant, in contrast to the ambiguous unit prefices.
The argument that Windows reports sizes using the lettes "MB" instead of "MiB" is not a strong one, since a) there are other OS that support NTFS at least partially, and b) this is not an article about the Windows Explorer, but about a filesystem, and the displaying of some number together with its unit is entirely up to the userspace tools.

In my opinion, WP:COMPUNITS has to be reworked, for several reasons, one of them being that there does not seem to be a community consensus on this topic. After all, guidelines should follow consensus, not the other way around. I suggest that we all take a step back, and stop edit warring for a while. – Adrianwn (talk) 05:34, 1 June 2010 (UTC)[reply]

Your neutral POV is appreciated. I will try to maintain the same.

Point 1, Not necessarily. Do you have stats?
Point 2, Agree. More on that in a bit
Point 3, Factoring in the 1/1,000,000,000 counter example, yes, agreed.

Apologies for using your page to detail my own thinking. If there's a better forum for this, please let me know.

I too thought about this a while before responding. My argument can be boiled down to this. Byte units will always be ambiguous. Sometimes it's convenient to speak in terms of decimal units and sometimes it's convenient to speak in terms of binary units. I hope this is not too great an axiom to claim, so I'll spare you the details.

Somewhat OT, but I tracked down this illusion. Necker Cube. It's how I see the binary/decimal debate.

The question then is how to make clear what units one is using—how to disambiguate. The current WP:COMPUNITS is actually quite extreme, recommending explict 1000^n or 1024^n notation. I realize "no original work" is a part of the Wikipedia ethic. Nevertheless, here are examples of two simpler alternatives:

A 4 KB (binary) buffer
A 500 GB (decimal) hard drive

or perhaps:

A 4 KB^b buffer
A 500 GB^d hard drive

The first example does not strike me as original work.

So why not use KiBs to disambiguate KBs as binary? It's an IEC standard after all. I offer three reasons:

The expansion of the unit abbreviations will never gain widespread use (I realize this is speculation). The terms are loathsome. Donald Knuth (the guy who wrote the book on computer science) agrees, calling them "dead on arrival". Moreover, the notion that you could ask an entire industry to change the terms for its fundamental units defies reason.

If KiB disambiguates KB as binary, what is the equivalent unit to disambiguate KB as decimal? There isn't one. To be complete, it should include KdB (Kidibyte). If you say KB is decimal, you are betraying a bias.

If the terms are dead on arrival, then using their abbreviations simply not useful. They are useless by association.

To summarize:

Byte units: ambiguous
IEC spec: DOA
Revisit WP:COMPUNITS: agree. Hard deprecate IEC spec, use (binary)/(decimal) to disambiguate.

Thanks for responding and for reading this. Jeberle (talk) 03:36, 2 June 2010 (UTC)[reply]

Thank you for your detailed reply. In theory, there is a better place to discuss this topic (Wikipedia talk:Manual of Style (dates and numbers), see the archives B0-B17). However, this debate has been going on for five years now and there is very little hope that it will be resolved anytime in the foreseeable future. I haven't read all of it, but there seems to be a small core of people that stubbornly enforce their point of view. The fact that a IEC proponent keeps trolling doesn't exactly help the discussion either.

Note that I'm not saying that the IEC standard should be promoted or deprecated by a guideline (altough in my personal opinion, I prefer the binary prefices). All I'm saying is that there is no consensus among the Wikipedia community for either promotion or deprecation, and I think it is immediately obvious that this is the case (otherwise, your changes to the SI prefices wouldn't be reverted so fiercely by several editors). I find it outrageous that a small group of people dictates a guideline for all of Wikipedia when there is no consensus (as I mentioned before, guidelines are formed by consensus, not the other way around). If I could see any hope for resolving the issue, I would engage in the discussion; but as of now, I can find better ways to waste my time.

I won't change any SI prefices to IEC prefices, but I'll probably use the IEC prefices for new content I write. My guess is that the binary prefices will continue to gain acceptance in the future, as this debate will be obsolete at one point. Until then, I choose not to engage in edit wars, because if I think about it, the issue is really not that important, and there are much more productive ways to improve Wikipedia. I would be glad if you could agree with me on that.

Regarding your arguments: yes, I agree that sometimes binary bases are more convenient, and sometimes decimal ones are, and that the debate is only about how to label the numbers with a binary base.

"A 4 KB (binary) buffer": I don't think this is a good idea, since "(binary)" could be thought to refer to "buffer", not to "4 KB".
"A 4 KB^b buffer" I think I like this even more than the IEC prefices, especially since it allows explicit marking of a decimal base. However, I would append the index to the multiplier, not to the unit, like this: "4 K^bB. In any case, I'm sure you know that this is not a realistic option, because it would be pretty much confined to Wikipedia. If only the IEC had thought of it…
"The expansion of the unit abbreviations will never gain widespread use (I realize this is speculation)." – I can't argue here, we'll have to see to know.
"The terms are loathsome." – I can't argue here either. "KiB" doesn't look bad in my opinion, but "kibibytes" sounds like a three year old came up with it. How would you pronounce "KB^b" and "KB^d"? On the other hand, it doesn't matter for written material, as long as it is not intended to be read out loud.
"Donald Knuth (the guy who wrote the book on computer science) agrees, calling them "dead on arrival"." – I know who he is :-) His proposal wasn't brilliant either, and caught on even less than the IEC's one.
"Moreover, the notion that you could ask an entire industry to change the terms for its fundamental units defies reason." – Is it? All but three nations abolished their system of units in favor of the metric system (or are in the process of doing so). Granted, it took a while, but it is a much more involved process than writing "KiB" instead of "KB", especially since this doesn't involve any conversions (like feet => meters).
"If KiB disambiguates KB as binary, what is the equivalent unit to disambiguate KB as decimal?" – KB. If the binary bases are routinely labeled using the binary prefices, there won't be any need to disambiguate KB, because it is not ambiguous. Until that is the case, every "KiB" removes a little bit of ambiguity, and only the remaining "KB" have to be disambiguated.
"If you say KB is decimal, you are betraying a bias." – The "kilo", "mega", etc. prefices have been in use for more than two centuries. Along come the computer scientists and declare kilo := 1024. What would you say if I defined 1 km := 976 meters, just because my estate has a width of 976 meters?
"If the terms are dead on arrival, then using their abbreviations simply not useful." – I agree with your implication, but not with your premisse. You can see from the growing support of IEC prefices, that your premisse is false. Knuth is not a god, he is a man with personal opinions.

Adrianwn (talk) 08:13, 2 June 2010 (UTC)[reply]

You are a very good writer. Thank you again for responding.

I won't drag this on very much more. There are better things to waste ones time on, as you said.

Here's what I was originally going to say:

I would rather have ambiguous units that I can pronounce, than unambiguous units that I cannot pronounce.

Your arguments are well argued and reasoned, but you do not address the question of speech. You say that the metric system is over two centuries old, but spoken word is far older. Written word is relatively new in comparison. If you write something that cannot be spoken you have created graffiti.

You say that every little bit of KiB & GiB lightens a corner, and reduces ambiguity. I believe it does the exact opposite. It creates more ambiguity. Until the hard drive marketers of the 90's came along, there was virtually no ambiguity in the term "KB". Now, pile on the OSS movement (how they got this wrong is beyond me), and the seemingly complicit Wikipedia, and no one knows which way is up. Unless...

We could go back in time and right this terrible mistake. And rewrite all the books, magazines, and technical articles, etc. Right? And never use those nasty binary numbers, and get rid of Hexadecimal as well, because of those funny A-F numbers, and we can all live in a cushy base-10 world. And I'm sure, no one will mind the revisionist whitewashing along the way.

"KB" is an atomic word. It cannot be sliced into K & B. The fact that it uses the same Greek name is a convenience, not a flaw that needs correcting. We like these prefixes and we're keeping them. That is all.

Jeberle (talk) 05:12, 3 June 2010 (UTC)[reply]

I guess this issue is more subjective and much less clear than it appears at first glance. Your arguments made me realize this, yet they didn't convince me. I just hope that you won't get involved in edit wars over this, for your sanity's sake ;-) – Adrianwn (talk) 06:27, 3 June 2010 (UTC)[reply]

I'll stop here: COMPUNITS Suggestion
Much appreciated debate, BTW. This has been bothering me for quite some time, and really the last thing I expected was a well-reasoned discussion.
Cheers Jeberle (talk) 08:09, 3 June 2010 (UTC)[reply]

Tree (data structure)[edit]

I saw your edit about tree graphs growing downward, replacing my previous edit there which Coasterlover1994 reverted. This is a good solution; I agree with you that the mention of natural trees isn't really necessary, and the distinction between tree data structures, as a vague abstraction, and the drawn graphs of trees (whether drawn on paper, on a video screen, or in one's imagination) is a good refinement—you subtly imply the point (maybe not with determined intent) that a tree as a pure abstraction does not grow or have spatial configuration at all, being merely an interconnection of notions, so to speak.

If you read my response on Coasterlover1994's talk page—oh, wait, I see that you did. Thanks for agreeing with me. (I know it was for rational reasons, not as any kind of a favor.) So, you saw that I admitted this is (was) a minor issue. Nonetheless, Nice work.

Also, thanks for supporting my reasoning in the forum when you found it to be valid. I agree with everything you said there, including that someone else might have come along and made another improvement on my edit. I always welcome further improvements, even if they completely replace and obliterate my work, just so long as they really are improvements. I admit that I would rather edit an article to sound bad but be correct and unambiguously understandable than to have it sound good but be wrong or unclear, and that I sometimes leave it to others to make it sound better, when I don't have time to roll up my sleeves and dig into editing to make a necessary fix fit well. I assume that any improvement is better than, and appreciated over, no improvement.

I've actually been editing Wikipedia for years, in the same on-the-fly, contributing-in-appreciation-for-free-use manner as I made this edit, but I never chose to register. I do know all the important policies and principles (Assume Good Faith, Verifiability, no OR, NPOV, 3RR, etc.), and I (now) remember to sign my posts (w/ 4 tildas) before the fact of posting them. If I had been a new user, today I would in fact have been discouraged from editing again; in fact, because this has happened to me before, this did at first make me doubt my enthusiasm for WP. I mean, who wants to spend time doing work that may be unappreciated and thrown away, when there are so many other things to do? I'd say over 90% of my edits are left alone, cooperatively improved, or even occasionally commended, but a few times, maybe several, I've had an edit reverted, once or twice with the "unconstructive" boilerplate. The most significant and probably most recent instance was on the article Post and lintel, in a matter of phrasing similar to this case—it was another of these semantic/linguistic things where I thought it was prone to misunderstanding and my reverter, well, didn't. We politely wrangled, finally reached an adequate agreement, and he made the change. The sentence currently reads, "The lintel will deform by sagging in the middle because the underside is under tension and the topside is under compression," which is probably unchanged from then. It's the last sentence in the article. I think the previous version was something like, "The lintel will deflect concave upward when the underside is under tension and the topside is under compression," which I objected to because it was unclear and even misleading about the causality--it seemed to make the tension and compression primary causes, when in fact the load on top, and the self-loading of weight of the beam, causes them--they are the forces that account for the rigidity of the beam to resist weight, and are a reaction to that loading. "When" also suggested that the tension and compression weren't necessary consequences of loading, which they are. In context, changing to the word "because" fixed these problems.

So, it seems that in most instances, justice is served for the Wikipedian whose intentions are pure and whose editorial reasoning is right. (Not, by a long shot, to say that I'm always right.) Which is an encouragement to stay in the game.

I'm posting a pointer to this comment on Coasterlover1994's talk page.

–Stephen 141.158.233.114 (talk) 10:18, 22 July 2010 (UTC)[reply]

Hello Stephen, I'm glad you liked my edit. One of the nice things about WP is that if someone can't think of a better alternative, someone else might. However, one of the bad things about WP is that some people become lazy and don't take the time to explain the reasons for their actions, not to mention trying to incorporate the ideas of others – it's so much less trouble to just say "I don't like it" and revert it. If one of my edits would be labeled "vandalism" just because someone doesn't agree with it, I would be pissed. That's the kind of behaviour that turns new contributors away, especially those that don't have the motivation or the time to defend their edits.

Maybe you should register; after all, others are more suspicious of edits by IP addresses than by registered users. It's not fair, but it's only too human. In fact, I behave similarly, although I try not to. – Adrian (Adrianwn (talk) 12:07, 22 July 2010 (UTC))[reply]

ArbCom elections are now open![edit]

Hi,
You appear to be eligible to vote in the current Arbitration Committee election. The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to enact binding solutions for disputes between editors, primarily related to serious behavioural issues that the community has been unable to resolve. This includes the ability to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate, you are welcome to review the candidates' statements and submit your choices on the voting page. For the Election committee, MediaWiki message delivery (talk) 13:33, 24 November 2015 (UTC)[reply]