In article <5533a77d$0$12993$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
>On Sun, 19 Apr 2015 04:08 am, Albert van der Horst wrote:
>
>> Fire up a lowlevel interpreter like Forth. (e.g. gforth)
>
>Yay! I'm not the only one who uses or likes Forth!
I'm an author of half a dozen im
On Mon, 20 Apr 2015 12:56 am, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Yay! I'm not the only one who uses or likes Forth!
>
> Out of interest, is Forth different from PostScript? I have done some
> small-time programming in PostScript but nothing in Forth.
Both Forth and PostScript are c
Steven D'Aprano writes:
> Have you tried Factor? I'm wondering if it is worth looking at, as a
> more modern and less low-level version of Forth.
Factor is basically Lisp with Forth-based syntax, from what I can tell.
Tagged objects, garbage collection, etc.
Forth is traditionally a self-hosted
On 04/19/2015 09:02 AM, Steven D'Aprano wrote:
On Sun, 19 Apr 2015 04:08 am, Albert van der Horst wrote:
Fire up a lowlevel interpreter like Forth. (e.g. gforth)
Yay! I'm not the only one who uses or likes Forth!
Have you tried Factor? I'm wondering if it is worth looking at, as a more
moder
On Sunday 19 April 2015 10:56:49 Marko Rauhamaa wrote:
> Steven D'Aprano :
> > Yay! I'm not the only one who uses or likes Forth!
>
> Out of interest, is Forth different from PostScript? I have done some
> small-time programming in PostScript but nothing in Forth.
>
>
> Marko
No relationship detec
Steven D'Aprano :
> Yay! I'm not the only one who uses or likes Forth!
Out of interest, is Forth different from PostScript? I have done some
small-time programming in PostScript but nothing in Forth.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, 19 Apr 2015 04:08 am, Albert van der Horst wrote:
> Fire up a lowlevel interpreter like Forth. (e.g. gforth)
Yay! I'm not the only one who uses or likes Forth!
Have you tried Factor? I'm wondering if it is worth looking at, as a more
modern and less low-level version of Forth.
--
Stev
In article ,
wrote:
>Den tisdag 7 april 2015 kl. 16:30:15 UTC+2 skrev Denis McMahon:
>> On Tue, 07 Apr 2015 09:29:59 -0400, Dave Angel wrote:
>>
>> > On 04/07/2015 05:44 AM, jonas.thornv...@gmail.com wrote:
>>
>> >> I want todo faster baseconversion for very big bases like base 1 000
>> >> 000, s
Steven D'Aprano :
> It's not so much the undefined behaviour part that gets me. That's bad
> enough. But the concept that having the compiler ignore what you write
> in the source code because you've accidentally hit some undefined part
> of the spec *is a feature* rather than a horrible, horrible
Chris Angelico :
> With applications languages, as earlier mentioned, none of this should
> be necessary. Sacrifice the performance and have arbitrary-precision
> integers, Unicode strings, garbage collection, and first-class
> lists/functions/mappings etc. This is only about lower-level
> languag
Steven D'Aprano :
> There are good ways to deal with out-of-range results in systems
> languages:
>
> - well-defined wrap-around behaviour;
> - saturation;
> - trapping.
Some months back I reported a bug in LXDE's CPU monitor applet: after a
couple of months of operation, the CPU monitor displaye
On Fri, Apr 10, 2015 at 3:41 AM, Steven D'Aprano
wrote:
> There are good ways to deal with out-of-range results in systems languages:
>
> - well-defined wrap-around behaviour;
> - saturation;
> - trapping.
>
> "Do whatever the hell the compiler feels like doing" is not one of them.
Systems langua
On Fri, Apr 10, 2015 at 3:35 AM, Steven D'Aprano
wrote:
> It's not so much the undefined behaviour part that gets me. That's bad
> enough. But the concept that having the compiler ignore what you write in
> the source code because you've accidentally hit some undefined part of the
> spec *is a fea
On Fri, 10 Apr 2015 02:36 am, Chris Angelico wrote:
> *According to the C standard*, you just did something impossible
Woo-hoo! I can do the impossible! Immovable objects? I juggle them like
rubber balls. Unstoppable forces? I don't even notice them. The very gods
themselves will fear me!
--
Chris Angelico :
> For low-level bit manipulation work, you usually want an *unsigned*
> integer of specific size, with well defined wrap-around behaviour.
> When do you actually want a signed integer with well-defined overflow
> behaviour?
Bit manipulation is not the issue here.
The reason for
On 2015-04-09, Chris Angelico wrote:
> On Fri, Apr 10, 2015 at 2:53 AM, Grant Edwards
> wrote:
>> On 2015-04-09, Chris Angelico wrote:
>>
>>> For application work, it's usually much better to have an integer
>>> type like Python's or Pike's int - a signed integer that can never
>>> overflow. Fo
On Fri, 10 Apr 2015 02:43 am, Chris Angelico wrote:
> For application work, it's usually much better to have an integer type
> like Python's or Pike's int - a signed integer that can never
> overflow. For low-level bit manipulation work, you usually want an
> unsigned integer of specific size, wit
On Fri, 10 Apr 2015 02:25 am, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> As far as it's concerned, it's impossible for a CPU register to
>> arbitrarily change without notice. It's equally impossible for the
>> addition of two positive signed integers to result in a negative
>> integer.
>
> Th
On 2015-04-09, Chris Angelico wrote:
> For application work, it's usually much better to have an integer
> type like Python's or Pike's int - a signed integer that can never
> overflow. For low-level bit manipulation work, you usually want an
> *unsigned* integer of specific size, with well defin
On Fri, Apr 10, 2015 at 2:53 AM, Grant Edwards wrote:
> On 2015-04-09, Chris Angelico wrote:
>
>> For application work, it's usually much better to have an integer
>> type like Python's or Pike's int - a signed integer that can never
>> overflow. For low-level bit manipulation work, you usually w
On Fri, Apr 10, 2015 at 2:25 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> As far as it's concerned, it's impossible for a CPU register to
>> arbitrarily change without notice. It's equally impossible for the
>> addition of two positive signed integers to result in a negative
>> integer.
>
> T
On 2015-04-09 16:21, Steven D'Aprano wrote:
On Fri, 10 Apr 2015 01:02 am, Chris Angelico wrote:
On Fri, Apr 10, 2015 at 12:53 AM, Alain Ketterlin
wrote:
Ouch, you're right, I tried to stick with Marko's example and forgot the
basics. I meant "signed ints", but the "removable" condition should
On Fri, Apr 10, 2015 at 2:15 AM, Steven D'Aprano
wrote:
> On Fri, 10 Apr 2015 01:34 am, Chris Angelico wrote:
>
>> It's equally impossible for the addition of two positive signed
>> integers to result in a negative integer.
>
> Why oh why do C programmers tell such porkies??? *semi-wink*
>
> [stev
On Thu, Apr 9, 2015 at 9:21 AM, wrote:
> And i know for a fact
What do you know for a fact?
> (i've factored RSA in the 200 digit range on a 486 in a couple of hours 98-)
Bullshit. RSA-200 wasn't factored until 2005, and the group that did
it required three months on a cluster of 80 2.2-GHz Op
Chris Angelico :
> As far as it's concerned, it's impossible for a CPU register to
> arbitrarily change without notice. It's equally impossible for the
> addition of two positive signed integers to result in a negative
> integer.
The standard says that any program that takes a signed integer out
On Fri, 10 Apr 2015 01:34 am, Chris Angelico wrote:
> It's equally impossible for the addition of two positive signed
> integers to result in a negative integer.
Why oh why do C programmers tell such porkies??? *semi-wink*
[steve@ando c]$ gcc add.c
[steve@ando c]$ ./a.out
a = 1
b = 2147483647
a+
On Fri, Apr 10, 2015 at 1:21 AM, Steven D'Aprano
wrote:
> On Fri, 10 Apr 2015 01:02 am, Chris Angelico wrote:
>
>> On Fri, Apr 10, 2015 at 12:53 AM, Alain Ketterlin
>> wrote:
>>> Ouch, you're right, I tried to stick with Marko's example and forgot the
>>> basics. I meant "signed ints", but the "r
On Fri, Apr 10, 2015 at 1:11 AM, Steven D'Aprano
wrote:
> On Thu, 9 Apr 2015 11:33 pm, Marko Rauhamaa wrote:
>
>> In this day and age, heavily optimized compilers (including gcc)
>> actively exploit undefined behavior in code generation.
>
> Optimization and undefined behaviour reminds me of a sto
On Fri, 10 Apr 2015 01:02 am, Chris Angelico wrote:
> On Fri, Apr 10, 2015 at 12:53 AM, Alain Ketterlin
> wrote:
>> Ouch, you're right, I tried to stick with Marko's example and forgot the
>> basics. I meant "signed ints", but the "removable" condition should be
>> something like:
>>
>> if (
Den torsdag 9 april 2015 kl. 17:04:53 UTC+2 skrev Ian:
> On Thu, Apr 9, 2015 at 8:54 AM, wrote:
> > Aside from the base changer i've written a bignumb anybase generic
> > multiplication, addition and subtraction routine. My goal is to make the
> > arithmetic in the base of choice whatever size.
On Thu, 9 Apr 2015 11:33 pm, Marko Rauhamaa wrote:
> In this day and age, heavily optimized compilers (including gcc)
> actively exploit undefined behavior in code generation.
Optimization and undefined behaviour reminds me of a story my wife told me,
of a time she was crossing the US with some r
Den torsdag 9 april 2015 kl. 17:02:24 UTC+2 skrev Chris Angelico:
> On Fri, Apr 10, 2015 at 12:53 AM, Alain Ketterlin
> wrote:
> > Ouch, you're right, I tried to stick with Marko's example and forgot the
> > basics. I meant "signed ints", but the "removable" condition should be
> > something like:
On Thu, Apr 9, 2015 at 8:54 AM, wrote:
> Aside from the base changer i've written a bignumb anybase generic
> multiplication, addition and subtraction routine. My goal is to make the
> arithmetic in the base of choice whatever size.
>
> And i think i can do it, i already have mult, add , subt w
On Fri, Apr 10, 2015 at 12:53 AM, Alain Ketterlin
wrote:
> Ouch, you're right, I tried to stick with Marko's example and forgot the
> basics. I meant "signed ints", but the "removable" condition should be
> something like:
>
> if ( x>0 && y>0 && z ...
>
> i.e., some condition that is n
Chris Angelico writes:
> On Thu, Apr 9, 2015 at 11:57 PM, Alain Ketterlin
> wrote:
>> Because, in:
>>
>> z = x+y; // all signed ints
>> if ( z < x )
>> ...
>>
>> either there was no overflow (and the condition is false), or there was,
>> and the result is undefined, i.e., "z
> Do
Den torsdag 9 april 2015 kl. 16:08:48 UTC+2 skrev Chris Angelico:
> On Thu, Apr 9, 2015 at 11:57 PM, Alain Ketterlin
> wrote:
> > Because, in:
> >
> > z = x+y; // all signed ints
> > if ( z < x )
> > ...
> >
> > either there was no overflow (and the condition is false), or there wa
On Thu, Apr 9, 2015 at 11:57 PM, Alain Ketterlin
wrote:
> Because, in:
>
> z = x+y; // all signed ints
> if ( z < x )
> ...
>
> either there was no overflow (and the condition is false), or there was,
> and the result is undefined, i.e., "zhttps://mail.python.org/mailman/listinfo/p
Marko Rauhamaa writes:
> Dave Angel :
>
>> So the C standard can specify such things as undefined. The
>> architecture still will do something specific, right or wrong, and
>> that's what Marko's claim was about. The C compiler has separate types
>> for unsigned and for signed, while the underlyi
Marko Rauhamaa :
> In this day and age, heavily optimized compilers (including gcc)
> actively exploit undefined behavior in code generation.
Example: Find the value of INT_MAX programmatically.
#include
int main()
{
Dave Angel :
> So the C standard can specify such things as undefined. The
> architecture still will do something specific, right or wrong, and
> that's what Marko's claim was about. The C compiler has separate types
> for unsigned and for signed, while the underlying architecture of
> every twos
Alain Ketterlin :
> Marko Rauhamaa writes:
>
>> Alain Ketterlin :
>>
>>> No, it would not work for signed integers (i.e., with lo and hi of
>>> int64_t type), because overflow is undefined behavior for signed.
>>
>> All architectures I've ever had dealings with have used 2's-complement
>> integer
On 04/09/2015 08:56 AM, Alain Ketterlin wrote:
Marko Rauhamaa writes:
Alain Ketterlin :
No, it would not work for signed integers (i.e., with lo and hi of
int64_t type), because overflow is undefined behavior for signed.
All architectures I've ever had dealings with have used 2's-complemen
Marko Rauhamaa writes:
> Alain Ketterlin :
>
>> No, it would not work for signed integers (i.e., with lo and hi of
>> int64_t type), because overflow is undefined behavior for signed.
>
> All architectures I've ever had dealings with have used 2's-complement
> integers. Overflow is well-defined,
Alain Ketterlin :
> No, it would not work for signed integers (i.e., with lo and hi of
> int64_t type), because overflow is undefined behavior for signed.
All architectures I've ever had dealings with have used 2's-complement
integers. Overflow is well-defined, well-behaved and sign-independent
w
Marko Rauhamaa writes:
> The basic arithmetic algorithms are independent of the base.
Right.
> For example, here's how you can add two 128-bit integers in C using
> 64-bit digits:
>
> typedef struct {
> uint64_t lo, hi;
> } uint128_t;
>
> uint128_t add128(uint128_t x, uint12
BartC :
> On 08/04/2015 23:06, Marko Rauhamaa wrote:
>> Arithmetics is performed just like in elementary school.
>
> Not in the school I went to; we used decimal!
The basic arithmetic algorithms are independent of the base.
For example, here's how you can add two 128-bit integers in C using
64-b
On 08/04/2015 23:06, Marko Rauhamaa wrote:
BartC :
So the the number 3,012,345, in base 100, could represented in
text form as the two 'digit':
(3, 12345)
ie. 3*100 + 12345*1. In internal binary, each digit can just be
stored in the normal form, probably as one digit per 32-bit inte
On Thu, Apr 9, 2015 at 12:32 PM, Steven D'Aprano
wrote:
> - Realistically, who is going to use this?
Nobody. I was never suggesting it as a serious option; just threw it
out there as another dumb alternative :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, 8 Apr 2015 11:49 am, Chris Angelico wrote:
> You could use base 1,114,112 fairly readily in any decent modern
> programming language. That'll happily represent base one-million.
Well, not really...
Here is the breakdown of Unicode code points by category, as of Python 3.3:
# Other
Cc:
On Wed, Apr 8, 2015 at 3:06 PM, Marko Rauhamaa wrote:
> BartC :
>
>> So the the number 3,012,345, in base 100, could represented in
>> text form as the two 'digit':
>>
>> (3, 12345)
>>
>> ie. 3*100 + 12345*1. In internal binary, each digit can just be
>> stored in the normal form, probabl
BartC :
> So the the number 3,012,345, in base 100, could represented in
> text form as the two 'digit':
>
> (3, 12345)
>
> ie. 3*100 + 12345*1. In internal binary, each digit can just be
> stored in the normal form, probably as one digit per 32-bit integer.
>
> (I have a big integer libr
On 07/04/2015 23:57, Steven D'Aprano wrote:
On Tue, 7 Apr 2015 07:44 pm, jonas.thornv...@gmail.com wrote:
I want todo faster baseconversion for very big bases like base 1 000 000,
so instead of adding up digits i search it.
What digits would you use for base one-million?
Base 2 uses 0 1.
Ba
On 08/04/2015 20:28, jonas.thornv...@gmail.com wrote:
Den onsdag 8 april 2015 kl. 19:34:39 UTC+2 skrev Mel Wilson:
On Wed, 08 Apr 2015 07:56:05 -0700, jonas.thornvall wrote:
There is no need for inventing a new set of characters representing
32-bit numbers. You will not be able to learn them b
On 08/04/2015 20:36, jonas.thornv...@gmail.com wrote:
Den onsdag 8 april 2015 kl. 21:28:34 UTC+2 skrev jonas.t...@gmail.com:
Den onsdag 8 april 2015 kl. 19:34:39 UTC+2 skrev Mel Wilson:
On Wed, 08 Apr 2015 07:56:05 -0700, jonas.thornvall wrote:
There is no need for inventing a new set of char
Den onsdag 8 april 2015 kl. 21:28:34 UTC+2 skrev jonas.t...@gmail.com:
> Den onsdag 8 april 2015 kl. 19:34:39 UTC+2 skrev Mel Wilson:
> > On Wed, 08 Apr 2015 07:56:05 -0700, jonas.thornvall wrote:
> >
> > > There is no need for inventing a new set of characters representing
> > > 32-bit numbers. Y
Den onsdag 8 april 2015 kl. 19:34:39 UTC+2 skrev Mel Wilson:
> On Wed, 08 Apr 2015 07:56:05 -0700, jonas.thornvall wrote:
>
> > There is no need for inventing a new set of characters representing
> > 32-bit numbers. You will not be able to learn them by heart anyway,
> > unless they build on a int
On Wed, 08 Apr 2015 07:56:05 -0700, jonas.thornvall wrote:
> There is no need for inventing a new set of characters representing
> 32-bit numbers. You will not be able to learn them by heart anyway,
> unless they build on a interpretation system binaries, decimals.
See Jorge Luis Borges, _Funes t
On Tue, 07 Apr 2015 23:18:14 -0700, wxjmfauth wrote:
> Le mercredi 8 avril 2015 08:08:04 UTC+2, wxjm...@gmail.com a écrit :
>> Le mercredi 8 avril 2015 00:57:27 UTC+2, Steven D'Aprano a écrit :
>> > On Tue, 7 Apr 2015 07:44 pm, jonas.thornv...@gmail.com wrote:
>> >
>> >
>> > > I want todo faster
Den onsdag 8 april 2015 kl. 15:40:46 UTC+2 skrev Mel Wilson:
> On Tue, 07 Apr 2015 23:19:49 -0700, jonas.thornvall wrote:
>
> > And you have just created 429496729 unique symbols ;), in a pencil
> > stroke.
>
> No. You did that, when you said base 429496729. Representing the
> symbols in a com
On Tue, Apr 7, 2015 at 7:18 PM, Steven D'Aprano
wrote:
> On Wed, 8 Apr 2015 10:38 am, Steven D'Aprano wrote:
>
>> On Wed, 8 Apr 2015 03:44 am, Ian Kelly wrote:
>>
>>
>>
> to_base(2932903594368438384328325832983294832483258958495845849584958458435439543858588435856958650865490,
>> 429496729
On Wed, Apr 8, 2015 at 1:28 AM, wrote:
> Den onsdag 8 april 2015 kl. 09:16:24 UTC+2 skrev Ian:
>> On Tue, Apr 7, 2015 at 4:35 PM, wrote:
>> > I am not sure you guys realised, that althoug the size of the factors to
>> > muliply expands according to base^(exp+1) for each digitplace the number
On Tue, 07 Apr 2015 23:19:49 -0700, jonas.thornvall wrote:
> And you have just created 429496729 unique symbols ;), in a pencil
> stroke.
No. You did that, when you said base 429496729. Representing the
symbols in a computer is no problem, any Python long int can do that. To
display the symb
Den onsdag 8 april 2015 kl. 09:16:24 UTC+2 skrev Ian:
> On Tue, Apr 7, 2015 at 4:35 PM, wrote:
> > I am not sure you guys realised, that althoug the size of the factors to
> > muliply expands according to base^(exp+1) for each digitplace the number of
> > comparissons needed to reach the digit
Den onsdag 8 april 2015 kl. 09:16:24 UTC+2 skrev Ian:
> On Tue, Apr 7, 2015 at 4:35 PM, wrote:
> > I am not sure you guys realised, that althoug the size of the factors to
> > muliply expands according to base^(exp+1) for each digitplace the number of
> > comparissons needed to reach the digit
On Tue, Apr 7, 2015 at 4:35 PM, wrote:
> I am not sure you guys realised, that althoug the size of the factors to
> muliply expands according to base^(exp+1) for each digitplace the number of
> comparissons needed to reach the digit place (multiple of base^exp+1) is
> constant with my approach
Den onsdag 8 april 2015 kl. 02:38:57 UTC+2 skrev Steven D'Aprano:
> On Wed, 8 Apr 2015 03:44 am, Ian Kelly wrote:
>
>
> to_base(2932903594368438384328325832983294832483258958495845849584958458435439543858588435856958650865490,
> 429496729)
> > [27626525, 286159541, 134919277, 305018215,
Den onsdag 8 april 2015 kl. 03:00:12 UTC+2 skrev Gregory Ewing:
> Steven D'Aprano wrote:
>
> > What digits would you use for base one-million?
>
> Interesting question. Unicode currently has about
> 75,000 CJK characters, so we would need to find about
> 12 more independently developed cultures w
Den onsdag 8 april 2015 kl. 00:57:27 UTC+2 skrev Steven D'Aprano:
> On Tue, 7 Apr 2015 07:44 pm, jonas.thornv...@gmail.com wrote:
>
>
> > I want todo faster baseconversion for very big bases like base 1 000 000,
> > so instead of adding up digits i search it.
>
> What digits would you use for ba
Steven D'Aprano :
> On Wed, 8 Apr 2015 03:07 am, jonas.thornv...@gmail.com wrote:
>> Using base 429496729?
>
> That makes no sense. With base 429496729 you need to have 429496729
> different digits.
You can use integers as digits. We already do that when we express times
and angles in base-60. I
On Wed, Apr 8, 2015 at 8:57 AM, Steven D'Aprano
wrote:
> On Tue, 7 Apr 2015 07:44 pm, jonas.thornv...@gmail.com wrote:
>
>
>> I want todo faster baseconversion for very big bases like base 1 000 000,
>> so instead of adding up digits i search it.
>
> What digits would you use for base one-million?
On Wed, Apr 8, 2015 at 8:51 AM, Steven D'Aprano
wrote:
> There hasn't been a machine in common use that used other than binary for
> integers for probably forty years now, and there has *never* been a PC that
> has used other than binary for integers. When you write 12345 as an integer
> in a prog
On 08/04/2015 01:59, Gregory Ewing wrote:
Steven D'Aprano wrote:
What digits would you use for base one-million?
Interesting question. Unicode currently has about
75,000 CJK characters, so we would need to find about
12 more independently developed cultures with similar
writing systems to get
On Wed, 8 Apr 2015 10:38 am, Steven D'Aprano wrote:
> On Wed, 8 Apr 2015 03:44 am, Ian Kelly wrote:
>
>
>
to_base(2932903594368438384328325832983294832483258958495845849584958458435439543858588435856958650865490,
> 429496729)
>> [27626525, 286159541, 134919277, 305018215, 329341598, 48181
Steven D'Aprano wrote:
What digits would you use for base one-million?
Interesting question. Unicode currently has about
75,000 CJK characters, so we would need to find about
12 more independently developed cultures with similar
writing systems to get enough characters. I suggest
revisiting th
jonas.thornv...@gmail.com wrote:
No i don't i say the operations assume base ten other wise INT A=7,B=4
Calculate C=A+B would not yield 11 as an answer.
The answer, when converted to base 10, will still be
11 regardless of the base in which the arithmetic is
performed.
For example, in base 2:
On Wed, 8 Apr 2015 03:44 am, Ian Kelly wrote:
to_base(2932903594368438384328325832983294832483258958495845849584958458435439543858588435856958650865490,
429496729)
> [27626525, 286159541, 134919277, 305018215, 329341598, 48181777,
> 79384857, 112868646, 221068759, 70871527, 416507001, 31
On 04/07/2015 06:35 PM, jonas.thornv...@gmail.com wrote:
Den tisdag 7 april 2015 kl. 21:27:20 UTC+2 skrev Ben Bacarisse:
Ian Kelly writes:
On Tue, Apr 7, 2015 at 12:55 PM, Terry Reedy wrote:
On 4/7/2015 1:44 PM, Ian Kelly wrote:
def to_base(number, base):
... digits = []
... whi
On Wed, 8 Apr 2015 03:07 am, jonas.thornv...@gmail.com wrote:
> So you can tell me the first (higest) digit of the integer
>
2932903594368438384328325832983294832483258958495845849584958458435439543858588435856958650865490
First digit:
py> s
=
'29329035943684383843283258329832948324832589584958
On Tue, Apr 7, 2015 at 4:55 PM, Steven D'Aprano
wrote:
> On Wed, 8 Apr 2015 12:32 am, Ian Kelly wrote:
>
>> On average, a random Oracle with a search space of 100 will need
>> 100 guesses.
>
> Surely on average it will only take 50 guesses?
>
> Best case is that it gets lucky the first
On Wed, 8 Apr 2015 12:32 am, Ian Kelly wrote:
> On average, a random Oracle with a search space of 100 will need
> 100 guesses.
Surely on average it will only take 50 guesses?
Best case is that it gets lucky the first time (1 guess). Worst case is that
it guesses every wrong answer u
On Tue, 7 Apr 2015 07:44 pm, jonas.thornv...@gmail.com wrote:
> I want todo faster baseconversion for very big bases like base 1 000 000,
> so instead of adding up digits i search it.
What digits would you use for base one-million?
Base 2 uses 0 1.
Base 3 uses 0 1 2.
Base 10 uses 0 1 2 3 4 5 6
On Wed, 8 Apr 2015 01:43 am, jonas.thornv...@gmail.com wrote:
> No that is not what i am saying, i am saying if you do operations on two
> integers the machine will assume base 10.
We understand what you are saying. You are simply WRONG.
There hasn't been a machine in common use that used other
On 08Apr2015 08:36, Steven D'Aprano
wrote:
On Wed, 8 Apr 2015 12:36 am, jonas.thornv...@gmail.com wrote:
Bullshit declare two integers in any language one 7 and one 4 and then
write x=7+4; if you find a programming language where that does not yield
11 tell me.
In Forth, you can set the base
Den tisdag 7 april 2015 kl. 21:27:20 UTC+2 skrev Ben Bacarisse:
> Ian Kelly writes:
>
> > On Tue, Apr 7, 2015 at 12:55 PM, Terry Reedy wrote:
> >> On 4/7/2015 1:44 PM, Ian Kelly wrote:
> >>
> >> def to_base(number, base):
> >>>
> >>> ... digits = []
> >>> ... while number > 0:
> >>>
On Wed, 8 Apr 2015 12:36 am, jonas.thornv...@gmail.com wrote:
> Bullshit declare two integers in any language one 7 and one 4 and then
> write x=7+4; if you find a programming language where that does not yield
> 11 tell me.
In Forth, you can set the base to any arbitrary integer (within reason).
On 07.04.15 22:28, Ian Kelly wrote:
On Tue, Apr 7, 2015 at 1:19 PM, Ian Kelly wrote:
On Tue, Apr 7, 2015 at 12:55 PM, Terry Reedy wrote:
% and probably // call divmod internally and toss one of the results.
Slightly faster (5.7 versus 6.1 microseconds on my machine) is
Not on my box.
$ pyt
On 07/04/2015 17:33, Dave Angel wrote:
On 04/07/2015 11:40 AM, jonas.thornv...@gmail.com wrote:
I haven't seen one line of Python from you yet, so perhaps you're just
yanking our chain.
This wouldn't surprise me, he's the guy who refused point blank to
modify his use of gg some 18 months ago
On Tue, Apr 7, 2015 at 9:40 AM, wrote:
> Well of course you use same principles like a binary search setting min and
> max, closing in on the digit. In this case the searched numbers > base^exp
> and number< base^exp+1.
>
> But since the search is within large bases upto 32-bit space, so base
Ian Kelly writes:
> On Tue, Apr 7, 2015 at 12:55 PM, Terry Reedy wrote:
>> On 4/7/2015 1:44 PM, Ian Kelly wrote:
>>
>> def to_base(number, base):
>>>
>>> ... digits = []
>>> ... while number > 0:
>>> ... digits.append(number % base)
>>> ... number //= base
>>> ...
On Tue, Apr 7, 2015 at 1:19 PM, Ian Kelly wrote:
> On Tue, Apr 7, 2015 at 12:55 PM, Terry Reedy wrote:
>> On 4/7/2015 1:44 PM, Ian Kelly wrote:
>>
>> def to_base(number, base):
>>>
>>> ... digits = []
>>> ... while number > 0:
>>> ... digits.append(number % base)
>>> ...
On Wed, Apr 8, 2015 at 5:19 AM, Ian Kelly wrote:
>> % and probably // call divmod internally and toss one of the results.
>> Slightly faster (5.7 versus 6.1 microseconds on my machine) is
>
> Not on my box.
>
> $ python3 -m timeit -s "n = 100; x = 42" "n % x; n // x"
> 1000 loops, best of
On Tue, Apr 7, 2015 at 12:55 PM, Terry Reedy wrote:
> On 4/7/2015 1:44 PM, Ian Kelly wrote:
>
> def to_base(number, base):
>>
>> ... digits = []
>> ... while number > 0:
>> ... digits.append(number % base)
>> ... number //= base
>> ... return digits or [0]
>> ...
>>
On 4/7/2015 1:44 PM, Ian Kelly wrote:
def to_base(number, base):
... digits = []
... while number > 0:
... digits.append(number % base)
... number //= base
... return digits or [0]
...
to_base(2932903594368438384328325832983294832483258958495845849584958458435439543
On Tue, Apr 7, 2015 at 11:07 AM, wrote:
> Den tisdag 7 april 2015 kl. 18:34:32 UTC+2 skrev Dave Angel:
>> Once again, there's no point in doing a search, when a simple integer
>> divide can give you the exact answer. And there's probably no point in
>> going left to right when right to left woul
Den tisdag 7 april 2015 kl. 18:34:32 UTC+2 skrev Dave Angel:
> On 04/07/2015 11:40 AM, jonas.thornv...@gmail.com wrote:
> > Den tisdag 7 april 2015 kl. 16:32:56 UTC+2 skrev Ian:
> >> On Tue, Apr 7, 2015 at 3:44 AM, wrote:
> >>>
> >>>
> >>> I want todo faster baseconversion for very big bases like
On 04/07/2015 11:40 AM, jonas.thornv...@gmail.com wrote:
Den tisdag 7 april 2015 kl. 16:32:56 UTC+2 skrev Ian:
On Tue, Apr 7, 2015 at 3:44 AM, wrote:
I want todo faster baseconversion for very big bases like base 1 000 000, so
instead of adding up digits i search it.
I need the fastest al
Den tisdag 7 april 2015 kl. 16:30:15 UTC+2 skrev Denis McMahon:
> On Tue, 07 Apr 2015 09:29:59 -0400, Dave Angel wrote:
>
> > On 04/07/2015 05:44 AM, jonas.thornv...@gmail.com wrote:
>
> >> I want todo faster baseconversion for very big bases like base 1 000
> >> 000, so instead of adding up digi
On 2015-04-07 16:05, Grant Edwards wrote:
On 2015-04-07, Chris Angelico wrote:
On Wed, Apr 8, 2015 at 12:36 AM, wrote:
Integers are internally assumed to be base 10 otherwise you could not
calculate without giving the base.
All operations on integers addition, subtraction, multiplication a
Den tisdag 7 april 2015 kl. 17:07:36 UTC+2 skrev Ian:
> On Tue, Apr 7, 2015 at 8:36 AM, wrote:
> > Den tisdag 7 april 2015 kl. 16:30:15 UTC+2 skrev Denis McMahon:
> >> On Tue, 07 Apr 2015 09:29:59 -0400, Dave Angel wrote:
> >>
> >> > On 04/07/2015 05:44 AM, jonas.thornv...@gmail.com wrote:
> >>
>
Den tisdag 7 april 2015 kl. 17:00:53 UTC+2 skrev MRAB:
> On 2015-04-07 15:36, jonas.thornv...@gmail.com wrote:
> > Den tisdag 7 april 2015 kl. 16:30:15 UTC+2 skrev Denis McMahon:
> >> On Tue, 07 Apr 2015 09:29:59 -0400, Dave Angel wrote:
> >>
> >>> On 04/07/2015 05:44 AM, jonas.thornv...@gmail.com
1 - 100 of 116 matches
Mail list logo
