I wrote a patch, which fixes the issue (#2232) and adds a padto-
parameter (as suggested).
Feel free to review :-)
http://trac.sagemath.org/sage_trac/ticket/2232
-vgermrk-
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To un
Fine -- clearly a sensible choice at the time, and I would not dream
of changing that now!
John
On 03/04/2008, William Stein <[EMAIL PROTECTED]> wrote:
>
> On Thu, Apr 3, 2008 at 12:14 PM, John Cremona <[EMAIL PROTECTED]> wrote:
> >
> > We have to regard 0 as a special case, I don't think th
On Thu, Apr 3, 2008 at 12:14 PM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> We have to regard 0 as a special case, I don't think there's any point
> in pretending otherwise. If all leading zeros were stripped off in
> all cases then the string representing 0 would be the empty string,
> and
That seem reasonable to me. If users expected the number of digits to
always equal the length of the string representation, then what about
negative integers?
Of course we could restrict the ndigits() function to positive integers only...
John
On 03/04/2008, Joel B. Mohler <[EMAIL PROTECTED]>
On Thursday 03 April 2008 15:14, John Cremona wrote:
> We have to regard 0 as a special case, I don't think there's any point
> in pretending otherwise. If all leading zeros were stripped off in
> all cases then the string representing 0 would be the empty string,
> and obviously that would be si
We have to regard 0 as a special case, I don't think there's any point
in pretending otherwise. If all leading zeros were stripped off in
all cases then the string representing 0 would be the empty string,
and obviously that would be silly.
I went to see what the degree of the 0 polynomial is in
On Apr 3, 7:37 am, Alex Ghitza <[EMAIL PROTECTED]> wrote:
> I guess this is a question of convention, and depends on how you think
> of "digit":
>
> (1) a digit is a symbol used to construct representations of numbers,
> and so the base 10 digits are: "0", "1", ..., "9". In this case,
> 0.ndigits
On Thursday 03 April 2008 10:37, Alex Ghitza wrote:
> Note that at the moment 0.digits() does (2) and 0.ndigits() does (1),
> which is really bad.
Yes, this is very bad. I was not aware of the ndigits convention until after
the digits patch I wrote was included. On this topic, we also need a v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joel B. Mohler wrote:
|
| Since I was the last person to touch the digits method, I'll state my
case.
| Note that digits was (I think) inconsistent in this regard before my
| modifications -- I believe binary was different than other bases, but
I don'
On Apr 3, 2008, at 10:05 AM, Joel B. Mohler wrote:
> I intentionally made 0.digits() return [] because that seems to me
> the most
> consistent mathematical thing to do.
+1
david
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegro
On Thursday 03 April 2008 08:51, vgermrk wrote:
> Hi! I want to hear your opinions about a little problem.
>
> The following bug is already reported as #2232:
> "1.digits(16,'0123456789abcdef')" returns "['1']"
> but "0.digits(16,'0123456789abcdef')" returns "[]" (and not "['0']"
> as i wish)
S
11 matches
Mail list logo