I didn't doubt that what you do works, but even "unsigned char" isn't the
same as a unsigned 8-bit integer on every platform. Plus whoever will
contribute in the future is bound to trip over the same issue again,
omitting "unsigned" because its not necessary on i386. While "unsigned
char" is cl
Le 27/01/2012 19:14, Volker Braun a écrit :
Instead of sprinkling "unsigned" around until it works,
Well, that's not exactly what happened.
Once it was recognized that the problem was that the code was using
"char" thinking it meant "signed char" and that was wrong (surprise!),
then I checke
Instead of sprinkling "unsigned" around until it works, we should IMHO use
C99 integer types if the code assumes signedness and/or a particular bit
width for "char". Just include inttypes.h (C) or cinttypes (C++), then
int8_t is a signed 8-bit integer and uint8_t is an unsigned 8-bit integer.
-
> Well, no : this is an independent change and hence needs an independent
> patch.
Oh. Ok, well, it was juste one line and changed nothing to the code's behaviour.
> between 0 and the cardinal of the graph
> 1. add a "cdef unsigned char next_set" as an aside but related fix
>
> in a new ticket wi
Le 27/01/2012 18:08, Nathann Cohen a écrit :
I'm almost scared right now O_O
You'll be happy to learn (eh, I just learnt it this very afternoon) that the
C standards says that char can be either "unsigned char" or "signed char"...
so if you want to be safe, just use the most precise form.
Ok
>> I'm almost scared right now O_O
>
> You'll be happy to learn (eh, I just learnt it this very afternoon) that the
> C standards says that char can be either "unsigned char" or "signed char"...
> so if you want to be safe, just use the most precise form.
Ok now I'm scared O_O;;;
> Here is the ti
Le 27/01/2012 17:56, Dima Pasechnik a écrit :
Perhaps some other doctest failures on ARM are also related to unsigned
char business? E.g. the pickling problem might be also due to this
messing with bits
I'll get to this pickling problem sooner or later ; I've known it to be
there ever sinc
Le 27/01/2012 18:00, Nathann Cohen a écrit :
Wait... It means that on your platform the default "char" are unsigned ? O_o
I'm almost scared right now O_O
You'll be happy to learn (eh, I just learnt it this very afternoon) that
the C standards says that char can be either "unsigned char" or "s
Wait... It means that on your platform the default "char" are unsigned ? O_o
I'm almost scared right now O_O
Nathann
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options,
Very interesting!
Perhaps some other doctest failures on ARM are also related to unsigned
char business? E.g. the pickling problem might be also due to this messing
with bits
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an emai
Le 27/01/2012 17:14, Willem Jan Palenstijn a écrit :
On Fri, Jan 27, 2012 at 05:07:56PM +0100, Julien Puydt wrote:
Le 27/01/2012 17:02, Julien Puydt a écrit :
Le 27/01/2012 16:52, Willem Jan Palenstijn a écrit :
Is char signed or unsigned on your platform?
Good question ; how do I find out?
On Fri, Jan 27, 2012 at 05:07:56PM +0100, Julien Puydt wrote:
> Le 27/01/2012 17:02, Julien Puydt a écrit :
> >Le 27/01/2012 16:52, Willem Jan Palenstijn a écrit :
> >>Is char signed or unsigned on your platform?
> >
> >Good question ; how do I find out?
>
> If I put the following in test.c :
>
>
Le 27/01/2012 17:02, Julien Puydt a écrit :
Le 27/01/2012 16:52, Willem Jan Palenstijn a écrit :
Is char signed or unsigned on your platform?
Good question ; how do I find out?
If I put the following in test.c :
#include
#include
int
main()
{
printf ("%d\n", CHAR_MIN);
return 0;
}
Le 27/01/2012 16:52, Willem Jan Palenstijn a écrit :
On Fri, Jan 27, 2012 at 02:05:25PM +0100, Julien Puydt wrote:
Le 26/01/2012 10:53, Dima Pasechnik a écrit :
Is the popcount() there even big-endian/little-endian safe?
It's not obvious. As well, it will blow on architectures that have
a diffe
Le 27/01/2012 16:25, Nathann Cohen a écrit :
Hell !!
Anyway, I finally have sage-4.8 again on that box, and the result of using
the builtin popcount is that it still doesn't work.
Where do we go from that point on?
Hmmm O_o
Well, I read the code again and the only weird thing I was
On Fri, Jan 27, 2012 at 02:05:25PM +0100, Julien Puydt wrote:
> Le 26/01/2012 10:53, Dima Pasechnik a écrit :
> >Is the popcount() there even big-endian/little-endian safe?
> >It's not obvious. As well, it will blow on architectures that have
> >a different from x86 idea about the length of int...
Hell !!
> Anyway, I finally have sage-4.8 again on that box, and the result of using
> the builtin popcount is that it still doesn't work.
>
> Where do we go from that point on?
Hmmm O_o
Well, I read the code again and the only weird thing I was able to
find was that : the function find_
Le 26/01/2012 10:53, Dima Pasechnik a écrit :
Is the popcount() there even big-endian/little-endian safe?
It's not obvious. As well, it will blow on architectures that have
a different from x86 idea about the length of int...
So one quick test would be to use __builtin_popcount(i) and see if it
m
> Copyright issue?
For 4 lines of code in a forum thread, given as an answer to a guy
asking "how to code a popcount efficiently" ?
If this can be a copyright issue, by itself it is sufficient to say
that we would be better without copyrights :-p
Nathann
--
To post to this group, send an email
Le 26/01/2012 12:33, Nathann Cohen a écrit :
And I did not write this popcount myself, I found it on the (many)
pages on which everybody contributes with his own version of that code
:-D
Copyright issue?
Snark on #sagemath
--
To post to this group, send an email to sage-devel@googlegroups.com
Helloo !!
> I'm sure this is configurable, and it should be configured, when building
> Sage.
Hmmm. That would be GREAT. Definitely worth asking the wise guys
working on Cython.
> And, calling a (very fast) function is faster than using your code, anyway,
> IMHO.
Nonono, I remember I re
On Thursday, January 26, 2012 6:46:30 PM UTC+8, Nathann Cohen wrote:
>
> > Actually, newer Intel and AMD processors (I guess, ARM too) have POPCNT
> > wired in, so __builtin_popcount(), which is a gcc function, will beat
> your
> > implementation, as time goes by.
>
> Yep but there's a functio
> Actually, newer Intel and AMD processors (I guess, ARM too) have POPCNT
> wired in, so __builtin_popcount(), which is a gcc function, will beat your
> implementation, as time goes by.
Yep but there's a function call "becase" it is a function, while the
current one is inlined. I really have no
On Thursday, January 26, 2012 5:59:39 PM UTC+8, Nathann Cohen wrote:
>
> > So one quick test would be to use __builtin_popcount(i) and see if it
> makes
> > a difference...
>
> Yepyep It's commented in the code, actually. I used it on a
> machine which had the popcount instruction enable, b
> So one quick test would be to use __builtin_popcount(i) and see if it makes
> a difference...
Yepyep It's commented in the code, actually. I used it on a
machine which had the popcount instruction enable, but on others the
__builtin_popcount is slower that the current code. This being said,
Is the popcount() there even big-endian/little-endian safe?
It's not obvious. As well, it will blow on architectures that have
a different from x86 idea about the length of int...
So one quick test would be to use __builtin_popcount(i) and see if it
makes a difference...
--
To post to this g
Hell !!!
HMmmm... Yep, those two patches are pretty new (though the first one was
partly there before, it mainly moves some methods into a new module). This
being said, the second patch has no reason to call the functions defined in
the first. Actually the second was applied
Le 25/01/2012 17:32, Julien Puydt a écrit :
What bothers me is that the "exists" function looks quite portable, so
the reason of the failure is unclear.
What bothers me even more is that this file has a very short history :
$ hg log sage/graphs/graph_decompositions/vertex_separation.pyx
chang
Le 25/01/2012 17:14, Julien Puydt a écrit :
Le 25/01/2012 13:22, Julien Puydt a écrit :
(2) strange graph errors :
The good news is that if I put the following lines in a test_graphs.py
file, the problem is still there:
from sage.all import *
from sage.graphs.graph_decompositions.vertex_separ
Le 25/01/2012 13:22, Julien Puydt a écrit :
(2) strange graph errors :
The good news is that if I put the following lines in a test_graphs.py
file, the problem is still there:
from sage.all import *
from sage.graphs.graph_decompositions.vertex_separation import
vertex_separation
from sage.g
Le 25/01/2012 13:22, Julien Puydt a écrit :
sage -t --long -force_lib devel/sage/sage/interfaces/quit.py
**
File "/home/jpuydt/sage-4.8/devel/sage-main/sage/interfaces/quit.py",
line 116:
sage: a, b
Expected:
(2, 3)
Got:
(0(%o19)
Hi,
I ran sage-4.8 (with the flint-1.5.2 spkg)'s ptestlong :
Total time for all tests: 29104.6 seconds
There are three kinds of failures in the log :
(1) numerical uncertainty :
sage -t --long -force_lib devel/sage/sage/functions/other.py
**
32 matches
Mail list logo
