2D Parametric Plot [Descartes Loop].sm (37 КиБ) скачан 44 раз(а). ... SS 6179

Thank you Jean, confirmed. In your example the iterator variable i replaces in the results the imaginary unit.
Have to investigate a little more because as for now I can't replicate it in a simpler case.

I think that the missing protection of e, i and pi against re-definition just causes confusion without having any benefit.

However I could not find a feature request for changing this, thus I submitted one.

See SS 3507.

Wrote

Thank you Jean, confirmed. In your example the iterator variable i replaces in the results the imaginary unit.
Have to investigate a little more because as for now I can't replicate it in a simpler case

Trust me Davide, on that one, I had to shoveled the clouds for quite a while !
"I can't replicate it in a simpler case"
It does not appear for a single case, it reveals for next and successive use.
Explained from observation in the attached.
All my other use in InverseLaplace are single cases and compatible.

Cheers Davide ... test your sandbox ... Jean

2D Parametric Plot [Descartes Loop].sm (43 КиБ) скачан 34 раз(а). ... SS 6179

Ok, simplified enough to have a clear test case

The behavior under loops is the same that you can experience on the canvas, when i is used as part of a function or of a dependant variable (a variable that contains undefined variables).

Therefore is not bug about loops, but the general behavior of the program (that might be discussed starting from the BTS filled by Martin in the post above)

imaginary.sm (23 КиБ) скачан 34 раз(а).

... this bug concerns SS 6179.
Easy to test SS newer than 6179 ... follows the last guidance.
==================================================
The worst cases are in [d2, d3, d4] above.
1. 'i' in d2 is OK ... "imaginary unit" is ignored.
2. set 'i' in [d3, d4] to destroy the project.
==================================================

If you destroy the project by setting 'i' in d3, d4
there is urgent need to repair. Make 'i' imaginary unit
bold, red ... whatever distinguishable. Providing not
so stupid than Maple 'I'.
Mathematica 4.0 'i' is such a glorious horror !

2D Parametric Plot [Descartes Loop].sm (54 КиБ) скачан 35 раз(а).

Wrote

.... Make 'i' imaginary unit
bold, red ... whatever distinguishable. Providing not
so stupid than Maple 'I'.
Mathematica 4.0 'i' is such a glorious horror !

I agree with Jean, that the option to protect i and make it useless for programming could be an error. Guess that a good workaround is using units:



Best regards.

Alvaro

Not easy to understand what is happening in all these steps...and all these changes of font for the same name of ...what? ( constant,variable ...)

Franco

Wrote

Guess that a good workaround is using units:

That is part of the feature request SS-3507

If you like it, you might vote for it.

Wrote

That is part of the feature request SS-3507

If you like it, you might vote for it.

Well, talking about features, I vote for having different styles for the same variable name, like in mathcad:



Best regards.

Alvaro.

Wrote

That is part of the feature request SS-3507

If you like it, you might vote for it.

My vote [typical]

I agree that protection of imaginary unit and euler number should not prevent the user from using e and i as names of variables.

There are two challenges:

1. Clear visual distinction between protected constants and variables of the same name. The basic approach is to just use italic and non-italic black font. I prefer this because this would not require changes for complex result formatting and would be consistent to the general format rules in SMath (built-ins upright, user-defined italic).

2. Unambiguous and simple way to input either constant or variable using the keyboard. If you enter i or e, then this refers to the constants, as long nothing has been defined by the user. Once custom e or i are defined, then the selection could be done using the dynamic assistant. Alternatively, you might generally input the constants i as CTRL-SHIFT-I and e as CTRL-SHIFT-E just like CTRL-SHIFT-P gives pi.

Protecting pi is less important but would not harm and would add to consistant formatting.

Not directly related but being mentioned above in the discussion:

Markup as vector e.g. by underlining or bold face would enable sort of type declaration. This could be used to identify the correct type of multiplication (commutative or non-commutative) in symbolic manipulations.

Here we would have to discuss, if the markup has to be removed if element indices are used (as in paper and pencil handcalc).