From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,16a35419d117fb15 X-Google-Attributes: gid103376,public From: fluffy_doo@dsuper.net Subject: Re: discriminant Date: 1999/07/12 Message-ID: <378c1097.184220259@news.dsuper.net>#1/1 X-Deja-AN: 500146701 Content-Transfer-Encoding: 7bit References: <3789bfc2.97977684@news.dsuper.net> X-Original-NNTP-Posting-Host: asc16-addr-228.dsuper.net Content-Type: text/plain; charset=us-ascii X-Trace: 12 Jul 1999 11:56:11 -0400, delphi.dsuper.net Organization: via Internet Direct MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-07-12T00:00:00+00:00 List-Id: On Mon, 12 Jul 1999 13:11:20 GMT, in comp.lang.ada you wrote: (Sorry about the e-mail Roger, I pushed the wrong button.) >I had to make a couple of changes to your source to get it to compile without >warnings or errors. Specifically, note that the spelling of "mantissa" is not >consistent. I assume those were typos in your message. Yes my stuff was with french based terminology and I forgot to change a couple of "Mantisse" to "Mantissa" when I transcribed for this news exchange. >When I corrected >those, I got a warning about Len raising Constraint_Error (it is assigned a >value of 0, which is outside its range), so I changed it to have an initial >value of 1. Yes, 1 is what it should be. >After that, I created a test, which worked fine on the latest >GNAT (3.12a) on Windows NT. > >What version of what compiler are you using on what host? Aonix : ObjectAda for Windows V7.1.105 (special edition). OS : Windows 95 (4.00.950) machine : P150 >Can you provide a complete test that fails? There's no failure, and there *should* be one. I was using the debugger while checking something else when I noticed the problem I've described (which made it difficult or impossible to continue the original check with the debugger I was trying to make). Maybe it's a debugger problem. Maybe it's just not showing me the actual value for the variable I'm looking at. Anyway, I'll make some changes so the var names and comments correspond to English terms and I'll make another post with the attachment containing the function that returns a T_Number type. I should probably also include the function that makes the reciprocal conversion ( T_Number => String ) so that you can at least output to the screen. Keep in mind though that both functions have errors in them, they're earlier versions. The errors are not related to the problem I'm discussing here. Also, in the current versions there is no longer a "Point" field with the "kind = REAL" discriminant. The whole point of this post and my previous one is not the actual value returned or output of my String => T_Number function but what goes on inside it: assigning a new value to the "Power_R" field affects an unwanted and unexplained change in the value of the "Point" field, and the new value of the "Point" field is *outside* the field's range. When I then try to assign a new value to Point, a few lines of code down, its value doesn't change, like it's locked in, but the debugger doesn't complain. This is what I see with the debugger. I've got to go to school now. I'll do it tonight. Thanks for helping. Marc -- What I really am is "fluffy", no "_dong", no "_puff", no "_woo", no nothing, just plain fluffy.