Maybe your work sheet needs be doctored as well as mine.
It happens, correct during the session of construction,
but fails on re-opening PC [little pest].



Solve Diophantine X_Y Plot.sm (25 KiB) downloaded 71 time(s).

Hello Jean
Your file gives me the error of division by zero in the graph.





Best Regards

Carlos

I too get the same error with 99.6611.

Wrote

Hello Jean
Your file gives me the error of division by zero in the graph.

Hello Carlos,
In the collected plot, neither f, XY, xy can issue this error message.
Hope not, otherwise X_Y would be all bug.
The module ortho(x,y):= -x/y may be the guilty. Try to remove it.
Hope for more testing from the crew [Martin, Davide, Radovan ... for sure Andrey].

In fact, no Smath stable version is stable.
The latest, declared stable, will be after evaporating any traces of previous
installed version. Seemingly, no such procedure is defined by steps .

1. Uninstall Smath
2. Delete from the directory
3. Delete anything wrt Smath from the Registry ...
I found only two items belonging to Smath. How many more hidden
under no inspiring name ??? Watson, that is the question !

Cheers Carlos, Jean

Hello Jean,
your file runs perfectly in the version of Smath Studio "0.98.6484.11448",
and fails in the versions "0.98.6179.21440" and "0.99.6611.22150", the error
is caused by the function "Ortho = -x / y". If this function is removed from
the graph, the error is eliminated, but only Parabola is plotted.






Best regards

Carlos

Wrote

Hello Jean,
your file runs perfectly in the version of Smath Studio "0.98.6484.11448",
and fails in the versions "0.98.6179.21440" and "0.99.6611.22150", the error
is caused by the function "Ortho = -x / y". If this function is removed from
the graph, the error is eliminated, but only Parabola is plotted.

That my friend is the most pertinent remark.
I have it the other way around: 6179 working great on XP Pro
6484 scrapped two work sheets, because I tried only two !!!
Whatever: there is a concurrent bug wrt X_Y wrt Smath versions.
Doctor one version, scrap the other one ... pest !

Cheers Carlos, Jean.

Jean,

Wrote

In fact, no Smath stable version is stable.
The latest, declared stable, will be after evaporating any traces of previous
installed version.

I would disagree with you. Beta versions usually much more unstable. But yes, sometimes I make mistake and build 6606 should not be marked as Stable, because I've missed something very important. But this is exception. F.e. latest stable is really good.

I have checked your worksheet and see question we have here is not about stable/not stable, this is about environment. I have checked different versions of SMath Studio (including 0.98.6484.11448, 0.98.6179.21440, 0.99.6611.22150) - error is shown everywhere.
Then I've tried to open SMath Studio in 32-bit mode and this helped! When it is 32-bit worksheet calculated without errors and graph is shown correctly.

So this is about 32/64 bit and present in all versions of the program.


(build 6615 32 bit = build 6611 64 bit)

Best regards.

The bitness is also known to be relevant for the function of 32bit mathcad user libraries in the Mathcad EFI plugin. These require SMath Studio running in 32 bit mode. I am not aware of plugins which insist on 64 bit mode, therefore my portable pre-configured distribution is generally set to 32 bit. It is in fact very easy to do using the CorFlags executable posted by uni somewhere in the forum.

I don't know how hard it is to switch or check the setting from inside SMath. My proposal would be to verify the matching bitness in the extension manager and at least warn about conflicts or just do the required adjustments.

However, I am not aware of a particular bitness of worksheets beyond the required bitness of the referenced plugins.

EDIT: From the info dialog it is obvious that the bit mode can be determined from inside SMath.

Wrote

The bitness is also known to be relevant for the function of 32bit mathcad user libraries in the Mathcad EFI plugin. These require SMath Studio running in 32 bit mode. I am not aware of plugins which insist on 64 bit mode, therefore my portable pre-configured distribution is generally set to 32 bit. It is in fact very easy to do using the CorFlags executable posted by uni somewhere in the forum.

I don't know how hard it is to switch or check the setting from inside SMath. My proposal would be to verify the matching bitness in the extension manager and at least warn about conflicts or just do the required adjustments.

However, I am not aware of a particular bitness of worksheets beyond the required bitness of the referenced plugins.
javascript:__doPostBack('forum$ctl03$PostReply','')
EDIT: From the info dialog it is obvious that the bit mode can be determined from inside SMath.

The bitness issue is typical of p/invoked libraries or external processes, something that smath can't manage automatically (except maybe introducing in the interface a flag that the plugin author can set manually to explicitly declare the plugin incompatible); however the developer can already throw an exception during the initialization to prompt the incompatibility to the user (mathcad efi f.e. has this check but it is suppressed in favor of his internal logger)

Here the question is:
How is it possible that by removing the Ortho function
from the graph, the file will work correctly?
What does the definition of the function
Ortho (x, y) = - x / y have to do with the version at 32 to 64 bit?




Best Regards

Carlos

Wrote

Here the question is:
How is it possible that by removing the Ortho function
from the graph, the file will work correctly?
What does the definition of the function
Ortho (x, y) = - x / y have to do with the version at 32 to 64 bit?

Can't be more right Carlos.
It has nothing to do, except that X_Y is buggy wrt 32/64 bits versions.
That's what the bitness exchange concludes. How can you manage a plug-in
designed 64 bits [not for 6179 ...] and X_Y 32 bits on same document.

Cheers Carlos, Jean.

Wrote

Here the question is:
How is it possible that by removing the Ortho function
from the graph, the file will work correctly?
What does the definition of the function
Ortho (x, y) = - x / y have to do with the version at 32 to 64 bit?

Best Regards

Carlos

Possibly, the plugin uses different libraries for different functions. Depending on what function is actually used, this may lead to a conflict or not.
Ortho uses the implicit plot feature which might depend on a 32 bit lib.

This is just a guess but it could be that way. No need to dig deeper if setting SMath to 32 bit is on the safe side for ordinary usage. Otherwise you just can examine the visual studio project for dependencies.

Wrote

The bitness issue is typical of p/invoked libraries or external processes, something that smath can't manage automatically (except maybe introducing in the interface a flag that the plugin author can set manually to explicitly declare the plugin incompatible); however the developer can already throw an exception during the initialization to prompt the incompatibility to the user (mathcad efi f.e. has this check but it is suppressed in favor of his internal logger)

What is the benefit of having SMath being delivered as 64 bit version? No conflicts have been reported for 32 bit versions. How is the user expected to modify the bitness? Couldn't that be an option upon install? Allow the user to set bitness to 64 "If you know what you are doing"

Wrote

What is the benefit of having SMath being delivered as 64 bit version?

Martin,

IMHO, no interest wrt the ordinary maths. No project reported 64 bits was needed.
It may have to do with the MicroMathematics plugin under design ?

Wrote

Here the question is:
How is it possible that by removing the Ortho function
from the graph, the file will work correctly?
What does the definition of the function
Ortho (x, y) = - x / y have to do with the version at 32 to 64 bit?

Good question. I see that you can get rid of the issue if you change the limits of the y axis. I think that the issue might be in some double value rounded differently in 64bit vs 32 bit... also the plugin is not based on external libraries... must be debugged

Wrote

What is the benefit of having SMath being delivered as 64 bit version?

Actually it is delivered as AnyCPU; it means that in 64 bit OS doesn't run emulated under WOW64, that adds some memory limitations (32/64 bit is not just matter of numbers' precision, but even about memory availability) and some CPU issues (see here). Also the 32bit flag isn't a magic wand, executable/plugins/OS incompatibility will ever occours under some combinations. That's just what is in my knowledge, Andrey know better than me the matter and the weight of the variables involved in the Smath Studio project.