# Incorrect LaTeX for some predefined functions when passing the wrong number of parameters #636

Closed
opened this Issue Apr 3, 2016 · 14 comments

Projects
None yet
2 participants
Collaborator

Collaborator

### FSMaxB commented Apr 5, 2016

 It's ugly in two regards: It needs to be done for every single function that defines it's own LaTeX output, even ones that will be added in the future. It makes the template language I introduced quite pointless for most functions, because you would suddenly need to distinguish between different amounts of arguments thereby requiring a dedicated handler function that handles those cases separately. UPDATE: 3. Many of those functions that have their own LaTeX output defined aren't as simple cases as sin. See combinations for example. (this relates to point 2!)
Owner

### josdejong commented Apr 7, 2016

 Thanks for your clear arguments. Yes for functions we will have to use ${args} instead of ${args[0]}, but I don't see a problem there. What I find more important is a solution which does not silently hide information from you, even if the information is partly invalid like sin(1,2,3). It's up to the user to fix that but if you hide this from the user, he has no way to know about it and fix it. The template language is an will be essential for all operators and some special functions like nthRoot and combinations. But we should not use the template stuff for the sake of using it but where it's appropriate and needed.
Collaborator

Collaborator

### FSMaxB commented Apr 8, 2016

 I strongly prefer option 1 because most LaTeX templates that were defined manually don't make too much sense if you extend them to support a variable number of arguments and users will probably expect their overwritten functions to have the default LaTeX output. Also many of the templates can't even be extended to support variable numbers of arguments because the LaTeX output would simply break or make no sense at all. Like '\\left(${args[0]}' + latex.operators['xor'] + '${args[1]}\\right)' or '\\binom{${args[0]}}{${args[1]}}'.
Owner

### josdejong commented Apr 8, 2016

 Ok lets go for option 1 then :)
Collaborator

### FSMaxB commented Apr 8, 2016

 I won't have the time to do this refactoring in the near future. You would either have to do it yourself or you'd have to wait a while until I find the time (which might be ok since this bug doesn't seem to critical).
Owner

### josdejong commented Apr 8, 2016

 I think I can do it, maybe this weekend. It's indeed not critical.
Owner

### josdejong commented Apr 11, 2016

 I've gone through all functions and made the toTex templates more strict, reckoning with the number of arguments. I've left the functions which had the default template ('\\mathrm{${name}}\\left(${args}\\right)') as they are, since some of them accept different numbers of arguments and it doesn't really help to make the toTex conditional since it falls back to the default template anyway. Just thinking, maybe we should change the functions that use the default template: format.toTex = '\\mathrm{${name}}\\left(${args}\\right)'; to something like: format.toTex = undefined; // use default template That way you get information that this function is using the default template, and it probably saves a few bytes of the bundle.
Collaborator

### FSMaxB commented Apr 11, 2016

 Will this get stripped during the minification? Otherwise maybe remove the line entirely. But I like the idea of explicitly stating that the default template was used. Thereby it is possible to distinguish between cases where a proper toTex is still missing and cases where the default template was intended.
Owner

### josdejong commented Apr 15, 2016

 Thereby it is possible to distinguish between cases where a proper toTex is still missing and cases where the default template was intended. yes exactly, and we shouldn't loose that. This shouldn't be stripped when minifying: the minifier cannot just decide to drop a property of an object because it's (initial) value is undefined. That would alter the behavior of for example Object.keys(obj). Ok I will refactor the places where the default toTex is used to format.toTex = undefined.

### josdejong added a commit that referenced this issue Apr 15, 2016

 Replaced toTex definitions using the default toTex template with "und… 
…efined" and a comment (see #636)
 b2066e5 
Owner

### josdejong commented Apr 15, 2016

 Done in b2066e5