Template talk:Props

I just realised that you are using subpages such as Unobtanium/Atomic Mass for each different property. First, would it not be more appropriate at Unobtanium/Properties/Atomic Mass? Second, why not have all the properties on one page, similar to the switch you have for the isotopes, would that not be simpler? I'm not saying your plan is wrong, just interested to hear your thought process. Chris Day 07:11, 7 June 2008 (CDT)

Hi Chris,

You asked a couple of good questions...let's take them one at a time...

*would it not be more appropriate at Unobtanium/Properties/Atomic Mass

I thought about this one to the point that I had decided that it was exactly the thing to do...and then I didn't implement it that way. In fact, it was so bad I caught myself a number of times almost errantly introducing exactly that syntax...probably just up too late to be quite frank...sort of like right now...

Anyway, the bottom line that I came to in my reasoning is that when we store these types of data in subpages of a material article, that simple fact in some sense already says that it is a property of the material. Or we can just look at: P.R.O.P.E.R.T.I.E.S. ten letters that are just not really necessary, and then ten more each time you retrieve the data...well you get the idea, why make the name longer than it needs to be?

*why not have all the properties on one page, similar to the switch you have for the isotopes, would that not be simpler?

I think you actually discovered the exact path leading to the move to seperate the properties onto their own pages...Let's see if I can recap...

The physical properties template got big fast...real big. And all indications were that if the scheme were to continue, it was going to get nothing but worse. The real problem with having all the data on a single template with a switch to give only the data called, is that the wiki "compiler" has to load the entire template every time you want even a small bit of info.

This is especially a problem if you are trying to list the whole set of data...the size of the pre-expand data grows at a rate of n squared (each time you add a bit of data, it gets called into memory...with every bit of data) this is perhaps not a good scheme for a large database...maybe it's ok for a small one. It is even more obvious what the answer is when we compare it to the pre-expand size growing at a rate of plain old n if we just store the data in regular pages.

The thing is, as you point out...it seems like there should be one page a reader can go to to see all of the data at once. Of course, by this we don't mean the main article mind you...that one then would be too cluttered. Thus the Isotopes subpage, or the properties subpage, or the MSDS, or whatever you want to call it...I'm not real sure we won't want both an MSDS and a Properties page for most "materials" with some duplicated info in many if not all cases.

Now, if you look closely back at the old versions of the IsoData template, (update 2010:you cant look back now...it's been deleted!--David Yamakuchi 19:30, 10 February 2010 (UTC)) you might find where I first tried this scheme by breaking out the data for ⁶Li in it's own template. I was having trouble with Lead's Isotopes page (Lead, I seem to remember reading somewhere, has the most stable isotopes of any element, and also has a great many long-lived radioactive ones...it was a good test...but one which the scheme failed...miserably...the old n² problem strikes again!)

In any event, it blew up the IsoData template because the pre-expand size was so big. The server would take a half hour to return the page and it was on the edge of crashing things I think. And Isotopes should be easier than physical properties...there are only so many of them. Apparently however, lead has enough of them to cause a problem...or perhaps I should say illustrate the problem.

Now, I'd already had the list idea worked out for the Isotopes, so I just decided to heck with it. If you want to know the Melting point for Foo, it can be found at Foo/Melting point. End of story. Things don't blow up and there is consistency and now that you have helped get the properties template working, we can show them all on a single page...Properties...or whatever people would like to call it. The downside for me is what it means is tossing out a bunch of templates (read as alot of work)...so I've been procrastinating :-)

There was one more thing with these properties tho...It's been buging me for a while and I think this fixes it too.

Let's say for the sake of argument that we want to compare the melting point of Hydrogen to the melting point of Iron. Obviously the actual measurements will be done at least somewhat differently, and probably quite differently indeed. With their own pages each property can easily have a significant amount of "metadata" attached. A :Foo/Melting point/Measurement_method page could give us valuable insight as to how we arrived at some particular measured or calculated number.--David Yamakuchi 02:38, 8 June 2008 (CDT)

{{Props}}

It was working for months...what happened?--David Yamakuchi 22:41, 24 November 2008 (UTC)

No idea but it seems fixable. The most likely reason for it not working is a mediawiki upgrade about three weeks ago. Chances are some of the template rules changed. Chris Day 22:42, 24 November 2008 (UTC)

That sounds about right. It seems like it's no longer evaluating {{Properties}} for whatever reason, but it does still load the "list". I was actually trying to find the MW version update info when you must have noticed my edits and "chimed in" :-) Just like old times eh?--David Yamakuchi 22:53, 24 November 2008 (UTC)

You mean a ton of edit clashes :) I noticed there seems to be an extra bar between the last variable and the material field. Does that help isolate the problem? Chris Day 22:55, 24 November 2008 (UTC)

The extra pipe should not cause an issue for this table. It seems to me that I had to add it to get something or other to work properly. It didn't seem important at the time...As for edit clashes, um...it's nice to have help? :-)--David Yamakuchi 07:01, 26 November 2008 (UTC)

It's so strange. If I put {{Props|Material=Iron}} into the Expand templates page, it returns text with an _unexpanded_ {{Properties}} template, with the arguments that the Iron/Properties/List "template" passed to it.

Stranger still, if I then copy the "output" syntax directly back to the input box, the template then expands 100% perfectly, right down to the formatting on the units (which is a couple of template levels deeper still). It's like:

"Oh you mean THAT template....well sure I can expand THAT one"

...Open the F$#%@n pod bay doors, HAL--David Yamakuchi 07:01, 26 November 2008 (UTC)

Check this out

User_talk:Chris_Day#How_do_I_increase_the_cellpadding_in_a_Wikitable.3F

This is another change that happened to tables at the same time. Clearly tables are not functioning as they used to. I don't know what the root of the problem is. Chris Day 00:05, 25 November 2008 (UTC)

Still driving you nuts? Just so you know. I'm stumped too. Chris Day 22:16, 7 December 2008 (UTC)

David, is there any reason why that list in {{Props}} can't just be fully inclusive? Something similar to this, without actually transcluding the list from a subsubpage (such as Iron/Properties/List)? As far as i can tell values only appear in the table if the appropriate value subpage exists anyway so a customised list is not really required. Is there any specific need for the /lists subsubpage to limit the number of fields? Chris Day 00:27, 8 December 2008 (UTC)

Is it a need? No. Would it be nice? Yes, most definitely.

I think I had something like the server having to check for say, Sulphr Dioxide/Atomic Number in mind. It wouldn't make sense. The template is much more general if you can tell it what the properties are. Consider, could a taxonomist come up with "properties" for say, mammals?--David Yamakuchi 18:47, 8 December 2008 (UTC)

I see what you're saying, but what would be a practical limit to the number of fields. Couldn't it be hundreds or would that be too much CPU time? Chris Day 05:51, 9 December 2008 (UTC)

Dunno about the CPU implications, I suppose that's a consideration as well. {{Properties}} currently only evaluates the first 50 anyway. The 51'st and onward would simply be ignored, although that number can be arbitrarily large...it would get very large...and unnecessarily bloated.

I think I've convinced myself at any rate. The simple solution is the most elegant here. Let Iron->Properties->List tell us what 50 fields we need to check for in the case of Iron, Mammals->Properties->List for mammals. We could call it Mammals->Properties->ls if you prefer ;-)

Sadly however, our latest and greatest wiki version does not seem happy with the technique where the old one did. Sort of seems like we moved backwards, _but_ I did however, notice numerous "template expand" type bugs when I searched the Bugzilla listings on MediaWiki for previous builds, I guess it would be kinda optimistic to expect a new build without them. The expand templates page doesn't expand the template as advertised. I contend that that is a bug that could be fixed.

So, I would like to propose the following: fix with your "central list" patch so that the various pages function for now and don't look like doo doo. Continue that way until such time as the wiki's template logic is repaired. I will put in a bug report to try and help effect the repair.--David Yamakuchi 06:42, 9 December 2008 (UTC)

Sounds good and i agree the versatility of having a specific list will make it more generally applicable. You may well be right that this will be fixed in an upcoming version. Are you going to set up a sentinel template on your talk page so we know when the expand is working correctly? Chris Day 06:51, 9 December 2008 (UTC)

See Lithium/Isotopes. I pulled the Isotopes out of the Metadata so there won't be a link to it from the main article. This one could be a sentinel where it is, or I could move it as you suggest. It uses the same technique.--David Yamakuchi 16:06, 9 December 2008 (UTC)