On 10/2/22 09:24, Fausto via Digitalmars-d-learn wrote:
Thanks a lot. I am to used to C and, more important, I didn't think to look for
also another operator for the power function :)
Oh, and I forgot to mention that this is doing what you probably asked for
originally:
```d
import std;
imp
On 10/2/22 09:24, Fausto via Digitalmars-d-learn wrote:
Thanks a lot. I am to used to C and, more important, I didn't think to look for
also another operator for the power function :)
D does have pow and many other useful math functions [1], it's just not defined
for BitInts. Oh, and speakin
On Sunday, 2 October 2022 at 02:02:37 UTC, rassoc wrote:
On 10/2/22 00:04, Fausto via Digitalmars-d-learn wrote:
Hello,
I am trying to use pow with an integer argument, but I cannot
have a bigint result, for example, ```pow(10,72)```.
Do I have to write my pow function or is there a native
so
On 10/2/22 00:04, Fausto via Digitalmars-d-learn wrote:
Hello,
I am trying to use pow with an integer argument, but I cannot have a bigint
result, for example, ```pow(10,72)```.
Do I have to write my pow function or is there a native solution?
thanks,
Fausto
In contrast to certain scripting
On 8/9/17 9:08 PM, Steven Schveighoffer wrote:
Right, but this is not a limitation of the API, just the implementation.
It could be improved.
https://issues.dlang.org/show_bug.cgi?id=17736
Based on H.S. Teoh's comment in the bug report, this actually is invalid.
That's a tough requirement.
On 8/9/17 5:40 PM, H. S. Teoh via Digitalmars-d-learn wrote:
On Wed, Aug 09, 2017 at 09:34:26PM +, Q. Schroll via Digitalmars-d-learn
wrote:
On Friday, 4 August 2017 at 16:40:08 UTC, Stefan Koch wrote:
[..]
foreach(x;A .. B)
it's lowerd to
auto limit = B;
auto key = A;
for(auto x = key;ke
On Wed, Aug 09, 2017 at 09:34:26PM +, Q. Schroll via Digitalmars-d-learn
wrote:
> On Friday, 4 August 2017 at 16:40:08 UTC, Stefan Koch wrote:
> > [..]
> >
> > foreach(x;A .. B)
> > it's lowerd to
> > auto limit = B;
> > auto key = A;
> > for(auto x = key;key < limit;++key)
> > {
> > // use
On Friday, 4 August 2017 at 16:40:08 UTC, Stefan Koch wrote:
[..]
foreach(x;A .. B)
it's lowerd to
auto limit = B;
auto key = A;
for(auto x = key;key < limit;++key)
{
// use x
}
That's enough to know that the foreach loop does not reuse the
space for the iteration variable. That was what I c
On Friday, 4 August 2017 at 13:09:55 UTC, Steven Schveighoffer
wrote:
Any foreach range statement like this:
foreach(var; A .. B)
is treated as if you wrote:
for(auto var = A; var < B; ++var)
So it's pretty much exactly like what you wrote, just the
initializer is different but the result
On 8/4/17 8:49 AM, Q. Schroll wrote:
One can do
BigInt n = returnsBigInt();
foreach (i; BigInt(0) .. n)
{ .. }
How is this implemented? The code for BigInt is very large and I didn't
find it.
And is it more efficient than
for (BigInt i = 0; i < n; ++i)
{ .. }
Any foreach range
On Friday, 4 August 2017 at 12:49:30 UTC, Q. Schroll wrote:
One can do
BigInt n = returnsBigInt();
foreach (i; BigInt(0) .. n)
{ .. }
How is this implemented? The code for BigInt is very large and
I didn't find it.
And is it more efficient than
for (BigInt i = 0; i < n; ++i)
{ .. }
as
On Tuesday, 7 July 2015 at 22:19:22 UTC, Paul D Anderson wrote:
On Sunday, 5 July 2015 at 20:35:03 UTC, Kai Nacke wrote:
On Friday, 3 July 2015 at 04:08:32 UTC, Paul D Anderson wrote:
On Friday, 3 July 2015 at 03:57:57 UTC, Anon wrote:
On Friday, 3 July 2015 at 02:37:00 UTC, Paul D Anderson
wr
On Sunday, 5 July 2015 at 20:35:03 UTC, Kai Nacke wrote:
On Friday, 3 July 2015 at 04:08:32 UTC, Paul D Anderson wrote:
On Friday, 3 July 2015 at 03:57:57 UTC, Anon wrote:
On Friday, 3 July 2015 at 02:37:00 UTC, Paul D Anderson wrote:
[...]
Should be plusTwo(in BigInt n) instead.
Yes, I
On Friday, 3 July 2015 at 04:08:32 UTC, Paul D Anderson wrote:
On Friday, 3 July 2015 at 03:57:57 UTC, Anon wrote:
On Friday, 3 July 2015 at 02:37:00 UTC, Paul D Anderson wrote:
enum BigInt test1 = BigInt(123);
enum BigInt test2 = plusTwo(test1);
public static BigInt plusTwo(in bigint n)
S
On Friday, 3 July 2015 at 02:37:00 UTC, Paul D Anderson wrote:
The following code fails to compile and responds with the given
error message. Varying the "plusTwo" function doesn't work; as
long as there is an arithmetic operation the error occurs.
[...]
https://issues.dlang.org/show_bug.cgi
On Friday, 3 July 2015 at 03:57:57 UTC, Anon wrote:
On Friday, 3 July 2015 at 02:37:00 UTC, Paul D Anderson wrote:
enum BigInt test1 = BigInt(123);
enum BigInt test2 = plusTwo(test1);
public static BigInt plusTwo(in bigint n)
Should be plusTwo(in BigInt n) instead.
Yes, I had aliased Big
On Friday, 3 July 2015 at 02:37:00 UTC, Paul D Anderson wrote:
The following code fails to compile and responds with the given
error message. Varying the "plusTwo" function doesn't work; as
long as there is an arithmetic operation the error occurs.
This works for me on OSX 10.10 (Yosemite) usi
On Saturday, 25 April 2015 at 21:13:29 UTC, Ali Çehreli wrote:
On 04/25/2015 01:23 PM, Dennis Ritchie wrote:
which section should apply similar requests?
https://issues.dlang.org/
After clicking "File and Issue":
Component: Phobos
Severity: Enhancement
Ali
Thanks. I reported this:
-
ht
On 04/25/2015 01:23 PM, Dennis Ritchie wrote:
which section should apply similar requests?
https://issues.dlang.org/
After clicking "File and Issue":
Component: Phobos
Severity: Enhancement
Ali
On Saturday, 25 April 2015 at 18:58:50 UTC, Marc Schütz wrote:
BigInt only supports %d, %x, %X and %s:
http://dlang.org/phobos/std_bigint.html#.BigInt.toString
The missing %o and %b were probably an oversight, feel free to
file an enhancement request or submit a PR.
All right. I will file a r
On Saturday, 25 April 2015 at 13:13:10 UTC, Dennis Ritchie wrote:
Hi,
Is there a way to apply a function "format" with BigInt?
-
import std.stdio, std.bigint, std.string;
void main() {
BigInt n = -10;
string s = format("%b", n); // error
writeln(s);
}
BigInt onl
On Tuesday, 24 March 2015 at 17:35:14 UTC, matovitch wrote:
xor it with -1 instead of 1. (-1 is store as 0xfff..f with the
classic modular arithmetic)
Thanks.
On Tuesday, 24 March 2015 at 17:28:50 UTC, Dennis Ritchie wrote:
On Tuesday, 24 March 2015 at 16:35:04 UTC, Ivan Kazmenko wrote:
What exactly is not working?
Everything works. I'm just a little forgotten properties of the
operation xor.
I just wanted to xor 1 each digit in the number of typ
On Tuesday, 24 March 2015 at 16:35:04 UTC, Ivan Kazmenko wrote:
What exactly is not working?
Everything works. I'm just a little forgotten properties of the
operation xor.
I just wanted to xor 1 each digit in the number of type BigInt,
while I would like to store each number in the binary
On Tuesday, 24 March 2015 at 15:45:36 UTC, Dennis Ritchie wrote:
Tell me, please, how can I replace this code?
import std.conv : to;
import std.bigint : BigInt;
import std.string : format;
import std.stdio : writeln;
void main() {
BigInt[10] bitArr;
ulong n = 18_446_724_073_70
On Tuesday, 24 March 2015 at 15:45:36 UTC, Dennis Ritchie wrote:
Tell me, please, how can I replace this code?
import std.conv : to;
import std.bigint : BigInt;
import std.string : format;
import std.stdio : writeln;
void main() {
BigInt[10] bitArr;
ulong n = 18_446_724_073_70
On Tuesday, 24 March 2015 at 15:45:36 UTC, Dennis Ritchie wrote:
Tell me, please, how can I replace this code?
import std.conv : to;
import std.bigint : BigInt;
import std.string : format;
import std.stdio : writeln;
void main() {
BigInt[10] bitArr;
ulong n = 18_446_724_073_70
Great! Thanks a lot.
Kind regards
André
On Friday, 19 December 2014 at 08:47:50 UTC, bearophile wrote:
Andre:
Do you have any idea how to translate the coding correctly?
Try:
i += long(buffer[3]) << 24 >>> 0;
But I also suggest to add parentheses, to make the code less
unreadable for hum
Andre:
Do you have any idea how to translate the coding correctly?
Try:
i += long(buffer[3]) << 24 >>> 0;
But I also suggest to add parentheses, to make the code less
unreadable for humans.
Bye,
bearophile
On Sunday, June 16, 2013 05:14:07 Tyro[17] wrote:
> The following code:
>
> void main()
> {
> import std.bigint;
> BigInt x, m;
> BigInt l = x & m;
> }
>
> Result in:
> andrew@ace:~$ dmd f
> f.d(6): Error: 'x' is not of integral type, it is a BigInt
> f.d(6): Error: 'm' is not o
On 09/05/2012 07:10 PM, bearophile wrote:
Ellery Newcomer:
Yep.
Oh, good.
Have any suggestions for supported conversion out of the box?
There are several important cases, like:
Some D lazy ranges <==> Python lazy iterators/generators
array.array <==> D arrays
NumPy arrays <==> D array
On 09/10/2012 10:50 PM, Russel Winder wrote:
Python 2 and Python 3 are totally different in this regard. I don't have
a obvious proposal to make to avoid having PyD for Python 2 and a
different PyD for Python 3, but the six package might have some hints as
it is intended to support creating Pyth
On Mon, 2012-09-10 at 15:54 -0700, Ellery Newcomer wrote:
[…]
> Bugger, I'm going to have to go through pyd and replace all usages
> of str with unicode.
Python 2 and Python 3 are totally different in this regard. I don't have
a obvious proposal to make to avoid having PyD for Python 2 and a
di
On 09/10/2012 12:11 PM, bearophile wrote:
I understand. The point of Pyd is to interface D and Python, while NumPy
is something external. So if you find difficulties just keep it out.
Adding it later is possible.
Thing is, pyd will convert a ndarray to d array already, it just won't
do it as
Ellery Newcomer:
I've been thinking about this one a bit more, and I am not sure
it belongs in pyd.
I understand. The point of Pyd is to interface D and Python,
while NumPy is something external. So if you find difficulties
just keep it out. Adding it later is possible.
Bye,
bearophile
On 09/05/2012 07:10 PM, bearophile wrote:
NumPy arrays <==> D arrays
I've been thinking about this one a bit more, and I am not sure it
belongs in pyd.
First, the conversion is not symmetric. One can convert a numpy.ndarray
to a d array like so:
PyObject* ndarray;
double[][] matrix = d_
Am Mon, 10 Sep 2012 14:48:30 +0200
schrieb Johannes Pfau :
> Sorry, I should have said 'It'll _probably_ never be supported in
> gdc'. There are some possible solutions but:
>
> * It must be good enough to get approved when gdc is merged into gcc.
> (remember it must be portable and gpl and you
Am Sun, 09 Sep 2012 12:55:19 -0700
schrieb Brad Roberts :
> On 9/9/2012 1:15 AM, Johannes Pfau wrote:
> > Am Sat, 08 Sep 2012 16:25:49 +0100
> > schrieb Russel Winder :
> >
> >> On Sat, 2012-09-08 at 07:20 -0700, Ellery Newcomer wrote:
> >> […]
> >>> Okay, here:
> >>> https://bitbucket.org/ariovi
On 9/9/2012 1:15 AM, Johannes Pfau wrote:
> Am Sat, 08 Sep 2012 16:25:49 +0100
> schrieb Russel Winder :
>
>> On Sat, 2012-09-08 at 07:20 -0700, Ellery Newcomer wrote:
>> […]
>>> Okay, here:
>>> https://bitbucket.org/ariovistus/deimos-elfutils/overview
>>>
>>> I have some code with a working makef
On Sun, 2012-09-09 at 10:15 +0200, Johannes Pfau wrote:
[…]
> Please note that pragma(lib) is an evil feature. For example it will
> never work in gdc.
So this is a DMD-only (*) feature and not a feature of the D programming
language per se?
(*) and hence LDC.
--
Russel.
Am Sat, 08 Sep 2012 16:25:49 +0100
schrieb Russel Winder :
> On Sat, 2012-09-08 at 07:20 -0700, Ellery Newcomer wrote:
> […]
> > Okay, here:
> > https://bitbucket.org/ariovistus/deimos-elfutils/overview
> >
> > I have some code with a working makefile and a nonworking
> > SConstruct file.
> >
>
On Sat, 2012-09-08 at 07:20 -0700, Ellery Newcomer wrote:
[…]
> Okay, here: https://bitbucket.org/ariovistus/deimos-elfutils/overview
>
> I have some code with a working makefile and a nonworking SConstruct file.
>
> I believe the issue is the header files have pragma(lib, X) in them, and
> a si
On 09/08/2012 03:09 AM, Russel Winder wrote:
On Fri, 2012-09-07 at 15:21 -0700, Ellery Newcomer wrote:
On 09/06/2012 12:07 AM, Russel Winder wrote:
[…]
just used your scons fork to build the pyd embedded unittests. works
pretty nice
Splendid :-)
Okay, here: https://bitbucket.org/ariovistu
On Fri, 2012-09-07 at 15:21 -0700, Ellery Newcomer wrote:
> On 09/06/2012 12:07 AM, Russel Winder wrote:
[…]
> just used your scons fork to build the pyd embedded unittests. works
> pretty nice
Splendid :-)
If you see any problems or glitches, let me know and/or post a bug
report. Although I sa
On Sat, 2012-09-08 at 00:58 +0200, bearophile wrote:
[…]
> If you support NumPy well and efficiently through Pyd, I think
> some people will start using the D language just for this :-)
>
> NumPy is good but it usually forces you to program vectorially,
> like Matlab. Sometimes this is not nice,
Ellery Newcomer:
I had a look at numpy, and at least ndarray supports the new
style buffer interface (which is pretty freaking complicated),
so convertion is totally doable. I'll fold in support as soon
as I can get dmd to stop stabbing me in the face.
If you support NumPy well and efficient
On 09/06/2012 12:07 AM, Russel Winder wrote:
I am guessing this is interfacing to CPython, remember there is also
PyPy and ActiveState, they have different ways of doing things. Well
the ActiveState C API will be very close to the CPython C API, but PyPy
(which is the best Python 2.7 just now)
On 09/06/2012 09:48 AM, Ellery Newcomer wrote:
On 09/05/2012 11:19 PM, Jacob Carlborg wr
Associative arrays?
check.
eh, that was check as in yes, not check as in look it up yourself.
didn't seem ambiguous at the time.
On 09/06/2012 04:11 AM, bearophile wrote:
Ellery Newcomer:
array.array <==> D arrays
just checked, looks like we have it:
PyStmts(q"{from array import array; a = array('i', [44,33,22,11]);}",
"testing");
assert(PyEval!(int[])("a", "testing") == [44,33,22,11]);
I think if the python object i
On 09/05/2012 11:19 PM, Jacob Carlborg wrote:
On 2012-09-06 04:10, bearophile wrote:
There are several important cases, like:
Some D lazy ranges <==> Python lazy iterators/generators
array.array <==> D arrays
NumPy arrays <==> D arrays
Associative arrays?
check.
https://bitbucket.org/a
Ellery Newcomer:
array.array <==> D arrays
just checked, looks like we have it:
PyStmts(q"{from array import array; a = array('i',
[44,33,22,11]);}", "testing");
assert(PyEval!(int[])("a", "testing") == [44,33,22,11]);
I think if the python object is iterable, it can be converted
to array
On 05/09/12 21:23, Paul D. Anderson wrote:
On Wednesday, 5 September 2012 at 18:13:40 UTC, Ellery Newcomer wrote:
Hey.
Investigating the possibility of providing this conversion in pyd.
Python provides an api for accessing the underlying bytes.
std.bigint seemingly doesn't. Am I missing anyth
Sorry, I missed earlier bits of this thread…
On Wed, 2012-09-05 at 19:37 -0700, Ellery Newcomer wrote:
> On 09/05/2012 07:10 PM, bearophile wrote:
> >
> > Some D lazy ranges <==> Python lazy iterators/generators
> >
>
> I'll look into this one.
>
> > array.array <==> D arrays
>
> just checked,
On 2012-09-06 04:10, bearophile wrote:
There are several important cases, like:
Some D lazy ranges <==> Python lazy iterators/generators
array.array <==> D arrays
NumPy arrays <==> D arrays
Associative arrays?
--
/Jacob Carlborg
On 09/05/2012 07:10 PM, bearophile wrote:
Some D lazy ranges <==> Python lazy iterators/generators
I'll look into this one.
array.array <==> D arrays
just checked, looks like we have it:
PyStmts(q"{from array import array; a = array('i', [44,33,22,11]);}",
"testing");
assert(PyEval!(in
Ellery Newcomer:
Yep.
Oh, good.
Have any suggestions for supported conversion out of the box?
There are several important cases, like:
Some D lazy ranges <==> Python lazy iterators/generators
array.array <==> D arrays
NumPy arrays <==> D arrays
Also, which of the following looks mor
On 09/05/2012 05:02 PM, bearophile wrote:
Ellery Newcomer:
Investigating the possibility of providing this conversion in pyd.
Are you updating Pyd? :-)
Bye,
bearophile
Yep. Have any suggestions for supported conversion out of the box? From
the standard library, I already have Complex, Tup
Ellery Newcomer:
Investigating the possibility of providing this conversion in
pyd.
Are you updating Pyd? :-)
Bye,
bearophile
On Wednesday, 5 September 2012 at 19:23:11 UTC, Paul D. Anderson
wrote:
No, I don't believe so. AFAIK there is no public access to the
underlying array, but I think it is a good idea.
I meant to say I think that access to the array is a good idea,
not the lack of access. Words are hard!
On Wednesday, 5 September 2012 at 18:13:40 UTC, Ellery Newcomer
wrote:
Hey.
Investigating the possibility of providing this conversion in
pyd.
Python provides an api for accessing the underlying bytes.
std.bigint seemingly doesn't. Am I missing anything?
No, I don't believe so. AFAIK there
Al 21/04/12 16:42, En/na Tyro[17] ha escrit:
> Actually, in that case it only happens when compiling to 64-bit.
>
> Note: comb1(BigInt(40), BigInt(20))/2; The the BigInt version is
> being divided by two (on MAC OS X) in order to yield the
> correct result.
>
You are right, sorry.
My test was d
On Saturday, 21 April 2012 at 14:30:49 UTC, Jordi Sayol wrote:
Al 21/04/12 16:07, En/na Tyro[17] ha escrit:
Why does the following implementation of the binomial
coefficient yield two different answers?
Only happens when compiling to 32-bit.
32-bit:
(40 20) = 137846528820
(40 20) = 689232
Al 21/04/12 16:07, En/na Tyro[17] ha escrit:
> Why does the following implementation of the binomial coefficient yield two
> different answers?
>
Only happens when compiling to 32-bit.
32-bit:
(40 20) = 137846528820
(40 20) = 68923264410
64-bit:
(40 20) = 137846528820
(40 20) = 13784652882
tsukikage wrote:
Please see source in attachment.
The output is
M2 M3 M5 M7 M13 M17 M19 M31 M61 M89 M107 M127 M521 M607 M1279 M2203
M2281 M3217 M4253 M4423
*** M9689***
M9941 M11213 M19937
*** M21701***
M23209
It missed 2 Mersenne Primes 9689 & 21701.
Is it my program bug or bigint broken?
tsukikage:
> For curiosity, would you explain/guess a possible reason for that?
I leave the answer to Don, I don't know the internals of D BigInts.
Multi-precision integers are basic bricks used to build many other programs.
How can you be sure they don't contain bugs that break your heavy nume
For curiosity, would you explain/guess a possible reason for that?
Thanks!
bearophile wrote:
tsukikage:
Is it my program bug or bigint broken?
http://d.puremagic.com/issues/show_bug.cgi?id=5568
Bye,
bearophile
tsukikage:
> Is it my program bug or bigint broken?
http://d.puremagic.com/issues/show_bug.cgi?id=5568
Bye,
bearophile
Kagamin wrote:
Don Wrote:
Why are they templated to begin with? Just for the heck of it?
bool opEquals(ref const BigInt y) const
bool opEquals(long y) const
No, because then it fails for ulong.
It's those bloody C implicit conversions.
hmm... works for me:
---
struct A
{
bool opEqua
Don Wrote:
> > Why are they templated to begin with? Just for the heck of it?
> >
> > bool opEquals(ref const BigInt y) const
> > bool opEquals(long y) const
>
> No, because then it fails for ulong.
> It's those bloody C implicit conversions.
hmm... works for me:
---
struct A
{
bool opE
Kagamin wrote:
Matthias Walter Wrote:
bool opEquals(Tdummy=void)(ref const BigInt y) const
bool opEquals(T: int)(T y) const
The only working sigature for array-of-structs-comparison to work is
bool opEquals(ref const BigInt y) const
But this removes the ability to compare against ints.
Why
Matthias Walter Wrote:
> bool opEquals(Tdummy=void)(ref const BigInt y) const
> bool opEquals(T: int)(T y) const
>
> The only working sigature for array-of-structs-comparison to work is
>
> bool opEquals(ref const BigInt y) const
>
> But this removes the ability to compare against ints.
Why ar
On 11/27/2010 02:05 PM, bearophile wrote:
>> Reduced case for bugzilla:
>>
> http://d.puremagic.com/issues/show_bug.cgi?id=5281
>
I investigated into the bug and the reason is the signature of opEquals,
which currently is
bool opEquals(Tdummy=void)(ref const BigInt y) const
bool opEquals(T
> Reduced case for bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=5281
Ellery Newcomer:
> why does the following code fail?
Reduced case for bugzilla:
import std.bigint;
void main() {
assert([BigInt(1)] == [BigInt(1)]);
}
Bye,
bearophile
74 matches
Mail list logo
