> On Jul 27, 11:58 am, John Cremona wrote:
> > My innocent posting to sage-devel on this subject two days ago seems
> > to have done something to increase the number of postings this month,
> > even if a lot of the discussion has been much wider than the orginal
> > title (Sage & Pari) suggests!
I cited Pari in a non-peer reviewed article today.
Bill.
On Jul 27, 11:58 am, John Cremona wrote:
> My innocent posting to sage-devel on this subject two days ago seems
> to have done something to increase the number of postings this month,
> even if a lot of the discussion has been much wider t
My innocent posting to sage-devel on this subject two days ago seems
to have done something to increase the number of postings this month,
even if a lot of the discussion has been much wider than the orginal
title (Sage & Pari) suggests!
John
--
To post to this group, send an email to sage-devel
Of course if you code is so dependent on CPU cycles then it is a good
candidate for assembly optimisation. After superoprimisation you might
hit the theoretical retirement rate of muops in which case you can
actually say something about how fast it will run. Integer arithmetic
is one such case.
In
On Wednesday, July 27, 2011 10:33:57 AM UTC+1, Bill Hart wrote:
>
> It's rarely possible to fully
> explain a cutoff without reference to the architecture, e.g.
> Instruction latency, caching, etc
Thats an understatement. The current state of CPUs makes it factually
impossible to precisely qua
Hi Tim,
Let me first say that I am a little embarrassed that you downloaded
Flint as a possible example of literate code. Reading my original post
I did seem to give that impression. Actually I was merely mentioning
it as an example of a documented system, not necessarily literate as
such.
I did
> > Again I have to credit Sebastian Pancratz and Fredrik Johansson here
> > for raising the standard in flint. I thought I had been producing
> > beautiful code until Sebastian started rewriting some of it for
> > me. :-)
I downloaded Flint and looked at the source code and documentation.
First
...[snip]...
> > In regular mathematics it is standard practice to fully document, that
> > is, show the complete proof of your findings. In computational maths
> > we do not do this. There is no particular reason why we don't except
> > that it is not the expected behavior.
>
> Unfortunately this
On Jul 26, 7:02 pm, daly wrote:
> On Tue, 2011-07-26 at 08:30 -0700, Bill Hart wrote:
> To paraphrase your above comment, I believe that we need to raise the
> standards of computational mathematics further toward being "a
> respectable sport".
>
> Consider your observation:
> "Of course p
On 7/26/11 11:03 AM, William Stein wrote:
(Sorry if anybody's favorite Sage component is missed in the attached
diagram -- these were just the notes for my talk, and the diagram I
actually drew was by hand with chalk and had ... below some spots to
emphasize incompleteness.)
Nice; I think it's
On Tue, 2011-07-26 at 08:30 -0700, Bill Hart wrote:
> Hi Simon,
>
...[snip]...
>
> Of course properly citing Pari and the algorithm used and checking
> under what conditions the result is meaningful, etc, assumes that
> these things are well documented and accessible. So, a positive step
> the P
On Jul 26, 5:59 pm, William Stein wrote:
> When doing such investigations, we care greatly that the data we get is
> correct. We just don't care so much that the program producing it be
> *proven* correct in a formal and technically rigorous sense.
I understand that you qualified that with "s
On Tue, Jul 26, 2011 at 9:00 AM, Bill Hart wrote:
>
> Regarding rigor, mathematics itself went through a phase where
> informal arguments were displaced with formal ones. Likewise, informal
> computer programs will eventually give way to formally verified ones,
> and this will naturally be embraced
On Jul 26, 1:51 am, rjf wrote:
> I hope that Bill was hoping to stir up some dissenting opinions.
Yes, naturally.
However, it looks to me that you have simply recorded the way things
currently are. People will do whatever they feel like. That's true by
definition.
Regarding rigor, mathematic
Hi Simon,
After reading what you wrote, I fully agree with you. Your distinction
between citing a citation and citing the original work is a useful
one. This would happen naturally if you focused on identifying the
algorithm and understanding its limitations, as I recommended. But
they way you hav
There seem to be two issues here.
1. It would be nice for Pari to get credit when Pari is used, even if
the
user gave credit to Sage.
and
2. (Bill Hart's assertion) that citing an algorithm that you haven't
studied
is like citing a paper you haven't read.
Regarding item 1. If you accept code und
Hi Bill,
let me comment on the "how to cite individual Sage components" topic.
On 26 Jul., 00:18, Bill Hart wrote:
> * Citing a Number Theory package you know nothing about in published
> research is about as dubious as citing a paper you have never read.
> Unless you are prepared to read the co
Can we please be more precise and scientific when discussing this
important issue. I find it confusing to try to think about the many
issues raised without some precision.
Some trivialities first. Please take care to distinguish:
* finding a bug in Pari and contributing a bug report
* finding a b
18 matches
Mail list logo
