6:56 a.m.
Hi to all.
I try this in my debian calculator:
"4 / 3 * (sqrt(2) - 1)" and return 0,55228475
in C++ return 0.414214
I want 0,55228475.
Where i lost? I have the cmath header
Regards, Jabier.
6:59 a.m.
On Mon, Jun 30, 2014 at 11:56:15PM +0200, Jabiertxo Arraiza Cenoz wrote:
Hi to all.
I try this in my debian calculator:
"4 / 3 * (sqrt(2) - 1)" and return 0,55228475
in C++ return 0.414214
I want 0,55228475.
Where i lost? I have the cmath header
4/3 = 1 because the type of both arguments is int. 4.0/3 fixes your
problem. I would put (4./3) * sqrt() because operator precedence for
divide is not always clear.
njh
4:41 p.m.
Thanks Nathan. I just read it in a book but dont remeber when
necessary :(.
And thanks for the operator precedence tip.
Cheers, Jabier.
El mar, 01-07-2014 a las 07:59 +1000, Nathan Hurst escribió:
On Mon, Jun 30, 2014 at 11:56:15PM +0200, Jabiertxo Arraiza Cenoz
wrote:
> Hi to all.
>
> I try this in my debian calculator:
> "4 / 3 * (sqrt(2) - 1)" and return 0,55228475
> in C++ return 0.414214
>
> I want 0,55228475.
> Where i lost? I have the cmath header
4/3 = 1 because the type of both arguments is int. 4.0/3 fixes your
problem. I would put (4./3) * sqrt() because operator precedence for
divide is not always clear.
njh
6:03 a.m.
Hi Jabier,
I'm not 100% sure, but you may consider to always use floating point
numbers for the type of calculation you are doing, unless you are sure
you want integer calculation. So then it becomes:
(4./3.) * (sqrt(2.) - 1.)
regards,
Johan
On 1-7-2014 9:41, Jabiertxo Arraiza Cenoz wrote:
Thanks Nathan. I just read it in a book but dont remeber when
necessary :(.
And thanks for the operator precedence tip.
Cheers, Jabier.
El mar, 01-07-2014 a las 07:59 +1000, Nathan Hurst escribió:
> On Mon, Jun 30, 2014 at 11:56:15PM +0200, Jabiertxo Arraiza Cenoz wrote:
>> Hi to all.
>>
>> I try this in my debian calculator:
>> "4 / 3 * (sqrt(2) - 1)" and return 0,55228475
>> in C++ return 0.414214
>>
>> I want 0,55228475.
>> Where i lost? I have the cmath header
> 4/3 = 1 because the type of both arguments is int. 4.0/3 fixes your
> problem. I would put (4./3) * sqrt() because operator precedence for
> divide is not always clear.
>
> njh
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
8:05 a.m.
Johan. Thanks for the tip.
Cheers, Jabier.
El mar, 01-07-2014 a las 23:03 +0200, Johan Engelen escribió:
Hi Jabier,
I'm not 100% sure, but you may consider to always use floating point
numbers for the type of calculation you are doing, unless you are sure
you want integer calculation. So then it becomes:
(4./3.) * (sqrt(2.) - 1.)
regards,
Johan
On 1-7-2014 9:41, Jabiertxo Arraiza Cenoz wrote:
> Thanks Nathan. I just read it in a book but dont remeber when
> necessary :(.
> And thanks for the operator precedence tip.
>
> Cheers, Jabier.
>
>
> El mar, 01-07-2014 a las 07:59 +1000, Nathan Hurst escribió:
>> On Mon, Jun 30, 2014 at 11:56:15PM +0200, Jabiertxo Arraiza Cenoz wrote:
>>> Hi to all.
>>>
>>> I try this in my debian calculator:
>>> "4 / 3 * (sqrt(2) - 1)" and return 0,55228475
>>> in C++ return 0.414214
>>>
>>> I want 0,55228475.
>>> Where i lost? I have the cmath header
>> 4/3 = 1 because the type of both arguments is int. 4.0/3 fixes your
>> problem. I would put (4./3) * sqrt() because operator precedence for
>> divide is not always clear.
>>
>> njh
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
>
>
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________ Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
11:06 p.m.
Interesting problem. Concerning readability of floating point numbers, for
me personally "4.0" is better than just "4.". Is this just personal
preference or is there any benefit of just "4."?
A quick search for "float" on inkscape coding style page didn't show
anything.
--
Christoffer Holmstedt
2014-07-02 1:05 GMT+02:00 Jabiertxo Arraiza Cenoz <jabier.arraiza@...2927....>
:
Johan. Thanks for the tip.
Cheers, Jabier.
El mar, 01-07-2014 a las 23:03 +0200, Johan Engelen escribió:
> Hi Jabier,
> I'm not 100% sure, but you may consider to always use floating point
> numbers for the type of calculation you are doing, unless you are sure
> you want integer calculation. So then it becomes:
>
> (4./3.) * (sqrt(2.) - 1.)
>
> regards,
> Johan
>
>
> On 1-7-2014 9:41, Jabiertxo Arraiza Cenoz wrote:
> > Thanks Nathan. I just read it in a book but dont remeber when
> > necessary :(.
> > And thanks for the operator precedence tip.
> >
> > Cheers, Jabier.
> >
> >
> > El mar, 01-07-2014 a las 07:59 +1000, Nathan Hurst escribió:
> >> On Mon, Jun 30, 2014 at 11:56:15PM +0200, Jabiertxo Arraiza Cenoz
wrote:
> >>> Hi to all.
> >>>
> >>> I try this in my debian calculator:
> >>> "4 / 3 * (sqrt(2) - 1)" and return 0,55228475
> >>> in C++ return 0.414214
> >>>
> >>> I want 0,55228475.
> >>> Where i lost? I have the cmath header
> >> 4/3 = 1 because the type of both arguments is int. 4.0/3 fixes your
> >> problem. I would put (4./3) * sqrt() because operator precedence for
> >> divide is not always clear.
> >>
> >> njh
> >
> >
> >
------------------------------------------------------------------------------
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community
Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> >
> >
> > _______________________________________________
> > Inkscape-devel mailing list
> > Inkscape-devel(a)lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
>
------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community
Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________ Inkscape-devel mailing
list Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
1:01 a.m.
On Wed, Jul 2, 2014, at 07:06 AM, Christoffer Holmstedt wrote:
Interesting problem. Concerning readability of floating point
numbers, for me personally "4.0" is better than just "4.". Is
this just personal preference or is there any benefit of just
"4."?
A quick search for "float" on inkscape coding style page didn't
show anything.
I was thinking exactly the same thing. Sure, dropping the '0'
leaves for fewer characters to type, but it makes the decimal
much harder to spot. Legibility helps with maintenance and with
spotting bugs, so it's generally a good idea to make things
more legible. Among other things, think of decimal calculations
in a parameter list "3 * 4., 5 *3". When next to a comma it
will really hide on some systems. Much harder for the human eye
to catch in casual scanning.
That goes along with parenthesis. Technically they are often
not required... however making them explicit helps the poor
humans who have to read the code. It's such a good practice
that when Java was being designed, that suggestion (add
parenthesis even when not required by the language) was
actually included in the Java language spec itself. And
think... that was for a language that does not have all the
ambiguity that C/C++ has.
--
Jon A. Cruz
jon@...18...
5:45 a.m.
On 2-7-2014 18:01, Jon A. Cruz wrote:
On Wed, Jul 2, 2014, at 07:06 AM, Christoffer Holmstedt wrote:
> Interesting problem. Concerning readability of floating point
> numbers, for me personally "4.0" is better than just "4.". Is
this
> just personal preference or is there any benefit of just "4."?
> A quick search for "float" on inkscape coding style page didn't show
> anything.
I was thinking exactly the same thing. Sure, dropping the '0' leaves
for fewer characters to type, but it makes the decimal much harder to
spot. Legibility helps with maintenance and with spotting bugs, so
it's generally a good idea to make things more legible. Among other
things, think of decimal calculations in a parameter list "3 * 4., 5
*3". When next to a comma it will really hide on some systems. Much
harder for the human eye to catch in casual scanning.
That goes along with parenthesis. Technically they are often not
required... however making them explicit helps the poor humans who
have to read the code. It's such a good practice that when Java was
being designed, that suggestion (add parenthesis even when not
required by the language) was actually included in the Java language
spec itself. And think... that was for a language that does not have
all the ambiguity that C/C++ has.
Not too long ago, I started changing small bits of code to not rely on
operator precedence.
We could enable "-Wparentheses" for this. It also nicely catches some
other issues like:
if (x = 0) {
}
forcing one to write
if ((x = 0)) {
}
if you really meant the assignment.
cheers,
Johan
5:50 a.m.
On Wed, Jul 2, 2014 at 4:45 PM, Johan Engelen <jbc.engelen@...2592...>
wrote:
We could enable "-Wparentheses" for this. It also nicely catches some
other issues like:
if (x = 0) {
}
forcing one to write
if ((x = 0)) {
}
if you really meant the assignment.
So if I write
if (SPItem* item = dynamic_cast<SPItem*>(obj)) {
// do something with item
}
Would it flag that too?
6:07 a.m.
On 2-7-2014 22:50, Liam White wrote:
On Wed, Jul 2, 2014 at 4:45 PM, Johan Engelen
<jbc.engelen@...2592... <mailto:jbc.engelen@...2592...>> wrote:
We could enable "-Wparentheses" for this. It also nicely catches some
other issues like:
if (x = 0) {
}
forcing one to write
if ((x = 0)) {
}
if you really meant the assignment.
So if I write
if (SPItem* item = dynamic_cast<SPItem*>(obj)) {
// do something with item
}
Would it flag that too?
I think so. You would need double parentheses.
I am a little confused, because -Wparentheses is enabled with -Wall,
which we already use...
The assignment thing is clang-only it seems. But I thought -Wparentheses
also complains about operator precedence, but perhaps only with
combinations of || and &&...
- Johan
6:11 a.m.
On Wed, Jul 2, 2014, at 02:07 PM, Johan Engelen wrote:
The assignment thing is clang-only it seems. But I thought
-Wparentheses also complains about operator precedence, but
perhaps only with combinations of || and &&...
For my local builds I usually configure so that they end up
with
-Wall -Wextra
For gcc that gets a nice useful set of warnings.
As far as clang only goes, I have seen such warnings elsewhere.
Might be from tools or from other compilers. Regardless it
probably is good to find and fix.
--
Jon A. Cruz
jon@...18...
6:36 a.m.
On Wed, Jul 2, 2014, at 01:50 PM, Liam White wrote:
So if I write
if (SPItem* item = dynamic_cast<SPItem*>(obj)) {
// do something with item
}
I was thinking that should be flagged as it is actually an
abuse of the condition.
You have two things collapsed to a single line, and at the
least it will interfere with debugging. On the other hand, when
broken apart, consider the break-point possibilities:
1 SPItem *item = dynamic_cast<SPItem*>(obj);
2 if (item) {
3 ...
n }
You can now set a breakpoint on line one or on line two. It
might seem less useful, but if one combines a condition on a
breakpoint at line 2 you can stop only if it is null or only if
it not null, etc. However you do lose a bit of safety by
leaving that pointer around to possibly use after it is no
longer valid. Fixing that gives
{
SPItem *item = dynamic_cast<SPItem*>(obj);
if (item) {
...
}
}
Extra parenthesis can be added at any time to limit scope of
any variables. Quite handy, that. However a more logical
restructuring could also be. There are other options too,
including for loops
for (SPItem *item = dynamic_cast<SPItem*>(obj); item; item =
NULL) {
}
That would address the assignment issue, and keep it to a
single line. I'll have to ponder if that is better enough. It
is definitely not to the level of abusing the 'for' statement
that the for(EVER) idiom is. :-)
But the bigger question would be why use such code to begin
with? It is a very C style approach. "Let's just store
everything as void* and cast back as needed on the fly". A more
C++ centric approach would not have a raw obj pointer, but
something more specific. I'd suggest looking at the structure
of the surrounding code to see if that can be fixed here and
the dynamic_cast<> be avoided completely.
--
Jon A. Cruz
jon@...18...
2:28 a.m.
It's just laziness on my part. We should use the .0 format as per iso
standard.
njh
On Wed, Jul 02, 2014 at 04:06:57PM +0200, Christoffer Holmstedt wrote:
Interesting problem. Concerning readability of floating point
numbers, for
me personally "4.0" is better than just "4.". Is this just personal
preference or is there any benefit of just "4."?
A quick search for "float" on inkscape coding style page didn't show
anything.
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
3254
days inactive
3256
days old
inkscape-devel@lists.inkscape.org
12 comments
6 participants
participants (6)
-
Christoffer Holmstedt -
Jabiertxo Arraiza Cenoz -
Johan Engelen -
Jon A. Cruz -
Liam White -
Nathan Hurst