Trigonometry in Feature Requests

Page: 1 2
ID:110802
 
Mar 14 2011, 1:42 pm
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
Duplicates:id:650497
Why are we so conservative about trigonometric functions? I'd like to see tan, cot, and perhaps sec or csc, as well as their respective inverses, built-in.
#1 Mar 14 2011, 2:49 pm (Edited on Apr 13 2012, 2:36 pm)
tan you can do by yourself:

proc/tan(x) return sin(x)/cos(x)


What Toad said.
#2 Mar 15 2011, 4:16 am
You can do them all on your own, including sin and cos - that's besides the point. If we have cos and sin built-in, I'd like to see the rest built-in, it's very convenient to have them and we don't really have a concept of standard library here on BYOND.
#3 Mar 15 2011, 8:35 am
They could just list the procs (like ExPixel has shown) in the reference entries for the related functions.
#4 Mar 15 2011, 3:36 pm (Edited on Mar 15 2011, 3:52 pm)
My feature request is for making them built-in, not telling us how to implement them. Anyone with some knowledge of math would know how to approximate sin, cos, or any of the above. It is a lot more convenient to have these built-in: no need to include a library whenever you need them, no need to point others to some arbitrary library (with equally arbitrary syntax) implementing them whenever you answer questions, efficiency, and least but not least: a sense of completeness.
#5 Mar 15 2011, 11:52 pm
If they were listed in the reference pages, you wouldn't need to include, or point somebody to an arbitrary library. You would simply need to copy and paste a single line of officially provided code into your source from the related help page.
They could be included for completeness, but I see no reason for this to be a priority, or a necessary addition.
#6 Mar 16 2011, 7:02 am
If they were listed in the reference pages, you wouldn't need to include, or point somebody to an arbitrary library. You would simply need to copy and paste a single line of officially provided code into your source from the related help page.

Which begs the question: why include the code of functions in the reference and not implement them? This is confusing and silly.

They could be included for completeness, but I see no reason for this to be a priority, or a necessary addition.

It is not "necessary" - nor are most feature requests here. Its priority is lower than some requests, higher than others. It has the benefit of being quite easy to implement. Just the same, I want to see it implemented. I don't see what you're arguing against here.
#7 Mar 16 2011, 7:12 am
Toadfish wrote:
Which begs the question: why include the code of functions in the reference and not implement them? This is confusing and silly.

Because its much more complicated for them to implement it into the compiler than it is to write a plain text line in a help file
#8 Mar 16 2011, 7:19 am
You won't be "implementing it into the compiler", whatever that means.
#9 Mar 16 2011, 8:09 am
Falacy wrote:
Because its much more complicated for them to implement it into the compiler than it is to write a plain text line in a help file

It's actually probably just as easy as what ExPixel has below. It could be included with stddef.dm (which has all of the globally defined things like bit flags, some icon procs, some interface procs, and I forget what else.
Even so, it really isn't hard to get most of the trigonometric functions, and I'm sure someone has a library with them, somewhere.
#10 Mar 16 2011, 9:16 am
Even so, it really isn't hard to get most of the trigonometric functions, and I'm sure someone has a library with them, somewhere.

I just gave it a quick look; there wasn't. I suppose I could contribute one until you scoundrels see the light. I'm going to be relying on my memory for the trig identities, so hopefully I get it right:

proc/tan(theta) return sin(theta) / cos(theta)
proc/cot(theta) return cos(theta) / sin(theta)
proc/sec(theta) return 1 / cos(theta)
proc/csc(theta) return 1 / sin(theta)
proc/atan(x) return arccos(1 / sqrt(1+x*x))
proc/acot(x) return arcsin(1 / sqrt(1+x*x))
proc/asec(x) return arccos(1 / x)
proc/acsc(x) return arcsin(1 / x)
#11 Mar 24 2011, 12:40 pm
I was wondering why this wasn't already implemented when I was playing around with trigonometry. It was kind of annoying to have to write the functions personally considering that I'm not yet that familiar with the subject as it is.
#12 Apr 1 2011, 2:43 am
Aye, it's inconvenient. You could always include a library but there's no reason why they shouldn't be built-in. Well, except perhaps additional clutter as we don't really have namespaces. But we already have sine and cosine so I see no problem there.
#13 Apr 9 2012, 5:56 pm
Bump
#14 Apr 9 2012, 7:24 pm
Well the odds of someone using the functions without knowing how to define them are very slim. Anyone using tan, sec, etc., should and would know how to make them using what has been provided.

Like Falacy said before, completeness, but not a priority.
#15 Apr 10 2012, 1:17 am
I would love to see these functions built in. Including them in the references without building them into the language sounds ridiculous.
#16 Apr 12 2012, 8:33 am
If you're after this for completeness's sake, why are you stopping at trig functions?

BYOND is for making games, so "completeness" means "complete for what a game needs". Games might have a use for tan, atan, and atan2 procs, but things like arccosecant is probably a stretch.

Also, there aren't a whole lot of three- or four-letter proc names, so there's a decent chance that someone would have a function in their game that they'd like to abbreviate as "sec" or "csc". It's best to have these be in a library, so people can include them as needed.
#17 Apr 12 2012, 8:39 am
In response to Forum_account (#16)
Forum_account wrote:
If you're after this for completeness's sake, why are you stopping at trig functions?
BYOND certainly shouldn't stop at trig functions... As for this feature specifically; BYOND already has sin, cos, arcsin, arccos, so I'm not sure why they seem to have skipped tan, since you can't even calculate angles to use in the others without it.

Also, there aren't a whole lot of three- or four-letter proc names, so there's a decent chance that someone would have a function in their game that they'd like to abbreviate as "sec" or "csc".
Then they should get some proper naming standards.

It's best to have these be in a library, so people can include them as needed.
It is not best to have something in a random library, especially not something this simple that should have been built in from the start.
#18 Apr 12 2012, 8:44 am
Falacy wrote:
Then they should get some proper naming standards.

These are typical names for math functions, so it'd be detrimental to use any other names. Other languages have namespaces, which helps. It's also a problem that having a built-in proc often precludes you from ever using that proc name anywhere.

It is not best to have something in a random library, especially not something this simple that should have been built in from the start.

The tan, atan, and atan2 procs should probably be built in, but the other ones aren't needed and are better put in a library. I don't think Java's Math class provides a cosecant function - if Java programmers haven't had a great need for it, I think DM users will get by.
#19 Apr 12 2012, 8:50 am
In response to Forum_account (#18)
Forum_account wrote:
These are typical names for math functions, so it'd be detrimental to use any other names.
Well, if you're talking about somebody just having their own tan proc, that does the same as a newly built-in tan proc, then the developer should just remove theirs? Why would this be an issue?

but the other ones aren't needed and are better put in a library.
Unless BYOND is going to start some official project, where BYOND comes with a handful of competent libraries, then providing something through a library is not a better solution.
Page: 1 2