On Sunday, November 25, 2012 10:34:47 PM UTC, John Cremona wrote: > The notation e(n) is common for exp(2*pi*i*n), more so than E(n) in > normal mathematics. But I do not think that either e() or E() should > be global functions with this meaning; anyone wanting to use them can > easily define it themselves
Well "e" is already an object is the global namespace, so that is not an option. The fact that you can easily define it yourself misses the point: We want stuff in the global namespace so that functions are discoverable. Yes you can always import anything in the global namespace with any name you want but that is hardly intuitive. Here we have a perfectly fine opportunity to make Sage easier to use by people that are familiar with GAP. And the answer is: nah, let them dig through the manual? The only reason for not using E() is if we want to reserve it for another functionality. So far nobody else had a better suggestion for what to do with "E". You want to keep it unused because the global namespace is nice and tidy that way? > . > > John > > On 25 November 2012 21:50, Volker Braun <vbrau...@gmail.com <javascript:>> > wrote: > > If you ever used GAP then the E(3) notation will be very familiar. Its > > shorthand for exp(2*pi*I/3), so its not unintentional that it is similar > to > > exponentiation. > > > > If you don't know GAP then neither E(3) nor UCF.gen(3) will be familiar > to > > you, of course. > > > > Also, one thing that I learned to appreciate in GAP is that the notation > > E(3) instead of zeta(3) or exp(2*pi*I/3) is very compact. So > representation > > matrices involving cyclotomics are as legible as possible. > > > > > > > > > > > > On Sunday, November 25, 2012 9:13:34 PM UTC, John H Palmieri wrote: > >> > >> > >> > >> On Sunday, November 25, 2012 12:56:55 PM UTC-8, Volker Braun wrote: > >>> > >>> On Sunday, November 25, 2012 8:12:50 PM UTC, Nils Bruin wrote: > >>>> > >>>> opposed to having an instance of UCF initialized in sage by default. > >>>> It's a very useful parent to have, but it can easily be constructed > >>>> when required. > >>> > >>> > >>> Are we also getting rid of QQ then, since it can easily be obtained as > >>> ZZ.fraction_field()? > >>> > >>> We are talking about the Sage command line here, anything that is of > use > >>> should be accessible in as few keystrokes as possible. Since Python is > >>> totally free-form there is virtually no drawback from having stuff > pulled > >>> into the global namespace on the command line. If you don't like it > you can > >>> still use E or UCF for whatever else you want without any consequence. > This > >>> is not like C/C++ namespace pollution where the available namespace > shrinks. > >> > >> > >> I have at least two questions: > >> > >> - will anyone have any idea what "E" would do from the Sage command > line? > >> Once you've seen ZZ, you can guess about QQ or RR or CC; how > universally > >> used is "E" for this mathematical object? > >> > >> - will people reasonably expect "E" to return something else? In a year > or > >> two, will someone else have a conflicting suggestion about what E > should > >> mean? > >> > >> There is a drawback to adding things to the global namespace if the > name > >> is ambiguous or uninformative. "UCF" looks much better to me than "E" > >> because of this. > >> > >> -- > >> John > >> > > -- > > You received this message because you are subscribed to the Google > Groups > > "sage-devel" group. > > To post to this group, send email to > > sage-...@googlegroups.com<javascript:>. > > > To unsubscribe from this group, send email to > > sage-devel+...@googlegroups.com <javascript:>. > > Visit this group at http://groups.google.com/group/sage-devel?hl=en. > > > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
