Difference between revisions of "Talk:Moon/Row"
From Kerbal Space Program Wiki
(→Expression error: Unrecognized punctuation character "{".) |
(→Expression error: Unrecognized punctuation character "{".) |
||
| Line 4: | Line 4: | ||
:Where does the error occur? Looking at your [http://wiki.kerbalspaceprogram.com/w/index.php?title=Template:Sigfigs&curid=994&diff=58555&oldid=25931&rcid=72485 fix] I doubt that it works. — [[User:XZise|xZise]] <small>[[[User talk:XZise|talk]]]</small> 12:52, 14 March 2015 (CDT) | :Where does the error occur? Looking at your [http://wiki.kerbalspaceprogram.com/w/index.php?title=Template:Sigfigs&curid=994&diff=58555&oldid=25931&rcid=72485 fix] I doubt that it works. — [[User:XZise|xZise]] <small>[[[User talk:XZise|talk]]]</small> 12:52, 14 March 2015 (CDT) | ||
::Revert the fix and it will appear here, and also when all the <nowiki><noinclue> & <includeonly></nowiki> tags are removed from the Sigfig template. The numbers parsed through Sigfig seem to all work ''with'' my attempted fix, so... what do you think? --[[User:Brendan|Brendan]] ([[User talk:Brendan|talk]]) 12:55, 14 March 2015 (CDT) | ::Revert the fix and it will appear here, and also when all the <nowiki><noinclue> & <includeonly></nowiki> tags are removed from the Sigfig template. The numbers parsed through Sigfig seem to all work ''with'' my attempted fix, so... what do you think? --[[User:Brendan|Brendan]] ([[User talk:Brendan|talk]]) 12:55, 14 March 2015 (CDT) | ||
| − | :::You made it to triple brackets which interpret it as a variable: {{{#ifexpr: 42 = 0|Oh|No}}} vs. {{#ifexpr: 42 = 0|Oh|No}} (<nowiki>{{{#ifexpr: 42 = 0|Oh|No}}}</nowiki> vs. <nowiki>{{#ifexpr: 42 = 0|Oh|No}}</nowiki>). It returns “Oh” in the first case because the variable “#ifexpr: 42 = 0” is not set (although that name doesn't make sense with the equal sign in it). And if a variable is not set it uses the first parameter after it (“Oh”, interestingly it doesn't use everything after the pipe). This here is also a meta template. The data is missing here so it can't show anything useful. If a variable is not set and also no default (e.g. <nowiki>{{{foobar}}}</nowiki>) then it'll display the text unchanged (so <nowiki>{{{foobar}}}</nowiki>) and the curly brackets are not a valid number. | + | :::You made it to triple brackets which interpret it as a variable: {{{#ifexpr: 42 = 0|Oh|No}}} vs. {{#ifexpr: 42 = 0|Oh|No}} (<code><nowiki>{{{#ifexpr: 42 = 0|Oh|No}}}</nowiki></code> vs. <code><nowiki>{{#ifexpr: 42 = 0|Oh|No}}</nowiki></code>). It returns “Oh” in the first case because the variable “#ifexpr: 42 = 0” is not set (although that name doesn't make sense with the equal sign in it). And if a variable is not set it uses the first parameter after it (“Oh”, interestingly it doesn't use everything after the pipe). This here is also a meta template. The data is missing here so it can't show anything useful. If a variable is not set and also no default (e.g. <code><nowiki>{{{foobar}}}</nowiki></code>) then it'll display the text unchanged (so <code><nowiki>{{{foobar}}}</nowiki></code>) and the curly brackets are not a valid number. |
| − | :::You've now changed it into a variable which seems to have disabled calculating with it and thus no apparent errors. But when I substitute <nowiki>{{sigfigs|1|4}}</nowiki> you see that it's using the scientific notation even though the number is shorter than the given significant figures: {{#ifeq: 1|N/A|N/A|<span style="white-space:nowrap;">{{#formatnum:{{#expr: 1/10^floor(ln(1)/ln(10)) round 4 - 1}}|{{#expr: 4 - 1}}|{{DS}}|t}}×10<sup>{{#formatnum:{{#expr: floor(ln(1)/ln(10))}}|{{DS}}|t}}</sup></span>}} — [[User:XZise|xZise]] <small>[[[User talk:XZise|talk]]]</small> 06:15, 16 March 2015 (CDT) | + | :::You've now changed it into a variable which seems to have disabled calculating with it and thus no apparent errors. But when I substitute <code><nowiki>{{sigfigs|1|4}}</nowiki></code> you see that it's using the scientific notation even though the number is shorter than the given significant figures: {{#ifeq: 1|N/A|N/A|<span style="white-space:nowrap;">{{#formatnum:{{#expr: 1/10^floor(ln(1)/ln(10)) round 4 - 1}}|{{#expr: 4 - 1}}|{{DS}}|t}}×10<sup>{{#formatnum:{{#expr: floor(ln(1)/ln(10))}}|{{DS}}|t}}</sup></span>}} — [[User:XZise|xZise]] <small>[[[User talk:XZise|talk]]]</small> 06:15, 16 March 2015 (CDT) |
| + | :::Okay now after I've reverted it, it's {{#ifeq: 1|N/A|N/A|<span style="white-space:nowrap;">{{#ifexpr: abs(floor(ln(1)/ln(10))) + 1>4|{{#formatnum:{{#expr: 1/10^floor(ln(1)/ln(10)) round 4 - 1}}|{{#expr: 4 - 1}}|{{DS}}|t}}×10<sup>{{#formatnum:{{#expr: floor(ln(1)/ln(10))}}|{{DS}}|t}}</sup>|{{#formatnum:1|{{#expr: 4-{{#ifexpr: ln(1) >= 0|abs(floor(ln(1)/ln(10)))-1|0}}}}|{{DS}}|t}}}}</span>}}. And you can also see why it happens: It's trying to get the body's mass using <code><nowiki>{{Body data|{{{1}}}|mass}}</nowiki></code>. By default (with no body name given) this will just return <code><nowiki>{{:{{{1}}}/Param|mass|}}</nowiki></code> and that is not a valid number which could be used in a calculation. When I replace the <code><nowiki>{{{1}}}</nowiki></code> with ''Mun'' it will generate “{{Body data|Mun|mass}}” and that is a valid number which can be used easily. | ||
| + | :::By the way most pages which are [[:Category:Metatemplates]]/[[:Category:Page-specific templates]] also show invalid data by default because they have no default value set (why bother?). — [[User:XZise|xZise]] <small>[[[User talk:XZise|talk]]]</small> 08:20, 16 March 2015 (CDT) | ||
Latest revision as of 13:20, 16 March 2015
Expression error: Unrecognized punctuation character "{".
This occurs at the Sigfigs template. Oddly, erasing one "{" in front of it makes the error quiet down, but near as I can tell that would be one too few "{"s to match the "}"s. So, I think the error may be in how Template:Sigfigs returns things. This is a little technical for me... --Brendan (talk) 23:31, 13 March 2015 (CDT)
- Where does the error occur? Looking at your fix I doubt that it works. — xZise [talk] 12:52, 14 March 2015 (CDT)
- Revert the fix and it will appear here, and also when all the <noinclue> & <includeonly> tags are removed from the Sigfig template. The numbers parsed through Sigfig seem to all work with my attempted fix, so... what do you think? --Brendan (talk) 12:55, 14 March 2015 (CDT)
- You made it to triple brackets which interpret it as a variable: Oh vs. No (
{{{#ifexpr: 42 = 0|Oh|No}}}vs.{{#ifexpr: 42 = 0|Oh|No}}). It returns “Oh” in the first case because the variable “#ifexpr: 42 = 0” is not set (although that name doesn't make sense with the equal sign in it). And if a variable is not set it uses the first parameter after it (“Oh”, interestingly it doesn't use everything after the pipe). This here is also a meta template. The data is missing here so it can't show anything useful. If a variable is not set and also no default (e.g.{{{foobar}}}) then it'll display the text unchanged (so{{{foobar}}}) and the curly brackets are not a valid number. - You've now changed it into a variable which seems to have disabled calculating with it and thus no apparent errors. But when I substitute
{{sigfigs|1|4}}you see that it's using the scientific notation even though the number is shorter than the given significant figures: 1.000×100 — xZise [talk] 06:15, 16 March 2015 (CDT) - Okay now after I've reverted it, it's 1.000. And you can also see why it happens: It's trying to get the body's mass using
{{Body data|{{{1}}}|mass}}. By default (with no body name given) this will just return{{:{{{1}}}/Param|mass|}}and that is not a valid number which could be used in a calculation. When I replace the{{{1}}}with Mun it will generate “” and that is a valid number which can be used easily. - By the way most pages which are Category:Metatemplates/Category:Page-specific templates also show invalid data by default because they have no default value set (why bother?). — xZise [talk] 08:20, 16 March 2015 (CDT)
- You made it to triple brackets which interpret it as a variable: Oh vs. No (
- Revert the fix and it will appear here, and also when all the <noinclue> & <includeonly> tags are removed from the Sigfig template. The numbers parsed through Sigfig seem to all work with my attempted fix, so... what do you think? --Brendan (talk) 12:55, 14 March 2015 (CDT)
