Alex Strickland wrote:
How does that work?
Thanks for the replies. On rereading my post it sounded it a bit trollish, but
on reexamining my motives, maybe I meant to be :)
Regards
Alex
On Sun, 11 Apr 2010 00:30:07 -0400, Steven Schveighoffer
wrote:
Signed is probably trickier, suppose one is always negative and one is
always positive!
Turns out signed is really easy once you have unsigned solved.
Here is minor and maxor for signed assuming unsigned is solved:
int maxor
On 04/11/2010 09:18 PM, Adam D. Ruppe wrote:
On Sun, Apr 11, 2010 at 10:00:41PM -0400, Steven Schveighoffer wrote:
We are talking about range propagation, a function of the compiler, not a
function of the compiled program. Therefore, slower but more exact functions
should be preferred, since
On 04/11/2010 10:07 PM, Steven Schveighoffer wrote:
[snip]
I'll work on signed values tomorrow :)
This is great work, Steve!
Andrei
On Mon, 12 Apr 2010 01:11:37 -0400, Rainer Deyke
wrote:
On 4/11/2010 20:51, Steven Schveighoffer wrote:
Range propagation is needed to determine if you can put a value into a
smaller type. At that point, all that is needed is the min and max.
Technically, you don't even need min and max a
This topic came up several times already, but I recently thought about
it again, and I think that there is an improvement that could be done.
There are people that dislike the idea of signed-> unsigned conversion,
I am not one of those.
I think that it is very useful.
For example 2u-1 will giv
On 2010-04-12 15:19:28 +0200, Fawzi Mohamed said:
1UL+(1u-1)
ehm my example should (obviously?) have been
1UL+(1u-2)
sorry about the mistake
Ali Çehreli wrote:
> Jérôme M. Berger wrote:
>> Ali Çehreli wrote:
>>> � wrote:
>>>
The idea is to build a value that is between minA and maxA and will
set as many bits as possible when or'ed with maxB:
>>> The assumption that maxB would be the value that produces the maximum
>>> a|b is
Steven Schveighoffer wrote:
> J�r�me M. Berger Wrote:
>
>> J�r�me M. Berger wrote:
>>> OK, I found a solution that is optimal in over 99% of the cases
>>> (99.195% to be precise), while still being fast (because it avoids
>>> looping over the bits):
>>>
>> I've run my function and Andrei'
Steven Schveighoffer wrote:
> I'll work on signed values tomorrow :)
>
Signed values are trivial:
int maxOr (int minA, int minB, int maxA, int maxB)
{
if ((minA < 0) && (maxA >= 0))
return max (maxOr (minA, minB, -1, maxB),
maxOr (0, minB, maxA, maxB));
if (
Steven Schveighoffer wrote:
> On Sun, 11 Apr 2010 22:36:33 -0400, Rainer Deyke
> wrote:
>
>> On 4/11/2010 13:16, Ali Çehreli wrote:
>>> Rainer Deyke wrote:
>>>
The intention of fill_bits is to create a number that contains all of
the bits of all of the numbers from min_v to max_v.
>>>
>
Jérôme M. Berger wrote:
>> Your function reports 0b_111 for these set of values:
>>
>> min_a = 5;
>> max_a = 6;
>> min_b = 4;
>> max_b = 4;
>>
>> But the maximum value of a|b is 6.
>>
>Yes, like I said with my code, it is conservative. It will give the
> optima
Here's a fast 100% precise solution:
==8<--
uint32_t maxOr (uint32_t minA, uint32_t minB,
uint32_t maxA, uint32_t maxB)
{
assert (minA <= maxA);
assert (minB <= maxB);
if (maxA == 0) return maxB;
if (maxB
Andrei Alexandrescu wrote:
> On 04/11/2010 09:18 PM, Adam D. Ruppe wrote:
>> On Sun, Apr 11, 2010 at 10:00:41PM -0400, Steven Schveighoffer wrote:
>>> We are talking about range propagation, a function of the compiler,
>>> not a function of the compiled program. Therefore, slower but more
>>> exac
Chris Mueller wrote:
>> On what OS? On linux, you can do:
>>
>> time foo
>> to get the run time for program foo, including elapsed clock time,
>> time spent in the program itself and time spent in the kernel on
>> behalf of the program (for I/O, mallocs, etc);
>>
>> cat /proc/$(pidof foo)/statu
Dnia 08-04-2010 o 01:01:03 bearophile
napisał(a):
Adding D1 with LDC to Google code Jam accepted languages?
It starts now, but there is time to add it still, I think.
I recall the Tango people wanted to put D1 to Google Summer of Code and
failed several times. Is code jam sth way differen
Tomek Sowiñski:
> Is code jam sth way different than GSoC?
> http://www.dsource.org/projects/tango/wiki/GsocIdeas
They are two quite different things. Summer of Code means google paying some
people to develop and improve some part of the D ecosystem. Google Code Jam is
an online programming comp
Jérôme M. Berger wrote:
Steven Schveighoffer wrote:
On Sun, 11 Apr 2010 22:36:33 -0400, Rainer Deyke
wrote:
On 4/11/2010 13:16, Ali Çehreli wrote:
Rainer Deyke wrote:
The intention of fill_bits is to create a number that contains all of
the bits of all of the numbers from min_v to max_v.
On Mon, 12 Apr 2010 13:45:14 -0400, Jérôme M. Berger
wrote:
Steven Schveighoffer wrote:
J�r�me M. Berger Wrote:
J�r�me M. Berger wrote:
OK, I found a solution that is optimal in over 99% of the cases
(99.195% to be precise), while still being fast (because it avoids
looping over t
On Mon, 12 Apr 2010 13:56:23 -0400, Jérôme M. Berger
wrote:
Here's a fast 100% precise solution:
==8<--
uint32_t maxOr (uint32_t minA, uint32_t minB,
uint32_t maxA, uint32_t maxB)
{
assert (minA <= maxA);
a
Don wrote:
> Jérôme M. Berger wrote:
>> Steven Schveighoffer wrote:
>>> On Sun, 11 Apr 2010 22:36:33 -0400, Rainer Deyke
>>> wrote:
On 4/11/2010 13:16, Ali Çehreli wrote:
> Rainer Deyke wrote:
If you want 100% percent accuracy then you probably shouldn't be using
(min, max) pair
Steven Schveighoffer wrote:
> On Mon, 12 Apr 2010 13:45:14 -0400, Jérôme M. Berger
> wrote:
>
>> We are talking about range propagation, a function of the compiler,
>> not a function of the compiled program. Since we can't get a 100%
>> accurate representation of the possible values anyway (e
Steven Schveighoffer wrote:
> Fails for test case:
>
> minA = 4, maxA = 4, minB = 4, maxB = 6 (outputs 7, accurate result is 6).
>
Nope, outputs 6. Note that I've run an exhaustive search for all
combinations in the [0, 63] range, so if there are mistakes they
have to be outside that rang
Robert Clipsham wrote:
It's a shame I can't make it to ACCU next week, I'd love to see your
compiler construction session, if only for a few insights into how you
managed this! Do you have any tips for keeping compilation speedy, or is
it just a process of profiling and experience to find what
Jérôme M. Berger wrote:
Steven Schveighoffer wrote:
Fails for test case:
minA = 4, maxA = 4, minB = 4, maxB = 6 (outputs 7, accurate result is 6).
Nope, outputs 6. Note that I've run an exhaustive search for all
combinations in the [0, 63] range, so if there are mistakes they
have to
cpp lexer folding in scintilla always seemed bizarre to me and I tried to
implement folding algorithm similar to that of akelpad or editplus.
https://sourceforge.net/tracker/?func=detail&aid=2986054&group_id=2439&atid=352439
What do you think?
maXmo Wrote:
> cpp lexer folding in scintilla always seemed bizarre to me and I tried to
> implement folding algorithm similar to that of akelpad or editplus.
>
> https://sourceforge.net/tracker/?func=detail&aid=2986054&group_id=2439&atid=352439
>
> What do you think?
Personally, I would prefe
"maXmo" wrote in message
news:hq083d$2qp...@digitalmars.com...
> cpp lexer folding in scintilla always seemed bizarre to me and I tried to
> implement folding algorithm similar to that of akelpad or editplus.
>
> https://sourceforge.net/tracker/?func=detail&aid=2986054&group_id=2439&atid=352439
Jérôme M. Berger Wrote:
> Steven Schveighoffer wrote:
> > Fails for test case:
> >
> > minA = 4, maxA = 4, minB = 4, maxB = 6 (outputs 7, accurate result is 6).
> >
> Nope, outputs 6. Note that I've run an exhaustive search for all
> combinations in the [0, 63] range, so if there are mis
Jérôme M. Berger Wrote:
> Steven Schveighoffer wrote:
> > When we're talking about the difference between O(1) and O(lgn), I'll
> > take accuracy over speed in my compiler any day.
> And when we're talking about the difference between 10s and 55s for
> a minimal loss of accuracy, which wil
Steven Schveighoffer Wrote:
> I'll have to double check, I thought I copied your code verbatim (I did
> switch around the arguments to be minA, maxA, minB, maxB to fit my test
> harness, and I changed the uint_32_t to uint). I'll check tomorrow at work
> where the computer I used to test is.
>
You don't need reset if you make the range a property of the list. Then
you would use `foreach( x ; list.elements )` or something.
Nick Sabalausky Wrote:
> "maXmo" wrote in message
> news:hq083d$2qp...@digitalmars.com...
> > cpp lexer folding in scintilla always seemed bizarre to me and I tried to
> > implement folding algorithm similar to that of akelpad or editplus.
> >
> > https://sourceforge.net/tracker/?func=detail&ai
Nick Sabalausky Wrote:
> I don't know if this is applicable or not, but one thing that drives me
> absolutely crazy is in Programmer's Notepad 2 is how collapsing this:
>
> foo
> {
> bar
> }
>
> Will collapse on the "{" line instead of the "foo" line. I hate that sooo
> much.
>
> Not sure i
Daniel Keep Wrote:
> You don't need reset if you make the range a property of the list. Then
> you would use `foreach( x ; list.elements )` or something.
In the List(T) code that I've shown there is a ListIterable struct and a
opSlice() that returns it. If you uncomment that part of the code you
"maXmo" wrote in message
news:hq0qrq$13p...@digitalmars.com...
> Nick Sabalausky Wrote:
>
>> "maXmo" wrote in message
>> news:hq083d$2qp...@digitalmars.com...
>> > cpp lexer folding in scintilla always seemed bizarre to me and I tried
>> > to
>> > implement folding algorithm similar to that of
36 matches
Mail list logo
