Do you mean something like "Steelfire" done/augmented a while ago ?

ODE Multiconditional [Steel fire].sm (63 KiB) downloaded 32 time(s).

... the compactum for loop counter is most shorter, slightly adapted.

ODE Multiconditional [Carlos Compactum].sm (26 KiB) downloaded 36 time(s).

Wrote

Do you mean something like "Steelfire" done/augmented a while ago ?

Like this..

One of my memory cards decided to leave me hanging this weekend.. I guess I've spent too much time on SMath.

Cheers.


Steel_temperature_complete.sm (90 KiB) downloaded 54 time(s).

Wrote

I guess I've spent too much time on SMath.

Spare time to adapt your project around the more advanced ODE multi-condition.
Be careful about Bolean, sometimes tolerant but generally must be specified completely.
Mathcad was more tolerant Bolean, however had to be doctored many times in Collaboratory.
Naturally, your document is red top to bottom SS 6179.
It is so much over killed of useless, it should pass QA piecewise.
If you join visibly, no need for the TOL.
In short wrt your SS version, you must arrive at the exportable pieces.
Each piece for QA sanity check [Matlab, Mathcad ...]
Cheers ... Jean

ODE Multiconditional [Carlos Compactum] Copy.sm (80 KiB) downloaded 38 time(s).

In the event this document generates red in your version,
no more help/doctoring is possible whereas SS version incompatibilities.

Wrote

In the event this document generates red in your version,
no more help/doctoring is possible whereas SS version incompatibilities.

Jean, I didnt understand till now what you meant by ‘red top to bottom’.

I will have a look at your sheet tomorrow.

Cheers

Wrote

In the event this document generates red in your version,
no more help/doctoring is possible whereas SS version incompatibilities.

The document is indeed red top to bottom.

Anyway, although the document became less "techincal" after uniting all pieces in one single ODE using cases(), the project is now complete after some testing against a Excel spreadsheet I found online.

SMath community comes through once again!

Wrote

The document is indeed red top to bottom.

Are you saying that my SS 6179 is all red in your latest SS ?
That must be checked by other volunteers ... Maybe Andrey himself.
If it is true, latest SS don't read previous, nice to know,
time for me to leave Smath Community, have cabbage grow on poles !
Here is the PDF... Jean.

ODE Compactum.pdf (170 KiB) downloaded 40 time(s).

Wrote

The document is indeed red top to bottom.

I can't believe your SS turns my SS 6179 red.
If so red, please make a PDF as you have red at opening.
At some point, it must be clear if your SS is bug, hopefully reconciliate the project.
Cheers ... Jean, have a good day.

ODE Multiconditional [Carlos Compactum] TEST.sm (31 KiB) downloaded 44 time(s).

Wrote

Wrote

The document is indeed red top to bottom.

I can't believe your SS turns my SS 6179 red.
If so red, please make a PDF as you have red at opening.
At some point, it must be clear if your SS is bug, hopefully reconciliate the project.
Cheers ... Jean, have a good day.

ODE Multiconditional [Carlos Compactum] TEST.sm (31 KiB) downloaded 44 time(s).

Jean,

I just printed this PDF.

Cheers.

ODE Multiconditional [Carlos Compactum] TEST.pdf (102 KiB) downloaded 46 time(s).

Wrote

Jean, I just printed this PDF.

Thanks Hanski, that identifies the Smath bug.
Since which SS version, that bug exists ... ?
If you can't doctor as given, end of most Smath.
Of so many utilities that make Smath productive, the auto-increment for loop
is by large the most used and necessary. If I would update my 6179,
a great percentage of my 2500 documents would turn red hot.

Hope designers read this. If not acknowledged, will report in "Bugs"
Was that bug introduced at time indexing the LHS definition 'data[i:= ...'
At work Doctors

Cheers ... Jean

If something is highlighted in red, this is not always a program bug. Here, perhaps, with the change of the DotNumerics plugin, this type of the last parameter is not supported.

The switch from 5346 to 6179 didn't destroy any of the previous 5346.
That latest SS destroys 6179 is purely a bug.
Mathcad 11 didn't destroy previous Mathcad 8
Decode the freaked code is non-sense to me.
Hello Hanski, try to decode the bug, let's see if it goes to end.

Jean

... Hello Hanski,
This document simulates the bug of your SS version,
it decodes the bug. So, the TEST version and the all original
should work top to bottom. If not => desperate case, recycle.

JeanDoctored version.sm (31 KiB) downloaded 38 time(s).

Wrote

That latest SS destroys 6179 is purely a bug.
Mathcad 11 didn't destroy previous Mathcad 8
Decode the freaked code is non-sense to me.

This is not true. Mathcad will change format if you save the document. You must use internal converter to save document in old mcd format.



In the world of Mathcad, Jean, you would only use version 6 and ask everyone to convert the file, because none of the files would open in your version. But you don’t do that because you manually convert files using Mathcad 11 to maintain compatibility. I'm right?
Here you have the opportunity to open files saved in the new version and you are still not happy with something.

If the file format has changed and this is documented, then this is not a bug. Otherwise, you should write in the PTC forum that each new version of Mathcad destroy your old-style documents. This is non-sense to me.

Wrote

... Hello Hanski,
This document simulates the bug of your SS version,
it decodes the bug. So, the TEST version and the all original
should work top to bottom. If not => desperate case, recycle.

JeanDoctored version.sm (31 KiB) downloaded 38 time(s).

Jean,

My very limited capabilities within SMath is unable to «doctor» this.

I understand SMath is a work in progress (thank god). It seems a shame older sheets are throwing up errors because the structure/use of functions are no longer supported/have changed.

But then again, maybe we are spoiled we are even able to open old sheets in new releases.

I love SMath and use it more or less exclusively.

Best regards..

Wrote

Jean,
My very limited capabilities within SMath is unable to «doctor» this.
I understand SMath is a work in progress (thank god). It seems a shame older sheets are throwing up errors because the structure/use of functions are no longer supported/have changed.

1. That piece that turned red in your *.PDF, try to code as per Uni snippet.
2. Otherwise, try to doctor the damaged SS 6179 as demonstrated.
There is no justification for your SS version to convert SS 6179 scalar into nested vector.
That to me is a bug that may render zillions documents red from the Samples Repository.
Please report where you stand-in [blue sky, red document, OK].
Cheers ... Jean.



ODE Multiconditional [Carlos Compactum] Copy.sm (82 KiB) downloaded 30 time(s).

Wrote

In the world of Mathcad, Jean, you would only use version 6 and ask everyone to convert the file, because none of the files would open in your version. But you don’t do that because you manually convert files using Mathcad 11 to maintain compatibility. I'm right?
Here you have the opportunity to open files saved in the new version and you are still not happy with something.

BTW Viacheslav, PTC is RIP where you guess !
That MCD 7 couldn't open 8 was a Mathsoft $.
My Mathematica 4.0 opens newer version, though Mathematica is snoozing for a long time.
I got MCD 8 Pro around August 2000, few days after the Mathsoft Collaboratory.
As there were demands for 7 to read 8. Xavier [from recollection] designed
a little bit of code called "distiller" that did the conversion.
Naturally, 7 or 8 users that were doctored were saved back original.
Yes, not happy latest SS converts SS 6179 scalar into vector.
Thanks for your immense contribution ... Jean.

Simplified version.



ODE Multiconditional [Carlos Compactum] (uni).sm (15 KiB) downloaded 47 time(s).

... w/o for loop, still conserving the export for QA sanity.