As mentioned, with complex numbers the radians make more sense and of course
cmath.sind(x) + 1j * cmath.sind(x) != cmath.exp(1j * x).
However, adding degrees version for cmath (import cmath) is still useful,
cmath.rectd, cmath.phased, cmath.polard etc.
2018-06-11 19:24 GMT+02:00 Michael Selik
^ is also used in regexes for matching the *beginning* of a string...
Realistically, I don't think this proposal would be added, but if it were,
^ would be a horrible choice.
That being said, I do understand the feeling of half your code being calls
to .append or .extend. You could always do:
Google will probably fix this problem for you after dataclasses become
popular. The docs will gain a bunch of inbound links and the issue will
(probably) solve itself as time passes.
On Tue, Jun 12, 2018 at 2:48 PM Neil Schemenauer <
nas-python-id...@arctrix.com> wrote:
> I'm testing "Data
On Tue, Jun 12, 2018 at 4:43 PM Mikhail V wrote:
> inserting in the beginning of the list may be also not rare.
>
Inserting in the beginning of a list is *slow* and should be rare.
If you want to append to the left-side of a list, you should use a deque.
Check out ``collections.deque`` for your
Mikhail V wrote:
L[0:0] = ["bb"]
-> ["bb", "aa"]
The trick is to put brackets around the element and so it works as insert().
Though additional brackets look really confusing for this purpose, so I don't
feel like using this seriously.
I don't think it's all that confusing. It looks
On Tue, Jun 12, 2018 at 10:25 PM, Michael Selik wrote:
> On Tue, Jun 12, 2018 at 11:08 AM Mikhail V wrote:
>>
>> On Tue, Jun 12, 2018 at 7:42 PM, Clint Hepner
>> wrote:
>>
>> So the idea was about an insert/append operator.
>> Which would use augmented operator. The operator may be
>> /= or ^=.
On Wed, Jun 13, 2018 at 5:25 AM, Michael Selik wrote:
> On Tue, Jun 12, 2018 at 11:08 AM Mikhail V wrote:
>>
>> On Tue, Jun 12, 2018 at 7:42 PM, Clint Hepner
>> wrote:
>>
>> So the idea was about an insert/append operator.
>> Which would use augmented operator. The operator may be
>> /= or ^=.
I'm testing "Data Classes" for Python 3.7. Awesome new feature,
BTW. The PEP is the first search result when I lookup "dataclass
python". Given that the PEP is not the best documentation for an
end user, I wonder if we should have a link in the header section of
the PEP that goes to better
On Tue, Jun 12, 2018 at 11:08 AM Mikhail V wrote:
> On Tue, Jun 12, 2018 at 7:42 PM, Clint Hepner
> wrote:
>
> So the idea was about an insert/append operator.
> Which would use augmented operator. The operator may be
> /= or ^=. (I like ^= more, so I'll put here example with it).
>
The "/"
On 6/12/2018 10:54 AM, Mikhail V wrote:
I think it would be logical to have the insert operator for lists.
Similar to list extend operator += , it could use one of augmented
assignment operators, e,g, /=.
...
Note that there is a trick to 'insert' an element with slicing syntax, e.g.:
This
On Tue, Jun 12, 2018 at 7:42 PM, Clint Hepner wrote:
>
>> On 2018 Jun 12 , at 10:54 a, Mikhail V wrote:
>>
>> I think it would be logical to have the insert operator for lists.
>> Similar to list extend operator += , it could use one of augmented
>> assignment operators, e,g, /=.
>>
>>L =
> On 2018 Jun 12 , at 10:54 a, Mikhail V wrote:
>
> I think it would be logical to have the insert operator for lists.
> Similar to list extend operator += , it could use one of augmented
> assignment operators, e,g, /=.
>
>L = ["aa"]
>
>L[0] /= "bb"
>
>-> ["bb", "aa"]
>
>
>
>
> [Tim]
>> 1. Python's float "%" is unsuitable for argument reduction; e.g.,
> >>
> >> >>> -1e-14 % 360.0
> >> 360.0
> >>
> >> `math.fmod` is suitable, because it's exact:
> >>
> >> >>> math.fmod(-1e-14, 360.0)
> >> -1e-14
>
> [Greg Ewing]
> So why doesn't float % use math.fmod?
>
12.06.18 17:54, Mikhail V пише:
I think it would be logical to have the insert operator for lists.
Similar to list extend operator += , it could use one of augmented
assignment operators, e,g, /=.
L = ["aa"]
L[0] /= "bb"
-> ["bb", "aa"]
L[0] /= [1,2]
-> [[1,2],
On Tue, Jun 12, 2018 at 5:54 PM, Mikhail V wrote:
> I think it would be logical to have the insert operator for lists.
> Similar to list extend operator += , it could use one of augmented
> assignment operators, e,g, /=.
>
> L = ["aa"]
>
> L[0] /= "bb"
>
> -> ["bb", "aa"]
>
>
That's a slice assignment, works great. I think if you use it more often
you'll start to enjoy it.
However, lists are optimized for append. Insert is slow. It should be
discouraged, not encouraged by the language. If inserting is just a tad
more awkward than appending, that's the language design
I think it would be logical to have the insert operator for lists.
Similar to list extend operator += , it could use one of augmented
assignment operators, e,g, /=.
L = ["aa"]
L[0] /= "bb"
-> ["bb", "aa"]
L[0] /= [1,2]
-> [[1,2], "aa"]
etc.
Without index it would work
Sym: SymPy, SymEngine, PySym, SymCXX, Diofant
(re: \pi, symbolic computation and trigonometry
instead of surprisingly useful piecewise optimizations)
On Fri, Jun 8, 2018 at 10:09 PM Wes Turner wrote:
> # Python, NumPy, SymPy, mpmath, sage trigonometric functions
>
On Tue, Jun 12, 2018, 00:03 Stephan Houben wrote:
> Hi all,
>
> I wrote a possible implementation of sindg:
>
> https://gist.github.com/stephanh42/336d54a53b31104b97e46156c7deacdd
>
> This code first reduces the angle to the [0,90] interval.
> After doing so, it can be observed that the simple
>
> I still don't get it... If you have a framework you presumably have an
> entry point. Why can't you set up your policy in that entrypoint? Why
> would a user attempt to change the policy at runtime (you haven't
> listed examples of libraries that do this)?
Not at run time. But several
Hi all,
I wrote a possible implementation of sindg:
https://gist.github.com/stephanh42/336d54a53b31104b97e46156c7deacdd
This code first reduces the angle to the [0,90] interval.
After doing so, it can be observed that the simple implementation
math.sin(math.radians(angle))
produces exact
On Tue, Jun 12, 2018 at 4:40 PM, Greg Ewing wrote:
> Tim Peters wrote:
>
>> 1. Python's float "%" is unsuitable for argument reduction; e.g.,
>>
>> >>> -1e-14 % 360.0
>> 360.0
>>
>> `math.fmod` is suitable, because it's exact:
>>
>> >>> math.fmod(-1e-14, 360.0)
>> -1e-14
>
>
> So why doesn't
Sorry for top posting, but these aren't really opinions for the
debate, just information. I haven't seen them mentioned, and none
grouped nicely under someone's reply.
Number representation::
IEEE-754 doubles cannot represent pi correctly at any bit-depth (i
mean, obviously, but more seriously).
Tim Peters wrote:
1. Python's float "%" is unsuitable for argument reduction; e.g.,
>>> -1e-14 % 360.0
360.0
`math.fmod` is suitable, because it's exact:
>>> math.fmod(-1e-14, 360.0)
-1e-14
So why doesn't float % use math.fmod?
--
Greg
___
24 matches
Mail list logo
