Re: [sage-support] Discrete Logarithm

[Johan S . H . Rosenkilde]

Hi Panos

In GF(p) then an element g is primitive if its embedding into ZZ is
coprime with p-1. Since Euclidean algorithm is so fast, you can test
this:

sage: p = Primes().next(2^2048) #long
sage: g1 = 3
sage: gcd(g1, p-1)
3
sage: g2 = 5
sage: gcd(g2, p-1)
1

So 3 is not a primitive element in GF(p) but 5 is. (Since 5 is also a
prime, you could also have done g2.divides(p-1) instead)

Best,
Johan


Panos Phronimos writes:

> Hello everyone,
>
> I am trying to calculate a primitive element (g) of a big Finite Field:
> GF(p) where p is prime number > 2^2048
>
> So then, i could share a secret integer (r) as: m=g^r, but it seems 
> impossible to calculate it with function primitive_element()
> Is there another way i can use to calculate it?
>
> Thanks in advance,
> Panos

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

[sage-support] Re: Sage says pdflatex it not on my path when it definitely is

[Jim Mooney]

On Thursday, May 4, 2017 at 5:02:57 PM UTC-7, Dima Pasechnik wrote:
>
> You can do the usual Linux administration things by logging into the Linux 
> console on the VM.
> See sections 5 and 6 in https://wiki.sagemath.org/SageAppliance/SageMath-7 
> for details.
>
> I think the new version for the VM should have all these things (pdflatex 
> and pandoc) 
> installed, as we really want the notebook converter to function.
>
> How and where do I find out when the new version for virtualbox is 
released, other than continuously checking the website. Is there an alert 
list or something? Also, when I install the new virtualbox sage is there a 
way to carry over my settings, or do I have to redo them all? 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

[sage-support] Re: new sagenb pre-release, please test

[Jim Mooney]

On Wednesday, May 10, 2017 at 7:12:29 AM UTC-7, Dima Pasechnik wrote:
>
> Please test ​https://github.com/sagemath/sagenb/tree/1.0.rc0 (copy of the 
> current master) before I go ahead with making a new Sage package. It works 
> for me following the instructions in HASKING (updated, to take care of 
> changed names and of the need to deal with mathjax).
>
> Report issues on github, please.
>
>
> Dima
>

When a new Sage is released is there a parallel release on virtualbox or 
does this take some time? 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

[sage-support] right click plot dropdown dead in Sage for virtualbox

[Jim Mooney]

I'm using Sage in virtualbox on win 8.1. When I right-click on a plot I get 
a dropdown, but it's dead. I can't use File to save the image, for 
instance. Is this normal in Sage for virtualbox or is there a fix?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

[sage-support] Embedding towers of number fields

[switzel]

Hello,

I would like to do this

K. = NumberField([x^2-2,x^2-5], embedding = [RR(sqrt(2)), 
RR(sqrt(5))])

but embedding towers of number fields seems not to be implemented (and 
fails without any warning). Here

https://ask.sagemath.org/question/25312/embeddings-in-numberfieldtower/

it is explained that sage does now about the possible embeddings:

K.embeddings(RR)

but I need to turn one of these into a coercion map. How can I do that?

Best,
Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

[sage-support] new sagenb pre-release, please test

[Dima Pasechnik]

Please test ​https://github.com/sagemath/sagenb/tree/1.0.rc0 (copy of the 
current master) before I go ahead with making a new Sage package. It works 
for me following the instructions in HASKING (updated, to take care of 
changed names and of the need to deal with mathjax).

Report issues on github, please.


Dima

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-support] Bounds in coding theory are still a mess

[Dima Pasechnik]

On Wednesday, May 10, 2017 at 12:17:25 PM UTC+1, Johan S. H. Rosenkilde 
wrote:
>
> Dima Pasechnik writes: 
> > Please note that that "completely unrelated" ticket was fixing the work 
> of 
> > your and David (?) GSoC mentee. 
> > (and part of it was David's himself, IIRC). 
> > Saying that you have nothing to do with it is, hmm, strange to me, 
> sorry. 
> > And you guys just fell totally silent there. 
> > It's nothing to do with offending or anything, it's just matter of 
> > responsibility of all the Sage developers 
> > that has to be taken seriously, otherwise we will end up with a lot of 
> > broken code. 
>
> The ticket was opened by our GSoC student in the warmup but he left it 
> unfinished (and unmerged) since he began his proper GSoC project. I was 
> not really involved with that. David decided to finish the ticket, which 
> it seems he did too hastily. When ACTIS was over, David mostly stopped 
> contributing to Sage (he got a new job); this is normal. Daniel Augot, 
> who had never himself before contributed to Sage, attempted to finish 
> the ticket during Review Days 3, with a lot of help from you. New 
> developers needing help with debugging is normal. No obviously broken 
> code was ever introduced into Sage. 
>

Well, it was an old doctest that made sure this error was caught.  A close 
call.


> > this is the usual error of open-source projects: "let's not fix our old 
> > bugs, but just rewrite it is all from scratch".   
>
> Generalisation. Sometimes that judgement is an error, sometimes it's 
> not. 
>

Unless there is a majority, or even better, a consensus, for doing this,
I'd much prefer improving the existing code. It's much more incremental,
and thus less error-prone (although more boring, of course).
 

>
> > This is a very hard undertaking, and the example of that "completely 
> > unrelated" ticket 
> > shows it all too well; few copies and pastes without thinking it all 
> over, 
> > and, oops, 
> > a hard to find bug: 
> > https://trac.sagemath.org/ticket/20787#comment:24 
>
> The bug came from one of the ways that #20787 *improved* Sage's 
> capabilities wrt. Golay codes, by hard-coding some of the 
> expensive-to-compute properties. It did not come from cut-and-pasting of 
> old code. 
>

Did I say "old code" here? No. It was copying and pasting high degree 
polynomials from somewhere
I have no idea about, see the removed function weight_enumerator() in

https://git.sagemath.org/sage.git/commit/?id=6bf9d4b11523aaf7fcf69dc73d87352eefb29a8b
 

>
> > Instead, I would say, adding more doctests and docs, auditing the old 
> code 
> > and fixing 
> > it if needed (some of it is more or less literal translation into Python 
> of 
> > old GAP Guava package, 
> > and reads quite non-Pythonic), is much more sensible. 
> > I did a bit of this on https://trac.sagemath.org/ticket/22961 (ready 
> for 
> > review now) 
>
> I'm still not arguing that wouldn't be good things to do, and you're 
> welcome to do them. I was merely suggesting something I found would add 
> more functionality to Sage. 
>
> > As long as no new code constructions have to be added, this is more of 
> > database-thing problem, easier than 
> > https://doi.org/10.1007/s10623-016-0264-x 
> > where we did add lots of tricky constructions. 
>
> AFAIK we are missing numerous code constructions and code manipulations. 
> To properly supersede codetables.de, we would also need the search 
> algorithm for finding good derived codes from base constructions. 
>

Well, yes, we need something like "best_code_sage_knows(*,linear=True)" 
function
for a given set of parameters.
IMHO much more urgent project than redoing from scratch what already is 
there. 
 
Cheers,
Dima

>
>
> Best, 
> Johan 
>
>
> Dima Pasechnik writes: 
>
> > On Wednesday, May 10, 2017 at 8:47:21 AM UTC+1, Johan S. H. Rosenkilde 
> > wrote: 
> >> 
> >> > Not that more recent additions to sage/coding are perfect, I recall 
> >> > spending time untangling the mess on 
> >> > https://trac.sagemath.org/ticket/20787 
> >> <
> https://www.google.com/url?q=https%3A%2F%2Ftrac.sagemath.org%2Fticket%2F20787&sa=D&sntz=1&usg=AFQjCNExN2h8OYzl3Fgqcq_SzWWgz8_PZg>
>  
>
> >> > more or less completely on my own,  which gives a good example on how 
> >> not 
> >> > to re-implement old functionality ;-) 
> >> 
> >> Did I personally offend you? Because it seems you're trying to offend 
> me 
> >> - mentioning a completely unrelated ticket, which I, mind, had nothing 
> >> to do with. 
> > 
> > 
> > Please note that that "completely unrelated" ticket was fixing the work 
> of 
> > your and David (?) GSoC mentee. 
> > (and part of it was David's himself, IIRC). 
> > Saying that you have nothing to do with it is, hmm, strange to me, 
> sorry. 
> > And you guys just fell totally silent there. 
> > It's nothing to do with offending or anything, it's just matter of 
> > responsibility of all the Sage developers 
> > that has to be taken seriously, otherwise we will end up with a 

Re: [sage-support] Bounds in coding theory are still a mess

[Johan S . H . Rosenkilde]

Dima Pasechnik writes:
> Please note that that "completely unrelated" ticket was fixing the work of 
> your and David (?) GSoC mentee.
> (and part of it was David's himself, IIRC).
> Saying that you have nothing to do with it is, hmm, strange to me, sorry. 
> And you guys just fell totally silent there. 
> It's nothing to do with offending or anything, it's just matter of 
> responsibility of all the Sage developers
> that has to be taken seriously, otherwise we will end up with a lot of 
> broken code.

The ticket was opened by our GSoC student in the warmup but he left it
unfinished (and unmerged) since he began his proper GSoC project. I was
not really involved with that. David decided to finish the ticket, which
it seems he did too hastily. When ACTIS was over, David mostly stopped
contributing to Sage (he got a new job); this is normal. Daniel Augot,
who had never himself before contributed to Sage, attempted to finish
the ticket during Review Days 3, with a lot of help from you. New
developers needing help with debugging is normal. No obviously broken
code was ever introduced into Sage.

> this is the usual error of open-source projects: "let's not fix our old 
> bugs, but just rewrite it is all from scratch".  

Generalisation. Sometimes that judgement is an error, sometimes it's
not.

> This is a very hard undertaking, and the example of that "completely 
> unrelated" ticket
> shows it all too well; few copies and pastes without thinking it all over, 
> and, oops,
> a hard to find bug:
> https://trac.sagemath.org/ticket/20787#comment:24

The bug came from one of the ways that #20787 *improved* Sage's
capabilities wrt. Golay codes, by hard-coding some of the
expensive-to-compute properties. It did not come from cut-and-pasting of
old code.

> Instead, I would say, adding more doctests and docs, auditing the old code 
> and fixing
> it if needed (some of it is more or less literal translation into Python of 
> old GAP Guava package,
> and reads quite non-Pythonic), is much more sensible.
> I did a bit of this on https://trac.sagemath.org/ticket/22961 (ready for 
> review now)

I'm still not arguing that wouldn't be good things to do, and you're
welcome to do them. I was merely suggesting something I found would add
more functionality to Sage.

> As long as no new code constructions have to be added, this is more of
> database-thing problem, easier than 
> https://doi.org/10.1007/s10623-016-0264-x
> where we did add lots of tricky constructions.

AFAIK we are missing numerous code constructions and code manipulations.
To properly supersede codetables.de, we would also need the search
algorithm for finding good derived codes from base constructions.


Best,
Johan


Dima Pasechnik writes:

> On Wednesday, May 10, 2017 at 8:47:21 AM UTC+1, Johan S. H. Rosenkilde 
> wrote:
>>
>> > Not that more recent additions to sage/coding are perfect, I recall 
>> > spending time untangling the mess on 
>> > https://trac.sagemath.org/ticket/20787 
>> 
>>  
>> > more or less completely on my own,  which gives a good example on how 
>> not 
>> > to re-implement old functionality ;-) 
>>
>> Did I personally offend you? Because it seems you're trying to offend me 
>> - mentioning a completely unrelated ticket, which I, mind, had nothing 
>> to do with. 
>
>
> Please note that that "completely unrelated" ticket was fixing the work of 
> your and David (?) GSoC mentee.
> (and part of it was David's himself, IIRC).
> Saying that you have nothing to do with it is, hmm, strange to me, sorry. 
> And you guys just fell totally silent there. 
> It's nothing to do with offending or anything, it's just matter of 
> responsibility of all the Sage developers
> that has to be taken seriously, otherwise we will end up with a lot of 
> broken code.
>  
>
>> IMHO it is quite evident that the code quality, doc quality 
>> and functionality of sage/coding went up a lot during ACTIS. 
>>
>
> I have no doubt about this, sure it was overall a great addition. 
>
>>
>> > How about we document what's undocumented 
>> > ... 
>>
>> Luckily we're each allowed to work on what we personally find rewarding. 
>>
>> > providing new interfaces to existing functions, but not replacing the 
>> code, 
>> > seems more meaningful 
>>
>> "meaningful" is subjective. If you want to improve Sage with a minimal 
>> effort, sure you're right. But there's multiple reasons for replacing 
>> the code completely. It has a crappy interface, it's not well-written, 
>> and my suggestion would enhance it's functionality a lot. 
>>
>> this is the usual error of open-source projects: "let's not fix our old 
> bugs, but just
> rewrite it is all from scratch".  
> This is a very hard undertaking, and the example of that "completely 
> unrelated" ticket
> shows it all too well; few copies and pastes without thinking it all over, 
> and, oops,
> a har

[sage-support] Re: Sage crash Report

[Dima Pasechnik]

at the bottom of the report you see


ImportError: libgfortran.so.3: cannot open shared object file: No such file or 
directory


You need to install libgfortran in order to fix this.

apt-get install libgfortran3

On Wednesday, May 10, 2017 at 9:26:59 AM UTC+1, Abhishek Kesarwani wrote:
>
>
> Hi,
>  
>  Whenever i trying to install sagemath on my ubuntu 17.04 it shows the 
> following error:
>
> Oops, Sage crashed. We do our best to make it stable, but...
>
> A crash report was automatically generated with the following information:
>   - A verbatim copy of the crash traceback.
>   - A copy of your input history during this session.
>   - Data on your current Sage configuration.
>
> It was left in the file named:
> '/home/abhishek/.sage/ipython-5.0.0/Sage_crash_report.txt'
> If you can email this file to the developers, the information in it will 
> help
> them in understanding and correcting the problem.
>
> You can mail it to: sage-support at sage-s...@googlegroups.com 
> 
> with the subject 'Sage Crash Report'.
>
> If you want to do it now, the following command will work (under Unix):
> mail -s 'Sage Crash Report' sage-s...@googlegroups.com  < 
> /home/abhishek/.sage/ipython-5.0.0/Sage_crash_report.txt
>
> To ensure accurate tracking of this issue, please file a report about it 
> at:
> http://trac.sagemath.org
> PLEASE HELP ME OUT FROM THIS PROBLEM.
>
> Thank you 
> -- 
> Abhishek Kesarwani
> (Research Scholar)
> Department of Mathematics
> Indian Institute of technology, Madras
> Chennai- 600036,Tamil Nadu
> Ph. 7499221918
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

[sage-support] Discrete Logarithm

[Panos Phronimos]

Hello everyone,

I am trying to calculate a primitive element (g) of a big Finite Field:
GF(p) where p is prime number > 2^2048

So then, i could share a secret integer (r) as: m=g^r, but it seems 
impossible to calculate it with function primitive_element()
Is there another way i can use to calculate it?

Thanks in advance,
Panos

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-support] Bounds in coding theory are still a mess

[Dima Pasechnik]

On Wednesday, May 10, 2017 at 8:47:21 AM UTC+1, Johan S. H. Rosenkilde 
wrote:
>
> > Not that more recent additions to sage/coding are perfect, I recall 
> > spending time untangling the mess on 
> > https://trac.sagemath.org/ticket/20787 
> 
>  
> > more or less completely on my own,  which gives a good example on how 
> not 
> > to re-implement old functionality ;-) 
>
> Did I personally offend you? Because it seems you're trying to offend me 
> - mentioning a completely unrelated ticket, which I, mind, had nothing 
> to do with. 


Please note that that "completely unrelated" ticket was fixing the work of 
your and David (?) GSoC mentee.
(and part of it was David's himself, IIRC).
Saying that you have nothing to do with it is, hmm, strange to me, sorry. 
And you guys just fell totally silent there. 
It's nothing to do with offending or anything, it's just matter of 
responsibility of all the Sage developers
that has to be taken seriously, otherwise we will end up with a lot of 
broken code.
 

> IMHO it is quite evident that the code quality, doc quality 
> and functionality of sage/coding went up a lot during ACTIS. 
>

I have no doubt about this, sure it was overall a great addition. 

>
> > How about we document what's undocumented 
> > ... 
>
> Luckily we're each allowed to work on what we personally find rewarding. 
>
> > providing new interfaces to existing functions, but not replacing the 
> code, 
> > seems more meaningful 
>
> "meaningful" is subjective. If you want to improve Sage with a minimal 
> effort, sure you're right. But there's multiple reasons for replacing 
> the code completely. It has a crappy interface, it's not well-written, 
> and my suggestion would enhance it's functionality a lot. 
>
> this is the usual error of open-source projects: "let's not fix our old 
bugs, but just
rewrite it is all from scratch".  
This is a very hard undertaking, and the example of that "completely 
unrelated" ticket
shows it all too well; few copies and pastes without thinking it all over, 
and, oops,
a hard to find bug:
https://trac.sagemath.org/ticket/20787#comment:24

Instead, I would say, adding more doctests and docs, auditing the old code 
and fixing
it if needed (some of it is more or less literal translation into Python of 
old GAP Guava package,
and reads quite non-Pythonic), is much more sensible.
I did a bit of this on https://trac.sagemath.org/ticket/22961 (ready for 
review now)

 

> > Most of these code bounds are more general than linear. 
> > While it might be that the focus of seemingly completed ACTIS INRIA Sage 
> > coding theory project 
> > was about linear codes, I don't think any special bias towards linear 
> codes 
> > is appropriate. 
>
> Either you misunderstand me or you're attacking me again; I'll assume 
> the first. ACTIS was about *algebraic* constructions and especially 
> efficient decoding - we mostly didn't care at all about general bounds 
> or general linear/non-linear codes (which were, functionality-wise in an 
> OK shape already). 
>
> There are bounds for general codes, and bounds for only linear codes. 
> All I'm suggesting is to have, aside from "best-code-bounds" *also* to 
> have a function for "best-linear-code-bounds", and stuff like that. If 
> you call that a bias towards linear code, then yes, I definitely think 
> that's appropriate, considering the major advantages and prevalence of 
> linear codes. 
>

I suppose I misunderstood; sorry.
Yes, sure, this would be a great addition; by the way, we have ready to be
used bounds functionality for additive codes as well.
 

>
> > Something we should do, I think, is to provide as much of what, 
> currently 
> > hardly updated any more, http://codetables.de/ 
> > ... 
>
> Note that codetables.de has constructive lower bounds, on top of the 
> upper-bounds. Replacing codetables.de is a *huge* undertaking - 
> especially the constructions - requiring Nathann'esque ardour. I 
> completely agree that it would be great if Sage had this, but it's 
> hardly on the same scale as improving the small set of bounds we 
> currently support in Sage (which we'd need in any case). 
>

As long as no new code constructions have to be added, this is more of
database-thing problem, easier than 
https://doi.org/10.1007/s10623-016-0264-x
where we did add lots of tricky constructions.

 

>
> Best, 
> Johan 
>
>
>
> Dima Pasechnik writes: 
>
> > On Tuesday, May 9, 2017 at 9:41:46 AM UTC+1, Johan S. H. Rosenkilde 
> wrote: 
> >> 
> >> 'Peter Mueller' via sage-support writes: 
> >> 
> >> > The functions and their docs in codes.bounds.* still seem to be a 
> mess 
> >> (as 
> >> > they have been since many years now). (...) 
> >> 
> >> Indeed, these bounds are a catastrophe. Names, order of parameters, and 
> >> documentation is sorely lacking. In particular, none of the docs 
> >> describe whether t

[sage-support] Sage crash Report

[Abhishek Kesarwani]

Hi,

 Whenever i trying to install sagemath on my ubuntu 17.04 it shows the
following error:

Oops, Sage crashed. We do our best to make it stable, but...

A crash report was automatically generated with the following information:
  - A verbatim copy of the crash traceback.
  - A copy of your input history during this session.
  - Data on your current Sage configuration.

It was left in the file named:
'/home/abhishek/.sage/ipython-5.0.0/Sage_crash_report.txt'
If you can email this file to the developers, the information in it will
help
them in understanding and correcting the problem.

You can mail it to: sage-support at sage-support@googlegroups.com
with the subject 'Sage Crash Report'.

If you want to do it now, the following command will work (under Unix):
mail -s 'Sage Crash Report' sage-support@googlegroups.com <
/home/abhishek/.sage/ipython-5.0.0/Sage_crash_report.txt

To ensure accurate tracking of this issue, please file a report about it at:
http://trac.sagemath.org
PLEASE HELP ME OUT FROM THIS PROBLEM.

Thank you
-- 
Abhishek Kesarwani
(Research Scholar)
Department of Mathematics
Indian Institute of technology, Madras
Chennai- 600036,Tamil Nadu
Ph. 7499221918

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
***

IPython post-mortem report

{'commit_hash': u'5c9c918',
 'commit_source': 'installation',
 'default_encoding': 'UTF-8',
 'ipython_path': 
'/home/abhishek/Downloads/SageMath/local/lib/python2.7/site-packages/IPython',
 'ipython_version': '5.1.0',
 'os_name': 'posix',
 'platform': 'Linux-4.10.0-19-generic-x86_64-with-debian-stretch-sid',
 'sys_executable': '/home/abhishek/Downloads/SageMath/local/bin/python',
 'sys_platform': 'linux2',
 'sys_version': '2.7.13 (default, Mar 26 2017, 06:36:11) \n[GCC 5.4.0 
20160609]'}

***



***

Crash traceback:

---
---
ImportErrorPython 2.7.13: /home/abhishek/Downloads/SageMath/local/bin/python
   Thu May 11 12:43:28 2017
A problem occurred executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.
/home/abhishek/Downloads/SageMath/src/bin/sage-ipython in ()
  1 #!/usr/bin/env python
  2 # -*- coding: utf-8 -*-
  3 """
  4 Sage IPython startup script.
  5 """
  6 
  7 from sage.repl.interpreter import SageTerminalApp
  8 
  9 app = SageTerminalApp.instance()
---> 10 app.initialize()
global app.initialize = >
 11 app.start()

 in initialize(self=, argv=None)

/home/abhishek/Downloads/SageMath/local/lib/python2.7/site-packages/traitlets/config/application.pyc
 in catch_config_error(method=, 
app=, *args=(None,), **kwargs={})
 72 TRAITLETS_APPLICATION_RAISE_CONFIG_FILE_ERROR = False
 73 else:
 74 raise ValueError("Unsupported value for environment variable: 
'TRAITLETS_APPLICATION_RAISE_CONFIG_FILE_ERROR' is set to '%s' which is none of 
 {'0', '1', 'false', 'true', ''}."% _envvar )
 75 
 76 
 77 @decorator
 78 def catch_config_error(method, app, *args, **kwargs):
 79 """Method decorator for catching invalid config 
(Trait/ArgumentErrors) during init.
 80 
 81 On a TraitError (generally caused by bad config), this will print 
the trait's
 82 message, and exit the app.
 83 
 84 For use on init methods, to prevent invoking excepthook on invalid 
input.
 85 """
 86 try:
---> 87 return method(app, *args, **kwargs)
method = 
app = 
args = (None,)
kwargs = {}
 88 except (TraitError, ArgumentError) as e:
 89 app.print_help()
 90 app.log.fatal("Bad config encountered during initialization:")
 91 app.log.fatal(str(e))
 92 app.log.debug("Config at the time: %s", app.config)
 93 app.exit(1)
 94 
 95 
 96 class ApplicationError(Exception):
 97 pass
 98 
 99 
100 class LevelFormatter(logging.Formatter):
101 """Formatter with additional `highlevel` record
102 

/home/abhishek/Downloads/SageMath/local/lib/python2.7/site-packages/IPython/terminal/ipapp.pyc
 in initialize(self=, argv=None)
294 
295 return super(TerminalIPythonAp

Re: [sage-support] Bounds in coding theory are still a mess

[Johan S . H . Rosenkilde]

> Not that more recent additions to sage/coding are perfect, I recall 
> spending time untangling the mess on
> https://trac.sagemath.org/ticket/20787
> more or less completely on my own,  which gives a good example on how not 
> to re-implement old functionality ;-)

Did I personally offend you? Because it seems you're trying to offend me
- mentioning a completely unrelated ticket, which I, mind, had nothing
to do with. IMHO it is quite evident that the code quality, doc quality
and functionality of sage/coding went up a lot during ACTIS.

> How about we document what's undocumented 
> ...

Luckily we're each allowed to work on what we personally find rewarding.

> providing new interfaces to existing functions, but not replacing the code, 
> seems more meaningful

"meaningful" is subjective. If you want to improve Sage with a minimal
effort, sure you're right. But there's multiple reasons for replacing
the code completely. It has a crappy interface, it's not well-written,
and my suggestion would enhance it's functionality a lot.

> Most of these code bounds are more general than linear.
> While it might be that the focus of seemingly completed ACTIS INRIA Sage 
> coding theory project
> was about linear codes, I don't think any special bias towards linear codes 
> is appropriate.

Either you misunderstand me or you're attacking me again; I'll assume
the first. ACTIS was about *algebraic* constructions and especially
efficient decoding - we mostly didn't care at all about general bounds
or general linear/non-linear codes (which were, functionality-wise in an
OK shape already).

There are bounds for general codes, and bounds for only linear codes.
All I'm suggesting is to have, aside from "best-code-bounds" *also* to
have a function for "best-linear-code-bounds", and stuff like that. If
you call that a bias towards linear code, then yes, I definitely think
that's appropriate, considering the major advantages and prevalence of
linear codes.

> Something we should do, I think, is to provide as much of what, currently 
> hardly updated any more, http://codetables.de/
> ...

Note that codetables.de has constructive lower bounds, on top of the
upper-bounds. Replacing codetables.de is a *huge* undertaking -
especially the constructions - requiring Nathann'esque ardour. I
completely agree that it would be great if Sage had this, but it's
hardly on the same scale as improving the small set of bounds we
currently support in Sage (which we'd need in any case).

Best,
Johan



Dima Pasechnik writes:

> On Tuesday, May 9, 2017 at 9:41:46 AM UTC+1, Johan S. H. Rosenkilde wrote:
>>
>> 'Peter Mueller' via sage-support writes: 
>>
>> > The functions and their docs in codes.bounds.* still seem to be a mess 
>> (as 
>> > they have been since many years now). (...) 
>>
>> Indeed, these bounds are a catastrophe. Names, order of parameters, and 
>> documentation is sorely lacking. In particular, none of the docs 
>> describe whether the bounds hold for only linear codes or not. 
>>
>
> Not that more recent additions to sage/coding are perfect, I recall 
> spending time untangling the mess on
> https://trac.sagemath.org/ticket/20787
> more or less completely on my own,  which gives a good example on how not 
> to re-implement old functionality ;-)
>
>
> How about we document what's undocumented 
> on https://trac.sagemath.org/ticket/22961
> before deciding what to do then?
> (most of the stuff is on wikipedia, it's just trivial addition of links)
>  
>
>>
>> A way around the incompatibility issues is to completely replace the 
>> functions with a new set of functions with a more well-designed 
>> interface. For instance, each of the bounds can be used as bounds for 
>> any one of the code parameters, instead of just the dimension. Perhaps 
>> someone could think of a clever interface to allow this. Is there any 
>> precedence elsewhere in Sage? 
>>
>
> providing new interfaces to existing functions, but not replacing the code, 
> seems more meaningful
>
>
>> Then the entire current module could just be deprecated. 
>>
>> > (4) Again, there seem to be wrong bounds. For instance, 
>> >  codesize_upper_bound(19,10,2) yields 8, while there are easy examples 
>> of 
>> > size 16, and it is known that there are even codes of size 20. Looking 
>> into 
>> > the source code reveals that codesize_upper_bound erroneously uses the 
>> > Griesmer bound, which works for linear codes only. 
>>
>> The doc here is clearly very lacking. I think it makes sense to allow 
>> querying only for linear codes (over fields), as the focus of Sage's 
>> current functionality is firmly based here. 
>
>
> Most of these code bounds are more general than linear.
> While it might be that the focus of seemingly completed ACTIS INRIA Sage 
> coding theory project
> was about linear codes, I don't think any special bias towards linear codes 
> is appropriate.
>
> Something we should do, I think, is to provide as much of what, currently 
> hardly updated any more