> Deprecating unary < is growing on me, it's always used with .. and so "..<"
> can be used instead.
+1
Wow, that IS quite bit surprising! It seemed to me ..< was originally meant to
be more-or-less equivalent to .. < (or maybe even an anti-typo trick?). I'm
glad I never use unary < to begin with.
@Araq I like the idea. One of my friends who's coding a hobby project in Nim
always avoids < so
> So are you saying there is a difference between `0..
Deprecating unary `<` is growing on me, it's always used with `..` and so `..<`
can be used instead.
> Besides, uints are as old as programming, so shouldn't you fix making it work
> correctly rather than discourage its use?
They silently overflow. What does it even mean to "make it work correctly"?
They don't, hence we discourage them.
**1)** In **nextp_init** in the line below, **i** can start from eithre '0' or
'1'.
for i in 0|1..
The only operator with this gotcha is < right? Maybe it would be best to just
deprecate it. Is there unary >?
By the way, Nim manual has a part with the discouraged syntax
[here](https://nim-lang.org/docs/manual.html#generics-generic-concepts-and-type-binding-rules)
proc
He, good catch. In general we advocate to use `..<` instead of `.. <`. I see no
alternative to "unary operators bind tighter than binary operators".
As it turns out, it was a somewhat subtle bug in the code. The compiler is fine.
Change the following code:
proc segsieve(Kn: int) = # for Kn resgroups in segment
for b in 0 ..
> Can you show me how to do that?
When you are using the Nim compiler from the command line, then in the current
working directory a subdirectory with name nimcache is created. For example
"nim c test.nim" creates "nimcache/test.c". You can inspect that intermediate C
code. When you have clang
> The inexorable conclusion is there is a fundamental bug in the structure of
> the language which causes this error to occur.
Are you sure about this? I found at least one difference between the C++ and
the Nim implementation (the first loop in `next_pinit` starts with 1 in C++ and
and with 0
Actually I'm not a C/C++ programmer, I'm (mostly now) a Ruby programmer who is
functional in C++, and haven't really done anything in C of any note.
I've been looking to see how to view the C/C++ that Nim is generating but I
don't know how to do that. Can you show me how to do that?
Remember,
> The inexorable conclusion
Does your code really only works when uint is used? Because most of us try to
avoid using uint, so uint is not that much tested.
Have you tried without optimization or different C compiler backend?
Have you tried compiling to C++ instead of C? (nim cpp test.nim)?
I
I see that you are using the pairs iterator followed by a if condition in the
Nim code. Can you check without? so that it's more in line with the C++ code?
for j, prime in primes: # for each prime r1..sqrt(N)
if nextp[row + j] < uint(Kn): # if 1st mult resgroup
Yes, better to avoid all the conversions between int and uint. Nim compiler
does not really like uint, but can use it.
Note that your Nim arithmetics are not identical to C arithmetic. For example
in Nim code you have
uint(k-Kn)
So you use signed values for substraction, and
None of these listings can be compiled. The only thing I can say is that I
would never use `uint` for these kind of computations. Much too prone to silent
over- and underflows.
I have identified a very subtle memory management error that took me weeks to
characterize.
I'm directly translating a working C++ program to Nim. The problem seems to be
that the Nim code erroneously addresses the **seg** array beyonds its bounds,
because the **k** values used to update the
17 matches
Mail list logo
